(57)【要約】  状態変化をトリガすることは、第１のセットアップ構成に基づいて一連のフレームの第１のバージョンを表示すること、一連のフレームに対する第２のセットアップ構成を取得すること、第２のセットアップ構成を取得したことに応じて、目の状態の変化を監視すること、及び目の状態の変化を検出したことに応じて、第２のセットアップ構成に基づいて一連のフレームの第２のバージョンを表示すること、を含む。【選択図】図２
2019530928.tif 000002
【特許請求の範囲】
【請求項１】
状態変化をトリガするための方法であって、
第１のセットアップ構成に基づいて、一連のフレームの第１のバージョンを表示することと、
前記一連のフレームに対する第２のセットアップ構成を取得することと、
前記一連のフレームの第１のバージョンが表示されている間に、前記第２のセットアップ構成を取得することに応じて、目の状態の変化を監視することと、
前記目の状態の変化を検出したことに応じて、前記第２のセットアップ構成に基づいて、前記一連のフレームの第２のバージョンを表示することと、を含む、方法。
【請求項２】
前記目の状態の変化は、ユーザの不注意を示す、請求項１に記載の方法。
【請求項３】
表示することは、
前記第２のセットアップ構成を取得したことに応じて、前記一連のフレームの前記第２のバージョンをレンダリングし、前記目の状態の前記変化が検出されるまで前記一連のフレームの前記第２のバージョンを表示しないこと、を含む、請求項１に記載の方法。
【請求項４】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境において表示された仮想コンテンツに関連付けられている、請求項１に記載の方法。
【請求項５】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境の特性を対象とする、請求項１に記載の方法。
【請求項６】
目の状態の変化を監視することは、
前記目の状態に対応する目に面するカメラから複数の画像フレームを取得することと、
前記目のまばたきについて前記複数の画像フレームを監視することと、を含む、請求項１に記載の方法。
【請求項７】
目の状態の変化を監視することは、前記目の状態に対応する目の視線方向を監視することを含む、請求項１に記載の方法。
【請求項８】
システムであって、
表示デバイスと、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに結合され、前記１つ以上のプロセッサによって実行可能なコンピュータコードを含むメモリであって、前記コンピュータコードは前記システムに、
第１のセットアップ構成に基づいて、一連のフレームの第１のバージョンを前記表示デバイス上に表示させ、
前記一連のフレームに対する第２のセットアップ構成を取得させ、
前記一連のフレームの第１のバージョンが表示されている間に、前記第２のセットアップ構成を取得したことに応じて、目の状態の変化を監視させ、
前記目の状態の変化を検出したことに応じて、前記第２のセットアップ構成に基づいて、前記一連のフレームの第２のバージョンを表示させる、メモリと、を備える、システム。
【請求項９】
前記目の状態の前記変化は、ユーザの不注意を示す、請求項８に記載のシステム。
【請求項１０】
表示する前記コンピュータコードは、
前記第２のセットアップ構成を取得したことに応じて、前記一連のフレームの前記第２のバージョンをレンダリングし、前記目の状態の前記変化が検出されるまで前記一連のフレームの前記第２のバージョンを表示しないコンピュータコードを更に含む、請求項８に記載のシステム。
【請求項１１】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境において表示された仮想コンテンツに関連付けられている、請求項８に記載のシステム。
【請求項１２】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境の特性を対象とする、請求項８に記載のシステム。
【請求項１３】
目の状態の変化を監視する前記コンピュータコードは、
前記目の状態に対応する目に面するカメラから複数の画像フレームを取得し、
前記目のまばたきについて前記複数の画像フレームを監視するコンピュータコードを含む、請求項８に記載のシステム。
【請求項１４】
目の状態の変化を監視することは、前記目の状態に対応する目の視線方向を監視することを含む、請求項８に記載のシステム。
【請求項１５】
１つ以上のプロセッサによって実行可能なコンピュータ可読コードを含むコンピュータ可読媒体であって、前記コンピュータ可読コードは、
第１のセットアップ構成に基づいて、一連のフレームの第１のバージョンを表示デバイス上に表示し、
前記一連のフレームに対する第２のセットアップ構成を取得し、
前記一連のフレームの第１のバージョンが表示されている間に、前記第２のセットアップ構成を取得したことに応じて、目の状態の変化を監視し、
前記目の状態の変化を検出したことに応じて、前記第２のセットアップ構成に基づいて、前記一連のフレームの第２のバージョンを表示する、コンピュータ可読媒体。
【請求項１６】
前記目の状態の前記変化、ユーザの不注意を示す、請求項１５に記載のコンピュータ可読媒体。
【請求項１７】
表示する前記コンピュータコードは、
前記第２のセットアップ構成を取得したことに応じて、前記一連のフレームの前記第２のバージョンをレンダリングし、前記目の状態の前記変化が検出されるまで前記一連のフレームの前記第２のバージョンを表示しないコンピュータコードを更に含む、請求項１５に記載のコンピュータ可読媒体。
【請求項１８】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境において表示された仮想コンテンツに関連付けられている、請求項１５に記載のコンピュータ可読媒体。
【請求項１９】
前記第１のセットアップ構成及び前記第２のセットアップ構成は、現実環境の特性を対象とする、請求項１５に記載のコンピュータ可読媒体。
【請求項２０】
目の状態の変化を監視する前記コンピュータコードは、
前記目の状態に対応する目に面するカメラから複数の画像フレームを取得し、
前記目のまばたきについて前記複数の画像フレームを監視するコンピュータコードを含む、請求項１５に記載のコンピュータ可読媒体。
【請求項２１】
目の状態の変化を監視することは、前記目の状態に対応する目の視線方向を監視することを含む、請求項１５に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２０１６年９月２２日に出願された米国仮特許出願第６２／３９８，４３８号に対し、米国特許法３５Ｕ．Ｓ．Ｃ．第１１９条（ｅ）に基づく優先権を主張し、その内容が全体として参照により本明細書に組み込まれる。
【背景技術】
【０００２】
本開示は、一般にデジタル画像処理の分野に関し、より詳細にはグラフィカルユーザインタフェース（ＧＵＩ）設計の分野に関する。具体的には、ＧＵＩに影響を及ぼす情報の状態変化を延期し、ＧＵＩのユーザの不注意状態の間に状態変化をトリガすることに関する。
【０００３】
現在の技術では、ユーザは多くの方法で自分たちの環境と対話できる。例として、ゲームソフトウェアでのＧＰＳデバイスは、ユーザが革新的な方法で現実の世界環境と対話することを可能にする。仮想情報を現実環境内にブレンドさせる際の１つの問題は、グラフィカルユーザインタフェースに対して行われた変更が、ユーザには不意で煩わしくて、ユーザエクスペリエンスを損なう場合があることである。
【０００４】
一例として、ＧＵＩ上の情報の状態変化は、ユーザがそれにフォーカスしている間に変化して混乱を引き起こすか、又はユーザがＧＵＩ内の近くの何かにフォーカスしているときに変化してユーザが気を散らす原因となるか、のいずれかの場合がある。コンピュータゲーム内の単語又はオブジェクトは、動的かつ急に現れる場合がある。画面上に表示される詳細レベルが突然変化して、ユーザに混乱を引き起こす場合がある。表示されているデータの状態変化に対処するために、改善されたユーザエクスペリエンスが必要とされる。
【発明の概要】
【０００５】
一実施形態では、状態変化をトリガするための方法が説明される。本方法は、第１のセットアップ構成に基づいて一連のフレームの第１のバージョンを表示すること、一連のフレームに対する第２のセットアップ構成を取得すること、第２のセットアップ構成を取得したことに応じて、目の状態の変化を監視すること、及び目の状態の変化を検出したことに応じて、第２のセットアップ構成に基づいて一連のフレームの第２のバージョンを表示すること、を含むことができる。別の実施形態では、本方法は、コンピュータ実行可能プログラムコードにおいて実施し、非一時的記憶装置に記憶することができる。更に別の実施形態では、本方法は、画像キャプチャ能力を有する電子デバイスによって実装することができる。
【図面の簡単な説明】
【０００６】
【図１】１つ以上の実施形態に係る、簡略化された多機能デバイスをブロック図形式で示す。
【図２】１つ以上の実施形態に係る、ＧＵＩに影響を及ぼす状態変化を管理するための方法をフローチャート形式で示す。
【図３】１つ以上の実施形態に係る、ＧＵＩに影響を及ぼす状態変化を管理するための別の方法をフローチャート形式で示す。
【図４】１つ以上の実施形態に係る、詳細レベルの状態変化を管理することを示す例示的なフロー図を示す。
【図５】１つ以上の実施形態に係る、更新されたキーフレームに基づいて状態変化を管理するための方法の例示的なフロー図を示す。
【図６】１つ以上の実施形態に係る、更新された詳細レベルに基づいて状態変化を管理するための方法の例示的なフロー図を示す。
【図７】１つ以上の実施形態に係る、更新された詳細レベルに基づいて状態変化を管理するための方法の例示的なフロー図を示す。
【図８】１つ以上の実施形態に係る、コンピューティングデバイスの例示的なシステム図を示す。
【発明を実施するための形態】
【０００７】
本開示は、不注意状態の間にグラフィカルユーザインタフェース（ＧＵＩ）に影響を及ぼす情報の状態変化を延期するためのシステム、方法、及びコンピュータ可読媒体に関する。一般に、一連のフレームに対するセットアップ構成が検出されると、一連のフレームの新しいバージョンがレンダリングされ得るが、ユーザが不注意であると判定されるまでは表示されないように、ＧＵＩ上の表示を管理するための技術が開示されている。例えば、１つ以上の実施形態によれば、ユーザがまばたき又は目をそらすと判定されるまで、フレームのセットの第１のバージョンが表示されてもよい。１つ以上の実施形態によれば、ユーザの不注意状態の間に表示を変更することは、ユーザに対する変更からの注意散漫を最小化するか、又はより軽減することができる。
【０００８】
１つ以上の実施形態によれば、新しいセットアップ構成を検出すると、システムは、第１の一連のフレームが表示されている間に、一連のフレームの第２のバージョンをレンダリングしてもよい。すなわち、一連のフレームの第１のバージョン及び一連のフレームの第２のバージョンが、並行してレンダリングされてもよい。いくつかの実施形態では、フレームの第２のバージョンが表示され得るまで、一連のフレームの両方のバージョンがレンダリングされてもよい。第２の一連のフレームは、目の状態の変化が検出されるまで、又は目の状態の変化が予測されるときは、レンダリングされなくてもよい。このように、一連のフレームのうちの２つのバージョンは、より短い期間に並行して生成されてもよい。
【０００９】
以下の記載では、説明を目的として、開示された概念に対する理解を深めるために、多くの具体的な詳細を説明している。この記載の一部として、本開示の図面のいくつかは、開示された実施形態の新規の態様が不明瞭になるのを避けるために、構造及び装置をブロック図の形態で表す。これに関連して、関連識別子のない番号（例えば、１００）を付された図の要素の参照は、識別子を有する図の要素のすべてのインスタンス（例えば、１００ａ及び１００ｂ）を参照することを理解されたい。更に、本記載の一部として、本開示の図のうちのいくつかは、フロー図の形式で提供されることがある。フロー図のボックスは、特定の順序で提示されてもよい。しかしながら、いずれのフロー図の特定のフローも、１つの実施形態を例示するためにのみ使用されることを理解されたい。他の実施形態では、フロー図に示された様々な構成要素のいずれも、削除され得、あるいは、これらの構成要素は、異なる順番で、又は同時にも、実行され得る。加えて、他の実施形態は、フロー図の一部として示されていない追加のステップを含み得る。本明細書において使用される文言は、専ら読みやすさ及び説明の目的で選択されたものであり、開示された主題を限定又は制限するために選択されたものではない。本開示において「１つの実施形態」又は「一実施形態」を言及することは、実施形態に関して述べる特定の特徴、構造又は特性が少なくとも１つの実施形態に含まれることを意味し、そして、「１つの実施形態」又は「一実施形態」を何度も言及することは、必ずしも全てが同じ実施形態を又は異なる実施形態を言及することとして理解されるべきではない。
【００１０】
（任意の開発プロジェクトの場合のような）任意の実際の具現化の開発では、開発者特有の目標（例えば、システム及びビジネス関連制約との適合）を達成するために多数の判断をしなければならず、かつ、これらの目標は、具現化ごとに変化し得ることが了解されよう。また、そのような開発努力は複雑で時間がかかることがあるが、それにもかかわらず、本開示の利益を有する画像キャプチャの当業者の日常行うべきものであることも了解されよう。
【００１１】
本開示の目的のため、用語「カメラ」は、センサ素子及び画像をキャプチャするために利用される他の回路と共に、単一のレンズアセンブリを指す。本開示の目的のため、２つ以上のカメラは、単一のセンサ素子及び他の回路を共有するが、２つの異なるレンズアセンブリを含んでもよい。しかしながら、１つ以上の実施形態では、２つ以上のカメラは、別個のセンサ素子並びに別個のレンズアセンブリ及び回路を含んでもよい。
【００１２】
図１を参照すると、本開示の１つ以上の実施形態に係る、電子デバイス１００の簡略化されたブロック図が示されている。電子デバイス１００は、携帯電話、タブレットコンピュータ、携帯情報端末、携帯音楽／ビデオプレーヤ、又はカメラシステム、ディスプレイ、及び様々な実施形態を実行するために利用される他の構成要素を含む任意の他の電子デバイスなどの、多機能デバイスの一部であってもよい。電子デバイス１００は、モバイルデバイス、タブレットデバイス、デスクトップデバイス、並びにサーバなどのネットワーク記憶装置など、ネットワークを横断して他のネットワークデバイスに接続され得る。
【００１３】
電子デバイス１００は、中央演算処理装置（central processing unit、ＣＰＵ）１３０を含んでもよい。プロセッサ１３０は、例えば、モバイル機器に見られるようなシステムオンチップでもよく、１つ以上の専用グラフィック処理ユニット（graphics processing unit、ＧＰＵ）を含んでもよい。更に、プロセッサ１３０は、同じタイプ又は異なるタイプの複数のプロセッサを含んでもよい。電子デバイス１００はまた、メモリ１４０を含んでもよい。メモリ１４０は、ＣＰＵ１３０と連動してデバイス機能を実行するために使用することができる、１つ以上の異なるタイプのメモリを含んでもよい。例えば、メモリ１４０は、キャッシュ、ＲＯＭ、及び／又はＲＡＭを含み得る。メモリ１４０は、目の状態モニタ１５５及びグラフィック表示モジュール１６０を含む、実行中の様々なプログラミングモジュールを記憶することができる。１つ以上の実施形態によれば、メモリ１４０は、動的セットアップ構成データに基づいてグラフィカルユーザインタフェースを生成及び管理するために利用される追加のアプリケーションを含み得る。例えば、メモリ１４０は、レンダリングエンジンを付加的に含んでもよい。
【００１４】
電子デバイス１００はまた、前面カメラ１１０及び背面カメラ１２０などの１つ以上のカメラを含んでもよい。カメラ１１０及び１２０は、画像センサ、レンズスタック、及び画像をキャプチャするために使用することができる他の構成要素をそれぞれ含んでもよい。１つ以上の実施形態では、カメラは、電子デバイス内の異なる方向に向けられてもよい。例えば、前面カメラ１１０は、電子デバイス１００の第１の面内又はその面上に配置されてもよく、背面カメラ１２０は、電子デバイス１００の第２の面内又はその面上に配置されてもよい。１つ以上の実施形態では、第１及び第２の面は、電子デバイス１００の向かい合う面であってもよい。別の例として、前面カメラ１１０は、ユーザの視点から現実環境の画像をキャプチャするように構成されていてもよいが、背面カメラ１２０は、ユーザの画像をキャプチャするように構成されている。以下で更に詳細に説明するように２つのカメラが示されているが、いくつかの実施形態では、電子デバイス１００は単一のカメラを含んでもよい。更に他の実施形態では、電子デバイス１００はまた、ディスプレイ１５０を含んでもよい。センサ１７５は、例えば、視線の方向、又は目が開いているか若しくは閉じているかどうかなどの、目の状態を判定する際に使用され得る任意の種類のセンサを含んでもよい。ディスプレイ１５０は、ＬＣＤディスプレイ、ＬＥＤディスプレイ、ＯＬＥＤディスプレイなどの任意の種類の表示デバイスであってもよい。加えて、ディスプレイ１５０は、ヘッドアップディスプレイなどの半不透明ディスプレイであり得る。電子デバイス１００は、上述した多数の構成要素を含むものとして示されているが、１つ以上の実施形態では、様々な構成要素は、複数のデバイスにわたって分散されてもよい。更に、追加の構成要素が使用されてもよく、構成要素のうちのいずれかの、機能性の一部の組み合わせが結び付けられてもよい。
【００１５】
１つ以上の実施形態によれば、目の状態モニタ１５５は目の状態を監視する。いくつかの実施形態では、目の状態は、ユーザの注意深さ又は不注意を示す。すなわち、目の状態モニタ１５５は、例えば、前面カメラ１１０から、又は様々なセンサ１７５から受信したデータに基づいて、ユーザが注意深いかどうかを判定してもよい。加えて、目の状態モニタ１５５は、目の状態の変化を予測することができる。例えば、前面カメラ１１０からの画像は、目が閉じられたか若しくは閉じているところか、又は目がディスプレイ１５０とは異なる方向を見ているかどうかを示すことができる。別の例として、目の周囲の筋肉を監視するセンサは、目がまばたきしようとしていることを検出し、それによって目の状態の変化を予測することができる。１つ以上の実施形態では、目の状態モニタ１５５は、目の状態を連続的に監視してもよく、又は定期的に若しくは必要なときに目の状態を監視してもよい。例えば、目の状態モニタ１５５は、新しいセットアップ構成が利用可能であると判定することに応じて、目の状態を監視してもよい。
【００１６】
１つ以上の実施形態によれば、グラフィック表示モジュール１６０は、所与のセットアップ構成に基づいて一連のフレームを生成するように構成されていてもよい。１つ以上の実施形態では、セットアップ構成は、例えば、センサ１７５、又はカメラ１１０及び１２０によってローカルに受信されたデータに基づいてもよい。加えて、又は代替的に、セットアップ構成に関するデータは、ネットワークデバイス又はサーバなどのリモートソースから受信されてもよい。一例として、電子デバイス１００が地図上に方向を表示している場合、セットアップ構成はＧＰＳユニット（図示せず）からのデータを含んでもよい。グラフィック表示モジュール１６０は、ＧＵＩのビューを一連のフレームとして変更する、更新されたセットアップ構成情報を時に受信してもよい。一例として、更新されたＧＰＳ情報が、ユーザが実際に、示される初期セットアップ構成データとは異なる道路又はレーン上にあることを示す場合に、一連のフレームの第２のバージョンがレンダリングされてもよい。１つ以上の実施形態では、グラフィック表示モジュール１６０は、複数の一連のフレームを同時に生成してもよい。実施例に戻ると、更新されたＧＰＳデータが受信された場合、グラフィック表示モジュール１６０は、第１の一連のフレームが依然としてレンダリングされ、かつ、表示されている間に、一連のフレームの第２のバージョンをレンダリングし始めてもよい。このように、グラフィック表示モジュール１６０は、要求に応じて、一連のフレームの第１のバージョンから一連のフレームの第２のバージョンにトグルすることができる。１つ以上の実施形態によれば、グラフィック表示モジュール１６０は、目の状態モニタ１５５によって判定された目の状態の変化に基づいて、一連のフレームの第２のバージョンを表示し始めるときを判定してもよい。いくつかの実施形態では、グラフィック表示モジュール１６０は、ユーザが不注意であると判定されると、表示された構成情報のバージョンを切り替えることができる。別の言い方をすれば、グラフィック表示モジュール１６０は、不注意の条件が満たされるまで、ＧＵＩ内のグラフィック表現の状態変化を延期することができる。
【００１７】
一例として、コンピュータゲームにおいて、新しいセットアップ構成は、ゲーム環境内に表示するために利用可能となる新しいオブジェクトを含むことができる。グラフィック表示モジュール１６０は、まばたきの後に新しいオブジェクトが表示されるように、新しいオブジェクトなしでゲーム環境を提示し続け、ユーザがまばたきしている間にゲーム環境を提示し続けてもよい。同様に、グラフィック表示モジュール１６０は、拡張現実アプリケーションにおいて、現実環境で表示するためのレンダリングされた仮想オブジェクトの変更を延期することができる。別の例として、プログレッシブＪＰＥＧは、より粗いブロックからより細かいブロックへ、又はより細かいブロックからより粗いブロックへ遷移してもよい。グラフィック表示モジュール１６０は、ユーザが不注意になるまで、更新された詳細レベルの表示を延期することができる。セットアップ構成は、他の方法で詳細レベルに適用することができる。例えば、地図へのズーム時には、ストリート名又は近隣などの情報が現れるか又は消失し得る。グラフィック表示モジュール１６０は、ユーザが不注意になるまで、地図上の表示された詳細レベルの変更を延期することができる。
【００１８】
図２は、１つ以上の実施形態に係る、ＧＵＩに影響を及ぼす状態変化を管理するための方法をフローチャート形式で示す。様々なアクションが特定の順序で示されているが、異なる実施形態では、様々なアクションが異なる順序で示されてもよい。更に、いくつかの実施形態では、２つ以上のアクションが同時に生じてもよい。他の実施形態では、アクションのいくつかは必要とされなくてもよく、又は他のアクションが含まれてもよい。明確にするため、フローチャートが、図１の様々な構成要素に関して説明される。しかしながら、様々なアクションが代替の構成要素によって取られてもよいことを理解されたい。
【００１９】
フローチャートは、グラフィック表示モジュール１６０がディスプレイ１５０上に一連のフレームの第１のバージョンを表示させる２０５で開始する。１つ以上の実施形態では、グラフィック表示モジュール１６０は、第１のセットアップ構成に基づいて、最初の一連のフレームを生成してもよい。第１のセットアップ構成は、一連のフレームをどのようにレンダリングすべきかを示す任意のデータであってもよい。１つ以上の他の実施形態では、グラフィック表示モジュール１６０は、背面カメラ１２０などのカメラによってキャプチャされた一連のフレームを提示してもよく、又は別の方法によって生成されるフレームを提示してもよい。更に、一連のフレームは、他のデータに基づいてレンダリングされる追加情報を含んでもよい。例えば、リモートサーバから、又はセンサ１７５から収集されたデータである。一例として、グラフィック表示モジュール１６０は、ディスプレイ１５０上に、背面カメラ１２０によってキャプチャされた現実環境のビュー内に仮想オブジェクトを提示してもよい。
【００２０】
フローチャートは２１０に続き、セットアップ構成における更新が識別されたかどうかに関する判定が行われる。上述のように、セットアップ構成における更新は、一連のフレームがどのようにレンダリングされるかを決定する任意の種類のデータであってもよい。例えば、より多くの又はより少ない詳細が利用可能であり得るか、又は他の要因に応じて、より大きい又はより少ないレベルの詳細を含むことが好ましい場合がある。更新が検出されない場合、フローチャートは２０５に続き、グラフィック表示モジュール１６０は、第１のセットアップ構成に基づいて一連のフレームの第１のバージョンを表示し続ける。２１０に戻ると、セットアップ構成における更新が識別されたと判定された場合、フローチャートは２１５に続き、グラフィック表示モジュール１６０は、更新されたセットアップ構成に基づいて一連のフレームの第２のバージョンをレンダリングする。
【００２１】
フローチャートは２２０に続き、目の状態モニタ１５５が目の状態の変化を監視する。１つ以上の実施形態によれば、目の状態モニタ１５５は、注視又はまばたきの変化を監視してもよく、これらのいずれかは、ユーザの不注意状態を示すことができる。いくつかの実施形態では、目の状態モニタ１５５は、例えば、前面カメラ１１０によって提供される目の画像を監視してもよい。更に、他の実施形態では、目の状態モニタ１５５は、目の状態の変化を判定するために、センサ１７５からの追加のセンサデータに依存してもよい。いくつかの実施形態によれば、目の状態モニタ１５５は、ユーザの目の状態を連続的に監視してもよく、又はセットアップ構成更新の識別に応じて、又はグラフィック表示モジュール１６０が、更新されたセットアップ構成に基づく一連のフレームの第２のバージョンをレンダリングしたことに応じて、目の状態を監視し始めてもよい。
【００２２】
フローチャートは２２５に続き、目の状態の変化が検出されたかどうかに関する判定が行われる。１つ以上の実施形態によれば、目の状態の変化は、ユーザが不注意であることを示してもよい。例えば、ユーザは、まばたきしているか、又はディスプレイから目をそらしている。他の実施形態では、ユーザの片目又は両目がまだ開いている場合に、目をそらすことが、ユーザが不注意であるとするのには十分ではない場合がある。むしろ、ユーザは、ユーザがディスプレイの変化を意識し得ないような方法で見ていなければならない。例えば、ユーザが依然としてＧＵＩのグラフィックの急激な変更に気付く可能性がある場合、異なる場所を単に見ているだけでは不十分である場合がある。例えば、ユーザの周辺視力においてである。２２５において目の状態の変化が検出されない場合、フローチャートは２２０に続き、目の状態モニタ１５５が目の状態の変化を監視し続ける。２２５に戻ると、目の状態の変化が検出されたと判定された場合、フローチャートは２３０に続き、グラフィック表示モジュール１６０は、第２のセットアップ構成に基づいて一連のフレームの第２のバージョンを表示し始める。
【００２３】
図３は、１つ以上の実施形態に係る、ＧＵＩに影響を及ぼす状態変化を管理するための別の方法をフローチャート形式で示す。図３のフローチャートは、図２の実施形態に対する代替の実施形態を示すことができる。様々なアクションが特定の順序で示されているが、いくつかの実施形態では、様々なアクションが異なる順序で示されてもよい。その上、更に他の実施形態では、２つ以上のアクションが同時に生じてもよい。加えて、なおも他の実施形態によれば、アクションのいくつかは必要とされなくてもよく、又は他のアクションが含まれてもよい。明確にするため、フローチャートが、図１の様々な構成要素に関して説明される。しかしながら、１つ以上の実施形態によれば、様々なアクションが代替の構成要素によって取られてもよいことを理解されたい。
【００２４】
フローチャートは３０５において開始し、グラフィック表示モジュール１６０に、ディスプレイ１５０上に一連のフレームの第１のバージョンを表示させる。１つ以上の実施形態では、グラフィック表示モジュール１６０は、第１のセットアップ構成に基づいて、最初の一連のフレームを生成してもよい。第１のセットアップ構成は、一連のフレームをどのようにレンダリングすべきかを示す任意のデータであってもよい。他の実施形態では、グラフィック表示モジュール１６０は、背面カメラ１２０などのカメラによってキャプチャされた一連のフレームを提示してもよく、又は別の方法によって生成されるフレームを提示してもよい。更に、一連のフレームは、他のデータ、例えば、リモートサーバから又はセンサ１７５から収集されたデータに基づいてレンダリングされる追加情報を含んでもよい。一例として、グラフィック表示モジュール１６０は、ディスプレイ１５０上に、背面カメラ１２０によってキャプチャされた現実環境のビュー内に仮想オブジェクトを提示してもよい。
【００２５】
フローチャートは３１０に続き、セットアップ構成における更新が識別されたかどうかに関する判定が行われる。上述のように、セットアップ構成における更新は、一連のフレームがどのようにレンダリングされるべきかを決定する任意の種類のデータであってもよい。例えば、より多くの又はより少ない詳細が利用可能であり得るか、又は他の要因に応じて、より大きい又はより少ないレベルの詳細を含むことが好ましい場合がある。更新が検出されない場合、フローチャートは３０５に続き、グラフィック表示モジュール１６０は、第１のセットアップ構成に基づいて一連のフレームの第１のバージョンを表示し続ける。しかしながら、図２に示されるステップとは対照的に、３１０においてセットアップ構成における更新が識別された場合、フローチャートは３１５に続き、グラフィック表示モジュール１６０は、一連のフレームの第１のバージョンを表示し続けてもよい。
【００２６】
フローチャートは３２０に続き、目の状態モニタ１５５が目を監視して、目の状態の変化が予測されるかどうかを判定する。１つ以上の実施形態によれば、目の状態の変化は、例えば、正面カメラ１１０からの画像に基づいて予測され得る。他の実施形態では、画像は、例えば、目が閉じていることを示してもよい。別の例として、センサ１７５から他のセンサデータを収集して、目の状態の変化が予測されることを示すまばたき又は他の動きが生じているかどうかを判定することができる。例えば、センサデータは、まばたきが差し迫ったときを予測するために、目の周囲の筋肉の筋肉運動を監視してもよい。目の状態の変化が予測されるという判定に応じて、フローチャートは３２５に続き、グラフィック表示モジュール１６０は、更新されたセットアップ構成に基づいて、一連のフレームの第２のバージョンをレンダリングする。
【００２７】
フローチャートは３３０に続き、目の状態モニタ１５５が、目の状態の変化を監視する。１つ以上の実施形態によれば、目の状態モニタ１５５は、目の状態の変化を確認するために目を監視してもよい。一例として、まばたきを単に予測するのではなく、目の状態モニタ１５５は、まばたきを確認するために監視してもよい。フローチャートは３３５に続き、目の状態の変化が検出されたかどうかに関する判定が行われ得る。いくつかの実施形態によれば、目の状態の変化は、ユーザが不注意であることを示してもよい。例えば、ユーザは、まばたきしているか、又はディスプレイから目をそらしている。１つ以上の他の実施形態では、ユーザの片目又は両目がまだ開いている場合に、目をそらすことが、ユーザが不注意であると判定するのには十分ではない場合がある。むしろ、ユーザは、ユーザがディスプレイ１５０の変化を意識し得ないような方法で見ていなければならない。例えば、ユーザが依然として、例えばユーザの周辺視覚において、ＧＵＩのグラフィックの急激な変更に気付く可能性がある場合、異なる場所を単に見ているだけでは不十分である場合がある。３３５において目の状態の変化が検出されない場合、フローチャートは３３０に続き、目の状態モニタ１５５が目の状態の変化を監視し続ける。３３５に戻ると、目の状態の変化が検出されたと判定される場合、フローチャートは３４０に続き、グラフィック表示モジュール１６０は、第２のセットアップ構成に基づいて一連のフレームの第２のバージョンを表示し始める。
【００２８】
１つ以上の実施形態によれば、図２のフローチャートと図３のフローチャートとの間の差異は、フレームの第２のバージョンがレンダリングされ始めるときである。１つ以上の実施形態では、フレームの第１のバージョンの表示とフレームの第２のバージョンとの間の迅速な変更を行うために、図２に示すように、更新されたセットアップ構成が利用可能であるときに、フレームの第２のバージョンのレンダリングを開始することが好ましい場合がある。更に、他の実施形態によれば、目の状態における予測される変化に応じて、第２のバージョンのフレームをレンダリングし始めることが好ましい場合がある。例えば、リソースを節約するために、フレームの第２のバージョンのレンダリングを延期することが好ましい場合がある。更に他の実施形態によれば、グラフィック表示モジュール１６０がフレームの第２のバージョンをレンダリングし始める時間は、コンピューティングリソースが節約されるべきか、又はセットアップ構成の変化率などの他の要因に基づいて決定されてもよい。
【００２９】
図４は例示的なユースケースを示し、詳細レベルの変更が、ユーザが不注意になるまで延期される。本来、仮想オブジェクトをレンダリングするために使用されるべき詳細レベルは、仮想オブジェクトのカメラまでの距離に依存し得る。各詳細レベル、及び、例えば関連する３Ｄモデルは、特定の距離間隔に関連付けられてもよい。使用される詳細レベルの変化は、距離がある閾値を通過するときにトリガされ得る。一例として、距離が１つの間隔を離れて別の間隔に入ると、詳細レベルの変化がトリガされ得る。４０１において、球状物体がカメラの近くにあり、そのため高度にモザイク化されたモデルがレンダリングに使用される。モデルが（４０２のように）カメラから更に離れて移動すると、同じレベルの詳細が使用され得る。しかし、ある時点（４２１）では、オブジェクトがとても遠く離れているため、別の詳細レベルが選択され得る。４２１において閾値距離を通過することに応じて、４１３に示すように、球状物体はより低い詳細でレンダリングされてもよい。画像４０２から画像４１３への変化は、ユーザによって気付かれ得る。しかしながら、詳細レベルにおけるこの変化は、４２２においてユーザが不注意になるまで、再び延期される。このように、ユーザは、フレーム４０３及び４０４における、高度にモザイク化されたモデルを見続け得る。１つ以上の実施形態では、ユーザが４２２において不注意であった場合にのみ、フレーム４１５として実行及び表示される低解像度メッシュへ変更される。
【００３０】
図５は、仮想缶（５５１）が現実世界環境のカメラ画像（５１２〜５１６）内にレンダリングされる拡張現実システムにおいて本方法が採用される、別の例示的なユースケースを示す。図５の例では、状態変化は、ポーズ判定アルゴリズムにおける選択されたキーフレームに対して延期される。このように、１つ以上の実施形態では、画像における仮想缶の（位置、スケール、又は向きなど）外観の急激な変化が、ユーザが変更に気付かないように延期される。
【００３１】
この例の目的では、仮想オブジェクトは缶（５５１）であり、セットアップ構成は、キャプチャされた画像のカメラのポーズを判定するために使用される特定のキーフレーム（例えば、５０２）であり、可視化構成は、仮想オブジェクトをレンダリングするために使用されるカメラ／オブジェクトの特定の決定されたポーズである。可視化フレームは、仮想オブジェクト（５５１）のレンダリングによって重ね合わされた現実世界環境のカメラ画像（例えば、５１２）を示す拡張画像（例えば、５２２）である。
【００３２】
現実世界環境は、現実テーブル（例えば、（５４１））のシーンからなってもよい。シーンのモデルは、それぞれがテーブルの画像（例えば５０２、５０３）及びキーポーズと呼ばれる、対応する既知６自由度カメラポーズからなるキーフレームとして利用可能であり得る。図５の例では、キーフレーム画像（５０２、５０３）は、異なる視点からのテーブル（５４１、５４２）を示す。
【００３３】
次いで、移動カメラを使用してシーンをキャプチャすることができる。例えば、モバイルデバイスのカメラである。図５の第２列（５１１）は、ライブビデオフレーム（５１１）などのキャプチャされた画像のシーケンスを示す。取得された各画像に対して、ポーズ決定方法は、キャプチャされた画像自体、シーンモデル、並びに潜在的に、以前にキャプチャされた画像及びポーズの履歴に基づいて、カメラポーズを決定することができる。
【００３４】
現実世界の第１の取得画像（５１２）に対して、アルゴリズムは、最良フィッティングキーフレーム５０２を見つけ、画像（５１２）、キーフレーム画像（５０２）、及びキーフレーム画像（５０２）の既知のキーポーズに基づいて、画像（５１２）のカメラポーズを決定することができる。キーフレーム（５０２）に基づく画像（５１２）のカメラポーズを使用して、画像（５１２）の上部上に仮想缶（５５１）をレンダリングし、それによって拡張画像（５２２）をもたらすことができる。
【００３５】
現実世界の第２の取得画像（５１３）に対して、アルゴリズムは、同じキーフレーム画像（５０２）を最良のフィッティングキーフレーム画像とみなし続けてもよい。例えば、キーフレーム画像は、最良フィッティングキーフレーム画像として決定されてもよく、又は最良のキーフレームを決定するためのアルゴリズムは、フレーム毎にトリガされなくてもよく、前のフレームに対して最良であると考えられるものを使用する。それゆえ、アルゴリズムは、画像（５１３）、キーフレーム画像（５０２）、及びキーフレーム画像（５０２）の既知のキーポーズに基づいて、画像（５１３）のポーズを決定することができる。あるいは、アルゴリズムは、画像（５１３）、画像（５１２）、及び以前に決定された画像のポーズ（５１２）に基づいて画像（５１３）のポーズを決定することができ、画像（５１２）は、キーフレーム画像（５０２）及びキーフレーム画像（５０２）の既知のキーポーズに基づいて決定されたものである。両方の場合において、決定されたポーズは本来、キーフレーム（５０２）に依存し得る。キーフレーム（５０２）に基づく画像（５１３）の決定されたカメラポーズを使用して、画像（５１３）の上部上に仮想缶（５５２）をレンダリングし、それによって拡張画像（５２３）をもたらすことができる。
【００３６】
現実の世界環境の第３の取得画像（５１４）に対して、アルゴリズムは、別のキーフレーム画像が、最良のフィッティング画像、すなわちキーフレーム（５０３）であると、ここで判定することができる。標準的なアプローチでは、画像（５１４）、キーフレーム画像（５０３）、及びキーフレーム画像（５０３）の既知のキーポーズに基づいて、画像（５１４）のポーズを決定するために、新たに決定された最良のフィッティングキーフレーム（５０３）を、ここで直接使用することができる。キーフレーム（５０３）に基づく画像（５１４）の決定されたカメラポーズを使用して、画像（５１４）の上部上に仮想缶（５５５）をレンダリングし、それによって拡張画像（５３４）をもたらすことができる。使用されたキーフレーム（すなわち、セットアップ構成）におけるこの変化は、潜在的に、ポーズ（可視化構成）において、それゆえ仮想オブジェクトのレンダリングに目に見える急激な変化をもたらす可能性があるため、それはユーザに気付かれるであろう。しかしながら、ユーザが不注意であった場合、新しいキーフレーム（５０３）を使用してポーズを決定することができ、最終的な拡張画像が画像（５３４）であり得る。しかしながら、描かれた例では、ユーザが注意深いため、キーボード（５０２）は依然として可視化のためのポーズを決定するために使用され、最終的な拡張画像は画像（５２４）である。追跡アルゴリズムの不正確さ、及びキーフレーム（５０２）から決定されたポーズにより、缶（５５３）は、テーブルの上部上に面一にレンダリングされなくてもよいが、テーブルの上方にわずかに浮かんでいてもよいことに注意すべきである。すなわち、キーフレーム（５０３）は、画像（５３４）内で目に見えるより正確なポーズを提供することができ、缶（５５５）はテーブルにより良好に位置合わせされる。フレームがフレーム追跡するのを可能にするために、新しいキーフレーム（５０３）によるポーズを決定することも可能であり得る。しかしながら、このポーズは、仮想オブジェクトの現在のレンダリングに使用されなくてもよい。
【００３７】
現実世界の第４の取得画像（５１５）に対して、アルゴリズムは、キーフレーム画像（５０３）を最良のフィッティングキーフレーム画像と再度みなしてもよい。これは、最良のキーフレームを決定するためのアルゴリズムが、全てのフレーム毎にトリガされなくてもよく、前のフレームから最良であると考えられるものを使用するからである場合がある。ユーザが不注意である場合、新しいキーフレーム（５０３）を使用して（直接的に、又はキーフレーム５０３に本来基づくフレームに対する前のポーズ追跡フレームに基づいて、のいずれかで）ポーズを決定することができ、最終的な拡張画像は画像（５３５）となり得る。しかしながら、描かれた例では、ユーザが再度注意深いため、キーフレーム（５０２）はポーズを決定するために使用され得て、最終的な拡張画像は画像（５２５）である。その上、追跡アルゴリズムの不正確さ、及びキーフレーム（５０２）から決定されたポーズにより、缶（５５４）は、テーブルの上部上に面一にレンダリングされなくてもよいが、テーブルの上方に浮いているか、又はテーブルと交差している。１つ以上の実施形態では、キーフレーム（５０３）は、画像（５３５）の場合のように、より正確なポーズを潜在的に配信することができ、缶（５５６）はテーブルにより良好に位置合わせされる。
【００３８】
図６は、ユーザ又はアプリケーション自体が都市の地図内にズームインする、別の例示的なユースケースを示す。最初にズームアウトすると（６０１）、都市の大部分が示され、粗い情報のみが表示される（主要ストリート（６０６）、都市名（６０７））。６０２においてズームインすると、大きなストリート（６０８）及び都市名（６０９）のみが表示され続ける。しかしながら、更にズームインすると、アプリケーションは、追加情報（より少ない主要ストリート（６１３）、関心点に対するラベル（６１１）、地下交通（６１４））と共に、６０４などの画像を表示しようとする場合がある。代わりに都市名は、もはや表示されなくてもよい（６１２）。追加情報が表示されるべきである場合、６１９は、例えば、動的にストリーミングされたコンテンツが完了したときに可用性に依存し得るか、又は、過度に多くのラベル／レイヤによってＧＵＩが雑然としないようにするための仕様に依存する。
【００３９】
その上、提案される方法は、レンダリングのために古いセットアップ構成（目に見える主要ストリート及び都市名（６１０）のみ）を維持し、それによって画像６０３を得てもよい。「新しい」セットアップ構成（例えばより小さいストリートの視認性）への変更は、ユーザが不注意になるまで延期される（６２０）。ユーザが不注意であったことが検出された後、「新しい」／第２のセットアップ構成がレンダリングに使用され、それによって今、目に見えるより小さいストリート（６１６）、関心点に対するラベル（６１５）、地下交通（６１８）と共に画像６０５が得られ、都市名はもはや表示されない（６１７）。セットアップ構成（レイヤの視認性）が変更された間は、ユーザは不注意であったので、ユーザはその変更を見逃している可能性がある。
【００４０】
図７は、ユーザが都市の地図上でパニングしている、又はＧＰＳ位置が更新され、それに応じてアプリケーションが地図を中心に置く、別の例示的なユースケースを示す。地図の初期表示画像（７０１）には、ストリート（７０７）及び関心点のラベル（７０６）が表示されている。マップをスクロールダウンすることによって、次に表示された画像（７０２）において、マップの新たな部分が視認可能となる。これらの新しい部分（７０８）は、最初はいかなるラベルも有しない（例えば、「Ｒｅｓｉｄｅｎｚ」は欠落している）。欠落しているラベルは、例えば、コンテンツの動的ストリーミングによって、又はクランプされたラベルを避けるための仕様によって、引き起こされる可能性がある。ユーザが（完全ダウンロードに起因するか仕様に起因するかのいずれかの）特定の時点（７１４）においてスクロールダウンすると、ラベル「Ｒｅｓｉｄｅｎｚ」（７０９）が現れる画像７０４に示すように、新しい地図領域の新しいラベルが突然現れることがある。しかしながら、レンダリングのための古いセットアップ構成では、ラベル「Ｒｅｓｉｄｅｎｚ」が依然として見えない（７１０）ままの画像７０３をもたらす。「新しい」セットアップ構成への変更（例えばＲｅｓｉｄｅｎｚが見える、新しいラベルを伴う）は、ユーザが不注意になるまで延期されてもよい。ユーザが不注意であることが検出されると（７１５）、「新しい」セットアップ構成がレンダリングに使用されて、今見える新しいラベル（７１１、７１２、７１３）を有する画像７０５を得ることができる。セットアップ構成（ラベルの視認性）が変更された間は、ユーザは不注意であったので、ユーザはその変更を見逃している可能性がある。
【００４１】
次に図８を参照すると、一実施形態による、例示的な多機能デバイス８００の簡単な機能ブロック図が示される。多機能電子デバイス８００は、プロセッサ８０５、ディスプレイ８１０、ユーザインタフェース８１５、グラフィックハードウェア８２０、デバイスセンサ８２５（例えば、近接センサ／環境光センサ、加速度計、及び／又はジャイロスコープ）、マイクロフォン８３０、オーディオコーデック（単数又は複数）８３５、スピーカ（単数又は複数）８４０、通信回路８４５、デジタル画像キャプチャ回路８５０（例えば、カメラシステム１００を含む）、ビデオコーデック（単数又は複数）８５５（例えば、デジタル画像キャプチャユニット８５０をサポートしている）、メモリ８６０、記憶装置８６５、及び通信バス８７０を含んでもよい。多機能電子デバイス８００は、例えば、デジタルカメラ、又はパーソナルデジタルアシスタント（ＰＤＡ）、パーソナル音楽プレーヤ、携帯電話、若しくはタブレットコンピュータなどのパーソナル電子デバイスでもよい。
【００４２】
プロセッサ８０５は、デバイス８００によって遂行される多数の機能の動作（例えば、本明細書に開示されているような画像の生成及び／又は処理、並びに単一及び複数カメラの較正など）を実行又は制御するのに必要な命令を実行することができる。プロセッサ８０５は、例えば、ディスプレイ８１０を駆動し、ユーザインタフェース８１５からユーザ入力を受信することができる。ユーザインタフェース８１５は、ユーザがデバイス８００と対話することを可能にし得る。例えば、ユーザインタフェース８１５は、ボタン、キーパッド、ダイヤル、クリックホイール、キーボード、ディスプレイスクリーン、及び／又はタッチスクリーンなどの種々の形態をとることができる。プロセッサ８０５はまた、例えば、モバイル機器に見られるようなシステムオンチップでもよく、専用のグラフィック処理ユニット（ＧＰＵ）を含むことができる。プロセッサ８０５は、縮小命令セットコンピュータ（ＲＩＳＣ）若しくは複合命令セットコンピュータ（ＣＩＳＣ）アーキテクチャ、又は任意の他の好適なアーキテクチャに基づくことができ、１つ以上の処理コアを含み得る。グラフィックハードウェア８２０は、グラフィックを処理するための専用の計算ハードウェアであり得て、及び／又はグラフィック情報を処理するようにプロセッサ８０５を支援し得る。一実施形態では、グラフィックハードウェア８２０は、プログラム可能なＧＰＵを含み得る。
【００４３】
画像キャプチャ回路８５０は、１つ（又はそれより多くの）のレンズアセンブリ８８０を含んでもよく、各レンズアセンブリは別個の焦点距離を有してもよい。各レンズアセンブリは、別個の関連するセンサ素子８９０を有してもよい。あるいは、２つ以上のレンズアセンブリは、共通のセンサ素子を共有してもよい。画像キャプチャ回路８５０は、静止画像及び／又はビデオ画像をキャプチャすることができる。画像キャプチャ回路８５０からの出力は、少なくとも部分的に、ビデオコーデック（単数又は複数）８５５及び／若しくはプロセッサ８０５及び／若しくはグラフィックハードウェア８２０、並びに／又は回路８５０内に組み込まれた専用の画像処理ユニット若しくはパイプラインによって処理され得る。そのようにキャプチャされた画像は、メモリ８６０及び／又は記憶装置８６５に記憶され得る。
【００４４】
センサ及びカメラ回路８５０は、静止画像及びビデオ画像をキャプチャすることができ、それらはこの開示に従って、少なくとも一部分は、ビデオコーデック（単数又は複数）８５５及び／若しくはプロセッサ８０５及び／若しくはグラフィックハードウェア８２０、並びに／又は回路８５０内に組み込まれた専用の画像処理ユニットによって処理され得る。そのようにキャプチャされた画像は、メモリ８６０及び／又は記憶装置８６５に記憶され得る。メモリ８６０は、デバイスの機能を遂行するためにプロセッサ８０５及びグラフィックハードウェア８２０により使用される１つ以上の異なるタイプの媒体を含み得る。例えば、メモリ８６０は、メモリキャッシュ、リードオンリメモリ（ＲＯＭ）、及び／又はランダムアクセスメモリ（ＲＡＭ）を含み得る。記憶装置８６５は、媒体（例えば、オーディオファイル、画像ファイル、及びビデオファイル）、コンピュータプログラム命令又はソフトウェア、プリファレンス情報、デバイスプロファイル情報、並びに任意の他の好適なデータを記憶することができる。記憶装置８６５には、例えば、（固定、フロッピー、及び取り外し可能な）磁気ディスク及びテープ、ＣＤ−ＲＯＭ及びデジタルビデオディスク（ＤＶＤ）などの光学的媒体、並びに電気的にプログラム可能なリードオンリメモリ（ＥＰＲＯＭ）及び電気的に消去可能なプログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）などの半導体メモリデバイスを含む、１つ以上の永続的記憶媒体を含むことができる。メモリ８６０及び記憶装置８６５は、１つ以上のモジュールへと編成され、かつ、任意の所望のコンピュータプログラミング言語で書かれたコンピュータプログラム命令又はコードを有形に保持するために使用することができる。例えば、プロセッサ８０５によって実行されるとき、そのようなコンピュータプログラムコードは、本明細書中に記載される方法のうちの１つ以上を実行することができる。
【００４５】
したがって、開示された主題の範囲は、添付の特許請求の範囲を参照にし、そのような特許請求の範囲に対して与えられる均等物の全範囲も併せて判断されなければならない。付属の特許請求の範囲において、「ｉｎｃｌｕｄｉｎｇ」及び「ｉｎ  ｗｈｉｃｈ」という語は、それぞれ、「ｃｏｍｐｒｉｓｉｎｇ」及び「ｗｈｅｒｅｉｎ」という用語に相当する平易な英語として使用されている。
【図１】
2019530928.tif 000003
【図２】
2019530928.tif 000004
【図３】
2019530928.tif 000005
【図４】
2019530928.tif 000006
【図５】
2019530928.tif 000007
【図６】
2019530928.tif 000008
【図７】
2019530928.tif 000009
【図８】
2019530928.tif 000010
【国際調査報告】
2019530928.tif 000011
2019530928.tif 000012