本開示の態様は、本開示の特定の実施形態を対象とする以下の説明および関係する図面において開示される。本開示の範囲から逸脱することなく代替的な実施形態が考案されてもよい。さらに、本開示のよく知られている要素は、本開示の関連する詳細を不明瞭にしないように、詳細には説明されず、または省略される。
「例示的」および/または「例」という語は、本明細書では、「例、事例、または例示として働くこと」を意味するために使用される。本明細書で「例示的」および/または「例」として説明するいかなる実施形態もまた、必ずしも他の実施形態よりも好ましいか、または有利であると解釈されるべきではない。同様に、「本開示の実施形態」という用語は、本開示のすべての実施形態が、論じられる特徴、利点または動作モードを含むことを必要とするとは限らない。
さらに、多くの実施形態について、たとえばコンピューティングデバイスの要素によって実行されることになる一連のアクションに関して説明する。本明細書で説明される様々なアクションは、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行されてもよいことが認識されよう。さらに、本明細書で説明されるこれらの一連のアクションは、実行されると、関連するプロセッサに本明細書で説明される機能を実行させるコンピュータ命令の対応するセットを記憶した、任意の形態のコンピュータ可読記憶媒体内で完全に具現化されるものと見なすことができる。したがって、本開示の様々な態様は、請求される主題の範囲内にそのすべてが入ることが企図されている、いくつかの異なる形態で具現化されてもよい。加えて、本明細書で説明される実施形態ごとに、任意のそのような実施形態の対応する形式について、本明細書では、たとえば説明された動作を実行する「ように構成される論理」として説明することがある。
本明細書ではユーザ機器(UE)と呼ばれるクライアントデバイスは、移動式であってもまたは固定式であってもよく、有線アクセスネットワークおよび/または無線アクセスネットワーク(RAN)と通信してもよい。本明細書において使用されるとき、「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」またはUT、「モバイルデバイス」、「モバイル端末」、「移動局」、およびそれらの変形として交換可能に呼ばれることがある。ある実施形態では、UEは、RANを介してコアネットワークと通信することができ、コアネットワークを通じて、UEは、インターネットなどの外部ネットワークに接続されてもよい。当然、UEには、ワイヤードアクセスネットワーク、(たとえば、IEEE 802.11などに基づく)WiFiネットワークなどを介してなどのコアネットワークおよび/またはインターネットに接続する他の機構も考えられる。UEは、限定はしないが、携帯電話、パーソナルデジタルアシスタント(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータ、PCカード、コンパクトフラッシュ(登録商標)デバイス、外付けまたは内蔵のモデム、あるいはワイヤレスまたは有線の電話などを含むいくつかのタイプのデバイスのうちの任意のものによって具現することができる。UEが信号をRANに送信することができる通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど)と呼ばれる。RANが信号をUEに送信することができる通信リンクは、ダウンリンクチャネルまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。UEが他のUEに信号を送ることができる通信リンクは、ピアツーピア(P2P)チャネルまたはデバイス間(D2D)チャネルと呼ばれる。
図1は、本開示の一実施形態によるワイヤレス通信システム100のハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100はUE1...Nを含む。たとえば、図1において、UE1...2は発呼側携帯電話として示され、UE1...6はタッチスクリーン携帯電話またはスマートフォンとして示され、UE NはデスクトップコンピュータまたはPCとして示される。
図1を参照すると、UE1...Nは、図1にエアインターフェース104、106、108および/または直接の有線接続として示される物理通信インターフェースまたは物理通信レイヤを通じてアクセスネットワーク(たとえば、RAN120、アクセスポイント125など)と通信するように構成される。エアインターフェース104および106は所与のセルラー通信プロトコル(たとえば、CDMA、EVDO、eHRPD、GSM(登録商標)、EDGE、W-CDMA、4G LTE、5G LTEなど)に準拠することができ、一方エアインターフェース108はワイヤレスIPプロトコル(たとえば、IEEE 802.11)に準拠することができる。RAN120は、エアインターフェース104および106などのエアインターフェースを通じてUEにサービスする複数のアクセスポイントを含んでもよい。RAN120の中のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、Node B、eNode Bなどと呼ぶことができる。これらのアクセスポイントは、地上アクセスポイント(または地上局)、または衛星アクセスポイントであってもよい。RAN120は、RAN120によってサービスされるUEとRAN120または異なるRANによってサービスされる他のUEとの間の回線交換(CS)呼を完全にブリッジングすることを含む様々な機能を実行することができ、インターネット175などの外部ネットワークとのパケット交換(PS)データの交換を仲介することもできる、コアネットワーク140に接続するように構成されてもよい。
いくつかの例では、インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上、図1には示されていない)を含む。図1で、UE Nは、インターネット175に直接(すなわち、WiFiまたは802.11ベースネットワークのイーサネット(登録商標)接続を介してなどのコアネットワーク140とは別個に)接続するように示される。それによって、インターネット175は、コアネットワーク140を介してUE 1...Nの間のパケット交換データ通信をブリッジングするように機能することができる。図1には、RAN120とは別個であるアクセスポイント125も示される。アクセスポイント125は、コアネットワーク140とは無関係に(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)インターネット175に接続されてもよい。エアインターフェース108は、ある例では、IEEE 802.11などのローカルワイヤレス接続を介してUE5またはUE6にサービスしてもよい。UE Nは、ある例では(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータのための)アクセスポイント125自体に対応することができる、モデムまたはルータへの直接接続などのインターネット175との有線接続を伴うデスクトップコンピュータとして示される。
図1を参照すると、サーバ170は、インターネット175、コアネットワーク140、またはその両方に接続されるように示される。サーバ170は、構造的に別々の複数のサーバとして実装されることが可能であり、または代替的には単一のサーバに対応することがある。サーバ170は、(たとえば、ウェブページをホストする)ウェブサーバ、アプリケーションダウンロードサーバ、またはボイスオーバーインターネットプロトコル(VoIP)セッション、プッシュツートーク(PTT)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなどの特定の通信サービスをサポートするアプリケーションサーバなどの任意の種類のサーバに対応してもよい。
図1を参照すると、UE1...3は、D2DネットワークまたはD2Dグループ185の一部として示され、UE1およびUE3は、エアインターフェース104を介してRAN120に接続される。一実施形態では、UE2は、UE1および/またはUE3による仲介を介してRAN120に間接的にアクセスしてもよく、それによってデータがUE2ならびにUE1およびUE3の一方(または複数)に/から「ホップ」し、UE1およびUE3はUE2に代わってRAN120と通信する。
図2は、本開示の一実施形態によるUE200を示す。UE200は、1つまたは複数のプロセッサ205(たとえば1つまたは複数のASIC、1つまたは複数のデジタル信号プロセッサ(DSP)など)とメモリ210(たとえば、RAM、ROM、EEPROM、フラッシュカード、または各コンピュータプラットフォームに共通の任意のメモリ)とを含む。メモリ210は、関連するオペレーティングシステムを介して1つまたは複数のプロセッサ205によって実行可能な複数のアプリケーション1...Nを含む。UE200はまた、1つまたは複数のUI入力コンポーネント215(たとえば、キーボードおよびマウス、タッチスクリーン、マイクロフォン、ボリュームまたは電源ボタンなどの1つまたは複数のボタン)と1つまたは複数のUI出力コンポーネント220(たとえば、スピーカー、ディスプレイスクリーン、UE200を振動させるための振動デバイスなど)とを含む。
UE200は、有線通信インターフェース225とワイヤレス通信インターフェース230とをさらに含む。例示的な実施形態では、有線通信インターフェース225は、周辺デバイスとの有線ローカル接続(たとえば、USB接続、ミニUSB、Firewire、もしくはLightning接続、ヘッドフォンジャック、シリアル、VGA、HDMI(登録商標)、DVI、もしくはDisplayPortなどのグラフィックスポート、オーディオポートなど)および/または(たとえば、イーサネットケーブル、もしくはHDMI v1.4以上などの有線アクセスネットワークとのブリッジとして機能することができる別の種類のケーブルを介した)有線アクセスネットワークとの有線ローカル接続をサポートするために使用することができる。別の例示的な実施形態では、ワイヤレス通信インターフェース230は、ローカルワイヤレス通信プロトコル(たとえば、WLANまたはWiFi、WiFi Direct、Bluetooth(登録商標)、LTE-D、Miracastなど)に従った通信用の1つまたは複数のワイヤレストランシーバを含む。ワイヤレス通信インターフェース225はまた、(たとえば、CDMA、W-CDMA、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多重(OFDM)、GSM(登録商標)、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用される場合がある他のプロトコルを介した)セルラーRANとの通信用の1つまたは複数のワイヤレストランシーバを含んでもよい。UE200の様々なコンポーネント205〜230は、バス235を介して互いに通信することができる。
図2を参照すると、UE200は、限定はしないが、スマートフォン、ラップトップコンピュータ、デスクトップコンピュータ、タブレットコンピュータ、ウエアラブルデバイス(たとえば、歩数計、スマートウォッチなど)などを含む任意の種類のUEに対応してもよい。UE200の2つの特定の実装形態例が図2に示され、ラップトップ240およびタッチスクリーンデバイス255(たとえば、スマートフォン、タブレットコンピュータなど)として示される。ラップトップ240は、ディスプレイスクリーン245とUI領域250(たとえば、キーボード、タッチパッド、電源ボタンなど)とを含み、図示されないが、ラップトップ240は、様々なポートならびに有線および/またはワイヤレストランシーバ(たとえば、イーサネットカード、WiFiカード、ブロードバンドカード、全地球測位システム(GPS)アンテナなどの衛星測位システム(SPS)アンテナ)を含んでもよい。
タッチスクリーンデバイス255は、当技術分野で知られているように、とりわけタッチスクリーンディスプレイ260、周辺ボタン265、270、275、および280(たとえば、電源ボタン、音量調整ボタンまたは振動調節ボタン、機内モード切替ボタンなど)、ならびに少なくとも1つのフロントパネルボタン285(たとえば、ホームボタンなど)などのコンポーネントで構成される。タッチスクリーンデバイス255の一部として明示的に示されないが、タッチスクリーンデバイス255は、限定はしないが、WiFiアンテナ、セルラーアンテナ、SPSアンテナ(たとえば、GPSアンテナ)などを含む、1つもしくは複数の外部アンテナおよび/またはタッチスクリーンデバイス255の外部ケーシングに内蔵される1つもしくは複数の内蔵アンテナを含むことができる。
図3は、本開示のある実施形態による、構造的なコンポーネントを含む通信デバイス300を示す。通信デバイス300は、限定はしないが、UE200などを含む上述の通信デバイスのいずれかに対応することができる。
図3を参照すると、通信デバイス300は、情報を受信および/または送信するように構成されるトランシーバ回路305を含む。ある例では、通信デバイス300がワイヤレス通信デバイス(たとえば、UE200)に対応する場合、情報を受信および/または送信するように構成されるトランシーバ回路305は、ワイヤレストランシーバおよび関連するハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)などのワイヤレス通信インターフェース(たとえば、Bluetooth(登録商標)、Wi-Fi、Wi-Fi Direct、LTE Directなど)を含むことができる。別の例では、情報を受信および/または送信するように構成されるトランシーバ回路305は、有線通信インターフェース(たとえば、シリアル接続、USB、Firewire、もしくはLightning接続、インターネット175にアクセスするのを可能にするイーサネット接続など)に対応することができる。さらなる例では、情報を受信および/または送信するように構成されるトランシーバ回路305は、通信デバイス300がそのローカル環境をそれによって監視することができる感知または測定ハードウェア(たとえば、加速度計、温度センサ、光センサ、ローカルRF信号を監視するためのアンテナなど)を含むことができる。情報を受信および/または送信するように構成されるトランシーバ回路305はまた、実行されると、情報を受信および/または送信するように構成されるトランシーバ回路305の関連するハードウェアにその受信および/または送信機能を実行することを許可するソフトウェアを含むことができる。しかしながら、情報を受信および/または送信するように構成されるトランシーバ回路305は、ソフトウェアだけに対応するのではなく、情報を受信および/または送信するように構成されるトランシーバ回路305は、その機能を達成するための構造的なハードウェアに少なくとも一部依拠する。その上、情報を受信および/または送信するように構成されるトランシーバ回路305は、背後にある機能が受信または送信機能に対応する限り、「受信」および「送信」以外の語により示唆されることがある。たとえば、取得すること(obatining)、得ること(acquiring)、取り出すこと、測定することなどの機能が、いくつかの文脈では特定のタイプの受信機能として、情報を受信および/または送信するように構成されるトランシーバ回路305によって実行されてもよい。別の例では、送信すること、配信すること、搬送すること、転送することなどの機能が、いくつかの文脈では特定のタイプの送信機能として、情報を受信および/または送信するように構成されるトランシーバ回路305によって実行されてもよい。他のタイプの受信および/または送信機能に対応する他の機能もまた、情報を受信および/または送信するように構成されるトランシーバ回路305によって実行されてもよい。
図3を参照すると、通信デバイス300はさらに、情報を処理するように構成される少なくとも1つのプロセッサ310を含む。情報を処理するように構成される少なくとも1つのプロセッサ310によって実行されてもよいタイプの処理の例示的な実装形態は、限定はされないが、決定を行うこと、接続を確立すること、異なる情報選択肢の中から選択を行うこと、データに関する評価を実行すること、測定動作を実行するために通信デバイス300に結合されるセンサと対話すること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviになどの異なるプロトコル間で)変換することなどを含む。たとえば、情報を処理するように構成される少なくとも1つのプロセッサ310は、汎用プロセッサ、DSP、ASIC、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェアコンポーネント、または本明細書で説明される機能を実行するように設計されたそれらの任意の組合せを含むことができる。汎用プロセッサはマイクロプロセッサであってもよいが、代わりに、情報を処理するように構成される少なくとも1つのプロセッサ310は、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ(たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成)として実装されてもよい。情報を処理するように構成される少なくとも1つのプロセッサ310はまた、実行されると、情報を処理するように構成される少なくとも1つのプロセッサ310の関連するハードウェアにその処理機能を実行することを許可するソフトウェアを含むことができる。しかしながら、情報を処理するように構成される少なくとも1つのプロセッサ310は、ソフトウェアだけに対応するのではなく、情報を処理するように構成される少なくとも1つのプロセッサ310は、その機能を達成するために構造的なハードウェアに少なくとも一部依拠する。その上、情報を処理するように構成される少なくとも1つのプロセッサ310は、背後にある機能が処理機能に対応する限り、「処理」以外の語により示唆されることがある。たとえば、評価すること、決定すること、計算すること、特定することなどの機能が、いくつかの文脈では特定のタイプの処理機能として、情報を処理するように構成される少なくとも1つのプロセッサ310によって実行されてもよい。他のタイプの処理機能に対応する他の機能もまた、情報を処理するように構成される少なくとも1つのプロセッサ310によって実行されてもよい。
図3を参照すると、通信デバイス300はさらに、情報を記憶するように構成されるメモリ315を含む。ある例では、情報を記憶するように構成されるメモリ315は、少なくとも1つの非一時的メモリおよび関連するハードウェア(たとえば、メモリコントローラなど)を含むことができる。たとえば、情報を記憶するように構成されるメモリ315に含まれる非一時的メモリは、RAM、フラッシュメモリ、ROM、消去可能プログラマブルROM(EPROM)、EEPROM、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形の記憶媒体に対応してもよい。情報を記憶するように構成されるメモリ315はまた、実行されると、情報を記憶するように構成されるメモリ315の関連するハードウェアにその記憶機能を実行することを許可するソフトウェアも含んでもよい。しかしながら、情報を記憶するように構成されるメモリ315は、ソフトウェアだけに対応するのではなく、情報を記憶するように構成されるメモリ315は、その機能を達成するために構造的なハードウェアに少なくとも一部依拠する。その上、情報を記憶するように構成されるメモリ315は、背後にある機能が記憶機能に対応する限り、「記憶」以外の語により示唆されることがある。たとえば、キャッシュすること、維持することなどの機能が、いくつかの文脈では特定のタイプの記憶機能として、情報を記憶するように構成されるメモリ315によって実行されてもよい。他のタイプの記憶機能に対応する他の機能もまた、情報を記憶するように構成されるメモリ315によって実行されてもよい。
図3を参照すると、通信デバイス300は、情報を提示するように構成されるユーザインターフェース出力回路320をさらに含む。ある例では、情報を提示するように構成されるユーザインターフェース出力回路320は、少なくとも出力デバイスおよび関連するハードウェアを含むことができる。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMIなどのビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカー、マイクロフォンジャック、USB、HDMIなどのオーディオ情報を搬送することができるポートなど)、振動デバイス、および/または、それによって情報を出力のためにフォーマットすることができ、もしくは情報を通信デバイス300のユーザまたは操作者によって実際に出力することができる任意の他のデバイスを含むことができる。たとえば、通信デバイス300が、図2に示されるようなUE200に対応する場合、情報を提示するように構成されるユーザインターフェース出力回路320は、ディスプレイ245またはタッチスクリーンディスプレイ260などのディスプレイを含むことができる。情報を提示するように構成されるユーザインターフェース出力回路320はまた、実行されると、情報を提示するように構成されるユーザインターフェース出力回路320の関連するハードウェアにその提示機能を実行することを許可するソフトウェアを含むことができる。しかしながら、情報を提示するように構成されるユーザインターフェース出力回路320は、ソフトウェアだけに対応するのではなく、情報を提示するように構成されるユーザインターフェース出力回路320は、その機能を達成するために構造的なハードウェアに少なくとも一部依拠する。その上、情報を提示するように構成されるユーザインターフェース出力回路320は、背後にある機能が提示機能に対応する限り、「提示」以外の語により示唆されることがある。たとえば、表示すること、出力すること、促すこと、伝えることなどの機能が、いくつかの文脈では特定のタイプの提示機能として、情報を提示するように構成されるユーザインターフェース出力回路320によって実行されてもよい。他のタイプの提示機能に対応する他の機能もまた、情報を提示するように構成されるユーザインターフェース出力回路320によって実行されてもよい。
図3を参照すると、通信デバイス300は、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325をさらに含む。ある例では、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325は、少なくともユーザ入力デバイスおよび関連するハードウェアを含むことができる。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、またはマイクロフォンジャックなどのオーディオ情報を搬送することができるポートなど)、および/またはそれによって通信デバイス300のユーザもしくは操作者から情報を受信することができる任意の他のデバイスを含むことができる。たとえば、通信デバイス300が図2に示されるようなUE200に対応する場合、ローカル入力を受信するように構成されるユーザインターフェース入力回路325は、UI領域250またはタッチスクリーンディスプレイ260などに対応してもよい。また、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325はまた、実行されると、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325の関連するハードウェアにその入力受信機能を実行することを許可するソフトウェアも含むことができる。しかしながら、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325は、ソフトウェアだけに対応するのではなく、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325は、その機能を達成するために構造的なハードウェアに少なくとも一部依拠する。その上、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325は、背後にある機能がローカルユーザ入力受信機能に対応する限り、「ローカルユーザ入力を受信する」以外の語により示唆されることがある。たとえば、取得すること、受信すること、収集することなどの機能が、いくつかの文脈では特定のタイプのローカルユーザ入力受信機能として、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325によって実行されてもよい。他のタイプのローカルユーザ入力受信機能に対応する他の機能もまた、ローカルユーザ入力を受信するように構成されるユーザインターフェース入力回路325によって実行されてもよい。
図3を参照すると、305から325の構成される構造的なコンポーネントは、図3では関連する通信バス(明示的に示されていない)を介して互いに暗黙的に結合される別個のまたは相異なるブロックとして示されるが、305から325のそれぞれの構成される構造的なコンポーネントがその機能をそれによって実行するハードウェアおよび/またはソフトウェアは、部分的に重複できることが了解されるであろう。たとえば、305から325の構成される構造的なコンポーネントの機能を容易にするために使用される任意のソフトウェアを、情報を記憶するように構成されるメモリ315と関連付けられた非一時的メモリに記憶することができるので、305から325の構成される構造的なコンポーネントは各々、それぞれの機能(すなわち、この場合ソフトウェア実行)を、情報を記憶するように構成されるメモリ315によって記憶されたソフトウェアの動作に一部基づいて実行する。同様に、305から325の構成される構造的なコンポーネントのうちの1つと直接関連付けられたハードウェアは、305から325の構成される構造的なコンポーネントの他のものによって時々借用または使用されてもよい。たとえば、情報を処理するように構成される少なくとも1つのプロセッサ310は、情報を受信および/または送信するように構成されるトランシーバ回路305によって送信される前に、データを適切な形式にフォーマットすることができるので、情報を受信および/または送信するように構成されるトランシーバ回路305は、その機能(すなわち、この場合データの送信)を、情報を処理するように構成される少なくとも1つのプロセッサ310と関連付けられる構造的なハードウェアの動作に一部に基づいて実行する。
表示機能を有する多くのUEは、スクリーンショットキャプチャ機能をサポートする。たとえば、Windowsオペレーティングシステム(OS)を動作させるコンピュータ(たとえば、ラップトップコンピュータ、デスクトップコンピュータ)は、ユーザがALTキーとPrintScreenキーを同時に押したことに応答してクリップボードメモリにスクリーンショット画像(たとえば、構成設定に応じてディスプレイスクリーン領域全体のスクリーンショット画像または特定のウィンドウ領域のスクリーンショット画像)をコピーする。別の例では、iOS(たとえば、iPhone(登録商標)、iPad(登録商標)、iPod Touch(登録商標)など)などのモバイルオペレーティングシステムを動作させるUEは、ユーザがホームボタンと電源ボタンを同時に押したことに応答してフォトギャラリーにスクリーンショット画像をコピーする。
ユーザは、限定はしないが、ショッピングウェブサイトからの所望の項目の保存、購入確認の保存、テキストチャット対話の特定の部分の保存、ビデオプログラム(たとえば、TV、YouTubeなど)の特定のフレームの保存、地図またはナビゲーション経路の特定の部分の保存、電子書籍または情報ウェブサイト(たとえば、ウィキペディアなど)からの特定のテキストの保存などを含む様々な理由でスクリーンショットをキャプチャすることを望む場合がある。
図4は、UE動作環境400におけるスクリーンショットキャプチャに関連するコンポーネント相互作用の一例を示す。UE動作環境400は、OS405と、ディスプレイエンジン410(たとえば、1つまたは複数のグラフィックスデバイスドライバ、グラフィックスカード、専用グラフィックスカーネルなど)と、UE実行可能アプリケーション1...N(たとえば、UEにおいて関連するメモリに記憶されたアプリケーション、ここでNは2以上である)と、スクリーンショット生成モジュール420とを含む。UE動作環境400は、(たとえば、図2の215、図3の325などに対応する)UI入力コンポーネント425と、(図2の220、図3の320などに対応する)ディスプレイスクリーン430と、(図2の210、図3の315などに対応する)メモリ435とをさらに含む。
図4を参照すると、1〜7として列挙された動作を介して機能フローが示される。動作1〜7の特定の順序は実装形態ごとに異なる場合がある(たとえば、動作3および4を任意の順序で行うことなどが可能である)。動作1において、スクリーンショット要求がUI入力コンポーネント425を介してOS405によって検出される。たとえば、動作1は、ユーザがWindows OS環境においてキーボードのキーを介してALTとPrintScreenを同時に押したことの検出、ユーザがiOS環境においてホームボタンと電源ボタンを同時に押したことの検出などに対応してもよい。動作2において、OS405は、ディスプレイエンジン410にスクリーンショット要求を送る。動作3において、アプリケーション1は、ディスプレイスクリーン430によって出力されるディスプレイフレーム内にレンダリングすべきアプリケーション固有画像データをディスプレイエンジン410に提供する。動作4において、アプリケーション2...Nはまた、場合によってはディスプレイスクリーン430によって出力されるディスプレイフレーム内にレンダリングすべきアプリケーション固有画像データを提供してもよい。UEがアプリケーション1に対してフルスクリーンモードで動作することが可能であり、その場合アプリケーション1に関する画像データのみがディスプレイフレームの一部を構成するので、動作4は任意である。動作5において、ディスプレイエンジン410は、アプリケーション1(および場合によっては、アプリケーション2...N)からのアプリケーション固有画像データに基づいて、レンダリングされたスクリーンデータをディスプレイスクリーン430に送る。
ディスプレイエンジン410はまた、動作6において、OS405からのスクリーンショット要求に応答して、レンダリングされたスクリーンデータをスクリーンショット生成モジュール420に送る。スクリーンショット生成モジュール420は、レンダリングされたスクリーンデータに基づき、あるファイル固有(またはアプリケーション汎用)メタデータ(たとえば、スクリーンキャプチャ時間、ファイル名、ファイルサイズなど)にも基づいてスクリーンショットを生成する。動作7において、スクリーンショット生成モジュール420は、生成された(またはキャプチャされた)スクリーンショットをメモリ435に送り、スクリーンショットはそこで、記憶されたスクリーンショット1...Nのセットの間に記憶される。
スクリーンショットは、特定の時点においてディスプレイスクリーン上に示された生画像データを記憶するうえで非常に有効であるが、スクリーンショットにおいて示されたアプリケーションセッションの状態(またはセッション状態)にユーザ(たとえば、最初のスクリーンショットを取ったユーザまたはスクリーンショットが共有される異なるユーザ)を戻すうえでは特に有効ではない場合がある。たとえば、スクリーンショットに関連して記憶される従来のメタデータは一般に、ファイル固有メタデータのみ(たとえば、スクリーンキャプチャ時間、ファイル名、ファイルサイズなど)を含み、このメタデータは、スクリーンショット上の地図上に示された住所へのナビゲーション経路をプロットしたいユーザ、またはある購入品目に関する購入確認のスクリーンショットに基づいてその購入品目に関する出荷状況をチェックしたいユーザなどには特に有用ではない。
したがって、本開示の実施形態は、キャプチャされたスクリーンショットに画像データを提供しているアプリケーションのセッション状態を定義するアプリケーション固有メタデータにキャプチャされたスクリーンショットを関連付けることを対象とする。後述のように、アプリケーション固有メタデータは、単にキャプチャされたスクリーンショットの生画像コンテンツを表示するのではなく、UEがアプリケーション固有メタデータによって定義されるセッション状態の1つまたは複数の特徴を再作成するのを可能にしてもよい。
図5は、本開示の一実施形態によるスクリーンショットキャプチャ手順を示す。図5のスクリーンショットキャプチャ手順は、UEにおいて実行され、ディスプレイスクリーンの一部または全部上に出力されている画像データをキャプチャする。ディスプレイスクリーンは、UE自体のディスプレイスクリーンに対応してもよく、その場合スクリーンショットキャプチャは、図4に関して上記で説明した例(たとえば、スクリーンショットのセルフキャプチャ)と同様である。しかし、代替として、ディスプレイスクリーンは別のデバイスのディスプレイスクリーンに対応してもよく、その場合キャプチャされるスクリーンショットは、他のデバイスのディスプレイスクリーンのスナップショットである(たとえば、UEのユーザがUEをカメラモードにして別のディスプレイスクリーンのスナップショットを撮る)。図5に関して説明したディスプレイスクリーンは、図2におけるUE200のUI出力コンポーネント220のうちの1つまたは図3の情報を提示するように構成されるユーザインターフェース出力回路320に対応してもよい。
図5を参照すると、ブロック500において、UEは、ディスプレイスクリーン上に出力されている画像データのスクリーンショットをキャプチャする要求を検出する。たとえば、ブロック500は、ユーザがWindows OS環境においてキーボードのキーを介してALTとPrintScreenを同時に押したことの検出、ユーザがiOS環境においてホームボタンと電源ボタンを同時に押したことの検出などに対応してもよい。別の例では、上述のように、ブロック500は、ユーザがUEをカメラモード(またはビューファインダーモード)にして外部ディスプレイスクリーンのスナップショットを撮ったことの検出に対応してもよい。ブロック505において、UEは、要求が検出されたときにディスプレイスクリーン上に出力されている画像データの少なくとも一部を提供しているアプリケーションのセッション状態を定義する(あるいはセッション状態の1つまたは複数の特徴の再作成を容易にするように構成される)アプリケーション固有メタデータを取得する。
本明細書で使用するアプリケーション固有メタデータは、特定のアプリケーションとのセッションを初期設定する情報(たとえば、あるURLにアクセス可能なウェブサイトとのウェブセッションを開始するためにウェブブラウザによって使用されるURL、アプリケーションを識別してアプリケーションセッションを開始するために使用できるアプリケーションIDなど)に部分的に基づいてセッション状態を定義してもよい。しかし、アプリケーション固有メタデータは、初期設定セッション状態だけでなく、スクリーンキャプチャを受けている画像データに反映される瞬間的な(または現在の)セッション状態をさらに特徴付ける。たとえば、セッション状態は、ズームのレベル、関連するウェブページ上でユーザがスクロールした特定の関心対象、URLからストリーミングされたビデオフレームが画像データにおいて示された時点などのURL自体からは導き出せないようにURLセッションを特徴付ける二次情報に結合されるURLを含んでもよい。一例では、アプリケーション固有メタデータに付加される場合があるURLは、トップレベルウェブページURLを含むだけでなく、画像URLおよび画像代替(alt)テキスト(たとえば、画像を容易に取得できない場合に画像の代わりに表示されるテキスト)を含んでもよい。一例では、画像URLおよび/または画像代替テキストは、トップレベルウェブページがもはや利用可能ではなく、ならびに/またはロードするのに時間がかかる場合にフォールバック機構として使用されてもよい。
以下でより詳細に説明するように、1つまたは複数の追加のアプリケーションもまたディスプレイスクリーン上に出力されている画像データを提供している場合、UEは、1つまたは複数の追加のアプリケーションの1つまたは複数のセッション状態を定義する(あるいはセッション状態の1つまたは複数の特徴の再作成を容易にするように構成される)アプリケーション固有メタデータを取得してもよい。
図5のブロック505を参照すると、アプリケーション固有メタデータは、以下の方法の任意の組合せを含む様々な方法で取得されてもよい。
・アプリケーション固有メタデータの一部がアプリケーションから直接取り出されてもよく(たとえば、アプリケーション自体が、スクリーンショットに示されるアプリケーションセッション状態の特徴の一部または全部を再作成するために使用される場合があるアプリケーション固有メタデータを提供する)、
・アプリケーション固有メタデータの一部が、UEのオペレーティングシステムによって提供されてもよく、
・アプリケーション固有メタデータの一部が、コンピュータビジョン機能を介してディスプレイスクリーン上に出力されている画像データから導出または抽出されてもよく(たとえば、ディスプレイスクリーン上に出力されている画像データに含まれるテキストに光学文字認識(OCR)が適用され、アプリケーション固有メタデータに付加される)、
・アプリケーション固有メタデータの一部が、UEの外部の別のデバイスから受信されてもよい。上述のスナップショットの例では、第1のUEが第2のUEに接続されてもよい。第1のUEは、第2のUEのディスプレイスクリーンのスナップショットを撮る。第1のUEは、スナップショットがキャプチャされたときに第2のUEにおいてディスプレイスクリーン出力に画像データを提供している1つまたは複数のアプリケーションのセッション状態を特徴付けるアプリケーション固有メタデータに関するクエリを(たとえば、D2D接続を介して)送る。第2のUEは、要求されたアプリケーション固有メタデータを(たとえば、D2D接続を介して)提供する。
・アプリケーション固有メタデータの一部は、上述のソースのいずれかから受信され、次いで異なる形態に後処理されてもよい。たとえば、ウェブブラウザが、スクリーンショットに表示される現在のURLを提供してもよく、このURLが分析または後処理されて、現在のURLの特定のセッション状態を再作成するための二次情報が得られる(たとえば、Google Maps URLがスクリーンショットにキャプチャされ、後処理によって、アプリケーション固有メタデータにおける特定のURLとは異なり、スクリーンショットおよび識別されたGoogle Mapsに示される住所または地理的エリアが抽出される)。後処理は、専用アプリケーションもしくはソフトウェアモジュール、OS、またはアプリケーション自体などの任意の適切なエンティティによって実行することができる。
図5を参照すると、ブロック510において、UEは、要求に応答して、ディスプレイスクリーン上に出力されている画像データのスクリーンショットを選択的にキャプチャする。一例では、ブロック510におけるスクリーンショットキャプチャは常に実行されてもよい。しかし、他の実施形態では、ブロック510におけるスクリーンショットキャプチャは、記憶空間因子またはアプリケーション固有メタデータ信頼度因子などの様々な基準に基づいてもよい。たとえば、非常に信頼度の高いアプリケーション固有メタデータがディスプレイスクリーン上に出力されている画像データの再作成に利用可能である場合(たとえば、ディスプレイフレーム内にフルスクリーンで表示されている画像ファイルへのディープリンクURL)、ディスプレイフレームをスクレイピングしてスクリーンショットの特定のピクセルをキャプチャすることを省略することができる。別の例では、UE上の利用可能な記憶空間がごく限られる場合、ブロック510におけるスクリーンショットキャプチャが(たとえば、記憶空間を節約するために)省略されてもよい。したがって、「キャプチャされた」スクリーンショットに対する参照が行われ、ブロック510のスクリーンショットキャプチャが実際に行われることが暗黙的に示されるが、これらの参照は一例として行われる。他の実施形態では、ブロック505においてスクリーンショットを実際にキャプチャすることなく(キャプチャして記憶することなく)アプリケーション固有メタデータを取得してもよい。
引き続き図5のブロック510を参照すると、ブロック510が必ずしもブロック505の後に行われるとは限らないことが了解されよう。ブロック505〜510に示されるそれぞれの動作は、任意の順序で行うかまたは場合によっては同時に行うことができる。さらに、ブロック510におけるスクリーンショットキャプチャは、フルスクリーンキャプチャ(たとえば、ディスプレイスクリーンによって出力されているディスプレイフレーム全体のスクリーンショットがキャプチャされる)または部分スクリーンキャプチャ(たとえば、ユーザ定義される場合がある、ディスプレイフレーム内の特定のウィンドウまたはディスプレイスクリーンの特定の部分がキャプチャされる)。一例では、部分スクリーンキャプチャの場合、ブロック505において取得されるアプリケーション固有メタデータは、ブロック510においてキャプチャされる関連する画面エリア内部に画像データを提供しているアプリケーションに限定されてもよく、ブロック510においてキャプチャされる関連する画面エリアの外部の画像データのみを提供しているアプリケーションに関するアプリケーション固有メタデータを省略してもよい。さらに、ブロック510のスクリーンキャプチャが複数のディスプレイスクリーンによって出力されるディスプレイフレームに関係することが考えられ、その場合スクリーンショットは、複数のディスプレイスクリーン全体にわたる画像データを包含してもよく、1つの指定されたディスプレイスクリーンのみに関する画像データを包含してもよい。上述のように、ブロック510のキャプチャ動作は、UE自体のディスプレイスクリーンによって出力されている画像データのキャプチャに対応してもよく、または代替としてUEのカメラによって撮られた外部デバイスのディスプレイスクリーンのスナップショットに対応してもよい。
図5を参照すると、キャプチャが行われた後、UEは、取得されたアプリケーション固有メタデータをブロック515において記憶する。ブロック515は、様々な方法で実施することができる。一例では、キャプチャされたスクリーンショットは、ブロック515において、取得されたアプリケーション固有メタデータに関連して記憶されてもよい。ただし、これは厳密である必要はない(たとえば、アプリケーション固有メタデータが取得された後、たとえばメモリを節約するために、キャプチャされたスクリーンショットを破棄することができると考えられる)。キャプチャされたスクリーンショットとアプリケーション固有メタデータの両方がブロック515において記憶される場合、一例ではキャプチャされた画像データが記憶される媒体部分から離れたスクリーンショットファイルのヘッダまたはオーバーヘッド部分にアプリケーション固有メタデータを(ファイル名、スクリーンキャプチャの時間などの他のファイル固有メタデータを記憶する方法と同様に)付加することができる。キャプチャされたスクリーンショットとアプリケーション固有メタデータの両方がブロック515において記憶される別の例では、アプリケーション固有メタデータは、媒体部分自体の画像データにウォーターマークとして埋め込まれてもよい。キャプチャされたスクリーンショットとアプリケーション固有メタデータの両方がブロック515において記憶される別の例では、アプリケーション固有メタデータをスクリーンショットファイルとは別に記憶することができ、ここである種のポインタまたは他の仮想リンクが、上記でブロック515において説明した関連付けを形成する。
図5を参照すると、ブロック520において、UEは、場合によってはキャプチャされたスクリーンショットおよび/または記憶されたアプリケーション固有メタデータを更新する。キャプチャされたスクリーンショットおよび/または記憶されたアプリケーション固有メタデータをどのように更新するかの様々な例を次に示す。
図5のブロック520の第1の例では、ユーザは、キャプチャされたスクリーンショットをクロッピングすることによって、キャプチャされたスクリーンショットを編集または修正してもよい。一実施形態では、キャプチャされたスクリーンショットをクロッピングすることが、任意のアプリケーション固有メタデータがキャプチャされたスクリーンショットのクロッピングされた部分にのみ関係するかどうかを判定するようUEに促してもよい。任意のアプリケーション固有メタデータがキャプチャされたスクリーンショットのクロッピングされた部分にのみ関係する場合、クロッピングされた部分に関係するアプリケーション固有メタデータを削除することができる(たとえば、ユーザは、特定の画像がもはや示されないようにキャプチャされたスクリーンショットをクロッピングし、画像URLおよび/またはその特定の画像用の画像代替テキストをアプリケーション固有メタデータから削除することができる)。別の実施形態では、ユーザは、クロッピングされたキャプチャ済みのスクリーンショット内には単一の画像のみが表示されたままになるように、キャプチャされたスクリーンショットをクロッピングしてもよい。この場合、残りの画像に関する画像URLは、クロッピングされた部分に関係する他のアプリケーション固有メタデータに対して優先されてもよい。
図5のブロック520の第2の例では、ユーザは、キャプチャされたスクリーンショット内の1つまたは複数のアイテム(たとえば、人、製品、位置など)にタグ付けすることなどの補足情報を付加するようにキャプチャされたスクリーンショットを編集または修正してもよい。アプリケーション固有メタデータは、タグ付けされたアイテムの参照を含むようにブロック520において更新されてもよい(たとえば、キャプチャされたスクリーンショットが特定の映画の映画チケットを示し、ユーザがその特定の映画にタグ付けし、アプリケーション固有メタデータが、その映画を購入することができるウェブサイトへのURLを含むように更新される)。
図5のブロック520の第3の例では、ブロック510においてスクリーンショットをキャプチャし、キャプチャされたスクリーンショットをブロック515においてアプリケーション固有メタデータと関連付けて記憶し、その後ユーザがキャプチャされたスクリーンショットを削除すると仮定する。一例では、これによって関連するアプリケーション固有メタデータが削除されてもよい。代替例では、キャプチャされたスクリーンショットが削除される場合でもまた、アプリケーション固有メタデータが保存されてもよい。
図5のブロック520の第4の例では、画像データは、1つまたは複数の情報対象(たとえば、地図、バス運行表など)を含んでもよい。この場合、情報対象は、アプリケーション固有メタデータにおいて識別されてもよい。UEは、(WiFi接続が利用可能な間月1回など定期的に、またはUEがアプリケーションのセッション状態を再作成することを求められたとき必ずなどイベントトリガ的に)情報対象をチェックして、更新があるかどうか(たとえば、地図の更新、バス運行表の修正)を判定してもよい。一例では、OCR整合またはコンピュータビジョンベースの類似性整合アルゴリズムを使用して情報対象を識別することができる。さらなる一例では、機械学習画像分類を使用して、更新が実行される場合がある情報対象を検出する(たとえば、ミームに関する更新チェックではなく、バス運行表に関する更新チェックを実行する)ことができる。さらなる一例では、情報対象は、スクリーンショットにおいて視覚的に示されるかまたは他の方法で参照される識別された製品に関する製品価格設定を含んでもよい。この場合、更新チェックは、製品に関するリアルタイム価格設定を(たとえば、Amazon.comなどの小売業者の特定のセットから)取り込むことを含んでもよい。たとえば、ユーザは、ランニングシューズを示すスクリーンショットのスナップショットを撮ってもよく、更新チェックでは、ランニングシューズのリアルタイム価格設定を監視し、価格が変更される場合にユーザに通知してもよい。
図6は、本開示の一実施形態によるUE動作環境600におけるスクリーンショットキャプチャに関連するコンポーネント相互作用の一例を示す。図6に示す例は、ブロック505において、アプリケーション固有メタデータが、画像を提供するアプリケーションから取得され、ブロック510において、UEがUE自体のディスプレイスクリーンのスクリーンショットをキャプチャする実装形態に固有の例である。しかし、これは、非限定的な例を意図するものであり、1つまたは複数の他の代替ソースからアプリケーション固有メタデータを取得することができ、UEは代替的に、上述のように外部ディスプレイスクリーンのスクリーンショットをキャプチャすることができる。
コンポーネントに関して、UE動作環境600は、図4のUE動作環境400に類似している。したがってUE動作環境600は、OS605と、ディスプレイエンジン610(たとえば、1つまたは複数のグラフィックスデバイスドライバ、グラフィックスカード、専用グラフィックスカーネルなど)と、UE実行可能アプリケーション1...N(たとえば、UEにおいて関連するメモリに記憶されたアプリケーション、ここでNは2以上である)と、スクリーンショット生成モジュール620とを含む。UE動作環境600は、(たとえば、図2の215、図3の325などに対応する)UI入力コンポーネント625と、(図2の220、図3の320などに対応する)ディスプレイスクリーン630と、(図2の210、図3の315などに対応する)メモリ635とをさらに含む。
図6を参照すると、図5のプロセスの例示的な実装形態が、1〜10として列挙された動作を介して示される。動作1〜10の特定の順序は実装形態ごとに異なる場合がある(たとえば、動作4および5を任意の順序で行えることなど)。動作1において、スクリーンショット要求がUI入力コンポーネント425を介してOS605によって検出される。たとえば、動作1は、ユーザがWindows OS環境においてキーボードのキーを介してALTとPrintScreenを同時に押したことの検出、ユーザがiOS環境においてホームボタンと電源ボタンを同時に押したことの検出などに対応してもよい。動作2において、OS605は、ディスプレイエンジン610にスクリーンショット要求を送る。図6における動作1〜2は、図4に関して上記で説明した動作1〜2と同様である。
図6を参照すると、動作3において、OS605は、アプリケーション1および場合によってはアプリケーション2...Nにセッション状態要求を送る。一例では、アプリケーション2...Nが現在実行されていないか、または現在スクリーンショットに関するターゲットエリア内の画像データを提供していない場合、OS605はアプリケーション2...Nにセッション状態要求を送る必要はない。
図6を参照すると、動作4において、アプリケーション1は、ディスプレイスクリーン630によって出力されるディスプレイフレーム内にレンダリングすべきアプリケーション固有画像データをディスプレイエンジン610に提供する。動作5において、アプリケーション2...Nはまた、場合によってはディスプレイスクリーン630によって出力されるようにディスプレイフレーム内でレンダリングすべきアプリケーション固有画像データを提供してもよい。UEがアプリケーション1に対してフルスクリーンモードで動作することが可能であり、その場合アプリケーション1に関する画像データのみがディスプレイフレームの一部を構成しているので、動作5は任意である。動作6において、ディスプレイエンジン610は、アプリケーション1(および場合によっては、アプリケーション2...N)からのアプリケーション固有画像データに基づいて、レンダリングされたスクリーンデータをディスプレイスクリーン630に送る。ディスプレイエンジン610はまた、OS405からのスクリーンショット要求に応答して、動作7において、レンダリングされたスクリーンデータをスクリーンショット生成モジュール620に送る。図6における動作4〜7は、図4に関して上記で説明した動作3〜6と同様である。
アプリケーション1は、動作3におけるOS605からのセッション状態要求に応答して、動作8において、アプリケーション1の現在のセッション状態の1つまたは複数の特徴の再作成を容易にするように構成されるアプリケーション固有メタデータをスクリーンショット生成モジュール620に送る。動作8においてアプリケーション1によって送られたアプリケーション固有メタデータ内に含まれる特定のデータまたはパラメータは、(i)OS605からのセッション状態要求によって指定するか、(ii)アプリケーション1によって指定するか、または(iii)それらの任意の組合せとすることができる。言い換えれば、動作時のセッション状態要求は、特定の種類の情報を求めてもよく、またはどんな特定のデータを含めるかに関してターゲットアプリケーションに従いつつ、単にターゲットアプリケーションにアプリケーション固有メタデータを提供するよう要求してもよく、またはこれらを組み合わせて行ってもよい。以下により詳細に説明するように、アプリケーション1に関するアプリケーション固有画像データが、(動作4と同様に)ディスプレイエンジン610に送られるかまたは(動作6と同様に)出力されるディスプレイスクリーンに提供されたときに、アプリケーション1から要求されたアプリケーション固有メタデータを使用して、アプリケーション1のセッション状態の1つまたは複数の特徴を再作成することができる。アプリケーション2...Nはまた、動作9において、場合によってはアプリケーション2...Nの現在のセッション状態の1つまたは複数の特徴の再作成を容易にするように構成されるアプリケーション固有メタデータをスクリーンショット生成モジュール620に送る。動作9は、アプリケーション2...Nが、(動作5が任意であるので)画像データを提供していない場合もあり、またはスクリーンショット内にキャプチャすべき関連するスクリーンエリアの外側にあるエリアに画像データを提供している場合(たとえば、ディスプレイスクリーン630が第1および第2のディスプレイスクリーンを含み、アプリケーション2...Nが、スクリーンショット用に指定されていないディスプレイスクリーンにのみ画像データを提供している場合、ディスプレイスクリーン630が第1および第2のウィンドウを含み、アプリケーション2...Nが、スクリーンショット用に指定されていないウィンドウにのみ画像データを提供している場合など)もあるので任意である。
図6を参照すると、スクリーンショット生成モジュール620は、レンダリングされたスクリーンデータならびにアプリケーション1...Nから受信された任意のアプリケーション固有メタデータに基づいてスクリーンショットを生成する。スクリーンショットはまた、あるファイル固有(またはアプリケーション汎用)メタデータ(たとえば、スクリーンキャプチャ時間、ファイル名、ファイルサイズなど)に基づいて生成されてもよい。スクリーンショットとアプリケーション固有メタデータの組合せは、図6には「スクリーンショット+」として示される。動作10において、スクリーンショット生成モジュール620は、生成された(またはキャプチャされた)スクリーンショット+をメモリ635に送り、スクリーンショット+はそこで、記憶されたスクリーンショット+ 1...Nのセットの間に記憶される。上記で図5のブロック515に関して説明したように、各スクリーンショット+は、アプリケーション固有メタデータを媒体ウォーターマークとして含むかまたは補足ヘッダ情報を介して埋め込まれたアプリケーション固有メタデータを含む単一のスクリーンショットファイルに対応するか、または代替としてメモリ内で互いにリンクされるかまたは関連付けられた2つの別個のファイルに対応してもよい。また、他の実施態様では、スクリーンショット+は、(たとえば、メモリを節約することなどのために)関連するキャプチャされた画像データを含まないアプリケーション固有メタデータから構成されてもよい。
図7は、本開示の一実施形態によるスクリーンショットキャプチャ時のアプリケーションセッション状態の1つまたは複数の特徴を再作成するプロセスを示す。図7のプロセスは、スクリーンショットをキャプチャしたのと同じUEにおいて実施されてもよく、または代替として異なるUEにおいて実施されてもよい。たとえば、図5のプロセスを実行するUEは、アプリケーション固有メタデータを含むキャプチャされたスクリーンショット(またはスクリーンショット+)をソーシャルネットワーキングサービスと共有してもよく、ソーシャルネットワーキングサービスは次いで、キャプチャされたスクリーンショットおよびアプリケーション固有メタデータをサードパーティUEに伝達してもよく、サードパーティUEは次いで、図7のプロセスを実行する。別の例では、図5のプロセスを実行するUEは、アプリケーション固有メタデータを含むキャプチャされたスクリーンショット(またはスクリーンショット+)を何らかの他の方法で(たとえば、P2PもしくはD2Dファイル交換、電子メール、またはテクスティングサービスなどを介して)別のUEと共有してもよく、別のUEは次いで、図7のプロセスを実行してもよい。また別の例では、スクリーンショットをキャプチャするUEが、キャプチャされた画像データを保持する関連するスクリーンショットを実際に共有することなくアプリケーション固有メタデータを共有することが可能である。この場合、アプリケーション固有メタデータが共有されるターゲットUEは、依然としてアプリケーション固有メタデータを使用してアプリケーションセッション状態の一部または全部を再作成してもよい。また別の例では、上記でブロック510に関して説明したようにスクリーンショットが実際にキャプチャされ記憶されることなしに、ブロック515においてアプリケーション固有メタデータが記憶され、その場合ブロック500においてスクリーンショットをキャプチャする要求を受信した(しかし、キャプチャしないことを選択した)UEは、依然としてアプリケーション固有メタデータを共有してもよい。したがって、以下のスクリーンショット+の参照は少なくともまた、アプリケーション固有メタデータの一部または全部を含むが、実際のキャプチャされたスクリーンショットを必ずしも含まなくてもよい。
図7を参照すると、ブロック700において、UEは、(たとえば、画像データのキャプチャされたスクリーンショットにおいて)スクリーンショットキャプチャ要求が発行されたときにディスプレイフレーム内の画像データを提供した第1のアプリケーションのセッション状態を定義するアプリケーション固有メタデータを取得する。アプリケーション固有メタデータは、ブロック700が実行されるときに対して、第1のアプリケーションの現在のセッション状態を必ずしも表すとは限らない第1のアプリケーションの履歴セッション状態を定義する。一例では、図7のUEが図5のプロセスを実行したのと同じUEに対応する場合、ブロック700は、アプリケーション固有データをメモリからロードするUEに対応してもよい。別の例では、図7のUEが図5のプロセスを実行したUEとは異なるUEに対応する場合、ブロック700は、外部ソースからアプリケーション固有データを受信するUE(たとえば、図5のプロセスを実行したUE、または中間UEなどの何らかの中間エンティティ、またはソーシャルネットワーキングサービスの一部としてソーシャルメディアシェアリング機能を実行するサーバ170)に対応してもよい。
図7を参照すると、UEは、ブロック703において、場合によってはキャプチャされたスクリーンショット(利用可能な場合)および/またはアプリケーション固有メタデータを更新する。ブロック703が実行される場合、更新後のキャプチャされたスクリーンショットおよび/またはアプリケーション固有メタデータは、スクリーンショット+の以後の処理に使用されてもよい。ブロック703は、図5のブロック520と同様に実行されてもよく、したがってブロック703については簡潔のためにこれ以上説明しない。
図7を参照すると、ブロック705において、UEは、アプリケーション固有メタデータによって定義される第1のアプリケーションのセッション状態をロードする要求を検出する。アプリケーション固有メタデータがブロック700において、キャプチャされたスクリーンショットに関する画像データとともに取得される一例では、図7のブロック705における検出は、ユーザがスクリーンショットを表すアイコン(またはサムネイル)をクリックし、その結果、キャプチャされたスクリーンショット内に生画像データを表示する代わりに(またはスクリーンショット内に生画像データを表示することに加えて)アプリケーション固有メタデータが処理されることに対応する。アプリケーション固有メタデータがブロック700において、キャプチャされたスクリーンショットなしに取得される代替例では、図7のブロック705における検出は、ロードできるユーザ選択可能なアプリケーションセッション状態などをリストするプルダウンメニューなどの様々な方法で行われてもよい。
図7を参照すると、UEは、ブロック710において、ブロック705において検出された要求に応答して第2のアプリケーションによって、アプリケーション固有メタデータを処理して、アプリケーション固有メタデータによって定義されるセッション状態の1つまたは複数の特徴を再作成する。一例では、ブロック710においてアプリケーション固有メタデータを処理する第2のアプリケーションは、図5のブロック505における第1のアプリケーションと同じアプリケーション(たとえば、同じプラットフォームまたはOS、同じバージョン番号など)に対応してもよい。ただし、これは厳密である必要はない。たとえば、それぞれのアプリケーションは、異なるバージョンを有してもよく(たとえば、Pandora iOSバージョン6とPandora iOSバージョン8)、異なるプラットフォーム上で動作してもよく(たとえば、iOSデバイス上のモバイルSafariブラウザとMacコンピュータ上のデスクトップSafariブラウザ)、同じアプリケーションクラスにおける異なるアプリケーションであってもよい(たとえば、デスクトップChromeブラウザとデスクトップFirefoxブラウザ)。一例では、アプリケーション固有メタデータは、第1のアプリケーションのセッション状態の再作成を試行しているアプリケーションのバージョン(たとえば、モバイルおよびデスクトップバージョン、特定のOSに関するアプリケーションの特定のバージョンなど)に基づいて第1のアプリケーションのセッション状態を再作成するために取るべき特定のアクションをリストするバージョンテーブルを含んでもよい。たとえば、Google Mapsアプリケーションセッション状態に関して、アプリケーション固有メタデータは、バージョンテーブルの一部として、モバイルGoogle Mapsアプリケーションによるセッション状態再作成に関する第1の命令、セッション状態再作成に関してGoogle Mapsウェブサイトにナビゲートするモバイルまたはデスクトップウェブブラウザアプリケーションによるセッション状態再作成に関する第2の命令、異なる地図アプリケーション(たとえば、Google Mapsが利用可能ではない場合のiOS上のApple Mapsなど)によるセッション状態再作成に関する第3の命令などを含んでもよい。第1のアプリケーションと第2のアプリケーションが(たとえば、PandoraやSpotifyなどのアプリケーションタイプ、iOSやWindows XPやAndroidなどのOS、ウェブブラウザまたは専用地図アプリケーションなどのアプリケーションクラス、ioS7互換PandoraやiOS10互換Pandoraなどのアプリケーション固有バージョン番号に関して)異なるかどうかとは無関係に、第2のアプリケーションは、スクリーンショットがキャプチャされたときに第1のアプリケーションのセッション状態の少なくともいくつかの特徴を再作成するようにアプリケーション固有メタデータを解釈できると仮定される。
引き続き図7を参照すると、第2のアプリケーションが、セッション状態の1つまたは複数の特徴の再作成に関するアプリケーション固有メタデータを解釈できないこと(たとえば、第1のアプリケーションが認識されない場合があること、URLまたはURIが無効であることなど)が考えられる。この場合、セッション状態の1つまたは複数の特徴を再作成するのを可能にする情報を導き出すための試行において、キャプチャされたスクリーンショット(ブロック700においてアプリケーション固有メタデータとともに取得された場合)が評価されてもよい。たとえば、1つまたは複数のアプリケーションにおいてキャプチャされたスクリーンショットとの最も近い一致を見つけるためにOCR分析および/またはコンピュータビジョン画像類似性整合が使用される場合があるブルートフォース方式を使用することができる(たとえば、アプリケーションのセットの様々なスクリーンオプションをキャプチャされたスクリーンショットと比較して最も近い一致を見つけることができる)。別の例では、キャプチャされた画像が、ビデオの特定のビデオフレームを示す画像データを含み、アプリケーション固有メタデータが、ビデオの特定のビデオフレームを識別するディープリンキングURIを含まないと仮定する。上述の手法と同様に、(たとえば、コンピュータビジョン類似性整合を使用して)ビデオに関係する画像データをビデオのビデオフレームと比較して正しいビデオフレームを識別することができるブルートフォース方式を使用することができる。
図8は、本開示の一実施形態によるUE動作環境800におけるアプリケーションセッション状態の再作成に関連するコンポーネント相互作用の一例を示す。各コンポーネントに関して、UE動作環境800は、図6のUE動作環境600と同様である。ただし、スクリーンキャプチャ生成が図8に示す機能とは無関連であるのでスクリーンショット生成モジュール620は省略される。上述のように、図5のプロセスと図7のプロセスを実行するUEは同じであってもよく、その場合UE動作環境600および800は同じUEの異なる機能表現に対応する。代替として、図5のプロセスと図7のプロセスを実行するUEは異なってもよく、その場合それぞれのコンポーネントは同じであってもまたは異なっていてもよい(たとえば、図6のOS605はiOSであってもよく、一方図8のOS805はWindows OSまたはAndroidであってもよいことなど)。
図8を参照すると、UE動作環境800は、OS805と、ディスプレイエンジン810(たとえば、1つまたは複数のグラフィックスデバイスドライバ、グラフィックスカード、専用グラフィックスカーネルなど)と、UE実行可能アプリケーション1...N(たとえば、UEにおける関連するメモリに記憶されたアプリケーション、ここでNは2以上である)とを含む。UE動作環境800は、(たとえば、図2の215、図3の325などに対応する)UI入力コンポーネント825と、(図2の220、図3の320などに対応する)ディスプレイスクリーン830と、(図2の210、図3の315などに対応する)メモリ835とをさらに含む。図8に示す例では、メモリ835はスクリーンショット+ 1...Nのセットを含む。一例では、メモリ835に保持される各スクリーンショット+は、特定のスクリーンショット+に関するアプリケーション固有メタデータとキャプチャされたスクリーンショットから得た生画像データの両方を含んでもよく、または代替としてアプリケーション固有データは、スクリーンショット+のうちの少なくとも1つの関連する生画像データなしで保持されてもよい。
図8を参照すると、図7のプロセスの例示的な実装形態が、1〜8として列挙された動作を介して示される。動作1〜8の特定の順序は実装形態ごとに異なる場合がある(たとえば、動作2および3を任意の順序で行うことなどが可能である)。動作1において、スクリーンショット+アプリケーションセッション状態要求がUI入力コンポーネント425を介してOS805によって検出される。たとえば、動作1は、ユーザが特定のスクリーンショット+を表すアイコンをクリックしたことに対応してもよい(たとえば、ユーザが電話上のフォトギャラリーをスクロールし、次いでスクリーンショット+の画像データ部分のサムネイルによって視覚的に表されているスクリーンショット+を選択する)。動作2において、OS805は、指定されたスクリーンショット+に関するアプリケーション固有メタデータを求める要求をメモリ835に送る。動作3において、メモリ835は、指定されたスクリーンショット+に関するアプリケーション固有メタデータをUS805に返す。
図8を参照すると、動作4において、取得されたアプリケーション固有メタデータの少なくとも一部がアプリケーション1に送られる。上述のように、図6の動作8においてアプリケーション固有メタデータを提供したアプリケーション1は、図8の動作4においてアプリケーション固有メタデータを受信するアプリケーション1と同じである必要はない。ただし、これは間違いなく可能である。むしろ、図6および図8におけるそれぞれのアプリケーション1は、バージョン番号、OSタイプに関して異なる場合があり、または同じクラスの異なるアプリケーション(たとえば、異なる種類のウェブブラウザまたはワード処理アプリケーションなど)に対応してもよい。アプリケーション固有メタデータは場合によっては、動作9および図6におけるアプリケーション2...Nに関して上記で示したのと同じスクリーンショット+に関連して複数のアプリケーションについて取得されてもよい。同様に、任意の動作5において、アプリケーション固有メタデータの少なくとも一部がアプリケーション2...Nに送られてもよい。一例では、場合によっては図8におけるアプリケーション2...Nに送られるアプリケーション固有メタデータは、場合によっては図6のアプリケーション2...Nについて取得されるアプリケーション固有メタデータに対応してもよい。代替例では、アプリケーション固有メタデータが図6におけるアプリケーション2...Nについて取得される場合でもまた、このアプリケーション固有メタデータを図8におけるアプリケーション2...Nに送る必要はない(たとえば、ユーザがこれらの特定のアプリケーションのセッション状態を再作成することを望まない場合、これらの特定のアプリケーションからのアプリケーション固有メタデータが情報プライバシー方式に従って取り去られるかまたは削除された場合など)。また、上記でアプリケーション1に関して説明したように、図8と比較して、図6では、アプリケーション2...Nは(たとえば、バージョン番号、OSタイプなどに関して)同じアプリケーションに対応してもよく、または互いに異なってもよい。
図8を参照すると、アプリケーション1は、動作4において受信されたアプリケーション固有メタデータを処理し、アプリケーション2...Nも場合によっては、動作5において受信されたアプリケーション固有メタデータを処理する。アプリケーション固有メタデータがどのように処理されるかの例については以下により詳細に説明する。アプリケーション固有メタデータの処理の結果は、ディスプレイスクリーン830によって出力されるディスプレイフレーム内にレンダリングすべきアプリケーション画像データとして、動作6においてアプリケーション1によってディスプレイエンジン810に伝達され、(場合によっては)動作7においてアプリケーション2...Nによってディスプレイエンジン810に伝達される。図8には明示的に示されていないが、アプリケーション固有メタデータの処理に基づいて他の種類の出力が与えられてもよいこと(たとえば、聴覚出力および/または視覚出力など)が了解されよう。動作8において、ディスプレイエンジン810は、アプリケーション1(および場合によっては、アプリケーション2...N)からのアプリケーション固有画像データに基づいて、レンダリングされたスクリーンデータをディスプレイスクリーン830に送る。
図9は、本開示の実施形態による、図5および図7のプロセスの例示的な実装形態を示す。特に、図9は、異なる量または種類のアプリケーション固有メタデータが、ソースUE(またはUE1)が特定のターゲットデバイスに対して有する信頼度に基づいて共有される例を示す。図9はまた、単一のアプリケーションが、スクリーンショットに関連するディスプレイフレームの部分において関連する画像データのすべてを提供している例を示す。一例では、これは、単一のアプリケーションがフルスクリーンモードで動作しているとき、または単一のアプリケーションが画像データを提供している唯一のアプリケーションであるディスプレイフレームの部分の上にスクリーンショットの境界が配置される場合に生じることがある。以下の図9のプロセスについては、便宜上、単一のアプリケーション(アプリケーション1)に関して説明する。ただし、他のアプリケーション(または同じアプリケーションの異なるインスタンス)が画像データを提供しているスクリーンショット領域の外側にディスプレイフレームのエリアがあることが考えられる。図9は、上述のように、UEが別のUEのディスプレイスクリーンのスナップショットを撮ってスクリーンショット+を生成するシナリオとは異なり、UE1がスクリーンショット+をセルフキャプチャする例も表す。
図9を参照すると、ブロック900において、アプリケーション1によって提供される画像データが、UE1のディスプレイスクリーン上のディスプレイフレーム内に出力されている。ブロック905において、(たとえば、図5のブロック500と同様に)スクリーンショットキャプチャ要求が検出される。ブロック910において、スクリーンショット+がキャプチャされ、ここでスクリーンショット+は、(図5のブロック505〜515と同様に)スクリーンショットとアプリケーション1に関するアプリケーション固有メタデータとを含む。
図9を参照すると、ブロック915において、UE1は、スクリーンショット+をサーバ(たとえば、サーバ170、一例ではソーシャルネットワーキングサーバに対応する場合がある)に送る要求を受信する。図9の実施形態では、UE1がサーバにおける信頼度が低いと仮定する(たとえば、サーバに関する信頼スコアは第1の信頼しきい値よりも低い)。ブロック920において、UE1のサーバにおける信頼度が低いことに応答して、スクリーンショット+に関する生画像データがサーバに送られる。一例では、UE1においてフィルタ処理演算を実行して、生画像データを含むスクリーンショットファイルから影響を受ける可能性がある任意のアプリケーション固有メタデータを削除し、ブロック920においてサーバに送られるスクリーンショット+のバージョンを生成してもよい。代替例では、生画像データを含むスクリーンショット+に関するスクリーンショットファイルが、アプリケーション1に関するアプリケーション固有メタデータを含むファイルとは別個に記憶される場合、ブロック920において、スクリーンショット+に関するスクリーンショットファイルを修正なしに(ただし、アプリケーション固有メタデータを含む別個のファイルをアタッチせずに)サーバにアップロードすることができる。ブロック925において、サーバは、スクリーンショット+に関する画像データをUE3と共有する。ブロック930において、UE3は、アプリケーション1(またはアプリケーション1と同等のアプリケーション)を起動せずに(たとえば、任意の他の画像ファイルと同様に)単に画像データを表示することによって、スクリーンショット+に関する画像データに従来の方法でアクセスする。ブロック915〜930は、サーバがスクリーンショット+に関する画像データを再分配するシナリオについて説明しているが、このシナリオにおけるサーバが任意の中間デバイスを表すことが了解されよう。他の実施形態では、UE1は、別のUEにおける信頼度が低く、スクリーンショット+に関する画像データのみを信頼度の低いUEに送る。信頼度の低いUEは次いで、スクリーンショット+に関する画像データをブロック925〜930においてサーバと同様に1つまたは複数の他のデバイスに再分配してもよい。
図9を参照すると、ブロック935において、UE1は、スクリーンショット+をUE2およびUE4に送る要求を受信する。図9の実施形態では、UE1のUE2における信頼度が中間レベルであり(たとえば、UE2に関する信頼スコアは第1の信頼しきい値よりも高く、第2の信頼しきい値よりも低い)、UE1のUE4における信頼度が高い(たとえば、UE4に関する信頼スコアは第1および第2の信頼しきい値よりも高い)と仮定する。一例では、UE1の様々なエンティティに対する信頼度は、ユーザによって指定されてもよく(たとえば、UE1は、あるエンティティを家族または友人などと標示する)、またはUE1とそれぞれのエンティティとの間の相互作用の分析から判定されてもよい。それぞれの信頼しきい値は、OS設定としてユーザ指定されてもよくまたはあらかじめ定義されてもよい。
図9を参照すると、ブロック940において、UE1のUE4における信頼度が高いことに応答して、スクリーンショット+に関する画像データがアプリケーション固有メタデータのフィルタ処理されていないバージョンとともにUE4に送られる。ブロック945において、UE1のUE2における信頼度が中間レベルであることに応答して、スクリーンショット+に関する画像データがアプリケーション固有メタデータのフィルタリング済みバージョンとともにUE2に送られる。一例では、UE1においてフィルタ処理演算を実行して、スクリーンショットファイルから特定のアプリケーション固有メタデータを削除し、ブロック945においてサーバに送られるスクリーンショット+のバージョンを生成してもよく、一方このフィルタ処理演算は、UE4に送られるスクリーンショット+のバージョンについては実行されない。
図9を参照すると、ブロック950において、アプリケーション1がUE1上で終了すると仮定する。ブロック955において、UE1は、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するアプリケーション固有メタデータに基づいてアプリケーション1セッション状態をロードする要求を受信する。UE1は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、ブロック960においてアプリケーション1を起動し、次いでアプリケーション1は、アプリケーション1に関するアプリケーション固有メタデータを処理して、ブロック965において(たとえば、図7のブロック710と同様に)アプリケーション1セッション状態の1つまたは複数の特徴を再作成する。
図9を参照すると、ブロック970において、フィルタ処理済みスクリーンショット+をUE1から受信した後のある時点において、UE2は、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するフィルタ処理済みアプリケーション固有メタデータに基づいてスクリーンショット+からアプリケーション1セッション状態をロードする要求を受信する。UE2は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、スクリーンショット+に関するアプリケーション固有メタデータを処理するのに適したアプリケーションがUE2上で利用可能であるかどうかを評価する。たとえば、スクリーンショット+に関するアプリケーション固有メタデータは、必要なアプリケーションクラス(たとえば、任意の種類のウェブブラウザが受け入れ可能になるような汎用ウェブブラウザ)、特定の必要なアプリケーション(たとえば、Chromeブラウザ)、必要なバージョン番号(たとえば、Chrome iOSブラウザバージョン6以上、Safari iOSブラウザバージョン8以上など)、またはそれらの組合せ(たとえば、iOSバージョン10以上に適合する任意のウェブブラウザ)を指定してもよい。別の例では、スクリーンショット+に関するアプリケーション固有メタデータは、上述のように、アプリケーションセッション状態の再構成を試行しているアプリケーションのそれぞれに異なるバージョンに関するセッション状態再作成に関して実行すべきそれぞれに異なる命令を指定するバージョンテーブルを含んでもよい。UE2は、新しいアプリケーションをインストールする必要があるか、または既存のアプリケーションを更新してアプリケーション固有メタデータを処理する必要があると判定した場合、ブロック974においてアプリケーションをインストールまたは更新する。ブロック978において、アプリケーション(上述のようにアプリケーション固有メタデータに記載されたアプリケーション要件に応じてアプリケーション1またはアプリケーション1と同等のアプリケーション)が起動され、ブロック982において、アプリケーションは、フィルタ処理済みのアプリケーション固有メタデータを処理して、スクリーンショット+からアプリケーション1セッション状態の特徴の一部または全部を再作成する。ブロック982で行われる場合がある処理の種類の例について、以下により詳細に説明する。
図9を参照すると、ブロック986において、フィルタ処理されていないスクリーンショット+をUE1から受信した後のある時点において、UE4は、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するフィルタ処理されていないアプリケーション固有メタデータに基づいてスクリーンショット+からアプリケーション1セッション状態をロードする要求を受信する。UE4は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、UE2に関して上記のブロック974において説明したように、スクリーンショット+に関するアプリケーション固有メタデータを処理するのに適したアプリケーションがUE4上で利用可能であるかどうかを評価する。UE4は、新しいアプリケーションをインストールする必要があるか、または既存のアプリケーションを更新してアプリケーション固有メタデータを処理する必要があると判定した場合、ブロック990においてアプリケーションをインストールまたは更新する。ブロック994において、アプリケーション(上述のようにアプリケーション固有メタデータに記載されたアプリケーション要件に応じてアプリケーション1またはアプリケーション1と同等のアプリケーション)が起動され、ブロック998において、アプリケーションは、フィルタ処理されていないアプリケーション固有メタデータを処理して、スクリーンショット+からアプリケーション1セッション状態の特徴の一部または全部を再作成する。ブロック998で行われる場合がある処理の種類の例について、以下により詳細に説明する。
図10は、本開示の実施形態による、図9のプロセスの例示的な実行に基づくアプリケーションセッション状態再作成1000を示す。図10において、図9におけるUE1は、スマートフォン1005として示され、UE4はスマートフォン1015として示され、アプリケーション1はモバイルYouTubeアプリケーションに対応する。ディスプレイスクリーン1010は、YouTubeアプリケーションが、全長が14:10(14分10秒)である"Cat Video Compilation - 2016"という名称のビデオの、特に4:07(4分7秒)の時点を実行する間に撮られたスクリーンショット+に関する画像データを表す。ディスプレイスクリーン1010に示すように、このビデオは現在、視聴総数が113,555であり、スマートフォン1005のユーザに対して関連するビデオ1が示され、スマートフォン1005のユーザに対して広告としてスポンサービデオ1が示される。
スクリーンショット+におけるモバイルYouTubeアプリケーションのセッション状態を特徴付けるアプリケーション固有メタデータ1020(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID: YouTube(バージョン6以上)
ユニフォームリソースロケータ(URL):https://youtu.be/abcdefg
視聴時間: 4:07
スマートフォン1015は、アプリケーション固有メタデータ1020に基づいて、モバイルYouTubeアプリケーションをインストールまたは更新し(必要な場合)、URL"https://youtu.be/abcdefg"にナビゲートし、指定された4:07の時点に直接進む。スマートフォン1015におけるモバイルYouTubeアプリケーションの得られるセッション状態が、ディスプレイスクリーン1025に示される。スマートフォン1015におけるディスプレイスクリーン1025に示されるモバイルYouTubeアプリケーションの得られるセッション状態が、スマートフォン1005におけるディスプレイスクリーン1010に示されるモバイルYouTubeアプリケーションの初期セッション状態と同一ではないことを了解されたい。この理由は、様々なパラメータが変更される(たとえば、視聴数が異なり、異なる関連/スポンサービデオが示唆され/広告として示される)からである。したがって、モバイルYouTubeアプリケーションの初期セッション状態の各特徴をスマートフォン1015におけるセッション状態再作成の一部として再作成する必要はない(ただし、これは特定のシナリオにおいて生じる場合がある)。
図11は、本開示の別の実施形態による図9のプロセスの例示的な実行に基づくアプリケーションセッション状態再作成1100を示す。図11において、図9におけるUE1はコンピュータ1105(たとえば、デスクトップコンピュータまたはラップトップコンピュータ)として示され、UE4は代替として、スマートフォン1115およびコンピュータ1125(たとえば、デスクトップコンピュータまたはラップトップコンピュータ)として示され、アプリケーション1はウェブブラウザに対応する。ディスプレイスクリーン1110は、ウェブブラウザが(たとえば、説明の便宜上部分的なURLであるhttps://www.amazon.com/tennisrackets/...,から始まる)特定のウェブページを表示する間に撮られたスクリーンショット+に関する画像データを表す。より詳細には、ユーザは、特定のテニスラケットを販売価格が99.99ドルであるものとしてリスト表示されるようにウェブページ内をスクロールダウンした。
スクリーンショット+におけるウェブブラウザのセッション状態を特徴付けるアプリケーション固有メタデータ1135(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID: 専用Amazonアプリケーション(利用可能な場合)またはデフォルトウェブブラウザ
URL: https://www.amazon.com/tennisrackets/...
スマートフォン1115は、アプリケーション固有メタデータ1135に基づいて、スマートフォン1115上にすでに専用Amazonアプリケーションがインストールされているかどうかをチェックする。スマートフォン1115上にすでに専用Amazonアプリケーションがインストールされている場合、専用Amazonアプリケーションを使用して、指定されたURLに対応する製品ページがロードされる。スマートフォン1115上に専用Amazonアプリケーションがインストールされていない場合、スマートフォン1115上のデフォルトウェブブラウザ(たとえば、モバイルウェブブラウザ)が、ディスプレイスクリーン1120内に示されるように指定されたURLにナビゲートする。ディスプレイスクリーン1120に示されるスマートフォン1115におけるモバイルウェブブラウザの得られるセッション状態は、スマートフォン1105におけるディスプレイスクリーン1110に示されるウェブブラウザの初期セッション状態と同一ではない。この理由は、様々なパラメータが変更される(たとえば、スマートフォン1115の出力先のURLのモバイルバージョンへの変更など)からである。
上述のように、コンピュータ1125は、スマートフォン1115に加えてスクリーンショット+を受信する別のターゲットデバイスである。コンピュータ1125は、アプリケーション固有メタデータ1135に基づいて、コンピュータ1125上にすでに専用Amazonアプリケーションがインストールされているかどうかをチェックする。コンピュータ1125上に専用Amazonアプリケーションがすでにインストールされている場合、専用Amazonアプリケーションを使用して、指定されたURLに対応する製品ページがロードされる。コンピュータ1125上に専用Amazonアプリケーションがインストールされていない場合、コンピュータ1125上のデフォルトウェブブラウザ(たとえば、フル機能または非モバイルウェブブラウザ)が、ディスプレイスクリーン1130内に示されるように指定されたURLにナビゲートする。一例では、ウェブサイトがディスプレイスクリーン1110上に表示されるスクロール位置もまた、アプリケーション固有メタデータ1135の一部として記録されることがあり、それによってコンピュータ1125におけるウェブブラウザが、指定されたURLをロードし、またスクロールバーをアプリケーション固有メタデータ1135に記録されたのと同じ点までシフトダウンさせて、スクリーンショット+によって定義されるセッション状態をより厳密に再作成する場合がある。
図12Aは、本開示の別の実施形態による、図9のプロセスの例示的な実行に基づくアプリケーションセッション状態再作成1200Aを示す。図12Aにおいて、図9におけるUE1は、スマートフォン1205Aとして示され、UE4はスマートフォン1215Aとして示され、アプリケーション1はモバイルGoogle Mapsアプリケーションに対応する。ディスプレイスクリーン1210Aは、モバイルGoogle Mapsアプリケーションが特定のターゲットアドレス(たとえば、ホワイトハウスのアドレスであるワシントンDCペンシルベニア大通り1600)を中心として表示される間に撮られたスクリーンショット+に関する画像データを表す。
スクリーンショット+におけるモバイルGoogle Mapsアプリケーションのセッション状態を特徴付けるアプリケーション固有メタデータ1225A(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID: Google Maps
アドレス: ワシントンDCペンシルベニア大通り1600
スマートフォン1215Aは、アプリケーション固有メタデータ1225Aに基づいて、スマートフォン1215A上にすでにGoogle Mapsアプリケーション(たとえば、スマートフォン1215AがモバイルデバイスであるのでモバイルGoogle Mapsアプリケーション)がインストールされているかどうかをチェックする。スマートフォン1215A上にモバイルGoogle Mapsアプリケーションがインストールされていない場合、一例ではユーザがモバイルGoogle Mapsアプリケーションをダウンロードしインストールするように促され、または代替としてモバイルGoogle Mapsアプリケーションが自動的にダウンロードされインストールされる。モバイルGoogle Mapsアプリケーションは次いで、ワシントンDCペンシルベニア大通り1600をターゲットアドレスとして入力することによってアプリケーション固有メタデータ1225Aを処理し、それによってディスプレイスクリーン1220Aがホワイトハウスを中心として表示される。一例では、ホワイトハウスがディスプレイスクリーン1210A上に表示されるときのズーム情報(たとえば、特定の地理的境界、ズームのスケールなど)もアプリケーション固有メタデータ1225Aの一部として記録されることがあり、それによってスマートフォン1215AにおけるモバイルGoogle Mapsアプリケーションは、ディスプレイスクリーン1210A内のターゲットアドレスの表示に相応するターゲットズームレベルでターゲットアドレスをロードする場合がある。
図12Bは、本開示の別の実施形態による、図9のプロセスの例示的な実行に基づくアプリケーションセッション状態再作成1200Bを示す。図12Bにおいて、図9におけるUE1は、スマートフォン1205Bとして示され、UE2はコンピュータ1215B(たとえば、デスクトップコンピュータまたはラップトップコンピュータ)として示され、アプリケーション1はモバイルGoogle Mapsアプリケーションに対応する。ディスプレイスクリーン1210Bは、モバイルGoogle Mapsアプリケーションが特定のターゲットアドレス(たとえば、ホワイトハウスのアドレスであるワシントンDCペンシルベニア大通り1600)を中心として表示される間に撮られたスクリーンショット+に関する画像データを表す。
スクリーンショット+におけるモバイルGoogle Mapsアプリケーションのセッション状態を特徴付けるフィルタ処理済みアプリケーション固有メタデータ1225B(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID: Google Maps
アドレス: ダウンタウンワシントンDC
アプリケーション固有メタデータ1225Bは、図9におけるUE2に関するブロック935およびブロック945と同様に、ワシントンDCペンシルベニア大通り1600というより詳細なアドレスが、アプリケーション固有メタデータ1225Bによって曖昧にされ、より一般的な「ダウンタウンタウン」という名称に置き換えられるので、フィルタ処理に応じて特徴付けられる。たとえば、ワシントンDCペンシルベニア大通り1600は、スマートフォン1205Bの現在位置または将来の位置に対応する場合があるが、スマートフォン1205Bのユーザは必ずしもこの位置をコンピュータ1215Bと共有したいとは限らない(たとえば、厳密な位置をソーシャルネットワークを介して共有することを望まない場合、または中間信頼度の友人と共有することを望まない場合など)。
コンピュータ1215Bは、フィルタ処理済みのアプリケーション固有メタデータ1225Bに基づいて、コンピュータ1215B上にすでにGoogle Maps互換アプリケーションがインストールされているかどうかをチェックする。この場合、コンピュータ1215Bが、Google Mapsウェブサイトにナビゲートするデフォルトウェブブラウザを適切なGoogle Mapsアプリケーションと見なすと仮定する。したがって、デフォルトウェブブラウザ(たとえば、Chromeブラウザとして示される)は、Downtown, Washington, DCをターゲットアドレス(またはターゲット領域)として入力することによってアプリケーション固有メタデータ1225Bを処理し、それによってディスプレイスクリーン1220BがワシントンDCを中心として表示される。上述のメタデータフィルタ処理によって、ディスプレイスクリーン1220B内のワシントンDCの投影図は、ディスプレイスクリーン1210B内のモバイルGoogle Mapsアプリケーションのセッション状態におけるより詳細に定義されたアドレスの表示に対してより大きくズームアウトされる。
図13は、本開示の別の実施形態による図9のプロセスの例示的な実行に基づくアプリケーションセッション状態再作成1300を示す。図13において、図9におけるUE1は、スマートフォン1305として示され、UE4はスマートフォン1315として示され、アプリケーション1はモバイルWeChatアプリケーション(たとえば、グループメッセージングアプリケーション)に対応する。ディスプレイスクリーン1310は、モバイルWeChatアプリケーションが特定のチャットグループ「クラスメート」間のチャット対話の特定の部分を示す間に撮られたスクリーンショット+に関する画像データを表す。
スクリーンショット+におけるモバイルWeChatアプリケーションのセッション状態を特徴付けるアプリケーション固有メタデータ1325(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID: WeChat
ユニフォームリソース識別子(URI): 「クラスメート」グループチャットへのディープリンク
スマートフォン1320("Joe"という名前のユーザによって操作されると仮定される)は、アプリケーション固有メタデータ1325に基づいて、スマートフォン1315上にすでにWeChatアプリケーション(たとえば、スマートフォン1315がモバイルデバイスであるのでモバイルWeChatアプリケーション)がインストールされているかどうかをチェックする。モバイルWeChatアプリケーションがインストールされていると仮定すると、モバイルWeChatアプリケーションは、関連するチャット履歴をロードすることによってアプリケーション固有メタデータ1325のURIに指定されたディープリンクを処理し、ディスプレイスクリーン1320内に示されるように、スクリーンショット+に示されるチャット履歴の部分に直接ナビゲートする。ディスプレイスクリーン1320に示されるスマートフォン1315におけるモバイルWeChatアプリケーションの得られるセッション状態は、スマートフォン1305におけるディスプレイスクリーン1310に示されるモバイルWeChatアプリケーションの初期セッション状態と同一ではない。この理由は、様々なパラメータが変更されるからである(たとえば、スマートフォン1320は、ユーザ"Joe"で登録されており、したがってモバイルWeChatアプリケーションは、ディスプレイスクリーン1320におけるJoeからのあらゆるチャットを"Joe"からのチャットとして指定するのではなく"Me"として指定する)。
図9〜図13は、図5および図7のプロセスの例示的な実装形態に関し、それによって特定のスクリーンショット+に関連するアプリケーション固有メタデータは単一のアプリケーションに関係するが、次に、図14〜図16Bに関して説明するように、図5および図7のプロセスが、スクリーンショット+の画像データ部分に画像データを提供する複数のアプリケーションに関するアプリケーション固有メタデータを含むスクリーンショット+に関係することも考えられる。
図14は、本開示の別の実施形態による、図5および図7のプロセスの例示的な実装形態を示す。詳細には、図14は、複数のアプリケーションがスクリーンショットに関連するディスプレイフレームの部分に画像データを提供しており、スクリーンショット+に関するこれらの複数のアプリケーションのうちの2つ以上に関連するアプリケーション固有メタデータが外部ターゲットアドレスデバイスと共有される例を示す。一例では、これは、ディスプレイスクリーン内に出力されているディスプレイフレームのスクリーンショットエリア内に各々が表示される別々のウィンドウ内で複数のアプリケーションが動作しているときに生じる場合がある。スクリーンショットエリアの外側において、他のアプリケーション(または同じアプリケーションのそれぞれに異なるインスタンス)が画像データを提供しているディスプレイフレームのエリアがあることも考えられる。図14は、上述のように、UEが別のUEのディスプレイスクリーンのスナップショットを撮ってスクリーンショット+を生成するシナリオとは異なり、UE1がスクリーンショット+をセルフキャプチャする例も表す。
図14を参照すると、ブロック1400において、アプリケーション1、2、および3によって提供される画像データが、UE1のディスプレイスクリーン上のディスプレイフレーム内に出力されている。ブロック1405において、(たとえば、図5のブロック500と同様に)スクリーンショットキャプチャ要求が検出される。ブロック1410において、UE1は、アプリケーション3の現在のセッション状態を定義するアプリケーション固有メタデータを取得することはできないと判定する。一例では、アプリケーション3に関するアプリケーション固有メタデータは、アプリケーション3が、(たとえば、デフォルトセキュリティ設定またはユーザ構成設定である場合がある)セキュリティ予防措置としてアプリケーション固有メタデータを共有することを許可しない保護されたアプリケーションとして(たとえば、UE1のOSにおけるセキュリティ設定またはアプリケーション3自体に組み込まれたセキュリティ設定を介して)構成されることに基づいて利用不能である場合がある。別の例では、アプリケーション3に関するアプリケーション固有メタデータは、アプリケーション3が、アプリケーション固有メタデータの共有をサポートしない(たとえば、アプリケーション3が、アプリケーション3の現在のセッション状態の特徴を再作成するのを助ける情報を共有するにはどうしたらよいかを知らない)レガシーアプリケーションであることに起因して利用不能である場合がある。ブロック1415において、スクリーンショット+がキャプチャされ、ここでスクリーンショット+は、(図5のブロック505〜515と同様に)スクリーンショットとアプリケーション1および2に関するアプリケーション固有メタデータとを含む。
図14を参照すると、ブロック1420において、UE1は、スクリーンショット+をUE2、UE3、およびUE4に送る要求を受信する。図14の実施形態では、説明の便宜上、(たとえば、選択的なメタデータフィルタ処理には信頼度が使用されず、UE1のUE2、UE3、およびUE4に対する信頼度が最高信頼しきい値以上であることに起因して)メタデータフィルタ処理は実行されないと仮定する。しかし、他の実施形態では、図9のプロセスにおけるサーバおよびUE2に関して上記で説明したようにUE2、UE3、およびUE4のうちの1つまたは複数に関してメタデータフィルタ処理が実行されてもよいことが了解されよう。ブロック1425において、スクリーンショット+に関する画像データが、アプリケーション1および2に関するアプリケーション固有メタデータとともにUE2、UE3、およびUE4に送られる。
図14を参照すると、ブロック1430において、UE2は、UE1からスクリーンショット+を受信した後のある時点において、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するアプリケーション固有メタデータに基づいてスクリーンショット+からアプリケーション1セッション状態およびアプリケーション2セッション状態をロードする要求を受信する。一例では、ブロック1430は、両方のアプリケーションセッション状態を構成する要求を示すが、スクリーンショット+は、以下にブロック1450〜1485に関して説明するように、アプリケーション固有メタデータを使用して選択的なアプリケーションセッション状態ローディング(たとえば、アプリケーション1セッション状態のみをロードすること、アプリケーション2セッション状態のみをロードすることなど)を可能にするように構成されてもよい。
UE2は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、スクリーンショット+に示されるアプリケーション1セッション状態およびアプリケーション2セッション状態に関するアプリケーション固有メタデータを処理するのに適したアプリケーションがUE2上で利用可能であるかどうかを評価する。UE2は、1つもしくは複数の新しいアプリケーションをインストールする必要があるか、または1つもしくは複数の既存のアプリケーションを更新してアプリケーション1セッション状態またはアプリケーション2セッション状態のいずれかの再作成に関するアプリケーション固有メタデータを処理する必要があると判定した場合、ブロック1435においてアプリケーションをインストールまたは更新する。ブロック1440において、アプリケーション(上述のようにアプリケーション固有メタデータに記載されたアプリケーション要件に応じてアプリケーション1および2、アプリケーション1および2と同等のアプリケーション、またはそれらの組合せ)が起動され、ブロック1445において、アプリケーションは、アプリケーション固有メタデータのそれぞれのアプリケーション1部分およびアプリケーション2部分を処理して、スクリーンショット+からそれぞれアプリケーション1セッション状態およびアプリケーション2セッション状態の特徴の一部または全部を再作成する。ブロック1445で行われる場合がある処理の種類の例について、以下により詳細に説明する。
図14のブロック1445を参照すると、、一例ではUE2におけるアプリケーション1セッション状態およびアプリケーション2セッション状態の再作成による任意の画像データを示すスクリーン部分が、UE1においてキャプチャされたスクリーンショットに示される同様のスクリーン部分に割り振られてもよい(たとえば、スクリーンショットが、ディスプレイフレームの左側にアプリケーション1ウィンドウを示し、ディスプレイフレームの右側にアプリケーション2ウィンドウを示す場合、これらの同じ相対位置が、UE2上の得られるアプリケーションセッション状態再作成において維持されてもよい)。相対スクリーン位置データは、一例ではアプリケーション固有メタデータの一部として伝達されてもよい。ただし、アプリケーション固有メタデータがそれぞれのアプリケーションに関する相対スクリーン位置データの参照なしに構成されることも考えられる。
図14を参照すると、ブロック1450において、UE3は、UE1からスクリーンショット+を受信した後のある時点において、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するアプリケーション固有メタデータに基づいてスクリーンショット+からアプリケーション1セッション状態をロードする要求を受信する。言い換えれば、UE3は、アプリケーション2セッション状態を再作成することを重要視しない。UE3は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、スクリーンショット+に示されるアプリケーション1セッション状態に関するアプリケーション固有メタデータを処理するのに適したアプリケーションがUE3上で利用可能であるかどうかを評価する。UE3は、新しいアプリケーションをインストールする必要があるか、または既存のアプリケーションを更新して、アプリケーション1セッション状態を再作成できるようにアプリケーション固有メタデータを処理する必要があると判定した場合、ブロック1455においてアプリケーションをインストールまたは更新する。ブロック1460において、アプリケーション(上述のようにアプリケーション固有メタデータに記載されたアプリケーション要件に応じてアプリケーション1またはアプリケーション1と同等のアプリケーション)が起動され、ブロック1465において、アプリケーションは、スクリーンショット+からアプリケーション1セッション状態の特徴の一部または全部を再作成するようにアプリケーション固有メタデータのそれぞれのアプリケーション1部分を処理する。ブロック1465で行われる場合がある処理の種類の例について、以下により詳細に説明する。
図14を参照すると、ブロック1470において、UE4は、UE1からスクリーンショット+を受信した後のある時点において、(たとえば、図7のブロック705と同様に)スクリーンショット+に関するアプリケーション固有メタデータに基づいてスクリーンショット+からアプリケーション2セッション状態をロードする要求を受信する。言い換えれば、UE4は、(ブロック1450〜1465に示すようにUE3とは対照的に)アプリケーション1セッション状態を再作成することを重要視しない。UE4は、スクリーンショット+に関する画像データを単にピクチャファイルとしてロードするのではなく、スクリーンショット+に示されるアプリケーション2セッション状態に関するアプリケーション固有メタデータを処理するのに適したアプリケーションがUE4上で利用可能であるかどうかを評価する。UE4は、新しいアプリケーションをインストールする必要があるか、または既存のアプリケーションを更新して、アプリケーション2セッション状態を再作成できるようにアプリケーション固有メタデータを処理する必要があると判定した場合、ブロック1475においてアプリケーションをインストールまたは更新する。ブロック1480において、アプリケーション(上述のようにアプリケーション固有メタデータに記載されたアプリケーション要件に応じてアプリケーション1またはアプリケーション1と同等のアプリケーション)が起動され、ブロック1485において、アプリケーションは、アプリケーション固有メタデータのそれぞれのアプリケーション2部分を処理して、スクリーンショット+からアプリケーション2セッション状態の特徴の一部または全部を再作成する。ブロック1485で行われる場合がある処理の種類の例について、以下により詳細に説明する。
図15Aは、本開示の一実施形態による、図14のプロセスの例示的な実行に基づくスクリーンショット+に関するアプリケーション固有メタデータ生成を示す図である。図15Aでは、図14におけるUE1は、ディスプレイスクリーン1510Aを含むコンピュータ1505Aとして示され、アプリケーション1は、ディスプレイスクリーン1510Aのウィンドウ1515Aに示されるワシントンDCペンシルベニア大通り1600を中心として表示されるGoogle Maps URLであるChromeウェブブラウザに対応し、アプリケーション2は、ディスプレイスクリーン1510Aのウィンドウ1520Aに示される、「ホワイトハウス」のGoogle Image Search URLにナビゲートされたChromeウェブブラウザの異なるインスタンスに対応する。たとえば、コンピュータ1505Aを操作するユーザが、ワシントンDCにあるホワイトハウスを見学する旅行について調べる場合がある。
ウィンドウ1520Aは、画像検索結果による1つの特定のサムネイルを中心として表示され、したがってこのサムネイルをアプリケーション2アプリケーション固有メタデータにおける関心対象として識別(またはタグ付け)することができる。したがって、ディスプレイスクリーン1510Aは、スクリーンショット+に関する画像データを表す。スクリーンショット+におけるモバイルGoogle Mapsアプリケーションのセッション状態を特徴付けるアプリケーション固有メタデータ1530(またはアプリケーションセッション状態メタデータ)の一例は次のような内容である。
アプリケーションID1: Google Maps
アドレス: ワシントンDCペンシルベニア大通り1600
アプリケーションID2: デフォルトウェブブラウザ
URI: 「ホワイトハウス写真」に関するGoogle Image Search
関心対象: タグ付けされたサムネイルにおけるホワイトハウス写真
上記で示したように、スクリーンショット+におけるアプリケーション2セッション状態に関するアプリケーション固有メタデータに関心対象フィールドを追加することができ、このフィールドは、まずアプリケーション2セッション状態に関するURIに指定されたホワイトハウス写真に関する画像検索結果にナビゲートすることによってアプリケーション2セッション状態を再作成させ、次いでスクリーンショット+内に示されるアプリケーション2セッション状態と同様に、得られるウェブページを(たとえば、オートスクロールダウンまたはズームインによって)タグ付けされたサムネイルからの特定のホワイトハウス写真を中心として表示させるように構成されてもよい。この例では、ホワイトハウスは、アプリケーション固有メタデータの一部として含められてもよいロケーション固有注目点(POI)情報の一例である。
図15Bは、本開示の一実施形態による、図14のプロセスの例示的な実行に基づく、図15Aに関して上記で説明したスクリーンショット+に関するアプリケーションセッション状態再作成手順を示す。図15Bでは、図14におけるUE3は、ディスプレイスクリーン1505Bを含むスマートフォン1500Bとして示され、図14におけるUE2は、ディスプレイスクリーン1515Bを含むコンピュータ1510B(たとえば、ラップトップコンピュータまたはデスクトップコンピュータなど)として示され、アプリケーション1および2は、図15Aに関して上記で説明したように構成される。
図15Bを参照すると、スマートフォン1500Bは、図15Aに関して上記で説明したようにアプリケーション固有メタデータ1525Aを受信する。スマートフォン1500Bは、(たとえば、図14のブロック1450と同様に)アプリケーション1セッション状態のみをロードする要求を受信する。したがって、スマートフォン1500Bは、アプリケーション固有メタデータ1525Aに基づいて、スマートフォン1500B上にすでにGoogle Mapsアプリケーション(たとえば、スマートフォン1500BがモバイルデバイスであるのでモバイルGoogle Mapsアプリケーション)がインストールされているかどうかをチェックする。スマートフォン1500B上にモバイルGoogle Mapsアプリケーションがインストールされていない場合、モバイルGoogle Mapsアプリケーションがダウンロードされインストールされる。モバイルGoogle Mapsアプリケーションは次いで、ワシントンDCペンシルベニア大通り1600をターゲットアドレスとして入力することによってアプリケーション固有メタデータ1525Aのアプリケーション1部分を処理し、それによってディスプレイスクリーン1505Bがホワイトハウスを中心として表示される。一例では、ホワイトハウスがディスプレイスクリーン1505B上に表示されるときのズーム情報(たとえば、特定の地理的境界、ズームのスケールなど)もアプリケーション固有メタデータ1525Aの一部として記録されることがあり、それによってスマートフォン1500BにおけるモバイルGoogle Mapsアプリケーションは、図15Aのウィンドウ1515A内のターゲットアドレスの表示に相応するターゲットズームレベルでターゲットアドレスをロードする場合がある。
図15Bを参照すると、コンピュータ1510Bは、図15Aに関して上記で説明したようにアプリケーション固有メタデータ1525Aを受信する。コンピュータ1510Bが、(たとえば、図14のブロック1430と同様に)アプリケーション1セッション状態とアプリケーション2セッション状態の両方をロードする要求を受信する。したがって、コンピュータ1510Bは、アプリケーション固有メタデータ1525Aに基づいて、アプリケーション1セッション状態の再作成に関して、コンピュータ1510B上にすでにGoogle Maps互換アプリケーションがインストールされているかどうかをチェックし、かつアプリケーション2セッション状態の再作成に関して、コンピュータ1510B上にすでにウェブブラウザがインストールされているかどうかをチェックする。この場合、コンピュータ1510Bが、Google Mapsウェブサイトにナビゲートするデフォルトウェブブラウザをアプリケーション1セッション状態の再作成に適切なGoogle Mapsアプリケーションと見なし、この同じウェブブラウザが、すでにアプリケーション2セッション状態を十分に再作成していると仮定する。
したがって、(たとえば、Chromeブラウザとして示される)デフォルトウェブブラウザは、アプリケーション固有メタデータ1525Aを処理して、ウィンドウ1520B内にアプリケーション1セッション状態を再作成し、ウィンドウ1525B内にアプリケーション2セッション状態を再作成する。詳細には、ウィンドウ1525Bは、アプリケーション固有メタデータ1525Aを処理して、関連するホワイトハウス画像結果を含む適切なウェブページをロードするだけでなく、ウェブページを関心対象(すなわち、図15Aに示されるスクリーンショット+のアプリケーション2ウィンドウからのタグ付けされたサムネイル)を中心として表示してもよい。一例では、図15Bには示されていないが、アプリケーション固有メタデータ1525Aは、ウィンドウ1520B〜1525Bの配置がそれぞれのディスプレイスクリーン内で図15Bの対応するウィンドウ1515Aおよび1520Aと揃うように、それぞれのウィンドウに関する相対スクリーン位置データを含むようにさらに構成されてもよい。
図16Aは、本開示の一実施形態によるスクリーンショット+に関するアプリケーション固有メタデータ生成を示す図である。図15Aと同様に、ディスプレイスクリーン1610Aを含むコンピュータ1605Aが示される。ディスプレイスクリーン1610Aは、ワシントンDCペンシルベニア大通り1600を中心とする、Google Maps URLに位置するChromeウェブブラウザを示すウィンドウ1615Aと、「ホワイトハウス」に関するGoogle Image Search URLにナビゲートされたChromeウェブブラウザの異なるインスタンスを示すウィンドウ1620Aとを含む。たとえば、コンピュータ1605Aを操作するユーザが、ワシントンDCにあるホワイトハウスを見学する旅行について調べる場合がある。
図15Aとは異なり、ブロック1625Aに示すように、ユーザは、ディスプレイスクリーン1610A内のスクリーンショット+をウィンドウ1615Aにのみ含まれる画像データに制限し、(ウィンドウ1620Aを含む)あらゆる外部画像データがスクリーンショット+から除外される。したがって、図16Aは、単一のアプリケーション(たとえば、ウィンドウ1615Aを生成するChromeウェブブラウザ)によって提供される画像データがスクリーンショット+内にキャプチャされるという意味で図9の例示的な実装形態を示す。Windows Osの具体例では、ユーザは、マウスによってウィンドウ1615A上を左クリックし、次いでキーボード上でALTキーとPrintscreenキーを同時に押すことによってウィンドウ固有スクリーンショットを開始することができる。代替として、ディスプレイスクリーン1610Aが、スクリーンショットをキャプチャしているUEの外部にあるスナップショットの例では、ユーザは、UEをディスプレイスクリーン1610Aのより近くに保持してもよく、またはウィンドウ1615Aにズームインして、ウィンドウ1620Aをキャプチャせずにウィンドウ1615Aをスクリーンショット+内にキャプチャしてもよい。
したがって、ウィンドウ1615Aは、スクリーンショット+に関する画像データを表し、スクリーンショット+におけるウェブブラウザのセッション状態を特徴付けるアプリケーション固有メタデータ1635A(またはアプリケーションセッション状態メタデータ)の例は次のような内容である。
アプリケーションID: Google Maps
アドレス: ワシントンDCペンシルベニア大通り1600
図16Bは、本開示の一実施形態による、図16Aに関して上記で説明したスクリーンショット+に関するアプリケーションセッション状態再作成手順を示す。図15Bと同様に、ディスプレイスクリーン1605Aを含むスマートフォン1600Bが、ディスプレイスクリーン1615Bを含むコンピュータ1610Bとともに示される。
図16Bを参照すると、スマートフォン1600Bは、図16Aに関して上記で説明したようにアプリケーション固有メタデータ1630Aを受信する。スマートフォン1600Bが、(たとえば、図9のブロック970またはブロック986と同様に)アプリケーション1セッション状態をロードする要求を受信すると仮定する。したがって、スマートフォン1600Bは、アプリケーション固有メタデータ1630Aに基づいて、スマートフォン1600B上にすでにGoogle Mapsアプリケーション(たとえば、スマートフォン1600BがモバイルデバイスであるのでモバイルGoogle Mapsアプリケーション)がインストールされているかどうかをチェックする。スマートフォン1600B上にモバイルGoogle Mapsアプリケーションがインストールされていない場合、モバイルGoogle Mapsアプリケーションがダウンロードされインストールされる。モバイルGoogle Mapsアプリケーションは次いで、ワシントンDCペンシルベニア大通り1600をターゲットアドレスとして入力することによってアプリケーション固有メタデータ1630Aを処理し、それによってディスプレイスクリーン1605Bがホワイトハウスを中心として表示される。一例では、ホワイトハウスがディスプレイスクリーン1605B上に表示されるときのズーム情報(たとえば、特定の地理的境界、ズームのスケールなど)もアプリケーション固有メタデータ1630Aの一部として記録されることがあり、それによってスマートフォン1600BにおけるモバイルGoogle Mapsアプリケーションは、図15Aのウィンドウ1615A内のターゲットアドレスの表示に相応するターゲットズームレベルにおいてターゲットアドレスをロードする場合がある。
図16Bを参照すると、コンピュータ1610Bは、図16Aに関して上記で説明したようにアプリケーション固有メタデータ1630Aを受信する。コンピュータ1610Bが、(たとえば、図9のブロック970またはブロック986と同様に)アプリケーション1セッション状態をロードする要求を受信すると仮定する。したがって、コンピュータ1610Bは、アプリケーション固有メタデータ1630Aに基づいて、アプリケーション1セッション状態の再作成に関して、コンピュータ1610B上にすでにGoogle Maps互換アプリケーションがインストールされているかどうかをチェックする。この場合、コンピュータ1610Bが、Google Mapsウェブサイトにナビゲートするデフォルトウェブブラウザをアプリケーション1セッション状態の再作成に適切なGoogle Mapsアプリケーションと見なすと仮定する。したがって、(たとえば、Chromeブラウザとして示される)デフォルトウェブブラウザは、アプリケーション固有メタデータ1630Aを処理して、ウィンドウ1620B内にアプリケーション1セッション状態を再作成する。
スクリーンショットキャプチャに関連して取得することができ、アプリケーションセッション状態の特徴の一部または全部を再作成するために使用できるアプリケーション固有メタデータの例について図10〜図13および図15A〜図16Bに関して上記で説明したが、これらは例示のみを意図するものであり、限定を意図するものではない。アプリケーションセッション状態を再作成するために使用できるアプリケーション固有メタデータのいくつかの追加の例は次のような内容である。
Table 1は、アプリケーションセッション状態メタデータの列にデータの様々な組合せを示しているが、各データ要素が任意の組合せに(まとめてまたは別々に)配置されてもよいことが了解されよう。たとえば、Table 1の実施例#6におけるURIは、様々な製品関連URIパラメータをリスト表示している。これらの同じURIパラメータは、他のコンテキストでは、ウェブブラウザを全般的に検索する(たとえば、Google検索など)か、またはサイト固有検索(たとえば、Amazon.comなど)を実行することによって、変更されたURLを有する製品(または他の種類のウェブページ)を見つけるために使用することができる。たとえば、Table 1の実施例#1または#2におけるビデオコールに製品が示される場合、その製品に関連する製品関連URIパラメータがアプリケーション固有メタデータに付加されてもよい。別の例では、製品がTable 1の実施例#5における歌詞に関連付けられる(たとえば、ジミーバフェットの「マルガリータヴィル」がトロピカルなアルコール飲料に関連付けられる)場合、その製品に関連する製品関連URIパラメータがアプリケーション固有メタデータなどに付加されてもよい。
当業者は、情報および信号が、様々な異なる技術および技法のいずれかを使用して表されてもよいことを理解するであろう。たとえば、上記の説明全体にわたって言及されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表されることがある。
さらに、本明細書で開示される実施形態に関して説明される様々な例証的な論理ブロック、モジュール、回路、およびアルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装されてもよいことを、当業者は了解するであろう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、上では、様々な例証的なコンポーネント、ブロック、モジュール、回路、およびステップが、全般的にそれらの機能の観点から説明された。そのような機能が、ハードウェアとして実現されるか、またはソフトウェアとして実現されるかは、具体的な適用例と、システム全体に課される設計制約とによって決まる。当業者は説明された機能を具体的な適用例ごとに様々な方法で実装してもよいが、そのような実装の決定は、本開示の範囲からの逸脱を引き起こすものと解釈されるべきでない。
本明細書において開示された実施形態に関して説明した様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、DSP、ASIC、FPGA、または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェアコンポーネント、または本明細書で説明した機能を実行するように設計されたそれらの任意の組合せで、実装または実行されてもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえばDSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成、として実装されてもよい。
本明細書において開示される実施形態に関して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアにおいて直接具現化されることもまた、プロセッサによって実行されるソフトウェアモジュールにおいて具現化されることもまた、または2つの組合せにおいて具現化されることもある。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野において知られている任意の他の形の記憶媒体内に存在してもよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取ること、および記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体は、プロセッサと一体化してもよい。プロセッサおよび記憶媒体は、ASICの中に存在する場合がある。ASICはユーザ端末(たとえば、UE)の中に存在してもよい。代替として、プロセッサおよび記憶媒体は、個別コンポーネントとしてユーザ端末内に存在する場合がある。
1つまたは複数の例示的な実施形態では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装されてもよい。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されてもよく、またはコンピュータ可読媒体を介して送信されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体と、ある場所から別の場所へのコンピュータプログラムの移転を容易にする任意の媒体を含む通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされることがある任意の利用可能な媒体であってもよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶デバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用できるとともにコンピュータによってアクセスできる任意の他の媒体を含むことができる。また、いかなる接続もまた、厳密にはコンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標) (disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
上記の開示は本開示の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本開示の範囲から逸脱することなく本明細書において様々な変更および修正が行われてもよいことに留意されたい。本明細書で説明した本開示の実施形態による方法クレームの機能、ステップおよび/またはアクションは、任意の特定の順序で実行される必要はない。さらに、本開示の要素は、単数形で説明または特許請求がなされることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。