JP6949917B2 - 通話中のテレビ会議の確立 - Google Patents

Description

スマートフォンなどの今日の携帯デバイスの多くは、ビデオ取り込み機能を提供する。携帯デバイスのユーザは、電話機のカメラを通じて静止画像及びビデオの両方を取り込むことができる。しかし、取り込まれたビデオを別の当事者に伝送するために、ユーザは一般に、ビデオの取り込みが完了した後に、そのビデオを別の当事者に直接送信するか、又はそのビデオを別の場所（例えば、インターネットのビデオホストサイト）にアップロードしなければならない。残念なことに、このようにしても、携帯デバイスによってビデオを取り込みつつ、他の当事者がライブビデオストリームを視聴することはできない。

さらに、標準的な携帯デバイスは、１つのカメラしか装備しておらず、この１つのカメラからの情報を処理することはかなり困難である。理想的なデバイスは、複数のカメラを有し、少なくとも２つのカメラからのビデオの合成であるライブビデオを送信できるだろう。これは、携帯デバイスが使用可能なリソースが限られていることを考慮すると、デバイスが複数の取り込まれたビデオストリームを処理すること、及びデバイスが接続されるネットワークがライブビデオストリームの伝送を扱うことの両方の観点から、特に困難な問題である。

本発明の一部の実施形態は、写真及びビデオを撮影可能な２つのカメラを有する携帯デバイスを提供する。一部の実施形態の携帯デバイスは、取り込まれた写真画像及びビデオ画像を表示するための表示画面を有する。この携帯デバイスは、取り込まれた画像を後で別のデバイスに伝送する目的で格納するための記憶装置も含む。このデバイスは、デバイスのユーザ間でのリアルタイム通信セッション中に、取り込まれた画像を１つ以上のデバイスに伝送可能なネットワークインタフェースをさらに有する。このデバイスは、取り込まれた画像をローカルに格納するか又は別のデバイスに伝送する目的で符号化するために使用できるエンコーダも含む。この携帯デバイスは、リアルタイム通信セッション中に別のデバイスによって取り込まれた画像を復号すること又はローカルに格納された画像を復号することをデバイスに可能するデコーダをさらに含む。

取り込まれたビデオ画像の伝送を含むリアルタイム通信セッションの一例がテレビ会議である。一部の実施形態では、携帯デバイスは、テレビ会議中の任意の所与の時間に１つのカメラの取り込まれたビデオ画像のみを伝送できる。しかし、他の実施形態では、携帯デバイスは、テレビ会議又は他のリアルタイム通信セッション中にそのカメラの両方からの取り込まれたビデオ画像を同時に伝送できる。

別のデバイスとのテレビ会議中に、一部の実施形態の携帯デバイスは、そのカメラの一方又は両方によって取り込まれたビデオと共に他のタイプのコンテンツを伝送できる。このような他のコンテンツの一例は、デバイスの他のカメラがテレビ会議で使用されるビデオを取り込みながら、デバイスのカメラのうちの１つによって取り込まれた低解像度又は高解像度の写真画像を含む。このような他のコンテンツの他の例は、（１）デバイスに格納されたファイル及び他のコンテンツ、（２）デバイスの画面表示（すなわち、デバイスの画面に表示されるコンテンツ）、（３）テレビ会議又は他のリアルタイム通信セッション中に別のデバイスから受信されたコンテンツなどがある。

一部の実施形態の携帯デバイスは、テレビ会議中に調整を行うための新規な会議中調整技術を採用する。例えば、一部の実施形態の携帯デバイスは、テレビ会議中に１つのカメラの取り込まれたビデオのみを伝送しながら、それの他のカメラによって取り込まれたビデオを伝送するために動的に切り換えることができる。このような状況では、一部の実施形態の携帯デバイスは、この他のデバイスが、２つのカメラによって取り込まれたビデオの間でのスムーズな移行をこのデバイス側で実現できるように、テレビ会議に参加している他の任意のデバイスにこの切り換えを通知する。

一部の実施形態では、カメラ切り換え要求は、テレビ会議中にそのカメラを切り換える「ローカル」デバイスに由来しうるだけでなく、ローカルデバイスによって取り込まれたビデオを受信している他の「リモート」デバイスからも由来しうる。さらに、１つのデバイスが別のデバイスにカメラを切り換えるように指示できることは、一部の実施形態のデバイスの遠隔制御機能の一例にすぎない。一部の実施形態においてデバイスにリモートから指示できる他の動作の例は、露出調整動作（例えば、自動露出）、焦点調整動作（例えば、オートフォーカス）などを含む。ローカル又はリモートから指定可能な新規な会議中調整の別の例は、取り込まれたビデオ内の関心領域（ＲＯＩ）の指定であり、このＲＯＩ識別の使用目的は、取り込んでいるカメラの挙動を変更すること、取り込んでいるカメラを有するデバイスの画像処理動作を変更すること、又は取り込んでいるカメラを有するデバイスの符号化動作を変更することである。

一部の実施形態の新規な会議中調整のさらに別の例は、デバイスによって生成される合成ビデオ表示のリアルタイム変更を含む。具体的には、一部の実施形態では、携帯デバイスは、１つ以上のデバイスの複数のカメラによって取り込まれた複数のビデオを同時に表示する合成表示を生成する。一部の場合では、合成表示は、隣接する表示域（例えば、隣接するウィンドウ）にビデオを置く。他の場合では、合成表示は、２つの異なるビデオを示す少なくとも２つの表示域を含むピクチャインピクチャ（ＰＩＰ）表示であり、表示域の一方は背景メイン表示域であり、他方は背景メイン表示域に重なる前景挿入表示域である。

一部の実施形態では、合成ビデオ表示のリアルタイム変更は、ユーザの選択及び表示域の移動に応答して合成表示内で表示域のうちの１つ以上を移動することを含む。また、一部の実施形態は、この合成表示を提供したデバイスの画面が回転する場合に、テレビ会議中に合成表示を回転する。また、一部の実施形態の携帯デバイスにより、デバイスのユーザは、ＰＩＰ表示内のビデオを入れ換えること（すなわち、背景メイン表示のビデオを前景挿入表示に表示するとともに、前景挿入表示のビデオを背景メイン表示に表示すること）が可能である。

上記の発明の概要は、本発明の一部の実施形態の簡単な説明として役立つことを意図したものである。これは、本明細書に開示されているすべての発明の主題の説明又は概説を意味しない。以下の発明を実施するための形態及び発明を実施するための形態で参照される図面において、発明の概要で説明した実施形態だけでなく他の実施形態をさらに説明する。したがって、本明細書によって説明されるすべての実施形態を理解するために、発明の概要、発明を実施するための形態及び図面の十分な検討が必要である。

添付の特許請求の範囲に、本発明の新規な特徴を記載する。しかし、説明の目的で、本発明の一部の実施形態を以下の図に示す。

一部の実施形態の合成表示を示す図である。 一部の実施形態の別の合成表示を示す図である。 一部の実施形態のデュアルカメラ携帯デバイスのビデオ処理及び符号化モジュールのためのソフトウェアアーキテクチャを概念的に示す図である。 一部の実施形態の取り込み済画像処理ユニットを概念的に示す図である。 異なる垂直帰線消去期間（ＶＢＩ）に基づいた異なるフレームレートの例を概念的に示す図である。 異なるＶＢＩに基づいた異なるインタリーブフレームレートの例を概念的に示す図である。 一部の実施形態の別の取り込み済画像処理ユニットを概念的に示す図である。 一部の実施形態の別の取り込み済画像処理ユニットを概念的に示す図である。 一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュールのためのソフトウェアアーキテクチャを概念的に示す図である。 一部の実施形態の例示的なテレビ会議要求メッセージシーケンスを概念的に示す図である。 テレビ会議セットアップ動作のための一部の実施形態のユーザインタフェースを示す図である。 テレビ会議への招待に応じるための一部の実施形態のユーザインタフェースを示す図である。 テレビ会議への招待に応じるための一部の実施形態の別のユーザインタフェースを示す図である。 テレビ会議セットアップ動作のための一部の実施形態の別のユーザインタフェースを示す図である。 テレビ会議のビットレートを設定するための一部の実施形態のプロセスを概念的に示す図である。 一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュールのための別のソフトウェアアーキテクチャを概念的に示す図である。 一部の実施形態のデュアルカメラ携帯デバイスのための別のソフトウェアアーキテクチャを概念的に示す図である。 図１６に示されるプロセスなどの、一部の実施形態のテレビ会議マネージャによって実行されるプロセスを概念的に示す図である。 一部の実施形態の時間ノイズ低減モジュールのためのソフトウェアアーキテクチャを概念的に示す図である。 ビデオの画像のノイズを低減させるための一部の実施形態のプロセスを概念的に示す図である。 図９に示されるプロセスなどの、一部の実施形態の画像処理マネージャによって実行されるプロセスを概念的に示す図である。 露出調整動作のための一部の実施形態のユーザインタフェースを示す図である。 焦点調整動作のための一部の実施形態のユーザインタフェースを示す図である。 図１６に示されるプロセスなどの、一部の実施形態の画像処理マネージャによって実行されるパースペクティブ補正プロセスを概念的に示す図である。 一部の実施形態の例示的なパースペクティブ補正動作を概念的に示す図である。 図１６に示されるソフトウェアアーキテクチャなどの、一部の実施形態のエンコーダドライバのためのソフトウェアアーキテクチャを概念的に示す図である。 図２６に示されるエンコーダなどの、一部の実施形態のエンコーダドライバによって実行される画像サイズ変更プロセスを概念的に示す図である。 図１６に示されるソフトウェアアーキテクチャなどの、一部の実施形態のデコーダドライバのためのソフトウェアアーキテクチャを概念的に示す図である。 図２８に示されるデコーダドライバなどの、一部の実施形態のデコーダドライバによって実行される画像抽出プロセスを概念的に示す図である。 ２つのレートコントローラを含む一部の実施形態のエンコーダドライバを示す図である。 図１６に示されるネットワークキングマネージャなどの一部の実施形態のネットワーキングマネージャのためのソフトウェアアーキテクチャを概念的に示す図である。 コーナー向けスナップ（snap-to-corner）動作のための一部の実施形態のユーザインタフェースを示す図である。 コーナー向けスナップ動作のための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示の前景挿入表示域をサイズ変更するための一部の実施形態のユーザインタフェースを示す図である。 ＰＩＰ表示の挿入表示域をサイズ変更するための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示の挿入表示域をサイズ変更するための一部の実施形態の別のユーザインタフェースを示す図である。 ＰＩＰ表示の挿入表示域をサイズ変更するための一部の実施形態の別のユーザインタフェースを示す図である。 表示における関心領域を識別するための一部の実施形態のユーザインタフェースを示す図である。 表示における関心領域を識別するための一部の実施形態の別のユーザインタフェースを示す図である。 表示における関心領域を識別するための一部の実施形態の別のユーザインタフェースを示す図である。 デュアルカメラ携帯デバイス上のローカルカメラ切り換え動作を実行するための一部の実施形態のプロセスを示す図である。 カメラ切り換え動作のための一部の実施形態のユーザインタフェースを示す図である。 カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 デュアルカメラ携帯デバイス上のリモートカメラ切り換え動作を実行するための一部の実施形態のプロセスを示す図である。 遠隔制御カメラ切り換え動作のための一部の実施形態のユーザインタフェースを示す図である。 遠隔制御カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 遠隔制御カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 遠隔制御カメラ切り換え動作のための一部の実施形態の別のユーザインタフェースを示す図である。 露出調整動作を実行するための一部の実施形態のプロセスを概念的に示す図である。 露出調整動作のための一部の実施形態のユーザインタフェースを示す図である。 露出調整動作のための一部の実施形態の別のユーザインタフェースを示す図である。 露出調整動作のための一部の実施形態の別のユーザインタフェースを示す図である。 図１６に示されるプロセスなどの、一部の実施形態の画像処理マネージャによって実行される露出調整プロセスを概念的に示す図である。 一部の実施形態の例示的な露出調整動作を概念的に示す図である。 焦点調整動作を実行するための一部の実施形態のプロセスを概念的に示す図である。 焦点調整動作のための一部の実施形態のユーザインタフェースを示す図である。 焦点調整動作のための一部の実施形態の別のユーザインタフェースを示す図である。 焦点調整動作のための一部の実施形態の別のユーザインタフェースを示す図である。 １つ以上のデュアルカメラ携帯デバイスから取り込まれたビデオのための一部の実施形態の異なる表示構成を示す図である。 ＰＩＰ表示において挿入ビデオの前景を背景ビデオに重畳するための一部の実施形態のユーザインタフェースを示す図である。 ビデオ画像の前景を決定するための一部の実施形態の技術を示す図である。 テレビ会議中にＰＩＰ表示の挿入表示を背景表示と交換するための一部の実施形態のユーザインタフェースを示す図である。 コーナー向けスナップ動作のための一部の実施形態のユーザインタフェースを示す図である。 コーナー向けスナップ及びプッシュ動作のための一部の実施形態のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態のユーザインタフェースを示す図である。 ＰＩＰ表示回転動作のための一部の実施形態の別のユーザインタフェースを示す図である。 テレビ会議中に２つのリモートビデオから１つのビデオを選択するための一部の実施形態のユーザインタフェースを示す図である。 テレビ会議中に２つのローカルビデオから１つのビデオを選択するための一部の実施形態のユーザインタフェースを示す図である。 テレビ会議に使用するべきビデオの会議前の選択のための一部の実施形態のユーザインタフェースを示す図である。 一部の実施形態のデュアルカメラ携帯デバイスによって取り込まれた２つのビデオ間の帯域幅割り当ての例を示す図である。 デュアルカメラ携帯デバイスのレートコントローラを管理するための一部の実施形態のアービトレータモジュールを概念的に示す図である。 デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を符号化するための一部の実施形態の方法を概念的に示す図である。 デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を符号化するための一部の実施形態の別の方法を概念的に示す図である。 図７９に示される方法のための例示的な画像合成を示す図である。 デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を符号化するための一部の実施形態の別の方法を概念的に示す図である。 デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を復号するための一部の実施形態の方法を概念的に示す図である。 デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を復号するための一部の実施形態の別の方法を概念的に示す図である。 一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュールのための別のソフトウェアアーキテクチャを概念的に示す図である。 複数参加者によるテレビ会議のための一部の実施形態のユーザインタフェースを示す図である。 複数参加者によるテレビ会議のための一部の実施形態の別のユーザインタフェースを示す図である。 複数参加者によるテレビ会議のための一部の実施形態の別のユーザインタフェースを示す図である。 一部の実施形態のアプリケーションプログラミングインタフェース（ＡＰＩ）アーキテクチャを概念的に示す図である。 一部の実施形態のデュアルカメラモバイルコンピューティングデバイスのためのアーキテクチャを示す図である。 一部の実施形態のタッチ入出力（Ｉ／Ｏ）デバイスを概念的に示す図である。 一部の実施形態の例示的な通信システムを概念的に示す図である。 一部の実施形態の別の例示的な通信システムを概念的に示す図である。

以下の説明で、多くの詳細が説明のために記載されている。しかし、本発明はこれらの特定の詳細を使用せずに実施されてもよいことが当業者に理解されよう。他の例では、不必要な詳細により本発明の説明をあいまいにしないように、よく知られている構造及びデバイスがブロック図の形式で示される。

本発明の一部の実施形態は、写真及びビデオを撮影可能な２つのカメラを有する携帯デバイスを提供する。携帯デバイスの例としては、携帯電話機、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップ、タブレットパーソナルコンピュータ、又は他の任意のタイプのモバイルコンピューティングデバイスがある。本明細書では、写真とは、単一写真モードで一度に１枚、又は高速実行（fast-action）モードで一度に複数枚、カメラで撮影された静止写真画像を指す。一方、ビデオとは、特定の速度でカメラによって取り込まれた一連のビデオ画像を指し、この速度は、フレームレートと呼ばれることが多い。ビデオを取り込む典型的なフレームレートは、２５フレーム／秒（ｆｐｓ）、３０ｆｐｓ及び６０ｆｐｓである。一部の実施形態の携帯デバイスのカメラは、これら及び他のフレームレートでビデオ画像（すなわち、ビデオフレーム）を取り込むことができる。

一部の実施形態の携帯デバイスは、（１）取り込まれた写真画像及びビデオ画像を表示でき、（２）取り込まれた画像を後で別のデバイスに伝送するために記憶でき、（３）デバイスのユーザ間でのリアルタイム通信セッション中に、取り込まれた画像を１つ以上のデバイスに伝送でき、（４）取り込まれた画像をローカルに格納するために又は別のデバイスに伝送するために符号化できる。

取り込まれたビデオ画像の伝送を伴うリアルタイム通信セッションの一例がテレビ会議である。一部の実施形態では、携帯デバイスは、テレビ会議中の任意の所与の時刻に１つのカメラの取り込まれたビデオ画像のみを伝送できる。しかし、他の実施形態では、携帯デバイスは、テレビ会議中又は他のリアルタイム通信セッション中にそのカメラの両方から取り込まれたビデオ画像を同時に伝送できる。

一部の実施形態の携帯デバイスは、１つ以上のデバイスの複数のカメラによって取り込まれた複数のビデオの同時表示を含む合成表示を生成する。いくつかの場合に、合成表示は、隣接する表示域（例えば、隣接するウィンドウ）にビデオを置く。図１は、１つのデバイスの２つのカメラによって取り込まれた又はテレビ会議中の２つの異なるデバイスの２つのカメラによって取り込まれた、２つのビデオを同時に表示する２つの隣接する表示域１０５及び１１０を含む合成表示１００のこのような一例を示す。

他の場合に、合成表示は、２つの異なるビデオを示す少なくとも２つの表示域を含むＰＩＰ表示であり、表示域の一方は背景メイン表示域であり、他方は、背景メイン表示域に重なる前景挿入表示域である。図２は、合成ＰＩＰ表示２００のこのような一例を示す。この合成ＰＩＰ表示２００は、背景メイン表示域２０５と、背景メイン表示域に重なる前景挿入表示域２１０とを含む。２つの表示域２０５及び２１０は、１つのデバイスの２つのカメラによって取り込まれた又はテレビ会議中の２つの異なるデバイスの２つのカメラによって取り込まれた、２つのビデオを同時に表示する。本明細書において図示し説明する例示的な合成ＰＩＰ表示は、背景メイン表示域２０５の内部に前景挿入表示域２１０全体が表示される合成ＰＩＰ表示２００と同様であるが、背景メイン表示域２０５と重なるが完全にその内部にあるわけではない前景挿入表示域２１０を有する他の合成ＰＩＰ表示が可能である。

別のデバイスとのテレビ会議中にビデオコンテンツを伝送することに加えて、一部の実施形態の携帯デバイスは、会議のビデオコンテンツと共に他のタイプのコンテンツを伝送できる。このような他のコンテンツの一例として、デバイスの他のカメラがテレビ会議で使用されるビデオを取り込んでいる間に、デバイスのカメラのうちの１つによって取り込まれた低解像度又は高解像度の写真画像がある。このような他のコンテンツの他の例として、（１）デバイスに格納されたファイル及び他のコンテンツ、（２）デバイスの画面表示（すなわち、デバイスの画面に表示されるコンテンツ）、（３）テレビ会議又は他のリアルタイム通信セッション中に別のデバイスから受信されたコンテンツなどがある。

一部の実施形態の携帯デバイスは、テレビ会議中に調整を行うための新規な会議中調整技術を用いる。例えば、一部の実施形態の携帯デバイスは、テレビ会議中に１つのカメラの取り込まれたビデオのみを伝送しながら、その他のカメラによって取り込まれたビデオを伝送するために動的に切り換えることができる。このような状況で、一部の実施形態の携帯デバイスは、テレビ会議に参加している他の任意のデバイスにこの切り換えを通知し、その結果、この他のデバイスは、２つのカメラによって取り込まれたビデオの間でのスムーズな移行を、このデバイス側で実現できる。

一部の実施形態では、カメラ切り換え要求は、テレビ会議中にそのカメラを切り換える「ローカル」デバイスで発生しうるだけでなく、ローカルデバイスによって取り込まれたビデオを受信している他の「リモート」デバイスからも発生しうる。さらに、１つのデバイスが、別のデバイスにカメラを切り換えるように指示できることは、一部の実施形態のデバイスの遠隔制御機能の一例にすぎない。一部の実施形態においてデバイスにリモートから指示できる他の動作の例として、露出調整動作（例えば、自動露出）、焦点調整動作（例えば、オートフォーカス）などがある。ローカル又はリモートから指定可能な新規な会議中調整の別の例は、取り込まれたビデオ内の関心領域（ＲＯＩ）の識別であり、このＲＯＩ識別の使用目的は、取り込んでいるカメラの挙動を変更すること、取り込んでいるカメラを有するデバイスの画像処理動作を変更すること、又は取り込んでいるカメラを有するデバイスの符号化動作を変更することである。

一部の実施形態の新規な会議中調整のさらに別の例は、デバイスによって生成される合成ビデオ表示のリアルタイム変更を伴う。具体的には、一部の実施形態では、合成ビデオ表示のリアルタイム変更は、ユーザの選択及び表示域の移動に応答して合成表示内で表示域のうちの１つ以上を移動させることを伴う。また、一部の実施形態では、この合成表示を提供したデバイスの画面が回転する場合に、テレビ会議中に合成表示を回転する。また、一部の実施形態の携帯デバイスにより、デバイスのユーザは、ＰＩＰ表示内のビデオの順序を反転させること（すなわち、背景メイン表示のビデオを前景挿入表示に表示させつつ、前景挿入表示のビデオを背景メイン表示に表示させること）が可能である。

いくつかのより詳細な実施形態が以下で説明される。セクションＩで、一部の実施形態のビデオ処理アーキテクチャの説明を提供する。その後、セクションＩＩで、一部の実施形態の取り込み済画像処理ユニットについて説明する。一部の実施形態では、このユニットは、デバイスのカメラによって取り込まれたＲＡＷ画像の処理を担当するデバイスのコンポーネントである。

次に、セクションＩＩＩで、一部の実施形態のテレビ会議アーキテクチャについて説明する。このセクションで、一部の実施形態のテレビ会議モジュールだけでなく単一カメラによるテレビ会議をセットアップするためのいくつかの方式についても説明する。その後、セクションＩＶで、一部の実施形態の会議中調整及び制御動作について説明する。その後、セクションＶで、テレビ会議中に個々のデバイスから複数のビデオを伝送及び表示する実施形態のテレビ会議機能について説明する。次に、セクションＶＩにおいて、テレビ会議中の非リアルタイムコンテンツと共にリアルタイムビデオを伝送することについて説明する。最後に、セクションＶＩＩで、一部の実施形態のデュアルカメラデバイスのハードウェアアーキテクチャについて説明する。

Ｉ．ビデオの取り込み及び処理
図３は、一部の実施形態のデュアルカメラ携帯デバイスのビデオ処理及び符号化モジュール３００を概念的に示す。一部の実施形態では、モジュール３００は、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を処理し、同じくデュアルカメラ携帯デバイスのカメラによって取り込まれたビデオを符号化する。図３に示すように、このモジュール３００は、取り込み済画像処理ユニット（ＣＩＰＵ）ドライバ３０５と、メディア交換モジュール３１０と、エンコーダドライバ３２０と、ビデオ処理モジュール３２５とを含む。

一部の実施形態では、メディア交換モジュール３１０によって、メディアコンテンツの消費者兼製作者であるデバイス上のプログラムが、メディアコンテンツ及びそのメディアコンテンツの処理に関する命令を交換できる。ビデオ処理及び符号化モジュール３００では、一部の実施形態のメディア交換モジュール３１０は、ビデオ処理モジュール３２５とＣＩＰＵドライバ３０５の間、及びビデオ処理モジュール３２５とエンコーダドライバ３２０の間で、命令及びメディアコンテンツを経路制御する。このような命令及びメディアコンテンツのルーティングを容易にするため、一部の実施形態のメディア交換モジュール３１０は、メディアコンテンツの消費者及び製作者が使用するアプリケーションプログラミングインタフェース（ＡＰＩ）の集合を提供する。このような実施形態のうちのいくつかでは、メディア交換モジュール３１０は、デュアルカメラ携帯デバイスで動作するオペレーティングシステムの一部である１つ以上のフレームワークの集合である。このようなメディア交換モジュール３１０の一例は、Ａｐｐｌｅ Ｉｎｃによって提供されるＣｏｒｅ Ｍｅｄｉａフレームワークである。

ビデオ処理モジュール３２５は、デバイスのカメラによって取り込まれた画像及び／又はビデオに対して画像処理を実行する。このような動作の例として、露出調整動作、焦点調整動作、パースペクティブ補正、ダイナミックレンジ調整、画像サイズ変更、画像合成などがある。一部の実施形態では、いくつかの画像処理動作は、メディア交換モジュール３１０によって実行されることもできる。例えば、図３に示すように、一部の実施形態のメディア交換モジュール３１０は、デバイスのカメラによって取り込まれたビデオ画像のノイズを低減する時間ノイズ低減（ＴＮＲ）動作を（例えば、ＴＮＲ３１５によって）実行する。ビデオ処理モジュール３２５及びメディア交換モジュール３１０のこのような画像処理動作のさらなる例について、以下に提供する。

上述のように、ビデオ処理モジュール３２５は、メディア交換モジュール３１０を通じて、ＣＩＰＵドライバ３０５及びエンコーダドライバ３２０とやり取りする。ＣＩＰＵドライバ３０５は、取り込み済画像処理ユニット（ＣＩＰＵ）３３０とメディア交換モジュール３１０の間の通信インタフェースとして機能する。以下でさらに説明するように、ＣＩＰＵ３３０は、デバイスのカメラの画像取り込み動作又はビデオ取り込み動作中に取り込まれた画像の処理を担当するデュアルカメラデバイスのコンポーネントである。ＣＩＰＵドライバ３０５は、ビデオ処理モジュール３２５からメディア交換モジュール３１０を通じて、デバイスのカメラの一方又は両方からの画像及び／又はビデオの要求を受け取る。ＣＩＰＵドライバ３０５は、このような要求をＣＩＰＵ３３０に中継し、それに応答して、要求された画像及び／又はビデオをＣＩＰＵ３３０から受け取り、ＣＩＰＵドライバ３０５はその後、この画像及び／又はビデオを、メディア交換モジュール３１０を通じてビデオ処理モジュール３２５に送る。一部の実施形態のビデオ処理モジュール３２５はまた、ＣＩＰＵドライバ３０５及びメディア交換モジュール３１０を通じて、自身の動作のうちの一部を変更する（例えば、カメラのフレームレート、露出調整動作、焦点調整動作などを変更する）ために、命令をＣＩＰＵ３３０に送る。

エンコーダドライバ３２０は、メディア交換モジュール３１０とエンコーダハードウェア３３５の間の通信インタフェース（例えば、エンコーダチップ、システムオンチップ上の符号化コンポーネントなど）として機能する。一部の実施形態では、エンコーダドライバ３２０は、ビデオ処理モジュール３２５からメディア交換モジュール３１０を通じて、画像及びこの画像を符号化する要求を受け取る。エンコーダドライバ３２０は、符号化されるべき画像をエンコーダ３３５に送り、その後エンコーダ３３５は、ピクチャ符号化又はビデオ符号化を画像に対して実行する。エンコーダドライバ３２０がエンコーダ３３５から符号化された画像を受け取る場合に、エンコーダドライバ３２０は、この符号化された画像を、メディア交換モジュール３１０を通じてビデオ処理モジュール３２５に送り返す。

一部の実施形態では、ビデオ処理モジュール３２５は、エンコーダから受け取った符号化された画像に対してさまざまな動作を実行できる。このような動作の例として、符号化された画像のデバイスの記憶装置への格納、デバイスのネットワークインタフェースを通じたテレビ会議中の符号化された画像の伝送などがある。

一部の実施形態では、ビデオ処理及び符号化モジュール３００のモジュールの一部又は全部がオペレーティングシステムの一部として実装される。例えば、一部の実施形態では、このモジュール３００の４つのコンポーネント３０５、３１０、３２０及び３２５のすべてがデバイスのオペレーティングシステムの一部として実装される。他の実施形態では、メディア交換モジュール３１０、ＣＩＰＵドライバ３０５及びエンコーダドライバ３２０がデバイスのオペレーティングシステムの一部として実装され、ビデオ処理モジュール３２５はオペレーティングシステム上で実行されるアプリケーションとして有する。さらに、モジュール３００の他の実装が可能である。

ビデオ取り込みセッション中のビデオ処理及び符号化モジュール３００の動作について以下に説明する。ビデオ取り込みセッションを開始するために、ビデオ処理モジュール３２５は、ビデオ取り込みセッションに必要ないくつかのコンポーネントを初期化する。一部の実施形態では、これらのコンポーネントとして、（１）ＣＩＰＵ３３０、（２）ビデオ処理モジュール３２５の拡大縮小及び合成モジュール（不図示）、（３）ビデオ処理モジュール３２５の画像処理モジュール（不図示）及び（４）エンコーダ３３５を含む。また、一部の実施形態のビデオ処理モジュール３２５は、テレビ会議に参加する際に、ネットワークマネージャ（不図示）を初期化する。

ビデオ処理モジュールは、デバイスのカメラの一方又は両方にビデオ取り込みを開始させるために、メディア交換モジュール３１０及びＣＩＰＵドライバ３０５を通じて、その初期化要求をＣＩＰＵ３３０に送る。一部の実施形態では、この要求は、ビデオを取り込む必要がある各カメラに対する、特定のフレームレート、露出レベル及び拡大縮小サイズを指定する。この要求に応答して、ＣＩＰＵ３３０は、要求されたカメラからのビデオ画像を、指定されたレート（群）、露出レベル（群）及び拡大縮小サイズ（群）で戻し始める。これらのビデオ画像は、ＣＩＰＵドライバ３０５及びメディア交換モジュール３１０を通じてビデオ処理モジュール３２５に戻され、メディア交換モジュール３１０は、上述のように、ビデオ画像にＴＮＲ動作を実行してからビデオ処理モジュール３２５に供給する。ビデオ処理モジュール３２５で、ビデオ画像は、さらなる画像処理のためにバッファ（不図示）に格納される。

ビデオ処理モジュール３２５の画像処理モジュールは、さらなるビデオ処理のためにバッファに格納されたビデオ画像を読み出す。拡大縮小及び合成モジュールは、その後、デバイスの表示画面でのリアルタイム表示に必要ならば拡大縮小するために、処理されたビデオ画像を読み出す。一部の実施形態では、このモジュールは、デバイス上での取り込まれたビデオ画像のリアルタイム表示を提供するため又は符号化のために合成ビデオ画像を作成するために、テレビ会議中に別のデバイスのカメラ（群）と共にデバイスの２つのカメラによって取り込まれた画像から又はデバイスのカメラ（群）によって取り込まれた画像から合成画像を作成する。

処理された及び／又は合成されたビデオ画像は、エンコーダドライバ３２０及びメディア交換モジュール３１０を通じてエンコーダ３３５に供給される。その後、エンコーダ３３５は、そのビデオ画像を符号化する。その後、符号化された画像は、デバイスでの格納又はテレビ会議中の伝送のために、（やはりエンコーダドライバ３２０及びメディア交換モジュール３１０を通じて）ビデオ処理モジュール３２５に戻される。デバイスがテレビ会議に参加している場合に、（ビデオ処理モジュール３２５によって初期化された）ネットワークマネージャは、その後、これらの符号化された画像を読み出し、これらの画像をパケット化してデバイスのネットワークインタフェース（不図示）を通じて１つ以上の他のデバイスに伝送する。

ＩＩ．取り込まれた画像の処理
Ａ．単一のパイプライン
一部の実施形態のデュアルカメラ携帯デバイスのカメラによって取り込まれた画像は、処理されていないＲＡＷ画像である。これらの画像は、（例えば、テレビ会議中の）別のデバイスへの画像の伝送、画像の格納又は画像の表示などの他の動作に使用されうる前に、特定の色空間への変換を必要とする。さらに、カメラによって取り込まれた画像は、誤り及び／又は歪みを補正し、画像の色、サイズなどを調整するために処理される必要がありうる。したがって、一部の実施形態では、このような画像を格納、伝送及び表示する前に、画像に対していくつかの処理動作を実行する。このような画像の処理の一部は、ＣＩＰＵ３３０によって実行される。

このようなＣＩＰＵの一例が図４に示される。具体的には、この図は、一部の実施形態の取り込み済画像処理ユニット（ＣＩＰＵ）４００を概念的に示す。このＣＩＰＵ４００は、デバイスのカメラの１つのカメラのみからの画像を一度に処理するか、又はデバイスのカメラの両方からの画像を時分割多重化方式で（すなわち、時間インタリーブ方式で）同時に処理する単一の処理パイプライン４８５を含む。ＣＩＰＵ４００の処理パイプライン４８５は、異なるカメラの異なる特性及び／又は動作設定に対処するように異なって構成されうる。一部の実施形態における異なるカメラ特性の例として、異なる解像度、雑音センサ、レンズのタイプ（固定レンズ又はズームレンズ）などを含む。また、デバイスが一部の実施形態においてカメラを動作できる異なる動作設定の例として、画像の解像度サイズ、フレームレート、ズームレベル、露出レベルなどを含む。

図４に示すように、ＣＩＰＵ４００は、センサモジュール４１５と、ライン／フレームバッファ４１７と、不良画素補正（ＢＰＣ）モジュール４２０と、レンズシェーディング（ＬＳ）モジュール４２５と、デモザイキングモジュール４３０と、ホワイトバランス（ＷＢ）モジュール４３５と、ガンマモジュール４４０と、色空間変換（ＣＳＣ）モジュール４４５と、色相、彩度、及びコントラスト（ＨＳＣ）モジュール４５０と、スケーラモジュール４５５と、フィルタモジュール４６０と、統計エンジン４６５と、２組のレジスタ４７０と、コントローラモジュール４７５とを含む。一部の実施形態では、ＣＩＰＵ４００のモジュールのすべては、ハードウェア（例えば、ＡＳＩＣ、ＦＰＧＡ、マイクロコントローラを有するＳＯＣなど）として実装されるが、他の実施形態では、ＣＩＰＵ４００のモジュールの一部又はすべては、ソフトウェアとして実装される。

図４に示すように、センサモジュール４１５は、デバイスの２つのカメラの２つの画素アレイ４１０ａ及び４１０ｂ並びに２組のセンサ４０５ａ及び４０５ｂに通信可能に結合する。一部の実施形態では、この通信可能な結合は、各カメラセンサのモバイルインダストリプロセッサインタフェース（ＭＩＰＩ）によって容易になる。

この通信可能な結合によって、センサモジュール４１５は、各カメラの電力レベル、ズームレベル、フォーカス、露出レベルなどのその動作の種々の側面を制御するためにカメラに命令を転送できる。一部の実施形態では、各カメラは、４つの動作電力モードを有する。第１動作電力モードでは、カメラの電源が切れている。第２動作電力モードの場合、カメラの電源が投入されているが、まだ構成されていない。第３動作電力モードでは、カメラの電源は投入されており、カメラのセンサは構成されており、カメラセンサの画素は、光子を収集して、収集した光子をデジタル値に変換する。しかし、カメラセンサは、画像をセンサモジュール４１５にまだ送っていない。最後に、第４動作電力モードでは、カメラは、カメラがセンサモジュール４１５に画像を現在送っていることを除いて、第３電力モードと同じ動作電力モードである。

デバイスの動作中に、カメラは、１つの動作電力モードから別のモードに任意の回数切り換わってもよい。動作電力モードを切り換える場合に、一部の実施形態では、カメラが、上述の順番で動作電力モードを切り換えることが必要とされる。したがって、これらの実施形態では、第１動作電力モードのカメラは、第２動作電力モードのみに切り換わることができる。カメラは、第２動作電力モードの場合に、第１動作電力モード又は第３動作電力モードに切り換わることができる。同様に、カメラは、第３動作電力モードから第２動作電力モード又は第４動作電力モードに切り換わることができる。カメラは、第４動作電力モードの場合に、第３動作電力モードに切り換わって戻ることのみができる。

さらに、ある動作電力モードから次又は前の動作電力モードに切り換わるには、特定の量の時間がかかる。したがって、２つ又は３つの動作電力モードの間での切り換えは、１つ動作電力モードの切り換えよりも低速である。また、動作電力モードによって消費する電力量が異なる。例えば、第４動作電力モードは最も多くの量の電力を消費し、第３動作電力モードは、第１動作電力モード及び第２動作電力モードよりも多くの電力を消費し、第２動作電力モードは第１動作電力モードよりも多くの電力を消費する。一部の実施形態では、第１動作電力モードは、電力を全く消費しない。

カメラは、画像を取り込む第４動作電力モードでない場合に、他の動作電力モードのうちの１つのままであってもよい。使用されていないカメラをそのままにしておくための動作モードの決定は、カメラがどれほど多くの電力を消費することを許可されているか、及びカメラが画像取り込み開始要求にどれほど迅速に応答する必要がありうるかに依存する。例えば、第３動作電力モード（例えば、スタンバイモード）で動作するように構成されたカメラは、第１動作電力モードであるように（すなわち、電源が切れているように）構成されたカメラよりも多くの電力を消費する。しかし、カメラが、画像を取り込むように命令された場合に、第３動作電力モードで動作しているカメラは、第１動作電力モードで動作しているカメラよりも迅速に第４動作電力モードに切り換わることができる。このように、カメラは、画像を取り込んでいない場合にさまざまな要件（例えば、画像の取り込み要求に対する応答時間、消費電力）に基づいて異なる動作電力モードで動作するように構成されうる。

以下でさらに説明するように、ビデオ処理モジュール３２５が一方又は両方のカメラに画像を取り込み始めるように要求し、センサモジュール４１５がこの要求をコントローラモジュール４７５を通じて受け取る場合に、センサモジュール４１５は、各カメラとの通信可能な結合を通じて、一方又は両方のカメラセンサの集合に、画像を取り込み始めるように指示できる。カメラセンサのそれぞれにベイヤーフィルタが重畳され、したがって、各カメラセンサは、ベイヤーパターン画像を出力し、このベイヤーパターン画像は、各カメラセンサに関連する画素アレイに格納される。ベイヤーパターン画像とは、各画素が赤色、青色又は緑色のうち１色のみを格納する画像である。

センサモジュール４１５は、画素アレイ４１０ａ及び４１０ｂとの自身の結合を通じて、カメラ画素アレイ４１０ａ及び４１０ｂに格納されているベイヤーパターンＲＡＷ画像を読み出す。センサモジュール４１５がカメラの画素アレイから画像を読み出す速度を制御することによって、センサモジュール４１５は、特定のカメラによって取り込まれているビデオ画像のフレームレートを制御できる。センサモジュール４１５は、自身の画像読み出し速度を制御することによって、ＣＩＰＵ処理パイプライン４８５による、異なるカメラから取り込まれた画像の画像処理をインタリーブするために、異なるカメラによって取り込まれた画像のフェッチをインタリーブすることもできる。センサモジュール４１５の画像読み出しの制御について、以下のサブセクションＩＩ．Ａ．１及びＩＩ．Ａ．２でさらに説明する。

センサモジュール４１５は、画像ライン（すなわち、画像の画素行）をセンサモジュール４１５が画素アレイ４１０ａ及び４１０ｂから読み出して、ライン／フレームバッファ４１７に格納する。ライン／フレームバッファ４１７内の各画像ラインは、ＣＩＰＵ処理パイプライン４８５によって処理される。図４に示すように、ＣＩＰＵ処理パイプライン４８５は、ＢＰＣモジュール４２０、ＬＳモジュール４２５、デモザイキングモジュール４３０、ＷＢモジュール４３５、ガンマモジュール４４０、ＣＳＣモジュール４４５、ＨＳＣモジュール４５０、スケーラモジュール４５５及びフィルタモジュール４６０によって形成される。一部の実施形態では、ＣＩＰＵ処理パイプライン４８５は、ライン／フレームバッファ４１７からの画像を１ラインずつ（すなわち、１行ずつ）処理するが、他の実施形態では、ＣＩＰＵ処理パイプライン４８５は、ライン／フレームバッファ４１７からの画像全体を１フレームずつ処理する。

図４に示される例示的なパイプラインでは、ＢＰＣモジュール４２０は、ライン／フレームバッファ４１７から画像を読み出すモジュールである。このモジュールは、読み出された画像中の不良画素を補正するように試みる不良画素除去動作を実行し、この不良画素は、カメラセンサの１つ以上に欠陥があったこと（例えば、欠陥のある光センサが光をまったく検知しないか、光を間違って検知するなど）によって生じる可能性がある。一部の実施形態では、ＢＰＣモジュール４２０は、画像中の特定の画素を画像中の隣接する１つ以上の画素と比較することによって不良画素を検出する。特定の画素の値と隣接する画素の値との差がしきい値量よりも大きいならば、特定の画素の値は、特定の画素と同じ色（すなわち、赤色、緑色及び青色）の隣接するいくつかの画素の値の平均によって置き換えられる。

ＢＰＣモジュール４２０の動作は、このモジュール用にＣＩＰＵ４００の２組のレジスタ４７０に格納された値によって一部が制御される。具体的には、デバイスの２つの異なるカメラによって取り込まれた画像を処理するために、一部の実施形態では、上述のように、ＣＩＰＵ処理パイプライン４８５は、各カメラに対して異なるように構成される。ＣＩＰＵ処理パイプライン４８５は、ＣＩＰＵ４００の２つの異なるレジスタ４７０ａ（Ｒａ）の集合及び４７０ｂ（Ｒｂ）の集合に２つの異なる値の集合を格納することによって、２つの異なるカメラについて構成される。レジスタ４７０の各集合は、ＣＩＰＵ処理パイプライン４８５内にモジュール４２０〜４６０のそれぞれに対して１つのレジスタ（Ｒａ又はＲｂ）を含む。各レジスタセット内の各レジスタは、１つの処理パイプラインモジュールの動作を定義する１セットの値を格納する。したがって、図４に示すように、レジスタセット４７０ａは、デュアルカメラ携帯デバイスの一方のカメラ（カメラＡ）のための各処理パイプラインモジュールの動作のモードを示すためにあり、レジスタセット４７０ｂは、デュアルカメラ携帯デバイスの他方のカメラ（カメラＢ）のための各モジュールの動作のモードを示すためにある。

各カメラ向けに異なるようにＣＩＰＵ処理パイプライン４８５を構成する一例は、さまざまなサイズの画像を処理するようにＣＩＰＵ処理パイプライン４８５のモジュールを構成することである。例えば、カメラセンサ４０５ａが６４０×４８０画素で、カメラセンサ４０５ｂが２０４８×１５３６画素であるならば、レジスタ４７０ａの集合は、ＣＩＰＵ処理パイプライン４８５のモジュールに６４０×４８０画素画像を処理するように命令する値を格納するように構成され、レジスタ４７０ｂの集合は、ＣＩＰＵ処理パイプライン４８５のモジュールに２０４８×１５３６画素画像を処理するように命令する値を格納するように構成される。

一部の実施形態では、異なる処理パイプライン構成（すなわち、レジスタ値）は、異なるプロファイル設定に格納される。このような実施形態のうちの一部では、携帯デバイスのユーザは、カメラ（群）の動作を設定するために（例えば、携帯デバイスに表示されるユーザインタフェースによって）プロファイル設定のうちの１つを選択することを許可されている。例えば、ユーザは、高解像度ビデオを取り込むようにカメラを構成するためのプロファイル設定、低解像度ビデオを取り込むように同じカメラを構成するためのプロファイル設定、又は高解像度静止画像を取り込むように両方のカメラを構成するためのプロファイル設定を選択できる。さまざまな構成が可能であり、多数の異なるプロファイル設定に格納されうる。このような実施形態の他のものでは、ユーザにプロファイル設定を選択させる代わりに、プロファイル設定は、ユーザが選択したアプリケーション又はアクティビティに基づいて自動的に選択される。例えば、ユーザがテレビ会議アプリケーションを選択したならば、ビデオを取り込むように両方のカメラを構成するプロファイルが自動的に選択され、ユーザが写真アプリケーションを選択したならば、静止画像を取り込むようにカメラのうちの１つを構成するプロファイルが自動的に選択される、などである。

ＢＰＣモジュール４２０の後に、ＬＳモジュール４２５は、不良画素補正済みの画像を受け取る。ＬＳモジュール４２５は、ライトフォールオフ効果を生じる（すなわち、光がカメラセンサの端に向かって減少する）カメラレンズによって引き起こされる画像の欠陥を補正するためにレンズシェーディング補正動作を実行する。このような効果によって、画像は不均一に照らされる（例えば、隅及び／又は端の方が暗い）。これらの画像の欠陥を補正するために、一部の実施形態のＬＳモジュール４２５は、レンズの照度フォールオフの数学的モデルを推定する。その後、推定されたモデルは、画像の不均一に照らされた部分を均一に照らすように画像のレンズフォールオフを補償するために使用される。例えば、画像の隅の明度が画像の中心の半分であるならば、一部の実施形態のＬＳモジュール４２５は、均一な画像を生成するために隅の画素値に２倍にする。

デモザイキングモジュール４３０は、サンプリングされた色の画像からフルカラー画像を生成するためにデモザイキング動作を実行する。前述のように、カメラセンサがベイヤーパターン画像を出力するが、ベイヤーパターン画像の各画素は１色の値のみを格納するのでこのベイヤーパターン画像は不完全である。デモザイキングモジュール４３０は、ベイヤーパターン画像の各色集合に対する色値を補間することによって、ベイヤーパターン画像から赤色、緑色、青色（ＲＧＢ）画像を再構成する。

ＷＢモジュール４３５は、画像のコンテンツの色が、実生活でヒトの眼に知覚されるこのようなコンテンツの色に類似するように、デモザイキングモジュール４３０から受け取ったＲＧＢ画像にホワイトバランス動作を実行する。ＷＢモジュール４３５は、中間色（例えば、灰色、白色など）を適切にレンダリングするように画像の色を調整することによって、ホワイトバランスを調整する。例えば、白熱光下での１枚の白紙の画像は黄色に見えることがあるが、ヒトの眼は、この紙を白色と知覚する。センサが取り込んだ画像の色とヒトの眼が知覚する色との違いを考慮するために、ＷＢモジュール４３５は、取り込まれた画像がヒトの眼によって知覚される色を適切に反映するように画像の色値を調整する。

統計エンジン４６５は、ＣＩＰＵ処理パイプライン４８５の種々の段階において画像データを収集する。例えば、図４は、統計エンジン４６５がＬＳモジュール４２５、デモザイキングモジュール４３０及びＷＢモジュール４３５の後に画像データを収集することを示す。さまざまな実施形態では、ＣＩＰＵ処理パイプライン４８５の任意の数のさまざまな段階からデータを収集する。統計エンジン４６５は、収集されたデータを処理し、処理されたデータに基づいて、コントローラモジュール４７５及びセンサモジュール４１５を通じてカメラセンサ４０５ａ及び４０５ｂの動作を調整する。このような動作の例としては、露出及びフォーカスがある。図４は、統計エンジン４６５がコントローラモジュール４７５を通じてカメラセンサ４０５ａ及び４０５ｂを制御することを示しているが、統計エンジン４６５の他の実施形態は、まさにセンサモジュール４１５を通じてカメラセンサを制御する。

処理されたデータは、ＣＩＰＵ４００の種々のモジュールの動作を調整するために使用することもできる。例えば、一部の実施形態の統計エンジン４６５は、ＷＢモジュール４３５の後で収集されたデータに基づいてＷＢモジュール４３５の動作を調整する。このような実施形態のうちの一部では、統計エンジン４６５は、処理されたデータを使用してＷＢモジュール４３５のホワイトバランス動作を調整することによって、自動ホワイトバランス（ＡＷＢ）機能を提供する。他の実施形態では、ＣＩＰＵ処理パイプライン４８５の任意の数の段階から収集された処理済みのデータを使用してＣＩＰＵ処理パイプライン４８５内の任意の数のモジュールの動作を調整できる。さらに、統計エンジン４６５は、ＣＩＰＵ処理パイプライン４８５の１つ以上のモジュールの動作を調整するためにコントローラモジュール４７５から命令を受け取ることもできる。

ガンマモジュール４４０は、ＷＢモジュール４３５から画像を受け取った後で、カメラシステムの輝度又は３刺激値を符号化し復号するために、ガンマ補正動作を画像に対して実行する。一部の実施形態のガンマモジュール４４０は、画像のガンマを補正するために１０〜１２ビットの線形信号を８ビットの非線形の符号化信号に変換することによってガンマを補正する。一部の実施形態では、ルックアップテーブルを使用することによってガンマを補正する。

ＣＳＣモジュール４４５は、ガンマモジュール４４０から受け取った画像を、ある色空間から別の色空間に変換する。具体的には、ＣＳＣモジュール４４５は、ＲＧＢ色空間から輝度及び色差（ＹＵＶ）色空間に画像を変換する。しかし、ＣＳＣモジュール４４５の他の実施形態は、任意の数の色空間から、任意の数の色空間に画像を変換できる。

ＨＳＣモジュール４５０は、ＣＳＣモジュール４４５から受け取った画像の色相、彩度、コントラスト又はそれらの任意の組み合わせを調整してもよい。ＨＳＣモジュール４５０は、例えば、これらの性質を調整して、ノイズを減少させたり画像を向上させたりできる。例えば、低ノイズカメラセンサによって取り込まれた画像の彩度は、画像をより鮮明に見えるようにするために増加できる。対照的に、高ノイズカメラセンサによって取り込まれた画像の彩度は、このような画像の色ノイズを抑えるように減少できる。

ＨＳＣモジュール４５０の後で、スケーラモジュール４５５は、画像の画素解像度を調整するか又は画像のデータサイズを調整するために、画像をサイズ変更できる。スケーラモジュール４５５は、例えば、より小さな表示に適合させるために画像のサイズを低減してもよい。スケーラモジュール４５５は、いくつかの異なる方法で画像を拡大縮小できる。例えば、スケーラモジュール４５５は、画像を拡大したり（すなわち、引き伸ばす）縮小したり（すなわち、縮める）できる。スケーラモジュール４５５は、画像を比例して拡大縮小するか又は画像をアナモルフィックに拡大縮小することもできる。

フィルタモジュール４６０は、画像の一部又は全部の画素の１つ以上の属性を変更するために、スケーラモジュール４５５から受け取った画像に１つ以上のフィルタ動作を適用する。フィルタの例としては、いくつかの例の中でも特に、ローパスフィルタ、ハイパスフィルタ、バンドパスフィルタ、バイラテラルフィルタ、ガウシアンフィルタがある。このようなものとして、フィルタモジュール４６０は、画像に任意の数の異なるフィルタを適用できる。

一部の実施形態のコントローラモジュール４７５は、ＣＩＰＵ４００の動作を制御するマイクロコントローラである。一部の実施形態では、コントローラモジュール４７５は、（１）センサモジュール４１５を通じてカメラセンサの動作（例えば、露出レベル）、（２）ＣＩＰＵ処理パイプライン４８５の動作、（３）ＣＩＰＵ処理パイプライン４８５のタイミング（例えば、いつカメラセンサを切り換えるべきか、いつレジスタを切り換えるべきかなど）、及び（４）一部の実施形態のデュアルカメラ携帯デバイスの一部であるフラッシュ／ストロボ（不図示）を制御する。

コントローラモジュール４７５の一部の実施形態は、統計エンジン４６５及びＣＩＰＵドライバ４８０から受け取った命令を処理する。一部の実施形態では、ＣＩＰＵドライバ４８０から受け取った命令は、デュアルカメラ携帯デバイスからの（すなわち、ローカルデバイスから受け取った）命令であるが、他の実施形態では、ＣＩＰＵドライバ４８０から受け取った命令は、別のデバイス（例えば、テレビ会議中のリモート制御）からの命令である。コントローラモジュール４７５は、処理された命令に基づいて、レジスタ４７０の値をプログラミングすることによって、ＣＩＰＵ４００の動作を調整できる。さらに、コントローラモジュール４７５は、ＣＩＰＵ４００の動作中にレジスタ４７０の値を動的に再プログラムできる。

図４に示すように、ＣＩＰＵ４００は、ＣＩＰＵ処理パイプライン４８５に複数のモジュールを含む。しかし、ＣＩＰＵ４００はほんの数個の説明したモジュール又は異なる追加のモジュールで実装できることが当業者には理解されよう。さらに、異なるモジュールによって実行される処理は、図４に示される順序とは異なる順序で画像に適用されうる。

ここで、ＣＩＰＵ４００の例示的な動作について、図４を参照して説明する。説明のために、レジスタＲａの集合は、デュアルカメラ携帯デバイスのカメラセンサ４０５ａによって取り込まれた画像を処理するために使用され、レジスタＲｂの集合は、デュアルカメラ携帯デバイスのカメラセンサ４０５ｂによって取り込まれた画像を処理するために使用される。コントローラモジュール４７５は、デュアルカメラ携帯デバイスのカメラのうちの１つによって取り込まれた画像を生成するためにＣＩＰＵドライバ４８０から命令を受け取る。

コントローラモジュール４７５は、その後、デュアルカメラ携帯デバイスのカメラのうちの１つによって取り込まれた画像を処理するためにＣＩＰＵ処理パイプライン４８５の種々のモジュールを初期化する。一部の実施形態では、これは、レジスタ４７０のうちのレジスタの適切な集合が使用されていることをコントローラモジュール４７５が確認することを含む。例えば、ＣＩＰＵドライバ４８０が、カメラセンサ４０５ａによって取り込まれた画像を生成するようにコントローラモジュール４７５に命令するならば、コントローラモジュール４７５は、レジスタＲａの集合が、ＣＩＰＵ４００のモジュールの読み取るレジスタの集合であることを確認する。そうでないならば、コントローラモジュール４７５は、レジスタＲａの集合が、ＣＩＰＵ４００のモジュールによって読み取られる集合であるように、レジスタの集合を切り換える。

ＣＩＰＵ処理パイプライン４８５の各モジュールに対して、動作のモードが、レジスタＲａの集合に格納された値によって示される。前述したように、レジスタ４７０の集合の値は、ＣＩＰＵ４００の動作中に動的に再プログラムされうる。したがって、１つの画像の処理は、次の画像の処理と異なりうる。ＣＩＰＵ４００のこの例示的な動作の説明では、ＣＩＰＵ４００の各モジュールが、モジュールの動作のモードを示すレジスタに格納された値を読み取ることが説明されているが、いくつかのソフトウェアで実装された実施形態では、その代わりに、パラメータがＣＩＰＵ４００の種々のモジュールに渡される。

一部の実施形態では、コントローラモジュール４７５は、画素アレイ４１０ａから画像を読み出した後で特定の量の時間だけ遅延するようにセンサモジュール４１５に命令することによってセンサモジュール４１５を初期化する。言い換えれば、コントローラモジュール４７５は、特定のレートで画素アレイ４１０ａから画像を読み出すように、センサモジュール４１５に命令する。

次に、コントローラモジュール４７５は、画像を取り込むように、センサモジュール４１５を通じて、カメラセンサ４０５ａに命令する。一部の実施形態では、コントローラモジュール４７５は、カメラセンサ４０５ａに、露出及び他のカメラ動作のパラメータも提供する。他の実施形態では、カメラセンサ４０５ａは、カメラセンサ動作パラメータにデフォルト値を使用する。カメラセンサ４０５ａは、パラメータに基づいて、画素アレイ４１０ａに格納されたＲＡＷ画像を取り込む。センサモジュール４１５は、ＣＩＰＵ処理パイプライン４８５が画像を処理する前に、画素アレイ４１０ａからＲＡＷ画像を読み出し、格納のために、この画像をライン／フレームバッファ４１７に送る。

ある一定の状況では、画像は、ライン／フレームバッファ４１７によって破棄されうる。カメラセンサ４０５ａ及び／又は４０５ｂが高速で画像を取り込んでいる場合に、センサモジュール４１５は、ＢＰＣモジュール４２０がライン／フレームバッファ４１７から画像を読み出すことができる（例えば、高フレームレートビデオを取り込む）よりも高速に、画像を受け取ってライン／フレームバッファ４１７に格納でき、ライン／フレームバッファ４１７はいっぱいになるだろう。これが発生すると、一部の実施形態のライン／フレームバッファ４１７は、先入れ先出し方式に基づいて画像（すなわち、フレーム）を破棄する。すなわち、ライン／フレームバッファ４１７が画像を破棄する場合に、ライン／フレームバッファ４１７は、ライン／フレームバッファ４１７の他のすべての画像の前に受け取った画像を破棄する。

ＣＩＰＵ処理パイプライン４８５による画像の処理は、画像の不良画素を補正するためにＢＰＣモジュール４２０がライン／フレームバッファ４１７から画像を読み出すことによって開始する。その後、ＢＰＣモジュール４２０は、画像の不均一な照度を補正するためにＬＳモジュール４２５に画像を送る。画像の照度が補正された後、ＬＳモジュール４２５は、ＲＡＷ画像を処理してＲＡＷ画像からＲＧＢ画像を生成するデモザイキングモジュール４３０に画像を送る。次に、ＷＢモジュール４３５は、デモザイキングモジュール４３０からＲＧＢ画像を受け取り、ＲＧＢ画像のホワイトバランスを調整する。

前述のように、統計エンジン４６５は、ＣＩＰＵ処理パイプライン４８５の種々の時点で何らかのデータを収集していてもよい。例えば、統計エンジン４６５は、図４に示すように、ＬＳモジュール４２５、デモザイキングモジュール４３０及びＷＢモジュール４３５の後でデータを収集する。この収集されたデータに基づいて、統計エンジン４６５は、カメラセンサ４０５ａからの以後の画像の取り込みを調整するために、カメラセンサ４０５ａの動作、ＣＩＰＵ処理パイプライン４８５の１つ以上のモジュールの動作、又は両方を調整できる。例えば、収集したデータに基づいて、統計エンジン４６５は、現在の画像の露出レベルが低すぎ、したがって、その後で取り込まれる画像に対する露出レベルを増加させるようにセンサモジュール４１５を通じてカメラセンサ４０５ａに命令することを決定してもよい。したがって、一部の実施形態の統計エンジン４６５は、一部の処理動作のためのフィードバックループとして動作する。

ＷＢモジュール４３５は、画像のホワイトバランスを調整した後、ガンマ補正のため（例えば、画像のガンマ曲線を調整するため）にガンマモジュール４４０に画像を送る。ＣＳＣモジュール４４５は、ガンマモジュール４４０からガンマ補正済みの画像を受け取り、色空間変換を実行する。この例では、ＣＳＣモジュール４４５は、ＲＧＢ画像をＹＵＶ画像に変換する。言い換えれば、ＣＳＣモジュール４４５は、ＲＧＢ色空間で表される画像をＹＵＶ色空間で表される画像に変換する。ＨＳＣモジュール４５０は、ＣＳＣモジュール４４５からＹＵＶ画像を受け取り、画像の種々の画素の色相属性、彩度属性及びコントラスト属性を調整する。ＨＳＣモジュール４５０の後で、スケーラモジュール４５５は、画像をサイズ変更する（例えば、画像を引き伸ばす又は縮める）。フィルタモジュール４６０は、スケーラモジュール４５５から画像を受け取った後、画像に対して１つ以上のフィルタを適用する。最後に、フィルタモジュール４６０は、処理された画像をＣＩＰＵドライバ４８０に送る。

上述のＣＩＰＵ４００の動作のこの例では、ＣＩＰＵ処理パイプライン４８５の各モジュールは、何らかの方式で画像を処理した。しかし、ＣＩＰＵ４００によって処理される他の画像は、ＣＩＰＵ処理パイプライン４８５のすべてのモジュールによる処理を必要としなくてもよい。例えば、画像は、ホワイトバランス調整、ガンマ補正、拡大縮小又はフィルタ処理を必要としなくてもよい。したがって、ＣＩＰＵ４００は、例えば、ＣＩＰＵドライバ４８０からの命令などのさまざまな受け取った入力又は統計エンジン４６５によって収集されたデータに基づいて任意の複数の手法で画像を処理できる。

異なる実施形態は、画像が処理される速度（すなわち、フレームレート）を異なるように制御する。フレームレートを制御する１つの方式は、垂直帰線消去期間（ＶＢＩ）の操作によるものである。画像を１ラインずつ処理するために画像ラインを読み出す一部の実施形態では、ＶＢＩは、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオの画像の最後のラインを画素アレイから読み出すことと、ビデオの次の画像の最初のラインを画素アレイから読み出すこととの時間差である。他の実施形態では、ＶＢＩは、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオの１つの画像を画素アレイから読み出すことと、ビデオの次の画像を画素アレイから読み出すこととの時間差である。

ＶＢＩを使用できる１つの例は、センサモジュール４１５と画素アレイ４１０ａ及び４１０ｂとの間である。例えば、センサモジュール４１５の一部の実施形態は、画素アレイ４１０ａ及び４１０ｂから画像を１ラインずつ読み出し、センサモジュール４１５の他の実施形態は、画素アレイ４１０ａ及び４１０ｂから画像を１画像ずつ読み出す。したがって、フレームレートは、センサモジュール４１５のＶＢＩを調整することによって制御されうる。ＶＢＩを増加させると、フレームレートが減少し、ＶＢＩを減少させると、フレームレートが増加する。

１．シングルカメラのためのＶＢＩの使用：フレームレート制御
図５は、異なるＶＢＩに基づいた異なるフレームレート５０５、５１０及び５１５の例を概念的に示す。各シーケンスは、デュアルカメラ携帯デバイスのカメラのうちの１つによって取り込まれた、タイムライン５２０に沿った種々の時刻５２５〜５５５でのギターを持つ人の画像を示す。さらに、各時刻５２５〜５５５間の時間は同じであり、１単位時間と呼ばれる。説明のために、ここで図５について、図４のセンサモジュール４１５及び画素アレイ４１０ａに関して説明する。したがって、各画像は、センサモジュール４１５が画素アレイ４１０ａから画像を読み出す時刻をタイムライン５２０に沿って表す。

例示的なフレームレート５０５では、画素アレイ４１０ａのためのセンサモジュール４１５のＶＢＩは、（例えば、コントローラモジュール４７５によって）３単位時間に設定される。すなわち、センサモジュール４１５は、タイムライン５２０に沿って３時刻ごとに画素アレイ４１０ａから画像を読み出す。例示的なフレームレート５０５に示されるように、センサモジュール４１５は、時刻５２５、５４０、及び５５５に画像を読み出す。したがって、例示的なフレームレート５０５は、３単位時間ごとに１画像のフレームレートを有する。

例示的なフレームレート５１０は、ＶＢＩが２単位時間に設定されることを除いて、例示的なフレームレート５０５と同様である。したがって、センサモジュール４１５は、タイムライン５２０に沿って２時刻ごとに画素アレイ４１０ａから画像を読み出す。例示的なフレームレート５１０は、センサモジュール４１５が時刻５２５、５３５、５４５及び５５５に画素アレイ４１０ａから画像を読み出すことを示す。例示的なフレームレート５１０のＶＢＩは例示的なフレームレート５０５のＶＢＩよりも小さいので、例示的なフレームレート５１０のフレームレートは例示的なフレームレート５０５のフレームレートよりも高い。

例示的なフレームレート５１５も、画素アレイ４１０ａのためのセンサモジュール４１５のＶＢＩが１単位時間に設定されることを除いて、例示的なフレームレート５０５と同様である。したがって、センサモジュール４１５は、タイムライン５２０に沿って１時刻ごとに画素アレイ４１０ａから画像を読み出すように命令される。図示のように、センサモジュール４１５は、時刻５２５〜５５５に画素アレイ４１０ａから画像を読み出す。例示的なフレームレート５１５のＶＢＩは、例示的なフレームレート５０５及び５１０のＶＢＩよりも小さい。したがって、例示的なフレームレート５１５のフレームレートは、例示的なフレームレート５０５及び５１０よりも高い。

２．２つのカメラのためのＶＢＩの使用
一部の実施形態では、デュアルカメラ携帯デバイスの両方のカメラを同時に動作する（例えば、テレビ会議中に両方のカメラからビデオを伝送する）ことが望まれうる。単一の処理パイプラインを含むデュアルカメラ携帯デバイスの異なる実施形態は、デュアルカメラ携帯デバイスの両方のカメラを同時に動作するための異なる機構を提供する。

このような１つの機構は、各カメラのＶＢＩを制御することによって、両方のカメラにより取り込まれた画像の処理をインタリーブすることである。すなわち、一方のカメラによって取り込まれた１つ以上の画像が、他方のカメラのＶＢＩ中に取り込まれて処理され、一方のカメラのＶＢＩ中に、他方のカメラによって取り込まれた１つ以上の画像が取り込まれて処理される。上述のＣＩＰＵ４００は単一の処理パイプライン４８５を有するので、この機構は一部の実施形態のＣＩＰＵ４００で実施されうる。このような実施形態では、センサモジュール４１５は、画素アレイ４１０ａ及び４１０ｂのうちの１つから画像を読み出し、読み出された画像は、センサモジュール４１５の他の画素アレイのためのＶＢＩ中にＣＩＰＵ４００によって処理される。

各画素アレイのためのセンサモジュール４１５のＶＢＩは、特定の値に設定されうる。しかし、一部の実施形態では、ＶＢＩは、ＣＩＰＵ４００が１つの画像を読み出して処理するのにかかる時間よりも小さな値に設定されない。一部の実施形態では、各画素アレイのためのセンサモジュール４１５のＶＢＩは、同じ値に設定される。例えば、各画素アレイのためのセンサモジュール４１５のＶＢＩが同じ値に設定される場合に、センサモジュール４１５は、画素アレイ４１０ａ及び４１０ｂから交互に画像を読み出す。他の実施形態では、各画素アレイのためのセンサモジュール４１５のＶＢＩは、異なる値に設定される。このような実施形態のうちの一部では、一方の画素アレイのためのセンサモジュール４１５のＶＢＩは、他方の画素アレイのためのセンサモジュール４１５のＶＢＩの倍数に設定される。例えば、一方の画素アレイのためのセンサモジュール４１５のＶＢＩは、２単位時間に設定され、他方の画素アレイのためのセンサモジュール４１５のＶＢＩは４単位時間に設定される。この例では、センサモジュール４１５は、センサモジュール４１５が他方の画素アレイから１つの画像を読み出すごとに、一方の画素アレイから２つの画像を読み出す。

図６は、異なるＶＢＩに基づいた異なるインタリーブフレームレート６０５、６１０及び６１５の例を概念的に示す。図６がタイムライン６２０に沿って１３の時刻６２５〜６８５を含むことを除いて、図６は図５と同様である。さらに、ギターを持つ人の画像は、タイムライン６２０に沿って、画像が一方の画素アレイから読み出される時刻を表すが、大学帽（すなわち、角帽）をかぶった人の画像は、タイムライン６２０に沿って、他方の画素アレイから画像が読み出される時刻を表す。

説明のために、ギターを持つ人の画像はデュアルカメラ携帯デバイスのカメラセンサ４０５ａによって取り込まれたものと想定し、大学帽をかぶった人の画像は、デュアルカメラ携帯デバイスのカメラセンサ４０５ｂによって取り込まれたものと想定する。さらに、ここで図６について、図４のセンサモジュール４１５及び画素アレイ４１０ａ及び４１０ｂに関して説明する。

例示的なインタリーブフレームレート６０５では、画素アレイ４１０ａ及び画素アレイ４１０ｂの両方に対するセンサモジュール４１５のＶＢＩは、２単位時間に設定される。例示的なインタリーブフレームレート６０５に示されるように、センサモジュール４１５は、タイムライン６２０に沿って時刻６２５、６３５、６４５、６５５、６６５、６７５及び６８５に画素アレイ４１０ａから画像を読み出し、センサモジュール４１５は、タイムライン６２０に沿って時刻６３０、６４０、６５０、６６０、６７０及び６８０に画素アレイ４１０ｂから画像を読み出す。すなわち、センサモジュール４１５は、単位時間ごとに画素アレイから交互に画像を読み出す。

画素アレイ４１０ａ及び画素アレイ４１０ｂの両方に対するセンサモジュール４１５のＶＢＩが４単位時間に設定されることを除いて、例示的なインタリーブフレームレート６１０は例示的なインタリーブフレームレート６０５と同様である。例示的なインタリーブフレームレート６１０は、センサモジュール４１５がタイムライン６２０に沿って時刻６２５、６４５、６６５及び６８５に画素アレイ４１０ａから画像を読み出し、センサモジュール４１５がタイムライン６２０に沿って時刻６３５、６５５及び６７５に画素アレイ４１０ｂから画像を読み出すことを示す。例示的なインタリーブフレームレート６１０のＶＢＩは例示的なインタリーブフレームレート６０５のＶＢＩよりも高いので、例示的なインタリーブフレームレート６１０のフレームレートは例示的なインタリーブフレームレート６０５のフレームレートよりも小さい。

例示的なインタリーブフレームレート６１５も、画素アレイ４１０ａ及び画素アレイ４１０ｂの両方に対するセンサモジュール４１５のＶＢＩが６単位時間に設定されることを除いて、例示的なインタリーブフレームレート６０５と同様である。図６に示すように、センサモジュール４１５は、タイムライン６２０に沿って時刻６２５、６５５及び６８５に画素アレイ４１０ａから画像を読み出し、センサモジュール４１５は、タイムライン６２０に沿って時刻６４０及び６７０に画素アレイ４１０ｂから画像を読み出す。例示的なインタリーブフレームレート６１５のＶＢＩは、例示的なインタリーブフレームレート６０５及び６１０のＶＢＩよりも大きい。したがって、例示的なインタリーブフレームレート６１５のフレームレートは、例示的なインタリーブフレームレート６０５及び６１０よりも小さい。

Ｂ．複数のパイプライン
図７は、一部の実施形態の取り込み済画像処理ユニット（ＣＩＰＵ）７００を概念的に示す。ＣＩＰＵ７００が単一の処理パイプラインの代わりに２つのフロントエンド処理パイプライン、記憶装置及びバックエンド処理パイプラインによって実装されることを除いて、ＣＩＰＵ７００は上述のＣＩＰＵ４００と同じ機能を実行する。したがって、ＣＩＰＵ７００の機能の説明について、ＣＩＰＵ４００のモジュールを参照して説明する。

図示のように、ＣＩＰＵ７００は、カメラセンサ４０５ａ及び画素アレイ４１０ａのためのフロントエンド処理パイプライン７１５と、カメラセンサ４０５ｂ及び画素アレイ４１０ｂのためのフロントエンド処理パイプライン７２０と、記憶装置７２５と、コントローラモジュール７３０と、バックエンド処理パイプライン７３５とを含む。一部の実施形態のカメラセンサ４０５ａ及び４０５ｂは、デュアルカメラ携帯デバイスのカメラのセンサである。

一部の実施形態のフロントエンド処理パイプライン７１５及び７２０は、ＣＩＰＵ４００の画像処理の一部分を実行する。したがって、異なる実施形態は、ＣＩＰＵ４００の異なる数のモジュールを含むことができる。例えば、一部の実施形態のフロントエンド処理パイプライン７１５及び７２０のそれぞれは、ＣＩＰＵ４００のセンサモジュール４１５と、ＢＰＣモジュール４２０と、ＬＳモジュール４２５と、デモザイキングモジュール４３０と、ＷＢモジュール４３５と、統計エンジン４６５とを含む。

フロントエンド処理パイプライン７１５及び７２０は、同じモジュールを有することによって同じタイプの画像処理を実行するが、フロントエンド処理パイプライン７１５及び７２０のそれぞれの各モジュールは、ＣＩＰＵ４００に関して上述したように、異なるレジスタ値によって異なるように構成されうる。さらに、カメラセンサ４０５ａ及び４０５ｂのそれぞれがそれ自体のフロントエンド処理パイプラインを有するので、フロントエンド処理パイプライン７１５及び７２０は、互いと無関係に画像を処理できる。例えば、フロントエンド処理パイプライン７１５及び７２０は、異なる時間に異なる速度で並列に（すなわち、同時に）画像を処理できる。

一部の実施形態では、フロントエンド処理パイプライン７１５及び７２０のそれぞれは、その対応するカメラセンサ及び画素アレイから画像を読み出せる。例えば、フロントエンド処理パイプライン７１５は、カメラセンサ４０５ａによって取り込まれた画像を画素アレイ４１０ａから読み出し、フロントエンド処理パイプライン７２０は、カメラセンサ４０５ｂによって取り込まれた画像を画素アレイ４１０ｂから受け取る。フロントエンド処理パイプライン７１５及び７２０のうちの１つが画像をその対応するカメラセンサ及び画素アレイから読み出す場合に、当該フロントエンド処理パイプラインは、画像を処理し、処理された画像を記憶装置７２５に送る。同様に、フロントエンド処理パイプライン７１５及び７２０のそれぞれは、上述のように（例えば、各フロントエンド処理パイプラインの統計エンジンを通じて）コントローラモジュール７３０と通信する。

一部の実施形態の記憶装置７２５は、バックエンド処理パイプライン７３５が処理を完了させるために、部分的に処理された画像を格納する。これらの実施形態では、記憶装置７２５は、部分的に処理された画像をフロントエンド処理パイプライン７１５及び７２０から受け取り、この部分的に処理された画像をバックエンド処理パイプライン７３５に送る。一部の実施形態では、記憶装置７２５が揮発性記憶装置（例えば、ランダムアクセスメモリ（ＲＡＭ））として実施されるが、他の実施形態では、記憶装置７２５が不揮発性記憶装置（例えば、フラッシュメモリ、ハードディスク、光ディスクなど）として実施される。さらに、一部の実施形態の記憶装置７２５は、内部記憶装置（例えば、ＲＡＭ）であるが、他の実施形態の記憶装置７２５は、外部記憶装置（例えば、コンパクトフラッシュ（登録商標）（ＣＦ）カード、セキュアデジタル（ＳＤ）カードなど）である。

バックエンド処理パイプライン７３５の一部の実施形態は、ＣＩＰＵ７００の画像処理の一部分を実行する。一部の実施形態では、バックエンド処理パイプライン７３５は、フロントエンド処理パイプライン７１５及び７２０が含まないＣＩＰＵ４００のモジュールを含む。例えば、上記の例を参照すると、バックエンド処理パイプライン７３５は、ＣＩＰＵ４００のＣＳＣモジュール４４５と、ガンマモジュール４４０と、ＨＳＣモジュール４５０と、スケーラモジュール４５５と、フィルタモジュール４６０とを含むだろう。したがって、このような実施形態のバックエンド処理パイプライン７３５は、フロントエンド処理パイプライン７１５及び７２０が実行しないＣＩＰＵ４００の残りの画像処理を実行する。したがって、バックエンド処理パイプライン７３５は、記憶装置７２５から部分的に処理された画像を読み出し、部分的に処理された画像に関する残りの画像処理を実行する。画像を処理した後、バックエンド処理パイプライン７３５は、処理された画像をＣＩＰＵドライバ４８０に送る。

コントローラモジュール７３０は、図４に関して上述した同じ機能を実行する。図７に示すように、コントローラモジュール７３０は、フロントエンド処理パイプライン７１５及び７２０並びにバックエンド処理パイプライン７３５と対話する。一部の実施形態では、コントローラモジュール７３０は、バックエンド処理パイプライン７３５に含まれるが、他の実施形態では、コントローラモジュール７３０は、フロントエンド処理パイプライン７１５及び７２０のうちの１つに含まれる。

ここで、ＣＩＰＵ７００の動作について、図７に示されるカメラセンサ４０５ａ及び４０５ｂ、画素アレイ４１０ａ及び４１０ｂ、フロントエンド処理パイプライン７１５及び７２０、記憶装置７２５並びにバックエンド処理パイプライン７３５に関して説明する。フロントエンド処理パイプライン７１５及び７２０のうちの１つが画像をその対応するカメラセンサ及び画素アレイから読み出す場合に、そのフロントエンド処理パイプラインは、画像を処理し、部分的に処理された画像を記憶装置７２５に送る。例えば、フロントエンド処理パイプライン７１５は、カメラセンサ４０５ａによって取り込まれた画像を画素アレイ４１０ａから読み出してもよいし、又はフロントエンド処理パイプライン７２０は、カメラセンサ４０５ｂによって取り込まれた画像を画素アレイ４１０ｂから読み出してもよい。前述のように、各フロントエンド処理パイプライン７１５及び７２０は、画像を並列に処理できる。

バックエンド処理パイプライン７３５は、部分的に処理された画像を記憶装置７２５から読み出し、この部分的に処理された画像を処理して、画像の画像処理を完了させる。一部の実施形態では、バックエンド処理パイプライン７３５は、記憶装置７２５に格納された画像を先入れ先出し方式で読み出して処理する。言い換えれば、記憶装置７２５内の特定の画像は、特定の画像の前に受け取られて記憶装置７２５に格納されたすべての画像の後に処理されるが、この特定の画像は、特定の画像の後に受け取られて記憶装置７２５に格納された画像の前に処理される。バックエンド処理パイプライン７３５は、画像を処理した後、処理された画像をＣＩＰＵドライバ４８０に送る。

図８は、一部の実施形態の別の取り込み済画像処理ユニット（ＣＩＰＵ）８００を概念的に示す。ＣＩＰＵ８００は、２つの別個の処理パイプラインによってＣＩＰＵ８００が実施され、各カメラセンサがそれ自体の別個の処理パイプラインを有することを除いて、上述のＣＩＰＵ４００と同じ機能を実行する。したがって、ＣＩＰＵ８００の機能の説明について、ＣＩＰＵ４００のモジュールを参照して説明する。

図示のように、ＣＩＰＵ８００は、カメラセンサ４０５ａ及び画素アレイ４１０ａのための処理パイプライン８１５と、カメラセンサ４０５ｂ及び画素アレイ４１０ｂのための処理パイプライン８２０とを含む。一部の実施形態の処理パイプライン８１５及び８２０のそれぞれは、ＣＩＰＵ４００に含まれるすべてのモジュールを含む。したがって、これらの実施形態の処理パイプライン８１５及び８２０のそれぞれの動作は、ＣＩＰＵ４００の動作と同じである。

カメラセンサ４０５ａ及び４０５ｂのそれぞれがそれ自体の処理パイプラインを有するので、処理パイプライン８１５及び８２０は、互いと無関係に画像を処理できる。例えば、処理パイプライン８１５及び８２０は、異なる時間に異なる速度で並列に（すなわち、同時に）画像を処理できる。さらに、一部の実施形態の処理パイプライン８１５及び８２０のそれぞれは、ＣＩＰＵ４００を参照して上述したように、異なるレジスタ値を通じて異なるように構成されうる。

一部の実施形態では、ＣＩＰＵ４００のいくつかのモジュールは、モジュールの動作のうちの一部又は全部を実行するための１つ以上のライン／フレームバッファを含む。例えば、一部の実施形態のフィルタ処理モジュール４６０は、３×３のローパスフィルタを実行するために実施される。このような実施形態では、３×３のローパスフィルタは、３つの連続するラインの中央のラインに３×３のローパスフィルタを適用するように、画像内の３つの連続するラインを処理する。したがって、このような実施形態のフィルタ処理モジュール４６０は、３×３のローパスフィルタを実行するために少なくとも３つのライン／フレームバッファを必要とする。ＣＩＰＵ４００の他のモジュールも、例えば、ＢＰＣモジュール４２０及びＬＳモジュール４２５のような１つ以上のライン／フレームバッファを含む。

ＣＩＰＵ８００の処理パイプラインはそれぞれ、その対応するカメラの特性に合わせて画像処理をカスタマイズするために、異なるライン／フレームバッファサイズを有しうる。例えば、デュアルカメラ携帯デバイスの一方のカメラが２０４８×１５００画素センサを有するならば、２０４８×１５００画素センサの処理パイプラインは、２０４８画素幅であるライン／フレームバッファを含むことができる。同様に、デュアルカメラ携帯デバイスの他方のカメラが６４０×４８０画素センサを有するならば、６４０×４８０画素センサの処理パイプラインは、６４０画素幅であるライン／フレームバッファを含むことができる。すなわち、１つの処理パイプラインのモジュールに含まれるライン／フレームバッファのサイズは、別の処理パイプラインのモジュールに含まれるライン／フレームバッファのサイズとは異なってもよい。

ＩＩＩ．テレビ会議
Ａ．テレビ会議アーキテクチャ
図９は、一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュール９００のためのソフトウェアアーキテクチャを概念的に示す。テレビ会議及び処理モジュール９００は、図３に関して上述した対応するモジュール及びドライバ３０５、３１０及び３２０と同様であるＣＩＰＵドライバ９０５と、メディア交換モジュール９１０と、エンコーダドライバ９２０とを含む。テレビ会議及び処理モジュール９００は、テレビ会議モジュール９２５と、テレビ会議クライアント９４５と、さまざまなテレビ会議機能を実行するためのネットワークインタフェース９５０とも含む。ビデオ処理及び符号化モジュール３００のように、テレビ会議及び処理モジュール９００は、デュアルカメラ携帯デバイスのカメラから取り込まれた画像を処理して符号化する。

図３に関して上述したように、メディア交換モジュール９１０を使用することによって、デバイス内のメディアコンテンツの消費者及び製作者は、メディアコンテンツの処理に関するメディアコンテンツ及び命令を交換し、ＣＩＰＵドライバ９０５は、取り込み済画像処理ユニット（ＣＩＰＵ）９５５との通信インタフェースとして機能し、エンコーダドライバ９２０は、エンコーダハードウェア９６０（例えば、エンコーダチップ、システムオンチップ上の符号化コンポーネントなど）との通信インタフェースとして機能する。

一部の実施形態のテレビ会議モジュール９２５は、画像処理、テレビ会議管理及びネットワーキングなどの種々のテレビ会議機能を扱う。図示のように、テレビ会議モジュール９２５は、メディア交換モジュール９１０、テレビ会議クライアント９４５及びネットワークインタフェース９５０と対話する。一部の実施形態では、テレビ会議モジュール９２５は、テレビ会議クライアント９４５から命令を受け取り、テレビ会議クライアント９４５に命令を送る。一部の実施形態のテレビ会議モジュール９２５はまた、ネットワークインタフェース９５０を通じて、ネットワーク（例えば、ローカルエリアネットワーク（ＬＡＮ）、無線ローカルエリアネットワーク（ＷＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ネットワークのネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、ＧＳＭ（登録商標）ネットワークなど）にデータを送信し、ネットワークからデータを受信する。

テレビ会議モジュール９２５は、画像処理層９３０と、管理層９３５と、ネットワーク層９４０とを含む。一部の実施形態では、画像処理層９３０は、テレビ会議の画像に関する画像処理動作を実行する。例えば、一部の実施形態の画像処理層９３０は、以下でさらに詳細に説明するように、露出調整、画像サイズ変更、パースペクティブ補正及びダイナミックレンジ調整を実行する。一部の実施形態の画像処理層９３０は、メディア交換モジュール９１０を通じて、ＣＩＰＵ９５５からの画像の要求を送信する。

一部の実施形態の管理層９３５は、テレビ会議モジュール９２５の動作を制御する。例えば、一部の実施形態では、管理層９３５は、デュアルカメラ携帯デバイスの１つのカメラ／複数のカメラを初期化し、リモートデバイスに伝送するために画像及びオーディオを処理し、リモートデバイスから受け取った画像及びオーディオを処理する。一部の実施形態では、管理層９３５は、デバイスのための合成（例えば、ＰＩＰ）表示を生成する。さらに、管理層９３５は、ネットワーク層９４０から受け取ったネットワーキング報告に基づいて、テレビ会議モジュール９２５の動作を変更してもよい。

一部の実施形態では、ネットワーク層９４０は、テレビ会議のためのネットワーキング機能のうちの一部又は全部を実行する。例えば、一部の実施形態のネットワーク層９４０は、以下で説明するように、いくつかの機能の中でも特に、テレビ会議のデュアルカメラ携帯デバイスとリモートデバイスとの間のネットワーク接続（不図示）を確立し、リモートデバイスに画像を伝送し、リモートデバイスから画像を受信する。さらに、ネットワーク層９４０は、いくつかのタイプのデータの中でも特に、パケット損失、片道レイテンシ（one-way latency）及びラウンドトリップ遅延時間などのネットワーキングデータを受信し、このようなデータを処理し、このデータを管理層９３５に報告する。

一部の実施形態のテレビ会議クライアント９４５は、テレビ会議アプリケーション、ボイスオーバーＩＰ（ＶＯＩＰ）アプリケーション（例えば、スカイプ）又はインスタントメッセージングアプリケーションなどのテレビ会議モジュール９２５のテレビ会議機能を使用してもよいアプリケーションである。一部の実施形態では、テレビ会議クライアント９４５はスタンドアロンアプリケーションであるが、他の実施形態では、テレビ会議クライアント９４５は別のアプリケーションに統合される。

一部の実施形態では、ネットワークインタフェース９５０は、テレビ会議モジュール９２５及びテレビ会議クライアント９４５がネットワークインタフェース９５０を通じてネットワーク（例えば、セルラーネットワーク、ローカルエリアネットワーク、無線ネットワーク、ネットワークのネットワーク、インターネットなど）を介してデータを送信しデータを受信できるようにする通信インタフェースである。例えば、テレビ会議モジュール９２５がデータ（例えば、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像）をインターネット上で別のデバイスに送信することを望むならば、テレビ会議モジュール９２５は、ネットワークインタフェース９５０を通じて他のデバイスに画像を送信する。

Ｂ．テレビ会議のセットアップ
図１０は、一部の実施形態の例示的なテレビ会議要求メッセージシーケンス１０００を概念的に示す。この図は、デバイス１００５上で実行されるテレビ会議クライアント１０１０、テレビ会議サーバ１０１５、及びデバイス１０２０上で実行されるテレビ会議クライアント１０２５の間のテレビ会議要求メッセージシーケンス１０００を示す。一部の実施形態では、テレビ会議クライアント１０１０及び１０２５は、図９に示されるテレビ会議クライアント９４５と同じである。図１０に示すように、１つのデバイス（すなわち、デバイス１００５）がテレビ会議を要求し、別のデバイス（すなわち、デバイス１０２０）がこのような要求に応答する。本出願で説明するデュアルカメラ携帯デバイスは、両方の動作を実行する（すなわち、要求を行い、要求に応答する）ことができる。

一部の実施形態のテレビ会議サーバ１０１５は、複数のテレビ会議クライアントの間でメッセージを経路制御する。一部の実施形態では、１つのコンピューティングデバイス上でテレビ会議サーバ１０１５を実施するが、他の実施形態では、複数のコンピューティングデバイス上でテレビ会議サーバ１０１５を実施する。一部の実施形態では、テレビ会議サーバは、一度に多数の会議のためのメッセージを扱って経路制御できる公にアクセス可能なサーバである。一部の実施形態のテレビ会議クライアント１０１０及び１０２５のそれぞれは、上述のネットワークインタフェース９５０などのネットワークインタフェースを通じてネットワーク（例えば、セルラーネットワーク、ローカルエリアネットワーク、無線ネットワーク、ネットワークのネットワーク、インターネットなど）を介してテレビ会議サーバ１０１５と通信する。

一部の実施形態のテレビ会議要求メッセージシーケンス１０００は、テレビ会議クライアント１０１０が、デバイス１０２０とのテレビ会議開始要求をデバイス１００５のユーザから（動作１で）受信した場合に開始する。一部の実施形態のテレビ会議クライアント１０１０は、デバイス１００５のユーザがデバイス１００５に表示されるユーザインタフェースのユーザインタフェース（ＵＩ）項目を選択した場合に、テレビ会議開始要求を受信する。このようなユーザインタフェースの例は、以下で説明する図１１から図１４に示される。

テレビ会議クライアント１０１０が要求を受信した後、テレビ会議クライアント１０１０は、ユーザからの入力に基づいてデバイス１０２０を受信者として示すテレビ会議要求をテレビ会議サーバ１０１５に（動作２で）送信する。テレビ会議サーバ１０１５は、テレビ会議要求をデバイス１０２０のテレビ会議クライアント１０２５に（動作３で）転送する。一部の実施形態では、テレビ会議サーバ１０１５は、テレビ会議要求をテレビ会議クライアント１０２５にプッシュ技術を使用して転送する。すなわち、テレビ会議サーバ１０１５は、クライアント１０２５が何らかのメッセージ要求を送信するのを待つのではなく、テレビ会議クライアント１０１０から受信すると、テレビ会議クライアント１０２５へのテレビ会議要求の伝送を始める。

一部の実施形態のテレビ会議クライアント１０２５がテレビ会議要求を受信した場合に、デバイス１００５のユーザがテレビ会議開始要求を送信したことをデバイス１０２０のユーザに示し、テレビ会議要求を承諾するか又は拒否するかをデバイス１０２０のユーザに確認するために、ユーザインタフェースがデバイス１０２０に表示される。このようなユーザインタフェースの一例が、以下で説明する図１２に示されている。一部の実施形態では、テレビ会議クライアント１０２５がテレビ会議要求承諾要求をデバイス１００５のユーザから（動作４で）受信した場合に、テレビ会議クライアント１０２５は、テレビ会議サーバ１０１５にテレビ会議承諾を（動作５で）送信する。一部の実施形態のテレビ会議クライアント１０２５は、例えば、デバイス１０２０のユーザが、図１２に示されるユーザインタフェースのユーザインタフェース項目を選択した場合に、テレビ会議要求承諾要求を受信する。

テレビ会議サーバ１０１５がテレビ会議承諾をテレビ会議クライアント１０２５から受信した後、テレビ会議サーバ１０１５は、テレビ会議クライアント１０１０にテレビ会議承諾を（動作６で）転送する。テレビ会議サーバ１０１５の一部の実施形態は、上述のようにプッシュ技術を使用してテレビ会議クライアント１０１０にテレビ会議承諾を転送する。

テレビ会議承諾を受信すると、一部の実施形態では、デバイス１００５とデバイス１０２０の間にテレビ会議を（動作７で）確立する。異なる実施形態では、テレビ会議を異なるように確立する。例えば、一部の実施形態のテレビ会議確立は、デバイス１００５とデバイス１０２０の間の接続の交渉、ビデオを符号化するビットレートの決定、及びデバイス１００５とデバイス１０２０の間のビデオの交換を含む。

上記の例では、デバイス１０２０のユーザはテレビ会議要求を承諾する。一部の実施形態では、デバイス１０２０は、着信するテレビ会議要求を、ＵＩを表示せずに自動的に承諾するように（例えば、デバイスの基本設定（preference setting）によって）構成されうる。さらに、デバイス１０２０のユーザは、（例えば、デバイス１０２０に表示されるユーザインタフェースのユーザインタフェース項目を選択することによって）テレビ会議要求を（動作４で）拒否することもできる。テレビ会議承諾を送信する代わりに、テレビ会議クライアント１０２５は、テレビ会議拒否をテレビ会議サーバ１０１５に送信し、テレビ会議サーバ１０１５は、テレビ会議拒否をテレビ会議クライアント１０１０に転送する。その場合、テレビ会議は確立されない。

１．テレビ会議セットアップユーザインタフェース
一部の実施形態では、テレビ会議は、進行中の通話に基づいて始められる。すなわち、携帯デバイスのユーザが第２ユーザとの通話に関わる間に、ユーザは、他の当事者の許可を得て、通話をテレビ会議に変えることができる。本発明の一部の実施形態では、図１１は、デュアルカメラハンドヘルド携帯デバイス１１００によるこのようなテレビ会議の開始を示す。この図は、デバイス１１００のユーザインタフェース（「ＵＩ」）１１０５の５つの動作段階１１１０、１１１５、１１２０、１１２５及び１１３０としてテレビ会議の開始を示す。

図１１に示すように、ＵＩ１１０５は、名前フィールド１１３５と、選択メニュー１１４０と、選択可能ＵＩ項目１１４５とを含む。名前フィールド１１３５は、ユーザがテレビ会議要求を希望するだろう、通話の相手側の人の名前を表示する。この例では、（選択可能なボタンとして実施できる）選択可能ＵＩ項目１１４５は、ユーザが通話を終了させるために選択可能な「通話終了」オプションを提供する。選択メニュー１１４０は、スピーカフォン項目１１４２、消音項目１１４４、キーパッド項目１１４６、電話帳項目１１４８、保留項目１１５２、テレビ会議項目１１５４などの、選択可能ＵＩ項目のメニューを表示する。異なる実施形態では、選択メニューを異なるように表示する。図１１によって示される実施形態では、選択メニュー１１４０は、それぞれが異なる動作を表す、サイズの等しいいくつかのアイコンを含む。他の実施形態は、スクロール可能なメニューを提供するか、又は（例えば、項目を大きくすることによって）特定の項目を優先する。

ここで、ＵＩ１１０５の動作について、図１１に示されている５つの段階１１１０、１１１５、１１２０、１１２５及び１１３０におけるこのＵＩの状態に関して説明する。第１段階１１１０では、ハンドヘルド携帯デバイスユーザとナンシー・ジョーンズの間に通話が確立されている。第２段階１１１５は、ユーザが選択可能なテレビ会議オプション１１５４を（例えば、指１１５０によるシングルフィンガータップを通じて）選択してテレビ会議ツールを起動した後のＵＩ１１０５を表示する。この例では、（選択可能アイコンとして実施できる）テレビ会議オプション１１５４によって、ユーザが通話中にテレビ会議を開始できる。第２段階では、テレビ会議オプション１１５４は、テレビ会議ツールが起動されたことを示すために強調表示される。異なる実施形態は、異なる仕方で（例えば、項目の境界線又はテキストを強調表示することによって）このような選択を示してもよい。

第３段階１１２０は、テレビ会議オプション１１５４の選択によりデバイス１１００がテレビ会議プロセスを開始した後のＵＩ１１０５を表示する。第３段階は、テレビ会議が確立されるのをデバイスが待つ間（例えば、通話の相手側のデバイスがテレビ会議を承諾するか又は拒否するのをデバイスが待つ間）の移行待機段階である。第３段階１１２０では、デバイス１１００のユーザは、テレビ会議接続が確立されている間、依然として他のデバイスのユーザ（すなわち、ナンシー・ジョーンズ）と話をできる。さらに、一部の実施形態により、デバイス１１００のユーザは、テレビ会議要求をキャンセルするための、ＵＩ１１０５に表示された選択可能ＵＩ項目（不図示）を選択することによって、第３段階１１２０でテレビ会議要求をキャンセルできる。この待機段階において、異なる実施形態では、待ち状態を示すためにＵＩ１１０５の異なる表示を使用する。

図１１に示すように、一部の実施形態では、第３段階の待ち状態は、このビデオの下部における「プレビュー」表記と共に、デバイス１１００によって取り込まれたビデオの全画面表示として示されている。具体的には、図１１では、第３段階１１２０は、デバイスのカメラによって取り込まれているビデオの全画面提示をＵＩ１１０５の表示域１１６０に表示することによってテレビ会議処理の開始を示す。一部の実施形態では、前面カメラは、テレビ会議の開始時にデバイスによって選択されるデフォルトのカメラである。多くの場合に、この前面カメラは、テレビ会議の開始時にデバイスのユーザを指す。したがって、図１１に示される例では、第３段階１１２０は、デバイス１１００のユーザの全画面ビデオを提示するものとしてデバイス１１００を示す。デバイスの待ち状態は、第３段階１１２０中に表示域１１６０に現れるビデオの下の「プレビュー」標識１１６５によってさらに強調表示される。

移行期の第３待機段階１１２０は、一部の実施形態では異なるように表されうる。例えば、一部の実施形態により、デバイス１１００のユーザは、テレビ会議を開始するためのカメラとして背面カメラを選択できる。この選択を可能にするため、一部の実施形態により、ユーザは、テレビ会議の開始のためのデフォルトのカメラとして背面カメラを（例えば、メニューの基本設定によって）指定でき、及び／又は、ユーザは、テレビ会議オプション１１５４を選択した後で、背面カメラ及び前面カメラを表示するメニューから背面カメラを選択できる。これらの状況のいずれにおいても、ＵＩ１１０５（例えば、表示域１１６０）は、第３待機段階１１２０中に背面カメラによって取り込まれたビデオを表示する。

同様に、他の実施形態では、デバイス１１００によって取り込まれたビデオの小型バージョンを表示することによって、デバイス１１００に格納された静止画像を表示することによって、デバイスの待ち状態を強調表示するメッセージを提供することによって（例えば、「会議の確立中」を示すことによって）、「プレビュー」標識を表示しないことなどによって、テレビ会議ツールの起動を示すことができる。同様に、第３段階１１２０において、一部の実施形態のＵＩ１１０５は、ユーザがこの段階で（例えば、リモートユーザが要求に応答するのをユーザが待っている間に）テレビ会議に入らないことを決心したならば、テレビ会議に入るのをキャンセルして通話に戻ることを可能にするために、終了ボタン（不図示）を提供する。

第４段階１１２５は、リモートユーザがテレビ会議要求を承諾してテレビ会議接続が確立された後の移行状態のＵＩ１１０５を示す。この移行状態では、矢印１１７５で示されるように、（この例では、前面カメラによって取り込まれている）ローカルユーザのビデオを表示する表示域１１６０のサイズが段階的に減少する（すなわち、段階的に縮む）。表示域１１６０（すなわち、ローカルユーザのビデオ）が縮んで、その結果、ＵＩ１１０５は、リモートデバイスのカメラからのビデオを含む表示域１１７０（例えば、表示ウィンドウ１１７０）を表示域１１６０の後ろに表示できる。言い換えれば、ローカルユーザのビデオ１１６０が縮むことによって、ローカルユーザのビデオの前景挿入表示１１６０とリモートユーザの背景メイン表示１１７０とを有するＰＩＰ表示１１８０が生成される。この例では、背景メイン表示１１７０は、リモートデバイスの前面カメラによって取り込まれている婦人（例えば、リモートデバイスのユーザであるナンシー・ジョーンズ）又はリモートデバイスの背面カメラによってビデオが取り込まれている婦人（例えば、ナンシー・ジョーンズによってビデオが取り込まれている婦人）のビデオを提示する。図１１に示される移行期の第４段階が一部の実施形態によって使用される１つの例示的な手法に過ぎず、他の実施形態は移行期の第４段階を異なるようにアニメーション化できることが当業者には理解されよう。

第４段階１１２５は、下部の表示域１１５５にある選択可能ＵＩ項目１１３２も示す。（選択可能なボタンとして実施されうる）選択可能ＵＩ項目１１３２は、ＰＩＰ表示１１８０の下に、選択可能会議終了オプション１１３２を提供する。ユーザは、この会議終了オプション１１３２を選択して（例えば、シングルフィンガータップを通じて）、テレビ会議を終了できる。異なる実施形態により、ユーザは、携帯デバイス上のスイッチを切り換えることによって、音声コマンドを与えることによってなどの、異なる仕方で、会議を終了してもよい。さらに、異なる実施形態により、会議終了オプション１１３２がテレビ会議中に表示されなくなることができ、それによって、ＰＩＰ表示１１８０が表示域１１８５全体を占有してもよい。その後、表示域１１８５の下部をシングルフィンガータップすると、会議終了オプション１１３２が再表示され、会議終了オプション１１３２へのアクセスをユーザに提供できる。一部の実施形態では、表示域１１５５のレイアウトは、以下でさらに詳細に説明する表示域１１５５と同じである。

第５段階１１３０は、第４移行状態１１２５のアニメーションが終了した後のＵＩ１１０５を示す。具体的には、第５段階１１３０は、テレビ会議中にＵＩ１１０５によって提示されるＰＩＰ表示１１８０を示す。上述のように、このＰＩＰ表示１１８０は、２つのビデオ表示、すなわちリモートカメラからの大きい方の背景表示１１７０と、ローカルカメラからの小さい方の前景挿入表示１１６０とを含む。

このＰＩＰ表示１１８０は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの仕方にすぎない。この合成ビューに加えて、一部の実施形態のデバイスは、他の合成ビューを提供する。例えば、リモートユーザに関する大きい方の背景表示１１７０を有する代わりに、大きい方の背景表示１１７０は、ローカルユーザに関するものにでき、小さい方の前景挿入表示１１６０はリモートユーザに関するものにできる。以下でさらに説明するように、一部の実施形態により、ユーザは、ＰＩＰ表示１１８０の挿入ビュー及びメインビュー用のカメラとしてローカルカメラ及び／又はリモートカメラをテレビ会議中に切り換えることができる。

同様に、一部の実施形態により、ローカルビデオ及びリモートビデオは、ＵＩ１１０５内の並んだ２つの表示域（例えば、左右の表示ウィンドウ、又は上下の表示ウィンドウ）又は斜めに整列した２つの表示域に表示されうる。以下でさらに説明するように、ＰＩＰ表示の仕方又はデフォルトの表示モードは、一部の実施形態では、デバイスの基本設定を通じて又はテレビ会議中にユーザが選択できる制御を通じてユーザによって指定されてもよい。

図１１のデバイス１１００のユーザがリモートユーザをテレビ会議に招待した場合に、リモートユーザは、その招待を承諾してもよいし、拒否してもよい。図１２は、リモートユーザのデバイスでテレビ会議招待を提示し承諾するための動作のシーケンスを示す６つの異なる段階１２１０、１２１５、１２２０、１２２５、１２３０及び１２３５におけるリモートユーザのデバイス１２００のＵＩ１２０５を示す。ＵＩ１２０５の以下の説明は、デバイス１２００（すなわち、テレビ会議要求を受信するデバイス）のユーザを招待受信者と呼び、デバイス１１００（すなわち、テレビ会議要求を送信するデバイス）のユーザを招待依頼者と呼ぶ。また、この例では、招待受信者のデバイス１２００は、招待依頼者のデバイスのように、デュアルカメラデバイスであると想定される。しかし、他の例では、これらのデバイスの一方又は両方はシングルカメラデバイスである。

第１段階１２１０は、招待受信者が招待依頼者のジョン・スミスからテレビ会議への招待を受信したときのＵＩ１２０５を示す。図１２に示すように、この段階のＵＩ１２０５は、名前フィールド１２３５と、メッセージフィールド１２４０と、２つの選択可能ＵＩ項目１２４５及び１２５０とを含む。名前フィールド１２３５には、テレビ会議を要求している人の名前が表示される。一部の実施形態では、名前フィールド１２３５には、テレビ会議を要求している人の名前の代わりに、その人の電話番号が表示される。メッセージフィールド１２４０には、招待依頼者から招待受信者への招待が表示される。この例では、フィールド１２４０の「テレビ会議招待」は、招待依頼者が招待受信者とのテレビ会議を要求していることを示す。（選択可能ボタンとして実施されうる）選択可能ＵＩ項目１２４５及び１２５０は、招待受信者が招待を拒否するか承諾するために使用するための選択可能な要求拒否オプション１２４５及び要求承諾オプション１２５０を提供する。異なる実施形態では、これらのオプションを異なるように表示し、及び／又は他のオプションを表示できる。

招待受信者は、「テレビ会議招待」表記がメッセージフィールド１２４０に表示されているのを見たら、ＵＩの要求拒否オプション１２４５又は要求承諾オプション１２５０をそれぞれ選択することによって、要求を拒否するか、承諾することができる。第２段階１２１５は、図１２に示される例においてユーザが要求承諾オプション１２５０を選択することを示す。この例では、この選択は、ユーザの指が要求承諾オプション１２５０をタップすることによってなされ、この選択は、このオプション１２５０の強調表示によって示されている。一部の実施形態では、選択を示す（例えば、ＵＩ項目の境界線又はテキストを強調表示する）ために要求承諾オプション１２４５又は要求拒否オプション１２５０を選択する他の技術（例えば、ダブルタップなど）が提供される。

第３段階１２２０は、招待受信者がテレビ会議への参加に同意した後のＵＩ１２０５を示す。この段階では、ＵＩ１２０５は、リモートデバイスの前面カメラからのビデオの全画面提示を表示域１２４４に示すプレビューモードに入る。前面カメラは、この場合、リモートデバイスのユーザ（すなわち、この例ではナンシー・ジョーンズ）に向けられる。したがって、このプレビューモードでは、彼女の画像が示される。このプレビューモードによって、招待受信者は、自分のビデオが適切に表示され、テレビ会議が始まる前（例えば、ビデオの実際の伝送が始まる前）に自分の外見に満足することを確認できる。一部の実施形態では、招待受信者がプレビューモードであることを示すために、「プレビュー」表記などの表記が表示域１２４４の下に表示されてもよい。

以下でさらに説明するように、一部の実施形態により、招待受信者は、テレビ会議の開示時のデフォルトのカメラとして背面カメラを選択でき、又はテレビ会議の冒頭で前面カメラ又は背面カメラを選択できる。また、他の実施形態では、招待受信者のプレビュー表示が、異なるように（例えば、表示域１２４４の隅に置かれた小さい方の画像に）表示される。さらに他の実施形態では、このプレビューモードを含まず、招待受信者が要求を承諾した直後にテレビ会議を開始する。

第３段階では、ＵＩ１２０５は、２つの選択可能ＵＩ項目１２７５及び１２４６を示し、その一方は表示域１２４４に重なり、他方は、この表示域１２４４の下にある。選択可能ＵＩ項目１２７５は、テレビ会議を開始するためにユーザが選択してもよい承諾ボタン１２７５である。選択可能ＵＩ項目１２４６は、招待受信者がこの段階でテレビ会議に参加しないことを決めた場合に選択できる終了ボタン１２４６である。

第４段階１２２５は、招待受信者が承諾ボタン１２７５を選択した後のＵＩ１２０５を示す。この例では、承諾ボタン１２７５は、招待受信者がテレビ会議を開始する準備ができたことを示すように強調表示されている。このような選択は、他の実施形態では、異なる仕方で示されうる。

第５段階１２３０は、招待受信者がテレビ会議要求を承諾した後の移行状態であるＵＩ１２０５を示す。この移行段階では、矢印１２６０で示されるように、（この例では、前面カメラによって取り込まれている）招待受信者のビデオを表示する表示域１２４４のサイズが段階的に減少する（すなわち、段階的に縮む）。招待受信者のビデオが縮んで、その結果、ＵＩ１２０５は、招待依頼者のカメラからのビデオを表示域１２４４の後ろに含む表示域１２６５（例えば、表示ウィンドウ１２６５）を表示できる。言い換えれば、招待受信者のビデオが縮むことによって、招待受信者のビデオの前景挿入表示域１２４４と招待依頼者の背景メイン表示１２６５とを有するＰＩＰ表示１２８０が生成される。

この例では、背景メイン表示１２６５は、ローカルデバイスの前面カメラによってビデオが取り込まれている男性のビデオ（すなわち、ローカルデバイス１１００のユーザであるジョン・スミス）を提示する。別の例では、このビデオは、ローカルデバイスの背面カメラによってビデオが取り込まれている男性（例えば、ジョン・スミスによってビデオが取り込まれている男性）のビデオにできる。異なる実施形態では、この移行期の第５段階を異なるようにアニメーション化できる。

第５段階１２３０におけるＵＩは、以下でさらに詳細に説明する、テレビ会議中に他のユーザの音声を消音するための選択可能ＵＩ項目１２８５（例えば、消音ボタン１２８５）と、テレビ会議を終了するための選択可能ＵＩ項目１２８７（例えば、会議終了ボタン１２８７）と、カメラを切り換えるための選択可能ＵＩ項目１２８９（例えば、カメラ切り換えボタン１２８９）とを含む表示域１１５５（例えば、ツールバー又はメニューバー）も表示する。したがって、招待受信者は、テレビ会議中に所望の動作を実行するために、選択可能ＵＩ項目１２８５〜１２８９のいずれかを（例えば、シングルフィンガータップによって）選択できる。異なる実施形態により、招待受信者は、例えば、携帯デバイス上のスイッチを切り換えることによって、音声コマンドを与えることによってなどのような、異なる仕方の動作のいずれかを実行できる。

図１２は、表示域１１５５の例示的なレイアウトを示しているが、一部の実施形態は、テレビ会議を終了するための会議終了の選択可能ＵＩ項目１１３２だけを含む、図１１の表示域１１５５のレイアウトなどの表示域１１５５の異なるレイアウトを提供する。表示域１１５５の他のレイアウトは、異なる機能を実行するための任意の数の異なる選択可能ＵＩ項目を含むことができる。さらに、第５段階１２３０は、ＵＩ１２０５の下部に表示された表示域１１５５を示す。表示域１１５５の異なる実施形態は、ＵＩ１２０５内部の異なる位置に表示されうるか、及び／又は異なる形状として規定されうる。

図１２は、表示域１１５５を静的な表示域として示す（すなわち、表示域１１５５は常に表示される）。しかし、一部の実施形態では、表示域１１５５は動的な表示域である。いくつかのこのような実施形態では、表示域１１５５は、通常は表示されない。むしろ、表示域１１５５は、トリガになるイベント（例えば、表示域１２８０をこのように一回タップするユーザの選択、音声コマンドなど）が受け取られた場合に表示される。ユーザの選択が受け取られた（例えば、選択可能消音ＵＩ項目１２８５を選択する）又は定義された時間量（例えば、３秒）の後で、表示域１１５５は非表示になり、この時間量は、携帯デバイス又はテレビ会議アプリケーションの基本設定を通じてユーザによって指定されうる。一部のこのような実施形態では、表示域１１５５は、テレビ会議が開始した後で自動的に表示され、上述した同じ仕方で非表示になる。

第６段階１２３５は、第５移行段階のアニメーションが終了した後のＵＩ１２０５を示す。具体的には、第６段階は、テレビ会議中にＵＩ１２０５によって提示されるＰＩＰ表示１２８０を示す。上述のように、このＰＩＰ表示１２８０は、２つのビデオ表示、すなわちローカルカメラからの大きい方の背景表示１２６５と、リモートカメラからの小さい方の前景挿入表示１２４４とを含む。このＰＩＰ表示１２８０は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの仕方にすぎない。この合成ビューに加えて、一部の実施形態のデバイスは、他の合成ビューを提供する。例えば、招待受信者に関する大きい方の背景表示を有する代わりに、大きい方の背景表示は、招待依頼者に関するものにでき、小さい方の前景挿入表示は招待受信者に関するものにできる。以下でさらに説明するように、一部の実施形態により、ユーザは、ローカルカメラ及びリモートカメラを切り換え可能に表示するようにＰＩＰ表示の挿入ビュー及びメインビューを制御できる。同様に、一部の実施形態により、ローカルビデオ及びリモートビデオは、ＵＩ１２０５内の並んだ２つの表示域（例えば、左右の表示ウィンドウ、又は上下の表示ウィンドウ）又は斜めに整列した２つの表示域に表示されうる。以下でさらに説明するように、ＰＩＰ表示の方式又はデフォルトの表示モードは、一部の実施形態では、デバイスの基本設定を通じて又はテレビ会議中にユーザが選択できる制御を通じてユーザによって指定されてもよい。

図１２は、テレビ会議招待を提示して承諾するための動作のシーケンスを、６つの異なる動作段階として示しているが、一部の実施形態では、より少ない数の段階で動作を実施できる。例えば、このような実施形態のうちの一部では、第３段階１２２０及び第４段階１２２５を提示することを省略し、ユーザが要求承諾オプション１２５０を選択した後で第２段階１２１５から第５段階１２３０に進むことができる。より少ない数の段階でその動作（すなわち、テレビ会議招待を提示して承諾すること）を実施する他の実施形態では、第１段階１２１０及び第２段階１２１５を省略し、招待受信者が招待依頼者からテレビ会議への招待を受信した場合に、ユーザに第３段階１２２０を提示できる。

図１３は、第１段階と第３段階とを１つの段階に結合し、かつ第２段階と第４段階とを１つの段階に結合することによって、より少ない数の段階で図１２に示される動作を実行する一例を示す。具体的には、この図は、５つの異なる段階１３９０、１３９２、１３９４、１２３０及び１２３５におけるリモートユーザのデバイス１２００のＵＩ１２０５を示す。第１段階１３９０は、通話の相手側の人の名前を示すために名前フィールド１２３５が名前「ジョン・スミス」を表示することを除いて、段階１１１０と同様である。すなわち、リモート携帯デバイスのユーザとローカルデバイスのユーザ（すなわち、この例ではジョン・スミス）との間に通話が確立されている。第２段階１３９２及び第３段階１３９４は、第２段階１３９２及び第３段階１３９４ではリモート携帯デバイスのユーザ（すなわち、この例ではナンシー・ジョーンズ）のプレビューも示されることを除いて、図１２の第１段階１２１０及び第２段階１２１５と同様である。第４段階１２３０及び第５段階１２３５は、図１２の第５段階１２３０及び第６段階１２３５と同じである。

通話中に選択可能なオプションを通じてテレビ会議ツールを起動することに加えて、一部の実施形態により、デュアルカメラデバイスのユーザは、最初に電話をかける必要なしにテレビ会議を直接始めることができる。図１４は、テレビ会議を始める別のこのような代替方法を示す。この図は、テレビ会議を開始するための動作の代替シーケンスを示す７つの異なる段階１４１０、１４１５、１４２０、１４２５、１４３０、１４３５及び１４４０におけるＵＩ１４０５を示す。

第１段階１４１０では、ユーザは、電話する連絡先をどのようにして探すかと同様にして、この携帯デバイスの連絡先リストからユーザがテレビ会議で関与したい人を探している。第２段階１４１５では、ユーザは、ユーザがテレビ会議を行いたい人１４５５を（例えば、人の名前１４５５へのシングルフィンガータップ１４６０を通じて）選択する。この選択は、連絡先の情報及び種々のユーザ選択可能なオプションを表示するＵＩ１４０５をトリガする。この例では、ジョンソンの名前１４５５が強調表示されて、これが、ユーザがテレビ会議を行いたい人であることを示す。異なる実施形態は、このような選択を異なる仕方で示すことができる。第２段階１４１５では、デバイス１４００のユーザは、ユーザがテレビ会議を行いたい人を連絡先リストを通じて選択できるが、一部の実施形態により、ユーザは、デバイス１４００のユーザが最近テレビ会議又は通話を行った人の具体的な番号又は名前をリストする「最近」の通話履歴を通じて人を選択できる。

第３段階１４２０では、ＵＩ１４０５は、人の名前１４５５が選択された後に、選択された人の情報１４６２並びに種々の選択可能ＵＩ項目１４６８、１４７２及び１４７０を表示する。この例では、（選択可能なアイコン又はボタンとして実施できる）種々の選択可能ＵＩ項目１４７２のうちの１つは、テレビ会議ツールを提供する。テレビ会議オプション１４７２を使用して、ユーザは、連絡先１４６６によって識別された人をテレビ会議に招待できる。異なる実施形態では、情報１４６２並びに選択可能ＵＩ項目１４６８、１４７２及び１４７０が異なるように（例えば、異なる構成で）表示される。

第４段階１４２５は、ユーザがテレビ会議オプション１４７２を（例えば、シングルフィンガータップを通じて）選択することを示す。この例では、テレビ会議オプション１４７２は、テレビ会議ツール１４７２が起動されたことを示すために強調表示される。このような選択は、異なる実施形態で異なるように（例えば、選択されたアイコンのテキスト又は境界線を強調表示することによって）示されうる。

第５段階１４３０、第６段階１４３５及び第７段階１４４０は、図１１に示される第３段階１１２０、第４段階１１２５及び第５段階１１３０と同様であり、これらの段階の説明を参照することによって理解されうる。要するに、第５段階１４３０は、リモートユーザがテレビ会議への招待に応答するのを待つ移行待機段階を示す。第６段階１４３５は、リモートユーザがテレビ会議要求を承諾した後で、（ローカルユーザのビデオを表示する）表示域１４８０のサイズが段階的に減少し、したがってＵＩ１４０５はリモートユーザのカメラからのビデオを含む表示域１４９２を表示域１４８０の後ろに示すことができることを示す。第７段階１４４０では、ＰＩＰ表示１４４７がテレビ会議中にＵＩ１４０５によって提示される。一部の実施形態では、第６段階１４３５及び第７段階１４４０における表示域１１５５のレイアウトは、上述の図１２の表示域１１５５のレイアウトに似ている。

図１０、図１１、図１２、図１３及び１４は、テレビ会議を確立するいくつかの仕方を示す。一部の実施形態では、通話中に、オーディオデータ（例えば、声）が１つの通信チャネルを通じて（回線交換通信ネットワーク又はパケット交換通信ネットワークのような通信ネットワークを介して）伝送され、テレビ会議中に、オーディオデータが別の通信チャネルを通じて伝送される。したがって、このような実施形態では、テレビ会議が確立される前にオーディオデータ（例えば、声）が通信チャネルを通じて伝送され、テレビ会議が確立されると、オーディオが（通話中に使用される通信チャネルの代わりに）異なる通信チャネルを通じて伝送される。

通話からテレビ会議へのオーディオデータの切れ目のない移行（例えば、ハンドオフ）を提供するために、一部の実施形態では、テレビ会議を確立する前に通話を終わらせない。例えば、一部の実施形態では、（例えば、図１０に示されるメッセージシーケンスを完了した後で）ピアツーピアテレビ会議接続を確立してから、通話を終わらせ、ピアツーピア通信セッションを通じてオーディオ／ビデオデータを送信し始める。あるいは、他の実施形態では、（例えば、図１０に示されるメッセージシーケンスを完了した後で）ピアツーピアテレビ会議接続を確立し、ピアツーピアテレビ会議セッションを通じてオーディオ／ビデオデータを送信し始めてから、通話を終わらせ、受信したオーディオ／ビデオデータを提示し始める。

一部の実施形態のピアツーピアテレビ会議接続により、テレビ会議中の携帯デバイスは、（例えば、中央サーバを通じて通信する代わりに）互いと直接通信できる。ピアツーピアテレビ会議の一部の実施形態によって、テレビ会議中の携帯デバイスが、リソースを互いと共有しうる。例えば、以下でさらに詳細に説明するように、テレビ会議の制御通信チャネルを通じて、１つの携帯デバイスは、露出調整動作、焦点調整動作及び／又はカメラ切り換え動作などの、画像を異なるように処理する（すなわち、その画像処理リソースを共有する）ように他の携帯デバイスに指示するために１つの携帯デバイスから他の携帯デバイスに命令を送信することによって、テレビ会議中に別の携帯デバイスの動作を遠隔制御できる。

２．動的なビットレートのセットアップ
典型的に、テレビ会議中の携帯デバイスは、さまざまなプライベート及びパブリックの無線通信ネットワーク（例えば、ＧＳＭ、ＵＭＴＳなどのようなセルラーネットワーク）などのさまざまなタイプの通信ネットワークの通信チャネルを通じて、データ（例えば、オーディオ及びビデオ画像）を互いに通信する。以下では、このような無線通信ネットワークの例について、図９１及び図９２に関して説明する。

所与の時間に通信ネットワークにアクセスする携帯デバイスの数が変わることに起因して、テレビ会議を行うための通信ネットワークの利用可能な帯域幅は、時間によって異なる。利用可能な帯域幅は、テレビ会議中ですら変化しうる。さらに、最適なテレビ会議ビットレートを追跡しようとしてテレビ会議中に高いビットレート又は大量のシグナリングで通信ネットワークをあふれさせることは、望ましくない。

これらの理由のため、一部の実施形態では、テレビ会議に最適な初期ビットレートを特定するための新規な方法を採用する。テレビ会議に最適な初期ビットレートを識別するため、この方法は、特定のビットレートでテレビ会議を開始し、これらの実施形態でテレビ会議品質を劣化させるネットワーク状態が検出されないならば、特定の間隔でビットレートを漸増する。

このような実施形態の一例が図１５に示されている。この図は、テレビ会議用のビットレートを設定するための本発明の一部の実施形態のプロセス１５００を概念的に示す。プロセス１５００は、種々のネットワーク状態に基づいてデータ（例えば、オーディオ及びビデオ画像）を送信するためのビットレートを動的に決定するために、テレビ会議セットアップの一部として（例えば、図１０に示されるテレビ会議の確立の一部として）実行される。一部の実施形態では、プロセス１５００は、図９に関して上述したテレビ会議モジュール９２５の管理層９３５によって実行される。このテレビ会議モジュールのより詳細なバージョンについて、以下で図１６に関して説明する。

図１５に示すように、プロセス１５００は、（１５０５において）ビットレートを初期ビットレートに設定することによって開始する。一部の実施形態では、初期ビットレートは、デバイスのデフォルトのベースラインレートである。しかし、一部の実施形態では、ユーザが初期ビットレートを指定できる。１５０５において、プロセス１５００はまた、１つ以上の通信チャネルを通じてリモートデバイスにデータ（例えば、オーディオ及びビデオ画像）を初期ビットレートで伝送するテレビ会議を開始する。

次に、プロセス１５００は、（１５１０において）テレビ会議でリモートデバイスから受信したネットワーク状態パラメータ集合を識別する。一部の実施形態では、ローカルデバイスは、テレビ会議の開始時に確立されたリアルタイムトランスポートプロトコル（ＲＴＰ）通信セッションを通じてリモートデバイスからネットワーク状態パラメータ集合を受信する。例えば、一部の実施形態は、ＲＴＰの拡張機能を通じてネットワーク状態パラメータを提供する。さらに、一部の実施形態のＲＴＰ拡張機能は、ＲＴＰパケットヘッダ内の拡張ヘッダの存在を示し、追加情報のための拡張ヘッダを定義することによって、いかなるタイプの情報（ネットワーク状態パラメータ集合など）も送信するために使用されうる。

異なる実施形態では、テレビ会議中のデバイスは、ネットワーク状態／輻輳パラメータの異なる集合を中継する。以下で説明する実施形態では、ネットワーク状態パラメータ集合は、片道レイテンシ及び帯域幅推定ビットレートを含む。他の実施形態では、ネットワーク状態パラメータ集合は、パケット損失データ及びラウンドトリップ時間（ＲＴＴ）遅延データを含む。したがって、異なる実施形態は、ネットワーク状態パラメータ集合に任意の数の異なるネットワーク状態パラメータを含むことができる。

一部の実施形態では、テレビ会議のリモートデバイスから受信されるネットワーク状態パラメータ集合は、動作１５０５において設定された初期ビットレートでテレビ会議中にローカル携帯デバイス（すなわち、プロセス１５００を実行する携帯デバイス）からリモートデバイスに伝送されるデータ（例えば、オーディオ及びビデオ）に基づく。例えば、一部の実施形態では、リモートデバイスは、オーディオパケットがローカル携帯デバイスからリモートデバイスにネットワーク接続を通じて伝播するのにかかる時間をオーディオパケットのタイムスタンプを使用して算出することによって、片道レイテンシを決定できる。具体的には、一部の実施形態では、各オーディオパケットにはタイムスタンプが付される。パケット遅延がない場合、リモートデバイスは、タイムスタンプの差に等しい設定された間隔でオーディオパケットを受信するはずである。しかし、片道レイテンシ遅延がある場合、リモートデバイスは、タイムスタンプの差よりも大きい間隔でオーディオパケットを受信する。

また、一部の実施形態では、リモートデバイスは、ビデオパケットが受信された時刻、連続するビデオパケットが受信された時刻、及び連続するビデオパケットのサイズを調べることによって、帯域幅推定ビットレートを決定する。すなわち、２つの連続するビデオパケットの受信時刻の差と第２ビデオパケットのサイズとは、ネットワーク接続の利用可能な帯域幅を推定するために使用される。一部の実施形態では、複数ペアの連続するビデオパケットを調べることによって帯域幅推定ビットレートが決定される。上記の例では、特定のタイプのデータ（すなわち、片道レイテンシを決定するためのオーディオデータ及び帯域幅推定ビットレートを決定するためのビデオデータ）を使用する。しかし、一部の実施形態では、ローカル携帯デバイスとリモートデバイスの間でネットワーク接続を通じて通信された他のタイプのデータも使用されうる。

（１５１０において）ネットワーク状態の集合を識別した後で、プロセス１５００は、その後、定義されたしきい値量を超えて片道レイテンシが劣化したかどうかを（１５１５において）判定する。一部の実施形態では、しきい値量は特定のレイテンシ量として定義され、片道レイテンシは、現在の片道レイテンシと以前の片道レイテンシとの差が特定のレイテンシ量を超えた場合にしきい値量を超えて劣化したと判定される。他の実施形態では、しきい値量は、片道レイテンシの特定の変化率として定義される。したがって、片道レイテンシは、片道レイテンシの集合（例えば、現在の片道レイテンシと以前の片道レイテンシ）の変化率が特定の変化率を超えた場合にしきい値量を超えて劣化したと判定される。

片道レイテンシがしきい値量を超えて劣化すると判定された場合に、プロセス１５００が終了する。そうでない場合に、プロセス１５００は、現在のビットレートが帯域幅推定ビットレートに達したかどうかを（１５２０において）はネイする。一部の実施形態では、帯域幅推定ビットレートは、ネットワーク接続に利用可能な帯域幅の量（例えば、１５キロビット／秒（ｋｂｐｓ））を示す。現在のビットレートが帯域幅推定ビットレートを超えたとプロセス１５００が判定した場合に、プロセス１５００は終了する。現在のビットレートが帯域幅推定ビットレートを超えていないとプロセス１５００が判定した場合に、プロセス１５００は動作１５２５に進む。

１５２５において、プロセス１５００は、現在のビットレートが、規定の最大ビットレートに達したかどうかを判定する。現在のビットレートが、規定の最大ビットレートを超えたとプロセス１５００が判定した場合に、プロセス１５００は終了する。そうでない場合に、プロセス１５００は動作１５３０に進み、規定の量だけ現在のビットレートを増加させる。異なる実施形態では、ビットレートを増加させる量を異なるように規定する。現在のビットレートを増加させる規定の量の例は、ビットレートを増加させる任意の数の他の量の中でとりわけ、３２ｋｂｐｓ、６４ｋｂｐｓを含む。

次に、プロセスは、規定の時間量が経過したかどうかを（１５３５において）判定する。異なる実施形態では時間量を異なるように規定するので、この規定の時間量は、１秒、２秒、５秒、又は他の任意の取りうる時間量でありうる。リモートデバイスが、（動作１５３０において）新たな増加したビットレートでローカル携帯デバイスから伝送されたデータ（例えば、オーディオ及びビデオ画像）を受信し、新たな増加したビットレートに基づいてネットワーク状態パラメータを決定するために、プロセス１５００は、規定の時間量が経過するのを待つ。規定の時間量が経過していないとプロセス１５００が判定した場合に、プロセス１５００は、規定の時間量が経過するまで、動作１５３５に戻る。規定の時間量が経過したとプロセス１５００が判定した場合に、プロセス１５００は動作１５１０に戻る。プロセス１５００の動作は、プロセス１５００が終了するまで、上述したように１５１０から先に進む。

プロセス１５００が終了する場合に（すなわち、動作１５１５、１５２０又は１５２５の後）、テレビ会議のためのビットレートのセットアップは完了しており、最適なビットレートが決定されている。テレビ会議に利用可能な帯域幅はテレビ会議中に変わりうるので、一部の実施形態は、リモートデバイスから受信されたネットワーク状態パラメータの集合（すなわち、片道レイテンシ及び帯域幅推定ビットレート）に基づいてビットレートを調整し続ける。ビットレートを増加させることによって、テレビ会議中にビットレートが調整されうる。例えば、規定のしきい値量を超えて片道レイテンシが劣化したのでプロセス１５００が終了し、テレビ会議中に片道レイテンシが改善したならば、一部の実施形態では、ビットレートが増加される。同様に、ビットレートが帯域幅推定ビットレートを超えたのでプロセス１５００が終了し、テレビ会議中に、帯域幅推定ビットレートが増加したならば、一部の実施形態では、ビットレートが増加される。

対照的に、ビットレートを減少させることによって、テレビ会議中にビットレートが調整されうる。例えば、規定のしきい値量を超えて片道レイテンシがテレビ会議中に劣化し続けるならば、一部の実施形態では、ビットレートが減少される。また、ビットレートがテレビ会議中に帯域幅推定ビットレートを超え続ける（例えば、帯域幅推定ビットレートが減少し続ける）ならば、一部の実施形態では、ビットレートが減少される。

さらに、プロセス１５００の説明では、ビットレートを増加させるかどうかを判定するために片道レイテンシ及び帯域幅推定ビットレートを使用する。しかし、異なる実施形態では、任意の数のネットワーク状態パラメータが、ビットレートを増加させるかどうかを判定するために使用できることが当業者に理解されよう。例えば、ビットレートを増加させるかどうかの判定は、単にＲＴＴ遅延データ又はパケット損失データだけに基づくことができる。

Ｃ．テレビ会議アーキテクチャ
上述のように、図１６は、一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュール１６００のためのソフトウェアアーキテクチャを概念的に示す。図示のように、テレビ会議及び処理モジュール１６００は、クライアントアプリケーション１６６５と、テレビ会議モジュール１６０２と、メディア交換モジュール１６２０と、バッファ１６２５と、取り込み済画像処理ユニット（ＣＩＰＵ）ドライバ１６３０と、エンコーダドライバ１６３５と、デコーダドライバ１６４０とを含む。一部の実施形態では、バッファ１６２５は、デュアルカメラ携帯デバイスのディスプレイ１６４５に表示するためのビデオの画像を格納するフレームバッファである。

一部の実施形態では、クライアントアプリケーション１６６５は、図９のテレビ会議クライアント９４５と同じである。上述のように、クライアントアプリケーション１６６５は、別のアプリケーションに統合されてもよいし、スタンドアロンアプリケーションとして実施されてもよい。クライアントアプリケーション１６６５は、テレビ会議アプリケーション、ボイスオーバーＩＰ（ＶＯＩＰ）アプリケーション（例えば、スカイプ）、又はインスタントメッセージングアプリケーションなどのテレビ会議モジュール１６０２のテレビ会議機能を使用するアプリケーションであってもよい。

一部の実施形態のクライアントアプリケーション１６６５は、会議を開始する命令及び会議を終了する命令などの命令をテレビ会議モジュール１６０２に送信し、テレビ会議モジュール１６０２から命令を受信し、命令をデュアルカメラ携帯デバイスのユーザからテレビ会議モジュール１６０２に経路制御し、デュアルカメラ携帯デバイスに表示されてユーザにアプリケーションとの対話を可能にするユーザインタフェースを生成する。

Ｄ．テレビ会議マネージャ
図１６に示すように、テレビ会議モジュール１６０２は、テレビ会議マネージャ１６０４と、画像処理マネージャ１６０８と、ネットワーキングマネージャ１６１４と、バッファ１６０６、１６１０、１６１２、１６１６及び１６１８とを含む。一部の実施形態では、テレビ会議モジュール１６０２は、図９に示されるテレビ会議モジュール９２５と同じであり、したがって、テレビ会議モジュール９２５に関して上述した同じ機能のうちの一部又は全部を実行する。

一部の実施形態では、テレビ会議マネージャ１６０４は、テレビ会議が開始する際のテレビ会議モジュール１６０２の他のモジュールのうちの一部（例えば、画像処理マネージャ１６０８及びネットワーキングマネージャ１６１４）又は全部の初期化、テレビ会議中のテレビ会議モジュール１６０２の動作の制御、及びテレビ会議が終了した際のテレビ会議モジュール１６０２の他のモジュールの一部又は全部の動作の中止を担当する。

一部の実施形態のテレビ会議マネージャ１６０４は、テレビ会議で１つ以上のデバイスから受信された画像及びデュアルカメラ携帯デバイスに表示するためにデュアルカメラ携帯デバイスの両方のカメラのうちの１つによって取り込まれた画像も処理する。例えば、一部の実施形態のテレビ会議マネージャ１６０４は、テレビ会議に参加している別のデバイスから受信された復号済みの画像をバッファ１６１８から読み出し、ＣＩＰＵ１６５０によって処理された画像（すなわち、デュアルカメラ携帯デバイスによって取り込まれた画像）をバッファ１６０６から読み出す。一部の実施形態では、テレビ会議マネージャ１６０４はまた、デュアルカメラ携帯デバイスに画像を表示する前に、画像を拡大縮小し、合成する。すなわち、テレビ会議マネージャ１６０４は、一部の実施形態では、携帯デバイスに表示するＰＩＰビュー又は他の合成ビューを生成する。一部の実施形態では、バッファ１６０６及び１６１８から読み出された画像を拡大縮小するが、他の実施形態では、単にバッファ１６０６及び１６１８のうちの一方から読み出された画像だけを拡大縮小する。

図１６は、テレビ会議モジュール１６０２の一部としてテレビ会議マネージャ１６０４を示しているが、テレビ会議マネージャ１６０４の一部の実施形態は、テレビ会議モジュール１６０２とは別個のコンポーネントとして実施される。したがって、単一のテレビ会議マネージャ１６０４は、いくつかのテレビ会議モジュール１６０２を管理及び制御するために使用されうる。例えば、一部の実施形態では、複数当事者による会議中に各当事者と対話するためにローカルデバイス上で別個のテレビ会議モジュールを実行し、ローカルデバイス上のこれらのテレビ会議モジュールのそれぞれは、１つのテレビ会議マネージャによって管理及び制御される。

一部の実施形態の画像処理マネージャ１６０８がデュアルカメラ携帯デバイスのカメラによって取り込まれた画像を処理してから、画像がエンコーダ１６５５によって符号化される。例えば、画像処理マネージャ１６０８の一部の実施形態では、ＣＩＰＵ１６５０によって処理された画像に関する露出調整、焦点調整、パースペクティブ補正、ダイナミックレンジ調整及び画像サイズ変更のうちの１つ以上を実行する。一部の実施形態では、画像処理マネージャ１６０８は、テレビ会議で他のデバイスに伝送された符号化済みの画像のフレームレートを制御する。

ネットワーキングマネージャ１６１４の一部の実施形態は、デュアルカメラ携帯デバイスとテレビ会議に参加している他のデバイスとの間の１つ以上の接続を管理する。例えば、一部の実施形態のネットワーキングマネージャ１６１４は、テレビ会議の開始時にデュアルカメラ携帯デバイスとテレビ会議の他のデバイスとの間の接続を確立し、テレビ会議の終了時にこれらの接続を切断する。

テレビ会議中に、ネットワーキングマネージャ１６１４は、エンコーダ１６５５によって符号化された画像をテレビ会議の他のデバイスに伝送し、テレビ会議の他のデバイスから受信された画像を復号のためにデコーダ１６６０に経路制御する。一部の実施形態では、画像処理マネージャ１６０８ではなくネットワーキングマネージャ１６１４が、テレビ会議の他のデバイスに伝送された画像のフレームレートを制御する。例えば、ネットワーキングマネージャ１６１４の一部のこのような実施形態は、テレビ会議の他のデバイスに伝送されたと想定される符号化されたフレームの一部を破棄する（すなわち、伝送しない）ことによって、フレームレートを制御する。

図示のように、一部の実施形態のメディア交換モジュール１６２０は、カメラソースモジュール１６２２と、ビデオ圧縮器モジュール１６２４と、ビデオ伸張器モジュール１６２６とを含む。メディア交換モジュール１６２０は、図３に示されるメディア交換モジュール３１０と同じであり、これについて、より詳細に説明する。カメラソースモジュール１６２２は、ＣＩＰＵドライバ１６３０を通じてテレビ会議モジュール１６０２とＣＩＰＵ１６５０との間のメッセージ及びメディアコンテンツを経路制御し、ビデオ圧縮器モジュール１６２４は、エンコーダドライバ１６３５を通じてテレビ会議モジュール１６０２とエンコーダ１６５５との間のメッセージ及びメディアコンテンツを経路制御し、ビデオ伸張器モジュール１６２６は、デコーダドライバ１６４０を通じてテレビ会議モジュール１６０２とデコーダ１６６０との間のメッセージ及びメディアコンテンツを経路制御する。一部の実施形態では、カメラソースモジュール１６２２の一部としてメディア交換モジュール３１０に含まれるＴＮＲモジュール３１５（図１６で不図示）を実施するが、他の実施形態では、ビデオ圧縮器モジュール１６２４の一部としてＴＮＲモジュール３１５を実施する。

一部の実施形態では、ＣＩＰＵドライバ１６３０及びエンコーダドライバ１６３５は、図３に示されるＣＩＰＵドライバ３０５及びエンコーダドライバ３２０と同じである。一部の実施形態のデコーダドライバ１６４０は、ビデオ伸張器モジュール１６２６とデコーダ１６６０との間の通信インタフェースとして機能する。このような実施形態では、デコーダ１６６０は、ネットワーキングマネージャ１６１４を通じてテレビ会議の他のデバイスから受信されビデオ伸張器モジュール１６２６を通じて経路制御された画像を復号する。画像が復号された後、画像は、デコーダドライバ１６４０及びビデオ伸張器モジュール１６２６を通じてテレビ会議モジュール１６０２に返送される。

テレビ会議中にビデオ処理を実行することに加えて、一部の実施形態のデュアルカメラ携帯デバイスのためのテレビ会議及び処理モジュール１６００は、テレビ会議中にオーディオ処理動作も実行する。図１７は、このようなソフトウェアアーキテクチャを示す。図示のように、テレビ会議及び処理モジュール１６００は、（テレビ会議マネージャ１６０４と、画像処理マネージャ１６０８と、ネットワーキングマネージャ１６１４とを含む）テレビ会議モジュール１６０２と、メディア交換モジュール１６２０と、クライアントアプリケーション１６６５とを含む。図１６に示されているテレビ会議及び処理モジュール１６００の他のコンポーネント及びモジュールは、説明を簡略化するため、図１７では省略されている。テレビ会議及び処理モジュール１６００は、フレームバッファ１７０５及び１７１０と、オーディオ処理マネージャ１７１５と、オーディオドライバ１７２０とも含む。一部の実施形態では、オーディオ処理マネージャ１７１５は、別個のソフトウェアモジュールとして実施されるが、他の実施形態では、オーディオ処理マネージャ１７１５は、メディア交換モジュール１６２０の一部として実施される。

オーディオ処理マネージャ１７１５は、テレビ会議において他のデバイスへの伝送のためにデュアルカメラ携帯デバイスによって取り込まれたオーディオデータを処理する。例えば、オーディオ処理マネージャ１７１５は、マイクロフォン１７２５によって取り込まれたオーディオデータを、オーディオドライバ１７２０を通じて受け取り、オーディオデータを符号化してから、他のデバイスへの伝送のために、符号化されたオーディオデータをバッファ１７０５に格納する。オーディオ処理マネージャ１７１５は、テレビ会議において他のデバイスによって取り込まれて他のデバイスから受信したオーディオデータも処理する。例えば、オーディオ処理マネージャ１７１５は、バッファ１７１０からオーディオデータを読み出し、このオーディオデータを復号し、その後、オーディオドライバ１７２０を通じてスピーカ１７３０に出力される。

一部の実施形態では、テレビ会議モジュール１６０２は、オーディオ処理マネージャ１７１５及びその関連バッファと共に、より大きな会議モジュールの一部である。複数参加者によるオーディオ会議が、ビデオコンテンツを交換することなく、いくつかのデバイス間で行われる場合に、このテレビ会議及び処理モジュール１６００は、インターネットプロトコル（ＩＰ）層を介したオーディオの交換を容易にするために、ネットワーキングマネージャ１６１４及びオーディオ処理マネージャ１７１５のみを使用する。

ここで、一部の実施形態のテレビ会議マネージャ１６０４の動作について、図１８に関して説明する。図１８は、図１６に示されるテレビ会議マネージャ１６０４などの、一部の実施形態のテレビ会議マネージャによって実行されるプロセス１８００を概念的に示す。これは、図９の管理層９３５によって実行されるのに等しくなりうる。一部の実施形態では、デュアルカメラ携帯デバイスのユーザが（例えば、デュアルカメラ携帯デバイスに表示されるユーザインタフェースを通じて）テレビ会議要求を承諾する場合に、又は別のデバイスのユーザが、デュアルカメラ携帯デバイスのユーザによって送信された要求を承諾する場合に、テレビ会議マネージャ１６０４はプロセス１８００を実行する。

プロセス１８００は、テレビ会議を開始する命令を（１８０５において）受信することによって始まる。一部の実施形態では、命令は、クライアントアプリケーション１６６５から受信されるか、又はデュアルカメラ携帯デバイスに表示されるユーザインタフェースを通じてユーザから受信され、クライアントアプリケーション１６６５によってテレビ会議マネージャ１６０４に転送される。例えば、一部の実施形態では、デュアルカメラ携帯デバイスのユーザがテレビ会議要求を承諾した場合に、命令はユーザインタフェースを通じて受信され、クライアントアプリケーションによって転送される。一方、他のデバイスのユーザが、ローカルデバイスから送信された要求を承諾した場合に、一部の実施形態では、（初期要求を送信するために以前のユーザインタフェースとの対話はあってもよいが）ユーザインタフェースと対話することなく、クライアントアプリケーションから命令を受信する。

次に、プロセス１８００は、テレビ会議マネージャ１６０４と対話する第１モジュールを（１８１０において）初期化する。テレビ会議マネージャ１６０４と対話する一部の実施形態のモジュールは、ＣＩＰＵ１６５０、画像処理マネージャ１６０８、オーディオ処理マネージャ１７１５及びネットワーキングマネージャ１６１４を含む。

一部の実施形態では、ＣＩＰＵ１６５０を初期化することは、デュアルカメラ携帯デバイスの一方又は両方のカメラによって取り込まれた画像の処理を開始するようにＣＩＰＵ１６５０に命令することを含む。一部の実施形態では、バッファ１６１０からの画像の読み出し並びに読み出された画像の処理及び符号化を開始するように画像処理マネージャ１６０８に命令することによって、画像処理マネージャ１６０８を初期化する。オーディオ処理マネージャ１７１５を初期化するため、一部の実施形態では、マイクロフォン１７２５によって取り込まれたオーディオデータの符号化及びスピーカ１７３０に出力するために（他のデバイスから受信されて）バッファ１７１０に格納されたオーディオデータの復号を始めるようにオーディオ処理マネージャ１７１５に命令する。一部の実施形態のネットワーキングマネージャ１６１４を初期化することは、テレビ会議において他のデバイスとのネットワーク接続を確立するようにネットワーキングマネージャ１６１４に命令することを含む。

プロセス１８００は、その後、初期化するべきモジュールが残されていないかどうかを（１８１５において）判定する。初期化するために残されているモジュールがある場合に、プロセス１８００は、モジュールの別のものを初期化するために動作１８１０に戻る。必要なモジュールがすべて初期化された場合に、プロセス１８００はデュアルカメラ携帯デバイス（すなわち、ローカル表示）に表示するための画像合成を（１８２０において）生成する。これらの合成画像は、以下に説明する、図６５に示される画像（すなわち、ＰＩＰ又は他の合成表示）を含んでもよく、ローカルデュアルカメラ携帯デバイスのカメラからの画像及びテレビ会議に参加している他のデバイスのカメラからの画像の種々の組み合わせを含みうる。

次に、プロセス１８００は、テレビ会議に変更がなされたかどうかを（１８２５において）判定する。一部の実施形態では、デュアルカメラ携帯デバイスに表示されたユーザインタフェースを用いたユーザとの対話を通じてテレビ会議への変更を受け取るが、他の実施形態では、ネットワーキングマネージャ１６１４（すなわち、遠隔制御）を通じて他のデバイスからのテレビ会議への変更を受信する。一部の実施形態では、テレビ会議設定への変更は、クライアントアプリケーション１６６５又はテレビ会議モジュール１６０２内の他のモジュールから受信されてもよい。テレビ会議設定は、ネットワーク状態の変化によって変化してもよい。

変更がなされた場合に、プロセス１８００は、テレビ会議への変更がネットワーク設定への変更であるかどうかを（１８３０において）判定する。一部の実施形態では、変更はネットワーク設定への変更又は画像取り込み設定の変更のどちらかである。テレビ会議の変更がネットワーク設定への変更である場合に、プロセスは、ネットワーク設定を（１８４０において）変更し、それから動作１８４５に進む。一部の実施形態のネットワーク設定の変更は、画像が符号化されるビットレート又は画像が他のデバイスに伝送されるフレームレートの変更を含む。

テレビ会議への変更がネットワーク設定への変更でない場合に、プロセス１８００は、変更が画像取り込み設定への変更であると判定し、それから動作１８３５に進む。プロセス１８００は、その後、画像取り込み設定への変更を（１８３５において）実行する。一部の実施形態では、画像取り込み設定への変更は、いくつかの設定変更の中でも特に、カメラの切り換え（すなわち、デュアルカメラ携帯デバイス上のどのカメラがビデオを取り込むかの切り換え）、焦点調整、露出調整、デュアルカメラ携帯デバイスの一方又は両方のカメラからの画像を表示するか又は表示しないか、及びデュアルカメラ携帯デバイスに表示される画像のズームイン又はズームアウトを含んでもよい。

動作１８４５では、プロセス１８００は、テレビ会議を終了するかどうかを判定する。テレビ会議が終了しないとプロセス１８００が判定した場合に、プロセス１８００は動作１８２０に戻る。テレビ会議が終了するとプロセス１８００が判定した場合に、プロセス１８００は終了する。プロセス１８００の一部の実施形態は、プロセス１８００がテレビ会議を終了する命令をクライアントアプリケーション１６６５から受け取った場合に（すなわち、ローカルデュアルカメラ携帯デバイスのユーザインタフェースを通じて受信された又はテレビ会議に参加している他のデバイスから受信された命令に起因して）、テレビ会議が終了すると判定する。

一部の実施形態では、テレビ会議マネージャ１６０４は、テレビ会議が終了する場合に、プロセス１８００に示されていない種々の動作を実行する。一部の実施形態では、画像の生成を止めるようにＣＩＰＵ１６５０に命令し、テレビ会議中の他のデバイスとのネットワーク接続を切断するようにネットワーキングマネージャ１６１４に命令し、画像の生成及び符号化を止めるように画像処理マネージャ１６０８に命令する。

Ｅ．時間ノイズ低減
一部の実施形態は、ビデオのノイズを低減するようにビデオ画像を処理するための個別の時間ノイズ低減モジュールを含む。一部の実施形態の時間ノイズ低減モジュールは、ビデオから望ましくないノイズを識別し消去するためにビデオシーケンスの後続の画像を比較する。

図１９は、一部の実施形態のこのような時間ノイズ低減（ＴＮＲ）モジュール１９００のためのソフトウェアアーキテクチャを概念的に示す。一部の実施形態では、ＴＮＲモジュール１９００をアプリケーションの一部として（例えば、図３に示すメディア交換モジュールの一部として）実施するが、他の実施形態では、他のアプリケーションによって使用されるスタンドアロンアプリケーションとしてＴＮＲモジュール１９００を実施する。さらに他の実施形態では、デュアルカメラ携帯デバイス上で実行されるオペレーティングシステムの一部としてＴＮＲモジュール１９００を実施する。一部の実施形態では、ＴＮＲモジュール１９００は、ＴＮＲモジュール１９００の機能のうちの一部又は全部を他のアプリケーションに提供するＡＰＩ集合によって実施される。

図１９に示すように、ＴＮＲモジュール１９００は、ＴＮＲマネージャ１９０５と、差分モジュール１９１０、画素平均化モジュール１９１５と、動き履歴モジュール１９２０とを含む。図１９は、３つのモジュール１９１０、１９１５及び１９２０を別個のモジュールとして示しているが、一部の実施形態では、以下で説明するように、これらのモジュールの機能を単一のモジュールで実施する。一部の実施形態のＴＮＲモジュール１９００は、入力画像、参照画像及び動き履歴を入力として受け取る。一部の実施形態では、入力画像は現在処理されている画像であり、参照画像はビデオシーケンス内の直前の画像であり、これと入力画像が比較される。ＴＮＲモジュール１９００は、出力画像（入力画像の、ノイズが低減されたバージョン）及び出力動き履歴を出力する。

一部の実施形態のＴＮＲマネージャ１９０５は、データの流れを、ＴＮＲモジュール１９００を通るように向ける。図示のように、ＴＮＲマネージャ１９０５は、入力画像、参照画像及び動き履歴を受け取る。ＴＮＲマネージャ１９０５はまた、出力画像及び出力動き履歴を出力する。ＴＮＲマネージャ１９０５は、差分モジュール１９１０に入力画像及び参照画像を送り、差分モジュール１９１０から差分画像を受け取る。

一部の実施形態では、差分モジュール１９１０は、ＴＮＲマネージャ１９０５から受け取ったデータを処理し、処理されたデータをＴＮＲマネージャ１９０５に送る。図示のように、差分モジュール１９１０は、ＴＮＲマネージャ１９０５から入力画像及び参照画像を受け取る。一部の実施形態の差分モジュール１９１０は、ある画像の画素値を他の画像の画素値から減算することによって差分画像を生成する。差分画像はＴＮＲマネージャ１９０５に送られる。一部の実施形態の差分画像は、直前の画像と比較して入力画像の変化した区画及び入力画像の同じままの区画を識別するために、２つの画像間の差分を示す。

ＴＮＲマネージャ１９０５はまた、画素平均化モジュール１９１５に入力画像及び参照画像を送る。図示のように、一部の実施形態では、画素平均化モジュール１９１５に動き履歴も送る。しかし、他の実施形態では、動き履歴を送信せずに、入力画像及び参照画像のみを送ってもよいだろう。いずれの実施形態においても、ＴＮＲマネージャ１９０５は、処理された画像を画素平均化モジュール１９１５から受け取る。

一部の実施形態の画素平均化モジュール１９１５は、画像の特定の位置に対して入力画像及び参照画像から画素の平均を取るかどうかを判定するために、動き履歴を使用する。一部の実施形態では、動き履歴は、入力画像の各画素に対する確率値を含む。特定の確率値は、参照画像の対応する画素に対して入力画像の対応する画素が変化した（すなわち、動的画素である）確率を表す。例えば、入力画像の特定の画素の確率値が２０であるならば、それは、参照画像の対応する画素に対して入力画像の特定の画素が変化した確率が２０％であることを示す。別の例として、入力画像の特定の画素の確率値が０であるならば、それは、参照画像の対応する画素に対して入力画像の特定の画素が変化していない（すなわち、静的画素である）ことを示す。

異なる実施形態では、入力画像の確率値を異なるように格納する。一部の実施形態では、１つのデータ配列に入力画像の各画素の確率値を格納してもよいだろう。他の実施形態では、ビデオの画像の解像度と同じ寸法を有する行列（例えば、配列の配列）に確率値を格納してもよいだろう。例えば、ビデオの画像の解像度が３２０×２４０であるならば、行列も３２０×２４０である。

画素平均化モジュール１９１５が入力画像及び参照画像に加えて動き履歴をＴＮＲマネージャ１９０５から受け取る場合に、画素平均化モジュール１９１５は、入力画像の各画素の確率値を読み込む。入力画像の特定の画素に対する確率値が、規定のしきい値（例えば、５％、２０％）を下回るならば、画素平均化モジュール１９１５は、特定の画素に動きがある可能性は低く、したがってその画素における画像間の差分はノイズに起因することがあるという前提に基づいて、参照画像の対応する画素値で特定の画素値を平均化する。

入力画像の特定の画素のための確率が、規定のしきい値を下回らないならば、画素平均化モジュール１９１５は、入力画像の特定の画素を変更しない（すなわち、その画素の画素値は、入力画像と同じのままである）。これは、特定の画素で動きの可能性が高く、したがって、画像間の差分はノイズの結果でない可能性が高いからである。一部の実施形態では、動き履歴が画素平均化モジュール１９１５に送られない場合に、画素平均化モジュール１９１５は、参照画像の対応する画素で入力画像の各画素を平均化する。画素平均化モジュール１９１５によって出力されＴＮＲマネージャ１９０５に送られる処理された画像は、平均化されなかったあらゆる画素のための入力画像画素値及び画素平均化モジュール１９１５によって平均化されたあらゆる画素ための平均化された画素値を含む。

一部の実施形態では、動き履歴モジュール１９２０は、ＴＮＲマネージャ１９０５から受信されたデータを処理し、結果データをＴＮＲマネージャ１９０５に返送する。一部の実施形態の動き履歴モジュール１９２０は、ＴＮＲマネージャ１９０５から入力画像及び動き履歴を受け取る。一部の実施形態では、次の入力画像のための画素平均化に使用されうる新たな動き履歴（すなわち、確率値の集合）を生成するために、ベイズ推定器にこのデータを入力する。他の実施形態では、他の推定器を使用して新たな動き履歴を生成する。

ここで、ＴＮＲモジュール１９００の動作について、図２０に関して説明する。この図は、ビデオの画像の時間ノイズを低減するための一部の実施形態のプロセス２０００を概念的に示す。プロセス２０００は、ＴＮＲマネージャ１９０５が入力画像、参照画像及び動き履歴を（２００５において）受け取ることによって開始する。入力画像は、ノイズ低減のために現在処理されている画像である。一部の実施形態では、参照画像は、ＣＩＰＵから受け取られたビデオの画像のシーケンスの直前の画像である。しかし、他の実施形態では、参照画像は、直前の入力画像の処理から生成された出力画像（すなわち、ＴＮＲモジュール１９００の出力）である。動き履歴は、直前の入力画像の処理から生成された出力動き履歴である。

入力画像がビデオの第１画像である場合に、一部の実施形態のＴＮＲモジュール１９００は、第１画像を処理しない（すなわち、第１画像にＴＮＲを適用しない）。言い換えれば、ＴＮＲマネージャ１９０５は、第１画像を受け取り、単に第１画像を出力するだけである。他の実施形態では、入力画像がビデオの第１画像である場合に、第１画像は、入力画像及び参照画像として使用され、ＴＮＲモジュール１９００は、以下で説明するように画像を処理する。さらに、入力画像がビデオの第１画像である場合に、動き履歴は空（例えば、ヌル、全ゼロなど）であり、ＴＮＲマネージャ１９０５は、単に空の動き履歴を出力動き履歴として出力するだけである。

ＴＮＲマネージャ１９０５は、その後、入力画像が静的であるかどうかを（２０１０において）判定する。この判定を行うために、一部の実施形態では、差分モジュール１９１０に入力画像及び参照画像を送り、差分モジュール１９１０から差分画像を受け取る。２つの画像間の差分が、規定のしきい値（例えば、５％の差分、１０％の差分など）を下回る場合に、一部の実施形態では、入力画像を静的として分類する。

入力画像が静的画像である場合に、ＴＮＲマネージャ１９０５は、静的画像からのノイズを低減させる目的で、参照画像の画素で入力画像の画素を（２０１５において）平均化するために、入力画像及び参照画像を画素平均化モジュール１９１５に送る。プロセスはその後２０４０に進み、これについては以下で説明する。

入力画像が静的画像でない場合に、ＴＮＲマネージャは、入力画像、参照画像及び動き履歴を画素平均化モジュール１９１５に処理のために送る。画素平均化モジュール１９１５は、入力画像の画素を（２０２０において）選択する。上述のように、画素平均化モジュール１９１５は、動き履歴を使用して、画素の動きの確率が特定のしきい値を下回るかどうかを（２０２５において）判定する。

選択された画素の確率が特定のしきい値を下回るならば、画素平均化モジュール１９１５は、参照画像の対応する画素で入力画像の画素を（２０３０において）平均化する。そうでないならば、画素は平均化されず、その特定の画素において、出力画像は入力画像と同じである。画素平均化モジュール１９１５は、その後、選択されていない画素が入力画像に残っているかどうかを（２０３５において）判定する。いずれかの画素が処理されていないならば、プロセスは動作２０２０に戻り、次の画素を選択する。画素平均化モジュール１９１５は、すべての画素が評価されるまで、動作２０２０〜２０３０を実行する。

プロセスは、その後、動き履歴を（２０４０において）更新する。図１９に示し、上述したように、動き履歴モジュール１９２０は、入力画像に基づいて動き履歴を更新する。画素平均化モジュールからの処理済みの画像と共に、新たな動き履歴がＴＮＲマネージャによって出力される。

Ｆ．画像処理マネージャ及びエンコーダ
一部の実施形態では、ＣＩＰＵ及び／又はＣＩＰＵドライバによって実行される時間ノイズ低減動作及び画像処理動作に加えて、さまざまな画像処理動作をテレビ会議モジュール９２５の画像処理層９３０において実行する。これらの画像処理動作は、いくつかある中でも特に、露出調整、焦点調整、パースペクティブ補正、ダイナミックレンジ調整及び画像サイズ変更を含みうる。

図２１は、このような画像処理動作を実行するためのプロセス２１００を概念的に示す。一部の実施形態では、プロセス２１００の動作のうちの一部又は全部は、図１６の画像処理マネージャ１６０８及びエンコーダドライバ１６３５の組み合わせによって実行される。このような実施形態のうちの一部では、画像処理マネージャ１６０８は、画素ベースの処理（例えば、サイズ変更、ダイナミックレンジ調整、パースペクティブ補正など）を実行する。一部の実施形態では、テレビ会議に参加している別のデバイスに伝送されるべき画像に対するプロセス２１００をテレビ会議中に実行する。

ここで、プロセス２１００について、図１６に関して説明する。プロセスは、バッファ１６０６から画像を（２１０５において）読み出すことによって開始する。一部の実施形態では、読み出される画像は、ビデオの画像（すなわち、画像シーケンス内の画像）である。このビデオは、プロセス２１００が実行されるデバイスのカメラによって取り込まれていてもよい。

次に、プロセス２１００は、読み出された画像に対して露出調整を（２１１０において）実行する。一部の実施形態では、デュアルカメラ携帯デバイスに表示されるユーザインタフェースを通じて露出調整を実行する。図２２は、このような実施形態の例示的な露出調整動作を示す。

この図は、露出調整動作を、デバイス２２００のＵＩ２２０５の３つの段階２２１０、２２１５及び２２２０に関して示す。第１段階２２１０は、表示域２２２５と表示域１１５５とを含むＵＩ２２０５を示す。図示のように、表示域２２２５は、太陽と、顔及び身体の色が暗い男性との画像２２３０を表示する。顔及び身体の色が暗いことは、男性が適切に露出されていないことを示す。画像２２３０は、デバイス２２００のカメラによって取り込まれたビデオ画像でありうるだろう。図示のように、表示域１１５５は、テレビ会議を終了させるために選択可能ＵＩ項目２２５０を含む。一部の実施形態では、表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。

第２段階２２１５は、デバイス２２００のユーザが表示域２２２５のエリアを選択することによって露出調整動作を始めることを示す。この例では、選択は、表示域２２２５内の任意の位置に指２２３５を置くことによってなされる。一部の実施形態では、ユーザは、取りうる画像設定調整のメニューから露出調整を選択する。

第３段階２２２０は、露出調整動作が完了した後の男性の画像２２４０を示す。図示のように、画像２２４０は画像２２３０と同様であるが、画像２２４０の男性が適切に露出されている。一部の実施形態では、適切に露出された画像は、不適切に露出された画像の後に取り込まれた画像である。第２段階２２１５で始められた露出調整動作は、デバイス２２００のカメラによって取り込まれた後続の画像の露出を調整する。

図２１に戻ると、プロセス２１００は、次に、画像に対して焦点調整を（２１１５において）実行する。一部の実施形態では、デュアルカメラ携帯デバイスに表示されるユーザインタフェースを通じて焦点調整を実行する。図２３は、このような焦点調整動作の一例を概念的に示す。

図２３は、焦点調整動作を、デバイス２３００のＵＩ２３０５の３つの異なる段階２３１０、２３１５及び２３２０に関して示す。第１段階２３１０は、表示域２３２５と表示域１１５５とを含むＵＩ２３０５を示す。表示域２３２５は、デバイス２３００のカメラによって取り込まれた男性の不鮮明な画像２３３０を提示する。ぼやけていることは、男性の画像２３３０の焦点がずれていることを示す。すなわち、男性の画像２３３０がカメラによって取り込まれた際に、カメラのレンズが、男性にフォーカスを合わせていなかった。また、画像２３３０は、デバイス２３００のカメラによって取り込まれたビデオ画像でありうる。図示のように、表示域１１５５は、テレビ会議を終了させるために選択可能ＵＩ項目２３５０を含む。一部の実施形態では、表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。

第２段階２３１５は、デバイス２３００のユーザが表示域２３２５のエリアを選択することによって焦点調整動作を始めることを示す。この例では、選択は、表示域２３２５内の任意の位置に指２３３５を置くことによってなされる。一部の実施形態では、ユーザは、取りうる画像設定調整のメニューから焦点調整を選択する。

第３段階２３２０は、焦点調整動作が完了した後の男性の画像２３４０を示す。図示のように、画像２３４０は画像２３３０と同じであるが、画像２３４０の男性がより鮮明に表示される。このことは、カメラのレンズが適切に男性にフォーカスを合わせていることを示す。一部の実施形態では、適切にフォーカスが合わされた画像は、不適切にフォーカスが合わされた画像の後に取り込まれた画像である。第２段階２３１５で始められた焦点調整動作は、デバイス２３００のカメラによって取り込まれた後続の画像のフォーカスを調整する。

図２１に戻ると、プロセス２１００は、画像に対して画像サイズ変更を（２１２０において）実行する。一部の実施形態では、画像を符号化するために使用されるビット数を低減させる（すなわち、ビットレートを低下させる）目的で、画像に対して画像サイズ変更を実行する。一部の実施形態では、プロセス２１００は、以下で図２６に関して説明するように、画像サイズ変更を実行する。

プロセス２１００は、次に、画像に対してパースペクティブ補正を（２１２５において）実行する。一部の実施形態では、プロセス２１００は、以下で図２４で説明するようにパースペクティブ補正を実行する。このようなパースペクティブ補正は、デュアルカメラ携帯デバイスの向き及び移動を識別する１つ以上の加速度計及び／又はジャイロスコープセンサによって取得されたデータを使用することを含む。このデータは、その後、ずれているパースペクティブを補正する目的で画像を変更するために使用される。

パースペクティブ補正が画像に対して実行された後、プロセス２１００は、画像のダイナミックレンジを（２１３０において）調整する。一部の実施形態では、画像のダイナミックレンジとは、画像の各画素が有しうる取りうる値の範囲である。例えば、０〜２５５のダイナミックレンジを有する画像は、０〜１２８の範囲又は他の任意の範囲の値に調整されうる。画像のダイナミックレンジを調整することによって、画像を符号化するために使用されるビット量を低減させ（すなわち、ビットレートを低下させ）、それによって、画像を平滑化できる。

画像のダイナミックレンジの調整は、種々の他の目的に使用されることもできる。１つの目的は、画像ノイズを低減させることである（例えば、画像はノイズの多いカメラセンサによって取り込まれた）。ノイズを低減させるため、黒レベルがより明るい黒を含む（すなわち、濃淡を調整する（crush blacks））ように再定義されるように画像のダイナミックレンジが調整される。このようにして、画像のノイズが低減される。ダイナミックレンジ調整の別の目的は、画像の質を向上させるために１つ以上の色又は色の範囲を調整することである。例えば、一部の実施形態では、前面カメラによって取り込まれた画像が人の顔の画像であると想定してもよい。したがって、画像のダイナミックレンジは、人の頬をバラ色／よりバラ色に表示させるために赤色及びピンク色を増加させるように調整されうる。ダイナミックレンジ調整動作は、他の目的にも使用されうる。

最後に、プロセス２１００は、画像を符号化するために使用される１つ以上のレートコントローラパラメータを（２１３５において）決定する。このようなレートコントローラパラメータは、一部の実施形態では、量子化パラメータ及びフレームタイプ（例えば、Ｐ（predictive）、Ｂ（bi-directional）、Ｉ（intra-coded））を含みうる。その後、プロセスが終了する。

プロセス２１００の種々の動作は、特定の順序で実行されるように示されているが、これらの動作（露出調整、焦点調整、パースペクティブ補正など）の多くは、任意の順序で実行でき、互いに依存しないことが当業者には理解されよう。すなわち、一部の実施形態のプロセスは、露出調整の前に焦点調整を実行することもできるし、図２１に示されるプロセスと同様の変更を実行することもできる。

１．パースペクティブ補正
上述のように、一部の実施形態では、画像を表示又は送信する前に、画像に対してパースペクティブ補正を実行する。いくつかの場合では、デュアルカメラ携帯デバイス上のカメラのうちの１つ以上は、その被写体に適切に配向されず、その被写体は、未補正の画像では歪んで見える。パースペクティブ補正は、どのようにして画像内の物体が人に見えるのかを画像が密接に反映するように画像を処理するために使用されうる。

図２４は、図１６に示されるプロセスなどの、一部の実施形態の画像処理マネージャによって実行されるパースペクティブ補正プロセス２４００を概念的に示す。一部の実施形態のプロセス２４００は、図９に示される（画像処理マネージャ１６０８を含むことができる）画像処理層９３０によって実行される。一部の実施形態では、画像を表示又は伝送する前に最近取り込まれたビデオ画像のパースペクティブを補正するために、プロセス２４００をプロセス２１００の動作２１２５において実行する。

プロセス２４００は、加速度計センサからデータを（２４０５において）受信することによって開始し、加速度計センサは、一部の実施形態ではデュアルカメラ携帯デバイスの一部である。一部の実施形態の加速度計センサは、デバイスの速度の変化率（すなわち、デバイスの加速度）を１つ以上の軸に沿って測定する。プロセスは、ジャイロスコープセンサからもデータを（２４１０において）受信し、ジャイロスコープセンサも、一部の実施形態ではデュアルカメラ携帯デバイスの一部であってもよい。一部の実施形態のジャイロスコープセンサ及び加速度計センサは、個別に使用されてもよいし、デュアルカメラ携帯デバイスの向きを識別するために組み合わせて使用されてもよい。

次に、プロセス２４００は、加速度計センサ及びジャイロスコープセンサから得られたデータに基づいて実行するパースペクティブ補正量を（２４１５において）決定する。一般に、向きがさらに軸からはずれている場合に、最適な画像を生成するために、より多くのパースペクティブ補正が必要とされる。一部の実施形態では、デバイスの向きに基づいてパースペクティブ補正量を表す歪み（warp）パラメータを算出する。

実行するパースペクティブ補正量を決定した後、プロセス２４００は、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を（２４２０において）受信する。このプロセスは、カメラによって取り込まれたビデオシーケンスの各画像に対して実行されうる。一部の実施形態では、デュアルカメラ携帯デバイス上の２つのカメラのそれぞれから到着する画像のために別個の算出を実行しうる。

プロセスは、その後、決定されたパースペクティブ補正量に基づいて画像を（２４２５において）変更する。一部の実施形態では、パースペクティブ補正量の歪みパラメータ又は他の表記に加えて、ベースライン画像又は他の情報（例えば、どの補正が実行されるべきかに関してユーザが入力した点）も使用する。画像を変更した後、プロセス２４００は終了する。

図２５は、一部の実施形態の例示的な画像処理動作を概念的に示す。この図は、パースペクティブ補正を使用しない第１画像処理モジュール２５２０によって実行される第１画像処理動作２５０５と、パースペクティブ補正を使用する第２画像処理モジュール２５６５によって実行される第２画像処理動作２５５０とを示す。

図示のように、第１画像処理動作２５０５は、ブロックに向かってある角度で下方向を見る大気遠近法からブロック２５１５の第１画像２５１０に対して実行される。そのパースペクティブから、ブロック２５１５の上部はブロックの下部よりも近い。したがって、ブロック２５１５は、第１画像２５１０を取り込んだカメラの方に傾くように見える。図２５は、第１画像処理モジュール２５２０による処理の後の処理済み第１画像２５２５も示す。図示のように、処理された第１画像２５２５のブロック２５１５は、第１画像処理モジュール２５２０がパースペクティブ補正を実行しなかったので、同じ後処理に見える。

第２画像処理動作２５５０は、ブロック２５６０の第２画像２５５５に対して実行される。ブロック２５６０は、第１画像２５１０のブロック２５１５と同じである。図２５は、第２画像処理モジュール２５６５のパースペクティブコレクタ２５７０による第２画像２５５５の処理の後の処理済み第２画像２５７５も示す。パースペクティブコレクタ２５７０は、第２画像２５５５のパースペクティブを補正するためにプロセス２４００を使用してもよい。第２画像２５５５を取り込んだカメラが下向きの角度で傾斜していることを示す加速度計及びジャイロスコープからのデータに基づいて（及び、場合によっては他のデータに基づいて）、パースペクティブコレクタ２５７０は、処理済みの第２画像２５７５上でブロックがまっすぐに表示されるように見えるように、第２画像を補正できる。

２．サイズ変更及びビットストリーム操作
一部の実施形態の画像処理層９３０によって実行される、図２１に関して上述した機能の中には、画像サイズ変更及びビットストリーム操作がある。一部の実施形態では、（動作２１３０において実行される）画像サイズ変更は、画像を拡大又は縮小すること（すなわち、画像を表すために使用される画素数を変更すること）を含む。一部の実施形態では、ビットストリーム操作は、サイズ変更後の画像のサイズを示すデータをビットストリームに挿入することを含む。このサイズ変更及びビットストリーム操作は、一部の実施形態では、エンコーダドライバ（例えば、ドライバ１６３５）によって実行される。

図２６は、一部の実施形態のこのようなエンコーダドライバ２６００のためのソフトウェアアーキテクチャを概念的に示し、例示的な画像２６０５に対してエンコーダドライバ２６００によって実行される例示的なサイズ変更及びビットストリーム操作動作を示す。一部の実施形態では、画像２６０５は、テレビ会議で別のデバイス（群）への伝送のためにデュアルカメラ携帯デバイスのカメラによって取り込まれたビデオの画像である。図１６を参照すると、一部の実施形態では、ビデオ画像は、ＣＩＰＵ１６５０からＣＩＰＵドライバ１６３０及びカメラソースモジュール１６２２を経てバッファ１６０６まで進むことになり、バッファ１６０６から画像処理マネージャ１６０８によって読み出される。画像処理マネージャ１６０８で画像処理（例えば、焦点調整、露出調整、パースペクティブ補正）に供された後、画像は、バッファ１６１０及びビデオ圧縮器モジュール１６２４を通じてエンコーダドライバ１６３５に送られる。

図示のように、エンコーダドライバ２６００は、処理層２６１０と、レートコントローラ２６４５とを含む。一部の実施形態のレートコントローラの例が、以下で説明する図３０に示されている。処理層２６１０は、画像リサイザ２６１５と、ビットストリームマネージャ２６２５とを含む。一部の実施形態では、これらのモジュールは、画像が符号化される前と後の両方で画像に対して種々の動作を実行する。この例では、画像リサイザは、エンコーダドライバ２６００の処理層２６１０の一部として示されているが、一部の実施形態では、エンコーダドライバ２６００ではなく画像処理マネージャ１６０８の一部として画像リサイザを実施する（すなわち、画像サイズ変更は、画像及びサイズデータをエンコーダドライバに送る前に行われる）。

図示のように、画像リサイザ２６１５は、画像がレートコントローラ２６４５を通じてエンコーダ２６５０に送られる前に画像をサイズ変更する。画像２６０５は、リサイザ２６１５を通じて送られ、画像２６３０に縮小される。一部の実施形態では、画像の縮小に加えて、画像を拡大することもできる。

図２６に示すように、一部の実施形態では、到来する画像（例えば、画像２６０５）を縮小し、その後、縮小画像（例えば、画像２６３０）を、到来する画像と（画素単位で）同じサイズである（すなわち、画像２６０５の画素の行及び列の数が空間的に冗長な画像２６３５の画素の行及び列の数と同じである）空間的に冗長な画像（例えば、画像２６３５）に重畳する。一部の実施形態では、縮小画像２６３０を、（図示のように、合成画像２６４０を生成するために）空間的に冗長な画像の左上隅に重畳するが、他の実施形態では、縮小画像を、空間的に冗長な画像の異なる区画（例えば、中央、右上、上部中央、下部中央、右下など）に重畳する。

一部の実施形態では、空間的に冗長な画像は、実質的にすべて１色（例えば、黒色、青色、赤色、白色など）である画像、又は繰り返しパターン（例えば、チェック、ストライプなど）を有する画像である。例えば、図２６に示される空間的に冗長な画像２６３５は、十字の繰り返しパターンを有する。合成画像２６４０の空間的に冗長な部分は、反復性があるために、エンコーダによって少量のデータに容易に圧縮されうる。そのうえ、画像のシーケンスがすべて縮小され、使用される空間的に冗長な画像がシーケンス中の各画像に対して同じであるならば、符号化された画像を現すのに必要なデータ量をさらに減少させるために時間的圧縮が使用されうる。

画像リサイザ２６１５の一部の実施形態では、サイズ変更された画像のサイズ（例えば、縮小画像２６３０のサイズ）を示すサイズデータ２６２０も生成し、この生成されたサイズデータ２６２０をビットストリームマネージャ２６２５に送る。一部の実施形態のサイズデータ２６２０は、サイズ変更された画像２６３０のサイズを、サイズ変更された画像２６３０の画素の行の数及び画素の列の数（すなわち、高さ及び幅）で示す。一部の実施形態では、サイズデータ２６２０は、合成画像２６４０内のサイズ変更された画像２６３０の位置も示す。

画像がサイズ変更された後、合成画像２６４０はレートコントローラ２６４５を通じてエンコーダ２６５０に送られる。レートコントローラ２６４５は、一部の実施形態では、以下でさらに詳細に説明するように、エンコーダ２６５０によって出力される画像のビットレート（すなわち、データサイズ）を制御する。一部の実施形態のエンコーダ２６５０は、画像を圧縮して符号化する。エンコーダ２６５０は、Ｈ．２６４符号化法又は別の符号化法を使用してもよい。

一部の実施形態のビットストリームマネージャ２６２５は、１つ以上の符号化された画像のビットストリームをエンコーダ２６５０から受け取り、サイズデータをビットストリームに挿入する。例えば、一部の実施形態では、ビットストリームマネージャ２６２５は、サイズデータ２６２０を画像リサイザ２６１５から受け取り、サイズデータ２６２０を、エンコーダ２６５０から受け取った符号化された合成画像２６４０のビットストリーム２６５５に挿入する。ビットストリームマネージャ２６２５の出力は、この場合、サイズデータ２６２０を含む変更されたビットストリーム２６６０である。異なる実施形態において、サイズデータ２６２０をビットストリーム２６５５の異なる位置に挿入する。例えば、ビットストリーム２６６０は、ビットストリーム２６６０の先頭に挿入されたサイズデータ２６２０を示す。しかし、他の実施形態では、サイズデータ２６２０を、ビットストリーム２６５５の最後、ビットストリーム２６５５の中央、又はビットストリーム２６５５内の他の任意の位置に挿入する。

一部の実施形態では、ビットストリーム２６５５は、合成画像２６４０を含む１つ以上の符号化された画像のシーケンスのビットストリームである。このような実施形態のうちの一部において、シーケンス内の画像はすべて同じサイズにサイズ変更され、サイズデータ２６２０は、それらのサイズ変更された画像のサイズを示す。画像がテレビ会議の相手側のデバイスに伝送された後、受信デバイスは、ビットストリームからサイズ情報を抽出し、受信された画像を適切に復号するためにサイズ情報を使用できる。

図２７は、ドライバ２６００などの、デュアルカメラ携帯デバイスのエンコーダドライバによって実行される画像サイズ変更プロセス２７００を概念的に示す。プロセス２７００は、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像（例えば、画像２６０５）を（２７０５において）受信することによって始まる。デュアルカメラデバイスが両方のカメラで画像を取り込んでいる場合に、一部の実施形態では、両方のカメラからの画像に対してプロセス２７００を実行する。

次に、プロセス２７００は、受信した画像を（２７１０において）サイズ変更する。前述のように、異なる実施形態では、画像２６０５を異なるようにサイズ変更する。例えば、図２６の画像２６０５は縮小され、合成画像２６４０を生成するために空間的に冗長な画像２６３５上に重畳される。

プロセス２７００は、その後、サイズ変更された画像（例えば、サイズ変更された画像２６３０を含む合成画像２６４０）を符号化するためにエンコーダ２６５０に（２７１５において）送る。プロセス２７００の一部の実施形態では、（合成画像２６４０に含まれる）サイズ変更された画像２６３０を、エンコーダが画像を符号化するビットレートを決定するレートコントローラを通じて、エンコーダ２６５０に送る。一部の実施形態のエンコーダ２６５０は、（例えば、離散コサイン変換、量子化、エントロピー符号化などを使用して）画像を圧縮して符号化し、符号化された画像を有するビットストリームをエンコーダドライバ２６００に戻す。

次に、プロセス２７００は、サイズ変更された画像のサイズ（例えば、サイズデータ２６２０）を示すデータをビットストリームマネージャに（２７２０において）送る。図２６に示すように、この動作は、一部の実施形態ではエンコーダドライバ２６００内で実行される（すなわち、エンコーダドライバ２６００のあるモジュールが、エンコーダドライバ２６００の別のモジュールにサイズデータを送る）。

サイズ変更された画像がエンコーダ２６５０によって符号化された後、プロセス２７００は、エンコーダからビットストリームを（２７２５において）受け取る。図示のように、一部の実施形態では、ビットストリームマネージャにおいてビットストリームを受け取り、ビットストリームマネージャは、サイズデータも受け取っている。受け取られたビットストリームは、符号化された合成画像を含み、ビデオシーケンスに１つ以上の追加画像も含んでもよい。

プロセス２７００は、その後、サイズ変更された画像のサイズを示すデータ（例えば、サイズデータ２６２０）をビットストリームに（２７３０において）挿入して、終了する。図２６に示すように、この動作は、一部の実施形態ではビットストリームマネージャによっても実行される。上述のように、異なる実施形態では、サイズデータをビットストリームの異なる部分に挿入する。図示の例では、サイズデータ２６２０は、結果として生成されるビットストリーム２６６０に示されるように、ビットストリーム２６５５の先頭に挿入される。このビットストリームは、この時点で、テレビ会議に参加している別のデバイスに伝送でき、別のデバイスで復号されて視聴されうる。

一部の実施形態では、デコーダドライバ（例えば、ドライバ１６４０）は、エンコーダドライバの反対の機能を実行する。すなわち、デコーダドライバは、受け取ったビットストリームからサイズデータを抽出し、このビットストリームをデコーダに渡し、復号された画像を、サイズデータを使用してサイズ変更する。図２８は、一部の実施形態のこのようなデコーダドライバ２８００のためのソフトウェアアーキテクチャを概念的に示し、例示的なビットストリーム２８２５に対してデコーダドライバ２８００によって実行される例示的なビットストリーム操作及びサイズ変更動作を示す。

一部の実施形態では、ビットストリーム２８２５は、テレビ会議でデバイスのカメラによって取り込まれたビデオの符号化された画像を含むビットストリーム（例えば、ドライバ２６００などのエンコーダドライバからのビットストリーム）であり、デコーダドライバ２８００が動作するデバイスに伝送される。図１６を参照すると、一部の実施形態では、ビットストリームは、ネットワーキングマネージャ１６１４によって受信され、バッファ１６１６に送られ、バッファ１６１６からビデオ伸張器モジュール１６２６によって読み出され、デコーダドライバ１６４０に送られる。

図示のように、デコーダドライバ２８００は、処理層２８０５を含む。処理層２８０５は、画像リサイザ２８１０と、ビットストリームマネージャ２８２０とを含む。一部の実施形態では、これらのモジュール２８１０及び２８２０は、画像が符号化される前と後の両方で、受け取られた画像に対して種々の動作を実行する。この例では、画像リサイザ２８１０は、デコーダドライバ２８００の処理層２８０５の一部として示されているが、一部の実施形態は、デコーダドライバではなく画像処理マネージャ１６０８の一部として画像リサイザを実施する（すなわち、画像サイズ変更は、デコーダドライバ２８００から画像を送った後に行われる）。

図示のように、一部の実施形態のビットストリームマネージャ２８２０は、１つ以上の符号化された画像（すなわち、ビデオシーケンス内の画像）のビットストリームを受け取り、復号のためにビットストリームをデコーダ２８３５に送る前にビットストリームからサイズデータを抽出する。例えば、図２８に示されるように、ビットストリームマネージャ２８２０は、符号化された画像のビットストリーム２８２５を受け取り、ビットストリーム２８２５からサイズデータ２８１５を抽出し、復号のために、結果として生成される（サイズデータ２８１５のない）ビットストリーム２８３０をデコーダ２８３５に送る。図示のように、ビットストリームマネージャ２８２０は、一部の実施形態では、抽出されたサイズデータ２８１５を画像リサイザ２８１０に送る。

一部の実施形態のサイズデータ２８１５は、エンコーダドライバ２６００によってビットストリームに挿入されるサイズデータ２６２０と同じである。図２６の説明で上述したように、一部の実施形態のサイズデータ２８１５は、サブ画像２８４５のサイズを、サブ画像２８４５の画素の行の数及び画素の列の数として示す。サイズデータ２８１５は、より大きな空間的に冗長な画像２８４０内のサブ画像２８４５の位置も示してもよい。この例では、ビットストリーム２８２５は、ビットストリーム２８２５の先頭に挿入されたサイズデータ２８１５を示す。しかし、前述のように、異なる実施形態では、サイズデータ２８１５をビットストリーム２８２５の異なる位置に挿入する。

一部の実施形態の画像リサイザ２８１０は、ビットストリームマネージャ２８２０から受け取られたサイズデータを使用して、画像からサブ画像を抽出する。例えば、図２８は、画像リサイザ２８１０が、サブ画像２８４５を含む画像２８４０をデコーダ２８３５から受け取るところを示す。図示のように、一部の実施形態の画像リサイザ２８１０は、画像２８４０からサブ画像２８４５を抽出する。その後、この抽出された画像は、デュアルカメラ携帯デバイスに表示されうる。

図２９は、ドライバ２８００などの、テレビ会議に参加しているデバイスのデコーダドライバによって実行される一部の実施形態の画像抽出プロセス２９００を概念的に示す。プロセスは、符号化された画像のビットストリーム（例えば、ビットストリーム２８２５）を（２９０５において）受け取ることによって始まる。ビットストリームは、デコーダドライバが動作しているデバイスとのテレビ会議に参加しているデバイスから送信されてもよいし、デバイスの記憶装置に格納されてもよい。デバイスが複数のソースから画像を受信している場合に、一部の実施形態は、各ソースからの画像に対してプロセス２９００を実行する。

次に、プロセス２９００は、ビットストリームからサイズデータを（２９１０において）抽出する。前述のように、このサイズデータは、ビットストリーム内のさまざまな位置で見つけられてもよい。一部の実施形態は、どこでサイズデータを探すべきかが分かっているが、他の実施形態は、受け取られたビットストリーム内のどこにサイズデータがあるかを示す特定の署名を探す。一部の実施形態では、サイズデータは、符号化された画像内のサブ画像のサイズ（例えば、各行における画素の数及び各列における画素の数）及び位置を示す。

プロセス２９００は、その後、抽出したサイズデータを画像リサイザに（２９１５において）送信する。図２８に示すように、この動作は、一部の実施形態ではデコーダドライバ内で実行される（すなわち、デコーダドライバのあるモジュールがデコーダドライバの別のモジュールにサイズデータを送る）。

プロセス２９００は、復号のためにビットストリームもデコーダに（２９２０において）送信する。デコーダは、一部の実施形態では、ビットストリームを（例えば、逆離散コサイン変換、逆量子化などを使用して）伸張して復号し、再構成した画像をデコーダドライバに戻す。

ビットストリームがデコーダによって復号された後、プロセス２９００は、復号された画像をデコーダから（２９２５において）受け取る。図示のように、一部の実施形態は、画像リサイザにおいて画像を受け取り、画像リサイザは、ビットストリームマネージャからサイズデータも受け取っている。プロセスは、その後、受け取ったサイズデータを使用して、復号された画像からサブ画像を（２９３０において）抽出する。図示のように、サブ画像２８４５は、サイズデータ２８１５に示されるように、復号された画像２８４０の左上から抽出される。この抽出されたサブ画像は、この時点で、表示デバイス（例えば、デュアルカメラ携帯デバイスの画面）に表示されうる。

３．レートコントローラ
一部の実施形態では、デバイスの２つのカメラは、異なる特性の集合を有する。例えば、一部の実施形態では、前面カメラは、動きビデオ画像の取り込みに最適化された、解像度の低い方のカメラであり、背面カメラは、静止画像の取り込みに最適化された解像度の高い方のカメラである。デバイスのコスト、機能及び／又は形状などの理由で、他の実施形態は、異なる特性を持つカメラの異なる組み合わせを使用してもよい。

異なる特性を有するカメラは、異なるアーチファクトをもたらしうる。例えば、解像度が高いカメラほど、解像度の低いカメラよりも多くのノイズが露見しうる。解像度の高いカメラによって取り込まれた画像は、解像度の低いカメラによって取り込まれた画像よりも高いレベルの空間的又は時間的な複雑さを示しうる。同様に、異なる光学的性質を有する異なるカメラは、取り込まれた画像に異なるガンマ値をもたらしうる。画像を取り込むために異なるカメラによって使用される異なる光検知機構も、異なるアーチファクトをもたらしうる。

これらのカメラ固有のアーチファクトのうちの一部は、他のソースから生成されたアーチファクトを隠蔽する。例えば、高いレベルのノイズを有する高解像度カメラによって取り込まれた画像では、ビデオ符号化プロセスの副産物であるアーチファクトは視認しにくくなる。カメラ固有のアーチファクトに隠れるように（量子化歪みなど）ノイズを符号化する場合に、ビデオ符号化プロセスは、ビットレートの低下を達成するために、より大きな量子化ステップサイズを使用できる。一方、（解像度の低いカメラの場合のように）カメラがもたらすアーチファクトが少ない場合に、ビデオ符号化プロセスは、量子化による許容できないレベルの視覚的歪みを回避するために、より細かい量子化ステップサイズを使用できる。したがって、これらのカメラ固有の特性を活用する又は補償するために最適化されたビデオ符号化プロセスは、これらのカメラ固有の特性を考慮しないビデオ符号化プロセスよりも優れたレート−歪みトレードオフを達成できる。

レート−歪みトレードオフを実行する目的でこれらのカメラ固有の特性を利用するために、一部の実施形態は、２つのビデオ符号化プロセスを実施し、各プロセスは、２つのカメラのそれぞれに最適化される。図３０は、２つのカメラ３０６０及び３０７０のための２つのビデオ符号化プロセスを有するシステムの一例を示す。図３０に示すように、システム３０００は、エンコーダドライバ３０１０と、レートコントローラ３０２０及び３０４０と、ビデオエンコーダ３０３０とを含む。エンコーダ３０３０は、ビデオカメラ３０６０及び３０７０から取り込まれたビデオ画像をビットストリーム３０８０及び３０９０に符号化する。

一部の実施形態では、ビデオエンコーダドライバ３０１０は、１つ以上の処理ユニット上で実行されるソフトウェアモジュールである。ビデオエンコーダドライバ３０１０は、ビデオエンコーダ３０３０と、ビデオカメラ、画像処理モジュール、ネットワーク管理モジュール及び記憶装置バッファなどのシステムの他のコンポーネントとの間のインタフェースを提供する。エンコーダドライバ３０１０は、カメラ及び画像処理モジュールからビデオエンコーダ３０３０までの取り込まれたビデオ画像の流れを制御し、記憶装置バッファ及びネットワーク管理モジュールへの、符号化されたビットストリーム３０８０及び３０９０のための経路（conduit1）も提供する。

図３０に示すように、エンコーダドライバ３０１０は、レートコントローラの２つの異なるインスタンス３０２０及び３０４０を含む。これらの複数のインスタンスは、２つの異なるカメラのための２つの異なるレートコントローラであってもよいし、２つの異なるカメラのために２つの異なる方式で構成された１つのレートコントローラであってもよい。具体的には、一部の実施形態では、２つのレートコントローラ３０２０及び３０４０は、２つの別個のレートコントローラを表す。あるいは、他の実施形態では、２つのレートコントローラ３０２０及び３０４０は、単一のレートコントローラの２つの異なる構成である。

図３０は、テレビ会議中に使用するレート制御動作のための符号化された状態情報を格納する状態バッファ３０１５を含むエンコーダドライバ３０１０も示す。具体的には、一部の実施形態では、２つの異なるレートコントローラ又は同じレートコントローラの２つの異なる構成は、状態バッファ３０１５に格納された同じ符号化状態情報をテレビ会議中に共有する。このように状態情報を共有することによって、デュアルビデオ取り込みテレビ会議において、均一なレートコントローラ動作が可能になる。この共有によって、単一のビデオ取り込みテレビ会議中のカメラ切り換え動作中に最適なビデオ符号化も可能になる（すなわち、現在のカメラによって取り込まれたビデオの符号化のためのレート制御動作が、直前のカメラによって取り込まれたビデオの符号化のためのレート制御動作によって維持された符号化状態情報を使用することが可能になる）。図３０は、エンコーダドライバ３０１０の一部である状態バッファ３０１５を示しているが、他の実施形態では、エンコーダドライバ３０１０の外に状態バッファ３０１５を実装する。

状態バッファ３０１５では、異なる実施形態は、符号化状態情報を表す異なるタイプのデータ（例えば、異なるタイプの符号化パラメータ）を格納する。このような符号化状態情報の一例が、テレビ会議用の現在の目標ビットレートである。目標ビットレートを識別するための１つの方式は、セクションＩＩＩ．Ｂにおいて上述した。このような符号化状態情報の他の例は、いくつかある符号化状態情報の中でも特に、バッファ占有量（buffer fullness）、最大バッファ占有量及び最近符号化されたフレームのビットレートのうちの１つ以上を含む。

その後、レートコントローラは、そのレート制御動作で使用される１つ以上のパラメータを算出するために、目標ビットレート（又は状態バッファに格納された別の符号化状態パラメータ）を使用できる。例えば、以下でさらに説明するように、一部の実施形態のレートコントローラは、マクロブロック又はフレームのための量子化パラメータＱＰを算出するために現在の目標ビットを使用する。例を挙げると、一部の実施形態では、マクロブロック及び／又はフレームの量子化パラメータＱＰを導出する量子化調整パラメータを計算するために、現在の目標ビットレートを使用する。したがって、テレビ会議のカメラ切り換え動作中に、（２つのレートコントローラの、又は１つのレートコントローラの２つの異なる構成の）２つのレート制御動作間で目標ビットレートを共有することによって、現在のカメラによって取り込まれたビデオを符号化するためのレート制御動作は、直前のカメラによって取り込まれたビデオを符号化するための直前のレート制御動作からの符号化状態データの恩恵を受ける。

図３０は、２つの異なるレート−コントローラインスタンス３０２０及び３０４０を含むようにエンコーダドライバ３０１０を示す。しかし、他の実施形態では、これらのレートコントローラインスタンス３０２０及び３０４０は、ビデオエンコーダ３０３０に組み込まれる。ビデオエンコーダ３０３０は、カメラ３０６０及び３０７０から取り込まれたビデオ画像をデジタルビットストリーム３０８０及び３０９０に符号化する。一部の実施形態では、ビデオエンコーダは、従来のビデオ符号化標準（例えば、Ｈ．２６４ ＭＰＥＧ−４）に準拠するビットストリームを生成する。これらの実施形態のうちの一部では、ビデオエンコーダは、動き推定、離散コサイン変換（「ＤＣＴ」）、量子化及びエントロピー符号化を含む符号化動作を実行する。ビデオエンコーダは、符号化動作の逆の機能である復号動作も実行する。

一部の実施形態では、エンコーダ３０３０は、量子化を実行するための量子化器モジュール３０３２を含む。量子化器モジュールは、レートコントローラ３０２０又は３０４０から量子化パラメータ３０２２又は３０４２によって制御される。一部の実施形態では、各量子化パラメータは、以下でさらに説明するように、対応するレートコントローラによって設定され、レートコントローラに関連するカメラの１つ以上の属性の関数である。レートコントローラは、より粗い量子化ステップサイズの設定に従って符号化に使用されるビット数を減少させることもできるし、より細かい量子化ステップサイズの設定によって使用されるビット数を増加させることもできる。量子化ステップサイズを制御することによって、レートコントローラはまた、符号化されたビデオ画像にどれほど多くの歪みがもたらされているかを判定する。したがって、レートコントローラは、ビットレートと画像品質とのトレードオフを実行できる。レート−歪みのトレードオフを実行するにあたり、レートコントローラは、メモリバッファのオーバーフロー、メモリバッファのアンダーフロー、又は伝送チャネル容量の超過を起こさないように、ビットレートを監視する。レートコントローラはまた、実現しうる最高の画像品質を提供し、量子化による画像品質の許容できない歪みを回避するために、ビットレートを制御しなければならない。一部の実施形態では、各レートコントローラは、監視されたデータを状態データ値の集合として状態バッファ３０１５に格納する。一部の実施形態では、レートコントローラ３０２０及び３０４０は、レート−歪みのトレードオフを最適化するために、カメラ固有の属性を使用する。

一部の実施形態では、各レートコントローラは、その量子化パラメータに変更係数を直接適用することによって、レート−歪みのトレードオフを最適化する。これらの実施形態のうちの一部では、変更係数は事前に決められており、カメラと共にデバイスに組み込まれている。デバイスは、これらの変更係数を動的に計算する必要はない。他の実施形態では、システムは、カメラに固有の適切な変更係数を動的に決定するために、カメラによって取り込まれた到来する画像を使用する。これらの実施形態のうちの一部では、システムは、カメラに関する特定の統計を収集するために、複数の符号化経路（pass）でカメラによって取り込まれた到来するビデオ画像のシーケンスを分析する。その後、システムは、これらの統計を使用して、カメラに最適化された量子化パラメータに対する変更係数を導出する。

一部の実施形態では、これらのカメラ固有の変更係数は、ビデオ画像の視覚マスキング属性を介して量子化パラメータに適用される。画像又は画像の一部分の視覚マスキング属性は、画像又は画像部分にどれほど多くの符号化アーチファクトが容認できるかの指標である。一部の実施形態は、画像又は画像部分の輝度エネルギーを定量化する視覚マスキング属性を計算するが、他の実施形態は、画像又は画像部分の活動エネルギー（activity energy）又は複雑さを定量化する視覚マスキング属性を計算する。視覚マスキング属性がどのようにして算出されるかに関係なく、一部の実施形態は、ビデオフレームのための変更された又はマスクされた量子化パラメータを算出するために視覚的マスキング属性を使用する。これらの実施形態のうちの一部は、マスクされた量子化パラメータを、フレームレベルの視覚マスキング属性φ_frame及び参照視覚マスキング属性φ_Rの関数として算出する。一部の実施形態では、視覚マスキング属性φ_frame及びφ_Rによって変更された量子化パラメータは、以下のように表される。

ＭＱＰ_frame＝ＱＰ_nom＋β_frame＊（φ_frame−φ_R）／φ_R （１）
上式で、ＭＱＰ_frameは、フレームのマスクされた又は変更された量子化パラメータであり、ＱＰ_nomは、初期量子化値又は名目量子化値であり、β_frameは、局所統計量に適合する定数である。一部の実施形態では、参照視覚マスキング属性φ_R及び名目量子化パラメータＱＰ_nomは、ネットワーク状態の初期評価又は定期的評価から事前に決められている。

一部の実施形態では、式（１）の視覚マスキング属性φ_frameは、以下のように算出される。

φ_frame＝Ｃ・（Ｅ・ａｖｇＦｒａｍｅＬｕｍａ）^β・（Ｄ・ａｖｇＦｒａｍｅＳＡＤ）^α （２）
上式で、ａｖｇＦｒａｍｅＬｕｍａはフレームの平均輝度値であり、ａｖｇＦｒａｍｅＳＡＤは、フレームの平均絶対値差分和である。定数α、β、Ｃ、Ｄ及びＥは、局所統計量に適合する。これらの定数は、一部の実施形態では、カメラ固有の特性に適合する。

一部の実施形態は、マクロブロックなどのビデオ画像の一部分のためのマスクされた量子化パラメータも算出する。それらの例では、マスクされた量子化パラメータは、以下のように、マクロブロック視覚マスキング属性φ_MBの関数として算出される。

ＭＱＰ_MB＝ＭＱＰ_frame＋β_MB＊（φ_MB−φ_frame）／φ_frame （３）
上式で、β_MBは局所統計量に適合する定数であり、ＭＱＰ_frameは一部の実施形態では式（１）及び式（２）を使用して算出される。一部の実施形態では、式（３）の視覚マスキング属性φ_MBは、以下のように算出される。

φ_MB＝Ａ・（Ｃ・ａｖｇＭＢＬｕｍａ）^β・（Ｂ・ＭＢＳＡＤ）^α （４）
上式で、ａｖｇＭＢＬｕｍａはマクロブロックの平均輝度値であり、ａｖｇＭＢＳＡＤはマクロブロックの平均絶対値差分和である。定数α、β、Ａ、Ｂ及びＣは、局所統計量に適合する。これらの定数は、一部の実施形態では、カメラ固有の特性に適合する。

一部の実施形態は、上述のように複数のカメラ固有の定数を使用して変更された量子化パラメータを算出するのではなく、単一のカメラ固有の係数のみを使用して量子化パラメータを計算することによってカメラ固有のレート制御を実行する。例えば、視覚マスキング属性φ_frame及びφ_MB並びに量子化パラメータＱＰ_frameを前提として、一部の実施形態は、単一のカメラ固有の係数μを使用して、マクロブロックの量子化パラメータを以下のように算出する。

ＱＰ_MB＝μ＊（φ_frame−φ_MB）＋ＱＰ_frame （５）
式（５）を計算するため、一部の実施形態は、フレーム及びマクロブロックの複雑性尺度をそれぞれ視覚マスキング属性φ_frame及びφ_MBとして使用する。

一部の実施形態は、ＱＰ_MBの算出に異なるカメラ固有の係数を適用する。例えば、一部の実施形態では、ＱＰ_MBは以下のように算出される。

ＱＰ_MB＝ρ・（１−φ_MB／φ_frame）・ＱＰ_frame＋ＱＰ_frame （６）
上式で、ρは、カメラ固有の特性に合わされた係数である。

上述のように、状態バッファ３０１５は、２つの異なるレートコントローラインスタンス３０２０及び３０４０がレート制御動作からより良い符号化結果を得るためにテレビ会議中に共有しうる符号化状態情報を格納する。目標ビットレートＲ_Tは、一部の実施形態では、このような共有される状態情報の一例である。このレートは、フレームのシーケンスを符号化するのに望ましいビットレートである。典型的には、このビットレートは、ビット／秒の単位で表記され、セクションＩＩＩ．Ｂで上述したプロセスのようなプロセスに基づいて決定される。

上述のように、一部の実施形態のレートコントローラは、ビデオエンコーダ３０３０に出力するフレーム及び／又はマクロブロック量子化パラメータ（群）ＱＰを算出するために目標ビットレートを使用する。例えば、一部の実施形態は、マクロブロック及び／又はフレームについての量子化パラメータＱＰを導出する量子化調整パラメータを算出するために、現在の目標ビットレートを使用する。一部の実施形態では、量子化調整パラメータは、直前のフレームのビットレート又は直前のフレームのビットレートの移動平均のいずれかを現在の目標ビットレートで除算することによって計算される比で表される。他の実施形態では、この調整パラメータは、このように正確に計算されるのではなく、より一般的には、（１）直前のフレームのビットレート又は直前のフレームのビットレートの移動平均に比例し、及び（２）現在の目標ビットレートに反比例する。

このような量子化調整パラメータを計算した後、一部の実施形態のレートコントローラは、このパラメータを使用し、マクロブロック及び／又はフレームの量子化パラメータ（群）を計算して調整する。このような調整を行う１つの方式は、計算されたマクロブロック及び／又はフレームの量子化パラメータ（群）に量子化調整パラメータを乗算することである。この調整を行う別の方式は、量子化調整パラメータから量子化パラメータオフセット値を計算し、その後、このパラメータオフセットを、計算されたマクロブロック及び／又はフレームの量子化パラメータ（群）に適用（例えば、減算）することである。その後、これらの実施形態のレートコントローラは、調整されたマクロブロック及び／又はフレームの量子化パラメータ（群）をビデオエンコーダ３０３０に出力する。

他の実施形態では、レートコントローラは、目標ビットレートを使用して、そのレート制御動作で使用される他のパラメータを算出する。例えば、一部の実施形態では、レートコントローラは、このビットレートを使用して、マクロブロック又はフレームの視覚マスキング強度を変更する。

Ｇ．ネットワーキングマネージャ
図３１は、図１６に示されるネットワーキングマネージャ１６１４などの一部の実施形態のネットワーキングマネージャ３１００のためのソフトウェアアーキテクチャを概念的に示す。上述のように、ネットワーキングマネージャ３１００は、テレビ会議においてネットワーキングマネージャ３１００が動作するデュアルカメラ携帯デバイスとリモートデバイスとの間のネットワーク接続（例えば、接続の確立、接続の監視、接続の調整、接続の切断など）を管理する。テレビ会議中に、一部の実施形態のネットワーキングマネージャ３１００はまた、リモートデバイスへの伝送のためにデータを処理し、リモートデバイスから受信したデータを処理する。

図３１に示すように、ネットワーキングマネージャ３１００は、セッションネゴシエーションマネージャ３１０５と、送信器モジュール３１１５と、汎用伝送バッファ３１２０と、汎用伝送バッファマネージャ３１２２と、仮想トランスポートプロトコル（ＶＴＰ）マネージャ３１２５と、受信器モジュール３１３０と、メディアトランスポートマネージャ３１３５とを含む。

セッションネゴシエーションマネージャ３１０５は、プロトコルマネージャ３１１０を含む。プロトコルマネージャ３１１０は、送信器モジュール３１１５が適切な通信プロトコルを使用してテレビ会議中にデータをリモートデバイスに伝送し、使用される通信プロトコルのルールを実施することを保証にする。プロトコルマネージャ３１１０の一部の実施形態は、とりわけ、リアルタイムトランスポートプロトコル（ＲＴＰ）、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）などのいくつかの通信プロトコルをサポートする。

セッションネゴシエーションマネージャ３１０５は、デュアルカメラ携帯デバイスとテレビ会議に参加している１つ以上のリモートデバイスとの間の接続の確立並びに会議後のこれらの接続の切断を担当する。一部の実施形態では、セッションネゴシエーションマネージャ３１０５は、（例えば、セッション開始プロトコル（ＳＩＰ）を使用して）テレビ会議におけるデュアルカメラ携帯デバイスとリモートデバイスとの間の（例えば、ビデオストリーム及び／又はオーディオストリームを送受信するための）マルチメディア通信セッションの確立も担当する。

セッションネゴシエーションマネージャ３１０５はまた、メディアトランスポートマネージャ３１３５からフィードバックデータを受け取り、このフィードバックデータに基づいて、汎用伝送バッファマネージャ３１２２を通した汎用伝送バッファ３１２０の動作（例えば、パケット／フレームを伝送するか破棄するか）を決定する。このフィードバックは、一部の実施形態では、片道レイテンシ及び帯域幅推定ビットレートを含んでもよい。他の実施形態では、フィードバックは、（例えば、テレビ会議においてリモートデバイスに送信されるパケット及びそのデバイスからの確認応答の受信に基づいて決定される）パケット損失情報及びラウンドトリップ遅延時間を含む。セッションネゴシエーションマネージャ３１０５は、メディアトランスポートマネージャ３１３５からの情報に基づいて、送信されているパケットが多すぎるかどうかを判定し、汎用伝送バッファマネージャ３１２２に、汎用伝送バッファ３１２０に送るパケットをより少なくするように（すなわち、図１５で説明するようにビットレートを調整するように）命令できる。

送信器モジュール３１１５は、符号化された画像を（例えば、ビットストリームとして）ビデオバッファ（例えば、図１６のバッファ１６１２）から読み出し、汎用伝送バッファ３１２０及び仮想トランスポートプロトコルマネージャ３１２５を通じてテレビ会議でのリモートデバイスへの伝送のために画像をパケット化する。符号化された画像が作製され送信器モジュール３１１５に送られる方式は、メディアトランスポートマネージャ３１３５及び／又はセッションネゴシエーションマネージャ３１０５から受け取った命令又はデータに基づくことができる。一部の実施形態では、画像のパケット化は、受け取ったビットストリームを、それぞれ特定のサイズ（すなわち、特定のプロトコルに従ってセッションネゴシエーションマネージャ３１０５によって指定されたサイズ）を有するパケットのグループに分解すること、及び任意の必要なヘッダ（例えば、アドレスヘッダ、プロトコル指定ヘッダなど）を追加することをも含む。

汎用伝送バッファマネージャ３１２２は、セッションネゴシエーションマネージャ３１０５から受け取ったデータ及び／又は命令に基づいて、汎用伝送バッファ３１２０の動作を制御する。例えば、汎用伝送バッファマネージャ３１２２は、データを送る、データの送出を中止する、データを破棄するなどのように汎用伝送バッファ３１２０に指示するよう命令されうる。上述のように、一部の実施形態では、会議に参加しているリモートデバイスは、パケットを破棄しているように見えるが、これは、リモートデバイスから受信された確認応答に基づいて認識されよう。パケット破棄を低減するため、汎用伝送バッファマネージャ３１２２は、より遅いレートでリモートデバイスにパケットを伝送するように命令されうる。

汎用伝送バッファ３１２０は、送信器モジュール３１１５から受け取ったデータを格納し、ＶＴＰマネージャ３１２５を介してリモートデバイスにデータを伝送する。前述のように、汎用伝送バッファ３１２０は、汎用伝送バッファマネージャ３１２２から受け取った命令に基づいてデータ（例えば、ビデオの画像）を破棄してもよい。

一部の実施形態では、ＲＴＰは、テレビ会議中にＵＤＰを介してデータパケット（例えば、オーディオパケット及びビデオパケット）を通信するために使用される。他の実施形態は、テレビ会議中にＴＣＰを介してデータパケットを通信するためにＲＴＰを使用する。異なる実施形態では、他のトランスポート層プロトコルも使用できる。

一部の実施形態は、１対のポート番号（すなわち、送信元ポート番号及び宛先ポート番号）によって、２つの携帯デバイス間の特定の通信チャネルを定義する。例えば、携帯デバイス間のある通信チャネルは、あるポート番号ペア（例えば、送信元ポート５０及び宛先ポート１００）によって定義でき、携帯デバイス間の別の異なる通信チャネルは、別の異なるポート番号ペア（例えば、送信元ポート７５及び宛先ポート１５０）によって定義されうる。一部の実施形態は、通信チャネルを定義するにあたって、１対のインターネットプロトコル（ＩＰ）アドレスも使用する。一部の実施形態では、異なる通信チャネルが、異なるタイプのデータパケットを伝送するために使用される。例えば、ビデオデータパケット、オーディオデータパケット及び制御信号データパケットが、別個の通信チャネルで伝送されうる。したがって、ビデオ通信チャネルはビデオデータパケットを搬送し、オーディオ通信チャネルはオーディオデータパケットを搬送する。

一部の実施形態では、制御通信チャネルは、テレビ会議中にローカル携帯デバイスとリモートデバイスとの間でメッセージを伝送するためのものである。このようなメッセージ伝送の例は、要求、通知及びこのような要求及び通知に対する確認応答の送受信を含む。メッセージ伝送の別の例は、あるデバイスから別のデバイスへの遠隔制御命令メッセージの送信を含む。例えば、以下で説明する遠隔制御動作（例えば、ある特定のカメラからの画像のみを送信するように、又は特定のカメラで画像のみを取り込むように、デバイスに命令すること）は、ローカルデバイスがリモートデバイスの動作を遠隔制御するために、制御通信チャネルを通じてローカルデバイスからリモートデバイスに命令を送信することによって実行されうる。異なる実施形態は、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）、ＲＴＰ拡張、ＳＩＰなどのようなさまざまなプロトコルを使用して制御通信を実施する。例えば、一部の実施形態は、テレビ会議において２つの携帯デバイス間で、ある制御メッセージ集合を中継するためにＲＴＰ拡張を使用し、テレビ会議中に携帯デバイス間で別の制御メッセージ集合を中継するためにＳＩＰパケットを使用する。

一部の実施形態のＶＴＰマネージャ３１２５により、異なる通信チャネルを通じて（例えば、異なるポート番号ペアを使用して）伝送されるように指定された異なるタイプのデータパケットが、単一の通信チャネルを介して（例えば、同じポート番号ペアを使用して）伝送されることが可能になる。これを行うための１つの技術は、データパケットタイプを識別すること、データパケットの指定されたポート番号ペアを抽出することによってデータパケットが伝送されるように指定された通信チャネルを識別すること、及び単一の通信チャネルのポート番号ペアとなるようにデータパケットのポート番号ペアを変更する（すなわち、すべてのデータパケットが同じポート番号ペアを介して伝送される）ことによって単一の通信チャネルを通じて伝送されるべきデータパケットを指定することを含む。

各タイプのデータパケットに対する元のポート番号ペアを追跡するため、一部の実施形態は、データパケットタイプに対する元のポート番号ペアのマッピングを格納する。その後、これらの実施形態のうちの一部は、１つの通信チャネルに多重化されている異なるパケットを区別するために、プロトコルのパケットタイプフィールドを使用する。例えば、ＶＴＰマネージャにオーディオパケット、ビデオパケット及び制御パケットを１つのＲＴＰストリームに多重化させる一部の実施形態は、テレビ会議において他のデバイスに１つのＲＴＰチャネルで伝送されるオーディオパケット、ビデオパケット及び制御パケットを区別するために、ＲＴＰパケットタイプフィールドを使用する。これらの実施形態のうちの一部では、ＶＴＰマネージャはまた、他のデバイスへのＳＩＰパケットにおける制御メッセージ伝送を経路制御する。

一部の実施形態では、異なるプロトコルを使用して通信された異なるパケットを区別するために（例えば、ＲＴＰを使用して搬送されたパケットとＳＩＰを使用して搬送されたパケットとを区別するために）、データパケット署名（すなわち、パケットヘッダフォーマット）を識別して調べる。このような実施形態では、異なるプロトコルのデータパケットが判定された後、同じプロトコルを使用するデータパケット（例えば、ＲＴＰを使用するオーディオデータ及びビデオデータ）のフィールドが上述のように調べられて、異なるデータタイプを識別する。このようにして、ＶＴＰマネージャ３１２５は、異なる通信チャネルを通じて伝送されることを意図された異なるデータパケットを単一の通信チャネルを通じて伝送する。

単一の通信チャネルを通じて異なるタイプのデータを結合する１つの手段について上述したが、他の実施形態では、他の技術を利用して、異なるパケットタイプを１つの通信ストリームに多重化する。例えば、一部の実施形態の１つの技術は、データパケットの元のポート番号ペアを追跡すること、及び後で抽出するためにデータパケット自体に元のポート番号ペアを格納することを含む。２人のテレビ会議参加者間での異なるタイプのデータを１つのポートペアチャネルに結合するためのさらに他の仕方が存在する。

ＶＴＰマネージャ３１２５がリモートデバイスから仮想通信チャネルを通じてデータパケットを受信する場合に、ＶＴＰマネージャ３１２５は、異なるプロトコルを使用して送信される異なるパケットを識別するためにデータパケットの署名を調べる。このような署名は、ＲＴＰパケットからＳＩＰパケットを区別するために使用されうる。一部の実施形態のＶＴＰマネージャは、単一の仮想チャネルに多重化された種々の異なるタイプのパケット（例えば、オーディオパケット、ビデオパケット及び制御パケット）を逆多重化するためにも、パケットの一部又は全部のパケットタイプフィールドを使用する。これらの異なるタイプのパケットを識別した後、ＶＴＰマネージャは、それが管理するポートペア番号とパケットタイプとのマッピングに基づいて、それぞれ異なるタイプのパケットをその対応するポートペア番号と関連付ける。その後、ＶＴＰマネージャ３１２５は、データパケットのポート番号ペアを、識別されたポート番号ペアで変更し、逆パケット化されるべきデータパケットを転送する。異なるパケットタイプを単一のチャネルに多重化するために異なる技術を使用する他の実施形態では、ＶＴＰマネージャは、パケットを解析するための異なる技術を使用する。

ＶＴＰマネージャ３１２５は、異なるパケットの多重化及び逆多重化を行うためのこのような技術を使用することによって、単一の仮想通信チャネル（例えば、単一のポート番号ペア）を生成し、この単一の仮想通信チャネルを通じてビデオデータ、オーディオデータ及び制御信号データを伝送し、この単一の仮想通信チャネルを通じてリモートデバイスからオーディオパケット、ビデオパケット及び制御パケットを受信する。したがって、ネットワークの観点からは、この単一の仮想通信チャネルを介してデータが伝送されるが、セッションネゴシエーションマネージャ３１０５及びプロトコルマネージャ３１１０の観点からは、異なる通信チャネルを通じてビデオデータ、オーディオデータ及び制御信号データが伝送される。

テレビ会議においてリモートデバイスに伝送される画像と同様に、テレビ会議においてリモートデバイスから伝送される画像はパケット形式で受信される。受信器モジュール３１３０は、パケットを受信し、そのパケットを逆パケット化して、画像を再構成してから、復号されるべき画像をビデオバッファ（例えば、図１６のバッファ１６１６）に格納する。一部の実施形態では、画像を逆パケット化することは、任意のヘッダを削除すること、及びパケットから画像データ（及び場合によってはサイズデータ）のみを有するビットストリームを再構成することを含む。

メディアトランスポートマネージャ３１３５は、データ伝送の速度（すなわち、ビットレート）を動的かつ適応的に調整するために、ネットワークから受信したフィードバックデータ（例えば、片道レイテンシ、帯域幅推定ビットレート、パケット損失データ、ラウンドトリップ遅延時間データなど）を処理する。メディアトランスポートマネージャ３１３５はまた、一部の他の実施形態では処理されたフィードバックデータに基づいて誤り耐性を制御し、拡大縮小、サイズ変更及び符号化などのテレビ会議モジュール１６０２の他の動作を調整するためにテレビ会議マネージャ１６０４にフィードバックデータを送信してもよい。会議においてリモートデバイスがパケットのすべてを処理できるとは限らない場合に汎用伝送バッファにパケットを破棄させることに加えて、テレビ会議モジュール及びエンコーダは、画像ごとにより少ないパケットが送信されるように、画像を符号化するためにより低いビットレートを使用できる。

一部の実施形態では、メディアトランスポートマネージャ３１３５はまた、上述のように、カメラの動作電力モードがどのように構成されるかに影響を及ぼしうる、消費電力及び熱的レベルなどのデバイスの他の変数を監視してもよい。このデータは、フィードバックデータへの追加入力として使用されてもよい（例えば、デバイスが熱くなりすぎているならば、メディアトランスポートマネージャ３１３５は、処理速度を落とさせようとしてもよい）。

ここで、ネットワーキングマネージャ３１００のいくつかの例示的な動作について、図１６に関して説明する。テレビ会議においてデュアルカメラ携帯デバイスのカメラによって取り込まれた画像のリモートデバイスへの伝送について最初に説明し、続いて、リモートデバイスからの画像の受信について説明する。送信器モジュール３１１５は、符号化された画像をバッファ１６１２から読み出し、この画像は、テレビ会議においてリモートデバイスに伝送されうる。

プロトコルマネージャ３１１０は、使用するのに適切なプロトコル（例えば、オーディオ及びビデオを伝送するためのＲＴＰ）を決定し、セッションネゴシエーションマネージャ３１０５は、このようなプロトコルを送信器モジュール３１１５に通知する。次に、送信器モジュール３１１５は、画像をパケット化し、パケット化された画像を汎用伝送バッファ３１２０に送る。汎用伝送バッファマネージャ３１２２は、セッションネゴシエーションマネージャ３１０５から命令を受け取り、画像を伝送又は破棄するように汎用伝送バッファ３１２０に指示する。ＶＴＰマネージャ３１２５は、汎用伝送バッファ３１２０からパケットを受け取り、単一の通信チャネルを通じてリモートデバイスにパケットを伝送するためにパケットを処理する。

リモートデバイスから画像を受信した場合に、ＶＴＰマネージャ３１２５は、仮想化された単一の通信チャネルを通じてリモートデバイスからパケット化された画像を受信し、画像を受信するために割り当てられた通信チャネル（例えば、ビデオ通信チャネル）を通じて受信器モジュール３１３０に画像を向けるためにパケットを処理する。

受信器モジュール３１３０は、画像を再構成するためにパケットを逆パケット化し、デコーダ１６６０によって復号するためにバッファ１６１６に画像を送信する。受信器モジュール３１３０はまた、メディアトランスポートマネージャ３１３５に制御信号メッセージ（例えば、テレビ会議においてリモートデバイスから受信したパケットの確認応答）を転送する。

ネットワーキングマネージャ３１００のいくつかの例示的な動作について上述した。これらは、例示的な例にすぎない。その理由は、種々の他の実施形態は、異なるモジュールを使用して、又はモジュール間に異なるように拡散された機能を用いて、これらの又は異なる動作を実行するからである。そのうえ、ネットワーキングマネージャ３１００のモジュール又は他のモジュールによって動的なビットレート調整などの追加の動作が実行されてもよい。

ＩＶ．会議中の調整及び制御動作
Ａ．ピクチャインピクチャの変更
１．コーナー向けスナップ
本発明の一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、合成表示を形成する１つ以上の表示域を移動させることによって、デバイスに表示された合成表示を変更する。１つのこのような例は、ＰＩＰ表示の挿入表示域を移動させることである。図３２は、テレビ会議中に実行されるこのような例を示す。テレビ会議では、ユーザは、このエリアが背景表示域の関心エリアを遮っている場合など、さまざまな理由で前景挿入表示域を移動させたいかもしれない。

図３２は、デバイスのＵＩ３２０５における挿入表示域３２４０の移動を、このＵＩの５つの異なる段階３２１０、３２１５、３２２０、３２２５及び３２３０として示す。第１段階３２１０は、デバイスのローカルユーザとリモートデバイスのリモートユーザとの間のテレビ会議中のＵＩ３２０５を示す。図３２のＵＩ３２０５は、テレビ会議が開始した後の図１１の第５段階に示されている同じＰＩＰ表示であるＰＩＰ表示を示す。この例では、ローカルユーザのデバイスによって取り込まれたビデオが挿入表示域３２４０に表示され、リモートユーザのデバイスによって取り込まれたビデオが背景表示域３２３５に表示されている。図示のように、表示域１１５５は、テレビ会議を終了させるために選択可能ＵＩ項目３２４５を含む。一部の実施形態では、表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。

第２段階３２１５は、ユーザが挿入表示域３２４０を選択することによってコーナー向けスナップ動作を開始することを示す。この例では、挿入表示域３２４０内の任意の位置に指３２５５を置くことによって選択がなされる。図示のように、この選択は、挿入表示域３２４０の太い境界線３２６０として表示される。異なる実施形態は、表示域３２４０を強調表示することによって、表示域３２４０を振動させることによってなど、異なる仕方でこのような選択を示してもよい。

第３段階３２２０は、ユーザがＰＩＰ表示３２５０内のあるエリアからこの表示内の別のエリアにＰＩＰ表示３２５０の挿入表示域３２４０を移動させ始めた後のＵＩ３２０５を示す。この例では、挿入表示域３２４０は、矢印３２６５によって示されるように、ＰＩＰ表示３２５０の左下隅からこの表示の右下隅に移動し始めている。この例では、挿入表示域３２４０は、第２段階３２１５で挿入表示を選択した後でユーザが自身の指３２５５をＰＩＰ表示３２５０の右下隅に向かってドラッグすることによって、移動される。一部の実施形態は、ＰＩＰ表示３２５０において挿入表示域３２４０を移動させるための他の技術を提供する。

第４段階３２２５は、ユーザがデバイス３２００の画面から自身の指３２５５を離した後の状態にあるＵＩ３２０５を示す。この状態では、挿入表示域３２４０は、依然として、第３段階３２２０におけるユーザの指の移動に基づいて識別された、ＰＩＰ表示３２５０の右下隅に向かって移動している。言い換えれば、指３２５５がＰＩＰ表示３２５０の右下隅に向かっての挿入表示域３２４０の移動を開始した後、ＵＩ３２０５は、指３２５５を離した後でさえも、この移動を維持する。この移動を維持するため、一部の実施形態のＵＩ３２０５は、ユーザが自身の指３２５５を離す前に、ユーザのドラッグ動作が特定のしきい値量よりも大きい（例えば、特定の距離又は特定の時間長よりも大きい）ことを必要とする。そうでない場合、これらの実施形態は、挿入表示域３２４０をわずかに移動させた後、又はまったく移動させなかった後、この表示域３２４０をその元の左隅位置に保つ。

しかし、一部の実施形態により、挿入表示域がその新たな位置に到達する前にユーザがドラッグ動作を止めた後でさえも、挿入表示域が移動できるが、他の実施形態は、挿入表示域がその新たな位置に到達するまで自身のドラッグ動作を維持するようにユーザに要求する。一部の実施形態は、挿入表示域を移動させるためのさらに他の技術を提供する。例えば、一部の実施形態は、挿入表示域３２４０が実際に移動し始める前に挿入表示域３２４０をどこに向けるべきかなどを指定することがユーザに要求してもよい。一部の実施形態は、携帯デバイスを異なる角度に傾斜させるだけで、表示域がスライド可能であり、コーナー向けスナップ動作が可能になってもよい。

第５段階３２３０は、挿入表示域３２４０がＰＩＰ表示３２５０の右下隅でその新たな位置に到達した後のＵＩ３２０５を示す。第５段階３２３０における太い境界線３２６０の除去は、コーナー向けスナップ動作が完了したことを示す。

上述の第３段階３２２０、第４段階３２２５及び第５段階３２３０に示されている移動を容易にするため、一部の実施形態のＵＩ３２０５は、ユーザが挿入表示域をＰＩＰ表示３２５０の隅に向かって移動させると、挿入表示域がその隅にすばやくスナップできるスナップルールを用いる。例えば、ユーザが特定の隅に向かってしきい値量を超えて挿入表示域３２４０をドラッグした場合に、一部の実施形態のＵＩ３２０５は、挿入表示域３２４０の動きの方向を特定し、動きがしきい値量を超えたと判定し、その後、挿入表示域３２４０をスナップできるＵＩ３２０５内の次のグリッド点をユーザがさらに入力しなくても、挿入表示域３２４０を自動的に移動する。一部の実施形態では、挿入表示域３２４０をスナップするために提供されるグリッド点のみが、ＰＩＰ表示３２５０の４つの隅におけるグリッド点である。他の実施形態は、ＵＩ３２０５内に（例えば、ＰＩＰ表示３２５０内に）、挿入表示域３２４０がスナップできる（すなわち、エリア３２４０の辺又は頂点に置くか又は位置合わせされうる）他のグリッド点を提供する。

さらに他の実施形態は、挿入表示域をＰＩＰ表示３２５０の任意の点に配置できるように、グリッド点を採用しなくてもよい。さらに他の実施形態は、ユーザがＵＩのグリッド点機能へのスナップをオン又はオフにできる機能を提供する。さらに、異なる実施形態により、ユーザは、デバイスから取り込まれたビデオに加えて、アイコンなどの種々の項目を用いたコーナー向けスナップ動作が可能になってもよい。

図３３は、ＵＩ３２０５におけるコーナー向けスナップ動作の他の２つの例３３３０及び３３３５を示す。これらの他のコーナー向けスナップ動作は、ユーザの垂直又は斜めのドラッグ動作に基づいて、挿入表示域３２４０がＰＩＰ表示３２５０内で垂直又は斜めに移動されることを示す。

図３２及び図３３はＰＩＰ表示内での挿入表示域の移動を示しているが、他の実施形態は、同様の技術を利用して、他のタイプのＰＩＰ表示又は他のタイプの合成表示において表示域を移動することが当業者には理解されよう。例えば、以下でさらに説明するように、一部の実施形態のＰＩＰ表示は２つ以上の前景挿入表示を有し、これらの挿入表示は、図３２及び図３３に関して上述した技術と同様の技術を使用して、ＰＩＰ表示において移動されうる。また、一部の実施形態は、同様の技術を使用して、合成表示で表示域を移動させる（例えば、ユーザのドラッグ移動を通じて、ある表示域を画面の左側から画面の右側に移動させる）。そのうえ、合成表示の表示域（群）の移動によって、テレビ会議マネージャ１６０４にユーザの入力に応答して合成表示で表示域を再合成させるなどの、デュアルカメラ携帯デバイスの画像処理動作の変更を引き起こすことができる。以下でさらに説明するように、一部の実施形態は、第１表示域を第１位置から押すと第２表示域が第３位置から第１位置に移動されるスナップアンドプッシュ（snap and push）技術を採用する。

２．回転
一部の実施形態は、テレビ会議に使用される携帯デバイスのユーザが会議中にデバイスを回転した場合に、テレビ会議中に提示されるＰＩＰ表示を回転する。図３４は、デバイスが垂直位置から水平位置に回転した場合のデバイス３４００のＵＩ１１０５の回転を示す。画面の長辺が垂直である場合にデバイス３４００は垂直に保持され、画面の長辺が水平である場合にデバイス３４００は水平に保持される。図３４に示される例では、ＵＩ１１０５は、デバイスの垂直保持に最適化された縦ビューから、デバイス３４００の水平保持に最適化された横ビューに回転する。この回転機能によって、ユーザは、携帯デバイス３４００が垂直又は水平のどちらに保持されている場合にも直立位置に表示されたＵＩ１１０５を見ることができる。

図３４は、ＵＩ１１０５の回転を、６つの異なる動作段階３４１０、３４１５、３４２０、３４２５、３４３０及び３４３５として示す。第１段階３４１０は、デバイスのローカルユーザとリモートデバイスのリモートユーザとの間のテレビ会議中のＵＩ１１０５を示す。図３４のＵＩ１１０５は、テレビ会議が確立された後の図１１の第５段階に示されているのと同じＰＩＰ表示であるＰＩＰ表示１１８０を示す。この例では、ローカルユーザのデバイスによって取り込まれたビデオが挿入表示域１１６０に表示され、リモートユーザのデバイスによって取り込まれたビデオが背景表示域１１７０に表示されている。ＰＩＰ表示１１８０の下の表示域１１５５には、選択可能ＵＩ項目３４８５（例えば、会議終了ボタン３４８５）が含まれ、ユーザは、このＵＩ項目を、テレビ会議を終了するために（例えば、シングルフィンガータップを通じて）選択してもよい。

第２段階３４１５は、ユーザがデバイス３４００を横に傾斜させ始めた後のＵＩ１１０５を示す。この例では、ユーザは、矢印３４６０によって示されるように、デバイス３４００を垂直に保持されている状態から水平に保持されている状態に傾斜させ始めている。ＵＩ１１０５の外見は変化しない。他の状況では、ユーザが、デバイス３４００を水平に保持されている状態から垂直に保持されている状態に傾斜させたいと考える場合もあり、これらの状況では、ＵＩ１１０５は、水平に最適化されたビューから垂直に最適化されたビューに切り換わる。

第３段階３４２０は、デバイス３４００が垂直に保持されている状態から水平に保持されている状態に傾斜された後の状態のＵＩ１１０５を示す。この状態では、ＵＩ１１０５の外見はまだ変化していない。一部の実施形態では、デバイス３４００がしきい値量を過ぎても傾斜されており、この点を超えて、ある期間保たれた後で、回転動作がトリガされる。図３４に示される例では、デバイスが水平位置に置かれた後、ある短期間の間隔が経過するまで、しきい値量及び回転の速度によってＵＩ１１０５が回転しないと想定されている。異なる実施形態は、回転動作をトリガするための異なるしきい値量及び待ち期間を有する。例えば、一部の実施形態は、デバイス３４００の向きとは関係なくＵＩ１１０５が常に直立位置に表示されるように見えさせるように、回転動作をトリガするためのしきい値が低くてもよい。他の実施形態では、デバイス３４００のユーザは、いつ回転動作をトリガできるかを（例えば、メニュー基本設定を通じて）指定してもよい。また、一部の実施形態は、デバイスがしきい値量を超えても傾斜されている後の回転を遅延させなくてもよい。さらに、異なる実施形態により、携帯デバイス上のスイッチを切り換えることによって、音声コマンドを与えることによって、メニューによる選択時などの、異なる仕方で、回転動作をトリガできてもよい。

第４段階３４２５は、回転動作が開始した後のＵＩ１１０５を示す。一部の実施形態は、回転動作に関するフィードバックをユーザに提供するために、回転表示域をアニメーション化する。図３４は、このようなアニメーションの一例を示す。具体的には、図３４は、その第４段階３４２５で、表示域１１８０及び１１５５が一緒に回転し始めるところを示している。表示域１１８０及び１１５５は、ＵＩ１１０５の中心を通る軸３４６５（すなわち、ｚ軸）のまわりを回転する。表示域１１８０及び１１５５は、デバイス３４００の回転の反対方向に（例えば、デバイス３４００の傾斜を通じて）同じ量だけ回転する。この例では、デバイス３４００が（垂直に保持される状態から水平に保持される状態に移ることによって）時計回り方向に９０度回転したので、この回転動作によって、表示域１１８０及び１１５５は反時計回り方向に９０度回転される。表示域１１８０及び１１５５が回転すると、表示域１１８０及び１１５５が依然としてＵＩ１１０５上で全体的に見えるように、表示域１１８０及び１１５５はＵＩ１１０５に合うように比例して縮む。一部の実施形態は、このデバイス３４００の状態を示すメッセージを（例えば、「回転中」という単語を表示することによって）提供してもよい。

第５段階３４３０は、表示域１１８０及び１１５５が縦ビューから横ビューに反時計回りに９０度回転した後のＵＩ１１０５を示す。この段階では、表示域１１８０及び１１５５は回転されているが、まだＵＩ１１０５の幅全体に拡張されていない。矢印３４７５は、第５段階の終了時に、表示域１１８０及び１１５５がＵＩ１１０５の幅全体に合うように側方に拡張し始めることを示す。拡張は第４段階３４２５での回転と同時に実行できるので、異なる実施形態は、この段階を含まなくてもよい。

第６段階３４３５は、表示域１１８０及び１１５５がＵＩ１１０５の表示全体を占有するように拡張された後のＵＩ１１０５を示す。上述のように、他の実施形態は、この回転を異なるように実施してもよい。一部の実施形態では、しきい値量を超えてデバイスの画面を回転するだけで、デバイス３４００の向きに関係なく、回転動作をトリガしてもよい。

また、他の実施形態は、回転動作を示すための異なるアニメーションを提供してもよいだろう。図３４で実行される回転動作は、表示域１１８０及び１１５５がＵＩ１１０５の中心のまわりを回転することを含む。あるいは、表示域は、これらの個別の表示域の中心軸のまわりを個別に回転してもよい。１つのこのような手法が図３５に示されている。図３５は、ＵＩ１１０５のＰＩＰ表示１１８０の表示域１１７０及び１１６０の回転をアニメーション化する代替方法を示す。図３５に示されるＰＩＰ表示１１８０は、図１１に示されるのと同じＰＩＰ表示１１８０である。

図３５は、ＰＩＰ表示１１８０の回転を、６つの異なる動作段階３４１０、３４１５、３４２０、３５２５、３５３０及び３５３５として示す。ＵＩ１１０５の動作の前半の３つの段階は、図３４のＵＩ１１０５に関して説明した動作の前半の３つの段階と同一である。図３４と図３５の両方に対する第３段階では、デバイス３５００は、垂直に保持された状態から水平に保持された状態に移っており、ＵＩ１１０５の回転はまだ開始していない。

第４段階３５２５は、回転をアニメーション化する代替方法を示す。この段階では、回転動作が開始している。具体的には、第４段階３５２５では、表示域１１７０及び１１６０が回転し始めるところが示されている。表示域１１７０及び１１６０は、それぞれ表示域のそれぞれの中心を通る軸３５６７及び３５６５（すなわち、ｚ軸）のまわりをそれぞれ回転する。表示域１１７０及び１１６０は、（例えば、デバイス３５００の傾斜による）デバイス３５００の回転の反対方向に同じ量だけ回転する。上記の図３４の第４段階３４２５に示されているのと同様に、デバイス３５００が（垂直に保持される状態から水平に保持される状態に移ることによって）時計回り方向に９０度回転したので、回転動作によって、表示域１１７０及び１１６０は反時計回り方向に９０度回転される。表示域１１７０及び１１６０が回転すると、表示域１１７０及び１１６０が依然としてＵＩ１１０５上で全体的に見えるように、表示域１１７０及び１１６０はＵＩ１１０５に合うように比例して縮む。

第５段階３５３０は、表示域１１７０及び１１６０のそれぞれが縦ビューから横ビューに反時計回りに９０度回転した後のＵＩ１１０５を示す。この段階では、表示域１１７０及び１１６０は回転したが、まだＵＩ１１０５の幅全体に拡張されていない。さらに、表示域１１６０は、その最終位置に移動していない。ＰＩＰ表示１１８０内の挿入表示域１１６０の最終位置は、第１段階３４１０に示されるＰＩＰ表示１１８０内の挿入表示域１１６０の位置（例えば、ＰＩＰ表示１１８０の左下隅の挿入表示域１１６０）によって決定される。この段階では、挿入表示域１１６０は、まだＵＩ１１０５の右上隅にある。

矢印３５８０は、第５段階３５３０の終了時に、水平に保持されているデバイスのＵＩ１１０５の幅全体にメイン表示域１１７０が合うまで、表示域１１７０及び１１６０が側方に拡張し始めることを示す。さらに、矢印３５７５は、挿入表示域１１６０がＰＩＰ表示１１８０の左下隅にスライドすることを示す。

異なる実施形態は、これを異なるように実施してもよい。一部の実施形態では、挿入表示域１１６０の移動は、メイン表示域１１７０の拡張と同時に、又は順次、行われてもよい。さらに、一部の実施形態は、新たなＰＩＰ表示１１８０を生成するために、メイン表示域１１７０の拡張前、拡張中に、又は拡張後に、挿入表示域１１６０をサイズ変更してもよい。この例では、表示域１１５５は、表示域１１６０及び１１７０が回転されている間、非表示になる。しかし、一部の実施形態では、表示域１１５５は、回転中にＵＩ１１０５に残存し、表示域１１６０及び１１７０と共に回転してもよい。

第６段階３５３５は、挿入表示域１１６０がその新たな位置に到達し、表示域１１６０及び１１７０がＵＩ１１０５の幅全体に合うように適切に拡張された後のＵＩ１１０５を示す。この例では、挿入表示域１１６０は、この時点では、ＰＩＰ表示１１８０の左下隅にあり、メイン表示域１１７０に重なっている。ＰＩＰ表示１１８０は、この時点で、第１段階３４１０のＰＩＰ表示１１８０と同じ表示構成を有する。第６段階におけるＰＩＰ表示１１８０の下の表示域１１５５の外見は、回転動作が完了したことを示す。前述のように、しきい値量を超えてデバイスの画面を回転するだけで、デバイス３５００の向きに関係なく、回転動作をトリガできる。

図３４及び図３５に関して上述した例では、表示域１１７０の向きも（すなわち、縦から横に）変化する。すなわち、表示域１１７０が第３段階３４２０で回転した後、ＵＩ１１０５全体を埋めるようにＰＩＰ表示１１８０を水平に拡張することによって、表示域１１７０の向きが縦から横に変化する。一部の実施形態では、デバイス３５００が回転した場合に、リモートデバイスによって取り込まれたビデオが回転するが、リモートデバイスによって取り込まれたビデオを表示する表示域の向きは変化しないままである。１つのこのような例が図３６に示されている。この図は、表示域１１７０に表示されるビデオは回転するが表示域１１７０は縦向きに表示されたままであることを除いて、図３５と同様である。

図３６は、表示域１１５５が（図３５に示されるように、回転して、ＰＩＰ表示１１８０を埋めるように水平に拡張するのではなく）同じ位置にあるままの回転動作の一例も示す。さらに、この図は、上述した図１２の表示域１１５５のレイアウトと同じである表示域１１５５のレイアウトを含む。図示のように、段階３６４０、３６４５、３６５０、３６５５、３６８５及び３６９０でデバイス３５００が回転するとき、表示域１１５５は同じ位置のままである。

一部の実施形態は、ローカルデバイスによって取り込まれたビデオを表示する表示域の向きが、（図３５に示すように同じ向きのままではなく）回転動作がローカルデバイスで実行された後のローカルデバイスの向きを反映するように変化する回転動作を提供する。図３６は、ＵＩ１１０５のこのような回転動作の一例を、６つの異なる段階３６４０、３６４５、３６５０、３６５５、３６８５及び３６９０として示す。この図では、第１段階３６４０は、デバイス３５００のカメラによって取り込まれたビデオを表示する挿入表示域１１６０を縦向きで示す。第２段階３６４５及び第３段階３６５０は、回転動作の種々の段階におけるデバイス３５００の傾斜を示しているので、図３５の第２段階３４１５及び第３段階３４２０と同様である。この時点で、デバイス３５００のカメラは、画像を横向きで取り込んでいる。この移行を示すために、一部の実施形態は、第４段階３６５５及び第５段階３６８５に示すアニメーションを提供するが、他の実施形態は、アニメーションをまったく提供しない。

第４段階３６５５では、第２段階３４４５及び第３段階３６５０におけるデバイス３５００の傾斜によって挿入表示域１１６０が横向きに回転されていたので、挿入表示域１１６０に表示された画像は回転されるが、挿入表示域１１６０自体は回転されない。第５段階３６８５では、挿入表示域１１６０における回転した画像は、挿入表示域１１６０を埋めるように水平に拡張され、挿入表示域１１６０は、第１段階３６４０のＰＩＰ表示内の挿入表示域１１６０と同じ相対的位置に挿入表示域１１６０を配置するために、ＰＩＰ表示１１８０の左下エリアに向かって移動し始める。

一部の実施形態では、リモートデバイスによって取り込まれたビデオを表示する表示域の向きも、回転動作がリモートデバイスで実行された後のリモートデバイスの向きを反映するように変化する。図３７は、デバイス３５００のＵＩ１１０５の４つの異なる段階を示し、これらの段階では、（１）ローカルデバイスによって取り込まれたビデオを表示する表示域（この例では表示域１１６０）の向きが、回転動作がローカルデバイスで実行された後のローカルデバイスの向きを反映するように変化し、（２）リモートデバイスによって取り込まれたビデオを表示する表示域（この例では表示域１１７０）の向きが、リモートデバイスで回転動作が実行された後のリモートデバイスの向きを反映するように変化する。

第１段階３７０５では、ＵＩ１１０５は、図３６のＵＩ１１０５と同じである。具体的には、デバイス３５００が縦向きで示され、リモートデバイスが縦向きである（不図示）ので、第１段階３７０５は表示域１１６０及び１１７０を縦向きで示す。第１段階３７０５から第２段階３７１０にかけて、デバイス３５００を直立位置から横向き位置に９０度回転することによって、回転動作がローカルデバイスで実行される。第２段階３７１０は、デバイス３５００の回転動作が完了した後のＵＩ１１０５を示す。この段階では、表示域１１７０及び１１６０に表示されたビデオは直立位置に回転している。しかし、回転動作がローカルデバイス（すなわち、デバイス３５００）でのみ実行されたので、ローカルで取り込まれたビデオの表示域１１６０のみが縦向きから横向きに回転した。表示域１１７０は縦向きのままである。

第２段階３７１０から第３段階３７１５にかけて、リモートデバイスを直立位置から横向き位置に回転することによって、回転動作がリモートデバイスで実行される（不図示）。第３段階３７１５は、リモートデバイスの回転動作が完了した後のＵＩ１１０５を示す。この段階では、回転動作がリモートデバイスのみで実行されるので、表示域１１７０に表示されたビデオ及びリモートで取り込まれたビデオの表示域１１７０が、縦向きから横向きに回転されている。したがって、ＵＩ１１０５のこの段階は、ローカルで取り込まれたビデオの表示域１１６０及びリモートで取り込まれたビデオの表示域１１７０をいずれも横向きで表示する。

第３段階３７１５から第４段階３７２０にかけて、デバイス３５００を横向き位置から直立位置に９０度回転することによって、回転動作がローカルデバイスで実行される。第４段階３７２０は、この回転動作の完了後のＵＩ１１０５を示す。この第４段階３７２０では、表示域１１６０及び１１７０に表示されたビデオが直立位置に回転されている。しかし、回転動作がローカルデバイス（すなわち、デバイス３５００）でのみ実行されたので、ローカルで取り込まれたビデオの表示域１１６０のみが横向きから縦向きに回転している。表示域１１７０は横向きのままである。

第４段階３７２０から第１段階３７０５にかけて、リモートデバイスを横向き位置から直立位置に９０度回転することによって、回転動作がリモートデバイスで実行される（不図示）。この場合、第１段階３７０５は、この回転動作の完了後の表示域１１７０を示す。したがって、この段階のＵＩ１１０５は、表示域１１６０及び１１７０を縦向きで示す。図３７は異なる回転動作のシーケンスを示しているが、他の実施形態は、任意の数の異なるシーケンスで任意の数の回転動作を実行できる。

図３４、図３５、図３６及び図３７は、テレビ会議中にローカルデバイス及びリモートデバイスで実行される回転動作を説明する。回転動作がローカル携帯デバイスで実行された場合に、一部の実施形態は、リモートデバイスがローカルデバイスのビデオに対する（ローカルデバイスのビデオを表示している表示域を回転するなどの）任意の変更も実行するために、リモートデバイスに回転動作を通知する。同様に、回転動作がリモートデバイスで実行された場合に、ローカルデバイスがリモートデバイスのビデオに対する任意の変更を実行できるようにするために、リモートデバイスはローカルデバイスにこの動作を通知する。一部の実施形態は、テレビ会議中にローカルデバイスとリモートデバイスとの間の回転動作の通知を通信するための制御通信チャネルを提供する。

図３４、図３５、図３６及び図３７は回転のアニメーションを実行できる異なる方式を示しているが、他の実施形態は他の異なる仕方で回転のアニメーションを表示してもよいことが当業者には理解されよう。さらに、回転動作のアニメーションによって、テレビ会議マネージャ１６０４にＵＩ１１０５において異なる角度で表示域（群）を再合成させ、表示域（群）に表示される画像を拡大縮小させるなどの、ローカル携帯デバイスの画像処理動作への変更を引き起こすことができる。

３．ウィンドウサイズの調整
一部の実施形態により、携帯デバイスのユーザは、テレビ会議中に提示されるＰＩＰ表示の挿入表示域のサイズを調整できる。異なる実施形態は、挿入表示域をサイズ変更するための異なる技術を提供する。図３８は、挿入表示域をサイズ変更するための１つの手法を示す。この手法では、携帯デバイスのユーザは、挿入表示域の隅を選択し、その後、挿入表示域を拡張する又は縮めることによって、挿入表示域のサイズを調整する。

図３８では、携帯デバイス３８２５のＵＩ３８００は、別の携帯デバイスのリモートユーザとのテレビ会議中にＰＩＰ表示３８６５を提示する。このＰＩＰ表示３８６５は、２つのビデオ表示、すなわち背景メイン表示域３８３０と、前景挿入表示域３８３５とを含む。背景メイン表示域３８３０はＰＩＰ表示３８６５の大半を占めるが、前景挿入表示域３８３５は背景メイン表示域３８３０よりも小さく、これに重なる。この例では、背景メイン表示域３８３０は、ギターを持つ人のビデオを提示し、この人は、リモートデバイスの前面カメラによってビデオが取り込まれている人又はリモートデバイスの背面カメラによってビデオが取り込まれている人であると想定される。前景挿入表示域３８３５は、帽子をかぶった人のビデオを提示し、この人は、この例では、ローカルデバイスの前面カメラによってビデオが取り込まれている人又はローカルデバイスの背面カメラによってビデオが取り込まれている人であると想定される。ＰＩＰ表示３８６５の下は、選択することによってユーザがテレビ会議を終了できる「会議終了」と標示された選択可能ＵＩ項目３８６０（例えばボタン３８６０）を含む表示域１１５５である。

このＰＩＰ表示３８６５は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、他の合成ビューを提供してもよい。例えば、リモートデバイスからのビデオのための大きい方の背景表示を有する代わりに、大きい方の背景表示１１７０は、ローカルデバイスからのビデオのものであり、小さい方の前景挿入表示はリモートデバイスからのビデオのものでありうる。同様に、一部の実施形態により、ローカルビデオ及びリモートビデオは、ＵＩ３８００内の並んだ２つの表示域（例えば、左右の表示ウィンドウ又は上下の表示ウィンドウ）又は斜めに整列した２つの表示域に表示されうる。一部の実施形態では、ＰＩＰ表示の方式又はデフォルトの表示モードは、ユーザによって指定されてもよい。他の実施形態では、ＰＩＰ表示はまた、大きい方の背景表示と２つの小さい方の前景挿入表示とを含むことができる。

図３８は、サイズ変更動作を、ＵＩ３８００の４つの動作段階として示す。第１段階３８０５では、前景挿入表示３８３５は、背景メイン表示域３８３０よりもかなり小さい。また、この例では、前景挿入表示域３８３５は、ＰＩＰ表示３８６５の右下隅にある。他の例では、前景挿入表示域３８３５は、異なるサイズであってもよいし、ＰＩＰ表示３８６５内の異なるエリアにあってもよい。

第２段階３８１０では、サイズ変更動作が始められる。この例では、ユーザがサイズ変更を希望する挿入表示域３８３５の隅を選択することによって（例えば、指３８４０で挿入表示域３８３５の左上隅を押すことによって）動作が始められる。ＵＩ３８００の第２段階３８１０は、この選択を、挿入表示域３８３５の太い境界線３８４５として示す。この段階で、ユーザは、（例えば、ＰＩＰ表示３８６５上で挿入表示域３８３５から離れるように又は挿入表示域３８３５に向かって自身の指３８４０をドラッグすることによって）挿入表示域３８３５を拡大する又は縮めることができる。

第３段階３８１５は、矢印３８５０によって示されるように、挿入表示域３８３５から離れるように自身の指３８４０を移動することによって（すなわち、この例では、ＵＩ３８００の左上隅に向かって斜めに自身の指を移動することによって）ユーザが挿入表示域３８３５を拡張し始めた後のＵＩ３８００を示す。また、矢印３８５５によって示されるように、指３８４０の移動によって、高さ及び幅の両方に関して比例するように挿入表示域３８３５が拡張される。他の例では、ユーザは、同じ技術を使用して（すなわち、指を挿入表示域３８３５に向かってドラッグすることによって）挿入表示域３８３５を縮めることができる。

第４段階３８２０は、挿入表示域３８３５のサイズ変更が完了した後のＵＩ３８００を表示する。この例では、ユーザは、挿入表示域３８３５が所望のサイズに達したら自身の指３８４０のドラッグを止めてＰＩＰ表示３８６５から自身の指を離すことによって、挿入表示域３８３５のサイズ変更を完了する。この手順の結果、サイズ変更された挿入表示域３８３５は、第１段階３８０５におけるその元のサイズよりも大きい。太い境界線３８４５の除去は、挿入表示域サイズ変更動作がこの時点で完了したことを示す。

一部の実施形態は、ユーザがテレビ会議中にＰＩＰ表示３８６５において挿入表示域３８３５をサイズ変更できるための他の技術を提供する。図３９は、１つのこのような他の技術を示す。この図は、挿入表示域３８３５の端（すなわち、この表示域３８３５の各辺のうちの１つ）を選択し、その後、挿入表示域３８３５を拡張する又は縮めることによって挿入表示域３８３５をサイズ変更するための技術を示す。

図３９は、このサイズ変更動作を、図３８のＵＩ３８００の４つの動作段階として示す。図３９の第１段階３８０５は、図３８の第１段階３８０５と同じである。具体的には、この段階で、デバイス３９２５のＵＩ３８００は、大きな方の背景メイン表示域３８３０と小さな方の前景挿入表示域３８３５とをＰＩＰ表示３８６５の右下隅に有するＰＩＰ表示３８６５を示す。図３８及び図３９は、同じＵＩ３８００で挿入表示域３８３５をサイズ変更するための２つの異なる技術を示しているが、一部の実施形態は、同じＵＩでこれらの技術の両方ともを提供しないことが当業者には理解されよう。

第２段階３９１０は、サイズ変更動作の開始を示す。この例では、ユーザがサイズ変更を希望する挿入表示域３８３５の辺を選択することによって（例えば、挿入表示域３８３５の上端又は側端に指３８４０を置くことによって）、ユーザは動作を始める。この例では、ユーザは、この選択を行うために挿入表示域３８３５の上端に自身の指３８４０を置く。第２段階３９１０は、この選択を、挿入表示域３８３５の太い境界線３８４５として示す。

第３段階３９１５は、矢印３９５０によって示されるように、挿入表示域３８３５から離れるように（すなわち、ＰＩＰ表示３８６５の上部に向かって垂直に）自身の指３８４０を移動することによってユーザが挿入表示域３８３５を拡張し始めた後のＵＩ３８００を示す。また、矢印３９５５によって示されるように、指３８４０の移動によって、高さ及び幅の両方に関して比例するように挿入表示域３８３５が拡張される。他の例では、ユーザは、同じ技術を使用して（例えば、指３８４０を挿入表示域３８３５に向かってドラッグすることによって）挿入表示域３８３５を縮めることができる。

第４段階３９２０は、挿入表示域３８３５のサイズ変更が完了した後のＵＩ３８００を表示する。この例では、ユーザは、挿入表示域３８３５が所望のサイズに達したら自身の指３８４０のドラッグを止めてデバイスの表示画面から自身の指３８４０を離すことによって、挿入表示域３８３５のサイズ変更を完了する。この手順の結果、サイズ変更された挿入表示域３８３５は、第１段階３８０５におけるその元のサイズよりも大きい。太い境界線３８４５の削除は、挿入表示域サイズ変更動作がこの時点で完了したことを示す。

図３８及び図３９によって示されるように、一部の実施形態は、ドラッグ動作に応答して、挿入表示域３８３５のサイズを高さ及び幅に比例して調整する。他の実施形態では、ユーザは、他の属性に影響を及ぼすことなく、挿入表示域３８３５の高さ及び／又は幅を調整できてもよい。図４０は、このようなサイズ変更手法の一例を示す。

具体的には、図４０は、挿入表示域３８３５の端のうちの１つが選択され、水平又は垂直に移動される場合に、図４０のＵＩ３８００によって挿入表示域３８３５が水平方向及び／又は垂直方向に拡張できることを除いて、図３８のＵＩ３８００と同様の携帯デバイス４０２５のＵＩ３８００を示す。ＵＩ３８００の説明を簡略化するため、図４０は、この時点で挿入表示域３８３５がＰＩＰ表示３８６５の右上隅にあることを除いて、図３８のＰＩＰ表示３８６５と同様のＵＩ３８００におけるＰＩＰ表示３８６５を示す。ＰＩＰ表示３８６５は、２つのビデオ表示、すなわち背景メイン表示域３８３０と、前景挿入表示域３８３５とを含む。この例では、背景メイン表示域３８３０は、リモートデバイスの前面カメラ又は背面カメラによって取り込まれているビデオを提示する。前景挿入表示域３８３５は、ローカルデバイスの前面カメラ又は背面カメラによって取り込まれているビデオを提示する。

図３８と同様に、図４０は、サイズ変更動作をＵＩ３８００の４つの動作段階として示す。第１段階４００５は、この時点で挿入表示域３８３５が右上隅にあることを除いて、図３８の第１段階３８０５と同様である。他の３つの段階４０１０、４０１５及び４０２０は、挿入表示域３８３５の下端の選択及び移動によって、挿入表示域３８３５の幅に影響を及ぼすことなく、挿入表示域３８３５が垂直方向にのみ拡張したことを除いて、３つの段階３９１０、３９１５及び３９２０と同様である。

図３８、３９及び４０は、ユーザが挿入表示域３８３５の隅又は辺を選択することによってＰＩＰ表示３８６５の挿入表示域３８３５をサイズ変更できる例示的な実施形態を提供する。一部の実施形態は、挿入ウィンドウ３８３５をサイズ変更するための他の技術を提供する。例えば、図４１は、一部の実施形態により挿入表示域３８３５の内部を選択することによって挿入表示域３８３５をサイズ変更できることを示す。この手法では、ユーザは、画面に２本の指４１５５及び４１５６を置き、互いに遠ざけるか又は近づけるかのどちらかに指をドラッグすることによって、挿入表示域３８３５のサイズを調整する。

図４１では、携帯デバイス４１４０のＵＩ３８００は、別の携帯デバイスのリモートユーザとのテレビ会議中にＰＩＰ表示３８６５を提供する。ＵＩ３８００の説明を簡略化するため、図４１は、図３８のＰＩＰ表示３８６５と同様のこのＵＩ３８００におけるＰＩＰ表示３８６５を示す。

図４１は、サイズ変更動作を、ＵＩ３８００の７つの動作段階として示す。前半の４つの段階３８０５、４１１０、４１１５及び４１２０は挿入表示域３８３５の拡張を示すが、後半の３つの段階は、挿入表示域３８３５の縮みを示す。図４１の第１段階３８０５は、図３８の第１段階３８０５と同じである。具体的には、この段階で、ＵＩ３８００は、大きな方の背景メイン表示域３８３０と小さな方の前景挿入表示域３８３５とを有するＰＩＰ表示３８６５を示す。この例では、背景メイン表示域３８３０は、リモートデバイスの前面カメラ又は背面カメラによって取り込まれているビデオを提示する。前景挿入表示域３８３５は、ローカルデバイスの前面カメラ又は背面カメラによって取り込まれているビデオを提示する。

第２段階４１１０は、サイズ変更動作が始められた後のＵＩ３８００を示す。この例では、ユーザがサイズ変更を希望する挿入表示域３８３５を選択することによって（例えば、挿入表示域３８３５内に２本の指４１５５及び４１５６を置くことによって）、ユーザは動作を始める。ＵＩ３８００の第２段階４１１０は、この選択を、挿入表示域３８３５の太い境界線４１９０として示す。

第３段階４１１５は、矢印４１６０によって示されるように、指４１５５及び４１５６を互いから離れるように移動する（すなわち、指４１５５をＰＩＰ表示３８６５の左上隅に向かって移動し、指４１５６をＰＩＰ表示３８６５の右下隅に向かって移動する）ことによってユーザが挿入表示域３８３５を拡張し始めた後のＵＩ３８００を示す。矢印４１６５によって示されるように、指４１５５及び４１５６の移動によって、高さ及び幅の両方に関して比例するように挿入表示域３８３５が拡張される。

第４段階４１２０には、挿入表示域３８３５のサイズ変更が完了した後のＵＩ３８００が表示されている。この例では、ユーザは、指４１５５及び４１５６のドラッグを止めてデバイスの表示画面から自身の指４１５５及び４１５６を離すことによって、挿入表示域３８３５のサイズ変更を完了する。この手順の結果、サイズ変更された挿入表示域３８３５は、第１段階３８０５におけるその元のサイズよりも大きい。太い境界線４１９０の削除は、挿入表示域サイズ変更動作がこの段階で完了したことを示す。

第５段階４１２５では、ユーザは、２つの指４１５５及び４１５６を挿入表示域３８３５に置くことによって、挿入表示域３８３５を再選択する。第６段階４１３０は、矢印４１７０によって示されるように、指４１５５及び４１５６を互いに近づけることによってユーザが挿入表示域３８３５を縮め始めた後のＵＩ３８００を示す。矢印４１７５によって示されるように、指４１５５及び４１５６の移動によって、高さ及び幅の両方に関して比例するように挿入表示域３８３５が縮小される。

第７段階４１３５は、動作の結果、挿入表示域３８３５のサイズが縮小したことを除いて、図４１の第４段階４１２０と同様である。太い境界線４１９０の除去は、挿入表示域サイズ変更動作がこの段階で完了したことを示す。

図３８〜図４１の上記の説明は、ユーザがＰＩＰ表示の挿入表示域をサイズ変更できるいくつかの例示的なユーザインタフェースを示す。一部の実施形態では、挿入表示域のサイズ変更によって、テレビ会議マネージャ１６０４が、ユーザの入力に応答してＰＩＰ表示における挿入表示域の拡大縮小及び合成を変更するように、デュアルカメラ携帯デバイスの画像処理動作への変更が起こる。さらに、一部の実施形態では、図３８〜図４１の表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。

４．関心領域の識別
一部の実施形態により、ユーザは、画像処理（例えば、図１６の画像処理マネージャ１６０８）、符号化（例えば、図１６のエンコーダ１６５５）、テレビ会議中の携帯デバイス及びそのカメラの挙動、又はそれらの組み合わせを変更するために、テレビ会議中に表示されるビデオにおける関心領域（ＲＯＩ）を識別できる。異なる実施形態は、ビデオにおいてこのような関心領域を識別するための異なる技術を提供する。図４２は、ビデオの画像品質を向上するためにビデオにおいて関心領域を識別するための一部の実施形態のユーザインタフェースを示す。

図４２では、携帯デバイス４２２５のＵＩ４２００は、別の携帯デバイスのリモートユーザとのテレビ会議中にＰＩＰ表示４２６５を提示する。図４２のＰＩＰ表示は、図４１のものと実質的に同様である。具体的には、図４２のＰＩＰ表示４２は、２つのビデオ表示、すなわち背景メイン表示４２３０と、前景挿入表示４２３５とを含む。この例では、背景メイン表示域４２３０は、木と帽子を被った人とのビデオを提示し、これは、リモートデバイスの前面カメラによってビデオが取り込まれている木及び人又はリモートデバイスの背面カメラによってビデオが取り込まれている木及び人であると想定される。前景挿入表示４２３５は、男性のビデオを提示し、これは、この例では、ローカルデバイスの前面カメラによってビデオが取り込まれている男性又はローカルデバイスの背面カメラによってビデオが取り込まれている男性であると想定される。ＰＩＰ表示の下は、選択することによってユーザがテレビ会議を終了できる「会議終了」と標示された選択可能ＵＩ項目４２６０（例えばボタン４２６０）を含む表示域１１５５である。

このＰＩＰ表示は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、他の合成ビューを提供してもよい。例えば、リモートデバイスからのビデオのための大きい方の背景表示を有する代わりに、大きい方の背景表示はローカルデバイスからのビデオのものであってもよく、小さい方の前景挿入表示は、リモートデバイスからのビデオのものであってもよい。同様に、一部の実施形態により、ローカルビデオ及びリモートビデオは、ＵＩ内の並んだ２つの表示域（例えば、左右の表示ウィンドウ又は上下の表示ウィンドウ）又は斜めに整列した２つの表示域に表示されうる。他の実施形態では、ＰＩＰ表示はまた、大きい方の背景表示と２つの小さい方の前景挿入表示とを含んでもよい。一部の実施形態では、ＰＩＰ表示の方式又はデフォルトの表示モードは、ユーザによって指定されてもよい。

図４２は、ＲＯＩ識別動作を、ＵＩ４２００の４つの動作段階として示す。第１段階４２０５に示すように、背景表示４２３０に提示されるビデオは、非常に低い品質を有する（すなわち、ビデオ画像がぼやけている）。この例では、携帯デバイス４２２５のユーザは、人の顔４２７０が表示される背景表示４２３０のエリアを関心領域として識別することを望んでいる。

第２段階４２１０では、関心領域を識別する動作が始められる。この例では、ユーザが関心領域として識別することを希望する背景表示４２３０に提示されたビデオ内のあるエリアを選択することによって（例えば、背景表示４２３０内に表示された人の顔４２７０のまわりの位置でデバイスの画面を指４２５０でタップすることによって）、動作が始められる。

第３段階４２１５に示すように、ユーザのエリアの選択によって、ＵＩ４２００は、ユーザの選択のエリアを取り囲む囲い（enclosure）４２７５（例えば、破線の方形４２７５）が描かれる。第４段階４２２０は、関心領域の識別が完了した後のＵＩ４２００を表示する。このプロセスの結果、関心領域内のビデオの品質は、第１段階４２０５における品質から実質的に向上する。囲い４２７５の除去は、ＲＯＩ選択動作がこの時点で完了したことを示す。一部の実施形態では、ＲＯＩ識別プロセスはまた、ローカルデバイス４２２５に対して引き起こすように、リモートデバイスに表示される同じビデオの同じ変更を引き起こす。この例では、例えば、リモートデバイスに表示された同じビデオの関心領域内の画質も実質的に向上する。

一部の実施形態では、ユーザは、第３段階４２１５で（例えば、指４２５０で表示を押し、囲い４２７５を引き伸ばすために画面の右上隅に向かって指４２５０を移動するか又は囲い４２７５を縮めるために画面の左下隅に向かって指４２５０を移動することによって）囲い４２７５を引き伸ばす又は縮めてもよい。また、一部の実施形態により、ユーザは、第３段階４２１５で（例えば、指４２５０で表示を押し、表示上で水平又は垂直に指４２５０を移動することによって）囲い４２７５を配置し直すことができる。一部の他の実施形態では、エリアの選択によって、ＵＩ４２００が第３段階４２１５で囲い４２７５をまったく描かなくてもよい。

他の実施形態は、ユーザがビデオ内で関心領域を識別できるようにするための異なる技術を提供する。図４３は、１つのこのような他の技術を示す。図４３では、ユーザは、領域の境界となる形状を描くことによって、関心領域を識別する。この例では、形状は長方形であるが、他の形状（例えば、他の任意の多角形、円、楕円など）にできる。一部の実施形態は、図４２に示される技術も提供するデバイスＵＩにおいて、図４３のこの代替技術を提供する。しかし、他の実施形態は、同じＵＩにおいてこれらの技術の両方ともは提供しない。

図４３は、このＲＯＩ識別動作を、ＵＩ４２００の５つの動作段階として示す。図４３の第１段階４２０５は、図４２の第１段階４２０５と同一である。具体的には、この第１段階４２０５では、ＵＩ４２００は、大きな方の背景メイン表示域４２３０と小さな方の前景挿入表示域４２３５とをＰＩＰ表示４２６５の右下隅に有するＰＩＰ表示４２６５を示す。

第２段階４３１０では、関心領域を識別する動作が始められる。この例では、背景表示域４２３０に提示されたビデオにおいて関心領域を規定するための第１位置をある期間選択することによって（例えば、デバイスの画面において背景表示４２３０に表示される人の顔４２７０のまわりの位置を指４３５０である期間押すことによって）、動作が始められる。第３段階４３１５では、ＵＩ４２００は、第１位置４３７０が選択されたことを、背景表示域４２３０上での選択された第１位置の隣の点４３５５として示す。

第４段階４３２０は、ユーザが関心領域を規定するための第２位置４３７５を選択した後のＵＩ４２００を示す。この例では、矢印４３６０によって示されるように、ユーザは、点４３５５が表示された後で第１位置からデバイスの画面をわたって指４３５０をドラッグし、背景表示域４２３０内の表示されている帽子と表示されている木との間の位置で止めることによって、この第２位置４３７５を選択する。第４段階に示すように、このドラッグによって、ＵＩ４２００は、その対向する頂点に第１位置４３７０及び第２位置４３７５を有する関心領域エリアのための方形の境界線４３６５が描かれた。

第５段階４３２５は、関心領域の識別が完了した後のＵＩ４２００を示す。この例では、ユーザは、所望の関心領域エリアが識別されたら指４３５０のドラッグを止めてデバイスの表示画面から指４３５０を離すことによって、関心領域の識別を完了する。第５段階４３２５は、描画プロセスの結果、関心領域内のビデオの品質が第１段階４２０５における品質から実質的に向上したことを示す。一部の実施形態では、描画プロセスはまた、ローカルデバイス４２２５に対して引き起こされたものと同じ変更をリモートデバイス上の表示に引き起こす。この例では、例えば、リモートデバイスに表示された同じビデオの関心領域内の画質が実質的に向上する。

上記の図４２及び図４３の説明は、識別された領域の画質を向上させるためにビデオ内の関心領域を識別する異なる方式を示す。一部の実施形態では、識別された関心領域の画質を向上させることによって、ビデオを符号化する際に、識別された領域により多くのビットを割り当てるなどの、デュアルカメラ携帯デバイスの符号化動作への変更が生じる。

一部の実施形態により、ユーザは、携帯デバイス又はそのカメラへのさまざまな変更を行うためにビデオにおいて関心領域を識別できる。例えば、図４４は、表示上で関心領域エリアを拡張する又は縮めるためにビデオにおいて関心領域を識別する一例を示す。この手法では、ユーザは、表示上でエリアを関心領域の中心として選択し、その後、関心領域エリアを拡張する又は縮めることによって、ビデオにおける関心領域を識別する。

図４４では、携帯デバイス４４２５のＵＩ４４００は、別の携帯デバイスのリモートユーザとのテレビ会議中にＰＩＰ表示４２６５を提示する。図４４のＰＩＰ表示４２６５は、図４２のＰＩＰ表示４２６５と実質的に類似しているが、図４４の前景挿入表示４２３５は、ＰＩＰ表示４２６５の左下隅にある。

図４４は、ＲＯＩ選択動作を、ＵＩ４４００の４つの動作段階として示す。第１段階４４０５に示すように、背景表示４４３０は、表示４４３０の左に男性を有し、右に木４４４０を有するビデオを提示する。さらに、木４４４０は比較的小さく、背景表示域４４３０の右側のみを占有する。この例では、携帯デバイス４４２５のユーザは、表示４４３０において木４４４０が表示されるエリアを関心領域として識別することを望んでいる。

第２段階４４１０では、関心領域を識別する動作が始められる。この例では、ユーザが関心領域として識別することを希望する背景表示４４３０に提示されたビデオ内のあるエリア４４４０を選択することによって（例えば、木４４４０が表示される背景表示域４４３０を２本の指４４４５及び４４４６で押すことによって）、動作が始められる。この段階４４１０では、ユーザは、指４４４５及び４４４６を互いからさらに遠ざかるようにドラッグすることによって、関心領域エリア４４４０を拡張させ、背景表示域４４３０のより大きな部分を取得させることができる。ユーザは、自身の指４４４５及び４４４６を互いに近づけるようにドラッグすることによって、関心領域４４４０を縮めさせ、背景表示域４４３０のより小さな部分を取得させることもできる。

第３段階４４１５は、矢印４４５０によって示されるように、自身の指４４４５及び４４４６を互いから離れるように移動する（すなわち、指４４４５を背景表示域４４３０の左上隅に向かって移動し、指４４４６を表示４４３０の右下隅に向かって移動する）ことによって、ユーザが関心領域４４４０を拡張させ、背景表示域４４３０のより大きな部分を占めさせ始めた後のＵＩ４４００を示す。一部の実施形態では、指の移動はまた、ローカルデバイスに対して引き起こしたのと同じ変更を、リモートデバイスの表示に引き起こす。この例では、例えば、同じビデオの関心領域は、拡張し、リモートデバイスの背景表示域４４３０のより大きな部分を占める。一部の実施形態では、以下でさらに説明するように、ローカル表示及び／又はリモート表示における関心領域の拡張によって、携帯デバイス又はそのカメラの一方又は両方が、他の動作のうちの１つ以上を変更する。

第４段階４４２０は、関心領域の識別が完了した後のＵＩ４４００を表示する。この例では、ユーザは、関心領域が背景表示域４４３０において所望の比率に達したら自身の指４４４５及び４４４６のドラッグを止めてデバイスの表示画面から指４４４５及び４４４６を離すことによって、関心領域の識別を完了する。このプロセスの結果、関心領域は、背景表示４４３０の大半を占める。関心領域動作の識別は、この時点で完了している。

上記の例のうちの一部は、（例えば、ビデオの関心領域部分を符号化するためにビットレートを増加させることによって）ビデオの選択された関心領域内の画像品質を向上するためにユーザがビデオ内の関心領域をどのように識別できるかを示す。一部の実施形態では、ビデオ内の関心領域を識別することによって、露出、拡大縮小、フォーカスなどの、携帯デバイスの画像処理動作への変更が生じる。例えば、ビデオ内の関心領域を識別することによって（例えば、ズームすべき関心領域を識別することによって）、テレビ会議マネージャ１６０４に、ビデオの画像を異なるように拡大縮小及び合成させうる。

他の実施形態では、ビデオ内の関心領域を識別することによって、携帯デバイスのカメラ（群）の動作（例えば、フレームレート、ズーム、露出、拡大縮小、フォーカスなど）への変更が生じる。さらに他の実施形態では、ビデオ内の関心領域を識別することによって、識別された領域へのより多くのビットの割り当て、拡大縮小などのような、携帯デバイスの符号化動作への変更が生じる。さらに、上述の例示的なＲＯＩ特定動作は、携帯デバイス又はそのカメラへの上述の変更のうちの１つのみを引き起こしてもよいが、一部の他の実施形態では、ＲＯＩ識別動作は、携帯デバイス又はそのカメラの動作への変更のうちの複数を引き起こしてもよい。さらに、一部の実施形態では、図４２〜図４４の表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。

Ｂ．カメラの切り換え
一部の実施形態は、テレビ会議中にカメラを切り換える（すなわち、画像が取り込まれるカメラを変更する）手順を提供する。異なる実施形態は、カメラ切り換え動作を実行するための異なる手順を提供する。一部の実施形態は、デバイスのカメラを切り換える（すなわち、ローカル切り換え）ためにデュアルカメラ携帯デバイスによって実行される手順を提供するが、他の実施形態は、デュアルカメラ携帯デバイスがテレビ会議中の別のデュアルカメラ携帯デバイスに当該他のデバイスのカメラを切り換える（すなわち、リモート切り換え）ように命令するための手順を提供する。さらに他の実施形態は、この両方のための手順を提供する。セクションＩＶ．Ｂ．１では、デュアルカメラ携帯デバイス上でローカルカメラ切り換え動作を実行するためのプロセスについて説明する。セクションＩＶ．Ｂ．２では、デュアルカメラ携帯デバイス上でリモートカメラ切り換え動作を実行するためのプロセスについて説明する。

１．ローカルカメラ切り換え
図４５は、少なくとも１つのカメラを含むリモート携帯デバイスとのテレビ会議中にデバイスの２つのカメラを切り換えるためにローカルデュアルカメラ携帯デバイス上で一部の実施形態が実行するプロセス４５００を示す。一部の実施形態では、プロセス４５００は、図１６に示されるテレビ会議マネージャ１６０４によって実行される。説明のために、この説明では、ローカルデュアルカメラ携帯デバイスの一方のカメラをカメラ１と呼び、ローカルデュアルカメラ携帯デバイスの他方のカメラをカメラ２と呼ぶ。

プロセス４５００は、ローカルデュアルカメラ携帯デバイスとリモート携帯デバイスとの間のテレビ会議を（４５０５において）開始することによって始まる。次に、プロセス４５００は、リモート携帯デバイスに表示するために、ローカルデュアルカメラ携帯デバイスの現在選択されているカメラ（例えば、カメラ１）からリモート携帯デバイスにビデオ画像を（４５１０において）送信する。４５１０では、プロセスは、このビデオ画像及びリモート携帯デバイスから受信したビデオ画像に基づいて、合成表示も生成して表示する。

プロセス４５００は、その後、テレビ会議終了要求が受信されているかどうかを（４５１５において）判定する。上述のように、一部の実施形態では、テレビ会議は、（例えば、ローカルデュアルカメラ携帯デバイスのユーザインタフェースを通じた）ローカルデュアルカメラ携帯デバイスのユーザの要求又は（例えば、リモート携帯デバイスのユーザインタフェースを通じた）リモート携帯デバイスのユーザの要求で終了できる。プロセス４５００がテレビ会議終了要求を受信した場合に、プロセス４５００は終了する。

プロセス４５００がテレビ会議終了要求を受信しない場合に、プロセス４５００は、その後、ローカルデュアルカメラ携帯デバイスのユーザがテレビ会議用のカメラを切り換えるようにデバイスに指示したかどうかを（４５２０において）判定する。デバイスがカメラを切り換えるように指示されていないと（４５２０において）プロセス４５００が判定した場合に、プロセス４５００は動作４５１０に戻る。しかし、デバイスがカメラを切り換えるように指示されたと（４５２０において）プロセス４５００が判定した場合に、プロセス４５００は４５２５に移行する。

プロセス４５００は、４５２５で、ローカルデュアルカメラ携帯デバイスがカメラを切り換えていることを示す通知をリモート携帯デバイスに送信する。一部の実施形態では、プロセス４５００は、上述のようなＶＴＰマネージャ３１２５によってオーディオチャネル及びビデオチャネルで多重化されたテレビ会議制御チャネルを通じて通知を送信する。

その通知を送信した後、プロセス４５００は、カメラ切り換え動作を（４５３０において）実行する。一部の実施形態では、カメラ切り換え動作を（４５３０において）実行することは、カメラ１によるビデオ画像の取り込みを止めてカメラ２によるビデオ画像の取り込みを開始するようにＣＩＰＵに命令することを含む。これらの命令は、カメラ２に関連する画素アレイから画像の取り込みに切り換えて、これらの画像の処理を開始するようにＣＩＰＵに単に指示できる。あるいは、一部の実施形態では、ＣＩＰＵに対する命令は、（１）設定の特定の集合に基づいてカメラ２を動作するように、（２）特定のフレームレートでカメラ２によって生成されたビデオを取り込むように、及び／又は（３）設定の特定の集合（例えば、解像度など）に基づいてカメラ２からのビデオ画像を処理するようにＣＩＰＵに指示する初期化パラメータ集合を伴う。

一部の実施形態では、（４５３０における）カメラ切り換え命令は、使用されていないカメラを上述の第４動作電力モードに切り換えるための命令も含む。この例では、カメラ切り換え命令は、カメラ２がその第４動作電力モードに切り換わるための命令を含む。さらに、カメラ切り換え命令は、画像を取り込むように要求された場合に第４動作電力モードにすばやく切り換わり、取り込みを開始できるように、カメラ１がその第４動作電力モードから電力を節約する第１動作電力モードなどの別の動作電力モード又は第３動作電力モードに切り換わるための命令も含む。カメラ切り換え動作４５３０は、（カメラ１によって取り込まれた画像ではなく）ローカルデュアルカメラ携帯デバイスのカメラ２によって取り込まれた画像をローカルデュアルカメラ携帯デバイスに表示するためにリモート携帯デバイスから受信した画像と合成することも含む。

４５３０においてカメラ切り換えを指示した後、プロセス４５００は、カメラ１からの画像の表示とカメラ２からの画像の表示との間の移行を表示するためにローカルデュアルカメラ携帯デバイス上でカメラ切り換えアニメーションを（４５３５において）実行する。ローカルデュアルカメラ携帯デバイス上でのカメラ切り換えアニメーションに続いて、テレビ会議終了要求又は新たなカメラ切り換え要求が受信されるまで、プロセス４５００は、動作４５１０〜４５２０を一巡して戻る。

図４６は、一部の実施形態によりデュアルカメラデバイスのＵＩ１１０５を介してカメラ切り換え動作をどのようにして要求できるか、及びこれらの実施形態がカメラ切り換え動作をアニメーション化するかの一例を示す。この図は、カメラ切り換え動作を、デバイスのＵＩ１１０５の８つの異なる動作段階４６１０、４６１５、４６２０、４６２５、４６３０、４６３５、４６４０及び４６４５として示す。ＵＩ１１０５の前半の４つの段階４６１０、４６１５、４６２０及び４６２５は、カメラを切り換えるというユーザの要求を受信する一例を示す。本発明の一部の実施形態では、デバイスのユーザは、このような要求を行うための他の機構を有する。

第１段階４６１０は、図１１のＵＩ１１０５の第５段階１１３０と同じであり、テレビ会議がセットアップされた後のＵＩ１１０５を示す。この段階で、ＵＩ１１０５は、２つのビデオ表示、すなわちリモートカメラからの大きい方の背景表示と、ローカルカメラからの小さい方の前景挿入表示とを含むＰＩＰ表示を表示する。この例では、背景メイン表示域１１７０は、この例ではリモートデバイスによってビデオが取り込まれている婦人と想定される婦人のビデオを提示し、前景挿入表示域１１６０は、この例ではローカルデバイスの前面カメラによってビデオが取り込まれている男性と想定される男性のビデオを提示する。

その後、第２段階４６１５は、ＵＩ１１０５のＰＩＰ表示域１１８０の選択を通じたカメラ切り換え動作の始まりを示す。図示のように、ＰＩＰ表示１１８０にユーザの指４６７０を置くことによって選択が行われる。第３段階４６２０は、テレビ会議中のローカルデバイス４６００のカメラ間の切り換えを要求するための選択可能ＵＩ項目４６７５（例えば、カメラ切り換えボタン４６７５）を含むＵＩ１１０５を示す。第４段階４６２５は、ローカルデバイス４６００のユーザが選択可能ＵＩ項目４６７５を（例えば、シングルフィンガータップによって）選択し、この選択が選択可能ＵＩ項目４６７５の強調表示を通じて示された後のＵＩ１１０５を示す。この選択可能ＵＩ項目４６７５を選択することによって、ユーザは、テレビ会議中にデバイス４６００の前面カメラからデバイス４６００の背面カメラに切り換えるようにデバイス４６００に指示している。デバイス４６００の背面カメラがビデオを取り込んでいる他の例では、選択可能ＵＩ項目４６７５のユーザの選択は、デバイス４６００の背面カメラからデバイス４６００の前面カメラに切り換えるようにデバイス４６００に指示する。第４段階の後で、テレビ会議マネージャは、カメラ切り換え動作を開始するようにＣＩＰＵ及びリモートデバイスに命令を送信する。

ＵＩ１１０５の後半の４つの段階４６３０、４６３５、４６４０及び４６４５は、ローカルデバイス上でのカメラ切り換えアニメーションの一例を示す。このアニメーションは、ローカルデバイスの前面カメラ及び背面カメラから取り込まれたビデオがビューペイン（viewing pane）の２つの対向する側に現在表示されており、この２つの側のうちの１つのみが任意の時点でユーザによって視認可能である印象（impression）を提供することを目的とする。カメラ切り換えがテレビ会議の途中で要求された場合に、このビューペインは、垂直軸のまわりを回転したと見えるようになされ、その結果、以前は１つのカメラのビデオをユーザに示していたビューペインの一方の側での１つのカメラのビデオの提示は、これがビューペインの他方の側によって置き換えられるまで、ユーザから遠ざかって回転し、ビューペインの他方の側が他方のカメラのビデオを示す。知覚されるビューペインの回転のこのアニメーション及び外見は、（１）一方のカメラ表示域におけるそのカメラからのビデオ画像が段階的に小さくなって、それに対してパースペクティブ補正動作を適用し、続いて（２）表示域における他方のカメラからのビデオ画像を段階的に拡張し、それに対するパースペクティブ補正動作を減少させることによって達成される。

したがって、第５段階４６３０は、垂直軸４６８２のまわりでの「ビューペインの回転」の開始を示す。ビューペインの回転の外見を付与するため、ＵＩ１１０５は、ビデオ表示域１１６０における前面カメラのビデオ画像のサイズを減少させ、パースペクティブ動作を適用して、ビデオ画像の左側に比べてビデオ画像の右側がユーザから遠く見えるようにした。

第６段階４６３５は、表示域１１６０の中央に表示される細い線４６８６によって示されるように、ユーザがこのペインの端のみを見ることが可能なようにビューペインが９０度回転したことを示す。第７段階４６４０は、ユーザの背面カメラから取り込まれたビデオを示すために今度はビューペイン４６８８の裏面がユーザに段階的に見えるように、ビューペインが回転し続けていることを示す。この場合もやはり、一部の実施形態では、回転アニメーションのこの表示は、ビデオ表示域４６８８における背面カメラのビデオ画像のサイズを減少させ、パースペクティブ動作を適用して、ビデオ画像の右側に比べてビデオ画像の左側がユーザから遠く見えるようにすることによって達成される。

第８段階４６４５は、カメラ切り換え動作を示すアニメーションの完了を示す。具体的には、この段階は、デバイス４６００の背面カメラによって取り込まれている自動車のビデオ画像を表示域１１６０に表示する。

図４６に関する上述の例は、カメラ切り換えユーザインタフェースを通じてカメラ切り換え動作を起動する。他の実施形態は、カメラ切り換え動作を異なるように起動する。例えば、一部の実施形態は、図４７のＵＩ１１０５などのテレビ会議中にＵＩに永久的に表示されるカメラ切り換え選択可能ＵＩ項目を有することによって、カメラ切り換え動作を起動する。図４７では、カメラ切り換えボタン１２８９は、消音ボタン１２８５及び会議終了ボタン１２８７と共に表示域１１５５に示されている。一部の実施形態では、表示域１１５５のレイアウトは、図１２に関して上述した表示域１１５５のレイアウトと同じである。

図４７は、ＵＩ１１０５のカメラ切り換え動作を、６つの段階すなわち４６１０、４７９０、４６３０、４６３５、４６４０及び４６４５として示す。図４７の第１段階４６１０は、表示域１１５５のレイアウトが、単一の会議終了ボタンではなく、消音ボタン１２８５、会議終了ボタン１２８７及びカメラ切り換えボタン１２８９を示すことを除いて、図４６の第１段階４６１０と同様である。第２段階４７９０は、ローカルデバイス４６００のユーザがカメラ切り換え選択可能ＵＩ項目１２８９を（例えば、指４６７０を使用したシングルフィンガータップを通じて）選択した後のＵＩ１１０５を示す。この例では、この選択可能ＵＩ項目１２８９を選択することによって、ユーザは、テレビ会議中にデバイス４６００の前面カメラからデバイス４６００の背面カメラに切り換えるようにデバイス４６００に指示する。図４７の後半の４つの段階は、表示域１１５５のレイアウトが第１段階４６１０における上述のレイアウトと同じであることを除いて、図４６の後半の４つの段階と同様であり、したがって、不必要な詳細で本発明の説明をあいまいにしないために、さらなる説明はしない。

一部の実施形態では、リモート携帯デバイスがローカルデュアルカメラ携帯デバイスの異なるカメラから画像を受信した（すなわち、ローカルデュアルカメラ携帯デバイスがカメラを切り換えた）場合に、リモート携帯デバイスは、ローカルデュアルカメラ携帯デバイスの一方のカメラからの画像の表示とローカルデュアルカメラ携帯デバイスの他方のカメラからの画像の表示との間の移行を表示するために、カメラ切り換えアニメーションも実行する。図４８は、このようなカメラ切り換えアニメーションのうちの１つの例を、ＵＩ４８０５の５つの動作段階４８１０、４８１５、４８２０、４８２５及び４８３０として示す。この図は、リモート携帯デバイス４８００上での例示的なカメラ切り換えアニメーションを示す。動作段階は、表示域４８３５に表示された画像上でアニメーションが実行されることを除いて、図４６の例示的なアニメーションと同じであり、表示域４８３５は、ローカルデュアルカメラ携帯デバイスからの画像がリモート携帯デバイス４８００に表示される位置である。したがって、表示域４８３５に表示された男性の画像は、表示域４８３５における男性の画像の表示と自動車４８７０の画像の表示との間の移行を示すように表示域４８５０の中央にある垂直軸４８５５に対して１８０度回転するように見えるようにアニメーション化される。一部の実施形態のカメラ切り換えアニメーションの実装は、上述のアニメーションの実装と同じである。

上記の例は、特定のユーザインタフェースレイアウトを有するリモートデバイス上でのカメラ切り換えアニメーションを示す。他の実施形態は、異なるユーザインタフェースレイアウトを有するリモートデバイス上でのこのカメラ切り換えアニメーションを実行してもよいだろう。例えば、図４９は、異なるユーザインタフェースレイアウト４８０５を有するリモートデバイス４８００のこのような一例を示す。特に、図４９のＵＩ４８０５は、表示域１１５５に含まれる、消音ボタン１２８５と、会議終了ボタン１２８７と、カメラ切り換えボタン１２８９とを有し、表示域１１５５は、テレビ会議中に合成表示４８５０の１辺に永久的に表示される。３つのボタンのレイアウトについては、図４８に関して上述した。異なるユーザインタフェースレイアウト以外に、図４９の５つの段階４８１０、４８１５、４８２０、４８２５及び４８３０は、図４８の５つの段階４８１０、４８１５、４８２０、４８２５及び４８３０と同一である。

２．リモートカメラ切り換え
図５０は、テレビ会議中にリモートデュアルカメラデバイスの２つのカメラを切り換えるためのプロセス５０００を示す。このプロセス５０００は、少なくとも１つのカメラを含むデバイスのテレビ会議マネージャによって実行される。以下の説明では、ユーザがリモートカメラ切り換えを指示するデバイスはローカルデバイスと呼ばれ、自身の２つのカメラを切り換えるデバイスはリモートデバイスと呼ばれる。同様に、以下の説明では、リモートデバイスは、その前面カメラ（すなわちカメラ１）とその背面カメラ（すなわちカメラ２）を切り換えると言われる。

図５０のプロセス５０００について、図５１、図５２、図５３及び図５４に関して説明する。図５１は、リモートデバイスがテレビ会議中にその２つのカメラを切り換えることをユーザが要求するために用いるローカルデバイス５１００のＵＩ５１０５を示す。この図は、このＵＩ５１０５の８つの異なる動作段階５１１０、５１１５、５１２０、５１２５、５１３０、５１３５、５１４０及び５１４５を示す。図５４は、ローカルデバイス５１００からカメラ切り換え要求を受信するリモートデバイス５４００のＵＩ５４０５を示す。図５４は、ＵＩ５４０５の６つの異なる動作段階５４１０、５４１５、５４２０、５４２５、５４３０及び５４３５を示す。

図５０に示すように、プロセス５０００は、ローカルデバイスとリモートデバイスとの間のテレビ会議を（５００５において）開始することによって始まる。その後、プロセス５０００は、各デバイスの１つのカメラから（例えば、各デバイスの前面カメラから）画像を（５０１０において）受信し、これらの画像に基づいてテレビ会議のための合成ビューを生成する。５０１０で、プロセス５０００は、ローカルデバイスからリモートデバイスにビデオ画像も送信する。

その後、プロセス５０００は、テレビ会議終了要求が受信されたかどうかを（５０１５において）判定する。上述のように、テレビ会議は、一部の実施形態では、ローカルデバイス又はリモートデバイスのユーザの要求により終了できる。プロセス５０００がテレビ会議終了要求を受信した場合に、プロセス５０００は終了する。

プロセス５０００がテレビ会議終了要求を受信しない場合に、その後、プロセス５０００を実行中であるデバイスのユーザ（すなわち、ローカルデバイスのユーザ）が、テレビ会議のためにリモートデバイスがそのカメラを切り換えることを要求するようにデバイスに指示したかどうかを（５０２０において）プロセス５０００が判定する。モートカメラ切り換えを開始するように指示されていないと（５０２０において）プロセス５０００が判定した場合に、プロセス５０００は動作５０１０に戻る。デバイスはリモートカメラ切り換えを開始するように指示されたと（５０２０において）プロセス５０００が判定した場合に、プロセス５０００は、以下でさらに説明する５０２５に移行する。

図５１のＵＩ５１０５の最初の４つの段階５１１０、５１１５、５１２０及び５１２５は、リモートデバイスのカメラを切り換えるためのユーザの要求を受信する一例を示す。第１段階５１１０及び第２段階５１１５は、図４６の第１段階４６１０及び第２段階４６１５と同じである。第３段階５１２０は、第３段階５１２０が、ローカルデバイス５１００にカメラを切り換えることを要求するための選択可能ＵＩ項目５１７５に加えて、カメラを切り換えることのリモートデバイス５１００への要求のための選択可能ＵＩ項目５１８０を含むことを除いて、第３段階４６２０と同じである。第４段階５１２５は、リモートデバイスにカメラを切り換えるように要求するためのＵＩ項目５１８０を（例えば、選択可能ＵＩ項目５１８０へのシングルフィンガータップ５１７０を通じて）ローカルデバイス５１００のユーザが選択することを示す。選択可能ＵＩ項目５１８０の強調表示によって選択が示される。図５１はこの動作を実行する一例を示すが、他の実施形態は、リモートデバイスにカメラを切り換えるように要求するための動作を異なるように実行してもよい。

図５１に関する上述の例は、リモートカメラ切り換えユーザインタフェースを通じてリモートカメラ切り換え動作を起動する。他の実施形態は、リモートカメラ切り換え動作を異なるように起動する。例えば、一部の実施形態は、図５２のＵＩ５１０５などのテレビ会議中にＵＩにカメラ切り換えの選択可能ＵＩ項目を永久的に表示させることによって、カメラ切り換え動作を起動する。図５２では、リモートカメラ切り換えボタン５２８８が、消音ボタン５２８２、会議終了ボタン５２８４及びローカルカメラ切り換えボタン５２８６と共に表示域１１５５に示されている。

図５２は、デバイス５１００のＵＩ５１０５のリモートカメラ切り換え動作を、６つの異なる段階５１１０、５２９０、５１３０、５１３５、５１４０及び５１４５として示す。図５２の第１段階５１１０は、表示域１１５５のレイアウトが消音ボタン５２８２、ローカルカメラ切り換えボタン５２８６、リモートカメラ切り換えボタン５２８８及び会議終了ボタン５２８４を示すことを除いて、図５１の第１段階５１１０と同様である。第２段階５２９０は、ローカルデバイス５１００のユーザが選択可能リモートカメラ切り換えＵＩ項目５２８８を（例えば、シングルフィンガータップ５１７０を通じて）選択した後のＵＩ１１０５を示す。図５２の後半の４つの段階は、表示域１１５５のレイアウトが第１段階５１１０における上述のレイアウトと同じであることを除いて、図５１の後半の４つの段階と同様であり、したがって、不必要な詳細で本発明の説明をあいまいにしないために、さらなる説明はしない。

一部の実施形態は、選択可能リモートカメラ切り換えＵＩ項目が表示域１１５５ではなくＰＩＰ表示５１６５に表示されることを除いて、図５２に示されるレイアウトと同様のレイアウトを提供する。図５３はこのようなレイアウト５１０５を示す。特に、この図は、選択可能リモートカメラ切り換えＵＩ項目５１８０と、消音ボタン５２８２、ローカルカメラ切り換えボタン５２８６及び会議終了ボタン５２８４を有する表示域１１５５とを有するＰＩＰ表示を示す。

上述のように、ユーザがリモートカメラ切り換えを要求する場合に、プロセス５０００は５０２５に移行する。５０２５では、プロセス５０００は、カメラ切り換え要求をリモートデバイスに送信する。一部の実施形態では、この要求は、上述のようなＶＴＰマネージャ３１２５によってオーディオチャネル及びビデオチャネルで多重化されたテレビ会議制御チャネルを通じて送信される。

カメラ切り換え要求が受信された後に、プロセス５０００は、リモートデバイスがカメラ切り換え要求に応答したかどうかを（５０３０において）判定する。一部の実施形態では、リモートデバイスは、テレビ会議制御チャネルを通じてローカルデバイスに承認応答を自動的に送信する（すなわち、確認応答を送信する）。しかし、他の実施形態では、リモートデバイスのユーザは、リモートデバイスのユーザインタフェースを通じて、この要求を承諾しなければならない。

図５４のＵＩ５４０５の最初の２つの段階５４１０及び５４１５は、リモートデバイス５４００のカメラ切り換え要求をリモートユーザが承諾する一例を示す。第１段階５４１０は、（１）リモートユーザに要求を通知するテキストを表示するための表示域５４４０、（２）リモートデバイスのカメラ切り換え要求を承諾するための選択可能ＵＩ項目５４６５（例えば、許可ボタン５４６５）、及び（３）リモートデバイスのカメラ切り換え要求を拒否するための選択可能ＵＩ項目５４７０（例えば、拒否ボタン５４７０）を示す。その後、第２段階５４１５は、選択可能ＵＩ項目５４６５の強調表示によって示されるように、カメラ切り換え要求を承諾するためのＵＩ項目５４６５をリモートデバイスのユーザが（例えば、シングルフィンガータップ５４８０を通じて）選択した後のＵＩ５４０５を示す。

リモートデバイスから応答をまだ受信していないと（５０３０において）プロセス５０００が判定した場合に、プロセス５０００は、テレビ会議終了要求が受信されたかどうかを（５０３５において）判定する。テレビ会議終了要求が受信された場合に、プロセス５０００は終了する。そうでない場合に、プロセスは、リモートデバイス及びローカルデバイスの現在使用されているカメラから画像を（５０４０において）受信し、これらの画像に基づいてテレビ会議のための合成ビューを生成し、ローカルデバイスのビデオ画像をリモートデバイスに伝送し、その後５０３０に移行する。

リモートデバイスから応答をまだ受信したと（５０３０において）プロセス５０００が判定した場合に、プロセス５０００は、リモートデバイスがカメラ切り換え要求を承諾したかどうかを（５０４５において）判定する。承諾していないならば、プロセス５０００は動作５０１０に戻り、他のデバイスのカメラから画像を受信し続ける。そうでないならば、プロセスは、リモートデバイスの他のカメラから画像を（５０５０において）受信し、その後、ローカルデバイスでカメラ切り換えアニメーションを（５０５５において）実行し、以前に利用したリモートカメラのビデオと現在利用されているリモートカメラのビデオ（すなわち、動作５０５０において受信した画像）との間の移行を表示する。５０５５の後で、プロセスは、上述した５０１０に移行する。

図５１のＵＩ５１０５に示される後半の４つの動作段階５１３０、５１３５、５１４０及び５１４５は、ローカルデバイス５１００上でのこのようなリモートカメラ切り換えアニメーションの一例を示す。例示的なアニメーションは、図５１がリモートデバイスの前面カメラによって取り込まれた女性のビデオを、リモートデバイスの背面カメラによって取り込まれた木のビデオと置き換えるアニメーションを表示域５１５０に示すことを除いて、図４８の段階４８１５、４８２０、４８２５及び４８３０に示される例示的なアニメーションと同様である。図５２及び図５３の後半の４つの段階は、図５２及び図５３の表示域１１５５が図５１の表示域１１５５と異なる選択可能ＵＩ項目を含むことを除いて、図５１のアニメーションと同じアニメーションを示す。

一部の実施形態では、リモートデバイスがカメラを切り換える場合に、リモートデバイスのＵＩも、２つのカメラ間の移行を表示するためにカメラ切り換えアニメーションを実行する。図５４のＵＩ５４０５に示される後半の４つの動作段階５４２０、５４２５、５４３０及び５４３５は、リモートデバイス５４００がカメラを切り換える場合にリモートデバイス５４００に表示されるカメラ切り換えアニメーションの一例を示す。このアニメーションは、表示域５４４５のアニメーションがリモートデバイス５４００の前面カメラによって取り込まれた女性のビデオを、リモートデバイス５４００の背面カメラによって取り込まれた木のビデオと置き換えることを除いて、図４６の段階４６３０、４６３５、４６４０及び４６４５に示されるアニメーションと同様である。

前述のように、図４６、図４７、図４８、図４９、図５１、図５２、図５３及び図５４は、ユーザインタフェースで実行されるカメラ切り換えアニメーションの種々の例を示す。一部の実施形態では、カメラ切り換えアニメーションによって、例えばテレビ会議マネージャ１６０４及び画像処理マネージャ１６０８によって実行できる、拡大縮小、合成及びパースペクティブ歪みなどのそれぞれのデュアルカメラ携帯デバイスの画像処理動作への変更を引き起こす。

Ｃ．露出調整
デュアルカメラ携帯デバイスと別の携帯デバイスとの間のテレビ会議中に、異なる実施形態は、どちらかの携帯デバイスのカメラによって取り込まれた画像の露出を調整するための異なる技術を提供する。一部の実施形態は、デュアルカメラ携帯デバイスのユーザが他のデバイスのカメラによって取り込まれた画像の露出を調整するための技術を提供するが、他の実施形態は、ユーザがデュアルカメラ携帯デバイスのカメラによって取り込まれた画像の露出を調整するための技術を提供する。いくつかの例示的な技術について、以下で詳細に説明する。

図５５は、テレビ会議中に一部の実施形態のデュアルカメラ携帯デバイスでリモート露出調整動作を実行するためのプロセス５５００を示す。以下の説明では、ユーザがリモートデバイスにその露出レベルを調整するように指示するデバイスは、ローカルデバイスと呼ばれる。一部の実施形態では、プロセス５５００は、ローカルデバイスのテレビ会議マネージャによって実行される。さらに、プロセス５５００について、図５６、図５７及び図５８に関して説明する。これらの図は、ローカルデバイスのユーザが露出調整動作を実行するようにリモートデバイスに要求するための種々の仕方を示す。

図５５に示すように、プロセス５５００は、ローカルデバイスとリモートデバイスとの間のテレビ会議を（５５０５において）開始することによって始まる。その後、プロセス５５００は、ローカルデバイスの表示画面に表示するためのリモートデバイスからのビデオを（５５１０において）受信する。次に、プロセス５５００は、テレビ会議終了要求が受信されたかどうかを（５５１５において）判定する。上述のように、一部の実施形態は、ローカルデバイス又はリモートデバイスのユーザからテレビ会議終了要求を受信できる。プロセス５５００がテレビ会議終了要求を受信した場合に、プロセス５５００は終了する。

しかし、プロセス５５００がテレビ会議終了要求を受信しない場合に、プロセス５５００は、その後、リモートデバイスのカメラの露出を調整するための要求が受信されたかどうかを（５５２０において）判定する。リモートデバイスのカメラの露出を調整するための要求が受信されたとプロセス５５００が判定した場合に、プロセス５５００は動作５５１０に戻り、リモートデバイスから取り込まれた追加のビデオを受信する。図５６、図５７及び図５８は、ユーザがこのような要求を行うための仕方を提供する３つの異なる例を示す。図５６、図５７及び図５８では、第１段階５６１０、５７１０及び５８１０はすべて、２つのビデオ、すなわちローカルデバイスのカメラによって取り込まれたビデオ及びリモートデバイスのカメラによって取り込まれたビデオを表示する、ローカルデバイス５６００、５７００及び５８００のＰＩＰ表示５６２５、５７５０及び５８３５を示す。第１段階５６１０、５７１０及び５８１０では、背景表示５６３５、５７６０及び５８４５の男性は暗く、男性が適切に露出されていないことを示す。

図５６の第２段階５６１５は、ローカルデバイス５６００のユーザがリモートデバイスのビデオを（例えば、背景表示５６３５のシングルタップを通じて）選択することによって露出調整を実行するようにリモートデバイスに要求するための１つの仕方を示す。この仕方では、ＵＩ５６０５は、ボックス５６４５によって規定されたユーザの関心領域の選択を、関心領域に対して露出調整を実行するようにリモートデバイスに指示し、したがって露出調整動作を実行するためにリモートデバイスに連絡するようにローカルデバイスのテレビ会議マネージャに指示したいというユーザの希望に自動的に関連付ける。規定の関心領域は、リモートデバイスによって露出調整の算出に使用される。

図５６の第２段階５６１５のように、図５７の第２段階５７１５は、第３段階５７２０に示す選択可能ＵＩ項目５７７０を表示するようにこの選択がＵＩ５７０５に指示することを除いて、リモートデバイスのビデオのローカルユーザの選択を示す。第４段階５７２５は、ローカルデバイスのユーザが上述の露出調整動作を実行するようにリモートデバイスに指示するために選択可能ＵＩ項目５７７０を選択することを示す。

図５８の第２段階５８１５は、図５７の第２段階５７１５と同様であるが、リモートデバイスのビデオのユーザの選択が単一の選択可能ＵＩ項目を表示するようにＵＩに指示するのではなく、第３段階５８２０に示すように、ユーザの選択が、選択可能ＵＩ項目５８５５、５８６０、５８６５及び５８７０のメニューを表示するようにＵＩ５８０５に指示する。選択可能ＵＩ項目は、オートフォーカス項目５８５５と、自動露出項目５８６０と、カメラ切り換え項目５８６５と、キャンセル項目５８７０とを含む。一部の実施形態では、カメラ切り換えの選択可能ＵＩ項目５８６５は、ローカルカメラ切り換え動作を要求するために使用されるが、他の実施形態では、カメラ切り換えの選択可能ＵＩ項目５８６５はリモートカメラ切り換え動作を要求するために使用される。第４段階５８２５は、ユーザが上述の露出調整動作を実行するようにリモートデバイスに指示するために自動露出項目５８６０を選択することを示す。

ローカルユーザが露出調整動作を要求するようにローカルデバイスに指示したと（５５２０において）プロセス５５００が判定した場合に、プロセス５５００は、現在ビデオを取り込んでいてローカルデバイスに伝送しているカメラによって取り込まれたビデオの露出を調整するために、テレビ会議制御チャネルを通じてリモートデバイスにコマンドを（５５２５において）送信する。動作５５２５の後に、プロセス５５００は、上述した動作５５１０に移行する。

一部の実施形態では、リモートデバイスのユーザは、リモートデバイスが露出調整動作を実行する前に承認を与えるように要求されるが、他の実施形態では、リモートデバイスは、ローカルデバイスから要求を受信すると、露出調整動作を自動的に実行する。さらに、一部の実施形態では、テレビ会議機能のうちの一部は、テレビ会議マネージャ１６０４によって実施される。これらの実施形態のうちの一部では、テレビ会議マネージャ１６０４は、使用されているリモートデバイスカメラのセンサの露出設定を調整するようにＣＩＰＵ１６５０に命令することによって、露出調整動作を実行する。

図５６、図５７及び図５８の最後の段階５６２０、５７３０及び５８３０は、リモートデバイスのビデオをより明るく示し、男性が適切に露出されていることを示す。図５６、図５７及び図５８は、リモートデバイスの露出を補正するという露出調整要求を受信する例を提供するが、一部の実施形態は、ローカルデバイスがローカルデバイスのカメラの露出を調整することをローカルデバイスのユーザが要求するための仕方を提供する。このような要求は、リモートデバイスにそのカメラの露出を調整するように要求するための、図５６、図５７及び図５８に示される仕方と同様にしてなされうる。

上述の図５６〜５８は、露出調整動作を実行するためのいくつかのユーザインタフェースを示す。一部の実施形態では、露出調整動作は、以下でさらに詳細に説明する露出調整プロセス５９００の起動などのデュアルカメラ携帯デバイスの画像処理動作への変更を引き起こすことができる。露出調整動作は、例えば、カメラの露出レベル設定の変更のようなビデオを取り込んでいるデュアルカメラ携帯デバイスのカメラの動作の変更も引き起こすことができる。

１．露出調整方法
図５９は、図１６に示されるプロセスなどの、一部の実施形態の画像処理マネージャによって実行される露出調整プロセス５９００を概念的に示す。一部の実施形態では、プロセス５９００は、図５５、図５６、図５７及び図５８に関して上述した露出調整動作の一部である。このような実施形態のうちの一部では、画像処理マネージャ１６０８は、プロセス５９００を実行し、テレビ会議マネージャ１６０４に命令を送信することによってカメラの露出設定を調整し、テレビ会議マネージャ１６０４は、上述のように、カメラセンサ４０５ａ又は４０５ｂを調整するようにＣＩＰＵ１６５０に命令する。

一部の実施形態では、プロセス５９００は、図９に示される画像処理層９３０によって実行されるが、他の実施形態では、プロセス５９００は、図４に示される統計エンジン４６５によって実行される。一部の実施形態は、テレビ会議中に（ローカル又はリモートの）デバイスのカメラによって取り込まれた画像に対してプロセス５９００を実行するが、他の実施形態は、図２１に示されるプロセス２１００（例えば、動作２１１０）の一部としてプロセス５９００を実行する。一部の実施形態は、デュアルカメラ携帯デバイスのカメラによって取り込まれた、明る過ぎも暗すぎもしない画像を露出させるために露出調整動作を実行する。言い換えれば、プロセス５９００は、詳細の量をできる限り最大にする方式で画像を取り込むために実行される。

プロセス５９００は、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像を（５９０５において）受信することによって始まる。一部の実施形態では、受信された画像がテレビ会議においてデバイスのカメラによって取り込まれた第１画像である場合に、プロセス５９００は、第１画像に対して実行されない（すなわち、第１画像よりも前に、露出値を判定するための画像はない）。その後、プロセス５９００は、受信した画像の規定の領域の画素値を（５９１０において）読み取る。異なる実施形態は、領域を異なるように規定する。このような実施形態のうちの一部は、正方形、長方形、三角形、円形などの異なる形状をした領域を規定するが、このような実施形態の他のものは、中央、上部中央、下部中央などの画像内の異なる位置に領域を規定する。

次に、プロセス５９００は、画像の規定の領域における画素値の平均を（５９１５において）算出する。プロセス５９００は、画素値の算出された平均が特定の規定の値に等しいかどうかを（５９２０において）判定する。異なる実施形態は、異なる特定の値を定義する。例えば、一部の実施形態は、画像のダイナミックレンジのメジアン画素値として特定の値を定義する。一部の実施形態では、単一の値ではなく、値の範囲が定義される。このような実施形態では、プロセス５９００は、画素値の算出された平均が規定の値の範囲内にあるかどうかを（５９２０において）判定する。

画素値の算出された平均が特定の規定の値に等しくない場合に、プロセス５９００は、算出された平均に基づいて露出値を（５９２５において）調整する。画素値の算出された平均が特定の規定の値に等しい場合に、プロセス５９００は終了する。一部の実施形態では、露出値は、カメラセンサが光に露光される時間量を表す。一部の実施形態では、調整された露出値は、受信した画像を取り込んだカメラによって取り込まれるべき次の画像を露出させるために使用される。算出された平均に基づいて露出値が調整された後、プロセス５９００は終了する。

一部の実施形態では、画素値の算出された平均が特定の規定の値に等しくなる（又は、値の規定の範囲内に入る）まで、プロセス５９００は反復して実行される。一部の実施形態は、テレビ会議中にプロセス５９００を常に実行するが、他の実施形態は、テレビ会議中に規定の間隔（例えば、５秒、１０秒、３０秒など）でプロセス５９００を実行する。そのうえ、テレビ会議中に、一部の実施形態のプロセス５９００は、プロセス５９００を実行する前に特定の画素値を動的に再定義する。

図６０は、一部の実施形態の露出調整動作の例を概念的に示す。例６０００、６０１０及び６０１５のそれぞれは、デュアルカメラ携帯デバイスのカメラによって取り込まれた画像６０２０を左側に示す。具体的には、画像６０２０は、色の暗い人を太陽の前に示す。色の暗い人は、画像の露出レベルが、人の顔又は身体を露出させるのに十分なほど高くないことを示す。各例６０００、６０１０及び６０１５の右側はそれぞれ、画像６０２０の後に取り込まれた画像６０２５、６０３０及び６０３５を示す。一部の実施形態では、画像６０２０及び右側の画像は、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオの画像である。他の実施形態では、画像６０２０及び右側の画像は、依然として、異なる時点でデュアルカメラ携帯デバイスのカメラによって取り込まれた静止画像である。

第１例６０００は、露出調整のされていない動作を示す。したがって、画像６０２５は、画像６０２０と同じように見える。露出調整が実行されなかったので、画像６０２５の人は、画像６０２０の人のように、色の暗いままである。

第２例６０１０では、露出調整動作が画像６０２０に対して実行される。一部の実施形態では、露出調整動作は、規定の領域６０４０を使用して、プロセス５９００によって実行される。露出調整動作に基づいて、カメラの露出レベルが調整され、カメラは、調整された露出レベルを使用して画像６０３０を取り込む。図６０に示すように、画像６０３０の人は、画像６０２５ほど暗くはない。しかし、画像６０３０の人の顔及び身体は、依然として明瞭ではない。

第３例６０１５は、画像６０２０に対して実行される露出調整動作を示す。第２例６０１０と同様に、一部の実施形態の例６０１５の露出調整動作は、規定の領域６０４５を使用してプロセス５９００によって実行される。露出調整動作に基づいて、カメラの露出レベルが調整され、カメラは、調整された露出レベルを使用して画像６０３５を取り込む。図６０で分かるように、人の顔及び身体が認識できるので、画像６０３５の人は完全に露出される。

一部の実施形態では、規定の領域の選択は、デュアルカメラ携帯デバイスのユーザによってなされうる。デバイス自体はまた、ＣＩＰＵ４００で上述した露出調整のフィードバックループを通じた露出調整動作のために、その規定の領域を自動的に調整できる。図４の統計エンジン４６５は、取り込まれた画像に対して露出レベルが適切であるかどうかを判定し、それに応じて（例えば、センサモジュール４１５への直接接続を通じて）カメラセンサを調整するためにデータを収集してもよい。

Ｄ．焦点調整
図６１は、テレビ会議中にデュアルカメラ携帯デバイスのフォーカスを調整するためのプロセス６１００を示す。以下の説明では、ユーザがリモートデバイスにそのカメラのフォーカスを調整するように指示するデバイスが、ローカルデバイスと呼ばれる。一部の実施形態では、図６１のプロセス６１００は、ローカルデバイスのテレビ会議マネージャ１６０４によって実行される。また、このプロセスについて、以下で図６２及び図６３に関して説明する。これらの図は、リモートデバイスによって焦点調整動作が実行されることをローカルデバイスのユーザが要求するための２つの例示的な方式を提供する。

図６１に示すように、プロセス６１００は、ローカルデバイスとリモートデバイスとの間のテレビ会議を（６１０５において）開始することによって始まる。その後、プロセス６１００は、ローカルデバイスの表示画面に表示するためのビデオをリモートデバイスから（６１１０において）受信する。次に、６１１５では、プロセス６１００は、テレビ会議終了要求が受信されたかどうかを判定する。上述のように、テレビ会議は、一部の実施形態では、ローカルデバイス又はリモートデバイスのユーザの要求により終了できる。プロセス６１００がテレビ会議終了要求を受信した場合に、プロセス６１００は終了する。

そうでない場合に、プロセスは、リモートデバイスのリモートカメラのフォーカスを調整することの要求を受信したかどうかを（６１２０において）判定する。リモートデバイスのリモートカメラのフォーカスを調整するための要求を受信していないとプロセス６１００が判定した場合に、プロセス６１００は、動作６１１０に戻り、リモートデバイスから追加のビデオを受信する。図６２、図６３及び図６４は、異なる実施形態がこのような要求を行うためにユーザに提供する３つの異なるやり方を示す。図６２、図６３及び図６４では、第１段階６２１０、６３１０及び６４７２はすべて、２つのビデオ、すなわちローカルデバイスによって取り込まれたビデオ及びリモートデバイスによって取り込まれたビデオを表示するローカルデバイス６２００、６３００及び６４７１のＰＩＰ表示６２２５、６３３５及び６４８２を示す。図６２及び図６３の表示域１１５５及び１１５５は、会議終了ボタンを示す。しかし、図６４では、表示域１１５５のレイアウトは、上述した図１２の表示域１１５５のレイアウトと同じである。さらに、表示域１１５５に示されるカメラ切り換えボタン６４８８は、一部の実施形態ではローカルカメラ切り換え動作を、又は他の実施形態ではリモートカメラ切り換え動作を起動するために選択されうる。第１段階６２１０、６３１０及び６４７２に示すように、背景表示６２３５、６３４５及び６４８０に表示されるリモートデバイスのビデオは不鮮明である。

図６２の第２段階６２１５は、ローカルデバイスのユーザが（例えば、リモートデバイスのビデオのシングルタップ６２４０を通じて）リモートデバイスのビデオを選択するだけで焦点調整を要求するための１つの手法を示す。この手法では、ＵＩ６２０５は、ボックス６２４５によって規定されたユーザの関心領域の選択を、関心領域に対して（フォーカスなどの）動作を実行するようにリモートデバイスに指示し、したがって（焦点調整動作などの）調整動作を実行するためにリモートデバイスに連絡するようにローカルデバイス６２００のテレビ会議マネージャ１６０４に指示したいというユーザの希望に自動的に関連付ける。規定の関心領域は、リモートデバイスによって焦点調整の算出に使用される。

図６３の第２段階６３１５は、同様に、（例えば、ユーザのリモートデバイスのビデオへのタップを通じて）ローカルユーザのリモートビデオの選択を示す。しかし、図６２に示される例とは異なり、図６３のこの選択は、第３段階６３２０に示すように、（選択可能なボタンとして実装できる）選択可能ＵＩ項目６３５５、６３６０、６３６５及び６３７０のメニューを表示するようにＵＩ６３０５に指示する。これらの選択可能ＵＩ項目は、オートフォーカス項目６３６０と、自動露出項目６３６５と、カメラ切り換え項目６３７０と、キャンセル項目６３５５とを含む。一部の実施形態では、カメラ切り換えの選択可能ＵＩ項目６３７０は、ローカルカメラ切り換え動作を要求するために使用されるが、他の実施形態では、カメラ切り換えの選択可能ＵＩ項目６３７０は、リモートカメラ切り換え動作を要求するために使用される。その後、第４段階６３２５は、ローカルユーザがオートフォーカス項目６３６０を選択することを示す。

図６４の第２段階６４７４は、この場合もやはり同様に、（例えば、ユーザのリモートデバイスのビデオのタップを通じて）ローカルユーザのリモートビデオの選択を示す。しかし、図６３に示される例とは異なり、図６４のこの選択は、焦点調整動作を（すなわち、第２段階６４７４において）要求するようにＵＩ６４７８に指示する。焦点調整動作が完了した後、ＵＩ６４７８は、選択可能なボタンとして実装できる選択可能ＵＩ項目６４８４及び６４８６のメニューを（すなわち、第３段階６４７６において）表示する。これらの選択可能ＵＩ項目は、自動露出項目６４８６とキャンセル項目６４８４とを含む。

ローカルユーザが焦点調整動作を要求するようにローカルデバイスに指示したと（６１２０において）プロセスが判定した場合に、プロセス６１００は、リモートデバイスが現在ビデオを取り込んで伝送しているカメラのフォーカスを調整するために、テレビ会議制御チャネルを通じてリモートデバイスにコマンドを（６１４０において）送信する。６１４０の後で、プロセスは、上述した６１１０に移行する。

一部の実施形態では、リモートデバイスのユーザは、リモートデバイスがこの動作を実行する前に承認を与えなければならないが、他の実施形態では、リモートデバイスは、ローカルデバイスのための要求を受信すると、この動作を自動的に実行する。また、一部の実施形態では、焦点調整動作は、テレビ会議中に使用されているリモートデバイスのカメラのフォーカス設定を調整する。このような実施形態のうちの一部では、テレビ会議機能のうちの一部は、上述のテレビ会議モジュール１６０２によって実施される。これらの実施形態では、テレビ会議マネージャ１６０４は、使用されているリモートデバイスカメラのセンサを調整するようにＣＩＰＵ１６５０に命令する。

図６２、図６３及び図６４の最後の段階６２２０、６３３０及び６４７６は、適切にフォーカスが合わされたリモートデバイスのビデオを示す。図６２、図６３及び図６４は、リモートデバイスのフォーカスを補正することの焦点調整要求を受信する例を提供するが、一部の実施形態により、ローカルデバイスのユーザは、ローカルデバイスがローカルデバイスのカメラのフォーカスを調整することを要求できる。このような要求は、リモートデバイスにそのカメラのフォーカスを調整するように要求するための、図６２、図６３及び図６４に示される手法と同様にしてなされうる。

図６２、図６３及び図６４は、ユーザが焦点調整動作を実行できる３つの例示的なユーザインタフェースを示す。一部の実施形態では、焦点調整動作によって、カメラのフォーカスの変更などの、ＵＩに表示されるビデオを取り込んでいるデュアルカメラ携帯デバイスのカメラの動作への変更が生じる。

図５６及び図６２で上述したように、規定の関心領域はそれぞれ、リモート携帯デバイスによってビデオの露出調整及び焦点調整の計算に使用された。しかし、一部の他の実施形態では、ユーザによる関心領域の選択は、１つ以上の動作を実行するようにリモートデバイスに指示するために使用されうる。例えば、一部の実施形態では、露出調整及び焦点調整の両方は、規定の関心領域に基づいて実行され、それによって、両方の動作を実行するようにリモートデバイスに指示されてもよい。

Ｅ．フレームレート制御
テレビ会議中に、一部の実施形態は、デュアルカメラ携帯デバイスのカメラによって取り込まれるビデオの画像がテレビ会議において他のデバイスに伝送される速度（すなわち、フレームレート）の調整又は維持を希望してもよい。例えば、固定帯域幅を仮定すると、このような実施形態のうちの一部は、ビデオの画像の画質を向上させるためにビデオのフレームレートを減少させるが、このような実施形態の他のものでは、ビデオを平滑化するためにビデオのフレームレートを増加させる（すなわち、ジッタを減少させる）。

異なる実施形態は、テレビ会議中にビデオの画像のフレームレートを制御するための異なる技術を提供する。以前に上述した一例は、カメラによって取り込まれた画像が処理される速度を制御するためのカメラのセンサモジュール４１５のＶＢＩを調整する。別の例として、図９に示されるテレビ会議モジュール９２５の管理層９３５の一部の実施形態は、画像を破棄することによってフレームレートを制御する。同様に、画像処理層９３０の一部の実施形態は、画像を破棄することによってフレームレートを制御する。一部の実施形態は、汎用伝送バッファ３１２０内のフレームの破棄などの、フレームレートを制御するためのさらに他の技術を提供する。

Ｖ．デュアルカメラ
Ａ．ビューの結合
１．ピクチャインピクチャ：２つのリモートカメラの表示
一部の実施形態により、デュアルカメラ携帯デバイスは、テレビ会議中に携帯デバイスから取り込まれたビデオ及び別のデュアルカメラ携帯デバイスから取り込まれたビデオをいくつかの表示構成のいずれかで表示できる。図６５は、１つ以上のデュアルカメラ携帯デバイスから取り込まれたビデオのための異なる表示構成の例を示す。図６５では、デュアルカメラ携帯デバイス６５００（デバイスＡ）のユーザ及び第２デュアルカメラ携帯デバイス６５０５（デバイスＢ）の第２ユーザは、互いとのテレビ会議を行っている。

図６５は、デバイスＡのための表示構成の４つの例を左に示す。デバイスＡのための４つの表示構成は、第１ビュー６５１０、第２ビュー６５１５、第３ビュー６５２０及び第４ビュー６５２５である。さらに、図６５はまた、デバイスＢのための表示構成の４つの例を右に示す。デバイスＢのための４つの表示構成は、第１ビュー６５６５、第２ビュー６５７０、第３ビュー６５７５及び第４ビュー６５８０である。この例では、デバイスＡは、デバイスＡのカメラから取り込まれた２つのビデオのみを表示し、デバイスＢは、デバイスＡのカメラから取り込まれた２つのビデオだけでなく、デバイスＢのカメラから取り込まれたビデオの一方又は両方を表示する。

第１ビュー６５１０では、デバイスＡのＵＩ６５８５は、合成表示６５１２を提供する。合成表示６５１２は、２つの表示域、すなわちデバイスＡの背面カメラから取り込まれたビデオを表示するための表示域６５３０と、デバイスＡの前面カメラから取り込まれたビデオを表示するための表示域６５３５とを含む。この例では、表示域６５３０は合成表示６５１２の上半分にあり、表示域６５３５は合成表示６５１２の下半分にある。この２つの表示域は、第１ビュー６５１０では、等しいサイズである。上部表示域６５３０は、山のビデオを表示しており、これは、デバイスＡの背面カメラによって取り込まれている山と想定される。表示域６５３５は、木と帽子を被った男性とを表示しており、これは、デバイスＡの前面カメラによって取り込まれている木と帽子を被った男性とであると想定される。

第２ビュー６５１５のＵＩ６５８５は、（デバイスＡの前面カメラから取り込まれたビデオを表示する）表示域６５３５がこの時点で合成表示６５１７の上半分にあり、かつ（デバイスＡの背面カメラから取り込まれたビデオを表示する）表示域６５３０が合成表示６５１７の下半分にあることを除いて、第１ビュー６５１０と同じ２つの表示域を含む合成表示６５１７を提供する。

第３ビュー６５２０では、ＵＩ６５８５は、ＰＩＰ表示６５９５を提供する。ＰＩＰ表示６５９５は、２つの表示域、すなわちデバイスＡの前面カメラから取り込まれたビデオを背景表示域として表示する表示域６５３５と、デバイスＡの背面カメラから取り込まれたビデオを前景挿入表示域として表示する表示域６５３０とを含む。このビューでは、背景表示域６５３５はＰＩＰ表示６５９５の大半を占めるが、挿入表示域６５３０は背景表示域６５３５よりも小さく、この一部分に重なる。

第４ビュー６５２５のＵＩ６５８５も、第３ビュー６５２０に示す表示域６５３０及び６５３５を含むＰＩＰ表示６５９８を提示する。ＰＩＰ表示６５９５とは異なり、ＰＩＰ表示６５９８は、（デバイスＡの背面カメラから取り込まれた）表示域６５３０を背景メイン表示として含み、（デバイスＡの前面カメラから取り込まれた）表示域６５３５を前景挿入表示として含む。さらに、ＰＩＰ表示６５９８は、横ビューで提示される（すなわち、ＰＩＰ表示６５９８の幅は高さよりも大きい）。

上記の例は、デバイスＡのＵＩのための４つの取りうる合成ビューを示し、そのうちの２つでは、第１デバイスの２つのカメラを表示するための２つの表示域６５３０及び６５３５が垂直に並べられ、２つはＰＩＰビューである。他のビューも、デバイスＡのＵＩで可能である。例えば、２つの表示域は、水平又は斜めに並べられることができ、又は異なるＰＩＰビューが使用されうる。

デバイスＢのために示された種々のビューは、デバイスＢのＵＩのための異なるビューが可能であることを示す。これらのビューは、デバイスＡの両方のカメラだけでなく、デバイスＢの１つ以上のカメラから取り込まれたビデオを含む。デバイスＢの第１ビュー６５６５では、デバイスＢのＵＩ６５９０は、ＰＩＰ表示６５６８を提供する。ＰＩＰ表示６５６８は、デバイスＡに表示される合成表示６５１２と同一である合成表示域６５６９だけでなく、デバイスＢのカメラの一方（例えば、前面カメラ）によって取り込まれたビデオを表示する挿入表示域６５５０を含む。合成表示域６５６９は、デバイスＡの背面カメラから取り込まれたビデオを表示するための表示域６５３１と、デバイスＡの前面カメラから取り込まれたビデオを表示するための表示域６５３６とを含む。デバイスＡからのビデオを表示する合成表示６５６９はＰＩＰ表示６５６８の大半を占めるが、挿入表示域６５５０は合成表示６５６９よりも小さく、これに重なる。表示域６５５０は、笑顔のビデオを表示しており、これは、デバイスＢの前面カメラによってビデオが取り込まれている笑顔と想定される。

第２ビュー６５７０のデバイスＢのＵＩ６５９０は、ＰＩＰ表示６５７２を提供する。ＰＩＰ表示６５７２は、（デバイスＢの前面カメラから取り込まれたビデオを表示する）表示域６５５０と、デバイスＡのカメラから取り込まれたビデオを表示する表示域６５３１及び６５３６を有する合成表示６５７３とを含む。合成表示６５７３は、デバイスＡのための第２ビュー６５１５の合成表示６５１７と同一であり、ＰＩＰ表示６５７２の大半を占める。第１ビュー６５６５のＰＩＰ表示６５６８と同様に、表示域６５５０は、合成表示６５７３よりも小さく、これに重なる。具体的には、両方のビューにおいて、表示域は、デバイスＡの背面カメラから取り込まれたビデオを表示する表示域６５３１の一部分に重なる。

第３ビュー６５７５では、ＵＩ６５９０は、デバイスＡのための第３ビュー６５２０のＰＩＰ表示６５９５と同様であるＰＩＰ表示６５７７を提供する。ＰＩＰ表示６５７７も、背景表示域６５３６に重なる第２挿入表示域として追加の表示域６５５０を含む。２つの挿入表示域６５３１及び６５５０は、背景主要表示域６５３６の下部に水平にタイル表示される。

第４ビュー６５８０のＵＩ６５９０は合成表示６５８２を提供する。合成表示６５８２は、３つの表示、すなわちＰＩＰ表示６５８３と、表示域６５５０と、（例えば、デバイスＢの背面カメラによって取り込まれたビデオを表示するための）表示域６５４０とを含む。ＰＩＰ表示６５８３は、デバイスＡのための第４ビュー６５２５のＰＩＰ表示６５９８と同一であり、合成表示域６５８２の大半を占める。表示６５４０及び６５５０は、ＰＩＰ表示域６５８３よりも小さく、この下に水平にタイル表示される。

図６５は、デバイスＢのための４つの取りうるビューを示しているが、多くの他のビューが可能である。デバイスＡからのビデオの背景合成表示は、垂直ではなく水平にタイル表示でき、背面カメラ表示域ではなくデバイスＡの前面カメラ表示域に挿入が重なることができ、大きい方の表示域は、デバイスＡのカメラではなく、デバイスＢのカメラ（群）を表示でき、挿入は異なるように位置することなどができる。

デバイスＡの各ビューから生じる矢印６５６０の各集合は、デバイスＡに示される表示とデバイスＢに示される表示の間に相関関係がある必要はないことを示す。例えば、デバイスＡが（例えば、デバイスＡのユーザによるその構成の選択に従って）ビュー６５１０の構成でそのビデオを表示している場合であっても、デバイスＢは、（例えば、デバイスＢのユーザによるその構成の選択に従って）４つの示された構成のいずれか又は図６５に示されていない複数の他の構成のいずれかでビデオを表示できる。言い換えれば、デバイスＡのための表示構成は、デバイスＢの表示構成とは無関係である。一部の実施形態は、あるデバイスから別のデバイスに表示域を伝送せず、単にビデオを（例えば、符号化された形で）伝送し、その対応する表示域にデバイスによって表示される。

２．特殊ＰＩＰ
一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、テレビ会議中にＰＩＰ表示においてビデオの前景を別のビデオに重畳することができる。一部の実施形態では、ビデオの前景は、単一のカメラによって取り込まれた単一のビデオの表示として見えるような仕方で、他のビデオに混合する。図６６は、ＰＩＰ表示において背景ビデオへの挿入ビデオの前景への重畳のこのような一例を示す。

図６６は、このビデオ重畳動作を、ＵＩ６６７０の７つの動作段階６６２０、６６２５、６６３０、６６３５、６６４０、６６６０及び６６６５として示す。第１段階６６２０は、リモートデバイスとのテレビ会議中のＰＩＰ表示６６８２を有するデュアルカメラ携帯デバイス６６００のＵＩ６６７０を示す。第１段階６６２０に示すように、ＰＩＰ表示６６８２は２つのビデオ表示、すなわち背景メイン表示６６１０と、前景挿入表示６６０５とを含む。背景メイン表示６６１０はＵＩ６６７０の大半を占めるが、前景挿入表示６６０５は背景メイン表示６６１０よりも小さく、これに重なる。

この例では、背景表示域６６１０は、山のビデオを表示しており、これは、リモートデバイスのカメラのうちの一方によって取り込まれている山であると想定される。前景挿入表示域６６０５は、帽子を被った人のビデオを表示しており、これは、この例では、ローカルデバイスのカメラのうちの一方によってビデオが取り込まれる人であると想定される。ＰＩＰ表示６６８２の下は、選択することによって（例えば、ボタンをシングルタップ又はダブルタップすることによって）ユーザがテレビ会議を終了できる会議終了と標示された選択可能ＵＩ項目６６８５（例えばボタン６６８５）である。

第２段階６６２５は、選択可能メニュー６６７５の起動を示す。一部の実施形態では、選択可能ＵＩ項目６６７５のメニューは、ＰＩＰ表示域６６８２を選択することによって（例えば、タッチすることによって）起動されうる。このような起動動作の代わりに、又はこれと共に、一部の実施形態により、ユーザは、異なるタッチスクリーン動作を通じてか、又はデバイスの１つ以上の他の物理的入力を使用するなどの、他の動作を通じて選択可能ＵＩ項目６６７５のメニューを起動することもできる。

第３段階６６３０は、ビデオ重畳動作を選択するための選択可能ＵＩ項目の起動された集合を有するＵＩ６６７０を表示する。この例では、いくつかの選択可能ＵＩ項目を有するポップアップメニュー６６７５が、ＰＩＰ表示６６８２上に表示される。選択可能ＵＩ項目６６７５のメニューは、「ＰＩＰフリップ」選択可能ＵＩ項目６６４０（例えばボタン６６４０）と、「特殊ＰＩＰ」選択可能ＵＩ項目６６４５（例えばボタン６６４５）と、「キャンセル」選択可能ＵＩ項目６６９０（例えばボタン６６９０）とを含む。この例では、「ＰＩＰフリップ」ボタン６６４０を選択することによって、ＵＩ６６７０は（次のセクションで詳細に説明するように）背景表示６６１０を挿入表示６６０５と交換し、「特殊ＰＩＰ」ボタン６６４５を選択することによって、ＵＩ６６７０はビデオ重畳動作を開始し、「キャンセル」ボタン６６９０を選択することによって、ＰＩＰ表示６６８２からポップアップメニュー６６７５を削除する。他の実施形態は、異なる又はこれより多い項目をＰＩＰポップアップメニュー６６７５に含む。

第４段階６６３５は、ユーザが（例えば、自身の指６６９５でボタン６６４５をタップすることによって）「特殊ＰＩＰ」ボタン６６４５を選択した後のＵＩ６６７０を示す。この選択は、ＵＩ表示６６７０上でのボタン６６４５の強調表示によって示される。一部の実施形態は、異なる標識（indication）表示（例えば、選択された項目の境界又は選択された項目のテキストの強調表示）を使用する。

第５段階６６４０は、ビデオ重畳動作が始まった後のＵＩ６６７０を示す。この段階で、ＵＩ６６７０により、ユーザは、重畳されるビデオにおいて、前景としてどのビデオから抽出したいかと、背景としてどのビデオを使用した以下を選定できる。ＵＩ６６７０は、いくつかの選択可能ＵＩ項目がＰＩＰ表示６６８２上に表示されたポップアップメニュー６６８０を通じてオプションを提供する。選択可能ＵＩ項目のポップアップメニュー６６８０は、「挿入を選択」選択可能ＵＩ項目６６５５（例えばボタン６６５５）と、「メインを選択」選択可能ＵＩ項目６６５０（例えばボタン６６５０）と、「キャンセル」選択可能ＵＩ項目６６９２（例えばボタン６６９２）とを含む。

「挿入を選択」ボタン６６５５の選択によって、ＵＩ６６７０は、ローカルデバイスのカメラからの挿入ビデオ６６０５の前景（すなわち、帽子を被った男性）をリモートデバイスのカメラからの背景メインビデオ６６１０上に重畳する。一方、「メインを選択」ボタン６６５０の選択によって、ＵＩ６６７０は、リモートデバイスのカメラからの背景メインビデオ６６１０の前景（すなわち、山）をローカルデバイスのカメラからの挿入ビデオ６６０５上に重畳する。一部の実施形態では、これによって、挿入表示域６６０５に現在あるビデオがＵＩ６６７０のほとんどを占有し、主要表示域６６１０に現在あるビデオは、この時点で主要ビデオに重畳されるように、２つのビデオフィードの切り換えが生じる。「キャンセル」ボタン６６９２の選択は、ビデオ重畳動作を中止し、ＰＩＰ表示域６６８２からポップアップメニュー６６８０を削除する。

第６段階６６６０は、ユーザが（例えば、自身の指６６９５でボタン６６５５をタップすることによって）「挿入を選択」ボタン６６５５を選択した後のＵＩ６６７０を示す。この選択は、ＵＩ表示６６７０上でのボタン６６５５の強調表示によって示される。一部の実施形態は、異なる標識表示（例えば、選択された項目の境界線又は選択された項目のテキストの強調表示）を使用する。

第７段階６６６５は、ビデオ重畳動作が完了した後のＵＩ６６７０を示す。ＵＩ６６７０に示すように、挿入表示域６６０５の前景（すなわち、帽子を被った男性）が表示域６６０５から抽出される。挿入表示６６０５のウィンドウフレーム及び背景（すなわち、前景以外の他のすべてのもの）も、画面から削除される。最後に、前景（すなわち、帽子を被った男性）は、単一のビデオであるように見える仕方で背景ビデオ６６１０に混合される。挿入ビデオの背景を削除するために種々の異なる技術が使用されうる。一部の実施形態は、他の画素に対して移動していない画素を識別し、一定であるパターン又は色を探し、前景を含む画像と比較されるベースライン画像を使用し、差分を減算するか、又は異なる技術を使用する。

図６６の例は背景表示域６６１０に重畳された場合に挿入表示域６６０５の前景がＵＩ６６７０の同じ所にとどまることを示すが、これは、重畳がどのように機能できるかの一例にすぎない。一部の実施形態は、前景ビデオをＵＩ６６７０内の特定の位置（例えば、中央、隅の１つなど）に移動する。セクションＩＶ．Ａ．１及びＩＶ．Ａ．３に示される機能と同様に、一部の実施形態により、ローカルデバイスのユーザは、ＵＩ内で重畳された前景ビデオをドラッグしたり、又は重畳された前景ビデオのサイズを変更したりできる。

ビデオ画像のどの部分（群）が上述のビデオ重畳動作のための「前景」であるかを判定するために異なる技術が使用されうる。一部の実施形態のこのような１つの方法は、あるとすれば、ビデオ画像のどの部分（群）が動的であるかを判定する。ビデオ画像の背景は一般に静的である（すなわち、動きがない）ので、動的な部分は「前景」であると考えられる。このような実施形態では、ビデオ画像は、特定の期間にわたって分析される。特定の期間の特定の画素の値の差が、規定のしきい値（例えば、５％、１０％、１５％）よりも大きくないならば、特定の画素は静的な画素であると考えられる。ビデオ画像の各画素が分析された後で、ビデオ画像の動的な（すなわち、静的でない）画素は、ビデオ画像の「前景」であると考えられる。

図６７は、例えば、テレビ会議マネージャ１６０４又は画像処理マネージャ１６０８によって実行されうるビデオ画像の前景を決定するためのこのような技術の一例を示す。具体的には、図６７は、帽子を被った人及び木を示すビデオの６つの画像６７０５〜６７３０のシーケンスを示す。この例では、人は、まったく静かに立っているわけではなく、話していてもよいことが想定される。上述のように、ビデオ画像の各画素は、画素が動的か静的かを判定するために分析される。例えば、画像６７０５〜６７３０の画素６７３５の値の差分は、それが規定のしきい値よりも大きいかどうかが判定される。この場合、画素６７３５は人ではなく地面の一部を表すので、画素６７３５は静的であると考えられる。画像６７０５〜６７３０の画素のすべてが分析された後、画像内の人が動的であり、画像の残りの部分が静的であると判定される。したがって、人は、上記で図６６に関して説明した動作によって抽出される「前景」である。

３．ピクチャインピクチャ表示におけるビデオの交換
一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、テレビ会議中にＰＩＰ表示内の２つの表示域を交換できる（すなわち、挿入表示域がＰＩＰ表示内の背景表示域になり、背景表示域が挿入表示域になる）。図６８は、テレビ会議中にＰＩＰ表示６６８２の挿入表示域６６０５を背景表示域６６１０と交換する一例を示す。

図６８は、ＰＩＰ交換動作を、図６６のデバイス６８００のＵＩ６６７０の８つの動作段階として示す。図６８の最初の３つの段階は、図６６の最初の３つの段階と同一である。これらの段階では、ユーザは、ローカルデバイスのタッチスクリーンを使用した選択を通じて、ＵＩ６６７０内でメニュー６６７５を展開した。

図６８の第４段階６８４０は、ユーザが（例えば、自身の指６６９５でボタン６６４０をタップすることによって）「ＰＩＰフリップ」ボタン６６４０を選択した後のＵＩ６６７０を示す。この選択は、ＵＩ表示６６７０上でのボタン６６４０の強調表示によって示される。一部の実施形態は、異なる標識表示（例えば、選択された項目の境界線又は選択された項目のテキストの強調表示）を使用する。

第５段階６８４５は、ＰＩＰ交換動作が開始した後のＵＩ６６７０が示されている。一部の実施形態は、フリップ動作を通じた挿入表示６６０５と背景表示６６１０との交換をアニメーション化する。図６８は、このようなアニメーションの一例を示す。この例では、アニメーションは、（交換動作が実行される前の）ＰＩＰ表示６６８２が片側にあり、（交換動作が実行された後の）新たなＰＩＰ表示６６８４が他の側にあるビューペインのフリップを通じて説明されうる。ビューペインは、ＰＩＰ表示６６８２の中央にある垂直軸６６８６のまわりを１８０度回転する。この第５段階６８４５で、ビューペインは、垂直軸６６８６のまわりを回転し始める。

第６段階６８５０では、ビューペインは、約９０度回転したように示される。これは、画面の中央に表示された細い線６６８８（すなわち、ビューペインの端）によって示される。第７段階６８５５は、完了に近いビューペインの回転を示す。新たなＰＩＰ表示６６８４は、ビューペインの他の側から見えはじめ、デバイスの画面を埋めるように水平に拡張する。ＰＩＰ表示６６８４は、交換動作が実行された後の２つの表示域６６０５及び６６１０を含む。（ローカルデバイスのカメラからの）帽子を被った男性のビデオを提示する表示域６６０５はこの時点でＰＩＰ表示６６８４の背景にあり、（リモートデバイスのカメラからの）山のビデオを提示する表示６６１０はこの時点で表示６６０５に重なるＰＩＰ表示６６８４の前景にある。第８段階６８６０は、交換表示アニメーションの完了を示す。

図６８に示されるアニメーションがＰＩＰ挿入／背景交換動作の多数の取りうるアニメーションのうちの１つにすぎないことが当業者には理解されよう。例えば、異なる実施形態は、水平軸に沿ってビューペインを回転する、２つの表示域を瞬時に交換する、他方の表示域を縮めながら一方の表示域を拡張することなどができる。一部の実施形態は、交換動作に常に使用される１つのアニメーションを提供するが、他の実施形態により、ユーザは、いくつかのアニメーションから選定したり、異なるアニメーションを（例えば、ランダムな選択を通じて）使用したりできる。そのうえ、交換動作によって、ユーザの入力に応答してビデオの拡大縮小及び合成をテレビ会議マネージャ１６０４に変更させるなどの、デュアルカメラ携帯デバイスの画像処理動作への変更を生じさせることができる。

４．コーナー向けスナップ
本発明の一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、合成表示を形成する１つ以上の表示域を移動させることによって、合成表示を変更できる。このような移動の一例は、セクションＩＶ．Ａ．１で上述した。挿入表示のこのような移動は、ＰＩＰ表示が複数の挿入表示域を含む場合にも可能である。

図６９は、テレビ会議中に実行されるこのような例を示す。図６９に示されるこの例は、図６９がこのような１つの挿入表示域のみではなく、２つの挿入表示域６９０５及び６９１０を含むＰＩＰ表示６９６５の挿入表示域６９１０を移動することを示すことを除いて、図３に示される例と同様である。

図６９では、携帯デバイス６９００のＵＩ６９６０は、別のデバイスのリモートユーザとのテレビ会議中にＰＩＰ表示６９６５を提示する。図６９のＰＩＰ表示６９６５は、３つのビデオ表示、すなわち背景メイン表示６９１５と、２つの前景挿入表示６９０５及び６９１０とを含む。この例では、背景メイン表示６９１５は、歌ってギターを演奏している人のビデオを提示し、これは、リモートデバイスの背面カメラによって取り込まれたビデオであると想定される。前面の挿入表示６９０５は、ラケットを持っている人のビデオを提示し、これは、この例では、ローカルデバイスの背面カメラによって取り込まれたビデオであると想定される。他方の前景挿入表示域６９１０は、帽子を被った人のビデオを提示し、これは、この例では、ローカルデバイスの前面カメラによってビデオが取り込まれている帽子を被った人であると想定される。ＰＩＰ表示６９６５の下は、項目を選択することによってユーザがテレビ会議を終了できる「会議終了」と標示された選択可能ＵＩ項目６９７０（例えばボタン６９７０）である。

このＰＩＰ表示６９６５は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、他の合成ビューを提供してもよい。例えば、リモートデバイスからのビデオのための大きい方の背景表示６９１５を有する代わりに、大きい方の背景表示６９１５はローカルデバイスからのビデオのものであり、小さい方の前景挿入表示６９０５及び６９１０は、リモートデバイスからのビデオのものでありうる。また、一部の実施形態により、ローカルビデオ及びリモートビデオは、挿入表示６９０５及び６９１０が片側にあり、背景表示６９１５が別の側にあるように有するか、又は３つすべてが隣り合うように有するＵＩ６９６０に表示されうる。他の実施形態では、ＰＩＰ表示６９６５はまた、大きい方の背景表示６９１５及び／又は小さい方の前景挿入表示を含んでもよい。一部の実施形態では、ＰＩＰ表示６９６５の方式又はデフォルトの表示モードは、ユーザによって指定されてもよい。

図６９は、デバイス６９００のＵＩ６９６０の２つの挿入表示域のうちの１つの移動を、５つの異なる動作段階６９２０、６９２５、６９３０、６９３５及び６９４０として示す。第１段階６９２０は、デバイス６９００のローカルユーザとリモートデバイスのリモートユーザとの間のテレビ会議中のＵＩ６９６０を示す。

第２段階６９２５は、ユーザが挿入表示域６９１０を選択することによってコーナー向けスナップ動作を開始することを示す。この例では、挿入表示域６９１０内の任意の位置に指６９５０を置くことによって選択がなされる。図示のように、この選択は、挿入表示６９１０の太い境界線６９６２として表示される。異なる実施形態は、挿入表示６９１０を強調表示することによって、挿入表示６９１０を振動させることによってなど、異なる仕方でこのような選択を示してもよい。

第３段階６９３０は、ユーザがＰＩＰ表示６９６５内のあるエリアからこのＰＩＰ表示６９６５内の別のエリアにＰＩＰ表示６９６５の挿入表示域６９１０を移動させ始めた後のＵＩ６９６０を示す。この例では、挿入表示域６９１０は、矢印６９５５によって示されるように、ＰＩＰ表示６９６５の右下隅からこの表示の左上隅に移動し始めている。挿入表示６９１０は、ユーザが挿入表示６９１を選択した後に自身の指６９５０をＰＩＰ表示６９６５の右上隅に向かってドラッグすることによって移動される。一部の実施形態は、ＰＩＰ表示６９６５において挿入表示６９１０を移動させるための他の技術を提供する。

第４段階６９３５は、ユーザが自身の指６９５０をデバイス６９００の画面から離した後の状態にあるＵＩ６９６０を示す。この状態では、挿入表示域６９１０は、第３段階におけるユーザの指の移動に基づいて識別されたＰＩＰ表示６９６５の右上隅に向かって依然として移動している。言い換えれば、指６９５０がＰＩＰ表示６９６５の右上隅に向かっての挿入表示６９１０の移動を開始した後、ＵＩ６９６０は、指６９５０が離れた後でさえもこの移動を維持する。この移動を維持するため、一部の実施形態のＵＩ６９６０は、ユーザが指を離す前に、ユーザのドラッグ動作が特定のしきい値量よりも大きい（例えば、特定の距離又は特定の時間の長さよりも大きい）ことを必要とする。そうでない場合に、これらの実施形態は、挿入表示域をやや移動させるか又はまったく移動させない後でこの挿入表示域をその元の右下隅位置に保つ。

しかし、一部の実施形態では、挿入表示域がその新たな位置に到達する前にユーザが自身のドラッグ動作を止めた後でさえも挿入表示域が移動できるが、他の実施形態では、挿入表示域がその新たな位置に到達するまで自身のドラッグ動作を維持するようにユーザに要求する。一部の実施形態は、挿入表示域を移動するためのさらに他の技術を提供する。例えば、一部の実施形態では、表示域６９１０が実際に移動始める前に表示域６９１０をどこに向けるべきかなどをユーザが指定することが必要とされてもよい。一部の実施形態は、携帯デバイスを異なる角度に傾斜させるだけで表示域がスライド可能であり、コーナー向けスナップされうる。

第５段階６９４０は、挿入表示域６９１０がＰＩＰ表示域６９６５の右上隅でその新たな位置に到達した後のＵＩ６９６０を示す。第５段階における太い境界線６９６２の除去は、コーナー向けスナップ動作が完了したことを示す。

上述の第３段階６９３０、第４段階６９３５及び第５段階６９４０に示されている移動を容易にするため、一部の実施形態のＵＩ６９６０は、ユーザが挿入表示域６９１０をＰＩＰ表示６９６５の隅に向かって移動させると挿入表示域６９１０がその隅にすばやくスナップされうるスナップルールを採用する。例えば、ユーザが特定の隅に向かってしきい値量を超えて挿入表示域６９１０をドラッグした場合に、一部の実施形態のＵＩ６９６０は、挿入表示６９１０の動きの方向を識別し、動きがしきい値量を超えたと判定し、その後、挿入表示６９１０がスナップされうるＵＩ６９６０内の次のグリッド点をユーザがさらに入力しなくても、挿入表示域６９１０を自動的に移動する。一部の実施形態では、挿入表示６９１０をスナップするために提供されるグリッド点のみが、ＰＩＰ表示６９６５の４つの隅におけるグリッド点である。他の実施形態は、ＵＩ６９６０において（例えば、ＰＩＰ表示６９６５において）、挿入表示６９１０をスナップできる他のグリッド点を提供する。

さらに他の実施形態は、挿入表示域６９１０をＰＩＰ表示の任意の点に配置できるように、グリッド点を採用しなくてもよい。さらに他の実施形態は、ユーザがＵＩのグリッド点機能へのスナップをオン又はオフにできる機能を提供する。さらに、異なる実施形態により、ユーザは、デバイスから取り込まれたビデオに加えて、アイコンなどの種々の項目に対してコーナー向けスナップ動作を実行できる。前述のように、合成表示の表示域（群）の移動によって、ユーザの入力に応答してテレビ会議マネージャ１６０４に合成表示で表示域を再合成させるなどの、デュアルカメラ携帯デバイスの画像処理動作への変更を引き起こすことができる。

５．プッシュアンドスナップ
図６９の例は、デュアルカメラ携帯デバイスのユーザが２つの挿入表示域のうちの１つを、ＰＩＰ表示のある隅から挿入表示によって占有されていない別の隅に移動できるコーナー向けスナップ動作を示す。一部の実施形態により、第１挿入を第２挿入の位置に移動し、また、第２挿入を新たな位置にプッシュするプッシュ機能が可能になる。図７０は、テレビ会議中に実行されるこのような一例を示す。

図７０は、ＰＩＰ表示のある隅からＰＩＰ表示の別の挿入表示によって占有された別の隅への挿入表示の移動を、このＵＩ６９６０の６つの異なる段階７０２０、７０２５、７０３０、７０３５、７０４０及び７０４５として示す。第１段階７０２０は、デバイスのローカルユーザとリモートデバイスのリモートユーザとの間のテレビ会議中のＵＩ６９６０を示す。図７０のＵＩ６９６０は、テレビ会議が始まった後の図６９の第１段階に示されているのと同じＰＩＰ表示であるＰＩＰ表示６９６５を示す。この例では、ローカルユーザのデバイスによって取り込まれたビデオが挿入表示域６９０５及び６９１０に表示され、リモートユーザのデバイスによって取り込まれたビデオが背景表示域６９１５に表示されている。

第２段階７０２５は、ユーザが挿入表示域６９０５を選択することによってコーナー向けスナップ動作を開始することを示す。この例では、挿入表示域６９０５内の任意の位置に指７０５５を置くことによって選択がなされる。図示のように、この選択は、挿入表示６９０５の太い境界線７０６５として表示される。異なる実施形態は、表示域６９０５を強調表示することによって、表示域６９０５を振動させることによってなど、異なる仕方でこのような選択を示してもよい。

第３段階７０３０は、矢印７０５０によって示されるように、（第３段階において挿入表示６９０５を選択した後にＰＩＰ表示６９６５の右下隅に向かって自身の指７０５５をドラッグすることによって）ユーザがＰＩＰ表示６９６５の左下隅からＰＩＰ表示６９６５の右下隅に挿入表示域６９０５を移動し始めた後のＵＩ６９６０を示す。一部の実施形態は、ＰＩＰ表示６９６５において挿入表示域６９０５を移動させるための他の技術を提供する。

第４段階７０３５は、挿入表示域６９０５が挿入表示域６９１０と接触した後のＵＩ６９６０を示す。接触すると、挿入表示域６９１０は、次の最も近い隅に向かって移動する。この例では、挿入表示域６９１０は、（矢印７０７５によって示される）ＰＩＰ表示６９６５の右上隅の方向に移動し始める。このプッシュ動作の起動は、挿入表示域６９１０の太い境界線７０７０として表示される。異なる実施形態は、表示６９１０を強調表示することによってなどの異なる仕方でこのような起動を示してもよい。

第５段階７０４０は、以前は挿入表示域６９１０によって占有されていた右下隅に挿入表示域６９０５がスナップした後の状態にあるＵＩを示す。この状態では、挿入表示域は、ＰＩＰ表示６９６５の右上隅に向かってなおも移動している。また、太い境界線７０６５は、もはや表示されない。第３段階７０３０からのユーザのドラッグ動作が、挿入表示域６９０５を右隅にスナップさせるしきい値よりも大きい限り、挿入表示域６９１０はその隅から除去され、次に近い隅までわざわざスナップする。

一部の実施形態は、どの方向に第２挿入表示域６９１０をプッシュするべきかを判定するためのルールの集合を含む。図７０に示されるケースでは、一部の実施形態は、挿入表示域の回転を継続しようとする。すなわち、表示域６９０５が反時計回り方向に移動されるので、表示域６９１０も反時計回りに移動される。一部の実施形態は、プッシュされた挿入表示域６９１０が移動してリスト上の占有されていない最初の位置を選択できる取りうる位置の階層を提供する。例えば、右下の挿入表示域が、左下から来た挿入表示域によってプッシュされる場合に、右上隅は、このようなリストの最初の位置でありうる。しかし、第３挿入表示域が右上隅に既に存在しているならば、一部の実施形態は、リスト上の次のオプション（例えば、左上隅、中央、又は左下隅）に移動するだろう。他の実施形態は、第２挿入表示域で第３挿入表示域をプッシュし、その結果、デバイスは第３挿入表示域のための新たな位置を決定する必要がある。

第６段階７０４５は、挿入表示域６９１０がＰＩＰ表示域６９６５の右上隅でその新たな位置に到達した後のＵＩ６９６０を示す。この段階における太い境界線７０７０の除去は、コーナー向けスナップアンドプッシュ動作が完了したことを示す。図６８に関して説明したコーナー向けプッシュ動作と同様に、合成表示の表示域（群）の移動によって、ユーザの入力に応答してテレビ会議マネージャ１６０４に合成表示における表示域を再合成させるなどの、デュアルカメラ携帯デバイスの画像処理動作への変更を引き起こすことができる。

６．回転
一部の実施形態は、テレビ会議に使用される携帯デバイスのユーザが会議中にデバイスを回転した場合に、テレビ会議中に提示されるＰＩＰ表示を回転する。図７１は、デバイスが垂直位置から水平位置に回転した場合のデバイス７１００のＵＩ表示７１７５の回転を示す。画面の長辺が垂直である場合にデバイス７１００は垂直に保持されているが、画面の長辺が水平である場合にデバイス７１００は水平に保持されている。図７１に示される例では、ＵＩ表示７１７５は、デバイスの垂直保持に最適化された縦ビューからデバイス７１００の水平保持に最適化された横ビューに回転する。この回転機能によって、携帯デバイス７１００が垂直又は水平のどちらかに保持されている場合にユーザは直立位置に表示されたＵＩ７１７５を見ることができる。図７１に示されるこの例は、図７１が、１つの挿入表示域のみではなく２つの挿入表示域を含むＰＩＰ表示を回転することを示すことを除いて、図３４に示される例と同様である。

図７１では、携帯デバイス７１００のＵＩ７１７５は、別の携帯デバイスのリモートユーザとのテレビ会議中にＰＩＰ表示７１８０を提示する。図７１のＰＩＰ表示７１８０は、３つのビデオ表示、すなわち背景メイン表示７１１５と、２つの前景挿入表示７１１０及び７１６０とを含む。この例では、背景メイン表示７１１５は、山のビデオを提示し、これは、リモートデバイスの前面カメラ又は背面カメラによって取り込まれたビデオであると想定される。前面挿入表示７１１０は、部屋にいる笑顔のビデオを提示し、これは、ローカルデバイスの前面カメラ又は背面カメラによって取り込まれたものと想定される。他方の前景挿入表示７１６０は、歌っているギター奏者のビデオを表示し、これは、ローカルデバイスの他方のカメラによってビデオが取り込まれているギター奏者であると想定される。ＰＩＰ表示７１８０の下は、ユーザがテレビ会議を終了するために（例えば、シングルフィンガータップを通じて）選択してもよい会議終了ボタン７１５５である。このＰＩＰ表示は、リモートデバイス及びローカルデバイスによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、タイル表示されたビュー又は異なるＰＩＰ表示などの、他の合成ビューを提供してもよい。

図７１は、ＵＩ７１７５の回転を、６つの異なる動作段階７１２０、７１２５、７１３０、７１３５、７１４０及び７１４５として示す。第１段階７１２０は、デバイスのローカルユーザとリモートデバイスのリモートユーザとの間のテレビ会議中のＵＩ７１７５を示す。

第２段階７１２５は、ユーザがデバイス７１００を横に傾斜させ始めた後のＵＩ７１７５を示す。この例では、デバイス７１００は、矢印７１８５によって示されるように、デバイス７１００を垂直に保持されている状態から水平に保持されている状態に傾斜させ始めている。ＵＩ７１７５の外見は変化していない。他の状況では、ユーザが、デバイス７１００を水平に保持されている状態から垂直に保持されている状態に傾斜させたいと考えてもよく、これらの状況では、ＵＩ表示７１７５は、水平に最適化されたビューから垂直に最適化されたビューに切り換わる。

第３段階７１３０は、デバイス７１００が垂直に保持されている状態から水平に保持されている状態に傾斜された後の状態のＵＩ７１７５を示す。この状態では、ＵＩ表示７１７５の外見はまだ変化しない。一部の実施形態では、デバイス７１００がしきい値量を過ぎて傾斜され、この点を超えて、ある期間保たれた後で、回転動作がトリガされる。図７１に示される例では、デバイスが水平位置に置かれた後、ある短期間の間隔が経過するまで、しきい値量及び回転の速度によってＵＩ表示７１７５が回転しないと想定されている。他の実施形態は、回転動作をトリガするしきい値量及び待ち期間が異なる。例えば、一部の実施形態は、デバイス７１００の向きとは関係なくＵＩ７１７５が常に直立位置に表示されるように見えるようにするために、回転動作をトリガするための低いしきい値を有しうる。他の実施形態では、デバイス７１００のユーザは、（例えば、メニュー基本設定を通じて）いつ回転動作がトリガされうるかを指定してもよい。また、一部の実施形態は、デバイスがしきい値量を超えて傾斜された後の回転を遅延させなくてもよい。さらに、異なる実施形態を使用することによって、携帯デバイス上のスイッチを切り換えることによって、音声オーディオコマンドを与えることによって、メニューによる選択に応じてなどの、異なる仕方で、回転動作をトリガすることが可能になってもよい。

第４段階７１３５は、回転動作が開始した後のＵＩ７１７５を示す。一部の実施形態は、回転動作に関するフィードバックをユーザに提供するために、回転表示域をアニメーション化する。図７１は、このようなアニメーションの一例を示す。具体的には、図７１は、その第４段階７１３５に、表示域７１１０、７１１５及び７１６０が一緒に回転し始めるところを示している。表示域７１１０、７１１５及び７１６０は、ＵＩ表示７１７５の中央を通る軸７１６５（すなわち、ｚ軸）のまわりを回転する。表示域７１１０、７１１５及び７１６０は、（例えば、デバイス７１００の傾斜を通じた）デバイス７１００の回転の反対方向に同じ量だけ回転する。この例では、デバイス７１００が（垂直に保持される状態から水平に保持される状態に移ることによって）時計回り方向に９０度回転したので、この回転動作によって、表示域７１１０、７１１５及び７１６０が反時計回りに９０度回転される。表示域７１１０、７１１５及び７１６０が回転すると、表示域７１１０、７１１５及び７１６０が依然としてＵＩ７１７５上で全体的に見えるように、表示域７１１０、７１１５及び７１６０はＵＩ表示７１７５に合うように比例して縮む。一部の実施形態は、このデバイス７１００の状態を示すメッセージを（例えば、「回転中」という単語を表示することによって）提供してもよい。

第５段階７１４０は、表示域７１１０、７１１５及び７１６０が縦ビューから横ビューに反時計回りに９０度回転した後のＵＩ７１７５が示されている。この段階では、表示域７１１０、７１１５及び７１６０は回転されているが、まだＵＩ７１７５の幅全体に拡張されていない。矢印７１７０は、第５段階の終了時に、表示域７１１０、７１１５及び７１６０がＵＩ７１７５の幅全体に合うように側方に拡張し始めることを示す。拡張は第４段階７１３５での回転と同時に実行できるので、異なる実施形態はこの段階を含まなくてもよい。

第６段階７１４５は、表示域７１１０、７１１５及び７１６０がＵＩ７１７５の表示全体を占有するように拡張された後のＵＩ７１７５を示す。上述のように、他の実施形態は、この回転を異なるように実施してもよい。一部の実施形態では、しきい値量を超えてデバイスの画面を回転するだけで、デバイス７１００の向きに関係なく、回転動作をトリガしてもよい。

また、他の実施形態は、回転動作を示すための異なるアニメーションを提供してもよい。図７１に実行される回転動作は、ＵＩ表示７１７５がＵＩ表示７１７５の中心のまわりを回転することを含む。あるいは、表示域は、これらの個別の表示域の中心軸のまわりを個別に回転してもよい。このような１つの手法が図７２に示され、図７２はＵＩ７１７５のＰＩＰ表示域７１８０の回転をアニメーション化する代替方法を示す。図７２に示されるＰＩＰ表示は、図７１に示されるのと同じＰＩＰ表示７１８０である。

図７２は、ＰＩＰ表示７１８０を、６つの異なる動作段階７１２０、７１２５、７１３０、７２２０、７２２５及び７２３０として示す。ＵＩ７１７５の動作の前半の３つの段階は、図７１のＵＩ７１７５に関して説明した動作の前半の３つの段階と同一である。図７１と図７２の両方に対する第３段階では、デバイスは、垂直に保持された状態から水平に保持された状態に移っており、ＵＩ７１７５の回転はまだ開始していない。

第４段階７２２０は、回転をアニメーション化する代替方法を示す。この段階で、回転動作が開始している。具体的には、第４段階７２２０は、表示域７１１０、７１１５及び７１６０が回転し始めるところを示している。表示域７１１０、７１１５及び７１６０は、表示域のそれぞれの中心を通る軸７２５０（すなわち、ｚ軸）のまわりをそれぞれ回転する。表示域７１１０、７１１５及び７１６０は、（例えば、デバイス７１００の傾斜による）デバイス７１００の回転の反対方向に同じ量だけ回転する。この例では、デバイス７１００が（垂直に保持される状態から水平に保持される状態に移ることによって）時計回り方向に９０度回転したので、この回転動作によって、表示域７１１０、７１１５及び７１６０が反時計回り方向に９０度回転する。表示域７１１０、７１１５及び７１６０が回転すると、表示域７１１０、７１１５及び７１６０が依然としてＵＩ７１７５上で全体的に見えるように、これらはまたＵＩ表示７１７５に合うように比例して縮む。

第５段階７２２５は、表示域７１１０、７１１５及び７１６０が縦ビューから横ビューに反時計回りに９０度回転した後のＵＩ７１７５を示す。この段階で、表示域７１１０、７１１５及び７１６０は回転されているが、まだＵＩ７１７５の幅全体に拡張されていないか、それらの最終位置に到達してもいない。ＰＩＰ表示７１１５内の表示域の最終位置は、第１段階７１２０に示されるＰＩＰ表示内の表示域の位置（例えば、ＰＩＰ表示７１８０の左下隅にある挿入表示域７１１０及び右下隅にある挿入表示域７１６０）によって決定される。

矢印７１７０は、第５段階の終了時に、メイン表示域７１１５がＵＩ７１７５の幅全体に合うまで、表示域７１１０、７１１５及び７１６０が側方に拡張し始めることを示す。さらに、矢印７２５５は、挿入表示域７１１０及び７１６０が移動してＰＩＰ表示７１８０の最終位置に到達することを示す。言い換えれば、挿入表示域７１１０は、ＰＩＰ表示７１８０の左下隅に向かって下方に移動し、他方の挿入表示域７１６０は、ＰＩＰ表示７１８０の右下隅に移動する。異なる実施形態は、例えば図７１に示されるスナップアンドプッシュ動作を使用することによって、このアニメーションを異なるように実行してもよい。第６段階７２３０は、表示域７１１０、７１１５及び７１６０がＵＩ７１７５の最終表示全体を占有するように拡張され、それらの最終位置に到達した後のＵＩ１１０を示す。

上述のように、他の実施形態は、この回転を異なるように実施してもよい。例えば、図３６及び図３７に同様に示されるように、一部の実施形態は、回転動作がローカルデバイスに対して実行された後のローカルデバイスの向きを反映するように、ローカルデバイスによって取り込まれたビデオを表示する表示域の向きが変化する回転動作を提供し、一部の実施形態は、回転動作がリモートデバイスに対して実行された後のリモートデバイスの向きを反映するように、リモートデバイスによって取り込まれたビデオを表示する表示域の向きが変化する回転動作を提供し、一部の実施形態は、表示域１１５５が同じ位置にあるままである回転動作を提供し、一部の実施形態は、表示域（例えば、図１２の表示域１１５５のレイアウト）における異なるレイアウト、又はこれらの組み合わせを提供する。

一部の実施形態では、しきい値量を超えてデバイスの画面を回転するだけで、デバイス７１００の向きに関係なく、回転動作をトリガしてもよい。また、上述したように、ローカルデバイス及びリモートデバイスは、回転動作がデバイスのうちの一方に対して実行されたことを制御通信チャネルを通じて互いに通知し、他方のデバイスが、この一方のデバイスのビデオに対する対応するいかなる変更も実行できるようにする。また、回転動作のアニメーションによって、テレビ会議マネージャ１６０４にＵＩ１１０５において異なる角度で表示域（群）を再合成させ、表示域（群）に表示される画像を拡大縮小させるなどの、カメラの動作又はデュアルカメラデバイスの画像処理動作の変更を引き起こすことができる。

７．視聴するリモートビューの選択
上述のように、一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、どのカメラをテレビ会議に使用するべきかをテレビ会議の開始前又はテレビ会議の開始時に選択できる。この機能の代わりに、又はこれと共に、一部の実施形態により、デバイスのユーザは、テレビ会議で表示されている２つのビデオであって、リモートデバイスの２つのビデオカメラからものであるか、ユーザのローカルデバイスの２つのビデオカメラからのものである２つのビデオの中から選択可能になる。図７３は、２つのリモートビデオからの１つのビデオの会議中の選択を示し、図７４は、２つのローカルビデオからの１つのビデオの会議中の選択を示す。

図７３は、リモートビデオの選択を、ローカルデバイス７３００に表示されるＵＩ７３７５の６つの動作段階７３３５、７３４０、７３４５、７３５０、７３５５及び７３６０として示す。第１段階７３３５は、２つのカメラを有する携帯デバイスのリモートユーザとのテレビ会議中に提示されている初期ＰＩＰ表示７３９０を有するＵＩ７３７５を示す。

第１段階７３３５に示すように、初期ＰＩＰ表示７３９０は、３つの表示、すなわち背景メイン表示７３１５と、２つの前景挿入表示７３０５及び７３１０とを含む。背景表示７３１５はＰＩＰ表示７３９０の大半を占めるが、前景挿入表示７３０５及び７３１０はＵＩ７３７５上の背景表示７３１５の一部分に重なる。この例では、背景表示７３１５は、マイクロフォンの前にいる人のビデオを提示し、これは、リモートデバイスの背面カメラによって取り込まれたビデオであると想定される。第１前面挿入表示７３０５は、男性の顔のビデオを提示し、これは、この例では、ローカルデバイス７３００のカメラの一方によって取り込まれたビデオであると想定される。第２前面挿入表示７３１０は、帽子を被った人のビデオを提示し、これは、この例では、リモートデバイスの前面カメラによって取り込まれたビデオであると想定される。

初期ＰＩＰ表示７３９０は、ローカルデバイス及びリモートデバイスのカメラによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、他の合成ビューを提供してもよい。例えば、背景表示は、ローカルデバイスのカメラの一方からのビデオを提示してもよく、小さい方の前景挿入表示は、リモートデバイスの前面カメラ及び背面カメラからのビデオを提示してもよい。また、一部の場合で、ＰＩＰ表示は、１つの背景ビデオ表示と、１つの前景ビデオ表示とをのみ含み、これらの両方は、リモートデバイスから来る。一部の実施形態では、ＰＩＰ表示の方式又はデフォルトの表示モードは、ユーザによって指定されてもよい。

第２段階７３４０は、ビデオ選択動作の開始を示す。この例では、この動作は、ＰＩＰ表示７３９０に表示されるべき選択可能ＵＩ項目の集合を起動することによって始められる。選択可能ＵＩ項目の集合は、表示用のリモートビデオを選択するためのオプションを提示する。一部の実施形態では、選択可能ＵＩ項目の集合は、ＵＩ７３７５上でリモートビデオを再生している任意の表示域を選択することによって（例えば、タッチすることによって）起動されうる。他の実施形態では、項目は、ＵＩ７３７５上の任意の位置を選択することによって（例えば、タッチすることによって）起動されうる。このような起動動作の代わりに、又はこれと共に、一部の実施形態により、ユーザは、異なるタッチスクリーン動作を通じて、又はデバイスの１つ以上の他の物理的入力を使用するなどの、他の動作を通じて選択可能ＵＩ項目の集合を起動することもできる。

第３段階７３４５は、リモートビデオを選択するための選択可能ＵＩ項目７３８０の起動された集合を有するＵＩ７３７５を表示する。この例では、ポップアップメニューの形をとる選択可能ＵＩ項目７３８０の集合は、ＰＩＰ表示域７３９０に表示され、ＰＩＰ表示に重なる。（選択可能なボタンとして実装できる）選択可能ＵＩ項目７３８０の集合は、「Ｒ１を選択」選択可能ＵＩ項目７３２０（例えばボタン７３２０）と、「Ｒ２を選択」選択可能ＵＩ項目７３２５（例えばボタン７３２５）と、「両方を選択」選択可能ＵＩ項目７３３０（例えばボタン７３３０）と、「キャンセル」選択可能ＵＩ項目７３８５（例えばボタン７３８５）とを含む。この例では、「Ｒ１を選択」ボタン７３２０を選択することによって、ＵＩ７３７５は、（背景表示７３１５に提示されている）リモートデバイスの背面カメラによって取り込まれたビデオのみを表示する。「Ｒ２を選択」ボタン７３２５を選択することによって、ＵＩ７３７５は、（前景挿入表示７３１０に提示されている）リモートデバイスの前面カメラによって取り込まれたビデオのみを表示する。「両方を選択」ボタン７３３０を選択することによって、ＵＩ７３７５は、リモートデバイスの前面カメラ及び背面カメラによって取り込まれた両方のビデオを表示し続ける。「キャンセル」ボタン７３８５を選択することによって動作がキャンセルされる。一部の実施形態では、ローカルデバイスによって取り込まれたビデオは、このメニューでなされた選択による影響を受けない。

第４段階７３５０は、ユーザが（例えば、自身の指７３６５でボタン７３２０をタップすることによって）「Ｒ１を選択」ボタン７３２０を選択した後のＵＩ７３７５を示す。この選択は、ＵＩ７３７５上でのボタン７３２０の強調表示によって示される。一部の実施形態は、異なる標識表示（例えば、選択された項目の境界線又は選択された項目のテキストの強調表示）を使用する。

第５段階７３５５は、ユーザが表示のためにＲ１からビデオを選択した後のＵＩ７３７５のアニメーションを示す。この例では、ＵＩ７３７５は、望まれない前景挿入表示域７３１０を、矢印７３７０によって示されるようなＰＩＰ表示７３９０の右端から外へスライドすることによって除去する。他の実施形態は、挿入をフェードアウト又はフェードオーバーする、挿入を異なる方向に移動する、又は単に挿入を瞬時に除去するなど、望まれない挿入表示域を除去するために異なるアニメーションを利用する。

第６段階７３６０は、ビデオ選択動作が完了した後のテレビ会議中のＵＩ７３７５を表示する。ビデオ表示域７３１０はもはやＵＩ７３７５に表示されていない。この段階で、ＵＩ７３７５は、ビデオ表示域７３１５を背景メイン表示として含み、ビデオ表示域７３０５を挿入表示として含む新たなＰＩＰ表示７３９５を提示する。

また、一部の実施形態では、このビデオ選択動作によって、選択されたビデオのみをリモートデバイスに表示させるが、他の実施形態では、この動作は、リモートデバイスに何ら影響を及ぼさない。一部の実施形態では、このビデオ選択動作によって、リモートデバイスは、望まれないビデオをローカルデバイスに伝送するのを止める。実際に、一部の実施形態において、このビデオ選択動作により、リモートデバイスのカメラは、望まれないビデオを取り込むのを止める。一部の実施形態では、リモートデバイスに対するこれらの影響は、リモートデバイスのユーザによって無効にされうる。

上記の例は、選択されたリモートビューが、背景メイン表示に既に表示されているビューであるケースを示す。一部の実施形態では、ユーザが挿入表示のうちの１つに表示されているリモートビューを選択した場合に、選択されたリモートビューは、背景メイン表示に表示される。一部のこのような実施形態は、このケースでは、図６８に表示されているアニメーションのようなアニメーションを使用する。さらに、リモートビデオ（群）を選択することによって、ユーザ入力に応答してテレビ会議マネージャ１６０４に、合成表示において、選択されたリモートビデオ（群）のみを合成させるなどの、デュアルカメラ携帯デバイスの画像処理動作の変更を引き起こすことができる。

８．視聴するローカルビューの選択
図７４は、ローカルビデオの選択を、ローカルデバイス７４００に表示されるＵＩ７４７５の６つの動作段階７４３５、７４４０、７４４５、７４５０、７４５５及び７４６０として示す。第１段階７４３５は、少なくとも１つのカメラを有する携帯デバイスのリモートユーザとのテレビ会議中に提示されている初期ＰＩＰ表示７４９０を有するＵＩ７４７５を示す。ＰＩＰ表示７４９０は、図７３とは異なり、背景表示７４１５がリモートデバイスのカメラによって取り込まれた男性のビデオを提示し、左の前景挿入表示７４１０がローカル携帯デバイスの背面カメラによって取り込まれたギターを持つ人のビデオを提示し、右の前景挿入表示７４０５がローカル携帯デバイス７４００の前面カメラによって取り込まれた帽子を被った男性のビデオを提示することを除いて、図７３の第１段階と同様である。したがって、１つのリモートビデオのみが表示され、２つのローカルビデオが表示される。

第２段階７４４０は、ビデオ選択動作の開始を示す。この例では、この動作は、表示用のリモートビデオを選択するためにＰＩＰ表示７４９０に表示されるべき選択可能ＵＩ項目の集合を起動することによって始められる。一部の実施形態では、選択可能ＵＩ項目の集合は、ＵＩ表示７４７５上でローカルビデオを再生している任意の表示域を選択することによって（例えば、タッチすることによって）起動されうる。他の実施形態では、項目は、ＵＩ表示７４７５上の任意の位置を選択することによって（例えば、タッチすることによって）起動されうる。このような起動動作の代わりに、又はこれと共に、一部の実施形態により、ユーザは、異なるタッチスクリーン動作によって、又はデバイスの１つ以上の他の物理的入力を使用するなどの、他の動作を通じて選択可能ＵＩ項目の集合を起動することもできる。

第３段階７４４５は、ローカルビデオを選択するための選択可能ＵＩ項目７４８０の起動された集合を有するＵＩ７４７５を表示する。この例では、ポップアップメニューの形をとる選択可能ＵＩ項目７４８０の集合は、ＰＩＰ表示に重なるＰＩＰ表示域７４９０に表示される。選択可能ＵＩ項目７４８０の集合は、「Ｌ１を選択」選択可能ＵＩ項目７４２０（例えばボタン７４２０）と、「Ｌ２を選択」選択可能ＵＩ項目７４２５（例えばボタン７４２５）と、「両方を選択」選択可能ＵＩ項目７４３０（例えばボタン７４３０）と、動作をキャンセルするための「キャンセル」選択可能ＵＩ項目７４８５（例えばボタン７４８５）とを含む。この例では、「Ｌ１を選択」ボタン７４２０を選択することによって、ＵＩ７４７５は、（前景挿入表示７４１０に提示されている）ローカルデバイスの背面カメラによって取り込まれたビデオのみを表示する。「Ｌ２を選択」ボタン７４２５を選択することによって、ＵＩ７４７５は、（前景挿入表示７４０５に提示されている）ローカルデバイスの前面カメラによって取り込まれたビデオのみを表示する。「両方を選択」ボタン７４３０を選択することによって、ＵＩ７４７５は、ローカルデバイス上の両方のカメラによって取り込まれた両方のビデオを表示し続け、「キャンセル」ボタン７４８５を選択することによって、動作がキャンセルされる。一部の実施形態では、リモートデバイスによって取り込まれたビデオは、このメニューを通じてなされた選択による影響を受けない。

第４段階７４５０は、ユーザが（例えば、自身の指７４６５でボタン７４２５をタップすることによって）「Ｌ２を選択」ボタン７４２５を選択した後のＵＩ７４７５を示す。この選択は、ＵＩ表示７４７５上でのボタン７４２５の強調表示によって示される。一部の実施形態は、異なる標識表示（例えば、選択された項目の境界線又は選択された項目のテキストの強調表示）を使用する。

第５段階７４５５は、ユーザが表示のためにＬ２からビデオを選択した後のＵＩ７４７５のアニメーションを表示する。この例では、ＵＩ７４７５は、望まれない前景挿入表示７４１０を、矢印７４７０によって示されるＰＩＰ表示７４９０の左端から外へスライドすることによって除去する。他の実施形態は、挿入をフェードアウト又はフェードオーバーする、挿入を異なる方向に移動する、又は単に挿入を瞬時に除去するなど、望まれない挿入表示域を除去するために異なるアニメーションを利用する。

第６段階は、ビデオ選択動作が完了した後のテレビ会議中のＵＩ７４７５を表示する。ビデオ表示域７４１０は、もはやＵＩ７４２５上にない。この段階で、ＵＩ７４７５は、リモートビデオ表示７４１５を背景メイン表示として含み、ローカルビデオ表示７４０５を挿入表示として含む新たなＰＩＰ表示７４９５を提示する。一部の実施形態では、両方のビデオ取り込みは依然としてリモートデバイスに伝送されているので、このビデオ選択動作は、ローカル表示にのみ影響を及ぼす。他の実施形態は、除去されたカメラからの取り込みを止める。

上記の例は、選択されたローカルビューが、背景メイン表示に既に表示されているビューであるケースを示す。一部の実施形態では、ユーザが挿入表示のうちの１つに表示されているローカルビューを選択した場合に、選択されたローカルビューは、メイン背景表示に表示される。一部のこのような実施形態は、この場合、図６８に表示されているアニメーションのようなアニメーションを使用する。他の実施形態は、背景メイン表示内のローカルビューが除去された場合に、挿入リモートビューを使用する。

図７３に関して上述したリモートビュー選択動作と同様に、ローカルのビデオ（群）を選択することによって、ユーザの入力に応答してテレビ会議マネージャ１６０４に合成表示において、選択されたリモートビデオ（群）のみを合成させるなどの、ローカルデュアルカメラ携帯デバイスの画像処理動作への変更を引き起こすことができる。ローカルのビデオ（群）を選択することによって、ローカルデバイスのカメラ（群）の動作に変更を引き起こすこともできる。例えば、一部の実施形態により、選択されていないビデオのカメラは、望まれないビデオをリモートデバイスに伝送するのを止めるが、他の実施形態により、カメラは、望まれないビデオを取り込むのを止める。

９．伝送するべきローカルビューの選択
上記のサブセクションは、ビデオ表示の会議中の変更を示す。一部の実施形態により、デュアルカメラ携帯デバイスのユーザは、どのカメラをテレビ会議に使用するべきかをテレビ会議の開始前に選択することもできる。図７５は、テレビ会議に使用するためにユーザのデュアルカメラ携帯デバイスによって取り込まれた２つのビデオからの１つのビデオの会議前の選択を示す。

図７５は、テレビ会議に使用するためのローカルビデオの選択を、ＵＩ７５００の８つの動作段階として示す。第１段階７５０２は、ユーザが携帯デバイスのリモートユーザとのテレビ会議を開始するように要求した後に提示されている初期ＰＩＰ表示７５４２を有するデュアルカメラ携帯デバイス７５１８のＵＩ７５００を示す。

第１段階７５０２に示すように、初期ＰＩＰ表示７５４２は、２つの表示、すなわち背景メイン表示７５２０と、前景挿入表示７５２２とを含む。背景メイン表示７５２０はデバイスの表示画面の大半を占めるが、前景挿入表示７５２２は背景メイン表示よりも小さく、これに重なる。この例では、背景表示７５２０はギターを持っている人のビデオを提示し、これは、デバイスの背面カメラによって取り込まれたビデオであると想定される。前景挿入表示７５２２は帽子を被った人のビデオを提示し、これは、この例では、デバイスの前面カメラによって取り込まれているビデオであると想定される。

この初期ＰＩＰ表示７５４２は、ローカルデバイスのカメラによって取り込まれているビデオの合成ビューを提示する１つの方式にすぎない。一部の実施形態は、他の合成ビューを提供してもよい。例えば、背景表示は、デバイスの前面カメラからのビデオを提示してもよく、小さい方の前景挿入表示は、デバイスの背面カメラからのビデオを提示してもよい。同様に、一部の実施形態により、２つのビデオは、ＵＩ７５００内の並んだ２つの表示域（例えば、左右の表示ウィンドウ、又は上下の表示ウィンドウ）又は斜めに整列した２つの表示域に表示されうる。一部の実施形態では、ＰＩＰ表示の方式又はデフォルトの表示モードは、ユーザによって指定されうる。ＰＩＰ表示の下は、項目を選択することによってユーザがテレビ会議を終了できる「会議終了」と標示された選択可能ＵＩ項目７５４０（例えばボタン７５４０）である。

第１段階７５０２では、携帯デバイス７５１８のユーザは、リモートユーザとのテレビ会議を行うように要求し、リモートユーザが応答するのを待っている。この待ち期間は、表示の下部の「プレビュー、応答を待っています．．．」表記によって説明される。

第２段階７５０４は、ビデオ選択動作の開始を示す。この例では、動作は、ＰＩＰ表示７５４２に表示されるべき選択可能ＵＩ項目の集合を起動することによって始められる。選択可能ＵＩ項目の集合は、テレビ会議のためにリモートデバイスに伝送するローカルビデオを選択するためのオプションを提示する。一部の実施形態では、選択可能ＵＩ項目の集合は、リモートユーザが応答するのを待っている間の会議前の時間中にＵＩ表示７５００上の任意の位置を選択する（例えば、タッチする）によって起動されうる。このような起動動作の代わりに、又はこれと共に、一部の実施形態により、ユーザは、異なるタッチスクリーン動作を通じて、又はデバイスの１つ以上の他の物理的入力を使用するなどの、他の動作によって選択可能ＵＩ項目を起動することもできる。

第３段階７５０６は、ユーザがビデオを選択するための選択可能ＵＩ項目７５２６の起動された集合を有するＵＩ７５００を示す。この例では、ポップアップメニューの形をとる選択可能ＵＩ項目７５２６の集合は、ＰＩＰ表示域７５４２に表示され、ＰＩＰ表示に重なる。この例では、選択可能ＵＩ項目の集合は、「Ｌ１の伝送」項目７５２８（例えばボタン７５２８）と、「Ｌ２の伝送」項目７５３０（例えばボタン７５３０）と、「両方の伝送」項目７５３２（例えばボタン７５３２）と、「キャンセル」項目７５３４（例えばボタン７５３４）とを含む。この例では、「Ｌ１の伝送」ボタン７５２８を選択することによって、ＵＩ７５００が、デバイスの背面カメラによって取り込まれたビデオのみをテレビ会議中にリモートデバイスに伝送する。「Ｌ２の伝送」ボタン７５３０を選択することによって、ＵＩ７５００は、デバイスの前面カメラによって取り込まれたビデオのみをテレビ会議中にリモートデバイスに伝送する。「両方の伝送」ボタン７５３２を選択することによって、ＵＩ７５００は、デバイスの前面カメラ及び背面カメラによって取り込まれた両方のビデオをテレビ会議のためにリモートユーザに伝送し、「キャンセル」ボタン７５３４を選択することによって、動作がキャンセルされる。

第４段階７５０８は、ユーザが（例えば、自身の指７５２４でボタン７５２８をタップすることによって）「Ｌ１の伝送」ボタン７５２８を選択した後のＵＩ７５００を示す。この選択は、ＰＩＰ表示域７５４２上でのボタン７５２８の強調表示によって示される。一部の実施形態は、異なる標識表示（例えば、選択された項目の境界線又は選択された項目のテキストの強調表示）を使用する。

第５段階７５１０は、ユーザがリモートデバイスに伝送するためにデバイスの背面カメラからのビデオを選択した後のＵＩ７５００のアニメーションを示す。この例では、ＵＩ７５００は、望まれない前景挿入表示７５２２を、矢印７５３６によって示されるＰＩＰ表示７５４２の右端から外へスライドすることによって除去する。第６段階７５１２では、挿入表示７５２２は、ＰＩＰ表示域７５４２から完全に除去されている。異なる実施形態は、表示域をフェードアウト又はフェードオーバーする、表示域を異なる方向に移動する、又は単に表示域を瞬時に除去するなど、望まれない表示域を除去するために異なるアニメーションを使用する。

第７段階７５１４は、リモートユーザがテレビ会議要求を承諾した後のＵＩ７５００のアニメーションを示す。テレビ会議要求の承諾は、表示上での「プレビュー、応答を待っています．．．」表記の除去によって強調表示される。この段階で、矢印７５３８によって示されるように、デバイスの背面カメラからのビデオである背景表示域７５２０のサイズは、ＰＩＰ表示域７５４２の左下隅に向けて段階的に減少する。ＵＩ７５００がリモートユーザのカメラからのビデオを含む表示域７５４４を表示域７５２０の後ろに示すことができるように、背景表示７５２０は縮む。一部の実施形態は、ローカルのカメラを異なる位置に合わせて縮め、表示されている２つのビデオのタイル表示された合成表示を使用するか、又はリモートビューをＰＩＰ表示の挿入表示域にする。

第８段階７５１６は、ビデオ選択動作が完了した後のＵＩ７５００を示す。ＵＩ７５００は、ローカルデバイスから取り込まれたビデオの挿入表示７５２０とリモートデバイスから伝送されたビデオの背景表示７５４４とを含む新たなＰＩＰ表示７５４６を提示する。

Ｂ．帯域幅及びフレームレート
一部の実施形態では、テレビ会議中のリモート携帯デバイスの表示域のサイズの調整によって、ローカル携帯デバイスが、ローカル携帯デバイスの２つのカメラ（すなわち、前面カメラ及び背面カメラ）によって取り込まれた各ビデオに割り当てられた帯域幅を再割り当てできる。図７６は、ローカルデバイスの２つのカメラ間でこのような帯域幅の再割り当てを行う２つの例を示す。

図７６の例のそれぞれは、ローカルデバイスの背面カメラセンサ７６０５と、ローカルデバイスの前面カメラセンサ７６１０と、ローカルデバイスのテレビ会議モジュール７６１５と、リモート携帯デバイス７６２０のＵＩ７６３５とを含む。背面カメラセンサ７６０５及び前面カメラセンサ７６１０は、ローカルデバイスの背面カメラ及び前面カメラそれぞれからビデオを取り込む。取り込まれたビデオはテレビ会議モジュール７６１５に送信され、テレビ会議モジュール７６１５はこのビデオを処理して、ＵＩ７６３５に表示するためにリモートデバイスに伝送する。

図７６では、リモートデバイスのＵＩ７６３５は、合成表示を提示する。合成表示は、ローカルデバイスの前面カメラ及び背面カメラによって取り込まれたビデオを示す。前面カメラからのビデオは、木及び帽子を被った男性を取り込み、背面カメラからのビデオは、山の風景を取り込む。図７６に示されるように、２つのビデオは、ビデオを表示するための表示域の構成に基づいて、さらには表示域のサイズにも基づいて、多くの異なる方式でＵＩ７６３５に表示されうる。各例では、テレビ会議モジュール７６１５は、最初に、リモートデバイスにおける表示域の相対サイズに従ってビデオのそれぞれに全出力帯域幅を割り当てる。具体的には、ＵＩ７６３５の大きい方の表示域に表示されるビデオは、全帯域幅のより大きな部分を割り当てられ、ＵＩ７６３５の小さい方の表示域に表示されるビデオは、帯域幅のより小さな部分を割り当てられる。一部の実施形態では、ビデオが同じサイズの表示域に表示される場合に、全出力帯域幅は、２つのビデオに均等に割り当てられる。

２つのビデオのそれぞれに割り当てられる帯域幅の量は、各ビデオが処理される方式に影響を及ぼすことがある。例えば、ビデオが、そのビデオに割り当てられたものより高い帯域幅を必要しうる。このような場合、低い帯域幅に対応するために、ビデオのフレームレートを調整するか、又はビデオの画像のサイズを縮小する。ビデオのフレームレートを低減することによって、ビデオが「途切れる」ように見えるが、ビデオの画像のサイズを縮小すると、ビデオが表示されるエリアも低減される。したがって、ビデオが帯域幅のある量を割り当てられた場合に、一部の実施形態は、割り当てられた帯域幅内でビデオが伝送されるようにするために、ビデオのフレームレートを調整する、ビデオの画像のサイズを縮小する、又は両方の組み合わせを実行する。最適な全体的なビデオ品質を得るためにフレームレート及び平均フレームサイズの調整が変化しても、割り当てられた帯域幅内でビデオを伝送できるようにすることが可能であることが当業者には理解されよう。

図７６の例（１）は、ＵＩ７６３５の２つの動作段階で帯域幅の再割り当てを行う１つのシナリオを示す。第１段階７６７０におけるリモートデバイス７６２０のＵＩ７６３５は、２つの表示を含む合成表示を提示する。２つの表示のうち、一方はＵＩ７６３５の上部にあり、他方はＵＩ７６３５の下部にある。この例では、上部表示域７６２５はローカルデバイスの前面カメラによって取り込まれているビデオを示し、下部表示域７６３０はローカルデバイスの背面カメラによって取り込まれているビデオを示す。第１段階７６７０に示すように、上部表示域７６２５は、下部表示域７６３０よりも大きい。したがって、ローカルデバイスの前面カメラからのビデオは帯域幅の８０％を割り当てられ、ローカルデバイスの背面カメラからのビデオは、帯域幅の２０％を割り当てられる。ローカルデバイスの背面カメラからのビデオを、割り当てられた帯域幅内でローカルデバイスからリモートデバイスに伝送できるようにするために、ビデオのフレームレート又は拡大縮小サイズ又はこれらの両方を調整する。

第２段階７６７５は、上部表示域７６２５と下部表示域７６３０のサイズがほぼ同じとなるようにリモートデバイスのユーザが下部表示域のサイズを増加させた後のＵＩ７６３５を示す。その結果、ビデオのそれぞれは、テレビ会議モジュール７６１５によって全帯域幅の５０％を再割り当てされる。

図７６の例（２）は、ＵＩ７６３５の２つの動作段階で帯域幅の再割り当てを行うための別のシナリオを示す。例（２）の第１段階７６８０では、ＵＩ７６３５はＰＩＰ表示を提示する。ＰＩＰ表示は、２つの表示、すなわち背景メイン表示域７６５０と、前景挿入表示域７６５５とを含む。背景表示域７６５０はＰＩＰ表示の大半を占めるが、前景挿入表示域７６５５は背景メイン表示域７６５０よりも小さく、これに重なる。この例では、背景表示域７６５０は、デバイスの前面カメラによって取り込まれているビデオを提示する。挿入表示域７６５５は、デバイスの背面カメラによって取り込まれているビデオを提示する。この段階に示すように、背景表示域７６５０は挿入表示域７６５５よりも大きい。したがって、デバイスの前面カメラからのビデオは帯域幅の８０％を割り当てられ、デバイスの背面カメラからのビデオは、帯域幅の２０％を割り当てられる。ローカルデバイスの背面カメラからのビデオを、割り当てられた帯域幅内でローカルデバイスからリモートデバイスに伝送できるようにするために、ビデオのフレームレート又は拡大縮小サイズ又はこれらの両方を調整する。

第２段階７６８５は、リモートデバイスのユーザが２つのビデオの表示を入れ換えた後のＵＩ７６３５を示す。具体的には、背景表示域７６６０は、この時点で、デバイスの背面カメラによって取り込まれているビデオを提示しており、挿入表示域７６６５は、この時点で、デバイスの前面カメラによって取り込まれているビデオを提示する。２つのビデオの表示域のサイズが変更されたので、デバイスの背面カメラからのビデオは帯域幅の８０％を割り当てられ、デバイスの前面カメラからのビデオは帯域幅の２０％を割り当てられる。したがって、ローカルデバイスの前面カメラからのビデオのフレームレート若しくは拡大縮小サイズ又はこれらの両方が低減する。図７６で説明する帯域幅の分配は、例にすぎず、テレビ会議中に２つのカメラに帯域幅を割り当てるための他の技術が可能であることは、当業者には理解されよう。

１．フレームレート制御
上述の会議中のフレームレート制御動作のように、一部の実施形態は、デュアルカメラ携帯デバイスの各カメラによって取り込まれたビデオの画像がテレビ会議において他のデバイスに伝送される速度を個別に調整又は維持することが臨まれる場合がある。これらの実施形態のうちの一部は、上述の同様の技術を提供する。例えば、一部の実施形態は、各カメラのセンサモジュール４１５のＶＢＩを調整することによって、各カメラのフレームレートを制御する。他の実施形態は、例えば、各カメラのセンサモジュール４１５及び／又は汎用伝送バッファ３１２０によって実行されうるフレーム間引き（frame dropping）などのさらなる技術も提供する。

２．拡大縮小を通じた帯域幅制御
上述のように、デュアルカメラ携帯デバイスと別のデバイスの間のテレビ会議中に、特定の時間量において１つ以上のネットワーク接続を介して伝送できる画像データ量（すなわち、ネットワーク接続帯域幅）は制限されうる。ネットワーク接続のスループットを最大にして維持するために、デュアルカメラ携帯デバイスの異なる実施形態は、特定の時間量においてネットワーク接続を介して伝送される画像データ量を制御する異なる仕方を提供する。一部の実施形態では、スループットは、通信チャネル（例えば、ネットワーク接続）を介したメッセージ配信の平均成功率である。

デュアルカメラ携帯デバイスの両方のカメラによって取り込まれた画像を伝送する場合に、１つのこのような仕方は、ネットワーク接続を介して伝送される画像データ量を制御するためにデュアルカメラ携帯デバイスの一方又は両方のカメラからの画像をサイズ変更する。一部の実施形態は、ネットワーク接続を介して伝送される画像データ量を低減するためにデュアルカメラ携帯デバイスによって取り込まれた画像のサイズを縮小するが、他の実施形態は、ネットワーク接続を介して伝送される画像データ量を増加するために画像のサイズを拡大する。

一部の実施形態は、拡大縮小時に画像の高さと幅の比を維持する（すなわち、均一な拡大縮小）。他の実施形態は、拡大縮小された画像の高さと幅の比が元の画像と異なるように画像を拡大縮小する（すなわち、アナモルフィックな拡大縮小）。

そのうえ、拡大縮小は、画像処理プロセスの異なる段階において実行されうる。一部の実施形態の拡大縮小は、カメラセンサによって実行されうる。このような実施形態では、カメラセンサは、画像のデータの行又は列（すなわち、画素値）を破棄しうる。このような実施形態のうちの一部では、残りの画像データは、画像の外見を平滑化するために補間される。

他の実施形態の拡大縮小は、ＣＩＰＵ４００のスケーラモジュール４５５によって実行される。一部の実施形態では、拡大縮小は、上述のようにテレビ会議マネージャ１６０４によって実行され、他の実施形態では、スケーラはエンコーダによって実行される。したがって、デュアルカメラ携帯デバイスの異なる実施形態は、拡大縮小を異なるように実行する。

３．ビットレート制御
一部の実施形態は、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオが符号化されるビットレートを管理するための異なる機構を提供する。一部の実施形態では、デュアルカメラ携帯デバイスは、カメラごとにレートコントローラを含む。一部の実施形態は、固定ビットレート管理スキームを提供する。このスキームでは、レートコントローラのそれぞれは、携帯デバイス上の両方のカメラからのビデオの全ビットレートが一定であるように、固定ビットレートに設定される。他の実施形態は、全ビットレートを低減することが必要な場合にデバイスのカメラからの２つのビデオのうちの一方が常に他方よりも優先される優先順位スキームを提供する。

一部の実施形態では、アービトレータモジュールは、２つのカメラの２つのレートコントローラを管理する。図７７は、このようなアービトレータモジュールの一例を示す。図７７に示すように、レートコントローラ７７００は、前面カメラに対するビットレートを設定し、レートコントローラ７７０５は、背面カメラのビットレートを設定する。レートコントローラは、カメラセンサからエンコーダ７７１５に画像を送信する。アービトレータモジュール７７１０は、両方のレートコントローラに接続され、利用可能な帯域幅のもとで両方のビデオをリモートデバイスに伝送できることを保証するために、利用可能な帯域幅、２つのビデオのそれぞれのビデオサイズなどの情報に基づいて、レートコントローラ７７００及び７７０５それぞれに対するビットレートの設定を多くの仕方で制御する。さらに、アービトレータ７７１０は、上述の固定レートスキーム又は優先順位スキームを実施するように構成されうる。

一部の他の実施形態では、２つのカメラのための２つのレートコントローラは互いと通信できる。このスキームのもとで、レートコントローラは、それぞれのビデオの情報を交換し、それに応じてビデオのビットレートを設定できる。レートコントローラレート管理機構のいくつかの例が提供される。しかし、多くの他の異なる機構が可能である。

４．ビデオ処理
デュアルカメラ携帯デバイスの一部の実施形態は、デュアルカメラ携帯デバイスの両方のカメラによって取り込まれた画像を異なる状況で異なるように処理する。例えば、デュアルカメラ携帯デバイスの両方のカメラによって取り込まれた画像を含むＰＩＰ合成画像を処理する場合に、一部の実施形態は、ＰＩＰ合成画像に対してＴＮＲプロセス２０００を選択的に実行する。これらの実施形態のうちの一部は、ＰＩＰ合成画像のメイン画像のみに対してＴＮＲプロセス２０００を実行するが、これらの実施形態のうち他の実施形態は、ＰＩＰ合成画像の挿入画像のみに対してＴＮＲプロセス２０００を実行する。

携帯デバイスの両方のカメラによって取り込まれた画像の処理の別の例として、一部の実施形態は、ビデオを表示する表示域のユーザによる調整など（例えば、ＰＩＰ表示の挿入の引き伸ばし、表示されているビデオにおける関心領域の規定、ＰＩＰ表示のメイン／挿入の入れ換えなど）のテレビ会議への種々の変更、利用可能な全帯域幅の変更などに基づいて、デュアルカメラ携帯デバイスの両方のカメラによって取り込まれた画像を拡大縮小する。これらの実施形態のうちの一部は、上述の方式で画像を拡大縮小する。すなわち、画像は、例えば、エンコーダ１６５５、テレビ会議マネージャ１６０４、スケーラモジュール４５５及び画像が取り込むのに用いられたカメラセンサ（すなわち、４０５ａ又は４０５ｂ）によって拡大縮小されうる。

５．符号化
上述のように、一部の実施形態は、デュアルカメラ携帯デバイスの両方のカメラからビデオを伝送する。したがって、これらの実施形態は、テレビ会議中にリモートデバイスに伝送するために、両方のカメラによって取り込まれたビデオを符号化しうる。異なる実施形態は、伝送のためにビデオを符号化する異なる仕方を提供する。図７８は、マルチプレクサ（ＭＵＸ）７８１５、エンコーダモジュール７８２５、バッファ７８３０及び結合モジュール７８３５を使用して、伝送すべきビデオを処理する手法を示す。

ＭＵＸ７８１５は、選択信号に基づいて、１つの入力信号を受け取り、選択された入力信号をエンコーダ７８２５に出力する。例えば、選択信号が、Ｃ１から入力信号を受け取ることをＭＵＸ７８１５に示すならば、ＭＵＸ７８１５は、その入力信号を選択し、その信号を出力する。この選択信号は、テレビ会議マネージャ１６０４からの命令などの多数の仕方で提供されうる。ＭＵＸ７８１５を通じて、エンコーダ７８２５は、ＭＵＸ７８１５から受け取った画像を交互にビットストリーム形式に符号化し、符号化された画像をバッファ７８３０に格納する。結合モジュール７８３５は、バッファ７８３０に格納された１つ以上のビットストリームを結合（すなわち、多重化）し、単一のビットストリームを出力する。

ここで、この符号化手法の動作について、３つの段階７８６０、７８６５及び７８７０に関して説明する。第１段階７８６０では、ＭＵＸ７８１５は、カメラＣ１によって取り込まれた画像７８０５を受け取って、符号化のためにエンコーダ７８２５に出力するように構成される。エンコーダ７８２５は、受け取った画像を符号化して、ビットストリーム７８５０を生成し、その後、ビットストリーム７８５０はバッファ７８３０に格納される。第２段階７８６５は、ＭＵＸ７８１５が、カメラＣ２によって取り込まれた画像７８１０を受け取って、符号化のためにエンコーダ７８２５に出力するように構成されることを除いて、第１段階７８６０と同様である。この場合も、エンコーダは、受け取った画像を符号化して、ビットストリーム７８５５を生成し、ビットストリーム７８５５はバッファ７８３０に格納される。第３段階７８７０で、結合モジュール７８３５は、ビットストリーム７８５０及び７８５５をバッファ７８３０から読み出して、リモートデバイスへの伝送のために１つのビットストリームに結合する。

図７９は、テレビ会議中にリモートデバイスへの伝送のためにデュアルカメラ携帯デバイスからの２つのビデオを符号化するための別の手法を示す。この手法では、携帯デバイスの第１カメラからのビデオフレーム（すなわち画像）及び携帯デバイスの第２カメラからの別のビデオフレームが、１つのビデオフレームに合成されてから、合成されたビデオフレームが、リモートデバイスに送信されるべきビットストリームに符号化される。図７９に示すように、この手法は、合成器７９１５と、バッファ７９２０と、エンコーダ７９２５とを含む。

図示のように、合成器７９１５は、第１カメラからの画像７９０５と第２カメラからの画像７９１０を合成して、合成画像７９５５を形成する。異なる実施形態は、画像７９０５と画像７９１０とを異なるように合成する。例えば、一部の実施形態の合成器７９１５は、図８０に示すように隣接する２つの画像を互いに整列することによって、画像を合成できる。合成画像８０３０及び８０３５は、この技術を使用する２つの例示的な合成画像を示す。合成画像８０３０では、第１カメラからの画像７９０５は、第２カメラからの画像７９１０の上に整列される。一方、合成画像８０３５は、画像７９１０の左に整列された画像７９０５を示す。

いくつかの他の実施形態では、合成器７９１５は、２つの画像７９０５及び７９１０をより大きな背景画像の上に重ねることによって、２つの画像７９０５と画像７９１０とを合成できる。図８０の合成画像８０４０は、この技術を使用する例示的な合成画像を示す。合成画像８０４０では、画像７９０５と画像７９１０とが斜めに位置合わせされ、空白画像の上に重ねられる（すなわち、画像７９０５は背景画像の左上隅にあり、画像７９１０は右下隅にある）。一部の実施形態では、カメラセンサは、異なるサイズであってよく、したがって、異なる画素解像度を有する画像を取り込んでもよい。このような実施形態では、合成器７９１５は、図８０の合成画像８０４５によって示されるのと同様の方式で、画像７９０５と画像７９１０とを合成できる。２つの画像を合成した後、合成器７９１５は、合成画像をバッファ７９２０に格納する。エンコーダ７９２５は、合成画像をバッファ７９２０から読み出し、合成された画像をビットストリームに符号化して、それをテレビ会議のリモートデバイスに送信する。

ここで、動作について、図７９に示される合成器７９１５、バッファ７９２０及びエンコーダ７９２５に関して説明する。最初に、第１カメラが、画像７９０５をビデオ内の画像のシーケンスの一部として合成器７９１５に送信する。同時に、第２カメラが、別の画像７９１０をビデオ内の画像のシーケンスの一部として合成器７９１５に送信する。その後、合成器７９１５は、上述した手段で、画像７９０５と画像７９１０とを合成して合成画像７９５５を形成する。次に、合成器７９１５は、合成画像７９５５をバッファ７９２０に送信する。その後、バッファ７９２０は、合成画像をエンコーダ７９２５に送信する前に合成画像を格納する。最後に、エンコーダ７９２５は、合成画像をビットストリームに符号化し、そのビットストリームをテレビ会議のリモートデバイスに送信する。

図８１は、テレビ会議中にリモートデバイスへの伝送のためにデュアルカメラ携帯デバイスからの２つのビデオを符号化するためのさらに別の手法を示す。この手法では、デバイスからの２つのビデオが合成表示に表示され、合成表示のスクリーンショットが撮影され、リモートデバイスに送信するべきビットストリームに符号化される。図８１に示すように、この手法は、エンコーダ８１１５を含む。一部の実施形態では、エンコーダ８１１５は、合成画像を符号化し、リモートデバイスに送信する。

ここで、動作について、図８１に示されるエンコーダ８１１５に関して説明する。最初に、デュアルカメラ携帯デバイスの２つのカメラからのビデオが、デバイスの画面の合成表示に表示される。合成表示は、ビデオを任意の方式で提示できる。例えば、一部の実施形態における合成表示は、図８１に示されるＰＩＰ表示８１０５などのＰＩＰ表示に２つのビデオを提示できる。他の実施形態では、合成表示は、並んだ２つの表示域又は斜めに整列した２つの表示域に２つのビデオを提示しうる。画像８１１０などの、ＰＩＰ表示８１０５のスクリーンショットが撮影され、エンコーダ８１１５に送信される。その後、エンコーダは、スクリーンショットのシーケンスをビットストリーム８１２０に符号化してから、ビットストリーム８１２０をテレビ会議のリモートデバイスに送信する。２つのビデオを符号化するためのいくつかの異なる手法を上述したが、他の手法も可能である。

６．復号
デュアルカメラ携帯デバイスの一部の実施形態は、図７８〜図８１に関して上述した手法によって符号化されたビットストリームを受け取ってもよい。このような実施形態では、デュアルカメラ携帯デバイスは、ビデオを符号化するために使用された手法を示す情報を（例えば、テレビ会議制御チャネルを通じて）受け取ってもよい。図８２は、テレビ会議中にデュアルカメラ携帯デバイスに表示するために通信ネットワークを通じて別のデバイスから受け取った２つのビデオのビットストリームを復号する１つの手法を示す。具体的には、この手法は、上記で図７８に関して説明した符号化手法によって符号化されたビットストリームを復号するために使用される。

図８２に示すように、この手法は、分離モジュール８２３５、バッファ８２３０及び８２９０並びにデコーダモジュール８２２５を使用する。分離モジュール８２３５は、ビットストリームを１つ以上のビットストリームに分解（すなわち、逆多重化）し、それらのビットストリームをバッファ８２３０に格納する。デコーダ８２２５は、符号化されたビットストリームを読み出し、それを復号してビデオを生成し、その後このビデオをバッファ８２９０に格納する。

ここで、この手法の動作について、図８２に示される分離モジュール８２３５、バッファ８２３０及び８２９０並びにデコーダモジュール８２２５に関して説明する。最初に、デュアルカメラ携帯デバイスが、テレビ会議において他のデバイスから通信ネットワークを通じて（例えば、ネットワーキングマネージャ１６１４において）ビットストリーム７８４５を受け取る。受け取ったビットストリームは、２つのビットストリームの多重化されたビットストリームであるので、分離モジュール８２３５は、受け取ったビットストリームを２つのビットストリーム８２５５及び８２６０に分解する。符号化された各ビットストリームは、デバイスの２つのカメラのうちの一方から取り込まれたビデオデータを表す。その後、分離モジュール８２３５は、ビットストリーム８２５５及び８２６０をバッファ８２３０に格納する。

その後、デコーダ８２２５は、２つのビットストリーム８２５５及び８２６０のうちの一方であるビットストリーム８２５０をバッファ８２３０から読み出し、デコーダ８２２５は、ビットストリーム８２５０を復号し、ビデオ８２８０を生成して、ビデオ８２８０をバッファ８２９０に格納する。デコーダ８２２５は、ビットストリーム８２５５及び８２６０のうちの他方も復号し、生成されたビデオをバッファ８２９０に格納する。ここで、両方のビデオは、バッファ８２９０から読み出され、格納されることもできるし、デュアルカメラ携帯デバイスに表示されることもできる。

図８３は、図７９に関して説明した手法によって符号化されたビットストリームを復号する手法を示す。図８３に示すように、この手法は、デコーダ８３２５と、バッファ８３２０と、分解器８３１５とを含む。

一部の実施形態では、デコーダ８３２５は、図７９に示される手法によって符号化されたビットストリームを受け取り、ビットストリームを１つ以上の合成画像に復号し、その後、この合成画像がバッファ８３２０に格納される。分解器８３１５は、各合成画像から２つの画像を抽出する。合成画像から２つの画像を抽出するために、分解器８３１５は、各画像の合成画像内部での位置を示す情報（例えば、画像を合成及び符号化したテレビ会議においてデバイスからテレビ会議通信制御チャネルを通じて受け取った情報）も受け取る。

ここで、この手法の動作について、図８３に示されるデコーダ８３２５、バッファ８３２０及び分解器８３１５に関して説明する。最初に、デコーダ８３２５は、図７９に関して説明した手法によって作製されたビットストリームなどのビデオのビットストリームを、テレビ会議の別の携帯デバイスから受け取る。デコーダ８３２５は、ビットストリームを、合成画像７９５５を含む１つ以上の合成画像に復号し、その合成画像をバッファ８３２０に格納する。その後、バッファ８３２０は、合成画像を分解器８３１５に送信する前に合成画像を格納する。分解器が合成画像７９５５をバッファ８３２０から受け取ると、分解器は、合成画像７９５５を２つの画像７９０５及び７９１０に分解する。これらの画像は、図７９の画像７９０５及び７９１０と同一である。

ビットストリームが、図８１で説明したシステムなどのシステムから受け取られた場合に、図８３のデコーダ８３２５などのデコーダは、ビットストリームをスクリーンショットのシーケンスに復号する。スクリーンショットのシーケンスは、さらなる処理を行わずに、デバイスの画面にビデオとして表示される。

ＶＩ．複数のソース
上述のように、ビデオは、テレビ会議においてデュアルカメラ携帯デバイスの両方のカメラによって取り込まれ、別のデバイスに伝送されうる。一部の実施形態は、デュアルカメラ携帯デバイスの両方のカメラから取り込まれたビデオを伝送するのではなく、デュアルカメラ携帯デバイスのカメラから取り込まれたビデオと共にデュアルカメラ携帯デバイスに表示される異なるメディアコンテンツ又は任意のコンテンツを伝送してもよい。言い換えれば、これらの実施形態は、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオと共にいくつかのソースからのコンテンツを伝送できる。

図８４は、一部の実施形態のデュアルカメラ携帯デバイスのテレビ会議及び処理モジュールのための別のソフトウェアアーキテクチャを概念的に示す。図８４のテレビ会議及び処理モジュールは、テレビ会議及び処理モジュールがディスプレイドライバ８４８５と記憶装置８４７５とを含み、メディア交換モジュール１６２０がメディアソースモジュール８４７０と画面取り込みモジュール８４８０とを含むことを除いて、図１６のテレビ会議及び処理モジュール１６００と同様である。

一部の実施形態のメディアソースモジュール８４７０は、テレビ会議モジュール８４０２と記憶装置８４７５との間でメディアコンテンツを経路制御する。メディアコンテンツの例は、ビデオ、画像、文書及び音楽を含む。他の実施形態は、他のタイプのメディアコンテンツを記憶装置８４７５に格納する。一部の実施形態の記憶装置８４７５は内部記憶装置（例えば、ＲＡＭ）であるが、他の実施形態の記憶装置８４７５は外部記憶装置（例えば、コンパクトフラッシュ（ＣＦ）カード、セキュアデジタル（ＳＤ）カードなど）である。

一部の実施形態では、画面取り込みモジュール８４８０は、ディスプレイドライバ８４８５を通じてデュアルカメラ携帯デバイスのディスプレイに表示されるコンテンツの画像を経路制御する。一部の実施形態では、ディスプレイドライバ８４８５は、ディスプレイ上のコンテンツの取り込み及びコンテンツの画像への変換を担当する。異なる実施形態は、ディスプレイに表示される異なるコンテンツを取り込む。例えば、一部の実施形態は、ディスプレイに表示されるすべてのコンテンツを取り込む。他の実施形態は、ディスプレイの特定の表示域（例えば、現在のアクティブなウィンドウの表示域、ＰＩＰ表示の表示域など）を取り込む。

ここで、テレビ会議及び処理モジュールの一部の例示的な動作について、図８４に関して説明する。デュアルカメラ携帯デバイスのカメラから取り込まれたビデオと共にメディアコンテンツを伝送するために、一部の実施形態のテレビ会議モジュール８４０２は、ＣＩＰＵ１６５０から画像を読み出すのではなく、テレビ会議マネージャ１６０４がメディアソースモジュール８４７０を通じて記憶装置８４７５からメディアコンテンツを読み出すことを除いて、図１６で上述したテレビ会議モジュール１６０２と同じ動作を実行する。デュアルカメラ携帯デバイスのディスプレイに表示されるコンテンツの画像を伝送するために、テレビ会議マネージャ１６０４の一部の実施形態は、ディスプレイドライバ８４８５を通じてデュアルカメラ携帯デバイスのディスプレイに表示されるコンテンツの画像を読み出す。一部の実施形態は、ディスプレイに表示されるメディアコンテンツ又はコンテンツの画像に対して、ＣＩＰＵ１６５０から読み出された画像に対して実行されるのと同様の処理（例えば、パースペクティブ補正、サイズ変更など）を実行するが、他の実施形態は処理をまったく実行しない。

上記の説明は、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオと共に種々のソースからのコンテンツを伝送する例のうちいくつかについて記載する。しかし、他の実施形態は、他の異なるタイプのコンテンツを伝送できる。例えば、複数の参加者が関与するテレビ会議では、一部の実施形態は、テレビ会議で、あるデバイスから受信したビデオ及びデュアルカメラ携帯デバイスのカメラによって取り込まれたビデオを別のデバイスに伝送する。したがって、任意の数のソースからの任意の数の異なるタイプのコンテンツが、デュアルカメラ携帯デバイスのカメラによって取り込まれたビデオと共に伝送されうる。

ＶＩＩ．複数の参加者によるテレビ会議
テレビ会議に関連する上記のセクションは、２人の参加者によるテレビ会議について説明する。しかし、一部の実施形態の携帯デバイスを用いた複数の参加者（すなわち、３人以上の参加者）によるテレビ会議も可能である。一部の実施形態では、複数の参加者によるテレビ会議の参加者全員が互いに姿を見、声を聞くことができる。他の実施形態は、１人の参加者（例えば、放送者）が他の参加者全員の姿を見、声を聞くことができ、他の参加者全員も放送者の姿を見、声を聞くことができるが、他の参加者が（例えば、放送者によって許可されないかぎり）互いの姿を見、声を聞くことはできない、複数の参加者による放送型テレビ会議を提供する。

Ａ．複数の参加者によるテレビ会議のユーザインタフェース
複数の参加者によるテレビ会議中に、一部の実施形態は、テレビ会議の参加者を表示し、姿を見る特定の参加者（群）を選択するためのさまざまな異なるＵＩを提供する。例えば、携帯デバイスの一部の実施形態は、複数の参加者によるテレビ会議の参加者全員を同時に表示するＵＩを提供し、携帯デバイスのユーザは、姿を見る参加者の１人を（例えば、選択した参加者の画像を引き伸ばすことによって）選択できる。図８５は、このようなＵＩの一例を示す。

この図は、複数の参加者によるテレビ会議の参加者全員を携帯デバイス８５００のＵＩ８５３０に同時に表示し、姿を見る参加者の１人を選択するための動作のシーケンスを、ＵＩ８５３０の５つの異なる段階８５０５、８５１０、８５１５、８５２０及び８５２５として示す。第１段階８５０５は、他のデバイスの他の３人のユーザ間の、複数の参加者によるテレビ会議が確立された後のＵＩ８５３０を示す。図示のように、ＵＩ８５３０は、合成表示８５３５と、表示域１１５５とを含む。合成表示８５３５は、複数の参加者によるテレビ会議の参加者のカメラによって取り込まれた画像を表示する４つの表示域８５６５、８５７０、８５７５及び８５８０を含む。この例では、表示域８５６５は、携帯デバイス８５００のユーザを示す（すなわち、表示域８５６５は、携帯デバイス８５００の前面カメラによって取り込まれた画像を表示する）。表示域１１５５は、図１２のこれまでの上述した表示域１１５５と同じである。

第２段階８５１０は、携帯デバイス８５００のユーザが合成表示域８５３０の表示域のうちの１つを選択することによって参加者選択動作を開始することを示す。具体的には、第２段階８５１０は、ユーザが表示域８５７０を（例えば、指８５５０で表示域８５７０をタップすることによって）選択することを示す。

ＵＩ８５３０の第３段階８５１５は、参加者選択動作が完了した後の合成表示８５５５を示す。一部の実施形態は、第２段階８５１０と第３段階８５１５との間の移行を表示するためにアニメーション（不図示）を提供する。合成表示８５５５は、第２段階８５１０で選択された参加者の表示域を示すＰＩＰ表示８５６０（すなわち、表示域８５７０）を背景表示域として含み、ユーザの表示域８５６５をＰＩＰ表示８５６０の挿入表示域として含む。この例では、ＰＩＰ表示８５６０は、横向きに合うように水平に伸張された選択された表示域８５７０の画像を示す。一部の実施形態では、画像は伸張されず、選択した表示域の画像はその縦向きを維持する（すなわち、背景表示域の各辺の余分な空白は、図３６に示すように、黒いバーで満たされる）。そのうえ、合成表示８５５５は、２つの選択されていない表示域８５７５及び８５８０の縮小画像を示す合成表示８５８５も含む。

第４段階８５２０は、ＰＩＰ表示８５６０を選択することによって（例えば、指８５５０でＰＩＰ表示８５６０をタップすることによって）、携帯デバイス８５００のユーザが参加者選択解除動作を始めているところを示す。第５段階８５２５は、参加者選択解除動作の完了後の合成表示８５３５を示す。

図８５は、複数の参加者によるテレビ会議の参加者全員を同時に表示し、参加者選択動作を実行し、参加者選択解除動作を実行するための動作の例示的なシーケンスを示す。動作の他のシーケンスが可能である。例えば、第３段階８５１５の後、ユーザは、参加者選択解除動作を開始する代わりに、表示域８５８５内の新たに選択された表示域をＰＩＰ表示８５６０の背景表示域（すなわち、以前に選択された表示域）と入れ換えるために合成表示８５８５に表示される選択されていない表示域のうちの１つを選択できる。したがって、ユーザは、複数の参加者によるテレビ会議中に、表示域８５８５内の表示域をＰＩＰ表示８５６０の背景表示域といつでも任意の回数入れ換えることができる。また、複数の参加者によるテレビ会議中にいつでも、ユーザは、参加者選択解除動作を実行して合成表示８５３５に戻ることができる。さらに、異なる実施形態により、ユーザは、携帯デバイス８５００上のスイッチを切り換えることによって、音声コマンドを与えることによってなどの、異なる仕方で、特定の参加者を選択できる。

一部の実施形態は、例えば、音声検出に基づいて参加者を自動的に選択するための技術を提供する。このような実施形態では、参加者の１人が話す場合に、その参加者の表示域がＰＩＰ表示８５６０の背景表示域として自動的に選択される。異なる参加者が話す場合に、その参加者の表示域がＰＩＰ表示８５６０の背景表示域として自動的に選択される。一部の実施形態では、複数の参加者によるテレビ会議の参加者のうちだれも話していない場合に、ディスプレイは、規定の量の沈黙（例えば、３秒）後に合成表示８５３５を表示する。一部の実施形態では、携帯デバイス８５００のユーザが話す場合に、携帯デバイス８５００のＵＩ８５３０で何も起こらない。

図８６は、複数の参加者によるテレビ会議の参加者全員を同時に表示し、参加者のうちの見るべき１人を選択するための動作の別の例示的なシーケンスを示す。図８６は、この動作を携帯デバイス８５００のＵＩ８６４５に、ＵＩ８６４５の異なる７つの段階８５０５、８６０５、８６１０、８６１５、８６２０、８６２５及び８６３０として示す。第１段階８５０５は、他のデバイスの他の３人のユーザ間の複数の参加者によるテレビ会議が確立された後のＵＩ８６４５を示す図８５に示される第１段階８５０５と同じである。

第２段階８６０５は、表示域８５７０を選択することによって（例えば、２本の指を表示域８５７０に置くことによって）、携帯デバイス８５００のユーザが参加者選択動作を開始しているところを示す。第３段階８６１０は、参加者選択動作の移行段階を示す。この段階で、ユーザは、表示域８５７０をより大きくさせ、合成表示８５３５となるために使用されたものの表示域を満たしながら、互いから離れるように２つの指をドラッグする。この例は、表示域８５７０が選択されていることを示すが、他の表示域８５６５、８５７５及び８５８０のいずれかが選択されうる。一部の実施形態では、携帯デバイス８５００のユーザは、ユーザの表示域（すなわち、この例では表示域８５６５）を選択しないようにできる。

ＵＩ８６４５の第４段階８６１５は、参加者選択動作が完了した後のＰＩＰ表示８６３５を示す。一部の実施形態は、ユーザが、表示域８５７０がＰＩＰ表示８６３５の背景表示域８６４０を満たすまで、互いから離れるような指のドラッグを継続することを必要とするが、他の実施形態は、ユーザが指を離す前に、ユーザが特定のしきい値量よりも大きくなる（例えば、特定の距離よりも長い、又は特定の時間量よりも大きい）ようなドラッグ動作を行うことのみが必要とされる。ユーザのドラッグ動作が特定のしきい値量を満たすか又はこれを超える場合に、ＵＩ８６４５は、ＰＩＰ表示８６３５の背景表示域８６４０を満たすまで、表示域８５７０を拡大しつづける。そうでない場合に、参加者選択動作は完了せず、ＵＩ８６４５は合成表示８５３５に戻る。図示のように、選択された表示域（すなわち、表示域８５７０）はＰＩＰ表示８６３５の背景表示域８６４０であり、ユーザの表示域８５６５はＰＩＰ表示８６３５の挿入表示域である。一部の実施形態は、第３段階８６１０と第４段階８６１５との間の移行を表示するためにアニメーション（不図示）を提供する。

第５段階８６２０は、携帯デバイス８５００のユーザがＰＩＰ表示８６３５の表示域８６４０を選択することによって（例えば、２本の指を背景表示域８６４０に置くことによって）参加者選択解除動作を開始しているところを示す。第６段階８６２５は、参加者選択解除動作の移行段階を示す。この段階は、ＰＩＰ表示８６３５の背景表示域８６４０となるように使用されるものの表示域を縮めるために、ユーザが指を互いに向かってドラッグするところを示す。第３段階８６１０で説明した動作と同様に、一部の実施形態は、ユーザが指を離す前に、ユーザのドラッグ動作がしきい値量よりも大きくなる（例えば、特定の距離よりも長い、又は特定の時間量よりも長い）ことを必要とする。そうでない場合に、参加者選択解除動作は完了せず、ＵＩ８６４５はＰＩＰ表示８６３５に戻る。ＵＩ８６４５の第７段階８６３０は、参加者選択解除動作の完了後の合成表示８５３５を示す。

図８６は、複数の参加者によるテレビ会議の参加者全員を同時に表示し、参加者選択動作を実行し、参加者選択解除動作を実行するための動作の別の例示的なシーケンスを示す。しかし、一部の実施形態により、携帯デバイス８５００のユーザは、参加者選択動作及び参加者選択解除動作を反復して実行できる。図８７は、１つのこのような実施形態を示す。

具体的には、図８７は、ＵＩ８７３０において参加者選択動作及び参加者選択解除動作を複数回実行する例示的なシーケンスを、ＵＩ８７３０の７つの異なる段階８５０５、８７０５、８６１５、８７１０、８７１５、８７２０及び８７２５として示す。第１段階８５０５は、上述の図８５及び図８６の第１段階８５０５と同じである。第２段階８７０５は、ユーザが（２本の指を表示域８５７０に置くのではなく）表示域８５７０を一度タップすることによって表示域８５７０を選択することを除いて、図８６の第２段階８６０５と同様である。第３段階８６１５は、参加者選択動作の完了後のＰＩＰ表示８６３５を示すので、図８６の第４段階８６１５と同じである。第４段階８７１０は、ユーザが（２本の指を背景表示域８６４０に置くのではなく）背景表示域８６４０を一度タップすることによってＰＩＰ表示８６４５の背景表示域８６４０を選択することを除いて、図８６の第５段階８６２０と同様である。

第５段階８７１５は、参加者選択解除動作が完了した後の合成表示８５３５を示すので、図８６の第７段階８６３０と同じである。第６段階８７２０は、参加者選択動作が表示域８５７５に対して実行されることを除いて、第２段階８５１０と同様に示す。同様に、第７段階８７２５は、選択された表示域（すなわち、表示域８５７５）をＰＩＰ表示８６３５の背景表示域８６４０として示すので、第３段階８７０５と同様である。図８７は、少数の参加者選択動作及び参加者選択解除動作のみを示しているが、任意の数のこのような動作が、複数の参加者によるテレビ会議中に実行されうる。

さらに、一部の実施形態は、テレビ会議中に異なる数の参加者を表示できるＵＩを提供する。例えば、一部の実施形態のＵＩは、携帯デバイスが直立位置（すなわち、縦向き）に保持される場合に複数の参加者によるテレビ会議の参加者の一部のみを表示し、携帯デバイスが横向き位置（すなわち、横向き）に保持される場合に追加の参加者を表示する。他の実施形態は、携帯デバイスが横向き位置に保持される場合に参加者全員を表示する。さらに、一部の実施形態は、図３４、図３５、図３６及び図３７に示されるのと同様に、携帯デバイスの異なる位置及び／又は向きの間での移行を示すアニメーションを提供する。他の異なるアニメーションも可能である。

テレビ会議中に異なる数の参加者を表示するＵＩの別の例として、一部の実施形態により、携帯デバイスのユーザは、複数の参加者を選択してテレビ会議中に同時に姿を見ることができる。説明のために図８５の第１段階８５０５を参照すると、これらの実施形態のうちの一部により、携帯デバイス８５００のユーザは、表示域８５６５、８５７０、８５７５及び８５８０の２つ以上を（例えば、合成表示８５３５の対応する表示域をタップすることによって）選択できる。選択された表示域は、他のタイプの複数の参加者の表示構成の中でも特に、合成表示、ＰＩＰ表示、図６５に示される表示構成のいずれかなどの種々の方式で表示されうる。そのうえ、一部の実施形態の一例を説明しているが、異なる実施形態は、複数の参加者によるテレビ会議の複数の参加者を多くの異なる仕方で選択及び表示できることが当業者には理解されよう。

Ｂ．複数の参加者による放送型テレビ会議のためのユーザインタフェース
前述のように、複数の参加者による放送型テレビ会議は、１人の参加者が他の参加者全員の姿を見て声を聞くことのみが可能であり、他の参加者は、互いに声を聞いたり姿を見たりすることはできない。複数の参加者による放送型テレビ会議を容易にするため、一部の実施形態は、複数の参加者による放送型テレビ会議の放送者及び他の参加者を表示するための多数の異なるＵＩを提供する。例えば、一部の実施形態は、図８５に示される第３段階８５１５のレイアウトと同様である学生と教師のような（student-teacher-like）ＵＩレイアウトを提供する。したがって、その後、一部の実施形態の学生と教師のＵＩレイアウトについて、この段階に関して説明する。

これらの実施形態では、放送者のみが、ＰＩＰ表示８５６０の表示域全体に表示される（すなわち、挿入表示域は表示されない）。複数の参加者による放送型テレビ会議の他の参加者は、合成表示８５８５に表示される表示域と同様のＰＩＰ表示８５６０の下に表示される。一部の実施形態では、規定の数の他の参加者は、携帯デバイスが縦モードである場合に合成表示８５８５に表示されるが、追加又はすべての参加者は、携帯デバイスが上述したものと同様に横モードである場合に合成表示８５８５に表示されうる。さらに、他の実施形態は、複数の参加者による放送型テレビ会議の放送者及び他の参加者を表示するための異なるＵＩを提供する。

Ｃ．複数の参加者によるテレビ会議のためのオーディオの制御
さらに、一部の実施形態の携帯デバイスは、複数の参加者によるテレビ会議の参加者のオーディオを制御するための異なる技術を提供する。例えば、携帯デバイスの一部の実施形態により、携帯デバイスのユーザは、このような実施形態のＵＩに表示されるボリューム制御の単一の集合（例えば、ボリュームスライダ）を通じて複数の参加者によるテレビ会議において各参加者のオーディオを制御できる。他の実施形態では、携帯デバイスにより、携帯デバイスのユーザは、各参加者の表表示域に表示されるボリュームスライダなどのボリューム制御の集合によって複数の参加者によるテレビ会議における各参加者のオーディオのボリュームを個別に制御できる。一部の実施形態は、ボリューム制御の集合の代わりに消音ボタンのみを提供する。したがって、一部のこのような実施形態では、携帯デバイスのユーザは、複数の参加者によるテレビ会議の参加者全員を消音又は消音解除することのみができるが、他のこのような実施形態では、携帯デバイスのユーザは、複数の参加者によるテレビ会議の各参加者を個別に消音又は消音解除できる。さらに、複数の参加者によるテレビ会議の参加者のオーディオを制御するための他の技術は、携帯デバイス上のスイッチを切り換えることによって、音声コマンドを与えることなどによって可能である。

ＶＩＩＩ．電子システム
上述の機能及び用途の多くは、（コンピュータ可読媒体とも呼ばれる）コンピュータ可読記憶媒体に記録された命令セットとして特定されるソフトウェアプロセスとして実施される。これらの命令が１つ以上の処理ユニット（例えば、１つ以上のプロセッサ、プロセッサのコア又は他の処理ユニット）によって実行される場合に、処理ユニット（群）に、命令に示された動作を実行させる。コンピュータ可読媒体の例は、ＣＤ−ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭなどを含むが、これらに限定されない。コンピュータ可読媒体は、無線接続又は有線接続を通る搬送波及び電子信号を含まない。

本明細書では、「ソフトウェア」という用語は、リードオンリメモリに常駐するファームウェア又は磁気記憶装置に格納されたアプリケーションを含むことを意味し、プロセッサによる処理のためにメモリに読み込まれることができる。また、一部の実施形態では、複数のソフトウェア発明は、別個のソフトウェア発明を残しながら、より大規模なプログラムのサブパーツ（sub-part）として実施されうる。一部の実施形態では、複数のソフトウェア発明は、別個のプログラムとして実施されることもできる。最後に、本明細書で説明するソフトウェア発明を一緒に実施する別個のプログラムのいかなる組み合わせも本発明の範囲内に含まれる。一部の実施形態では、ソフトウェアプログラムは、１つ以上の電子システム上で動作するようにインストールされた場合に、ソフトウェアプログラムの動作を実行及び実施する１つ以上の特定のマシン実装を規定する。

一部の実施形態は、呼び出し側プログラムコードが１つ以上のインタフェースを通じて呼び出されている他のプログラムコードと対話する環境で、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を含むソフトウェアプロセスとして実施される。種々の種類のパラメータをさらに含みうる種々の関数呼び出し、メッセージ又は他のタイプの起動は、呼び出し側プログラムと呼び出されているコードの間のＡＰＩを介して転送されうる。さらに、ＡＰＩは、ＡＰＩで定義され、かつ呼び出しされるプログラムコードで実装されるデータ型又はクラスを使用する能力を呼び出し側プログラムコードに提供しうる。

少なくとも所定の実施形態は、呼び出し側ソフトウェアコンポーネントが、呼び出されるソフトウェアコンポーネントとＡＰＩを通じて対話する環境を含む。この環境においてＡＰＩを通じて動作するための方法は、ＡＰＩを介した１つ以上の関数呼び出し、メッセージ、他のタイプの起動又はパラメータの転送を含む。

一部の実施形態では、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を使用できる。例えば、メディア交換モジュール３１０（又は９１０）の一部の実施形態は、図１９に説明したＴＮＲモジュール１９００の機能などの図３及び図９に説明した種々のビデオ処理及び符号化機能にアクセスするために、ＡＰＩ集合を他のソフトウェアコンポーネントに提供する。

ＡＰＩは、プログラムコードコンポーネント又はハードウェアコンポーネント（以下「ＡＰＩ実装コンポーネント」と呼ぶ）によって実装されるインタフェースであり、異なるプログラムコードコンポーネント又はハードウェアコンポーネント（以下「ＡＰＩ呼び出し側コンポーネント」と呼ぶ）は、これにアクセスして、ＡＰＩ実装コンポーネントによって提供される１つ以上の関数、メソッド、プロシージャ、データ構造、クラス及び／又は他のサービスを使用できる。ＡＰＩは、ＡＰＩ呼び出し側コンポーネントとＡＰＩ実装コンポーネントとの間で渡される１つ以上のパラメータを定義できる。

ＡＰＩにより、（サードパーティの開発者であってもよい）ＡＰＩ呼び出し側コンポーネントの開発者は、ＡＰＩ実装コンポーネントによって提供される特定の機能を活用できる。１つのＡＰＩ呼び出し側コンポーネントもありうるし、複数のこのようなコンポーネントもありうる。ＡＰＩは、アプリケーションからのサービスの要求をサポートするためにコンピュータシステム又はプログラムライブラリが提供するソースコードインタフェースでありうる。オペレーティングシステム（ＯＳ）は、ＯＳ上で実行されるアプリケーションがこれらのＡＰＩのうちの１つ以上を呼び出すことを可能にするために複数のＡＰＩを有することができ、（プログラムライブラリなどの）サービスは、サービスを使用するアプリケーションがそれらのＡＰＩのうちの１つ以上を呼び出すために複数のＡＰＩを有しうる。ＡＰＩは、アプリケーションのビルド時に解釈実行又はコンパイルされうるプログラミング言語の観点で特定されうる。

一部の実施形態では、ＡＰＩ実装コンポーネントは、それぞれＡＰＩ実装コンポーネントによって実装される機能の異なる態様の異なるビュー又はこの異なる態様にアクセスする異なる態様を提供する複数のＡＰＩを提供できる。例えば、ＡＰＩ実装コンポーネントのあるＡＰＩは、関数の第１集合を提供でき、サードパーティの開発者に公開でき、ＡＰＩ実装コンポーネントの別のＡＰＩは、隠されており（公開されておらず）、関数の第１集合の部分集合を提供し、関数の第１集合に含まれない関数のテスト又はデバッグなどの、関数の別の集合も提供する。他の実施形態では、ＡＰＩ実装コンポーネント自体が、その基礎となるＡＰＩを介して１つ以上の他のコンポーネントを呼び出し、したがってＡＰＩ呼び出し側コンポーネントとＡＰＩ実装コンポーネントとの両方を兼ねることができる。

ＡＰＩは、ＡＰＩ実装コンポーネントの特定の機能にアクセスして使用する場合にＡＰＩ呼び出し側コンポーネントが使用する言語及びパラメータを定義する。例えば、ＡＰＩ呼び出し側コンポーネントは、ＡＰＩによって公開される（例えば、関数又はメソッドによって実施される）１つ以上のＡＰＩの呼び出し又は起動を通じてＡＰＩ実装コンポーネントの特定の機能にアクセスし、ＡＰＩの呼び出し又は起動を介してパラメータを使用してデータ及び制御情報を渡す。ＡＰＩ実装コンポーネントは、ＡＰＩ呼び出し側コンポーネントからのＡＰＩ呼び出しに応答してＡＰＩを通じて値を返してもよい。ＡＰＩは、ＡＰＩ呼び出しの構文及び結果（例えば、どのようにしてＡＰＩ呼び出しを起動するか、及びＡＰＩ呼び出しが何を行うか）を定義するが、ＡＰＩは、ＡＰＩ呼び出しによって指定された関数をＡＰＩ呼び出しがどのように実現するかを明らかにしなくてもよい。種々のＡＰＩ呼び出しは、呼び出し側（ＡＰＩ呼び出し側コンポーネント）とＡＰＩ実装コンポーネントとの間の１つ以上のアプリケーションプログラミングインタフェースを介して転送される。ＡＰＩ呼び出しの転送は、関数呼び出し又はメッセージの発行、開始、起動、呼び出し、受信、返送、又は応答を含みうる。言い換えれば、転送は、ＡＰＩ呼び出し側コンポーネント又はＡＰＩ実装コンポーネントのいずれかによる動作を記述できる。ＡＰＩの関数呼び出し又は他の起動は、パラメータリスト又は他の構造を通じて１つ以上のパラメータを送信又は受信できる。パラメータは、定数、キー、データ構造、オブジェクト、オブジェクトクラス、変数、データ型、ポインタ、配列、リスト、又は関数若しくはメソッドへのポインタ、又はＡＰＩを介して渡されるデータ若しくは他の項目を参照する別の仕方でありうる。

そのうえ、データ型又はクラスは、ＡＰＩによって提供され、ＡＰＩ実装コンポーネントによって実装されうる。したがって、ＡＰＩ呼び出し側コンポーネントは、ＡＰＩで提供される定義を使用することによって、変数を宣言し、このような型又はクラスへのポインタを使用し、このような型又はクラスの定数値を使用又はインスタンス化できる。

一般に、ＡＰＩは、ＡＰＩ実装コンポーネントによって提供されるサービス若しくはデータにアクセスするために、又はＡＰＩ実装コンポーネントによって提供される動作又は計算の実行を開始するために使用されうる。例を挙げると、ＡＰＩ実装コンポーネント及びＡＰＩ呼び出し側コンポーネントはそれぞれ、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム又は他のモジュールの任意の１つであってもよい（ＡＰＩ実装コンポーネント及びＡＰＩ呼び出し側コンポーネントは、同じタイプのモジュールであってもよいし、互いと異なるタイプのモジュールであってもよいことを理解されたい）。一部の場合では、ＡＰＩ実装コンポーネントは、少なくとも一部がファームウェア、マイクロコード又は他のハードウェア論理回路において実施されうる。一部の実施形態では、ＡＰＩにより、クライアントプログラムが、ソフトウェア開発キット（ＳＤＫ）ライブラリによって提供されるサービスを使用することが可能になる。他の実施形態では、アプリケーション又は他のクライアントプログラムは、アプリケーションフレームワークによって提供されるＡＰＩを使用できる。これらの実施形態では、アプリケーション又はクライアントプログラムは、ＳＤＫ及びＡＰＩによって提供される関数又はメソッドへの呼び出しを組み込むことができ、又は、ＳＤＫで定義されＡＰＩによって提供されるデータ型又はオブジェクトを使用できる。アプリケーションフレームワークは、これらの実施形態では、フレームワークによって定義された種々のイベントに応答するプログラムにメインイベントループを提供できる。ＡＰＩにより、アプリケーションは、アプリケーションフレームワークを使用してイベント及びイベントへの応答を規定できる。いくつかの実装形態では、ＡＰＩ呼び出しは、入力の能力及び状態、出力の能力及び状態、処理能力、電力状態、記憶装置の容量及び状態、通信能力などの態様に関連する能力又は状態を含む、ハードウェアデバイスの能力又は状態をアプリケーションに報告でき、ＡＰＩは、一部において、ファームウェア、マイクロコード又は一部においてハードウェアコンポーネント上で実行する他の低レベル論理回路によって実装されうる。

ＡＰＩ呼び出し側コンポーネントは、ローカルコンポーネント（すなわち、ＡＰＩ実装コンポーネントと同じデータ処理システム上にある）であってもよいし、ネットワークを介してＡＰＩを通じてＡＰＩ実装コンポーネントと通信するリモートコンポーネント（すなわち、ＡＰＩ実装コンポーネントと異なるデータ処理システム上にある）であってもよい。ＡＰＩ実装コンポーネントは、ＡＰＩ呼び出し側コンポーネントとして機能してもよく（すなわち、異なるＡＰＩ実装コンポーネントによって公開されているＡＰＩへのＡＰＩ呼び出しを行ってもよく）、ＡＰＩ呼び出し側コンポーネントは、異なるＡＰＩ呼び出し側コンポーネントに公開されるＡＰＩを実装することによってＡＰＩ実装コンポーネントとして機能してもよいことを理解されたい。

ＡＰＩにより、異なるプログラミング言語で記述された複数のＡＰＩ呼び出し側コンポーネントが、ＡＰＩ実装コンポーネントと通信できる（したがって、ＡＰＩは、ＡＰＩ実装コンポーネントとＡＰＩ呼び出し側コンポーネントとの間で呼び出し及び戻り値を変換するための機能を含むことができる）。しかし、ＡＰＩは、特定のプログラミング言語の観点で実装されてもよい。ＡＰＩ呼び出し側コンポーネントは、一実施形態では、ＯＳプロバイダからのＡＰＩ集合及びプラグインプロバイダからの別のＡＰＩ集合及び別のプロバイダ又は別のＡＰＩ集合の作成者からの別のＡＰＩ集合（例えばソフトウェアライブラリのプロバイダ）などの異なるプロバイダからのＡＰＩを呼び出せる。

図８８は、本発明の一部の実施形態で使用されてもよい例示的なＡＰＩアーキテクチャを示すブロック図である。図８８に示すように、ＡＰＩアーキテクチャ８８００は、ＡＰＩ８８２０を実装するＡＰＩ実装コンポーネント８８１０（例えば、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、ソフトウェア又は他のモジュール）を含む。ＡＰＩ８８２０は、ＡＰＩ呼び出し側コンポーネント８８３０によって使用されうるＡＰＩ実装コンポーネントの１つ以上の関数、メソッド、クラス、オブジェクト、プロトコル、データ構造、フォーマット及び／又は他の機構を規定する。ＡＰＩ８８２０は、ＡＰＩ実装コンポーネント８８１０の関数がどのようにＡＰＩ呼び出し側コンポーネント８８３０からパラメータを受け取るか、及び関数がどのようにＡＰＩ呼び出し側コンポーネントに結果を返すかを規定する少なくとも１つの呼び出し規約を規定できる。ＡＰＩ呼び出し側コンポーネント８８３０（例えば、オペレーティングシステム、ライブラリ、デバイスドライバ、ＡＰＩ、アプリケーションプログラム、ソフトウェア又は他のモジュール）は、ＡＰＩ８８２０によって規定されるＡＰＩ実装コンポーネント８８１０の機能にアクセスして使用するために、ＡＰＩ８８２０を通じてＡＰＩ呼び出しを行う。ＡＰＩ実装コンポーネント８８１０は、ＡＰＩ呼び出しに応答してＡＰＩ８８２０を通じてＡＰＩ呼び出し側コンポーネント８８３０に値を返すことができる。

ＡＰＩ実装コンポーネント８８１０が、ＡＰＩ８８２０を通じて規定されず、ＡＰＩ呼び出し側コンポーネント８８３０が利用できないさらなる関数、メソッド、クラス、データ構造及び／又は他の機構を含んでもよいことが理解されよう。ＡＰＩ呼び出し側コンポーネント８８３０が、ＡＰＩ実装コンポーネント８８１０と同じシステム上にあってもよいし、リモートにあって、ネットワークを介してＡＰＩ８８２０を使用してＡＰＩ実装コンポーネント８８１０にアクセスしてもよいことを理解されたい。図８８は、ＡＰＩ８８２０と対話する単一のＡＰＩ呼び出し側コンポーネント８８３０を示しているが、ＡＰＩ呼び出し側コンポーネント８８３０とは異なる言語（又は同じ言語）で記述されうる他のＡＰＩ呼び出し側コンポーネントがＡＰＩ８８２０を使用してもよいことを理解されたい。

ＡＰＩ実装コンポーネント８８１０、ＡＰＩ８８２０及びＡＰＩ呼び出し側コンポーネント８８３０は機械可読媒体に格納でき、機械可読媒体は、機械（例えば、コンピュータ又は他のデータ処理システム）によって読み取り可能な形で情報を格納するためのいかなる機構も含む。例えば、機械可読媒体は、磁気ディスク、光ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリデバイスなどを含む。

図８９は、デュアルカメラモバイルコンピューティングデバイスアーキテクチャ８９００の一例である。モバイルコンピューティングデバイスの実装形態は、１つ以上の処理ユニット８９０５と、メモリインタフェース８９１０と、周辺機器インタフェース８９１５とを含むことができる。コンピューティングデバイスアーキテクチャを構成するこれらのコンポーネントのそれぞれは、別個のコンポーネントとすることもできるし、１つ以上の集積回路に統合することもできる。これらの種々のコンポーネントは、１つ以上の通信バス又は信号線によって、まとめて結合されることもできる。

周辺機器インタフェース８９１５は、カメラサブシステム８９２０、無線通信サブシステム（群）８９２５、オーディオサブシステム８９３０、Ｉ／Ｏサブシステム８９３５などを含む種々のセンサ及びサブシステムに結合されうる。周辺機器インタフェース８９１５により、プロセッサと周辺機器との間の通信が可能になる。方位センサ８９４５又は加速度センサ８９５０などの周辺機器は、向き及び加速度の機能を容易にするために周辺機器インタフェース８９１５に結合されうる。

カメラサブシステム８９２０は、１つ以上の光センサ８９４０、例えば電荷結合素子（ＣＣＤ）光センサ、相補型金属酸化膜半導体（ＣＭＯＳ）光センサに結合されうる。センサに結合されたカメラサブシステム８９２０は、画像及び／又はビデオのデータ取り込みなどのカメラの機能を容易にできる。無線通信サブシステム８９２５は、通信機能を容易にする働きをしうる。無線通信サブシステム８９２５は、無線周波数受信機と、無線周波数送信機と、光受信機と、光送信機とを含むことができる。無線通信サブシステムは、ＧＳＭネットワーク、Ｗｉ−Ｆｉネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワークなどの１つ以上の通信ネットワークで動作するように実施されうる。オーディオサブシステム８９３０は、オーディオ認識、デジタル記録などの音声対応機能を容易にするためにスピーカ及びマイクロフォンに結合される。

Ｉ／Ｏサブシステム８９３５は、ディスプレイ、タッチスクリーンなどの入出力周辺デバイスと、ＣＰＵのデータバスとの間の周辺機器インタフェースを通じた転送を含む。Ｉ／Ｏサブシステム８９３５は、タッチスクリーンコントローラ８９５５と、他の入力コントローラ８９６０とを含み、これらの機能を容易にできる。タッチスクリーンコントローラ８９５５は、タッチスクリーン８９６５に結合され、複数の接触感度技術のいずれかを使用して画面上での接触及び移動を検出できる。他の入力コントローラ８９６０は、１つ以上のボタンなどの他の入力／制御デバイスに結合されうる。

メモリインタフェース８９１０はメモリ８９７０に結合でき、メモリ８９７０は、高速ランダムアクセスメモリ及び／又はフラッシュメモリなどの不揮発性メモリを含むことができる。メモリは、オペレーティングシステム（ＯＳ）８９７２を格納できる。ＯＳ８９７２は、基本システムサービスを取り扱うため、及びハードウェアに依存するタスクを実行するための命令を含むことができる。

メモリは、１つ以上の追加デバイスとの通信を容易にするための通信命令８９７４と、グラフィックユーザインタフェース処理を容易にするためのグラフィカルユーザインタフェース命令８９７６と、画像／ビデオに関連する処理及び機能を容易にするための画像／ビデオ処理命令８９７８と、電話に関連するプロセス及び機能を容易にするための電話命令８９８０と、メディア通信及び処理に関連するプロセス及び機能を容易にするためのメディア交換及び処理命令８９８２と、カメラに関連するプロセス及び機能を容易にするためのカメラ命令８９８４と、テレビ会議プロセス及び機能を容易にするためのテレビ会議命令８９８６とも含むことができる。上記で識別された命令は、別個のソフトウェアプログラム又はモジュールとして実装される必要はない。モバイルコンピューティングデバイスの種々の機能は、１つ以上の信号処理及び／又は特定用途向け集積回路を含むハードウェア及び／又はソフトウェアで実装されうる。

上述の実施形態は、図９０に示すように、有線又は無線の通信チャネル９００２を介してコンピューティングシステム９００３と対話するためにタッチ入力を受け取り可能なタッチＩ／Ｏデバイス９００１を含むことができる。タッチＩ／Ｏデバイス９００１は、キーボード、マウスなどの他の入力デバイスの代わりに、又はこれと組み合わせて、コンピューティングシステム９００３にユーザ入力を提供するために使用されうる。１つ以上のタッチＩ／Ｏデバイス９００１は、コンピューティングシステム９００３にユーザ入力を提供するために使用されうる。タッチＩ／Ｏデバイス９００１は、コンピューティングシステム９００３の一体部分（例えば、ラップトップ上のタッチスクリーン）であってもよいし、コンピューティングシステム９００３とは別であってもよい。

タッチＩ／Ｏデバイス９００１は、全体的又は部分的に透過的、半透過的、非透過、不透明又はこれらの任意の組み合わせであるタッチセンサパネルを含むことができる。タッチＩ／Ｏデバイス９００１は、タッチスクリーン、タッチパッド、タッチパッドとして機能するタッチスクリーン（例えば、ラップトップのタッチパッドを置き換えるタッチスクリーン）、他の任意の入力デバイスと結合若しくは組み合わせたタッチスクリーン若しくはタッチパッド（例えば、キーボード上に配されたタッチスクリーン又はタッチパッド）、又はタッチ入力を受け取るためのタッチセンサ面を有する任意の多次元物体として実施されうる。

一例では、タッチスクリーンとして実施されたタッチＩ／Ｏデバイス９００１は、ディスプレイの少なくとも一部分の上に部分的又は全体的に配置された透過的及び／又は半透過的なタッチセンサパネルを含むことができる。この実施形態によれば、タッチＩ／Ｏデバイス９００１は、コンピューティングシステム９００３（及び／又は別のソース）から送られたグラフィカルデータを表示するように機能し、また、ユーザ入力を受け取るように機能する。他の実施形態では、タッチＩ／Ｏデバイス９００１は、タッチセンサコンポーネント／デバイスがディスプレイコンポーネント／デバイスと一体化された統合タッチスクリーンとして実施されうる。さらに他の実施形態では、タッチスクリーンは、補助又は同じグラフィカルデータを主要表示として表示してタッチ入力を受け取るための補助又は追加の表示画面として使用されうる。

タッチＩ／Ｏデバイス９００１は、容量測定、抵抗測定、光学測定、音響測定、誘導測定、機械的測定、化学的測定又はデバイス９００１近傍での１つ以上のタッチ又はニアタッチの発生に関して測定できるあらゆる現象に基づいて、デバイス９００１上の１つ以上のタッチ又はニアタッチの位置を検出するように構成されうる。ソフトウェア、ハードウェア、ファームウェア又はこれらの任意の組み合わせは、１つ以上のジェスチャーを識別して追跡する目的で、検出されたタッチの測定を処理するために使用されうる。ジェスチャーは、タッチＩ／Ｏデバイス９００１上での定常的又は非定常的な、単一又は複数の、タッチ又はニアタッチに対応してもよい。ジェスチャーは、本質的に同じ時刻に、隣接して又は連続して、タップする、押す、固定する、こする、捻る、向きを変更する、圧力を変化させて押すなどの、タッチＩ／Ｏデバイス９００１上で特定の方式で１つ以上の指又は他の物体を移動することによって実行されうる。ジェスチャーは、他の任意の１本以上の指で又は他の任意の１本以上の指により、挟む、スライドする、スワイプする、回転する、曲げる、ドラッグする又はタップする動きを特徴とできるが、これらに限定されない。単一のジェスチャーは、１つ以上の手を用いて、１人以上のユーザによって、又はこれらの任意の組み合わせによって実行されうる。

コンピューティングシステム９００３は、グラフィカルデータを用いて、ディスプレイにグラフィカルユーザインタフェース（ＧＵＩ）を表示させてもよい。ＧＵＩは、タッチＩ／Ｏデバイス９００１を介してタッチ入力を受け取るように構成されうる。タッチＩ／Ｏデバイス９００１は、タッチスクリーンとして実施されているので、ＧＵＩを表示できる。あるいは、ＧＵＩは、タッチＩ／Ｏデバイス９００１とは別のディスプレイに表示されうる。ＧＵＩは、インタフェース内の特定の位置に表示されるグラフィカル要素を含むことができる。グラフィカル要素は、仮想スクロールホイール、仮想キーボード、仮想ノブ、仮想ボタン、任意の仮想ＵＩなどを含む、表示される様々な仮想入力デバイスを含みうるが、これらに限定されない。ユーザは、ＧＵＩのグラフィカル要素と関連付けられうるタッチＩ／Ｏデバイス９００１上の１つ以上の特定の位置で、ジェスチャーを実行できる。他の実施形態では、ユーザは、ＧＵＩのグラフィカル要素の位置と無関係な１つ以上の位置でジェスチャーを実行できる。タッチＩ／Ｏデバイス９００１上で実行されるジェスチャーは、ＧＵＩ内のカーソル、アイコン、メディアファイル、リスト、テキスト、画像の前部又は一部などのグラフィカル要素を直接的又は間接的に操作し、制御し、変更し、移動し、作動し、開始し、又は一般に影響を及ぼすことができる。例えば、タッチスクリーンの場合に、ユーザは、タッチスクリーン上のグラフィカル要素を介してジェスチャーを実行することによって、グラフィカル要素と直接的に対話できる。あるいは、タッチパッドは、一般に間接的な対話を提供する。ジェスチャーはまた、表示されていないＧＵＩエレメントに影響を及してもよいし（例えば、ユーザインタフェースを表示させる）、又はコンピューティングシステム９００３内の他の動作に影響を及ぼしてもよい（例えば、ＧＵＩ、アプリケーション又はオペレーティングシステムの状態又はモードに影響を及ぼす）。ジェスチャーは、表示されるカーソルと共にタッチＩ／Ｏデバイス９００１上で実行されてもよいし、実行されなくてもよい。例えば、ジェスチャーがタッチパッド上で実行される場合に、カーソル（又はポインタ）は表示画面又はタッチスクリーンに表示されてもよく、カーソルは、表示画面上のグラフィカルオブジェクトと対話するためにタッチパッド上でのタッチ入力を介して制御されてもよい。ジェスチャーがタッチスクリーン上で直接的に実行される他の実施形態では、ユーザは、カーソル又はポインタがタッチスクリーンに表示されているかどうかにかかわらず、タッチスクリーン上のオブジェクトと直接的に対話できる。

タッチＩ／Ｏデバイス９００１上でのタッチ又はニアタッチに応答して又はこれに基づいて、通信チャネル９００２を介してユーザにフィードバックが提供されうる。フィードバックは、光学的に、機械的に、電気的に、嗅覚的に、音響的になど、又はこれらの任意の組み合わせで、可変的な又は非可変的な方式で送られうる。

上述したこれらの機能は、デジタル電子回路において、コンピュータソフトウェア、ファームウェア又はハードウェアにおいて実施されうる。技術は、１つ以上のコンピュータプログラムを使用して実施されうる。プログラム可能なプロセッサ及びコンピュータは、携帯デバイスに含まれるか又は携帯デバイスとしてパッケージ化されうる。プロセス及び論理フローは、１つ以上のプログラム可能なプロセッサによって、及び１つ以上のプログラム可能な論理回路によって実行されうる。通信ネットワークを通じて汎用コンピューティングデバイス及び記憶デバイス並びに専用コンピューティングデバイス及び記憶デバイスが相互接続されうる。

一部の実施形態は、（コンピュータ可読記憶媒体、機械可読媒体又は機械可読記憶媒体とも呼ばれる）機械可読媒体又はコンピュータ可読媒体にコンピュータプログラム命令を格納する、マイクロプロセッサ、記憶装置及びメモリなどの電子コンポーネントを含む。このようなコンピュータ可読媒体の一部の例は、ＲＡＭ、ＲＯＭ、リードオンリーコンパクトディスク（ＣＤ−ＲＯＭ）、レコーダブルコンパクトディスク（ＣＤ−Ｒ）、リライタブルコンパクトディスク（ＣＤ−ＲＷ）、リードオンリーデジタル多用途ディスク（例えば、ＤＶＤ−ＲＯＭ、２層ＤＶＤ−ＲＯＭ）、さまざまなリコーダブル／リライタブルＤＶＤ（例えば、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷなど）、フラッシュメモリ（例えば、ＳＤカード、ｍｉｎｉＳＤカード、ｍｉｃｒｏＳＤカードなど）、磁気ハードドライブ及び／又は固体ハードドライブ、リードオンリーＢｌｕ−Ｒａｙ（登録商標）ディスク及びレコーダブルＢｌｕ−Ｒａｙディスク、ＵＤＯ（ultra density optical）ディスク、他の任意の光媒体又は磁気媒体並びにフロッピーディスク（登録商標）を含む。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能で種々の動作を実行するための命令セットを含むコンピュータプログラムを格納できる。コンピュータプログラム又はコンピュータコードの例は、コンパイラによって生成されるような機械コード、及びインタプリタを使用してコンピュータ、電子コンポーネント又はマイクロプロセッサによって実行される高レベルコードを含むファイルを含む。

上記の説明は、主に、ソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサについて言及しているが、一部の実施形態は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つ以上の集積回路によって実行される。一部の実施形態では、このような集積回路は、回路自体に格納された命令を実行する。

本明細書及び本出願の任意の請求項において使用されている「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」という用語はいずれも、電子デバイス又は他の技術的デバイスを指す。これらの用語は、人又は人のグループを除外する。特定するために、「表示」又は「表示する」という用語は、電子デバイスに表示することを意味する。本明細書及び本出願の任意の請求項において使用されている「コンピュータ可読媒体」という用語は、コンピュータによって読み取り可能な形で情報を格納する有形の物理的な物体に完全に限定される。これらの用語は、いかなる無線信号、有線ダウンロード信号及び他の任意の一時的な（ephemeral）信号も除外する。

図９１は、一部の実施形態によるテレビ会議の何人かの参加者を接続するのに使用される例示的な通信システム９１００を概念的に示す。図示のように、通信システム９１００は、いくつかの携帯デバイス９１１５と、いくつかのセルラー基地局（又はノードＢ）９１１０と、いくつかの無線ネットワークコントローラ（ＲＮＣ）９１０５と、コアネットワーク９１２５とを含む。セルラー基地局及びＲＮＣは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上無線アクセスネットワーク（ＵＴＲＡＮ）９１３０と総称される。各ＲＮＣ９１０５は、１つ以上のセルラー基地局９１１０に接続され、合わせて無線アクセスネットワーク（ＲＡＮ）と呼ばれる。

各セルラー基地局９１１０は、サービス領域９１２０をカバーする。図示のように、各サービス領域内の携帯デバイス９１１５は、Ｕｕインタフェースを通じてサービス領域９１２０のサービングセルラー基地局９１１０に無線接続される。Ｕｕインタフェースは、２つのプレーン、すなわち制御プレーンとユーザプレーンとを有するプロトコルスタックを使用する。ユーザプレーンは、回線交換データストリーム、パケット交換データストリーム及びブロードキャストデータストリームをサポートする。制御プレーンは、ネットワークのシグナリングメッセージを搬送する。

各セルラー基地局は、Ｉｕｂインタフェースを通じてＲＮＣに接続される。各ＲＮＣ９１０５は、Ｉｕ−ｃｓインタフェース及びＩｕ−ｐｓインタフェースによってコアネットワーク９１２５に接続される。Ｉｕ−ｃｓインタフェースは回線交換サービス（例えば、音声）のために使用され、Ｉｕ−ｐｓインタフェースは、パケット交換サービス（例えば、データ）に使用される。Ｉｕｒインタフェースは、２つのＲＮＣを互いに接続するために使用される。

したがって、通信システム９１００は、回線交換サービスとパケット交換サービスとの両方をサポートする。例えば、回線交換サービスにより、通信システム９１００の回線交換機を通じて通話データ（例えば、音声）を伝送することによって、通話を行うことができる。パケット交換サービスにより、ＩＰのようなインターネット層プロトコルを介してＵＤＰ又はＴＣＰなどのトランスポートプロトコル層を使用して、通信システム９１００のパケット交換機を通じてテレビ会議データを伝送することによって、テレビ会議を行うことができる。一部の実施形態では、テレビ会議セットアップセクションで前述したテレビ会議への通話の移行（例えば、ハンドオフ）は、通信システム９１００のような通信システムによってサポートされる回線交換サービス及びパケット交換サービスを使用する。すなわち、このような実施形態では、通話は、通信システム９１００の回線交換機を通じて行われ、テレビ会議は、通信システム９１００のパケット交換機を通じて行われる。

図９１の例示的な通信システムは、第３世代（３Ｇ）技術であるＵＴＲＡＮ無線モバイル通信システムを示しているが、一部の実施形態では、会議の参加者の一部を接続するために、第２世代（２Ｇ）通信システム、３ＧＰＰ２エボリューションデータオプティマイズド／エボリューションデータオンリー（ＥＶ−ＤＯ）及び第３世代パートナシッププロジェクト２（３ＧＰＰ２）符号分割多元接続ＩＸ（ＣＤＭＡ ＩＸ）などの他の３Ｇ通信システム、第４世代（４Ｇ）通信システム、無線ローカルエリアネットワーク（ＷＬＡＮ）及びワールドワイドインタオペラビリティフォーマイクロ波接続（ＷｉＭＡＸ）通信システムを使用できることに留意されたい。２Ｇシステムの例は、グローバルシステムフォーモバイルコミュニケーション（ＧＳＭ）、汎用パケット無線サービス（ＧＰＲＳ）及びエンハンストデータレートフォーＧＳＭエボリューション（ＥＤＧＥ）を含む。２Ｇ通信システムアーキテクチャは、２Ｇ通信システムアーキテクチャがノードＢ９１１０の代わりに無線基地局装置（ＢＴＳ）を使用し、ＲＮＣ９１０５の代わりに基地局コントローラ（ＢＳＣ）を使用することを除いて、図９１に示されるアーキテクチャと同様である。２Ｇ通信システムでは、ＢＳＣとコアネットワークとの間のＡインタフェースが回線交換サービスに使用され、ＢＳＣとコアネットワークとの間のＧｂインタフェースがパケット交換サービスに使用される。

一部の実施形態では、通信システム９１００は、サービスキャリアによって運用され、サービスキャリアは、最初に、携帯デバイス９１１５をプロビジョニングして、携帯デバイス９１１５が通信システム９１００を使用できるようにする。一部の実施形態は、携帯デバイス９１１５に加入者識別モジュール（ＳＩＭ）カードを構成し登録することによって、携帯デバイス９１１５をプロビジョニングする。他の実施形態では、携帯デバイス９１１５は、そうではなく、携帯デバイス９１１５のメモリを使用して構成され登録される。さらに、（顧客が携帯デバイス９１１５を購入した後で）ＧＰＲＳ、マルチメディアメッセージサービス（ＭＭＳ）及びインスタントメッセージングのようなデータサービスなどの追加のサービスをプロビジョニングできる。携帯デバイス９１１５は、プロビジョニングされると、起動され、それによって、サービスキャリアによる通信システム９１００を使用できるようになる。

通信システム９１００は、一部の実施形態ではプライベート通信ネットワークである。このような実施形態では、携帯デバイス９１１５は、互い（例えば、通信システム９１００にプロビジョニングされた携帯デバイス９１１５）の間で通信する（例えば、音声通話を行う、データを交換する）ことができる。他の実施形態では、通信システム９１００はパブリック通信ネットワークである。したがって、携帯デバイス９１１５は、通信システム９１００にプロビジョニングされた携帯デバイス９１１５に加えて、通信システム９１００の外部にある他のデバイスと通信できる。通信システム９１００の外部にある他のデバイスのうちの一部は、電話機、コンピュータ及び公衆交換電話網又は別の無線通信ネットワークなどの他のネットワークを通じて通信システム９１００に接続された他のデバイスを含む。

ロングタームエボリューション（ＬＴＥ）仕様は、４Ｇ通信システムを規定するために使用される。図９２は、一部の実施形態によるテレビ会議の何人かの参加者を接続するのに使用される４Ｇ通信システム９２００の例を概念的に示す。図示のように、通信システム９２００は、いくつかの携帯デバイス９１１５と、いくつかの発展型ノードＢ（ｅＮＢ）９２０５と、モビリティ管理エンティティ（ＭＭＥ）９２１５と、サービングゲートウェイ（Ｓ−ＧＷ）９２２０と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ９２２５と、ホーム加入者サーバ（ＨＳＳ）９２３５とを含む。一部の実施形態では、通信システム９２００は、１つ以上のＭＭＥ９２１５と、１つ以上のＳ−ＧＷ９２２０と、１つ以上のＰＤＮゲートウェイ９２２５と、１つ以上のＨＳＳ９２３５とを含む。

ｅＮＢ９２０５は、携帯デバイス９１１５にエアインタフェースを提供する。図示のように、各ＮＢ９２０５はサービス領域９２１０をカバーする。各サービス領域９２１０内の携帯デバイス９１１５は、ＬＴＥ−Ｕｕインタフェースを通じてサービス領域９２１０のｅＮＢ９２０５に無線接続される。図９２は、Ｘ２インタフェースを通じて互いに接続されたｅＮＢ９２０５も示す。さらに、ｅＮＢ９２０５は、Ｓ１−ＭＭＥインタフェースを通じてＭＭＥ９２１５に接続され、Ｓ１−Ｕインタフェースを通じてＳ−ＧＷ９２２０に接続される。ｅＮＢ９２０５は、発展型ＵＴＲＡＮ（Ｅ−ＴＲＡＮ）９２３０と総称される。

ｅＮＢ９２０５は、無線リソース管理（例えば、無線ベアラ制御、接続モビリティ制御など）、Ｓ−ＧＷ９２２０へのユーザプレーンデータの経路制御、信号測定及び測定報告、携帯デバイスのアタッチ時のＭＭＥの選択などの機能を提供する。ＭＭＥ９２１５の機能は、アイドルモードの携帯デバイスの追跡及びページング、無線ベアラの起動及び停止、携帯デバイスのアタッチ時のＳ−ＧＷ９２２０の選択、非アクセスストラタム（ＮＡＳ）シグナリングの終了、ＨＳＳ９２３５との対話によるユーザ認証などを含む。

Ｓ−ＧＷ９２２０の機能は、（１）ユーザデータパケットの経路制御及び転送、並びに（２）ＩＰベアラサービスのパラメータ及びネットワーク内部ルーティング情報などの携帯デバイスコンテキストの管理及び格納を含む。ＰＤＮゲートウェイ９２２５の機能は、携帯デバイス宛てのトラフィックの出口と入口とであることによる、携帯デバイスから外部パケットデータネットワーク（不図示）への接続の提供がある。移動局は、複数のパケットデータネットワークにアクセスするために、複数のＰＤＮゲートウェイとの同時接続を有しうる。ＰＤＮゲートウェイ９２２５は、ＷｉＭＡＸと３ＧＰＰ２（例えば、ＣＤＭＡ ＩＸ及びＥＶ−ＤＯ）などの３ＧＰＰ技術と３ＧＰＰ以外の技術とのモビリティアンカーとしても機能する。

図示のように、ＭＭＥ９２１５は、Ｓ１１インタフェースを通じてＳ−ＧＷ９２２０に接続され、Ｓ６ａインタフェースを通じてＨＳＳ９２３５に接続される。Ｓ−ＧＷ９２２０とＰＤＮゲートウェイ９２２０とは、Ｓ８インタフェースを通じて接続される。ＭＭＥ９２１５、Ｓ−ＧＷ９２２０及びＰＤＮゲートウェイ９２２５は、発展型パケットコア（ＥＰＣ）と総称される。ＥＰＣは、３ＧＰＰ ＬＴＥ無線通信規格のコアネットワークアーキテクチャであるシステムアーキテクチャエボリューション（ＳＡＥ）アーキテクチャの主要なコンポーネントである。ＥＰＣは純粋なパケットシステムである。例えば、ＥＰＣは、音声メディアゲートウェイを有しない。音声及びＳＭＳのようなサービスは、パケット交換ルーティングされ、ＥＰＣサービスを利用するアプリケーション機能によって提供される。そのため、前述の通話からテレビ会議への移行を一例として使用すると、一部の実施形態では、通話とテレビ会議との両方が通信システム９２００のパケット交換機を通じて行われる。一部のこのような実施形態では、通話に使用されるパケット交換チャネルは、通話終了後のテレビ会議のオーディオデータに使用され続ける。しかし、他のこのような実施形態では、異なるパケット交換チャネルが（例えば、テレビ会議の確立時に）作成され、オーディオデータは、通話終了時の通話のパケット交換チャネルではなく、新たに作成されたパケット交換チャネルを通じて伝送される。

さらに、これらの異なる技術によって提供される帯域幅の量は、ＧＰＲＳの４４キロビット／秒（ｋｂｐｓ）からＬＴＥの１０メガビット／秒（Ｍｂｐｓ）超に及ぶ。ＬＴＥについては、将来的に、１００Ｍｂｐｓのダウンロード速度及び５０Ｍｂｐｓのアップロード速度が予測される。

多くの特定の詳細を参照して本発明を説明してきたが、本発明は、本発明の趣旨の範囲から逸脱することなく他の特定の形態で実現できることが当業者には理解されるだろう。さらに、いくつかの図は、プロセスを概念的に示している。これらのプロセスの特定の動作は、図示及び説明したとおりの順序で実行されなくてもよい。特定の動作は、１つの連続的な一連の動作で実行されなくてもよく、異なる実施形態で異なる特定の動作が実行されてもよい。そのうえ、プロセスは、いくつかのサブプロセスを使用して、又はより大きなマクロプロセスの一部として実施されうる。

また、多くの実施形態を、２つのデュアルカメラ携帯デバイス間のテレビ会議として上述した。しかし、これらの実施形態の多くが、デュアルカメラ携帯デバイスと、シングルカメラ携帯デバイス、コンピュータ、テレビ会議機能を有する電話機などの別のデバイスとの間でのテレビ会議を伴う場合に使用されることは、当業者には理解されよう。さらに、上述の実施形態の多くは、シングルカメラ携帯デバイス及びテレビ会議機能を有する他のコンピューティングデバイスにおいて使用できる。したがって、本発明は、上述の詳細によって限定されず、添付の請求の範囲によって規定されることが当業者には理解されよう。

Claims (20)

1. 命令セットを有するプログラムであって、前記命令セットは、カメラを備える第１モバイルデバイスによって実行された場合に、前記第１モバイルデバイスに、
   前記第１モバイルデバイスとテレビ会議中である第２モバイルデバイスへ前記第１モバイルデバイスの前記カメラによって撮影された画像を送信することと、
   前記第２モバイルデバイスの第１カメラによって撮影された画像を受信及び表示することと、
   カメラ切替え要求を示すグラフィカルユーザインタフェース（ＧＵＩ）オプションを選択するユーザ入力を前記テレビ会議中に受け取ることと、
   前記ユーザ入力を受け取ることに応じて、前記第２モバイルデバイスの第２カメラが起動され、前記第２モバイルデバイスが前記第１カメラによって撮影された前記画像の代わりに前記第２カメラによって撮影された画像を送信するカメラ切替え動作を実行するように前記第２モバイルデバイスへ命令するコマンドを前記第２モバイルデバイスへ送信することと、
   を行わせる、プログラム。
2. 前記ＧＵＩオプションの前記選択は、フィンガー・タップを含む、請求項１に記載のプログラム。
3. 前記第１カメラは、前記第２モバイルデバイスの前面カメラを含み、前記第２カメラは、前記第２モバイルデバイスの背面カメラを含む、請求項１に記載のプログラム。
4. 前記第２モバイルデバイスの前記第１カメラは、前記第２モバイルデバイスの背面カメラを含み、前記第２カメラは、前記第２モバイルデバイスの前面カメラを含む、請求項１に記載のプログラム。
5. 前記第１モバイルデバイスによって実行された場合に、前記第１モバイルデバイスに、
   前記第２モバイルデバイスの前記第２カメラによって撮影された前記画像を受信し、
   前記第２モバイルデバイスの前記第１カメラによって撮影された前記画像の表示から、前記第２モバイルデバイスの前記第２カメラによって撮影された前記画像の表示に切り替えることと、
   前記第２モバイルデバイスの前記第２カメラによって撮影された前記画像を表示する前に、回転アニメーションを表示することと、
   を行わせる命令セットをさらに有する、請求項１に記載のプログラム。
6. 前記第１モバイルデバイスの前記カメラによって撮影された前記画像が前記第２モバイルデバイスの前記第１カメラによって撮影された前記表示された画像の少なくとも一部に重なるように、前記第１モバイルデバイスの前記カメラによって撮影された前記画像を前記第１モバイルデバイスで表示するための命令セットを更に有する、請求項１に記載のプログラム。
7. 関心領域は、前記第１モバイルデバイスのグラフィカルユーザインタフェースを通じて受信される、請求項１に記載のプログラム。
8. 前記第１モバイルデバイスは表示画面を更に備え、前記コマンドを送信するための前記命令セットは、前記第１モバイルデバイスの前記表示画面上の前記ＧＵＩオプションのタッチ入力を受信したことに応じて前記コマンドを送信するための命令セットを含む、請求項１に記載のプログラム。
9. テレビ会議中に第１モバイルデバイスが第２モバイルデバイスをリモートから制御することを可能にするための方法であって、
   前記第１モバイルデバイスの表示画面に表示されるグラフィカルユーザインタフェース（“ＧＵＩ”）に、前記第２モバイルデバイスの第１カメラによって撮影された画像を表示することと、
   カメラ切替え要求を示す前記ＧＵＩでのユーザ選択を受け取ることと、
   前記カメラ切替え要求を示す前記ＧＵＩでの前記ユーザ選択を受け取ることに応じて、前記第２モバイルデバイスの第２カメラが起動され、前記第２モバイルデバイスが前記第１カメラによって撮影された前記画像の代わりに前記第２カメラによって撮影された画像を送信するカメラ切替え動作を前記テレビ会議中に実行するように前記第２モバイルデバイスに前記第１モバイルデバイスを介して指示することと、
   前記第１モバイルデバイスの前記表示画面に前記第２カメラによって撮影された前記画像を表示することと、
   を有する方法。
10. 前記ＧＵＩでの前記ユーザ選択は、フィンガー・タップを含む、請求項９に記載の方法。
11. 前記ＧＵＩでの前記ユーザ選択は、前記第２モバイルデバイスの前面カメラビューから背面カメラビューへの切替えを可能にする、請求項９に記載の方法。
12. 前記ＧＵＩでの前記ユーザ選択は、前記第２モバイルデバイスの背面カメラビューから前面カメラビューへの切替えを可能にする、請求項９に記載の方法。
13. 前記第２カメラによって撮影された前記画像を表示する前に、前記第１モバイルデバイスの前記表示画面を介して、回転アニメーションを表示することをさらに有する、請求項９に記載の方法。
14. 前記回転アニメーションは、前記第２モバイルデバイスの前記第１カメラによって撮影された前記画像を段階的に縮小することと、それに続く前記第２モバイルデバイスの前記第２カメラによって撮影された前記画像の前記表示の段階的な拡大とを含む、請求項１３に記載の方法。
15. 第１モバイルデバイスについて、テレビ会議中に第２モバイルデバイスが前記第１モバイルデバイスをリモートから制御することを可能にするためのプログラムを規定する方法であって、
    前記第１モバイルデバイスの第１カメラによって撮影された第１ビデオを前記第１モバイルデバイスを介して前記第２モバイルデバイスへ送信することと、
    前記第１モバイルデバイスでのカメラ切替え要求を前記テレビ会議中に前記第２モバイルデバイスから受信することと、
    前記カメラ切替え要求を受信することに応じて、前記第１モバイルデバイスの第２カメラが起動され、前記第１モバイルデバイスが前記第１カメラによって撮影された前記第１ビデオの代わりに前記第２カメラによって撮影された第２ビデオを送信するカメラ切替え動作を実行することと、
    を有する方法。
16. 前記テレビ会議中に前記第１モバイルデバイスの第２ネットワークマネージャへ前記カメラ切替え要求を中継する前記第２モバイルデバイスのための第１ネットワークマネージャを規定することを更に有する、請求項１５に記載の方法。
17. 前記第１ネットワークマネージャは、インターネットプロトコル（“ＩＰ”）を介して送信されたパケットを通じて前記テレビ会議中に前記第２ネットワークマネージャへデータを中継し、前記パケットは、前記第２モバイルデバイスの前記動作を制御するために前記第１モバイルデバイスで受信された入力データを中継するための制御パケットを含む、請求項１６に記載の方法。
18. 前記カメラ切替え要求を受信することに応じて、前記第１カメラから前記第２カメラへの切替えを示す通知を前記第１モバイルデバイスによって前記第２モバイルデバイスへ提供することをさらに有する、請求項１５に記載の方法。
19. 前記第２モバイルデバイスから前記カメラ切替え要求を受信することに応じて、カメラ切替えを許可するか拒否するかの確認プロンプトを提供することと、
    前記カメラ切替えを許可することのインジケーションを前記確認プロンプトを介して受け取ることに応じて、前記第１ビデオの代わりに前記第２ビデオを送信することと、をさらに有する、請求項１５に記載の方法。
20. 前記第１カメラと前記第２カメラとは、前記第１モバイルデバイスの互いに反対側に配置されている、請求項１５に記載の方法。

Images