特許 6000258 スマートパッド方向付け

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6000258

(24)【登録日】2016年9月9日

(45)【発行日】2016年9月28日

(54)【発明の名称】スマートパッド方向付け

(51)【国際特許分類】

   G06F 3/0487 20130101AFI20160915BHJP

   G06F 3/14 20060101ALI20160915BHJP

   G09G 5/00 20060101ALI20160915BHJP

   G09G 5/36 20060101ALI20160915BHJP

【ＦＩ】

   G06F3/0487

   G06F3/14 350A

   G06F3/14 310C

   G09G5/00 550C

   G09G5/00 510V

   G09G5/00 555D

   G09G5/00 510H

   G09G5/36 520K

【請求項の数】19

【全頁数】71

(21)【出願番号】特願2013-531866(P2013-531866)

(86)(22)【出願日】2011年9月29日

(65)【公表番号】特表2013-546050(P2013-546050A)

(43)【公表日】2013年12月26日

(86)【国際出願番号】US2011054039

(87)【国際公開番号】WO2012044839

(87)【国際公開日】20120405

【審査請求日】2014年9月5日

(31)【優先権主張番号】61/458,150

(32)【優先日】2010年11月17日

(33)【優先権主張国】US

(31)【優先権主張番号】61/389,117

(32)【優先日】2010年10月1日

(33)【優先権主張国】US

(31)【優先権主張番号】61/539,884

(32)【優先日】2011年9月27日

(33)【優先権主張国】US

(31)【優先権主張番号】13/247,581

(32)【優先日】2011年9月28日

(33)【優先権主張国】US

(31)【優先権主張番号】61/389,087

(32)【優先日】2010年10月1日

(33)【優先権主張国】US

(31)【優先権主張番号】61/389,000

(32)【優先日】2010年10月1日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】513080542

【氏名又は名称】ゼット１２４

【氏名又は名称原語表記】Ｚ１２４

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】サーパル、サンジブ

(72)【発明者】

【氏名】ギンプル、マーティン

(72)【発明者】

【氏名】ヴィソスキー、ジョン スティーブン

【審査官】 西田 聡子

(56)【参考文献】

【文献】 特開２００４−３３４８６５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０２４５２０９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００７／０１２０７６３（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０１３８７８０（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０４８７

Ｇ０６Ｆ ３／１４

Ｇ０９Ｇ ５／００

Ｇ０９Ｇ ５／３６

(57)【特許請求の範囲】

【請求項1】

スマートパッドであって、
画面と、
ディスプレイと、
ジェスチャ捕捉エリアと、
少なくとも１つのユーザ構成可能エリアと、
を備え、前記スマートパッドは、デバイスにドッキング可能であり、前記デバイスは、２つの接続された画面を有し、前記スマートパッドは、前記２つの接続された画面からのコンテンツを前記画面に表示可能であり、
前記コンテンツは、前記デバイス内の加速度計からの前記デバイスおよび前記スマートパッドの向きに関する入力に基づいて前記画面に表示され、
前記デバイスの画面の向きは、前記スマートパッドの向きに自動的に合わせられる、スマートパッド。

【請求項2】

ドッキングインタフェースをさらに備え、前記ドッキングインタフェースは、前記デバイスを受け、前記スマートパッドと前記デバイスとの間に電気通信を提供するように構成されている、請求項１に記載のスマートパッド。

【請求項3】

前記ディスプレイは、タッチスクリーンディスプレイである、請求項１に記載のスマートパッド。

【請求項4】

前記スマートパッドは、縦向きモード及び横向きモードを有する、請求項１に記載のスマートパッド。

【請求項5】

前記デバイスが、前記スマートパッドにドッキングされると、前記デバイスに表示された１つまたは複数のアプリケーションは、前記スマートパッドで表示されるように方向付けられる、請求項１に記載のスマートパッド。

【請求項6】

前記スマートパッドは、前記ディスプレイを少なくとも２つの論理的な部分に分割する、請求項１に記載のスマートパッド。

【請求項7】

前記論理的な部分のうちの第１の部分は、前記デバイスからの第１のアプリケーションを表示し、前記論理的な部分のうちの第２の部分は、前記デバイスからの第２のアプリケーションを表示する、請求項６に記載のスマートパッド。

【請求項8】

前記スマートパッドは、単一アプリケーションモードを有し、前記単一アプリケーションモードは、アプリケーションを全画面で表示する、請求項１に記載のスマートパッド。

【請求項9】

前記単一アプリケーションモードは、前記アプリケーションを最大モードで表示する、請求項８に記載のスマートパッド。

【請求項10】

最大モードにおいて、前記アプリケーションは、前記スマートパッドと同じ向きに方向付けられる、請求項９に記載のスマートパッド。

【請求項11】

カメラ、ビデオカメラ、マイクロホン、電力ボタン、ホームボタン、スピーカ、ＡＣアダプタジャック、及びヘッドホンジャックのうちの１つまたは複数をさらに備える、請求項１に記載のスマートパッド。

【請求項12】

方法であって、
スマートパッドをデバイスにドッキングすることであって、前記スマートパッドは、画面、ディスプレイ、ジェスチャ捕捉エリア、及び少なくとも１つのユーザ構成可能エリアを含み、前記デバイスは２つの接続された画面を有する、前記ドッキングすること、
前記２つの接続された画面からのコンテンツを前記スマートパッドの画面に表示すること
を含み、
前記コンテンツは、前記デバイス内の加速度計からの前記デバイスおよび前記スマートパッドの向きに関する入力に基づいて前記画面に表示され、
前記デバイスの画面の向きは、前記スマートパッドの向きに自動的に合わせられる、方法。

【請求項13】

前記スマートパッドのドッキングインタフェースにおいて、前記デバイスを受けることをさらに含み、前記ドッキングインタフェースは、前記デバイスを受け、前記スマートパッドと前記デバイスとの間に電気通信を提供するように構成されている、請求項１２に記載の方法。

【請求項14】

前記ディスプレイは、タッチスクリーンディスプレイである、請求項１２に記載の方法。

【請求項15】

前記スマートパッドは、縦向きモード及び横向きモードを有する、請求項１２に記載の方法。

【請求項16】

前記デバイスが前記スマートパッドにドッキングされると、前記デバイスに表示された１つまたは複数のアプリケーションは、前記スマートパッドで表示されるように方向付けられる、請求項１２に記載の方法。

【請求項17】

前記スマートパッドは、前記ディスプレイを少なくとも２つの論理的な部分に分割する、請求項１２に記載の方法。

【請求項18】

前記論理的な部分のうちの第１の部分は、前記デバイスからの第１のアプリケーションを表示し、前記論理的な部分のうちの第２の部分は、前記デバイスからの第２のアプリケーションを表示する、請求項１７に記載の方法。

【請求項19】

前記スマートパッドは単一アプリケーションモードを有し、前記単一アプリケーションモードは、アプリケーションを全画面で表示する、請求項１２に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、スマートパッド方向付け（ｏｒｉｅｎｔａｔｉｏｎ）に関する。

【背景技術】

【0002】

携帯電話、タブレット及びＥリーダ（Ｅ−Ｒｅａｄｅｒ）などのかなりの数の携帯用コンピューティングデバイスは、タッチスクリーンディスプレイを利用して、単にユーザに表示情報を配信するばかりでなく、ユーザインタフェースコマンドからの入力の受信も行う。タッチスクリーンディスプレイは、携帯用デバイスのコンフィギュアビリティを増加し、多種多様なユーザインタフェースオプションを提供することができるが、通常、この柔軟性は高くつく。コンテンツを提供し、ユーザコマンドを受信するタッチスクリーンの二重用途は、ユーザにとっては柔軟性があるが、ディスプレイが難読化し、視覚的クラッタが発生し、それはユーザフラストレーション及び生産性損失の原因となる恐れがある。

【0003】

携帯用コンピューティングデバイスの小さなフォームファクタは、表示されたグラフィックスと入力受信用に設けられたエリアとの間の慎重なバランス維持を必要とする。一方では、小型のディスプレイは表示スペースを制約し、それにより、動作または結果の解釈の困難が増す恐れがある。他方では、仮想キーパッドまたは他のユーザインタフェーススキームは、実行アプリケーション上で重ね合わせるか、または、実行アプリケーションに隣接して配置され、その結果、アプリケーションをディスプレイのさらに小さな部分に詰め込む必要がある。

【0004】

このバランス維持行為は、単一ディスプレイのタッチスクリーンデバイスでは特に難しい。単一ディスプレイのタッチスクリーンデバイスは、それらの限られた画面スペースにより不具合が生じる。単一ディスプレイを通じてユーザがデバイスに情報を入力すると、特に、ディスプレイとインタフェースとの間の複雑な相互作用が必要とされる場合は、ディスプレイ内の情報を解釈する能力が大幅に妨げられる恐れがある。

【発明の概要】

【課題を解決するための手段】

【0005】

従来の単一ディスプレイの携帯用コンピューティングデバイスと比較して、パワーの増強及び／または多様性の向上を実現するデュアルマルチディスプレイの携帯用コンピューティングデバイスが必要である。これらの及び他の必要性は、本開示のさまざまな態様、実施形態及び／または構成によって対応する。また、本開示は、例示的な実施形態について提示しているが、本開示の個々の態様を別々に請求できることを理解されたい。

【0006】

さらに、複数ディスプレイデバイスを追加のデバイスとドッキング可能または他の様式で関連付け可能なことが望ましい。例示的な一実施形態によれば、複数ディスプレイデバイスはスマートパッドとドッキング可能である。例示的なスマートパッドは、画面と、タッチセンサ式ディスプレイと、構成可能エリアと、ジェスチャ捕捉領域と、カメラとを含むことができる。スマートパッドは、デバイスを受けるように構成されたポートを含むこともできる。例示的なスマートパッドは、デバイスに表示可能な情報がスマートパッドにも表示可能なようにデバイスと協働可能である。さらに、デバイス上の機能のうちの任意の１つまたは複数はスマートパッドに拡張可能であり、スマートパッドは、スマートパッドの入／出力インタフェースまたは拡張として動作することが可能である。したがって、例えば、複数画面デバイス上の表示のうちの１つまたは複数からの情報は、スマートパッドに表示可能である。

【0007】

したがって、例示的な態様は、画面と、ディスプレイと、ジェスチャ捕捉エリアと、少なくとも１つのユーザ構成可能エリアとを備えるスマートパッドであって、スマートパッドがデバイスとドッキング可能であり、デバイスは２つの接続された画面を有し、スマートパッドは、２つの接続された画面からのコンテンツを画面に表示可能である、スマートパッドに関する。

【0008】

別の例示的な態様は、スマートパッドをデバイスにドッキングすることであって、スマートパッドは画面、ディスプレイ、ジェスチャ捕捉エリア、及び少なくとも１つのユーザ構成可能エリアを備え、デバイスは２つの接続された画面を有する、ドッキングすること、並びに２つの接続された画面からのコンテンツをスマートパッドの画面に表示することを含む方法に関する。

【0009】

本開示は、特定の態様、実施形態、及び／または構成に応じていくつかの利点を提供することができる。
例えば、スマートパッドは、追加の表示エリアを提供して、デバイスでのユーザによるコンテンツの閲覧を補助することができる。

【0010】

さらに、例えば、蓄電に使用することができるスマートパッドのサイズが大きいことにより、電力共有・管理機能が利用可能である。
さらに、スマートパッドでは、通信デバイスの機能をタブレットのようなプラットフォーム及び／またはフォームファクタに拡張することができる。

【0011】

さらに、本開示は、複数ディスプレイデバイス用のコンテンツを単一画面デバイス用のコンテンツに翻訳または他の様式で変換することに関する技法を提供する。
さらに、スマートパッドは、タッチスクリーンの入力を超える入力を受信するように構成された追加の入力エリアを提供する。

【0012】

さらなる利点は、複数ディスプレイデバイス上の１つまたは複数のアプリケーションに関連付けられた１つまたは複数のウィンドウの、単一ディスプレイデバイスでの表示の管理に関する。

【0013】

さらなる利点は、複数画面コンテンツの単一画面デバイスでのエミュレーションに関する。
これらの及び他の利点は、本開示から明らかになるであろう。

【0014】

「少なくとも１つ」、「１つまたは複数」、及び「及び／または」との記載は、使用中、接続語かつ離接語である非限定的な（ｏｐｅｎ−ｅｎｄｅｄ）表現である。例えば、「Ａ、Ｂ及びＣの少なくとも１つ」、「Ａ、ＢまたはＣの少なくとも１つ」、「Ａ、Ｂ及びＣのうちの１つまたは複数」、「Ａ、ＢまたはＣのうちの１つまたは複数」及び「Ａ、Ｂ及び／またはＣ」の表現の各々は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢともに、ＡとＣともに、ＢとＣともに、または、ＡとＢとＣともに、を意味する。

【0015】

「１つの」、「１つまたは複数」及び「少なくとも１つ」との記載は、本明細書では交換可能に使用することができる。用語「備える」、「含む」及び「有する」もまた交換可能に使用できることに留意されたい。

【0016】

用語「自動」及びその変形語は、本明細書で使用する場合、プロセスまたはオペレーションを実行する際に、実質的な人的入力なしで行われる任意のプロセスまたはオペレーションを指す。しかし、プロセスまたはオペレーションの実行前に入力を受信すれば、プロセスまたはオペレーションの実行において実質的または非実質的な人的入力を使用しても、プロセスまたはオペレーションは自動であり得る。人的入力は、そのような入力がプロセスまたはオペレーションの実行方法に影響を及ぼす場合は、実質的と見なされる。プロセスまたはオペレーションの実行を受け入れる人的入力は、「実質的」とは見なされない。

【0017】

用語「コンピュータ可読媒体」は、本明細書で使用する場合、実行のためのプロセッサへの命令の提供に参加する任意の有形の記憶及び／または伝送媒体を指す。そのような媒体は、これらに限定されないが、不揮発性媒体、揮発性媒体及び伝送媒体を含む多くの形式を取り得る。不揮発性媒体は、例えば、ＮＶＲＡＭまたは磁気もしくは光ディスクを含む。揮発性媒体は、メインメモリなどのダイナミックメモリを含む。コンピュータ可読媒体の一般的な形式は、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープもしくは任意の他の磁気媒体、光磁気記録媒体、ＣＤ−ＲＯＭ、任意の他の光媒体、パンチカード、紙テープ、任意の他の孔パターンの物理的な媒体、ＲＡＭ、ＰＲＯＭ及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカードのようなソリッドステート媒体、任意の他のメモリチップもしくはカートリッジ、以下で説明する搬送波、または、コンピュータが読み取ることができる任意の他の媒体を含む。Ｅメールに添付するデジタルファイルまたは他の自己内蔵情報アーカイブもしくはアーカイブセットは、有形の記憶媒体と同等の配信媒体と考えられる。コンピュータ可読媒体がデータベースとして構成される場合、データベースは、関係型、階層型、オブジェクト指向型及び／または同様のものなどの任意のタイプのデータベースであり得ることを理解されたい。それに応じて、本開示は、本開示のソフトウェア実装形態が格納される有形の記憶媒体または配信媒体及び先行技術分野において承認されている均等物及び後続媒体を含むと考えられる。

【0018】

用語「デスクトップ」は、システムを表現するために使用される例え（ｍｅｔａｐｈｏｒ）を指す。デスクトップは、一般に、アイコン、ウィジェット、フォルダなどと呼ばれる絵柄を含む「面」と考えられ、通常、その上でアプリケーション、ウィンドウ、キャビネット、ファイル、フォルダ、ドキュメント、他のグラフィカルなアイテムを起動または表示することができる。アイコンは、一般に、ユーザインタフェース相互作用を通じてタスクに着手するように選択可能であり、ユーザは、アプリケーションを実行することも、他のオペレーションを行うこともできる。

【0019】

用語「画面」、「タッチスクリーン（ｔｏｕｃｈ ｓｃｒｅｅｎまたはｔｏｕｃｈｓｃｒｅｅｎ）」は、ユーザインタフェースをレンダリングする及び／またはユーザ入力を受信する能力をデバイスに提供する１つまたは複数のハードウェアコンポーネントを含む物理的構造を指す。画面は、ジェスチャ捕捉領域、タッチセンサ式ディスプレイ及び／または構成可能なエリアの任意の組合せを包含し得る。デバイスは、ハードウェアに組み込まれた１つまたは複数の物理的画面を有し得る。しかし、画面は、デバイスから着脱可能な外部の周辺デバイスも含み得る。実施形態では、複数の外部のデバイスをデバイスに取り付けることができる。したがって、実施形態では、画面は、ユーザが画面上のエリアに触れることでデバイスと情報のやり取りを行うことを可能にし、ディスプレイを通じてユーザに情報を提供する。タッチスクリーンは、電気的パラメータ（例えば、抵抗またはキャパシタンス）の変化、音波の変動、赤外線近接検出、変光検出及び同様のものなどの多くの異なる方法でユーザの接触を感知することができる。抵抗性タッチスクリーンでは、例えば、通常、画面内の別々の導電性及び抵抗性金属層が電流を通過させる。ユーザが画面に触れると、触れた位置で２つの層が接触し、それにより、電界の変化が見られ、触れた位置の座標が計算される。容量性タッチスクリーンでは、容量性層が電荷を蓄積し、電荷はユーザがタッチスクリーンに触れると同時に放電され、それにより、容量性層の電荷が低減する。その低減が測定され、触れた位置の座標が決定される。表面音波タッチスクリーンでは、画面を通じて音波が伝播され、音波はユーザ接触によって妨げられる。受信用トランスデューサは、ユーザ接触インスタンスを検出し、触れた位置の座標を決定する。

【0020】

用語「ディスプレイ」は、コンピュータの出力をユーザに表示するために使用される１つまたは複数の画面の一部分を指す。ディスプレイは、単一画面ディスプレイまたは複合ディスプレイと呼ばれる複数画面ディスプレイであり得る。複合ディスプレイは、１つまたは複数の画面のタッチセンサ式ディスプレイを包含し得る。単一の物理的画面は、別々の論理的ディスプレイとして管理される複数のディスプレイを含み得る。したがって、同じ物理的画面の一部ではあるが別々のディスプレイ上に異なるコンテンツを表示することができる。

【0021】

用語「表示画像」は、ディスプレイ上に生成された画像を指す。典型的な表示画像は、ウィンドウまたはデスクトップである。表示画像は、ディスプレイの全体または一部を占有することができる。

【0022】

用語「ディスプレイ方向」は、閲覧のためにユーザが長方形のディスプレイを方向付ける方法を指す。ディスプレイ方向の２つの最も一般的なタイプは、縦向き（ｐｏｒｔｒａｉｔ）と横向き（ｌａｎｄｓｃａｐｅ）である。横向きモードでは、ディスプレイは、ディスプレイの幅がディスプレイの高さよりも大きくなるように方向付けられる（幅４単位及び高さ３単位の４：３の割合または幅１６単位及び高さ９単位の１６：９の割合など）。別の言い方をすれば、横向きモードでは、ディスプレイの長い方の寸法は、実質的に水平の方向に方向付けられ、ディスプレイの短い方の寸法は、実質的に垂直の方向に方向付けられる。対照的に、縦向きモードでは、ディスプレイの幅がディスプレイの高さよりも小さくなるように方向付けられる。別の言い方をすれば、縦向きモードでは、ディスプレイの短い方の寸法は、実質的に水平の方向に方向付けられ、ディスプレイの長い方の寸法は、実質的に垂直の方向に方向付けられる。

【0023】

用語「複合ディスプレイ」は、１つまたは複数の画面を包含することができるディスプレイを定義する論理的構造を指す。複数画面ディスプレイは、すべての画面を包含する複合ディスプレイに関連付けられ得る。複合ディスプレイは、デバイスのさまざまな向きに基づいて異なる表示特性を有し得る。

【0024】

用語「ジェスチャ」は、意図する考え、動作、意味、結果及び／または成果を表現するユーザ動作を指す。ユーザ動作は、デバイスの操作（例えば、デバイスの開閉、デバイスの向きの変更、トラックボールまたはホイールの移動など）、デバイスに対する身体部分の動き、デバイスに対する道具またはツールの動き、音声入力などを含み得る。ジェスチャは、デバイス上（画面上など）に、またはデバイスを用いて行われ、デバイスと相互作用することができる。

【0025】

用語「モジュール」は、本明細書で使用する場合、任意の公知のまたは後に開発されたハードウェア、ソフトウェア、ファームウェア、人工知能、ファジィ理論、または、その要素に関連付けられた機能を実行することができるハードウェアとソフトウェアとの組合せを指す。

【0026】

用語「ジェスチャ捕捉」は、ユーザジェスチャのインスタンス及び／またはタイプの感知または別の方法での検出を指す。ジェスチャ捕捉は、画面の１つまたは複数のエリアで起こり得る。ジェスチャ領域は、タッチセンサ式ディスプレイと呼ばれる場合があるディスプレイ上またはジェスチャ捕捉エリアと呼ばれる場合があるディスプレイ外であり得る。

【0027】

「複数画面アプリケーション」は、複数のモードが可能なアプリケーションを指す。複数画面アプリケーションモードは、これらに限定されないが、単一画面モード（アプリケーションは単一画面に表示される）または複合ディスプレイモード（アプリケーションは２つ以上の画面に表示される）を含み得る。複数画面アプリケーションは、モードに対して最適化された異なるレイアウトを有し得る。したがって、複数画面アプリケーションは、単一画面に対してまたは２つ以上の画面を包含し得る複合ディスプレイに対して異なるレイアウトを有し得る。異なるレイアウトは、複数画面アプリケーションのユーザインタフェースをレンダリングすることができる異なる画面／ディスプレイ寸法及び／または構成を有し得る。異なるレイアウトにより、アプリケーションは、ディスプレイのタイプ、例えば、単一画面または複数画面に対して、アプリケーションのユーザインタフェースを最適化することができる。単一画面モードでは、複数画面アプリケーションは、情報の１つのウィンドウ枠を提示することができる。複合ディスプレイモードでは、複数画面アプリケーションは、表示コンテンツに対してより多くのスペースがあるため、情報の複数のウィンドウ枠を提示することも、より大きくより豊かなプレゼンテーションを提供することもできる。複数画面アプリケーションは、システムがどのディスプレイ（単一または複合）を複数画面アプリケーションに割り当てるかに応じて、デバイス及びモードの変化に動的に適合させるように設計することができる。代替の実施形態では、ユーザは、ジェスチャを使用して、異なるモードへのアプリケーションの移行を要求することができ、要求されたモードに対してディスプレイが利用可能な場合は、デバイスは、アプリケーションをそのディスプレイ及び移行モードに移動させることができる。

【0028】

「単一画面アプリケーション」は、単一の画面モードが可能なアプリケーションを指す。したがって、単一画面アプリケーションは、１つのウィンドウしか生成することができず、異なるモードも、異なるディスプレイ寸法も可能ではない可能性がある。単一画面アプリケーションは、複数画面アプリケーションで論じられたいくつかのモードでの実行は不可能であり得る。

【0029】

用語「ウィンドウ」は、ディスプレイの少なくとも一部に表示された典型的に長方形の画像を指し、画面の残りの部分とは異なるコンテンツを含むまたは提供する。ウィンドウは、デスクトップを覆い隠す場合がある。

【0030】

用語「決定する、判断する」、「計算する」及び「演算する」ならびにその変形語は、本明細書で使用する場合、交換可能に使用され、任意のタイプの方法論、プロセス、数学演算または技法を含む。

【0031】

用語「手段」は、本明細書で使用する場合、米国特許法第１１２条第６段落に従って、その可能な限り最も広い解釈が与えられるものとすることを理解されたい。それに応じて、用語「手段」を組み込む請求項は、本明細書に記載されるすべての構造、材料または行為及びその均等物のすべてを対象とするものとする。さらに、構造、材料または行為及びその均等物は、発明の概要、図面の簡単な説明、発明を実施するための形態、要約書及び特許請求の範囲自体で説明されたすべてのものを含むものとする。

【0032】

前述の説明は、本開示の簡略化した概要であり、本開示のいくつかの態様の理解を与える。この概要は、本開示の概要ならびにそのさまざまな態様、実施形態及び／または構成の広範なものでも包括的なものでもない。この概要は、本開示の主要な、または重要な要素を特定することも、本開示の範囲を詳しく説明することも意図しないが、以下で提示するより詳細な説明の導入部として、本開示の選択された概念を簡素化した形式で提示することを意図する。理解されるように、本開示の他の態様、実施形態及び／または構成は、単独でまたは組み合わせて、上記で記載されるかまたは以下で詳細に説明される特徴の１つまたは複数を利用することができる。

【図面の簡単な説明】

【0033】

【図1A】複数画面ユーザデバイスの実施形態の第１の図を含む。

【図1B】複数画面ユーザデバイスの実施形態の第２の図を含む。

【図1C】複数画面ユーザデバイスの実施形態の第３の図を含む。

【図1D】複数画面ユーザデバイスの実施形態の第４の図を含む。

【図1E】複数画面ユーザデバイスの実施形態の第５の図を含む。

【図1F】複数画面ユーザデバイスの実施形態の第６の図を含む。

【図1G】複数画面ユーザデバイスの実施形態の第７の図を含む。

【図1H】複数画面ユーザデバイスの実施形態の第８の図を含む。

【図1I】複数画面ユーザデバイスの実施形態の第９の図を含む。

【図1J】複数画面ユーザデバイスの実施形態の第１０の図を含む。

【図2】デバイスのハードウェアの実施形態のブロック図である。

【図3A】デバイスの向き及び／または構成に基づくデバイスの状態モデルの実施形態のブロック図である。

【図3B】デバイスの向き及び／または構成に基づくデバイスの状態モデルの実施形態の表である。

【図4A】デバイスにおいて受信されたユーザジェスチャの実施形態の第１の表現である。

【図4B】デバイスにおいて受信されたユーザジェスチャの実施形態の第２の表現である。

【図4C】デバイスにおいて受信されたユーザジェスチャの実施形態の第３の表現である。

【図4D】デバイスにおいて受信されたユーザジェスチャの実施形態の第４の表現である。

【図4E】デバイスにおいて受信されたユーザジェスチャの実施形態の第５の表現である。

【図4F】デバイスにおいて受信されたユーザジェスチャの実施形態の第６の表現である。

【図4G】デバイスにおいて受信されたユーザジェスチャの実施形態の第７の表現である。

【図4H】デバイスにおいて受信されたユーザジェスチャの実施形態の第８の表現である。

【図5A】デバイスソフトウェア及び／またはファームウェアの実施形態のブロック図である。

【図5B】デバイスソフトウェア及び／またはファームウェアの実施形態の第２のブロック図である。

【図6A】デバイス状態に応じて生成されたデバイス構成の実施形態の第１の表現である。

【図6B】デバイス状態に応じて生成されたデバイス構成の実施形態の第２の表現である。

【図6C】デバイス状態に応じて生成されたデバイス構成の実施形態の第３の表現である。

【図6D】デバイス状態に応じて生成されたデバイス構成の実施形態の第４の表現である。

【図6E】デバイス状態に応じて生成されたデバイス構成の実施形態の第５の表現である。

【図6F】デバイス状態に応じて生成されたデバイス構成の実施形態の第６の表現である。

【図6G】デバイス状態に応じて生成されたデバイス構成の実施形態の第７の表現である。

【図6H】デバイス状態に応じて生成されたデバイス構成の実施形態の第８の表現である。

【図6I】デバイス状態に応じて生成されたデバイス構成の実施形態の第９の表現である。

【図6J】デバイス状態に応じて生成されたデバイス構成の実施形態の第１０の表現である。

【図7A】論理的ウィンドウスタックの表現である。

【図7B】論理的ウィンドウスタックの実施形態の別の表現である。

【図7C】論理的ウィンドウスタックの実施形態の別の表現である。

【図7D】論理的ウィンドウスタックの実施形態の別の表現である。

【図7E】論理的ウィンドウスタックの実施形態の別の表現である。

【図8】ウィンドウスタック用の論理データ構造の実施形態のブロック図である。

【図9】ウィンドウスタックを作成するための方法の実施形態のフローチャートである。

【図10】例示的なスマートパッド（ＳＰ）を示す。

【図11】スマートパッドをデバイスに関連付ける例示的な方法を示す。

【図12】スマートパッドにドッキングされたデバイスを示す。

【図13A】画面を向ける例示的な方法を示す。

【図13B】画面を向ける例示的な方法を示す。

【図14】ＳＰが横向きモードである場合にアプリケーションを表示する方法を示す。

【図15】ＳＰが縦向きモードである場合にアプリケーションを表示する方法を示す。

【図16】縦向き最大モードのデュアル画面アプリケーションの例を示す。

【図17】最大モード横向きのデュアル画面アプリケーションの例を示す。

【図18】ＳＰ上のキーボード管理の例を示す。

【図19】アプリケーションエリアが最大モードであるＳＰ上のキーボード管理の例を示す。

【図20】横向きモードのＳＰのキーボード管理の別の例を示す。

【図21】仮想キーボードと共にＳＰにおいてデュアル画面エミュレーションモードで実行中のデュアル画面アプリケーションの例を示す。

【図22】ＳＰ上のアプリケーションウィンドウスタック管理の例を示す。

【図23】ＳＰ上のアプリケーションウィンドウスタック管理の別の例を示す。

【図24】複数アプリケーションモードにおいて、ＳＰがミニタブレット形式でデバイスをエミュレートする、ＳＰの複数アプリケーションモードの例を示す。

【図25】ＳＰの複数アプリケーションモードの別の例を示す。

【図26】ＳＰの複数アプリケーションモードの別の例を示す。

【図27】ＳＰの複数アプリケーションモードの別の例を示す。

【図28】画面ディスプレイを管理する方法を示す。

【図29】デスクトップと共に画面表示を管理する例示的な方法を示す。

【図30】キーボードと共に画面表示を管理する例示的な方法を示す。

【図31A】ＳＰ上のデスクトップ管理を示す。

【図31B】ＳＰ上のデスクトップ管理を示す。

【図32A】デスクトップパネル管理の例示的な方法を示す。

【図32B】デスクトップパネル管理の例示的な方法を示す。

【図33】ＳＰ上の例示的な通知管理を示す。

【図34A】例示的なアプリケーション管理技法を示す。

【図34B】例示的なアプリケーション管理技法を示す。

【図35A】デスクトッププレビューまたはヒントを提供する例示的な方法を示す。

【図35B】デスクトッププレビューまたはヒントを提供する例示的な方法を示す。

【図36】例示的なカルーセルアプリケーションウィンドウスタックを示す。

【図37】仮想キーボードと共に例示的なカルーセルアプリケーションウィンドウスタックを示す。

【図38】デバイスをＳＰに関連付ける例示的な方法を示す。

【図39】ＳＰの向きに基づいてアプリケーションの向きを変更する例示的な方法を示す。

【図40】ＳＰ上のキーボードを管理する例示的な方法を示す。

【図41】１つまたは複数のジェスチャに基づいてウィンドウを操作する例示的な方法を示す。

【図42】アプリーションが複数アプリケーションモードでフォーカスされている場合にアプリケーションを強調表示する例示的な方法を示す。

【図43】アプリケーションを最大化する例示的な方法を示す。

【図44】アプリケーションウィンドウからデスクトップに遷移する例示的な方法を示す。

【図45】ＳＰ上のデスクトップ及び／または１つ若しくは複数のパネルの表示を管理する例示的な方法を示す。

【図46】ＳＰに表示するパネルを統合する例示的な方法を示す。

【図47】ＳＰに１つまたは複数のパネルをプレビューする例示的な方法を示す。

【図48】複数アプリケーションモードでスタックを管理する例示的な方法を示す。

【発明を実施するための形態】

【0034】

付属の図面では、同様のコンポーネント及び／または特徴は、同じ参照ラベルを有し得る。さらに、同じタイプのさまざまなコンポーネントは、同様のコンポーネントの中で区別する文字で参照ラベルをたどることによって、区別することができる。第１の参照ラベルのみが本明細書で使用される場合、説明は、第２の参照ラベルに関係なく、同じ第１の参照ラベルを有する同様のコンポーネントのいずれか１つに適用可能である。

【0035】

本明細書で提示するものは、デバイスの実施形態である。デバイスは、携帯電話または他のスマートデバイスなど通信デバイスであり得る。デバイスは、いくつかのユニークなディスプレイ構成を提供するように方向付けられた２つの画面を含み得る。さらに、デバイスは、ユニークな方法でユーザ入力を受信することができる。デバイスの総合的な設計及び機能性は、デバイスをより有用に及びより効果的にするユーザ経験を高めることを実現する。
機械的な特徴：
図１Ａ〜１Ｊは、本開示の実施形態によるデバイス１００を示す。以下でさらに詳細に説明されるように、デバイス１００は、多くの異なる方法で配置することができ、そのそれぞれが異なる機能性をユーザに提供する。デバイス１００は、その両方がタッチセンサ式の一次画面１０４と二次画面１０８とを含む複数画面デバイスである。実施形態では、画面１０４及び１０８の前面全体は、タッチセンサ式であり得、ユーザが画面１０４及び１０８の前面に触れることによって入力を受信することができる。一次画面１０４は、タッチセンサ式ディスプレイ１１０を含み、タッチセンサ式ディスプレイ１１０は、タッチセンサ式であることに加えて、ユーザに情報を表示することも行う。二次画面１０８は、タッチセンサ式ディスプレイ１１４を含み、タッチセンサ式ディスプレイ１１４もまたユーザに情報を表示する。他の実施形態では、画面１０４及び１０８は、２つ以上のディスプレイエリアを含み得る。

【0036】

また、一次画面１０４は、ユーザが構成可能なエリア１１２の一部に触れる際の特定の入力用に構成済みの構成可能なエリア１１２も含む。二次画面１０８もまた、特定の入力用に構成済みの構成可能なエリア１１６を含む。エリア１１２ａ及び１１６ａは、ユーザが以前に表示された情報を閲覧することを望むことを示す「バック」入力を受信するよう構成済みである。エリア１１２ｂ及び１１６ｂは、ユーザがメニューからオプションを閲覧することを望むことを示す「メニュー」入力を受信するよう構成済みである。エリア１１２ｃ及び１１６ｃは、ユーザが「ホーム」ビューに関連付けられた情報を閲覧することを望むことを示す「ホーム」入力を受信するよう構成済みである。他の実施形態では、エリア１１２ａ〜ｃ及び１１６ａ〜ｃは、上記で説明される構成に加えて、デバイス１００の特徴の制御を含む他のタイプの特定の入力用に構成することができ、いくつかの非限定的な例としては、全体的なシステムパワーの調整、音量の調整、輝度の調整、振動の調整、表示アイテムの選択（画面１０４または１０８のいずれか）、カメラの操作、マイクロホンの操作及び通話の開始／終了が挙げられる。また、いくつかの実施形態では、エリア１１２ａ〜ｃ及び１１６ａ〜ｃは、デバイス１００上で実行するアプリケーション及び／またはタッチセンサ式ディスプレイ１１０及び／または１１４上に表示される情報に応じて特定の入力用に構成することができる。

【0037】

タッチセンサ式に加えて、一次画面１０４及び二次画面１０８は、ユーザが画面のディスプレイエリアに触れる必要なく、ユーザから入力を受信するエリアも含む。例えば、一次画面１０４は、ジェスチャ捕捉エリア１２０を含み、二次画面１０８は、ジェスチャ捕捉エリア１２４を含む。これらのエリアは、例えば、ユーザが実際にディスプレイエリアの表面に触れる必要なく、ユーザによって行われたジェスチャを認識することにより、入力を受信することができる。タッチセンサ式ディスプレイ１１０及び１１４と比較すると、ジェスチャ捕捉エリア１２０及び１２４は、一般には、表示画像をレンダリングすることはできない。

【0038】

２つの画面１０４及び１０８は、ヒンジ１２８で接続され、ヒンジ１２８は、図１Ｃ（デバイス１００の背面図を示す）で明確に示される。図１Ａ〜１Ｊに示される実施形態では、ヒンジ１２８は、画面１０４と１０８とを接続する中央のヒンジであり、その結果、ヒンジを閉じると、画面１０４と１０８は、図１Ｂ（デバイス１００の正面図を示す）に示されるように並置される（すなわち、隣り合わせになる）。ヒンジ１２８を開いて、２つの画面１０４及び１０８を相対的に互いに異なる配置にすることができる。以下でさらに詳細に説明するように、デバイス１００は、画面１０４及び１０８の相対位置に応じて異なる機能性を有し得る。

【0039】

図１Ｄは、デバイス１００の右側を示す。図１Ｄに示されるように、二次画面１０８は、その側面にカードスロット１３２とポート１３６も含む。実施形態では、カードスロット１３２は、加入者識別モジュール（ＳＩＭ）を含む異なるタイプのカードを収容する。実施形態では、ポート１３６は、ディスプレイ、キーボードまたは印刷デバイスなどの他の周辺デバイスにデバイス１００を接続することを可能にする入力／出力ポート（Ｉ／Ｏポート）である。理解できるように、これらは単なる例示の一部であり、他の実施形態では、デバイス１００は、追加のメモリデバイスを収容するための及び／または他の周辺デバイスを接続するためのスロット及びポートなどの他のスロット及びポートを含み得る。また、図１Ｄには、例えば、ユーザのヘッドホンまたはヘッドセットの利用を可能にするチップ、リング、スリーブ（ＴＲＳ）コネクタを収容する音声ジャック１４０も示されている。

【0040】

また、デバイス１００は、多数のボタン１５８も含む。例えば、図１Ｅは、デバイス１００の左側を示す。図１Ｅに示されるように、一次画面１０４の側面は、３つのボタン１４４、１４８及び１５２を含み、これらのボタンは、特定の入力用に構成することができる。例えば、ボタン１４４、１４８及び１５２は、組み合わせて、または単独で、デバイス１００の多くの態様を制御するよう構成することができる。いくつかの非限定的な例としては、全体的なシステムパワー、音量、輝度、振動、表示アイテムの選択（画面１０４または１０８のいずれか）、カメラ、マイクロホン及び通話の開始／終了が挙げられる。いくつかの実施形態では、別々のボタンの代わりに、２つのボタンを組み合わせてロッカーボタンにすることができる。この構成は、音量または輝度などの特徴を制御するようにボタンが構成された状況において有用である。ボタン１４４、１４８及び１５２に加えて、デバイス１００は、デバイス１００の上側を示す図１Ｆに示されるようなボタン１５６も含む。一実施形態では、ボタン１５６は、デバイス１００への全体的なシステムパワーの制御に使用されるオン／オフボタンとして構成される。他の実施形態では、ボタン１５６は、システムパワーの制御に加えてまたはシステムパワーの制御の代わりに、デバイス１００の他の態様を制御するよう構成される。いくつかの実施形態では、ボタン１４４、１４８、１５２及び１５６のうちの１つまたは複数は、異なるユーザコマンドをサポートすることができる。一例として、通常のプレスは、一般に、約１秒未満の持続時間を有し、クイックタップに似ている。中程度のプレスは、一般に、１秒以上だが約１２秒未満の持続時間を有する。長時間のプレス（長押し）は、一般に、約１２秒以上の持続時間を有する。ボタンの機能は、通常、現時点でそれぞれのディスプレイ１１０及び１１４に焦点が合わせられているアプリケーションに特有である。例えば、通話アプリケーションでは、特定のボタンに応じて、通常の、中程度のまたは長時間のプレスは、通話終了、通話音量の増加、通話音量の減少、マイクロホンのミュートの切り替えを意味し得る。例えば、カメラまたは映像アプリケーションでは、特定のボタンに応じて、通常の、中程度のまたは長時間のプレスは、ズーム拡大、ズーム縮小、写真撮影または映像記録を意味し得る。

【0041】

また、デバイス１００には、多くのハードウェアコンポーネントが存在する。図１Ｃに示されるように、デバイス１００は、スピーカ１６０とマイクロホン１６４とを含む。また、デバイス１００は、カメラ１６８（図１Ｂ）も含む。それに加えて、デバイス１００は、２つの位置センサ１７２ａ及び１７２ｂを含み、位置センサ１７２ａ及び１７２ｂは、画面１０４及び１０８の相対位置の決定に使用される。一実施形態では、位置センサ１７２ａ及び１７２ｂは、ホール効果センサである。しかし、他の実施形態では、ホール効果センサに加えて、またはホール効果センサの代わりに、他のセンサを使用することができる。また、デバイス１００の一部として、加速度計１７６を含めて、デバイス１００の向き及び／または画面１０４及び１０８の向きを決定することもできる。デバイス１００に含めることができる追加の内部のハードウェアコンポーネントについては、図２に関連して、以下で説明する。

【0042】

デバイス１００の総合的な設計は、他の通信デバイスで利用不可能な追加の機能性の提供を可能にする。機能性のいくつかは、デバイス１００が有し得るさまざまな位置及び向きに基づく。図１Ｂ〜１Ｇに示されるように、デバイス１００は、画面１０４と１０８が並置される「開」位置で操作することができる。この位置により、ユーザに情報を表示するための大きなディスプレイエリアが可能になる。デバイス１００が開位置にあると位置センサ１７２ａ及び１７２ｂが決定すると、位置センサ１７２ａ及び１７２ｂは、両方の画面１０４及び１０８上での情報の表示などの異なるイベントのトリガに使用することができる信号を生成することができる。追加のイベントは、デバイス１００が横向き位置（図示せず）と対向する縦向き位置（図１Ｂ）にあると加速度計１７６が決定した場合にトリガすることができる。

【0043】

開位置に加えて、デバイス１００は、図１Ｈに示されるような「閉」位置も有し得る。この場合もやはり、位置センサ１７２ａ及び１７２ｂは、デバイス１００が「閉」位置にあることを示す信号を生成することができる。これにより、画面１０４及び／または１０８上に表示された情報の変化をもたらすイベントをトリガすることができる。例えば、デバイス１００が「閉」位置にある場合、ユーザは１つの画面しか閲覧できないため、デバイス１００は、画面のうちの１つ、例えば、画面１０８上での情報の表示を停止するようにプログラムすることができる。他の実施形態では、デバイス１００が「閉」位置にあることを示す、位置センサ１７２ａ及び１７２ｂによって生成された信号は、電話の発呼に応答するようにデバイス１００をトリガすることができる。「閉」位置は、携帯電話としてデバイス１００を利用する場合にも好ましい位置であり得る。

【0044】

デバイス１００は、図１Ｉに示されるような「イーゼル」位置でも使用することができる。「イーゼル」位置では、画面１０４及び１０８は、互いに角度をなして外側を向いた状態であり、画面１０４及び１０８の縁は実質的に水平である。この位置では、デバイス１００は、両方の画面１０４及び１０８上で情報を表示するよう構成することができ、二人のユーザが同時にデバイス１００と情報のやり取りを行うことを可能にする。デバイス１００が「イーゼル」位置にある場合、センサ１７２ａ及び１７２ｂは、画面１０４及び１０８が互いに角度をなして配置されていることを示す信号を生成することができ、加速度計１７６は、画面１０４及び１０８の縁が実質的に水平となるようにデバイス１００が配置されたことを示す信号を生成することができる。次いで、信号を組み合わせて使用し、画面１０４及び１０８上での情報の表示の変化をトリガするイベントを生成することができる。

【0045】

図１Ｊは、「変形イーゼル」位置のデバイス１００を示す。「変形イーゼル」位置では、画面１０４または１０８のうちの１つは、スタンドとして使用され、テーブルなどの物体の表面上に下を向いた状態に置かれる。この位置は、横向きでユーザに情報を表示する便利な方法を提供する。イーゼル位置と同様に、デバイス１００が「変形イーゼル」位置にある場合、位置センサ１７２ａ及び１７２ｂは、画面１０４及び１０８が互いに角度をなして配置されていることを示す信号を生成する。加速度計１７６は、画面１０４及び１０８のうちの１つが下を向いた状態で、実質的に水平となるようにデバイス１００が配置されたことを示す信号を生成することになる。次いで、信号を使用して、画面１０４及び１０８の情報の表示の変化をトリガするイベントを生成することができる。例えば、ユーザはその画面を見ることができないため、下向きの画面上には情報は表示されない可能性がある。

【0046】

また、移行状態も可能である。画面が閉じているまたは折り畳まれている（開位置から）ことを位置センサ１７２ａ及びｂ及び／または加速度計が示す場合は、閉への移行状態が認識される。逆に、画面が開いているまたは折り畳まれている（閉位置から）ことを位置センサ１７２ａ及びｂが示す場合は、開への移行状態が認識される。閉及び開への移行状態は、通常、時間に基づくか、または感知された開始点からの最大持続時間を有する。通常、閉及び開状態のうちの１つが進行中のときは、ユーザ入力は不可能である。このように、閉または開動作中のユーザによる画面との偶発的な接触は、ユーザ入力として誤って解釈されることはない。実施形態では、デバイス１００が閉じている場合は、別の移行状態が可能である。この追加の移行状態により、デバイス１００が閉じている場合は、例えば、画面１１０、１１４上でのダブルタップなどの何らかのユーザ入力に基づいて、ある画面１０４から第２の画面１０８にディスプレイを切り替えることが可能になる。

【0047】

理解できるように、デバイス１００に関する説明は、単なる例示を目的として行われ、実施形態は、図１Ａ〜１Ｊに示され、上記で説明される特定の機械的な特徴に制限されない。他の実施形態では、デバイス１００は、１つまたは複数の追加のボタン、スロット、ディスプレイエリア、ヒンジ及び／またはロック機構を含む追加の特徴を含み得る。それに加えて、実施形態では、上記で説明される特徴は、デバイス１００の異なる部分に位置し得、それでも同様の機能性を提供することができる。したがって、図１Ａ〜１Ｊ及び上記で提供される説明は、非限定的である。
ハードウェアの特徴：
図２は、本開示の実施形態によるデバイス１００のコンポーネントを示す。一般に、デバイス１００は、一次画面１０４と二次画面１０８とを含む。一次画面１０４及びそのコンポーネントは、通常、開位置または状態でも閉位置または状態でも有効化される一方で、二次画面１０８及びそのコンポーネントは、通常、開状態では有効化されるが、閉状態では無効化される。しかし、閉状態であっても、ユーザまたはアプリケーションがトリガするインタラプト（通話アプリケーションまたはカメラアプリケーションオペレーションに応じてなど）は、適切なコマンドによって、アクティブ画面を変更することも、一次画面１０４を無効化して二次画面１０８を有効化することもできる。各画面１０４、１０８は、タッチセンサ式であり得、異なる動作エリアを含み得る。例えば、それぞれのタッチセンサ式画面１０４及び１０８内の第１の動作エリアは、タッチセンサ式ディスプレイ１１０、１１４を含み得る。一般に、タッチセンサ式ディスプレイ１１０、１１４は、フルカラーのタッチセンサ式ディスプレイを含み得る。それぞれのタッチセンサ式画面１０４及び１０８内の第２のエリアは、ジェスチャ捕捉領域１２０、１２４を含み得る。ジェスチャ捕捉領域１２０、１２４は、タッチセンサ式ディスプレイ１１０、１１４のエリア外のエリアまたは領域を含み得、そのエリアまたは領域は、例えば、ユーザによって提供されるジェスチャの形での入力の受信が可能である。しかし、ジェスチャ捕捉領域１２０、１２４は、表示機能または能力を実行することができる画素を含まない。

【0048】

タッチセンサ式画面１０４及び１０８の第３の領域は、構成可能なエリア１１２、１１６を含み得る。構成可能なエリア１１２、１１６は、入力を受信することができ、表示または制限された表示能力を有する。実施形態では、構成可能なエリア１１２、１１６は、異なる入力オプションをユーザに提示することができる。例えば、構成可能なエリア１１２、１１６は、ボタンまたは他の関連付けられるアイテムを表示することができる。その上、表示されたボタンのアイデンティティ、または、タッチセンサ式画面１０４もしくは１０８の構成可能なエリア１１２、１１６内に表示されているボタンがあるかどうかは、デバイス１００が使用される及び／または操作されるコンテキストから決定することができる。例示的な実施形態では、タッチセンサ式画面１０４及び１０８は、ユーザに視覚出力を提供することができるタッチセンサ式画面１０４及び１０８の少なくともそれらの領域に広がる液晶ディスプレイデバイスと、ユーザから入力を受信することができるタッチセンサ式画面１０４及び１０８のそれらの領域にわたる容量性入力マトリックスとを含む。

【0049】

１つまたは複数のディスプレイコントローラ２１６ａ、２１６ｂは、入力（タッチセンサ式）及び出力（表示）機能を含むタッチセンサ式画面１０４及び１０８のオペレーションを制御するために設けることができる。図２に示される例示的な実施形態では、別々のタッチスクリーンコントローラ２１６ａまたは２１６ｂが各タッチスクリーン１０４及び１０８に設けられる。代替の実施形態によれば、共通のまたは共有されたタッチスクリーンコントローラ２１６を使用して、含まれるタッチセンサ式画面１０４及び１０８の各々を制御することができる。さらなる他の実施形態によれば、タッチスクリーンコントローラ２１６の機能は、プロセッサ２０４などの他のコンポーネントに組み込むことができる。

【0050】

プロセッサ２０４は、アプリケーションプログラミングまたは命令を実行するための汎用のプログラム可能プロセッサまたはコントローラを含み得る。少なくともいくつかの実施形態によれば、プロセッサ２０４は、複数のプロセッサコアを含む、及び／または、複数の仮想プロセッサを実装することができる。さらなる他の実施形態によれば、プロセッサ２０４は、複数の物理的プロセッサを含み得る。具体的な例として、プロセッサ２０４は、特別に構成された特定用途向け集積回路（ＡＳＩＣ）もしくは他の集積回路、デジタル信号プロセッサ、コントローラ、配線電子もしくは論理回路、プログラム可能論理デバイスもしくはゲートアレイ、専用コンピュータ、または、同様のものを含み得る。プロセッサ２０４は、一般に、デバイス１００のさまざまな機能を実装するプログラミングコードまたは命令を実行するように機能する。

【0051】

また、通信デバイス１００は、プロセッサ２０４によるアプリケーションプログラミングまたは命令の実行に関連して使用するための、ならびに、プログラム命令及び／またはデータを一時的または長期に格納するための、メモリ２０８も含み得る。例として、メモリ２０８は、ＲＡＭ、ＤＲＡＭ、ＳＤＲＡＭまたは他のソリッドステートメモリを含み得る。その代替としてまたはそれに加えて、データストレージ２１２を設けることができる。メモリ２０８と同様に、データストレージ２１２は、１つまたは複数のソリッドステートメモリデバイスを含み得る。その代替としてまたはそれに加えて、データストレージ２１２は、ハードディスクドライブまたは他のランダムアクセスメモリを含み得る。

【0052】

通信機能または能力をサポートする際、デバイス１００は、携帯電話モジュール２２８を含み得る。例として、携帯電話モジュール２２８は、セルラネットワーク上で音声、マルチメディア及び／またはデータ転送をサポートすることができるＧＳＭ（登録商標）、ＣＤＭＡ、ＦＤＭＡ及び／またはアナログ携帯電話トランシーバを含み得る。その代替としてまたはそれに加えて、デバイス１００は、追加のまたは他の無線通信モジュール２３２を含み得る。例として、他の無線通信モジュール２３２は、ワイファイ（Ｗｉ−Ｆｉ）、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）（登録商標）、ワイマックス（ＷｉＭａｘ）、赤外線または他の無線通信リンクを含み得る。携帯電話モジュール２２８及び他の無線通信モジュール２３２は、それぞれが、共有または専用アンテナ２２４と関連付けられることができる。

【0053】

ポートインタフェース２５２を含めることができる。ポートインタフェース２５２は、ドックなどの他のデバイスまたはコンポーネントとのデバイス１００の相互接続をサポートする独自のまたはユニバーサルポートを含み得、他のデバイスまたはコンポーネントは、デバイス１００に不可欠なものへの追加のまたはそれとは異なる能力を含んでも含まなくともよい。デバイス１００と別のデバイスまたはコンポーネントとの間での通信信号の交換のサポートに加えて、ドッキングポート１３６及び／またはポートインタフェース２５２は、デバイス１００へのまたはデバイス１００からの電力の供給をサポートすることができる。また、ポートインタフェース２５２は、デバイス１００と接続されたデバイスまたはコンポーネントとの間の通信または他の相互作用を制御するためのドッキングモジュールを含むインテリジェントな要素も含む。

【0054】

入力／出力モジュール２４８及び関連ポートを含めて、例えば、他の通信デバイス、サーバデバイス及び／または周辺デバイスとの有線ネットワークまたはリンク上での通信をサポートすることができる。入力／出力モジュール２４８の例としては、イーサネット（登録商標）ポート、ユニバーサルシリアルバス（ＵＳＢ）ポート、電気電子技術者協会（ＩＥＥＥ）１３９４または他のインタフェースが挙げられる。

【0055】

音声入力／出力インタフェース／デバイス２４４を含めて、相互接続されたスピーカまたは他のデバイスにアナログ音声を提供したり、接続されたマイクロホンまたは他のデバイスからアナログ音声入力を受信したりすることができる。一例として、音声入力／出力インタフェース／デバイス２４４は、関連アンプとアナログデジタル変換器とを含み得る。その代替としてまたはそれに加えて、デバイス１００は、外部のスピーカまたはマイクロホンを相互接続するための統合音声入力／出力デバイス２５６及び／または音声ジャックを含み得る。例えば、統合スピーカ及び統合マイクロホンを提供し、近接通話またはスピーカフォンオペレーションをサポートすることができる。

【0056】

ハードウェアボタン１５８を含めて、例えば、ある制御動作に関連して使用することができる。例としては、図１Ａ〜１Ｊと併せて説明されるように、マスタ電源スイッチ、音量調節などが挙げられる。カメラなどの１つまたは複数の画像捕捉インタフェース／デバイス２４０を含めて、静止及び／またはビデオ画像を捕捉することができる。その代替としてまたはそれに加えて、画像捕捉インタフェース／デバイス２４０は、スキャナまたはコードリーダを含み得る。画像捕捉インタフェース／デバイス２４０は、フラッシュまたは他の光源などの追加の要素を含むか、または追加の要素と関連付けられることができる。

【0057】

また、デバイス１００は、全地球側位システム（ＧＰＳ）受信機２３６も含み得る。本発明の実施形態によれば、ＧＰＳ受信機２３６は、デバイス１００の他のコンポーネントに絶対位置情報を提供できるＧＰＳモジュールをさらに含み得る。また、加速度計１７６も含めることができる。例えば、ユーザへの情報の表示及び／または他の機能に関連して、加速度計１７６からの信号を使用して、その情報をユーザに表示するための方向及び／または形式を決定することができる。

【0058】

また、本発明の実施形態は、１つまたは複数の位置センサ１７２を含み得る。位置センサ１７２は、互いに対するタッチセンサ式画面１０４及び１０８の位置を示す信号を提供することができる。例えば、ユーザインタフェースアプリケーションへの入力としてこの情報を提供し、動作モード、すなわち、タッチセンサ式ディスプレイ１１０、１１４及び／または他のデバイス１００オペレーションの特性を決定することができる。例として、画面位置センサ１７２は、一連のホール効果センサ、複数の位置スイッチ、光スイッチ、ホイートストンブリッジ、電位差計、または、タッチスクリーンが置かれている複数の相対位置を示す信号を提供することができる他の構成を含み得る。

【0059】

デバイス１００のさまざまなコンポーネント間の通信は、１つまたは複数のバス２２２によって行うことができる。それに加えて、電源及び／または電力制御モジュール２６０からデバイス１００のコンポーネントに電力を供給することができる。電力制御モジュール２６０は、例えば、バッテリ、ＡＣ／ＤＣ変換器、電力制御ロジック及び／または外部の電源にデバイス１００を相互接続するためのポートを含み得る。
デバイスの状態：
図３Ａ及び３Ｂは、デバイス１００の例示的な状態を表す。多くの例示的な状態が示され、第１の状態から第２の状態へ移行するが、例示的な状態を示す図は、すべての可能な状態及び／またはすべての可能な第１の状態から第２の状態への移行を包含するわけではないことを理解されたい。図３で示されるように、状態間のさまざまな矢印（円で表された状態によって示される）は、デバイス１００に起こる物理的変化を表す。物理的変化は、ハードウェア及びソフトウェアの１つまたは複数によって検出され、その検出により、ハードウェア及び／またはソフトウェアインタラプトの１つまたは複数がトリガされ、デバイス１００の１つまたは複数の機能の制御及び／または管理に使用される。

【0060】

図３Ａで示されるように、１２の例示的な「物理的」状態があり、それらは、閉３０４、移行３０８（または開への移行状態）、イーゼル３１２、変形イーゼル３１６、開３２０、着信／発信通話または通信３２４、画像／映像捕捉３２８、移行３３２（または閉への移行状態）、横向き３４０、ドッキング３３６、ドッキング３４４及び横向き３４８である。各例示的な状態の隣にあるのは、デバイス１００の物理的状態の表現であるが、状態３２４及び３２８は例外であり、状態３２４及び３２８では、一般に、状態は、電話用の国際的なアイコン及びカメラ用のアイコンによってそれぞれ象徴化される。

【0061】

状態３０４では、デバイスは閉状態であり、デバイス１００は、一般に、一次画面１０４と二次画面１０８が異なる面で背中合わせの状態で、縦向き方向に方向付けられる（図１Ｈを参照）。閉状態から、デバイス１００は、例えば、ドッキング状態３３６または横向き状態３４０に入ることができ、ドッキング状態３３６では、デバイス１００はドッキングステーションやドッキングケーブルと結合されるか、または、一般に１つもしくは複数の他のデバイスもしくは周辺機器とドッキングされるかもしくは関連付けられ、横向き状態３４０では、一次画面１０４はユーザに面し、一次画面１０４と二次画面１０８は背中合わせの状態でデバイス１００が一般に方向付けされる。

【0062】

また、閉状態では、デバイスは、移行状態に移動することができ、移行状態では、デバイスは閉じたままであるが、ディスプレイは、例えば、画面１１０、１１４上でのダブルタップなどのユーザ入力に基づいて、ある画面１０４から別の画面１０８に移動する。さらに別の実施形態は、両面状態（ｂｉｌａｔｅｒａｌ ｓｔａｔｅ）を含む。両面状態では、デバイスは閉じたままであるが、単一のアプリケーションが少なくとも１つのウィンドウを第１のディスプレイ１１０と第２のディスプレイ１１４の両方に表示する。第１及び第２のディスプレイ１１０、１１４に示されるウィンドウは、アプリケーション及びそのアプリケーションの状態に基づいて、同じであっても異なっていてもよい。例えば、カメラで画像を取得する間、デバイスは、第１のディスプレイ１１０上でファインダを表示することができ、第２のディスプレイ１１４上で被写体のプレビュー（全画面及び左から右へミラーリング）を表示する。

【0063】

閉状態３０４から半開状態またはイーゼル状態３１２への移行状態である状態３０８では、デバイス１００は、一次画面１０４及び二次画面１０８をヒンジと一致する軸のポイントの周りで回転させて開いた状態で示される。イーゼル状態３１２に入ると、一次画面１０４及び二次画面１０８は、例えば、デバイス１００がイーゼル様構成で表面上に位置することができるように、互いに分離される。

【0064】

変形イーゼル位置として知られる状態３１６では、デバイス１００は、互いにイーゼル状態３１２と同様の相対関係にある一次画面１０４及び二次画面１０８を有し、その違いは、示されるように、一次画面１０４または二次画面１０８のうちの１つが表面上に配置されることである。

【0065】

状態３２０は開状態であり、開状態では、一次画面１０４及び二次画面１０８は、一般に、同じ平面上にある。開状態から、デバイス１００は、ドッキング状態３４４または開横向き状態３４８に移行することができる。開状態３２０では、一次画面１０４及び二次画面１０８は、一般に、縦向きのような状態にあるが、横向き状態３４８では、一次画面１０４及び二次画面１０８は、一般に、横向きのような状態にある。

【0066】

状態３２４は、デバイス１００でそれぞれ着信通話を受けるまたは発信通話をかける場合などの通信状態の例示である。明確には示されていないが、デバイス１００は、図３に示されるいかなる状態からも着信／発信通話状態３２４へ移行できることを理解されたい。同様に、画像／映像捕捉状態３２８もまた、図３に示される他のいかなる状態からも入ることができ、画像／映像捕捉状態３２８では、デバイス１００は、映像捕捉デバイス２４０を備えたカメラ及び／またはビデオを介して、１つまたは複数の画像を撮影することができる。

【0067】

移行状態３３２は、一次画面１０４及び二次画面１０８が、例えば、閉状態３０４に入るために、互いに向かって閉じている状態を例示的に示す。
図３Ｂは、キーを参照して、第１の状態から第２の状態への移行を検出するために受信された入力を示す。図３Ｂでは、状態のさまざまな組合せが示されており、一般に、列の一部は、縦向き状態３５２や横向き状態３５６を対象とし、行の一部は、縦向き状態３６０と横向き状態３６４を対象とする。

【0068】

図３Ｂでは、キーは、「Ｈ」が１つまたは複数のホール効果センサからの入力を表し、「Ａ」が１つまたは複数の加速度計からの入力を表し、「Ｔ」がタイマからの入力を表し、「Ｐ」が通信トリガ入力を表し、「Ｉ」が画像及び／または映像捕捉要求入力を表すことを示す。したがって、表の中央部分３７６では、デバイス１００がどのように第１の物理的な状態から第２の物理的な状態への移行を検出するかを表す入力または入力の組合せが示される。

【0069】

論じられるように、表の中央部分３７６では、受信した入力により、例えば、縦向き開状態から横向きイーゼル状態への移行（太字の「ＨＡＴ」で示される）の検出が可能になる。この例示的な縦向き開状態から横向きイーゼル状態への移行の場合、ホール効果センサ（「Ｈ」）、加速度計（「Ａ」）及びタイマ（「Ｔ」）入力が必要とされ得る。タイマ入力は、例えば、プロセッサに関連付けられた時計から得ることができる。

【0070】

縦向き及び横向き状態に加えて、ドッキング信号３７２の受信に基づいてトリガされるドッキング状態３６８も示される。上記で論じられるように、図３に関連して、ドッキング信号は、デバイス１００を、１つまたは複数の他のデバイス１００、アクセサリ、周辺機器、スマートドックまたは同様のものと接続することによってトリガすることができる。
ユーザ相互作用：
図４Ａ〜４Ｈは、画面１０４、１０８によって認識することができるジェスチャ入力のさまざまなグラフィカルな表現を描写する。ジェスチャは、指などのユーザの身体部分ばかりではなく、画面１０４、１０８の接触感知部分によって感知することができるスタイラスなどの他のデバイスによっても行うことができる。一般に、ジェスチャは、どこでジェスチャが行われるか（ディスプレイ１１０、１１４上に直接またはジェスチャ捕捉領域１２０、１２４のいずれか）に基づいて、異なって解釈される。例えば、ディスプレイ１１０、１１４内のジェスチャは、デスクトップまたはアプリケーションを対象とし、ジェスチャ捕捉領域１２０、１２４内のジェスチャは、システム用として解釈され得る。

【0071】

図４Ａ〜４Ｈを参照すると、ジェスチャの第１のタイプ（タッチジェスチャ４２０）は、選択された時間長の間、画面１０４、１０８上に実質的に静止する。円４２８は、画面の接触感知部分の特定の位置で受信されたタッチまたは他の接触タイプを表す。円４２８は、境界４３２を含み得、その厚さは、接触位置において実質的に静止した状態で接触が保持された時間長を示す。例えば、タップ４２０（または短時間のプレス）は、長時間のプレス４２４に対する（または通常のプレスに対する）境界４３２ｂより薄い境界４３２ａを有する。長時間のプレス４２４は、タップ４２０より長い時間の間、画面上に実質的に静止した状態のままの接触を伴う可能性がある。理解されるように、異なって定義されたジェスチャは、接触停止前または画面上での移動前のタッチが静止した状態のままの時間長に応じて登録することができる。

【0072】

図４Ｃを参照すると、画面１０４、１０８上でのドラッグジェスチャ４００は、最初の接触（円４２８によって表される）に、選択された方向への接触移動４３６が伴う。最初の接触４２８は、境界４３２によって表される特定の時間量の間、画面１０４、１０８上で静止した状態のままであり得る。ドラッグジェスチャは、通常、ユーザが第１の位置でアイコン、ウィンドウまたは他の表示画像に接触し、その後、選択された表示画像に対して所望の新しい第２の位置に向かうドラッグ方向に接触を移動させる必要がある。接触移動は、直線である必要はないが、接触が第１から第２の位置に実質的に連続したものである限り、いかなる経路の移動もあり得る。

【0073】

図４Ｄを参照すると、画面１０４、１０８上でのフリックジェスチャ４０４は、最初の接触（円４２８によって表される）に、選択された方向への短縮された接触移動４３６（ドラッグジェスチャと比較して）が伴う。実施形態では、フリックは、ドラッグジェスチャと比較して、ジェスチャの最後の動きに対してより高い退出速度を有する。フリックジェスチャは、例えば、最初の接触に続く指スナップであり得る。ドラッグジェスチャと比較すると、フリックジェスチャは、一般に、表示画像の第１の位置から既定の第２の位置まで、画面１０４、１０８との連続的な接触を必要としない。接触した表示画像は、フリックジェスチャによって、既定の第２の位置に向かうフリックジェスチャ方向に移動される。両方のジェスチャは、一般に、第１の位置から第２の位置に表示画像を移動させることができるが、画面上での接触の持続時間及び移動距離は、一般に、ドラッグジェスチャよりもフリックジェスチャの方が短い。

【0074】

図４Ｅを参照すると、画面１０４、１０８上でのピンチジェスチャ４０８が描写されている。ピンチジェスチャ４０８は、例えば、第１の指によって画面１０４、１０８に第１の接触４２８ａを行い、例えば、第２の指によって画面１０４、１０８に第２の接触４２８ｂを行うことによって着手することができる。第１及び第２の接触４２８ａ、ｂは、共通の画面１０４、１０８の共通の接触感知部分によって、共通の画面１０４もしくは１０８の異なる接触感知部分によって、または、異なる画面の異なる接触感知部分によって、検出することができる。第１の接触４２８ａは、境界４３２ａによって表されるように、第１の時間量の間保持され、第２の接触４２８ｂは、境界４３２ｂによって表されるように、第２の時間量の間保持される。第１及び第２の時間量は、一般に、実質的に同じであり、第１及び第２の接触４２８ａ、ｂは、一般に、実質的に同時に起こる。また、第１及び第２の接触４２８ａ、ｂは、一般に、それぞれ、対応する第１及び第２の接触移動４３６ａ、ｂを含む。第１及び第２の接触移動４３６ａ、ｂは、一般に、対向方向である。別の言い方をすれば、第１の接触移動４３６ａは、第２の接触４２８ｂに向かう方向にあり、第２の接触移動４３６ｂは、第１の接触４２８ａに向かう方向にある。より簡単な言い方をすれば、ピンチジェスチャ４０８は、ユーザの指がピンチ動作で画面１０４、１０８に触れることによって実現することができる。

【0075】

図４Ｆを参照すると、画面１０４、１０８上でのスプレッドジェスチャ４１０が描写されている。スプレッドジェスチャ４１０は、例えば、第１の指で画面１０４、１０８に第１の接触４２８ａを行い、例えば、第２の指で画面１０４、１０８に第２の接触４２８ｂを行うことによって着手することができる。第１及び第２の接触４２８ａ、ｂは、共通の画面１０４、１０８の共通の接触感知部分によって、共通の画面１０４もしくは１０８の異なる接触感知部分によって、または、異なる画面の異なる接触感知部分によって、検出することができる。第１の接触４２８ａは、境界４３２ａによって表されるように、第１の時間量の間保持され、第２の接触４２８ｂは、境界４３２ｂによって表されるように、第２の時間量の間保持される。第１及び第２の時間量は、一般に、実質的に同じであり、第１及び第２の接触４２８ａ、ｂは、一般に、実質的に同時に起こる。また、第１及び第２の接触４２８ａ、ｂは、一般に、それぞれ、対応する第１及び第２の接触移動４３６ａ、ｂを含む。第１及び第２の接触移動４３６ａ、ｂは、一般に、共通の方向である。別の言い方をすれば、第１及び第２の接触移動４３６ａ、ｂは、第１及び第２の接触４２８ａ、ｂから遠ざかる方向にある。より簡単な言い方をすれば、スプレッドジェスチャ４１０は、ユーザの指がスプレッド動作で画面１０４、１０８に触れることによって実現することができる。

【0076】

上記のジェスチャは、図４Ｇ及び４Ｈによって示されるものなど、任意の方法で組み合わせて、決定された機能的な結果を生成することができる。例えば、図４Ｇでは、タップジェスチャ４２０と、タップジェスチャ４２０から遠ざかる方向へのドラッグまたはフリックジェスチャ４１２とが組み合わされている。図４Ｈでは、タップジェスチャ４２０と、タップジェスチャ４２０に向かう方向へのドラッグまたはフリックジェスチャ４１２とが組み合わされている。

【0077】

ジェスチャを受信するという機能的な結果は、デバイス１００、ディスプレイ１１０、１１４もしくは画面１０４、１０８の状態、ジェスチャに関連付けられたコンテキスト、または、ジェスチャの感知位置を含む多くの要因に応じて異なり得る。デバイスの状態は、一般に、デバイス１００の構成、ディスプレイ方向ならびにデバイス１００で受信されるユーザ及び他の入力のうちの１つまたは複数を指す。コンテキストは、一般に、アプリケーションが単一画面アプリケーションであろうが、複数画面アプリケーションであろうが、及び、アプリケーションが１つまたは複数の画面に１つまたは複数のウィンドウを表示する複数画面アプリケーションであろうが、１つまたは複数のスタックに１つまたは複数のウィンドウを表示する複数画面アプリケーションであろうが、ジェスチャによって選択された特定のアプリケーション及び現時点で実行しているアプリケーションの部分のうちの１つまたは複数を指す。ジェスチャの感知位置は、一般に、感知されたジェスチャ位置座標セットが、タッチセンサ式ディスプレイ１１０、１１４上にあるかまたはジェスチャ捕捉領域１２０、１２４にあるか、感知されたジェスチャ位置座標セットが、共通のディスプレイもしくは画面１０４、１０８に関連付けられているか、または異なるディスプレイもしくは画面１０４、１０８に関連付けられているか、及び／または、ジェスチャ捕捉領域のどの部分が感知されたジェスチャ位置座標セットを含むかを指す。

【0078】

タップは、タッチセンサ式ディスプレイ１１０、１１４で受信する場合、例えば、対応するアプリケーションの実行の開始または終了、ウィンドウの最大化または最小化、スタック内でのウィンドウの並べ換え、及び、キーボード表示または他の表示画像などによるユーザ入力の提供のためにアイコンを選択する際に使用することができる。ドラッグは、タッチセンサ式ディスプレイ１１０、１１４で受信する場合、例えば、ディスプレイ内の所望の位置へアイコンもしくはウィンドウを移動する、ディスプレイ上でスタックを並べ換える、または、両ディスプレイをスパンする（その結果、選択したウィンドウは各ディスプレイの部分を同時に占有する）際に使用することができる。フリックは、タッチセンサ式ディスプレイ１１０、１１４またはジェスチャ捕捉領域１２０、１２４で受信する場合、例えば、第１のディスプレイから第２のディスプレイへウィンドウを移動する、または、両ディスプレイをスパンする（その結果、選択したウィンドウは各ディスプレイの部分を同時に占有する）際に使用することができる。しかし、ドラッグジェスチャとは異なり、フリックジェスチャは、一般に、特定のユーザ選択位置へ表示画像を移動する際には使用されないが、ユーザによる構成が不可能なデフォルト位置へ表示画像を移動する際には使用される。

【0079】

ピンチジェスチャは、タッチセンサ式ディスプレイ１１０、１１４またはジェスチャ捕捉領域１２０、１２４で受信する場合、ウィンドウの表示エリアもしくはサイズを最小化もしくは増加する（通常、共通のディスプレイで全体を受信する場合）、各ディスプレイ上のスタックの最上部に表示されるウィンドウを他のディスプレイのスタックの最上部に切り替える（通常、異なるディスプレイまたは画面で受信する場合）、または、アプリケーションマネージャを表示する（スタックにウィンドウを表示する「ポップアップウィンドウ」）際に使用することができる。スプレッドジェスチャは、タッチセンサ式ディスプレイ１１０、１１４またはジェスチャ捕捉領域１２０、１２４で受信する場合、ウィンドウの表示エリアもしくはサイズを最大化もしくは減少する、各ディスプレイ上のスタックの最上部に表示されるウィンドウを他のディスプレイのスタックの最上部に切り替える（通常、異なるディスプレイまたは画面で受信する場合）、または、アプリケーションマネージャを表示する（同じまたは異なる画面上の画面外ジェスチャ捕捉領域で受信する場合）際に使用することができる。

【0080】

図４Ｇの組み合わされたジェスチャは、共通のディスプレイまたは画面１０４、１０８内の共通のディスプレイ捕捉領域で受信する場合、ジェスチャを受信するディスプレイに一定の第１のスタックに第１のウィンドウスタック位置を保持する一方で、第２のウィンドウスタック位置を第２のウィンドウスタックに並べ替えて、ジェスチャを受信するディスプレイにウィンドウを含める際に使用することができる。図４Ｈの組み合わされたジェスチャは、共通のディスプレイもしくは画面１０４、１０８または異なるディスプレイもしくは画面内の異なるディスプレイ捕捉領域で受信する場合、ジェスチャのタップ部分を受信するディスプレイに一定の第１のウィンドウスタックに第１のウィンドウスタック位置を保持する一方で、第２のウィンドウスタック位置を第２のウィンドウスタックに並べ替えて、フリックまたはドラッグジェスチャを受信するディスプレイにウィンドウを含める際に使用することができる。先行例における特定のジェスチャ及びジェスチャ捕捉領域は、機能的な結果の対応するセットと関連付けられてきたが、これらの関連性は、いかなる方法でも再定義でき、ジェスチャ及び／またはジェスチャ捕捉領域及び／または機能的な結果間で異なる関連性を生成できることを理解されたい。
ファームウェア及びソフトウェア：
メモリ５０８は、１つまたは複数のソフトウェアコンポーネントを格納することができ、プロセッサ５０４は、それを実行することができる。これらのコンポーネントは、少なくとも１つのオペレーティングシステム（ＯＳ）５１６、アプリケーションマネージャ５６２、デスクトップ５６６及び／またはアプリケーションストア５６０からの１つもしくは複数のアプリケーション５６４ａ及び／または５６４ｂを含み得る。ＯＳ ５１６は、以前に図２と併せて説明された、フレームワーク５２０、１つもしくは複数のフレームバッファ５４８、１つもしくは複数のドライバ５１２及び／またはカーネル５１８を含み得る。ＯＳ ５１６は、プログラム及びデータからなる任意のソフトウェアであり得、プログラム及びデータは、コンピュータハードウェアリソースを管理し、さまざまなアプリケーション５６４の実行のための共通のサービスを提供する。ＯＳ ５１６は、任意のオペレーティングシステムであり得、少なくともいくつかの実施形態では、これらに限定されないが、リナックス（Ｌｉｎｕｘ）（登録商標）、アンドロイド（Ａｎｄｒｏｉｄ）（登録商標）、アイフォンＯＳ（ｉＰｈｏｎｅ ＯＳ）（ｉＯＳ（登録商標））、ウィンドウズフォン７（Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ ７）（登録商標）などを含むモバイルデバイス専用である。ＯＳ ５１６は、本明細書に記載されるように、１つまたは複数のオペレーションを実行することによって、電話に機能性を提供するよう動作可能である。

【0081】

アプリケーション５６４は、ユーザのための特定の機能性を実行する任意の高レベルのソフトウェアであり得る。アプリケーション５６４は、Ｅメールクライアント、ウェブブラウザ、テキストメッセージアプリケーション、ゲーム、メディアプレーヤ、オフィススイートなどのプログラムを含み得る。アプリケーション５６４は、アプリケーションストア５６０に格納することができ、アプリケーションストア５６０は、アプリケーション５６４を格納するための任意のメモリまたはデータストレージ及びそれに関連付けられた管理ソフトウェアを表し得る。実行された時点で、アプリケーション５６４は、メモリ５０８の異なるエリアで実行することができる。

【0082】

フレームワーク５２０は、デバイス上で実行されている複数のタスクの相互作用を可能にする任意のソフトウェアまたはデータであり得る。実施形態では、フレームワーク５２０の少なくとも部分及び以下で説明する個別のコンポーネントは、ＯＳ ５１６またはアプリケーション５６４の一部と見なすことができる。しかし、それらのコンポーネントはそのように限定されないことを除けば、これらの部分は、フレームワーク５２０の一部として説明される。フレームワーク５２０は、これらに限定されないが、複数ディスプレイ管理（ＭＤＭ）モジュール５２４、サーフェスキャッシュモジュール５２８、ウィンドウ管理モジュール５３２、入力管理モジュール５３６、タスク管理モジュール５４０、アプリケーションモデルマネージャ５４２、ディスプレイコントローラ、１つもしくは複数のフレームバッファ５４８、タスクスタック５５２、１つもしくは複数のウィンドウスタック５５０（ディスプレイエリア内のウィンドウ及び／またはデスクトップの論理構成である）及び／またはイベントバッファ５５６を含み得る。

【0083】

ＭＤＭモジュール５２４は、デバイスの画面上でアプリケーションまたは他のデータの表示を管理するよう動作可能な１つまたは複数のモジュールを含む。ＭＤＭモジュール５２４の実施形態は、図５Ｂと併せて説明する。実施形態では、ＭＤＭモジュール５２４は、ドライバ５１２などの他のＯＳ ５１６コンポーネントから及びアプリケーション５６４から入力を受信し、常にデバイス１００の状態を決定する。入力は、アプリケーションの優先度及び要件ならびにユーザ動作に応じてディスプレイをどのように構成して割り当てるかを決定する際にＭＤＭモジュール５２４を支援する。ディスプレイ構成に対する決定がなされた時点で、ＭＤＭモジュール５２４は、アプリケーション５６４とディスプレイとを結合することができる。次いで、１つまたは複数の他のコンポーネントに構成を提供して、ディスプレイでウィンドウを生成することができる。

【0084】

サーフェスキャッシュモジュール５２８は、ウィンドウの１つまたは複数の画像を格納またはキャッシュするための任意のメモリまたはストレージ及びそれに関連付けられたソフトウェアを含む。一連のアクティブ及び／または非アクティブウィンドウ（またはデスクトップ表示などの他の表示オブジェクト）は、各ディスプレイに関連付けられ得る。アクティブウィンドウ（または他の表示オブジェクト）が現時点で表示されている。非アクティブウィンドウ（または他の表示オブジェクト）は、ある時点で開かれ、表示されていたが、現時点では表示されていない。ユーザ経験を高めるため、ウィンドウをアクティブ状態から非アクティブ状態へ移行する前に、ウィンドウ（または他の表示オブジェクト）の最後に生成された画像の「スクリーンショット」を格納することができる。サーフェスキャッシュモジュール５２８は、現時点で表示されていないウィンドウ（または他の表示オブジェクト）の最後のアクティブ画像のビットマップを格納するよう動作可能であり得る。したがって、サーフェスキャッシュモジュール５２８は、データストアに非アクティブウィンドウ（または他の表示オブジェクト）の画像を格納する。

【0085】

実施形態では、ウィンドウ管理モジュール５３２は、それぞれのディスプレイ上でアクティブであるまたは非アクティブであるウィンドウ（または他の表示オブジェクト）を管理するよう動作可能である。ウィンドウ管理モジュール５３２は、ＭＤＭモジュール５２４、ＯＳ ５１６または他のコンポーネントからの情報に基づいて、ウィンドウ（または他の表示オブジェクト）がいつ可視であるかまたは非アクティブであるかを決定する。次いで、ウィンドウ管理モジュール５３２は、不可視ウィンドウ（または他の表示オブジェクト）を「非アクティブ状態」に置き、タスク管理モジュールタスク管理５４０と併せて、アプリケーションのオペレーションを一時停止する。さらに、ウィンドウ管理モジュール５３２は、ＭＤＭモジュール５２４との協働相互作用を通じて、ウィンドウ（または他の表示オブジェクト）にディスプレイ識別子を割り当てることも、ウィンドウ（または他の表示オブジェクト）に関連付けられたデータの１つまたは複数の他のアイテムを管理することもできる。また、ウィンドウ管理モジュール５３２は、アプリケーション５６４、タスク管理モジュール５４０、または、ウィンドウ（または他の表示オブジェクト）と相互作用するかもしくは関連付けられた他のコンポーネントに格納された情報を提供することもできる。また、ウィンドウ管理モジュール５３２は、動作空間内のウィンドウフォーカス及びディスプレイ座標に基づいて、入力タスクをウィンドウと関連付けることもできる。

【0086】

入力管理モジュール５３６は、デバイスで起こるイベントを管理するよう動作可能である。イベントは、例えば、ユーザとのユーザインタフェース相互作用などのウィンドウ環境への任意の入力である。入力管理モジュール５３６は、イベントを受信し、イベントをイベントバッファ５５６に論理的に格納する。イベントは、そのようなユーザインタフェース相互作用を、画面１０４、１０８がユーザからタッチ信号を受信した場合に起こる「ダウンイベント」、ユーザの指が画面を横切って移動していることを画面１０４、１０８が決定した場合に起こる「移動イベント」、ユーザが画面１０４、１０８に触れるのを止めたことを画面１０４、１０８が決定した場合に起こる「アップイベント」などとして含み得る。これらのイベントは、入力管理モジュール５３６によって、受信され、格納され、他のモジュールに転送される。また、入力管理モジュール５３６は、デバイス上で利用可能なすべての物理的及び仮想ディスプレイの集大成である動作空間に画面入力をマッピングすることもできる。

【0087】

動作空間は、一緒に「タイル化」してデバイス１００の物理的寸法を模倣した、すべてのタッチセンサ式ディスプレイ１１０、１１４を含む仮想化空間である。例えば、デバイス１００が展開されている場合は、動作空間サイズは９６０×８００であり得、これは、両方のタッチセンサ式ディスプレイ１１０、１１４の組み合わされたディスプレイエリア内の画素数であり得る。ユーザが位置（４０，４０）で第１のタッチセンサ式ディスプレイ１１０に触れる場合、全画面ウィンドウは、位置（４０，４０）でタッチイベントを受信することができる。ユーザが位置（４０，４０）で第２のタッチセンサ式ディスプレイ１１４に触れる場合、全画面ウィンドウは、位置（５２０，４０）でタッチイベントを受信することができるが、その理由は、第２のタッチセンサ式ディスプレイ１１４は第１のタッチセンサ式ディスプレイ１１０の右側にあり、したがって、デバイス１００は、第１のタッチセンサ式ディスプレイ１１０の幅の分、すなわち、４８０画素分だけ、そのタッチにオフセットを設けることができるためである。ドライバ５１２からの位置情報でハードウェアイベントが起こる場合、デバイスの向き及び状態に基づいてイベントの位置が異なり得るため、フレームワーク５２０は、物理的位置を動作空間にアップスケールすることができる。動作空間は、それが教示するすべて及びすべての目的のためにその全体が参照により本明細書に組み込まれる、２０１１年７月２０日に出願された「複数の入力デバイスに及ぶジェスチャ入力を受信するためのシステム及び方法（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｒｅｃｅｉｖｉｎｇ Ｇｅｓｔｕｒｅ Ｉｎｐｕｔｓ Ｓｐａｎｎｉｎｇ Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｄｅｖｉｃｅｓ）」と称する米国特許出願第１３／１８７，０２６号明細書に記載されるようなものであり得る。

【0088】

タスクは、アプリケーションであり得、サブタスクは、ユーザが、例えば、電話をする、写真を撮る、Ｅメールを送信するまたはマップを見るなど何かを行うために情報のやり取りを行うことができるウィンドウを提供するアプリケーションコンポーネントであり得る。各タスクには、ユーザインタフェースを描くためのウィンドウを与えることができる。ウィンドウは、通常、ディスプレイ（例えば、タッチセンサ式ディスプレイ１１０、１１４）全体を占めるが、ディスプレイ１１０、１１４より小さく、他のウィンドウ上で浮動してもよい。アプリケーションは、通常、互いに緩やかに結合された複数のサブタスクからなる。通常、アプリケーション内の１つのタスクが「メイン」タスクとして指定され、最初にアプリケーションに着手する際にユーザに提示される。次いで、各タスクは、別のタスクまたはサブタスクを開始して、異なる動作を実行することができる。

【0089】

タスク管理モジュール５４０は、デバイスによって実行することができる１つまたは複数のアプリケーション５６４のオペレーションを管理するよう動作可能である。したがって、タスク管理モジュール５４０は、信号を受信して、アプリケーションストア５６０に格納されたアプリケーションまたはアプリケーションサブタスクの着手、一時停止、終了などを行うことができる。次いで、タスク管理モジュール５４０は、アプリケーション５６４の１つまたは複数のタスクまたはサブタスクのインスタンスを作成し、アプリケーション５６４のオペレーションを開始することができる。さらに、タスク管理モジュール５４０は、ユーザ入力の結果または協働フレームワーク５２０コンポーネントからの信号の結果、タスクまたはサブタスクの着手、一時停止または終了を行うことができる。タスク管理モジュール５４０は、アプリケーションの着手からアプリケーションの終了までのアプリケーション（タスク及びサブタスク）のライフサイクルの管理に対する責任を有する。

【0090】

タスク管理モジュール５４０の処理は、タスクスタック５５２によって容易にし、タスクスタック５５２は、タスク管理モジュール５４０に関連付けられた論理構造である。タスクスタック５５２は、デバイス１００上のすべてのタスク及びサブタスクの状態を維持する。オペレーティングシステム５１６の一部のコンポーネントがタスクまたはサブタスクにそのライフサイクルにおける移行を行わせる必要がある場合、ＯＳ ５１６コンポーネントは、タスク管理モジュール５４０に通知することができる。次いで、タスク管理モジュール５４０は、識別情報を使用してタスクスタック５５２においてタスクまたはサブタスクを位置付け、タスクがどのようなライフサイクル移行を実行する必要があるかを示す信号をタスクまたはサブタスクに送信する。移行についてタスクまたはサブタスクに通知することにより、タスクまたはサブタスクは、ライフサイクル状態移行の準備を行うことができる。次いで、タスク管理モジュール５４０は、タスクまたはサブタスクに対する状態移行を実行することができる。実施形態では、状態移行は、終了が必要な場合に、ＯＳカーネル５１８をトリガしてタスクを終了することを伴う場合がある。

【0091】

さらに、タスク管理モジュール５４０は、ウィンドウ管理モジュール５３２からの情報に基づいて、アプリケーション５６４を一時停止することができる。アプリケーション５６４の一時停止により、メモリ内のアプリケーションデータを維持することができるが、ウィンドウまたはユーザインタフェースのレンダリングからアプリケーション５６４を制限することも停止することもある。再びアプリケーションがアクティブ状態になった時点で、タスク管理モジュール５４０は、再び、アプリケーションをトリガして、そのユーザインタフェースをレンダリングすることができる。実施形態では、タスクが一時停止されれば、タスクは、タスクの終了が行われる場合は、タスクの状態を保存することができる。一時停止状態では、アプリケーションウィンドウはユーザから見えないため、アプリケーションタスクは、入力を受信することはできない。

【0092】

フレームバッファ５４８は、ユーザインタフェースのレンダリングに使用される論理構造である。フレームバッファ５４８は、ＯＳカーネル５１８によって作成及び破壊され得る。しかし、ディスプレイコントローラ５４４は、可視ウィンドウに対し、画像データをフレームバッファ５４８に書き込むことができる。フレームバッファ５４８は、１つの画面または複数の画面に関連付けられ得る。画面とのフレームバッファ５４８の関連性は、ＯＳカーネル５１８との相互作用によって動的に制御することができる。複合ディスプレイは、複数の画面を単一のフレームバッファ５４８と関連付けることによって作成することができる。次いで、アプリケーションのウィンドウのユーザインタフェースのレンダリングに使用されるグラフィカルなデータは、複合ディスプレイに対し、単一のフレームバッファ５４８に書き込むことができ、それは複数画面１０４、１０８に出力される。ディスプレイコントローラ５４４は、アプリケーションのユーザインタフェースを、特定のディスプレイ１１０、１１４にマッピングされたフレームバッファ５４８の一部に移動させることができ、したがって、１つの画面１０４または１０８上にのみユーザインタフェースを表示することができる。ディスプレイコントローラ５４４は、ユーザインタフェースの制御を複数のアプリケーションに拡大し、フレームバッファ５４８またはその一部と関連付けられるだけの数のディスプレイに対してユーザインタフェースを制御することができる。この手法は、ディスプレイコントローラ５４４上のソフトウェアコンポーネントで使用中の複数の物理的画面１０４、１０８を補整する。

【0093】

アプリケーションマネージャ５６２は、ウィンドウ環境に対するプレゼンテーション層を提供するアプリケーションである。したがって、アプリケーションマネージャ５６２は、タスク管理モジュール５４０によるレンダリングのためのグラフィカルなモデルを提供する。同様に、デスクトップ５６６は、アプリケーションストア５６０に対するプレゼンテーション層を提供する。したがって、デスクトップは、レンダリング用にウィンドウ管理モジュール５５６に提供することができるアプリケーションストア５６０内のアプリケーション５６４用の選択可能なアプリケーションアイコンを有する表面のグラフィカルなモデルを提供する。

【0094】

さらに、フレームワークは、アプリケーションモデルマネージャ（ＡＭＭ）５４２を含み得る。アプリケーションマネージャ５６２は、ＡＭＭ ５４２とインタフェースをとることができる。実施形態では、ＡＭＭ ５４２は、アプリケーションの状態（実行中または一時停止中）に関する状態変化情報をデバイス１００から受信する。ＡＭＭ ５４２は、サーフェスキャッシュモジュール５２８からのビットマップ画像を活動中（実行中または一時停止中）のタスクと関連付けることができる。さらに、ＡＭＭ ５４２は、タスク管理モジュール５４０内で維持されている論理的ウィンドウスタックを、ディスプレイ外のジェスチャ捕捉エリア１２０を使用してウィンドウをより分ける際にユーザが捉える線形（「フィルムストリップ」または「トランプ一組」）組織に変換することができる。さらに、ＡＭＭ ５４２は、実行中のアプリケーションのリストを、アプリケーションマネージャ５６２に提供することができる。

【0095】

ＭＤＭモジュール５２４の実施形態を図５Ｂに示す。ＭＤＭモジュール５２４は、これらに限定されないが、デバイスの向き、デバイス１００は開いているかまたは閉じているか、どのアプリケーション５６４を実行しているか、どのようにアプリケーション５６４を表示するか、ユーザはどの動作を行っているか、表示されているタスクなどを含むデバイスのための環境の状態を決定するよう動作可能である。ディスプレイを構成するため、ＭＤＭモジュール５２４は、図６Ａ〜６Ｊと併せて説明されるように、これらの環境要因を解釈し、ディスプレイ構成を決定する。次いで、ＭＤＭモジュール５２４は、アプリケーション５６４または他のデバイスコンポーネントをディスプレイと結合することができる。次いで、ディスプレイコントローラ５４４及び／またはＯＳ ５１６内の他のコンポーネントに構成を送信し、ディスプレイを生成することができる。ＭＤＭモジュール５２４は、これらに限定されないが、ディスプレイ構成モジュール５６８、優先度モジュール５７２、デバイス状態モジュール５７４、ジェスチャモジュール５７６、要件モジュール５８０、イベントモジュール５８４及び／または結合モジュール５８８のうちの１つまたは複数を含み得る。

【0096】

ディスプレイ構成モジュール５６８は、ディスプレイ用のレイアウトを決定する。実施形態では、ディスプレイ構成モジュール５６８は、環境因子を決定することができる。環境因子は、１つまたは複数の他のＭＤＭモジュール５２４からまたは他のソースから受信することができる。次いで、ディスプレイ構成モジュール５６８は、因子のリストからディスプレイに最適な構成を決定することができる。可能な構成及びそれに関連付けられた因子のいくつかの実施形態については、図６Ａ〜６Ｆと併せて説明する。

【0097】

優先度モジュール５７２は、アプリケーション５６４または他のコンポーネントの表示優先度を決定するよう動作可能である。例えば、アプリケーションは、単一またはデュアルディスプレイに対する優先度を有し得る。優先度モジュール５７２は、アプリケーションの表示優先度を決定することができ（例えば、アプリケーションの優先度設定を検査することによって）、デバイス１００が好ましいモードに対応することができる状態にある場合は、アプリケーション５６４がモード（例えば、単一画面、二重画面、最大など）を変更することを可能にする場合がある。しかし、いくつかのユーザインタフェース方針は、そのモードが利用可能であっても、モードを認めない場合がある。デバイスの構成が変化すると、優先度を見直して、アプリケーション５６４に対してより良いディスプレイ構成を実現できるかどうかを決定することができる。

【0098】

デバイス状態モジュール５７４は、デバイスの状態を決定または受信するよう動作可能である。デバイスの状態は、図３Ａ及び３Ｂと併せて説明されるようなものであり得る。デバイスの状態は、ディスプレイ構成モジュール５６８で使用して、ディスプレイの構成を決定することができる。このように、デバイス状態モジュール５７４は、入力を受信し、デバイスの状態を解釈することができる。次いで、状態情報は、ディスプレイ構成モジュール５６８に提供される。

【0099】

ジェスチャモジュール５７６は、ＭＤＭモジュール５２４の一部として示されるが、実施形態では、ジェスチャモジュール５７６は、ＭＤＭモジュール５２４から分離された別々のフレームワーク５２０コンポーネントであり得る。実施形態では、ジェスチャモジュール５７６は、ユーザインタフェースの任意の部分でユーザが何らかの動作を行っているかどうかを決定するよう動作可能である。代替の実施形態では、ジェスチャモジュール５７６は、構成可能なエリア１１２、１１６のみからユーザインタフェース動作を受信する。ジェスチャモジュール５７６は、入力管理モジュール５３６を用いて、構成可能なエリア１１２、１１６（または、場合により、他のユーザインタフェースエリア）上で起こるタッチイベントを受信することができ、タッチイベントを解釈して（方向、速度、距離、持続時間及びさまざまな他のパラメータを使用して）ユーザがどのようなジェスチャを実行しているかを決定することができる。ジェスチャが解釈されると、ジェスチャモジュール５７６は、ジェスチャの処理に着手することができ、他のフレームワーク５２０コンポーネントと協働して、必要なウィンドウアニメーションを管理することができる。ジェスチャモジュール５７６は、アプリケーションモデルマネージャ５４２と協働して、どのアプリケーションが実行中（アクティブまたは一時停止）か、及び、ユーザジェスチャが実行される際にアプリケーションが現れなければならない順番に関する状態情報を収集する。また、ジェスチャモジュール５７６は、ビットマップ（サーフェスキャッシュモジュール５２８から）及びライブウィンドウへの参照を受信することができ、その結果、ジェスチャが起こると、ジェスチャモジュール５７６は、ディスプレイ１１０、１１４を横切ってウィンドウを移動させる方法をディスプレイコントローラ５４４に指示することができる。したがって、一時停止されたアプリケーションは、それらのウィンドウがディスプレイ１１０、１１４を横切って移動すると、実行しているように見える。

【0100】

さらに、ジェスチャモジュール５７６は、タスク管理モジュール５４０または入力管理モジュール５３６のいずれかからタスク情報を受信することができる。ジェスチャは、図４Ａ〜４Ｈと併せて定義されるようなものであり得る。例えば、ウィンドウの移動により、ディスプレイは、ウィンドウの移動を示す一連のディスプレイフレームをレンダリングする。そのようなユーザインタフェース相互作用に関連付けられたジェスチャは、ジェスチャモジュール５７６で受信し解釈することができる。次いで、ユーザジェスチャについての情報はタスク管理モジュール５４０に送信され、タスクのディスプレイ結合が修正される。

【0101】

優先度モジュール５７２と同様の要件モジュール５８０は、アプリケーション５６４または他のコンポーネントに対するディスプレイ要件を決定するよう動作可能である。アプリケーションは、観察しなければならないディスプレイ要件セットを有し得る。いくつかのアプリケーションは、特定のディスプレイ方向を必要とする。例えば、アプリケーション「アングリバード（Ａｎｇｒｙ Ｂｉｒｄｓ）」は、横向きでのみ表示することができる。この種のディスプレイ要件は、要件モジュール５８０によって決定または受信することができる。デバイスの向きが変更されると、要件モジュール５８０は、アプリケーション５６４に対するディスプレイ要件を再び主張することができる。ディスプレイ構成モジュール５６８は、要件モジュール５８０によって提供されるアプリケーション表示要件に従ったディスプレイ構成を生成することができる。

【0102】

ジェスチャモジュール５７６と同様のイベントモジュール５８４は、ユーザインタフェースに影響を及ぼし得るアプリケーションまたは他のコンポーネントで起こる１つまたは複数のイベントを決定するよう動作可能である。したがって、イベントモジュール５８４は、イベントバッファ５５６またはタスク管理モジュール５４０のいずれかからイベント情報を受信することができる。これらのイベントは、タスクがどのようにディスプレイと結合されるか変更することができる。イベントモジュール５８４は、他のフレームワーク５２０コンポーネントから状態変化情報を収集し、その状態変化情報に応じて作用され得る。一例では、電話が開かれるか、または閉じられる場合、または方向変化が生じる場合、新しいメッセージが二次画面にレンダリングされる。このイベントに基づく状態変化は、イベントモジュール５８４により受信され、解釈されることができる。次いで、イベントについての情報は、ディスプレイ構成モジュール５６８に送信され、ディスプレイの構成を修正することができる。

【0103】

結合モジュール５８８は、アプリケーション５６４または他のコンポーネントをディスプレイ構成モジュール５６８によって決定された構成と結合するよう動作可能である。結合は、メモリ内で、各アプリケーションに対するディスプレイ構成をアプリケーションの表示及びモードと関連付ける。したがって、結合モジュール５８８は、アプリケーションをそのアプリケーションに対するディスプレイ構成（例えば、横向き、縦向き、複数画面など）と関連付けることができる。次いで、結合モジュール５８８は、ディスプレイ識別子をディスプレイに割り当てることができる。ディスプレイ識別子は、アプリケーションをデバイス１００の特定のディスプレイと関連付ける。次いで、この結合は、格納され、ディスプレイコントローラ５４４、ＯＳ ５１６の他のコンポーネントまたは他のコンポーネントに提供され、ディスプレイが適正にレンダリングされる。結合は、動的であり、イベント、ジェスチャ、状態変化、アプリケーション優先度または要件などに関連付けられた構成変更に基づいて、変更することも更新することもできる。
ユーザインタフェース構成：
ここで図６Ａ〜Ｊを参照し、デバイス１００によって可能となったさまざまなタイプの出力構成について以下で説明する。

【0104】

図６Ａ及び６Ｂは、第１の状態にあるデバイス１００の２つの異なる出力構成を描写する。具体的には、図６Ａは、閉縦向き状態３０４にあるデバイス１００を描写し、データは、一次画面１０４に表示される。この例では、デバイス１００は、第１の縦向き構成６０４でタッチセンサ式ディスプレイ１１０を介してデータを表示する。理解できるように、第１の縦向き構成６０４は、デスクトップまたはオペレーティングシステムホーム画面のみを表示することができる。あるいは、デバイス１００が第１の縦向き構成６０４でデータを表示している間、１つまたは複数のウィンドウを縦向きで提示することができる。

【0105】

図６Ｂは、依然として閉縦向き状態３０４にあるデバイス１００を描写するが、代わりに、データは、二次画面１０８に表示される。この例では、デバイス１００は、第２の縦向き構成６０８でタッチセンサ式ディスプレイ１１４を介してデータを表示する。

【0106】

第１または第２の縦向き構成６０４、６０８のいずれかで同様のまたは異なるデータを表示することが可能である場合がある。また、ユーザジェスチャ（例えば、ダブルタップジェスチャ）、メニュー選択または他の手段をデバイス１００に提供することによって、第１の縦向き構成６０４と第２の縦向き構成６０８との間を移行することが可能である場合もある。また、他の適切なジェスチャを使用して、構成間を移行することもできる。その上、デバイス１００がどの状態に移動されるかに応じて、第１または第２の縦向き構成６０４、６０８から本明細書に記載される他の任意の構成へデバイス１００を移行することが可能である場合もある。

【0107】

代替の出力構成は、第２の状態にあるデバイス１００によって対応することができる。具体的には、図６Ｃは、第３の縦向き構成を描写し、データは、一次画面１０４と二次画面１０８の両方に同時に表示される。第３の縦向き構成は、デュアル縦向き（ＰＤ）出力構成と呼ばれる場合がある。ＰＤ出力構成では、一次画面１０４のタッチセンサ式ディスプレイ１１０は、第１の縦向き構成６０４でデータを描写する一方で、二次画面１０８のタッチセンサ式ディスプレイ１１４は、第２の縦向き構成６０８でデータを描写する。第１の縦向き構成６０４と第２の縦向き構成６０８の同時プレゼンテーションは、デバイス１００が開縦向き状態３２０にある場合に起こり得る。この構成では、デバイス１００は、１つのアプリケーションウィンドウを１つのディスプレイ１１０または１１４に、２つのアプリケーションウィンドウを（それぞれのディスプレイ１１０及び１１４に１つずつ）、１つのアプリケーションウィンドウと１つのデスクトップを、または、１つのデスクトップを表示することができる。また、他の構成も可能である場合がある。デバイス１００がどの状態に移動されるかに応じて、構成６０４、６０８の同時表示から本明細書に記載される他の任意の構成へデバイス１００を移行することが可能である場合もあることを理解されたい。その上、この状態にある間、アプリケーションの表示優先度により、両ディスプレイがアクティブであり、同じアプリケーションで異なるウィンドウを表示する両面モードにデバイスが置かれる場合がある。例えば、カメラアプリケーションは、一面でファインダ及び制御を表示することができる一方で、他面は被写体で見ることができるミラーリングされたプレビューを表示する。また、２人のプレーヤによる同時プレーを伴うゲームも、両面モードを利用することができる。

【0108】

図６Ｄ及び６Ｅは、第３の状態にあるデバイス１００の２つのさらなる出力構成を描写する。具体的には、図６Ｄは、閉横向き状態３４０にあるデバイス１００を描写し、データは、一次画面１０４に表示される。この例では、デバイス１００は、第１の横向き構成６１２でタッチセンサ式ディスプレイ１１０を介してデータを表示する。本明細書に記載される他の構成に類似して、第１の横向き構成６１２は、デスクトップ、ホーム画面、アプリケーションデータを表示する１つもしくは複数のウィンドウまたは同様のものを表示することができる。

【0109】

図６Ｅは、依然として閉横向き状態３４０にあるデバイス１００を描写するが、代わりに、データは、二次画面１０８に表示される。この例では、デバイス１００は、第２の横向き構成６１６でタッチセンサ式ディスプレイ１１４を介してデータを表示する。第１または第２の横向き構成６１２、６１６のいずれかで同様のまたは異なるデータを表示することが可能である場合がある。ツイスト及びタップジェスチャまたはフリップ及びスライドジェスチャの一方または両方をデバイス１００に提供することによって、第１の横向き構成６１２と第２の横向き構成６１６との間を移行することが可能である場合もある。また、他の適切なジェスチャを使用して、構成間を移行することもできる。その上、デバイス１００がどの状態に移動されるかに応じて、第１または第２の横向き構成６１２、６１６から本明細書に記載される他の任意の構成へデバイス１００を移行することが可能である場合もある。

【0110】

図６Ｆは、第３の横向き構成を描写し、データは、一次画面１０４と二次画面１０８の両方に同時に表示される。第３の横向き構成は、デュアル横向き（ＬＤ）出力構成と呼ばれる場合がある。ＬＤ出力構成では、一次画面１０４のタッチセンサ式ディスプレイ１１０は、第１の横向き構成６１２でデータを描写する一方で、二次画面１０８のタッチセンサ式ディスプレイ１１４は、第２の横向き構成６１６でデータを描写する。第１の横向き構成６１２と第２の横向き構成６１６の同時プレゼンテーションは、デバイス１００が開横向き状態３４０にある場合に起こり得る。デバイス１００がどの状態に移動されるかに応じて、構成６１２、６１６の同時表示から本明細書に記載される他の任意の構成へデバイス１００を移行することが可能である場合もあることを理解されたい。

【0111】

図６Ｇ及び６Ｈは、さらに別の状態にあるデバイス１００の２つの図を描写する。具体的には、デバイス１００は、イーゼル状態３１２にあるものとして描写される。図６Ｇは、第１のイーゼル出力構成６１８をタッチセンサ式ディスプレイ１１０に表示できることを示す。図６Ｈは、第２のイーゼル出力構成６２０をタッチセンサ式ディスプレイ１１４に表示できることを示す。デバイス１００は、第１のイーゼル出力構成６１８または第２のイーゼル出力構成６２０のいずれかを個別に描写するよう構成することができる。あるいは、イーゼル出力構成６１８、６２０の両方を同時に提示することができる。いくつかの実施形態では、イーゼル出力構成６１８、６２０は、横向き出力構成６１２、６１６と同様でも同一でもよい。また、デバイス１００は、変形イーゼル状態３１６にある間、イーゼル出力構成６１８、６２０の一方または両方を表示するよう構成することができる。イーゼル出力構成６１８、６２０の同時利用は、２人用のゲーム（例えば、バトルシップ（Ｂａｔｔｌｅｓｈｉｐ）（登録商標）、チェス、チェッカなど）、２人以上のユーザが同じデバイス１００及び他のアプリケーションを共有する複数ユーザ会議を容易にできることを理解されたい。理解できるように、デバイス１００がどの状態に移動されるかに応じて、構成６１８、６２０の一方または両方のディスプレイから本明細書に記載される他の任意の構成へデバイス１００を移行することが可能である場合もある。

【0112】

図６Ｉは、デバイス１００が開縦向き状態３２０にある間に対応することができるさらなる別の出力構成を描写する。具体的には、デバイス１００は、本明細書で縦向きマックス（ＰＭａｘ）構成６２４と呼ばれる縦向き構成で、両方のタッチセンサ式ディスプレイ１１０、１１４にわたって単一の連続画像を提示するよう構成することができる。この構成では、データ（例えば、単一画像、アプリケーション、ウィンドウ、アイコン、ビデオなど）は、分割して、タッチセンサ式ディスプレイの１つに部分的に表示する一方で、データの他の部分を他のタッチセンサ式ディスプレイに表示することができる。Ｐｍａｘ構成６２４は、デバイス１００上に特定の画像を表示するためのより大きな表示及び／またはより良好な解像度を容易にすることができる。他の出力構成と同様に、デバイス１００がどの状態に移動されるかに応じて、Ｐｍａｘ構成６２４から本明細書に記載される他の任意の出力構成へデバイス１００を移行することが可能である場合がある。

【0113】

図６Ｊは、デバイス１００が開横向き状態３４８にある間に対応することができるさらなる別の出力構成を描写する。具体的には、デバイス１００は、本明細書で横向きマックス（ＬＭａｘ）構成６２８と呼ばれる横向き構成で、両方のタッチセンサ式ディスプレイ１１０、１１４にわたって単一の連続画像を提示するよう構成することができる。この構成では、データ（例えば、単一画像、アプリケーション、ウィンドウ、アイコン、ビデオなど）は、分割して、タッチセンサ式ディスプレイの１つに部分的に表示する一方で、データの他の部分を他のタッチセンサ式ディスプレイに表示することができる。Ｌｍａｘ構成６２８は、デバイス１００上に特定の画像を表示するためのより大きな表示及び／またはより良好な解像度を容易にすることができる。他の出力構成と同様に、デバイス１００がどの状態に移動されるかに応じて、Ｌｍａｘ構成６２８から本明細書に記載される他の任意の出力構成へデバイス１００を移行することが可能である場合がある。

【0114】

図７Ａ及び７Ｂに示されるように、デバイス１００は、少なくとも１つのウィンドウスタック７００、７２８でデスクトップ及び／またはウィンドウを管理する。ウィンドウスタック７００、７２８は、複数画面デバイスに対するアクティブ及び／または非アクティブウィンドウの論理構成である。例えば、ウィンドウスタック７００または７２８は、トランプ一組と論理的に同様であり得、図７Ａ及び７Ｂに示されるように、１つまたは複数のウィンドウまたはデスクトップは、順番に配置される。アクティブウィンドウは、タッチセンサ式ディスプレイ１１０、１１４の少なくとも１つに現時点で表示されているウィンドウである。例えば、ウィンドウ１０４及び１０８は、アクティブウィンドウであり、タッチセンサ式ディスプレイ１１０及び１１４上に表示されている。非アクティブウィンドウは、開かれ、表示されていたが、現時点ではアクティブウィンドウの「背後」にあり、表示されていないウィンドウである。実施形態では、非アクティブウィンドウは、一時停止中であるアプリケーション用であり得、したがって、ウィンドウはアクティブコンテンツを表示していない。例えば、ウィンドウ７１２、７１６、７２０及び７２４は非アクティブウィンドウである。

【0115】

ウィンドウスタック７００、７２８は、さまざまな構成または組織構造を有し得る。図７Ａに示される実施形態では、デバイス１００は、第１のタッチセンサ式ディスプレイ１１０に関連付けられた第１のスタック７６０と、第２のタッチセンサ式ディスプレイ１１４に関連付けられた第２のスタック７６４とを含む。したがって、各タッチセンサ式ディスプレイ１１０及び１１４は、それぞれに関連付けられたウィンドウスタック７６０、７６４を有し得る。これらの２つのウィンドウスタック７６０、７６４は、それぞれのスタック７６０、７６４に配置された異なる数のウィンドウを有し得る。さらに、２つのウィンドウスタック７６０、７６４は、異なる方法で識別し、別々に管理することもできる。したがって、第１のウィンドウスタック７６０は、第１のウィンドウ７０４から次のウィンドウ７２０へ、そして最後のウィンドウ７２４へ、そして最終的にデスクトップ７２２（実施形態ではウィンドウスタック７６０の「最下部」である）へと順番に配置することができる。実施形態では、デスクトップ７２２下のウィンドウスタックにアプリケーションウィンドウを配置することができ、また、デスクトップを見えるようにしている（ｄｅｓｋｔｏｐ ｒｅｖｅａｌ）間、デスクトップ７２２を他のウィンドウ上のスタックの「最上部」へ持ってくることができるため、デスクトップ７２２は常に「最下部」であるとは限らない。同様に、第２のスタック７６４は、第１のウィンドウ７０８から次のウィンドウ７１２へ、そして最後のウィンドウ７１６へ、そして最終的にデスクトップ７１８（実施形態では、デスクトップ７２２を有し、ウィンドウスタック７６０とウィンドウスタック７６４の両方のすべてのウィンドウ下の単一のデスクトップエリアである）へと配置することができる。２つのウィンドウスタック７６０、７６４を管理するための論理データ構造は、以下の図８と併せて説明されるようなものであり得る。

【0116】

ウィンドウスタック７２８の別の構成を図７Ｂに示す。この実施形態では、両方のタッチセンサ式ディスプレイ１１０、１１４に対して、単一のウィンドウスタック７２８が存在する。したがって、ウィンドウスタック７２８は、デスクトップ７５８から第１のウィンドウ７４４へ、そして最後のウィンドウ７５６へと配置される。ウィンドウは、特定のタッチセンサ式ディスプレイ１１０、１１４に関連付けられることなく、すべてのウィンドウの中のある位置に配置することができる。この実施形態では、各ウィンドウは、ウィンドウ順に並んでいる。さらに、少なくとも１つのウィンドウは、アクティブ状態にあると識別される。例えば、単一のウィンドウは、第１のタッチセンサ式画面１１０と第２のタッチセンサ式画面１１４のそれぞれで表示される２つの部分７３２及び７３６でレンダリングすることができる。この単一のウィンドウは、両方のディスプレイ１１０、１１４上に表示されているが、ウィンドウスタック７２８において、単一の位置のみを占有することができる。

【0117】

ウィンドウスタック７６０のさらなる別の構成を図７Ｃ〜７Ｅに示す。ウィンドウスタック７６０は、３つの「立体」図で示される。図７Ｃでは、ウィンドウスタック７６０の上面を示す。ウィンドウスタック７６０の２つの側面は、図７Ｄ及び７Ｅに示す。この実施形態では、ウィンドウスタック７６０は、レンガの積み重ねに似ている。ウィンドウは、互いに積み重ねられる。図７Ｃは、ウィンドウスタック７６０を上方から見ているため、複合ディスプレイ７６４の異なる部分においてウィンドウスタック７６０の最上部のウィンドウしか見えない。複合ディスプレイ７６４は、デバイス１００のディスプレイエリア全体のための論理モデルを表し、タッチセンサ式ディスプレイ１１０及びタッチセンサ式ディスプレイ１１４を含み得る。デスクトップ７８６（図７Ｄ及び７Ｅ）またはウィンドウは、複合ディスプレイ７６４の一部または全体を占有することができる。

【0118】

示される実施形態では、デスクトップ７８６がウィンドウスタック７６０の最下部のディスプレイまたは「レンガ」である。そこから、ウィンドウ１ ７８２、ウィンドウ２ ７８２、ウィンドウ３ ７６８及びウィンドウ４ ７７０が積層される。ウィンドウ１ ７８２、ウィンドウ３ ７６８、ウィンドウ２ ７８２及びウィンドウ４ ７７０は、複合ディスプレイ７６４のほんの一部を占領する。したがって、スタック７６０の別の部分は、ウィンドウ８ ７７４と、セクション７９０で示されるウィンドウ５〜７とを含む。複合ディスプレイ７６４の任意の部分の最上部のウィンドウのみが実際にレンダリングされ、表示される。したがって、図７Ｃの上面図に示されるように、ウィンドウスタック７６０の異なる部分においてディスプレイの最上部にあるものとして、ウィンドウ４ ７７０、ウィンドウ８ ７７４及びウィンドウ３ ７６８が表示される。ウィンドウは、寸法変更して、複合ディスプレイ７６０のほんの一部を占有し、ウィンドウスタック７６０の下方のウィンドウを「明らかにする」ことができる。例えば、ウィンドウ３ ７６８は、スタックにおいて、ウィンドウ４ ７７０及びウィンドウ８ ７７４の下方にあるが、依然として表示されている。ウィンドウスタックを管理する論理データ構造は、図８と併せて説明されるようなものであり得る。

【0119】

デバイス１００上で新しいウィンドウを開くと、一般に、新たに起動されたウィンドウがスタックの最上部に配置される。しかし、ウィンドウがスタック内のどこにどのように配置されるかは、デバイス１００の向き、どのプログラム、機能、ソフトウェアなどがデバイス１００上で実行されているかについてのコンテキスト、新しいウィンドウが開かれた際にどのようにスタックが配置されるかなどに依存し得る。ウィンドウをスタックに挿入するため、スタック内のウィンドウの位置が決定され、また、ウィンドウが関連付けられるタッチセンサ式ディスプレイ１１０、１１４も決定することができる。この情報を用いて、ウィンドウ用の論理データ構造を作成し、格納することができる。ユーザインタフェースまたは他のイベントもしくはタスクがウィンドウの配置を変化させると、配置の変化を反映するため、ウィンドウスタックが変更され得る。上記で説明されるこれらの同じ概念を使用して、デバイス１００用の１つまたは複数のデスクトップを管理できることに留意されたい。

【0120】

ウィンドウスタック内のウィンドウまたはデスクトップの配置を管理するための論理データ構造８００を図８に示す。論理データ構造８００は、オブジェクト、記録、ファイルなどにかかわらず、データの格納に使用される任意のデータ構造であり得る。論理データ構造８００は、プロトコルまたは規格にかかわらず、いかなるタイプのデータベースまたはデータ格納システムにも格納することができる。実施形態では、論理データ構造８００は、情報の容易な格納及び回収を可能にする論理構成でデータを格納する１つまたは複数の部分、フィールド、属性などを含む。以下では、これらの１つまたは複数の部分、フィールド、属性などを単なるフィールドとして説明するものとする。フィールドは、ウィンドウ識別子８０４、寸法８０８、スタック位置識別子８１２、ディスプレイ識別子８１６及び／またはアクティブインジケータ８２０に対するデータを格納することができる。ウィンドウスタック内の各ウィンドウは、関連する論理データ構造８００を有し得る。図８では、単一の論理データ構造８００が示されているが、楕円８２４によって表されるように、ウィンドウスタックで使用されるより多くのまたはより少ない論理データ構造８００が存在し得る（スタック内のウィンドウまたはデスクトップの数に基づいて）。さらに、楕円８２８によって表されるように、図８に示されるものより多くのまたはより少ないフィールドが存在し得る。

【0121】

ウィンドウ識別子８０４は、ウィンドウスタック内の他のウィンドウとの関連で、関連ウィンドウを独自に識別する任意の識別子（ＩＤ）を含み得る。ウィンドウ識別子８０４は、グローバル一意識別子（ＧＵＩＤ）、数値ＩＤ、英数字ＩＤまたは他のタイプの識別子であり得る。実施形態では、ウィンドウ識別子８０４は、開くことができるウィンドウの数に基づく１桁、２桁または任意の桁数であり得る。代替の実施形態では、ウィンドウ識別子８０４のサイズは、開いているウィンドウの数に基づいて変化し得る。ウィンドウが開いている間、ウィンドウ識別子８０４は、静的で、不変のままであり得る。

【0122】

寸法８０８は、複合ディスプレイ７６０のウィンドウの寸法を含み得る。例えば、寸法８０８は、ウィンドウの２つ以上の角部の座標を含むことも、１つの座標ならびにウィンドウの幅及び高さに対する寸法を含むこともある。これらの寸法８０８は、ウィンドウが複合ディスプレイ７６０のどの部分を占有することができるかを描写することができ、それは、複合ディスプレイ７６０全体でも、複合ディスプレイ７６０のほんの一部でもあり得る。例えば、ウィンドウ４ ７７０は、図７Ｃ〜７Ｅに示されるように、ウィンドウ７７０が複合ディスプレイ７６０のディスプレイエリアのほんの一部を占有することを示す寸法８０８を有し得る。ウィンドウがウィンドウスタック内で移動されるかまたは挿入されると、寸法８０８は変化し得る。

【0123】

スタック位置識別子８１２は、ウィンドウのスタック内での位置を識別することができるか、または、リストもしくはスタックなどのデータ構造内のウィンドウの制御記録から推定することができる任意の識別子であり得る。スタック位置識別子８１２は、ＧＵＩＤ、数値ＩＤ、英数字ＩＤまたは他のタイプの識別子であり得る。各ウィンドウまたはデスクトップは、スタック位置識別子８１２を含み得る。例えば、図７Ａに示されるように、スタック１ ７６０のウィンドウ１ ７０４は、ウィンドウ７０４がスタック ７６０の第１のウィンドウであり、アクティブウィンドウであることを特定する１のスタック位置識別子８１２を有し得る。同様に、ウィンドウ６ ７２４は、ウィンドウ７２４がスタック ７６０の第３のウィンドウであることを表す３のスタック位置識別子８１２を有し得る。また、ウィンドウ２ ７０８は、ウィンドウ７０８が第２のスタック ７６４の第１のウィンドウであることを表す１のスタック位置識別子８１２を有し得る。図７Ｂに示されるように、ウィンドウ１ ７４４は、１のスタック位置識別子８１２を有し得、部分７３２及び７３６にレンダリングされたウィンドウ３は、３のスタック位置識別子８１２を有し得、ウィンドウ６ ７５６は、６のスタック位置識別子８１２を有し得る。したがって、スタックのタイプに応じて、スタック位置識別子８１２は、スタック内でのウィンドウの位置を表すことができる。

【0124】

ディスプレイ識別子８１６は、第１のディスプレイ１１０もしくは第２のディスプレイ１１４、または、両方のディスプレイで構成された複合ディスプレイ７６０などの特定のディスプレイにウィンドウまたはデスクトップが関連付けられていることを特定することができる。図７Ａに示されるように、このディスプレイ識別子８１６は複数スタックシステムで必要とされない場合があるが、ディスプレイ識別子８１６は、図７Ｂの連続スタック内のウィンドウが特定のディスプレイに表示されているかどうかを示すことができる。したがって、ウィンドウ３は、図７Ｂにおいて、２つの部分７３２及び７３６を有し得る。第１の部分７３２は、第１のディスプレイに対するディスプレイ識別子８１６を有し得る一方で、第２の部分７３６は、第２のディスプレイ１１４に対するディスプレイ識別子８１６を有し得る。しかし、代替の実施形態では、ウィンドウは、ウィンドウが両方のディスプレイ１１０、１１４に表示されていること、または、ディスプレイ識別子８１６が複合ディスプレイを特定したことを表す２つのディスプレイ識別子８１６を有し得る。別の代替の実施形態では、ウィンドウは、ウィンドウが両方のディスプレイ１１０、１１４に表示されていることを表すための単一のディスプレイ識別子８１６を有し得る。

【0125】

ディスプレイ識別子８１６と同様に、アクティブインジケータ８２０は、スタック位置１のウィンドウがアクティブであり、表示されているため、図７Ａのデュアルスタックシステムで必要とされない場合がある。図７Ｂのシステムでは、アクティブインジケータ８２０は、スタック内のどのウィンドウが表示されているかを示すことができる。したがって、ウィンドウ３は、図７において、２つの部分７３２及び７３６を有し得る。第１の部分７３２がアクティブインジケータ８２０を有する一方で、第２の部分７３６もまたアクティブインジケータ８２０を有し得る。しかし、代替の実施形態では、ウィンドウ３は、単一のアクティブインジケータ８２０を有し得る。アクティブインジケータ８２０は、ウィンドウがアクティブであるかまたは表示されていることを表す簡単なフラグまたはビットであり得る。

【0126】

ウィンドウスタックを作成するための方法９００の実施形態を図９に示す。図９では、方法９００の工程の一般的な順番を示す。一般に、方法９００は、開始動作９０４で始まり、終了動作９２８で終了する。方法９００は、図９に示されるものより多くのまたはより少ない工程を含むことも、異なる形で工程の順番を整えることもできる。方法９００は、コンピュータシステムによって実行され、コンピュータ可読媒体で符号化されるかまたは格納される一連のコンピュータ実行可能命令として実行することができる。以下では、図１〜８と併せて説明されるシステム、コンポーネント、モジュール、ソフトウェア、データ構造、ユーザインタフェースなどを参照して、方法９００を説明する。

【0127】

工程９０８では、複数画面デバイス１００は、ウィンドウの起動を受信することができる。実施形態では、複数画面デバイス１００は、タッチセンサ式ディスプレイ１１０もしくは１１４、構成可能なエリア１１２もしくは１１６、ジェスチャ捕捉領域１２０もしくは１２４、または、ユーザインタフェース入力を受信するよう動作可能ないくつかの他のハードウェアセンサから入力を受信することによって、ウィンドウの起動を受信することができる。プロセッサは、タスク管理モジュール５４０を実行して入力を受信することができる。タスク管理モジュール５４０は、ウィンドウスタックにウィンドウを開く、実行すべきアプリケーションタスクを要求するものとして入力を解釈することができる。

【0128】

実施形態では、タスク管理モジュール５４０は、複数ディスプレイ管理モジュール５２４（図５Ａ、５Ｂ）のディスプレイ構成モジュール５６８（図５Ｂ）に作用されるタスクスタック５５２（図５Ａ）にユーザインタフェース相互作用を置く。さらに、タスク管理モジュール５４０は、複数ディスプレイ管理モジュール５２４からの情報を待ち、ウィンドウ管理モジュール５３２に命令を送信して、ウィンドウスタックにウィンドウを作成する。

【0129】

工程９１２では、複数ディスプレイ管理モジュール５２４は、タスク管理モジュール５４０から命令を受信すると、新たに起動されたウィンドウを関連付けるべき複合ディスプレイ７６０のタッチ部分を決定する。例えば、ウィンドウ４ ７７０は、複合ディスプレイ７６４と関連付けられる。実施形態では、複数ディスプレイ管理モジュール５２４のデバイス状態モジュール５７４は、デバイスがどのように方向付けられているか、または、デバイスがどの状態にあるか（例えば、開状態、閉状態、縦向き状態など）を決定することができる。さらに、優先度モジュール５７２（図５Ｂ）及び／または要件モジュール５８０（図５Ｂ）は、ウィンドウをどのように表示するかを決定することができる。ジェスチャモジュール５７６（図５Ｂ）は、ジェスチャのタイプ及びジェスチャが行われた位置に基づいて、ウィンドウをどのように開くかについてのユーザの意図を決定することができる。

【0130】

ディスプレイ構成モジュール５６８（図５Ｂ）は、これらのモジュールからの入力を使用して、可視性アルゴリズムに基づいて、現時点におけるウィンドウスタック７６０を評価し、最善の場所及び最善の寸法を決定し、ウィンドウを開くことができる。したがって、工程９１６では、ディスプレイ構成モジュール５６８は、ウィンドウスタック７６０の最上部にウィンドウを置くための最善の場所を決定する。可視性アルゴリズムは、実施形態では、複合ディスプレイのすべての部分に対して、どのウィンドウがスタックの最上部にあるかを決定する。例えば、可視性アルゴリズムは、図７Ｃ〜７Ｅで見られるように、ウィンドウ３ ７６８、ウィンドウ４ ７７０及びウィンドウ８ ７７４がスタック７６０の最上部にあることを決定する。どこでウィンドウを開くかを決定すると、ディスプレイ構成モジュール５６８は、ディスプレイ識別子８１６及び場合により寸法８０８をウィンドウに割り当てることができる。次いで、ディスプレイ識別子８１６及び寸法８０８は、タスク管理モジュール５４０に送り返すことができる。次いで、タスク管理モジュール５４０は、ウィンドウスタックの最上部でのウィンドウ位置を示すスタック位置識別子８１２をウィンドウに割り当てることができる。

【0131】

実施形態では、タスク管理モジュール５４０は、ウィンドウスタック情報及び命令を送信し、ウィンドウ管理モジュール５３２（図５Ａ）にウィンドウをレンダリングする。工程９２４では、ウィンドウ管理モジュール５３２及びタスク管理モジュール５４０（図５Ａ）は、論理データ構造８００を作成することができる。タスク管理モジュール５４０とウィンドウ管理モジュール５３２は両方とも、ウィンドウスタックのコピーを作成し、管理することができる。これらのウィンドウスタックのコピーは、ウィンドウ管理モジュール５３２とタスク管理モジュール５４０との間の通信を通じて、同期化することも、同様に保持することもできる。したがって、ウィンドウ管理モジュール５３２及びタスク管理モジュール５４０は、複数ディスプレイ管理モジュール５２４によって決定された情報に基づいて、寸法８０８、スタック位置識別子８１２（例えば、ウィンドウ１ ７８２、ウィンドウ４ ７７０など）、ディスプレイ識別子８１６（例えば、タッチセンサ式ディスプレイ１ １１０、タッチセンサ式ディスプレイ２ １１４、複合ディスプレイ識別子など）及びアクティブインジケータ８２０を割り当てることができ、これは、一般に、ウィンドウがスタックの「最上部」にある場合に常に設定される。次いで、論理データ構造８００は、ウィンドウ管理モジュール５３２とタスク管理モジュール５４０の両方で格納することができる。さらに、ウィンドウ管理モジュール５３２及びタスク管理モジュール５４０は、その後、ウィンドウスタック及び論理データ構造８００を管理することができる。

【0132】

高レベルの機能を有するポータブル電子デバイスに対する需要は上昇し続け、個人電子デバイスの可搬性はますます高まっている。携帯電話及びスマートフォンの計算力、電池の寿命、画面のサイズ、及び全体機能が増大し続ける間、これらのデバイスへのユーザの依存も増大する。そのようなデバイスの多くのユーザは、一般的な通信、インターネットへのアクセス、クラウドコンピューティング、及び交信情報、ファイル、音楽、写真等の様々なローカルに記憶された情報へのアクセスに関して、そのようなデバイスに非常に依存している。したがって、そのような非常に依存しているデバイスに接続して、スマートパッド（ＳＰ）１０００（図１０参照）等の、モニタまたはタブレットデバイス等の追加の計算デバイスまたはディスプレイに接続することが望ましいことが多い。

【0133】

したがって、デバイス１００がスマートパッド１０００等の追加のデバイスとインタフェース可能であり、それにより、例えば、タブレットコンピュータシステム及びスマートフォンの両方と同様の機能が可能になることが望ましい。さらに、上述したデバイスで、電話の送受信等の両デバイスの様々な既存の特徴が可能であり、且つデバイス１００で実行中のアプリケーションにアクセス可能なことも必要とされる。上のデバイス１００が、デバイスのフォームファクタを損なわずに、共通の動作及び機能を可能にすることにより、タブレットコンピュータシステム及びセルラ電話の両方の利点を１つの統合デバイスに提供することも必要とされる。

【0134】

例示的な一実施形態は、選択的に着脱可能なデバイス及びスマートパッドシステムに関する。スマートパッドシステムは、以下にさらに詳細に考察するが、スマートフォンまたはデバイス１００等の通信デバイスを補う様々な特徴を有することができる。例えば、スマートパッドは、画面サイズの増大、プロセッササイズの増大、電池または電源等の増大を提供することにより、デバイス１００を補い得る。同様に、デバイス１００は、１つまたは複数の無線ネットワークを通しての接続性、記憶された様々な情報へのアクセス等を提供することにより、ＳＰ１０００を補い得る。したがって、本発明の２つ以上のデバイスを、接続またはドッキングし、一般に共生関係で提供し得ることがはっきりと認識されよう。デバイスが、様々な特徴、利点、及び機能を独立した状態で提供することがさらに認識されよう。

【0135】

例示的な一実施形態によれば、デバイス１００は、デバイス１００に対応する寸法を有するＳＰ１０００の窪み特徴を通して、ＳＰ１０００で受けることができる。例示的な一実施形態では、ＳＰ１０００が提供され、好ましくは、所定のデバイス１００を受けるようなサイズである。しかし、代替の実施形態では、ＳＰ１０００が提供され、スマートパッドが異なるサイズの複数の通信デバイスを受けることが可能なことが意図される。そのような実施形態では、ＳＰ１０００は、例えば、スペーサ及び様々な調整可能特徴等の追加の要素を含むことにより、様々なサイズの通信デバイスを受け得る。

【0136】

例示的な一実施形態によれば、デバイス１００及びＳＰ１０００は、様々な動作モード中、デバイス１００がＳＰ１０００に接続された場合に確立されるドッキング関係を有する。例えば、一実施形態では、ＳＰ１０００及びデバイス１００を備えるシステムが提供され、ＳＰ１０００はデバイス１００を物理的に受けることが可能であり、デバイス１００は、主計算デバイスとして動作可能である。そのような実施形態では、ＳＰ１０００は、例えば、単純に、それ自体のＣＰＵ、メモリ等を備えるデバイス１００にオーディオ特徴及びビジュアル特徴の強化を提供し得る。システムを、ＳＰ１０００にドッキングされたデバイス１００が、例えば、デバイス１００がデバイス１００の電池充電等のためにＳＰ１０００から電力を消費するより受動的なモードで提供する動作モードにし得ることがさらに意図される。

【0137】

別の例示的な実施形態によれば、デバイス１００及びＳＰ１０００が提供され、デバイス１００はＳＰ１０００に受けられるか、またはドッキングされ、デバイス１００の大半のエリアはＳＰ１０００の１つまたは複数の区画内に位置決めされる。例えば、様々な既知のデバイスが、ドッキングされる物品を概して露出する必要があるか、または結果として露出することになり、それにより、ホストデバイスの外形寸法を実質的に変更し、及び／または一方若しくは両方のデバイスが衝突で破損する潜在性を生み出すドッキング特徴を備えるのに対して、例示的な実施形態は、デバイスが接続される際、ＳＰ１０００の外形寸法が実質的に変更されないようにデバイス１００を受けるＳＰ１０００が意図される。そのような構成では、デバイス１００及び関連付けられた接続手段は一般に保護され、ＳＰ１０００は元の形状を実質的に維持することができる。例示的な一実施形態によれば、ＳＰ１０００はデバイス１００を受け、及び／またはドッキングすることが可能であり、デバイス１００はＳＰ１０００とロック可能な関連付けで受けられる。本明細書で使用される場合、「ロック可能」という用語はいかなる特定の構成を示すことも意図せず、またいかなる特定の構成への限定も意図しない。むしろ、ロック可能とは、本明細書に記載され、当業者に認識されるような様々な実施形態を指すことが意図される。一実施形態では、デバイス１００はＳＰ１０００に接続可能であり、ＳＰ１０００は、まずデバイス１００をドッキングして電気的に固定する引っ張りばねと、ＳＰ１０００からデバイス１００を解放する取り出し特徴とを備える。さらに、より詳細に後述するように、デバイス１００及びＳＰ１０００が有線及び／または無線技術を使用して等しい成功率で通信可能なことを理解されたい。さらに、別の例示的な実施形態によれば、ヒンジ付きデバイス１００をＳＰ１０００に選択的に接続可能であり、デバイス１００は開位置においてＳＰ１０００で受けられ、ＳＰ１０００の１つまたは複数の既存のポートは、ＳＰ１０００の内部収容特徴に対応し、それにより、デバイス１００及びＳＰ１０００は様々な使用モードで同時に動作し得る。

【0138】

いくつかの例示的な実施形態によれば、ＳＰ１０００には、取り出しボタンまたはリリースボタンが提供されて、格納またはドッキングされたデバイス１００の取り出しを容易にする。

【0139】

図１０は、例示的な実施形態による例示的なスマートパッド（ＳＰ）１０００を示す。例示的なスマートパッドは少なくとも、デバイス１００に動作可能に結合可能なより大きなタッチセンサ式ディスプレイを提供する。

【0140】

以下の説明では、表示デバイス１０００と併せて「スマート」という用語が使用されるが、この用語が必ずしも、スマートパッドにインテリジェンスがあることを含意するわけではないことを理解されたい。むしろ、スマートパッド内のプロセッサ、メモリ、記憶デバイス、ディスプレイドライバ等の１つ若しくは複数及び／または例えば、ポート、バス、接続等のうちの１つ若しくは複数を介してデバイス１００と共有されるこれらの要素のうちの１つ若しくは複数を含め、「インテリジェンス」が存在し得ることを理解されたい。一般に、デバイス１００の機能のうちの１つまたは複数は、スマートパッド７００に拡張可能であり、逆の場合も同じである。

【0141】

例示的なスマートパッド７００は、画面１００４と、ＳＰタッチセンサ式ディスプレイ１０１０と、ＳＰ構成可能エリア１００８と、ＳＰジェスチャ捕捉領域１０１２と、ＳＰカメラ１０１６とを含む。ＳＰ１０００は、少なくとも図１１に示されるようなデバイス１００を受けるように構成されたポート（この向きでは見えない）も含む。

【0142】

デバイス１００は、ＳＰ１０００のポート及びデバイス１００の対応するポート１３６を介してスマートパッド１０００にドッキングする。考察したように、いくつかの実施形態では、ポート１３６は入／出力ポート（Ｉ／Ｏポート）であり、Ｉ／Ｏポートにより、デバイス１００をディスプレイ、キーボード、印刷デバイス、及び／またはＳＰ１０００等の他の周辺デバイスに接続することができる。例示的な一実施形態によれば、ドッキングは、開状態のデバイス１００がＳＰ１０００の左側にスライドし、デバイス１００がポート１３６に対応するＳＰ１０００のポートに係合することにより達成される。例示的な一実施形態によれば、デバイス１００は、デバイス１００がスライドするＳＰ１０００のドア付きカセットのようなスロットに係合する。（例えば、図１３参照）。しかし、２つのデバイスを物理的且つ電気的に係合させる他の構成があり得、一般に、デバイス１００及びＳＰ１０００が互いに電気的通信状態にある限り、係合の様式は重要ではないことを理解されたい。

【0143】

ＳＰ１０００は画面１００４を含む。いくつかの実施形態では、ＳＰ１０００の前面全体は、タッチセンサ式であり得、ユーザが画面１０４の前面に触れることにより入力を受信することが可能である。画面１００４はタッチセンサ式ディスプレイ１０１０を含み、このディスプレイ１０１０は、タッチセンサ式であることに加えて、ユーザに対して情報を表示することも可能である。

【0144】

画面１００４は構成可能エリア１００８も含み、構成可能エリア１００８は、ユーザが構成可能エリア１００８の部分に触れた場合、特定の入力に向けて構成されている。エリア１０１２ａは、ユーザが前に表示されていた情報を閲覧したいことを示す「戻る」入力を受信するように構成される。エリア１０１２ｂは、ユーザがメニューからの選択肢を閲覧したいことを示す「メニュー」入力を受信するように構成される。エリア１０１２ｃは、ユーザが「ホーム」ビューに関連付けられた情報を閲覧したいことを示す「ホーム」入力を受信するように構成される。

【0145】

他の実施形態では、エリア１０１２ａ〜ｃは、上述した構成に加えて、デバイス１００及び／またはデバイス１０００の制御特徴を含む他のタイプの特定の入力に向けて構成し得、いくつかの非限定的な例としては、全体システム電力の調整、音量の調整、輝度の調整、バイブレーションの調整、画面１００４に表示されるアイテムの選択、ＳＰカメラ１０１６の操作、マイクロホンの操作、及び電話呼の開始／終了が挙げられる。いくつかの実施形態では、エリア１０１２ａ〜ｃは、デバイス１００／ＳＰ１０００で実行中のアプリケーション及び／またはタッチセンサ式ディスプレイ１０１０に表示されている情報に応じて、特定の入力に向けて構成することもできる。

【0146】

タッチセンスに加えて、画面１００４は、ユーザが画面の表示エリアに触れる必要なく、ユーザから入力を受信するエリアも含み得る。例えば、画面１００４はジェスチャ捕捉エリア１０１２を含むことができる。これらのエリアは、ユーザが実際に表示エリアの表面に触れる必要なく、ユーザがとったジェスチャを認識することにより入力を受信することが可能である。タッチセンサ式ディスプレイ１０１０及び１０１４と比較して、ジェスチャ捕捉エリア１０１２は、表示された画像をレンダリングできないことがある。

【0147】

示されていないが、いくつかのハードウェア構成要素がＳＰ１０００内に存在してもよい。図１０に示されるように、ＳＰ１０００はスピーカ、マイクロホン、及び１つまたは複数のカメラ１０１６を含むことができる。デバイス１００をＳＰ１０００にドッキングすると、デバイス１００の対応するデバイス（例えば、スピーカ）は、ＳＰ１０００のスピーカを優先してディセーブルすることができる。同様に、画面１００４、マイクロホン、スピーカ等の他の構成要素も、ＳＰ１０００を優先してデバイス１００でディセーブルすることができる。

【0148】

一般に、タッチセンサ式ディスプレイ１０１０は、フルカラータッチセンサ式ディスプレイを含み得る。各タッチセンサ式画面１００４内の第２のエリアは、ＳＰジェスチャ捕捉領域１０１２を含み得る。ＳＰジェスチャ捕捉領域１０１２は、ＳＰタッチセンサ式ディスプレイ１０１０の外部にあり、例えば、ユーザが提供するジェスチャの形態で入力を受信可能なエリアまたは領域を含み得る。しかし、ＳＰジェスチャ捕捉領域１０１２は、必ずしも、表示機能または表示能力を実行可能なピクセルを含む必要があるわけではない。

【0149】

ＳＰタッチセンサ式画面１００４の第３の領域は、構成可能エリア１０１２を含み得る。構成可能エリア１０１２は、入力を受信することが可能であり、ディスプレイまたは限られた表示能力を有する。実施形態では、構成可能エリア１０１２は、異なる入力選択肢をユーザに提示し得る。例えば、構成可能エリア１０１２は、ボタンまたは他の関連可能なアイテムを表示し得る。さらに、表示されたボタンの識別情報または任意のボタンがＳＰタッチセンサ式画面１００４の構成可能エリア１０１２内ですべて表示されるか否かは、デバイス１０００が使用され、及び／または動作する状況から決まり得る。例示的な実施形態では、タッチセンサ式画面１００４は、少なくとも、ユーザに視覚的出力を提供可能なタッチセンサ式画面１００４の領域にわたって延びる液晶ディスプレイデバイスと、ユーザから入力を受信可能なタッチセンサ式画面１００４の領域上の容量性入力マトリックスとを含む。

【0150】

図４Ａ〜図４Ｈを参照して上述したように、画面１０４、１０８が認識し得るジェスチャ入力の様々なグラフィカル表現は、画面１００４によっても認識可能である。考察したように、ジェスチャは、指等のユーザの人体部分のみならず、画面１００４の接触感知部分で感知し得る、スタイラス等の他のデバイスによっても実行し得る。一般に、ジェスチャは、ジェスチャがどこで実行されたか（ディスプレイ１００４において直接か、またはジェスチャ捕捉領域１０２０においてか）に基づいて別様に解釈される。例えば、ディスプレイ１０１０でのジェスチャはデスクトップまたはアプリケーションを対象とし得、ジェスチャ捕捉領域１０２０でのジェスチャはシステム用として解釈し得る。

【0151】

上に加えて、ＳＰタッチセンサ式画面１００４は、画面のどの部分がフォーカスされているかを識別する際にユーザを支援するエリアも有し得る。これは、ライトバーまたは一般には、ＳＰタッチセンサ式画面１００４のどの１つまたは複数の部分がフォーカスされているかを識別するインジケータであることができる（例えば、図２９参照）。

【0152】

１つまたは複数のディスプレイコントローラ（ディスプレイコントローラ２１６ａ、２１６ｂ、及び／またはＳＰ１０００の専用ディスプレイコントローラ等）を提供して、入力機能（タッチセンス）及び出力機能（表示）を含むタッチセンサ式画面１００４の動作を制御し得る。

【0153】

例示的な一実施形態によれば、タッチスクリーン１０４及び１０８の各コントローラに加えて、別個のタッチスクリーンコントローラがＳＰ１０００に提供される。代替の実施形態によれば、共通または共有のタッチスクリーンコントローラを使用して、タッチセンサ式画面１０４及び１０８及び／または１００４のうちの任意の１つまたは複数を制御し得る。さらなる他の実施形態によれば、タッチスクリーンコントローラの機能は、プロセッサ及びメモリまたは専用グラフィックスチップ等の他の構成要素に組み込み得る。

【0154】

同様にして、ＳＰ１０００は、プロセッサ２０４を補うプロセッサを含み得、これらのいずれも、アプリケーションプログラミングまたは命令を実行する汎用プログラマブルプロセッサまたはコントローラを備え得る。少なくともいくつかの実施形態によれば、プロセッサは、複数のプロセッサコアを含み、且つ／または複数の仮想プロセッサを実施し得る。さらなる他の実施形態によれば、プロセッサは複数の物理的なプロセッサを含み得る。特定の例として、プロセッサは、特に構成された特定用途向け集積回路（ＡＳＩＣ）または他の集積回路、デジタル信号プロセッサ、コントローラ、ハードワイヤード電子または論理回路、プログラマブル論理素子またはゲートアレイ、専用コンピュータ等を含み得る。プロセッサは一般に、デバイス１００及び／またはＳＰ１０００の様々な機能を実施するプログラミングコードまたは命令を実行するように機能する。

【0155】

ＳＰ１０００は、任意選択的に、音声入／出力インタフェース／デバイス（図示せず）を備えて、アナログ音声を相互接続されたスピーカまたは他のデバイスに提供するとともに、アナログ音声入力を接続されたマイクロホンまたは他のデバイスから受信することもできる。例として、音声入／出力インタフェース／デバイス２５６は、ＳＰ１０００と共に使用可能な関連付けられた増幅器及びアナログ／デジタル変換器を備え得る。代替または追加として、デバイス１００は、ＳＰ１０００を介して外部スピーカまたはマイクロホンを相互接続する統合音声入／出力デバイス２５６及び／または音声ジャックを含むことができる。例えば、統合スピーカ及び統合マイクロホンを提供して、近接通話（ｎｅａｒ ｔａｌｋ）動作またはスピーカフォン動作をサポートすることができる。

【0156】

ハードウェアボタン（図示していないが、ハードウェアボタン１５８と同様である）が、例えば、特定の制御動作に関連して使用するために含むことができる。例として、図１Ａ〜図１Ｊに関連して説明したように、マスタ電力スイッチ、音量制御等が挙げられる。カメラ等の１つまたは複数の画像捕捉インタフェース／デバイス１０１６を含めて、静止画像及び／またはビデオ画像を捕捉することができる。代替または追加として、画像捕捉インタフェース／デバイス１０１６はスキャナまたはコードリーダを含むことができる。画像捕捉インタフェース／デバイス１０１６は、フラッシュまたは他の光源等の追加の要素を含むか、または追加の要素に関連付けることができる。

【0157】

デバイス１００及びＳＰ１０００の様々な構成要素間の通信は、１つまたは複数のバス及び／または通信チャネルにより実行することができる。加えて、電力を電源及び／または電力制御モジュール２６０からデバイス１００及びＳＰ１０００の構成要素のうちの１つまたは複数に供給することができる。電力制御モジュール２６０、及び／またはデバイス１００、及び／またはＳＰ１０００は、例えば、電池、ＡＣ／ＤＣ変換器、電力制御論理、及び／またはデバイス１００／１０００を外部電源に相互接続するポートを含むことができる。

【0158】

ミドルウェア５２０は、デバイスで実行中の複数のプロセスが対話できるようにする任意のソフトウェアまたはデータであってもよい。実施形態では、ミドルウェア５２０の少なくとも部分及び本明細書に記載される離散した構成要素は、ＯＳ５１６またはアプリケーション５６４の部分であると見なし得る。しかし、これらの部分についてはミドルウェア５２０の部分として説明するが、これらの構成要素はそのように限定されない。ミドルウェア５２０は、複数ディスプレイ管理（ＭＤＭ）クラス５２４、サーフェスキャッシュクラス５２８、ウィンドウ管理クラス５３２、アクティビティ管理クラス５３６、アプリケーション管理クラス５４０、表示制御ブロック、１つまたは複数のフレームバッファ５４８、アクティビティスタック５５２、及び／またはイベントバッファ５５６を含むことができるが、これらに限定されない−これらのすべての機能はＳＰ１０００に拡張可能である。クラスは、関連する機能を有するか、またはソフトウェア階層内で関連付けられた２つ以上のモジュールの任意のグループであることができる。

【0159】

ＭＤＭクラス５２４は、ＳＰ１０００の画面へのアプリケーションまたは他のデータの表示を管理するように動作可能な１つまたは複数のモジュールも含む。ＭＤＭクラス５２４の実施形態について、図５Ｂに関連して説明する。実施形態では、ＭＤＭクラス５２４は、ＯＳ５１６、ドライバ５１２、及びアプリケーション５６４から入力を受信する。入力は、ユーザが要求する情報をどのように表示するかを判断するに当たってＭＤＭクラス５２４を支援する。表示構成に関する判断が下されると、ＭＤＭクラス５２４はアプリケーション５６４を表示構成にバインドすることができる。次に、構成を１つまたは複数の他の構成要素に提供して、ＳＰ１０００上に表示を生成し得る。

【0160】

図１１は、ＳＰ１０００とドッキングするデバイス１００を示す例示的な実施形態を示す。より具体的には、デバイス１００は、ＳＰ１０００のスロット（図示せず）に挿入されている。ＳＰ１０００へのデバイス１００の挿入が完了すると（図１２参照）、デバイス１００は、バスまたは他の有線若しくは無線電気手段１２０４を介してＳＰ１０００と通信する。デバイス１００は、例えば、カメラ／ビデオカメラ１０１６、マイクロホン（Ｍｉｃ）、及び電力ポート１２０８にも接続される。

【0161】

ＳＰ１０００へのデバイス１００のドッキングと併せて、デバイスのうちの一方または両方は電力管理を開始することができる。例えば、デバイス１００及びＳＰ１０００のうちの一方または両方は、電池、太陽電源、または任意の電源全般等の電源を含むことができ、これらのうちの任意の１つまたは複数は、デバイス１００及びＳＰ１０００のうちの一方または両方への供給に使用可能である。さらに、例えば、ポート１２０８に接続されたＡＣ電力アダプタの使用を通して、ＳＰ１０００は、デバイス１００の充電等のためにデバイス１００に給電することができる。本明細書において説明する電力管理機能をデバイス１００及びＳＰ１０００のうちの一方または両方に分散させて、電力が２つのデバイスで共有可能なことが理解されよう。

【0162】

電力管理機能に加えて、デバイス１００がＳＰ１０００にドッキングされると、デバイス１００のディスプレイをオフにして、例えば、節電することができる。さらに、ＳＰ１０００が受けたスピーカ、マイクロホン、ディスプレイ、入力捕捉領域、入力等をデバイス１００に転送可能なように、電気接続がデバイス１００とＳＰ１０００との間で確立される。さらに、デバイス１０００のディスプレイは、タッチセンサ式ディスプレイ１１０及び１１４のうちの１つまたは複数に表示されていた情報がタッチセンサ式ディスプレイ１０１０に表示されるようにイネーブルされる。本明細書においてさらに詳細に考察するように、ＳＰ１０００は、デバイス１００のデュアルディスプレイ構成を単一ディスプレイ１０１０でエミュレートすることができる。

【0163】

ＳＰ１０００は任意選択的に、ヘッドホンジャック１２１２及び電力ボタン１２１６を備えることができる。さらに、デバイス１００の任意のハードウェアボタンまたはユーザ入力ボタンをＳＰ１０００に拡張し、複製することができる。

【0164】

デバイス１００とＳＰ１０００とのこのドッキングイベントは、図３Ａの状態３３６または３４４として見ることができる。明らかなように、本明細書における例示的な実施形態の１つによれば、デバイス１００は、開状態２１０でＳＰ１０００とドッキングする。しかし、デバイス１００が、閉状態３０４でＳＰ１０００にドッキングしてもよく、または例えば、デバイス１００を必ずしもＳＰ１０００に挿入する必要なくケーブルを介してドッキングしてもよいことを理解されたい。

【0165】

図１３Ａ及び図１３Ｂは、本発明の例示的な実施形態によるアプリケーション向き変更を示す。特に、図１３Ａは、ＳＰ１０００に挿入中のデバイス１００を示す。ＳＰ１０００に関連付けられる前、デバイス１００は、第１の画面で横向きのアプリケーション「Ｂ」及び第２の画面（部分的にＳＰ１０００により遮られる）で横向きのアプリケーション「Ｃ」で表される、両方とも横向きモードの２つのアプリケーションを有する。

【0166】

図１３Ｂは、横向きのＳＰ１０００に関連付けられているデバイス１００に基づく２つのアプリケーションのウィンドウの向き変更を示す。この例示的な実施形態によれば、デバイス１００のアプリケーション「Ｂ」は、ＳＰ１０００で縦向きに向き変更され、同様に、デバイス１００のアプリケーション「Ｃ」も、タッチセンサ式ディスプレイ１０１０の右側で縦向きに向き変更される。理解されるように、デバイス１００からＳＰ１０００へのアプリケーションの向き変更は、デバイス１００で実行中の単一のアプリケーションに対しても同様に行うことができる。例えば、デバイス１００で実行中のアプリケーションが１つのみであり、アプリケーションが横向きモードで実行中である場合、デバイス１００がＳＰ１０００にドッキングされるとき、アプリケーションの向きは、ＳＰ１０００の現在の向きに適切なように変更される。例えば、デバイス１００のアプリケーションが縦向きモードであり、ＳＰ１０００が横向きモードである場合、アプリケーションは、デバイス１００での縦向きモードからＳＰ１０００での横向きモードに向き変更される。同様にして、デバイスのアプリケーションが横向きモードである場合、縦向きモードのＳＰ１０００にドッキングされると、アプリケーションは、ＳＰ１０００で適切に表示されるように縦向きモードに向き変更される。

【0167】

例示的な一実施形態によれば、デバイス１００の加速度計１７６を使用して、デバイス１００及びＳＰ１０００の両方の向き、ひいてはタッチセンサ式ディスプレイ１０１０の向きを特定する。したがって、加速度計１７６は信号を出力し、その信号を、情報の表示に関連して使用して、情報がディスプレイ１０１０上でユーザに表示されるべき向き及び／または形式を制御する。理解されるように、向き変更は、アプリケーションに関連付けられたウィンドウの縦向きから横向きへの変換、横向きから縦向きへの変換、サイズ変更、比率変更、及び／または再描画のうちの１つまたは複数を含むことができる。

【0168】

実行中のアプリケーションを向き変更する際、アプリケーションはＳＰ１０００のディスプレイ１０１０に表示される。
任意選択的で例示的な実施形態によれば、フォーカスされているアプリケーションを優先することができる。例えば、ここでも図１３Ｂに示されるアプリケーション「Ｂ」及び「Ｃ」を使用すると、仮にアプリケーションＣがドッキング前にフォーカスされていた場合、アプリケーションＣを向き変更し、ディスプレイ１０１０の左側部分に表示することができ、ドッキング前にフォーカスされていなかったアプリケーションＢは、ドッキングされるとディスプレイ１０１０の右側部分に表示することができる。

【0169】

別の任意選択的な実施形態によれば、フォーカスされているアプリケーションは、ディスプレイ１０１０に全画面モードで表示することができ、フォーカスされていないアプリケーションは、例えば、後述するカルーセル式構成であるウィンドウスタックに配置される。

【0170】

図１４は、ＳＰ１０００の単一アプリケーションモードの例示的な実施形態を示す。単一アプリケーションモードでは、すべてのアプリケーションが全画面で起動し、表示される。単一アプリケーションモードは、宣言バー（ｅｎｕｎｃｉａｔｏｒ ｂａｒ）または画面１００４上の他のある位置における複数タスクアイコンにより示すことができる。

【0171】

アプリケーションの表示は、ディスプレイコントローラ５４４、フレームワーク５２０、ウィンドウ管理モジュール５３２、表示構成モジュール５６８、並びにミドルウェア５２０及び関連付けられたクラスのうちの１つまたは複数により管理される。単一アプリケーションモードでは、すべてのデュアル画面対応アプリケーションを、デュアル画面または最大モードで起動することができ、最大モードでは、アプリケーションがディスプレイ１０１０を実質的に埋めて表示される。これは、ＳＰ１０００が図１４に示されるように縦向きモードであるか、または図１５に示されるように横向きモードである場合に適用可能である。これらの図では、「Ａ」は単一のアプリケーションを表し、Ｘ１、Ｘ２は、アプリケーション「Ａ」を変位すべきウィンドウの座標及び／または位置を表す変数である。以下において、同様の表記が複数アプリケーションモードに関しても使用され、例えば、Ｘ１が第１のアプリケーションのウィンドウの表示の座標情報を含み得、Ｘ２が第２のアプリケーションに対応するウィンドウの表示の座標情報を含み得る等々であることが理解される。

【0172】

したがって、例示的な一実施形態では、単一のアプリケーションが実行される場合、単一のアプリケーションを全画面モードで起動し、図６Ｉに関連して考察される最大モードに相関付けることができ、最大モードでは、単一のアプリケーションがデバイス１００の両画面に広がる。この最大モードは、図１４及び図１５に示される縦向き及び横向きの両方に適用可能であり、表示構成モジュール５６８は、ディスプレイ１０１０の略すべてまたはすべてに収まるようにアプリケーションのウィンドウを適宜サイズ変更する。

【0173】

このサイズ変更は、デバイス１００のネイティブアプリケーションが実際にＳＰ１０００の向きをサポートするか否かに関係なく行うことができる。したがって、アプリケーションがデバイス１００での特定の向きをサポートしない場合であっても、表示構成モジュール５６８は、ＳＰ１０００で適切に表示されるようにアプリケーションのウィンドウを適宜再レンダリングし、及び／またはサイズ変更することができる。

【0174】

図１６及び図１７は、それぞれが縦向き最大モード及び横向き最大モードでのデュアル画面アプリケーションである単一のアプリケーションをレンダリングする例示的な方法を示す。より具体的には、図１６では、縦向きモードでのデュアル画面アプリケーションのレンダリングは、ディスプレイ１０１０を略または完全に埋める２つの画面のうちの１つをディスプレイ１０１０に表示する。次に、ユーザは、例えば、ジェスチャを使用して、単一のアプリケーションの２つの画面間をスクロールすることができる。図１７に示されるように、横向きモードでは、画面１０１０は第１の部分１７０４及び第２の部分１７０８に分割される。この例示的な実施形態では、デュアル画面アプリケーションの第１の画面は第１の部分１７０４にレンダリングされ、デュアル画面アプリケーションの第２の画面は第２の部分１７０８にレンダリングされる。画面１０１０の特定の部分が説明のために、第１の部分１７０４及び第２の部分１７０８に論理的に分割されるが、各部分に割り当てられる画面の面積が、例えば、ウィンドウの最適表示、各部分に表示されている情報の種類、ユーザの好み、及び／またはアプリケーションに関連付けられたルール等のうちの１つまたは複数に基づいて変更可能なことを理解されたい。

【0175】

第１の例によれば、第１の部分には画面１０１０の解像度の１／３が割り当てられ、その一方で、第２の部分１７０８には画面面積の２／３が割り当てられる。別の例によれば、画面１０１０は５０／５０に分割される。さらに別の例によれば、第１の部分には画面１０１０の面積の７０％を割り当てることができ、その一方で、第２の部分１７０８には３０％を割り当てることができる。これらのウィンドウの管理及びサイズ変更はここでも、表示構成モジュール５６８並びにＳＰ１０００でのウィンドウの位置のレンダリングを成功させるウィンドウ管理モジュール５３２及びディスプレイコントローラと協働して行うことができる。

【0176】

理解されるように、デバイス１０００の動作と同様にして、ＳＰ１０００が向きを変更した場合（例えば、横向きから縦向き、またはこの逆に）、アプリケーションのウィンドウは、特定のアプリケーション及び現在のフォーカスがデュアル画面アプリケーションであるか、それとも単一画面アプリケーションであるかに基づいて、ウィンドウ優先度を考慮に入れて適切な向きで再描画することができる。

【0177】

ＳＰ１０００が縦向き位置である場合にアプリケーションのどのウィンドウを表示すべきかを決定する際に、フォーカスを考慮に入れることもできる。例えば、アプリケーションが電子メールクライアントであり、アプリケーションが元々はデバイス１０００においてデュアル画面で表示されていた場合（第１の画面が受信ボックスコンテンツを示すことを対象とし、第２の画面が、受信ボックス内の特定のアイテムのプレビューウィンドウである）、システムは、どのウィンドウが現在フォーカスされているかを評価し、ＳＰ１０００が縦向きである場合、ウィンドウが縦向き最大モードで表示されることを保証することができる。

【0178】

図１７では、ＳＰ１０００は、デュアル画面アプリケーションからのウィンドウを単一のディスプレイ１０１０に統合するように構成される。この横向きでは、第１のウィンドウからのデータ（例えば、単一の画像、アプリケーション、ウィンドウ、アイコン、ビデオ等）はディスプレイ１０１０の第１の部分に表示され、その一方で、データ（例えば、単一の画像、アプリケーション、ウィンドウ、アイコン、ビデオ等）はディスプレイ１０１０の第２の部分に示される。他の出力構成と同様に、例えば、ＳＰ１０００をどの状態に移すかに応じて、ＳＰ１０００を示される出力構成から本明細書に記載される他の任意の出力構成に推移することが可能であり得る。

【0179】

デバイス１００がＳＰ１０００にドッキングした後のＳＰ１０００内のウィンドウ管理のいくつかの他の例示的な実施形態は以下である：例えば、デバイス１００が縦向きのＳＰ１０００にドッキングし、ＳＰ１０００が縦向きの状態で、デバイス１０００で２つの単一画面アプリケーションが実行中であり、フォーカスされているアプリケーションはディスプレイ１０１０の下部に配置され、フォーカスされていないアプリケーションはディスプレイ１０１０の上部に配置される。デバイス１００が縦向きＳＰ１０００にドッキングされ、１つのデュアル画面アプリケーションがデバイス１００で実行中であり、ＳＰ１０００がデュアルアプリケーションモードである別の例示的なシナリオは、本明細書において考察される重力降下（ｇｒａｖｉｔｙ ｄｒｏｐ）を適用する。

【0180】

デバイス１００が２つの単一画面アプリケーションを実行中であり、ＳＰ１０００が横向きデュアルアプリケーションモードである別の例示的なシナリオでは、第１のアプリケーションはディスプレイ１０１０の第１の部分に割り当てられ、第２のアプリケーションはディスプレイ１０１０の第２の部分に割り当てられる。

【0181】

デバイス１００が１つのデュアル画面アプリケーションを実行中であり、ＳＰ１０００がデュアルアプリケーション横向きモードであるさらに別の例示的なシナリオでは、デュアル画面アプリケーションの両画面をＳＰ１０００に示すことができる。

【0182】

例えば、第１のアプリケーションがフォーカスされている場合、単一アプリケーションモードＳＰ１０００にドッキングされると、アプリケーションはドッキング後も可視のままであるように、スティッキネスをＳＰ１０００に適用することもできる。スティッキネスの別の例として、第２のアプリケーションがフォーカスされている場合、単一アプリケーションモードＳＰ１０００にドッキングされると、アプリケーション２はドッキング後も可視のままである。

【0183】

別の例によれば、デバイス１００は１つのデュアル画面アプリケーションを実行中であり、最大モードで横向きＳＰ１０００にドッキングしており、ウィンドウは、上下にではなく、左右に並ぶように向き変更される。

【0184】

図１８〜図２１は一般に、ディスプレイ１０１０での仮想キーボード１８０４の管理及び表示を示す。より具体的には、図１８では、縦向きモードにおいて、仮想キーボード１８０４はアプリケーションエリア１８０８の下に位置決めされ、アプリケーションは、例えば、最大モードで表示される。一般に、ＳＰが横向きモードであるか、それとも縦向きモードであるかに関係なく、キーボードをディスプレイ１０１０の下部に付けられることが好ましい。しかし、例えば、ユーザの好みに基づいて、画面を画面の別の部分に付けられることもでき、または例えば、ジェスチャを介して別の位置に移動可能なことを理解されたい。図１８では、アプリケーションエリア１８０８は、例えば、標準アプリケーションを表示し、仮想キーボード１８０４はディスプレイ１０１０の下部に表示される。図１９では、例えば、アプリケーションエリア１９０８はデュアル画面対応アプリケーションを最大モードで示している。キーボード１８０４はここでも同様に、ディスプレイ１０１０の下部に表示される。

【0185】

図２０では、ＳＰ横向きモードにおいて、キーボード１８０４はディスプレイ１０１０の下部に表示され、アプリケーションエリア２００４はキーボード１８０４の上の表示可能エリアを略または完全に埋めている。図２１では、ＳＰはここでも横向きモードであり、デュアル画面対応アプリケーションを最大モードで表示し、アプリケーションエリア１ ２１０４及びアプリケーションエリア２ ２１０８を表示し、キーボード１８０４は２つのアプリケーションエリアの下に表示される。

【0186】

一般に、図１８〜図２１に示される実施形態では、キーボードを表示すべきか否かの最初の判断が下される。キーボードを表示すべき場合、ＳＰの向きについて次の判断がなされる。ＳＰが縦向きモードである場合、仮想キーボードも、好ましくは画面の下部に縦向きモードで提示される。ＳＰが横向きモードの場合、キーボードは任意選択的に、例えば、１つまたは複数のアプリケーションウィンドウが仮想キーボードの上に配置された状態で、実質的にディスプレイの下部に表示されるようにサイズ変更される。ＳＰの向き変更に伴い、キーボードもＳＰの向きに一致するように向き変更される。同様に、キーボードがもはや必要ない場合、キーボードは、再びディスプレイ１０１０を略埋めるように拡大されたアプリケーションエリアで隠される。

【0187】

図２２及び図２３は、ＳＰ１０００でのウィンドウ位置を管理する例示的な方法を示す。特に、図２２では、アプリケーションＸ２２０４はディスプレイ１０１０上で視野内にある。ジェスチャ捕捉領域１０２０において２２０８で表されるスワイプ運動等のユーザ入力を受信すると、アプリケーションＸは左に「スクロール」し、図２３に示されるように、デュアル画面アプリケーションＡ１｜Ａ２を置換する。同じジェスチャ２２０８を繰り返す場合、アプリケーションＺが表示される。同じように、図２２のジェスチャ２２０８が逆方向の右であった場合、アプリケーションＹがディスプレイ１０１０に表示される。利用可能なウィンドウを通してのスクロールは、当然、ＳＰの横向きモード及び縦向きモードの両方で同様に適用可能である。例えば、縦向きモードでは、左から右または右から左に移動するジェスチャの代わりに、ジェスチャは下方移動または上方移動であることができ、ウィンドウの仮想スタックは、ローロデックス（ｒｏｌｏｄｅｘ）と同様にデバイスの「上」または「下」に配置される。したがって、ユーザが下方型ジェスチャを開始した場合、次に「上」のアプリケーションがディスプレイ１０１０に表示される。

【0188】

図２４は、ＳＰ１０００の複数アプリケーションモードを示し、複数アプリケーションモードでは、ＳＰ１０００はデバイス１００をミニタブレット形式でエミュレートする−このモードは任意選択的に、複数アプリケーションボタン（以下に示され、説明される）の選択により呼び出される。このモードを理解する簡単な方法は、モードが開かれているデバイス１００をエミュレートすることを理解することである。この複数アプリケーションモードでは、ＳＰ１０００は、デバイス１００での情報の表示に関するルールを継承することができる−例えば、すべてのアプリケーションが単一画面モードで起動されるというルール。１つの例外は、機会が提供される場合、最大モードをサポートするアプリケーションをデフォルトで自動的にこのモードに拡大することができることであり得る。

【0189】

このモードでは、各アプリケーションは、アプリケーションが各向き（例えば、縦向き及び横向き）でどのように現れるかを決定する能力を有する。
図２６は、ＳＰ１０００の複数アプリケーションモードを管理する例示的な方法を示す。複数アプリケーションモードでは、複数のアプリケーションをディスプレイ１０１０内で管理し表示することができる。複数アプリケーションモードでは、単一の画面を有するＳＰ１０００は、デバイス１００のデュアル画面をエミュレートする。複数アプリケーションモードを開始するために、ボタン／トグル２６１８が選択され、それにより、ユーザは、ディスプレイ１０１０に表示する複数のアプリケーションを選択することができる。この例示的な実施形態では、第１のアプリケーション２６０４Ｃは、縦向きモードＳＰ１０００の上部に示され、第２のアプリケーション２６０８Ｄは画面１０１０の下部に示される。複数アプリケーションモードで複数のアプリケーションを表示することと併せて、フォーカスインジケータ２６１６を提供して、どのアプリケーションがフォーカスされているかを識別するに当たってユーザを補助することができる。考察したように、このフォーカスインジケータはライトバーまたはどのアプリケーションがフォーカスされているかに向けてユーザの注意を引く他のインジケータ（画面１０１０内または傍のインジケータ２６０８等）であることができる。図２６の例示的な実施形態では、アプリケーションＤ２６０８が、フォーカスバー２６１６で表されるようにフォーカスされている。この例示的な実施形態によれば、フォーカスバー２６１６はジェスチャ捕捉領域１０２０に示されるが、フォーカスインジケータはＳＰ１０００の他のある部分に配置することも可能なことを理解されたい。例えば、フォーカスされているアプリケーションのウィンドウは、ウィンドウに隣接してピクセルバーを表示できるようにわずかにサイズ変更することができ、ピクセルバーは同様に、そのアプリケーションがフォーカスされていることをユーザに対して注意喚起する。同様に、フォーカスされているアプリケーションは、通常の輝度で表示することができ、その一方で、フォーカスされていないアプリケーションはわずかに暗くすることができる。一般に、どのアプリケーションがフォーカスされているかを容易に判断するに当たってユーザを補助するために、任意の教示を使用することができる。

【0190】

フォーカスを変更するために、ユーザは本明細書において考察された任意のジェスチャを使用することができ、または例えば、アプリケーションＣが表示されているエリアに単に触れ、それにより、フォーカスをアプリケーションＣに変更することができ、その時点で、アプリケーションＣの隣へのフォーカスインジケータ２６１６の対応する配置替えが行われる。

【0191】

図２７は、横向きモードＳＰ１０００での同様のシナリオを示す。特に、複数アプリケーションモードが選択されると、ディスプレイ１０１０は、この例では、第１のアプリケーションＤ２７１２及び第２のアプリケーションＦ２７０８に分割される。ここでは、アプリケーションＤはディスプレイ１０１０の右側部分に表示され、アプリケーションＦはディスプレイ１０１０の左側部分に表示される。この例示的な実施形態では、ディスプレイの面積は２つのアプリケーションに５０／５０で分割されるが、一方のアプリケーションを他方のアプリケーションよりも大きなディスプレイ１０１０の部分に表示してもよいことを理解されたい。この特定の例示的な実施形態では、フォーカスインジケータ２４１６で表されるように、アプリケーションＤがフォーカスされている。

【0192】

複数アプリケーションモードでは、縦向き及び横向きの両方において、各アプリケーションは、図２２及び図２３に示されるように、各自の関連付けられたウィンドウスタックを有してもよく、または表示されているすべてのアプリケーションで１つのスタックを共有してもよい。より具体的には、各アプリケーションが各自のスタックを有し、スタック構造が図２２に示される構造と同様である場合、１つのスタックが、アプリケーションＣ等の第１のアプリケーションに提供され、同様のスタックがアプリケーションＤに提供される。これらの各スタックは、例えば、上述したようなジェスチャを使用して独立してスクロールすることができる。

【0193】

図２８は、本発明の別の実施形態による画面ディスプレイ特徴を管理する例示的な方法を示す。この実施形態によれば、アプリケーションが最大化可能であるか否かが判断され、最大化可能な場合、デュアル画面モードまたは最大モードに適宜拡張されて、この図に示されるようにディスプレイ１０１０を略埋める。ここでは、最大化可能なアプリケーションであるアプリケーションＥ１が、最大モードを使用して拡大されて、ディスプレイ１０１０を略または完全に埋めている。

【0194】

図２８では、ボタン２６１８により、ユーザは単一画面モード（図２８に示されるような）と、例えば、図２６及び図２７に示されるようなエミュレートされたデュアル画面モードとを切り替えることができる。ここで、ボタン２６１８は「｜」を含まず、したがって、ＳＰ１０００が単一画面モードであることをユーザに示す。

【0195】

図２９は、ウィンドウを管理する例示的な方法を示す。この例示的な実施形態では、デバイス１００の動作と同様に、スタック内の最後のアプリケーションが脇に移動すると、デスクトップが表示される。さらに具体的には、図２９に示されるように、アプリケーションＦ２９０８はディスプレイ１０１０の上部に表示され、デスクトップ２９１２はディスプレイ１０１０の下部に表示される。ここでは、フォーカスインジケータ２９１６に示されるように、デスクトップがフォーカスされている。この構成は、ユーザがデュアル画面エミュレーションモードボタン２６１８を選択したために利用することができる。

【0196】

図３０は、一実施形態によるキーボードを表示する例示的な方法を示す。特に、ＳＰが縦向きモードの場合、ＳＰはキーボードエリア３００４及びアプリケーションエリア３００８を有する。キーボード３００４が表示されると、アプリケーションエリア３００８内のアプリケーションは、キーボード３００４で占められていない画面のエリアを略または完全に埋めるようにサイズ変更される。

【0197】

図３１Ａ及び図３１Ｂは、ＳＰ横向きモード及びＳＰ縦向きモードの両方において、単一アプリケーションモード及びデュアルアプリケーションモードの両方でデスクトップが利用可能なことを示す。特に、例示的な実施形態によれば、デスクトップ３１０４は画面１０１０の全体を占める。さらに、デスクトップが全画面モードで示されるこの例示的な実施形態によれば、宣言バー１３１２は、画面１０１０の全体にわたって拡大することができる。これは、図３１Ａに示される縦置きモード並びに図３１Ｂに示される横向きモードの両方で行うことができる。ここから、アプリケーションランチャ３１１６が選択されると、アプリケーションランチャは任意選択的に、縦向きモードまたは横向きモードで画面１０１０の全体にわたって拡大することができる。同様に、ファイルエクスプローラボタン３１２０を押下することにより起動されるファイルエクスプローラも同様に、画面１０１０のスペースの略すべてまたはすべてに拡大することができる。

【0198】

図３２Ａ及び図３２Ｂは、デバイス１００からＳＰ１０００へのデスクトップの遷移に必要とされ得る画面再描画を示す。特に、図３２Ａでは、６つの例示的なデスクトップパネルが示される３２０４〜３２２４。これらのデスクトップパネルは、ユーザからのジェスチャ入力に基づいて回転木馬のように移動可能である。しかし、これらのパネルを直接翻訳して、パネルを歪ませずに、または画面１０１０の全体を占有せずに、ＳＰ１０００に正確に表示することが可能ではないことがある。したがって、例示的な一実施形態によれば、ＳＰ１０００に表示される場合、画面１０１０のすべてまたは略すべてを収容するために、パネル３２０４〜３２２４のうちの１つまたは複数をサイズ変更することができる。別の例示的な実施形態によれば、パネルＤ２ ３２０８の部分、パネルＤ３ ３２１２の部分、及びパネルＤ４ ３２１６の部分等のパネルのうちの３つ以上を画面１０１０に示すことができる。このようにして、ＳＰ１０００に示されるデスクトップは、デバイス１００に示されるデスクトップパネルと同様のルックアンドフィールを有する。同じ回転木馬のような移動が、ユーザがデスクトップの１つまたは複数のパネルにスクロールできるように、ＳＰ１０００へのジェスチャ入力を介して利用可能である。

【0199】

図３３は、デバイス１００とかなり類似してＳＰ１０００で挙動する例示的な通知表示を示す。特に、縦向きモードであるか、それとも横向きモードであるかに関係なく、通知及び状態／トグルボタンが提供され、それにより、ユーザは、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ、画面ロック、デュアルまたは単一画面モード、電力オプション等をオンまたはオフに切り替えることができる。これらは、他の選択肢と同様に、一般にエリア３３０４に示される。上述した搬送波情報、通知情報、通信情報等のうちの１つまたは複数を含む追加の通知をエリア３３０８に示すこともできる。

【0200】

より詳細には、エリア３３０４は、ＷｉＦｉトグルオン・オフ、Ｂｌｕｅｔｏｏｔｈ（登録商標）トグルオン・オフ等の標準ウィジェットのいくつかのボタンを提供する。画面ロックトグルにより、例えば、ユーザは、画面をロックし、それにより、ＳＰ１０００の向きにも拘わらず回転しないようにすることができる。トグルは、色または表示特徴を変更して、画面ロックがイネーブルされているか否かを示すことができる。単一／デュアルアプリケーションモードボタンは、例えば、デュアルアプリケーションモード状態、単一アプリケーションモード状態、及び単一アプリケーションロック状態を含む３つの異なる状態を切り替える。電力モードトグルは、ハンドセット最適化、ＳＰ最適化、またはハイブリッド消費電力等を切り替える。これらの電力モードには、デバイス１００及びＳＰ１０００の電力レベルにそれぞれ対応する２つの電池状態インジケータ３３１２及び３３１６により示されるように、電力レベルに関連付けることができる。

【0201】

図３４Ａ及び図３４Ｂは、アプリケーションランチャボタン３１１６が選択された場合、アプリケーションランチャを起動し表示する例示的な方法を示す。図３４Ａに示される縦向きモード及び図３４Ｂに示される横向きモードの両方において、ＳＰが単一アプリケーションモードである場合、必ずしも画面１０１０の全体を占有する必要がないように、アプリケーションランチャはバブル内に表示することができる。しかし、例えば、ユーザによる適切なジェスチャまたは入力を受信すると、アプリケーションランチャを拡大して、画面１０１０の全体を占めることができる。これは、画面１０１０の全体を占めないように、デフォルトが常にアプリケーションランチャをバブル内で開くか、または画面１０１０の略すべてまたはすべてを占めて、常に全画面モードで開くことであるように、優先度でさらに分類することができる。

【0202】

図３５Ａ及び図３５Ｂは、システムが完全にはビュー内にはないデスクトップパネルの内容についての「ヒント」を提供することができる任意選択的な実施形態を示す。より具体的には、図３５Ａは、デスクトップパネルＤ１〜Ｄ６、３５０４〜３５２４のそれぞれの第１の実施形態を示す。考察したように、ユーザは、カルーセル様式でこれらのパネルを通してスクロールして、Ｄ１〜Ｄ６内の任意の内容を明らかにすることができる。同じパネルＤ１〜Ｄ６がユーザによる閲覧に提供される、図３５Ｂに示される任意選択的な実施形態によれば、ユーザに、１つまたは複数の隣接するパネル、ここではＤ２ ３５０８及びＤ５ ３５２０のプレビューが与えられる。この構成では、このユーザは、必ずしもカルーセルのような様式でスクロールして、パネルの全体を見る必要なく、隣接するパネルの内容を「のぞき見」することが可能である。より具体的には、パネルＤ３ ３５１２及びＤ４ ３５１６の全体がディスプレイ１０１０に示される。さらに、パネルＤ２ ３５０８の約１／３及びパネルＤ５ ３５２０のおよそ１／３もディスプレイ１０１０に示される。理解されるように、パネルＤ２及びＤ５の約１／３よりも大きいか、または小さい部分を示してもよく、示されるパネルが大きいほど、デスクトップのその部分のユーザに対する可視性が高くなる。

【0203】

図３６は、ウィンドウのスタックを複数アプリケーションモードで管理する任意選択的な実施形態を示す。この洗練された方法は、概念モデルを補強し、複数アプリケーションモードでのスタックの「カルーセル」式構成を空間的に視覚化するに当たってユーザを支援する。理解されるように、図３６に示される例示的な実施形態はＳＰ１０００の縦向きモードに関するが、横向きモードでも等しく上手く機能することができ、違いは、上から下または下から上式構成で回転するカルーセルの代わりに、「カルーセル」を左から右または右から左というタイプの動きで操作することができる。しかし、カルーセルは、横向きモードでも同様に上から下または下から上モードで機能することもできる。

【0204】

この例示的な実施形態では、複数アプリケーションモードがボタン２６１８を介してイネーブルされている場合、アプリケーションＣ３６０４及びアプリケーションＤ３６０８は、セパレータ３６１２により隔てて表示することができる。この任意選択的で例示的な実施形態によれば、アプリケーションＣ３６０４の背後に１つまたは複数のオーバーフローアプリケーションもあり、ここでは、オーバーフローアプリケーションは３４２４及び３４２８である。同様にして、アプリケーションＤ３６０８の背後にも１つまたは複数のオーバーフローアプリケーション、ここではアプリケーション３４１６及びアプリケーション３４２０があり得る。この特定の例示的な実施形態では、戻る及びメニューボタン３４３２は、アプリケーションスタックの背後に見られるデスクトップ３４３６の部分を用いてイネーブルすることができる。ジェスチャ３４４０等の１つまたは複数の入力ジェスチャを受信すると、ユーザはアプリケーションの「カルーセル」を通してスクロールし、この場合、アプリケーションＤ３６０８をアプリケーションＣ３６０４の位置に配置替えし、それにより、アプリケーション３４１６を明らかにすることができる。さらに、フォーカスインジケータを、フォーカスされているアプリケーションの近傍に表示することができる。この特定の例では、フォーカスインジケータ３４４４はアプリケーションＤの脇に表示される。任意選択的で例示的な実施形態によれば、ユーザがアプリケーション３４２０またはアプリケーション３４２８等の最後のアプリケーションに達した場合、スタックを「停止」させる代わりに、アプリケーションをカルーセル式に重ね、ユーザによる１つまたは複数の入力ジェスチャに応答して連続して回転することができる。

【0205】

これらの概念は、キーボードも複数アプリケーションモードで表示される状況に拡張することができる。例えば、図３７に示されるように、キーボード３７０４はアプリケーションスタック３７０８の下に表示される。アプリケーションスタック３７０８の「背後」には、ユーザが、例えば、ジェスチャ３７２０の開始を介してアクセスすることができる追加のアプリケーション３７１２及び３７１６がある。この例示的な実施形態は、ビュー内外への回転木馬のような様式でのアプリケーションスクロールを有し、キーボード３７０４は、例えば、ディスプレイ１０１０の底部で可視のままである。図３５の実施形態と同様に、戻る及びメニューボタンをイネーブルし、例えば、グラフィカルボタン３７２４で示されるように、ディスプレイ１０１０に視覚的に表示することができる。

【0206】

図３８は、デバイス１００をスマートパッド１０００にドッキングする例示的な方法を概説する。特に制御はステップＳ３８０２において開始され、ステップＳ３８０４に続く。ステップＳ３８０４において、ＳＰへのデバイスへの挿入が検出される。次に、ステップＳ３８０６において、電力管理を任意選択的に開始することができる。例えば、考察したように、ＳＰをデバイスの電源として使用してもよく、デバイスをＳＰの電源として使用してもよく、電力を２つのデバイスで共有してもよく、且つ／または例えば、ＳＰ及びデバイス１００のうちの一方または両方を充電可能なＡＣアダプタを介してＳＰを差し込んでもよい。次に、ステップＳ３８０８において、デバイス１００のディスプレイは任意選択的にオフになり、例えば、節電する。次に、制御はステップＳ３８１０に続く。ステップＳ３８１０において、通信及び／または接続がデバイス１００とＳＰとの間で確立される。次に、ステップＳ３８１２において、ＳＰのディスプレイ及び他の入／出力機能がイネーブルされる。次に、ステップＳ３８１４において、デバイスソフトウェア設定はスマートパッドハードウェア設定にマッピングされる。次に、制御はステップＳ３８１６に続く。

【0207】

ステップＳ３８１６において、デバイスの画面の向きは、ＳＰの向きに自動的に合わせられる。次に、ステップＳ３８１８において、デバイスでフォーカスされている最後のアプリケーションはフォーカスされたままであり、ＳＰに表示される。次に、通常動作及びＳＰとの対話は引き続き、例えば、デバイス１００で使用可能なジェスチャと同じジェスチャを利用する。次に、制御はステップＳ３８２０に続き、制御シーケンスは終了する。

【0208】

図３９は、アプリケーション／ディスプレイ向き／向き変更の例示的な方法を示す。特に、制御はステップＳ３９００において開始され、ステップＳ３９０２に続く。ステップＳ３９０２において、ＳＰの向きが検出される。次に、ステップＳ３９０４において、デバイスでのアプリケーションの向きが検出される。次に、ステップＳ３９０６において、表示された１つまたは複数のアプリケーションが、ＳＰと同じ向きになるように向き変更される。加えて、向き変更の必要性に基づいて、アプリケーションの再描画またはサイズ変更を、ＳＰに表示されているアプリケーションに対して行うこともできる。次に、制御はステップＳ３９０８に続き、制御シーケンスは終了する。

【0209】

図４０は、キーボードを管理する例示的な方法を概説する。特に、制御はステップＳ４０００において開始され、ステップＳ４００２に続く。ステップＳ４００２において、キーボード要求が検出されたか否かが判断される。キーボード要求が検出されていない場合、制御は元のステップＳ４０００に飛び、その他の場合、制御はステップＳ４００４に続く。ステップＳ４００４において、ＳＰの向きが判断される。ＳＰが横向きの場合、制御はステップＳ４０１０に飛び、その他の場合、制御はステップＳ４００６に続き、ＳＰは縦向きである。ステップＳ４００６において、キーボードは縦向きモードで表示される。

【0210】

次に、ステップＳ４００８において、向き変更があったか否かが判断される。向き変更があった場合、制御はステップＳ４０１０に飛び、その他の場合、制御はステップＳ４０１４に続く。

【0211】

ステップＳ４０１０において、キーボードは横向きモードで表示される。次に、ステップＳ４０１２において、ＳＰの向きが変更されたか否かが判断される。向きが変更された場合、制御はステップＳ４００６に飛び、その他の場合、制御はＳ４０１４に続く。

【0212】

ステップＳ４０１４において、キーボードを隠すべきか否かが判断される。キーボードを隠すべき場合、制御はステップＳ４０１６に続き、その他の場合、制御は元のステップＳ４００４に続く。

【0213】

ステップＳ４０１６において、キーボードが隠され、制御はステップＳ４０１８に続き、制御シーケンスは終了する。
図４１は、ウィンドウ管理の例示的な方法を示す。特に、制御はステップＳ４１００において開始され、ステップＳ４１０２に続く。ステップＳ４１０２において、ジェスチャが検出される。理解されるように、デバイス１００と同様に、このジェスチャはタッチセンサ式ディスプレイの構成可能エリア及び／またはジェスチャ捕捉領域にあることができる。ステップＳ４１０４において、ジェスチャ方向を任意選択的に検出することができる。次に、ステップＳ４１０６において、次のアプリケーションウィンドウを視界に持ってきて、例えば、ユーザがアプリケーションウィンドウスタックを通してスクロールできるようにする。次に、別のジェスチャが検出されたか否かが判断される。別のジェスチャが検出された場合、制御は元のステップＳ４１０４に飛び、その他の場合、制御はステップＳ４１１０に続く。

【0214】

図４２は、画面管理の例示的な方法を概説する。特に、制御はステップＳ４２００において開始され、ステップＳ４２０２に続く。ステップＳ４２０２において、複数アプリケーションモードが、例えば、ボタンまたはトグルの選択を介してイネーブルされる。次に、ステップＳ４２０４において、ユーザは任意選択的に、どのアプリケーションが表示されるかを選択するように促される。代替の実施形態では、スタック内の２つの隣接するアプリケーションが表示され、アプリケーションの一方は現在フォーカスされているアプリケーションである。次に、ステップＳ４２０６において、画面は分割され、画面の第１の部分は第１のアプリケーションを表示し、画面の第２の部分は第２のアプリケーションを表示する。次に、ステップＳ４２０８において、フォーカスされていると検出されたアプリケーションが、次に、ステップＳ４２１０において、ＳＰにおいて強調表示される。次に、制御はステップＳ４２１２に続く。

【0215】

ステップＳ４２１２において、新しいアプリケーションがフォーカスされたか否かが判断される。新しいアプリケーションがフォーカスされた場合、制御は元のステップＳ４２１０に飛び、そのアプリケーションが「フォーカス中」インジケータを用いて強調表示される。その他の場合、制御はステップＳ４２１４に続き、制御シーケンスは終了する。

【0216】

図４３は、ウィンドウ管理の例示的な方法を概説する。特に、制御はステップＳ４３００において開始され、ステップＳ４３０２に続く。ステップＳ４３０２において、アプリケーションを最大化できるか否かが判断される。次に、ステップＳ４３０４において、アプリケーションが最大化可能な場合、制御はステップＳ４３０６に飛び、アプリケーションがデュアル画面モードまたは最大モードに拡大される。次に、制御はステップＳ４３０８に続き、制御シーケンスは終了する。

【0217】

図４４は、アプリケーションウィンドウからデスクトップに遷移する例示的な方法を概説する。特に、制御はステップＳ４４００において開始され、ステップＳ４４０２に続く。ステップＳ４４０２において、アプリケーションウィンドウスタック内の最後のアプリケーションが検出される。次に、ステップＳ４４０４において、「次の」ウィンドウを要求するジェスチャが検出されるが、現在のウィンドウはウィンドウスタック内の最後のアプリケーションである。このシナリオでは、ステップＳ４４０６において、アプリケーションウィンドウスタック内に表示するウィンドウがもうないという点で、デスクトップが表示される。次に、制御はステップＳ４４０８に続き、制御シーケンスは終了する。

【0218】

図４５は、ＳＰ１０００でデバイス１００の複数画面ディスプレイをエミュレートする例示的な方法を示す。特に、制御はステップＳ４５００において開始され、ステップＳ４５０２に続く。ステップＳ４５０２において、デスクトップはＳＰに表示される。次に、ステップＳ４５０４において、デスクトップは、ＳＰ上で、例えば２つのセクションに論理的に分割される。次に、ステップＳ４５０６において、デスクトップの第１の画面が、ＳＰディスプレイの第１の論理的な部分に表示される。次に、ステップＳ４５０８において、デスクトップの第２の画面が、ＳＰディスプレイの第２の論理的な部分に表示される。次に、制御はステップＳ４５１０に続く。

【0219】

ステップＳ４５１０において、ディスプレイに示される「パネル」のカルーセル移動を、ジェスチャ等のユーザ入力を通して開始することができる。次に、制御はステップＳ４５１２に続き、制御シーケンスは終了する。

【0220】

図４６は、ＳＰのデスクトップの複数の「パネル」を表示する例示的な方法を概説する。特に、制御はステップＳ４６００において開始され、ステップＳ４６０２に続く。ステップＳ４６０２において、デスクトップの部分がＳＰに表示される。次に、ステップＳ４６０４において、デスクトップは、複数のデスクトップ「パネル」を収容するようにスマートパッド上で論理的に分割される。次に、ステップＳ４６０８において、デスクトップの第１の画面またはパネルは、ＳＰディスプレイの１つの論理的な部分に表示される。次に、ステップＳ４６１０において、デスクトップの第２の画面またはパネルが表示され、ＳＰディスプレイの第１及び第２の論理的な部分を橋渡しする。次に、デスクトップの第３の画面またはパネルが、ＳＰディスプレイの第２の論理的な部分に表示される。次に、制御はステップＳ４６１４に続く。

【0221】

ステップＳ４６１４において、パネルのカルーセル移動は、例えば、ユーザによるジェスチャの入力により影響を受けることができる。次に、制御はステップＳ４６１６に続き、制御シーケンスは終了する。

【0222】

図４７は、デスクトップの１つまたは複数の部分を表示する例示的な方法を概説する。特に、制御はステップＳ４７００において開始され、ステップＳ４７０２に続く。ステップＳ４７０２において、デスクトップへのアクセス要求が検出される。次に、ステップＳ４７０４において、少なくとも１つのデスクトップパネルが表示される。次に、ステップＳ４７０６において、少なくとも１つの追加のデスクトップパネルが、デスクトップに部分的に表示される。次に、制御はステップＳ４７０８に続く。

【0223】

ステップＳ４７０８において、ジェスチャが検出されると、部分的に表示されたパネルをＳＰのディスプレイに完全に表示することができる。次に、制御はステップＳ４７１０に続き、制御シーケンスは終了する。

【0224】

図４８は、複数アプリケーションモードでウィンドウを管理する例示的な方法を概説する。特に、制御はステップＳ４８００において開始され、ステップＳ４８０２に続く。ステップＳ４８０２において、複数アプリケーションモードになる。次に、ステップＳ４８０４において、ウィンドウスタックは、１つまたは複数のアプリケーションが第１のアプリケーションの背後で部分的に可視になるように構成される。次に、ステップＳ４８０６において、スタックは、１つまたは複数のアプリケーションが第２のアプリケーションの背後で部分的に可視であるように構成される。次に、ステップＳ４８０８において、ユーザから入力ジェスチャを受信すると、スタックの終わりに達するまで、スタックを通して回転木馬のような（Ｃａｒｏｕｓｅｌ−Ｌｉｋｅ）スクロールをイネーブルすることができ、または第２の実施形態では、スタックは、スタックを通しての連続スクロールが可能な「円形」構成を有することができる。次に、制御はステップＳ４８１０に続き、制御シーケンスは終了する。

【0225】

スマートパッド及びデバイスとの相互作用との関連で、本開示の例示的なシステム及び方法について説明してきた。しかし、本開示を不必要に曖昧にすることを避けるため、前の記述では多くの公知の構造及びデバイスを省略する。この省略は、特許請求の範囲を限定するものと解釈してはならない。具体的な詳細は、本開示の理解を与えるために記載する。しかし、本開示は、本明細書に記載される具体的な詳細の域を超えるさまざまな方法で実施できることを理解されたい。

【0226】

例えば、スマートパッドは、複数の物理的及び／または論理的な画面／ディスプレイを有しうる。加えて、スマートパッドは、スタイラス、マウスのような、一つ又は複数の入力デバイスと共に用いることができる。さらに、スマートパッドは、スタンドアローン動作を可能とするプロセッサ、メモリ、通信手段等を装着されることができる。さらに、スマートパッドは、スマートフォンのような他のタイプの通信デバイスと関連付けられ、又はドッキングされ得、これによりスマートパッドはディスプレイ及び／またはＩ／Ｏインタフェースとして使用され得る。

【0227】

その上、本明細書に示される例示的な態様、実施形態及び／または構成は、並置されるシステムのさまざまなコンポーネントを示すが、システムのあるコンポーネントは、ＬＡＮ及び／またはインターネットなどの分散型ネットワークの遠方部に、または、専用システム内で遠隔設置することができる。したがって、システムのコンポーネントを、タブレット様デバイスのような１つまたは複数のデバイスに組み合わせることも、アナログ及び／もしくはデジタルの電気通信ネットワーク、パケット交換ネットワーク、または、回路交換ネットワークなどの分散型ネットワークの特定のノード上に並置することもできることを理解されたい。前の記述から、演算効率のため、システムのコンポーネントは、システムのオペレーションに影響を及ぼすことなく、コンポーネントの分散型ネットワーク内のいずれの位置にも配置できることが理解されよう。例えば、さまざまなコンポーネントは、ＰＢＸ及びメディアサーバ、ゲートウェイなどのスイッチに、１つもしくは複数の通信デバイスに、１つもしくは複数のユーザの構内で、または、それらのいくつかの組合せで配置することができる。同様に、システムの１つまたは複数の機能部分は、電気通信デバイスと関連コンピューティングデバイスとの間で分散させることが可能である。

【0228】

その上、要素を接続するさまざまなリンクは、有線リンクでも無線リンクでも、その任意の組合せでも、接続された要素への及び接続された要素からのデータの供給及び／または通信が可能な他の任意の公知のまたは後に開発された要素でもあり得ることを理解されたい。これらの有線または無線リンクは、保護されたリンクでもあり得、暗号化された情報を通信できる場合もある。リンクとして使用される伝送媒体は、例えば、同軸ケーブル、銅線及び光ファイバを含む任意の適切な電気信号のキャリアであり得、電波及び赤外線データ通信中に生成されるものなどの音波または光波の形をとることができる。

【0229】

また、イベントの特定のシーケンスとの関連でフローチャートについて論じ示してきたが、開示される実施形態、構成及び態様のオペレーションに実質的に影響を及ぼすことなく、このシーケンスに対する変更、追加及び省略が起こり得ることを理解されたい。

【0230】

さらなる別の実施形態では、本開示のシステム及び方法は、専用コンピュータ、プログラムされたマイクロプロセッサもしくはマイクロコントローラ及び周辺集積回路素子、ＡＳＩＣもしくは他の集積回路、デジタル信号プロセッサ、個別素子回路などの配線電子もしくは論理回路、ＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬなどのプログラム可能論理デバイスもしくはゲートアレイ、専用コンピュータ、任意の同等な手段、または、同様のものと併せて実施することができる。一般に、本明細書に示される方法論の実施が可能な任意のデバイスまたは手段を使用して、本開示のさまざまな態様を実施することができる。開示される実施形態、構成及び態様に使用できる例示的なハードウェアは、コンピュータ、携帯用デバイス、電話（例えば、携帯電話、インターネット可能な、デジタル、アナログ、ハイブリッド及び他のもの）、及び、当技術分野で知られている他のハードウェアを含む。これらのデバイスのいくつかは、プロセッサ（例えば、単一または複数のマイクロプロセッサ）、メモリ、不揮発性記憶装置、入力デバイス及び出力デバイスを含む。その上、これらに限定されないが、分散処理もしくはコンポーネント／オブジェクト分散処理、並列処理、または、仮想マシン処理を含む代替のソフトウェア実装形態は、本明細書に記載される方法を実施するよう構築することもできる。

【0231】

さらなる別の実施形態では、開示される方法は、さまざまなコンピュータまたはワークステーションプラットフォームで使用することができるポータブルソースコードを提供するオブジェクトまたはオブジェクト指向ソフトウェア開発環境を使用するソフトウェアと併せて容易に実施することができる。あるいは、開示されるシステムは、標準論理回路またはＶＬＳＩ設計を使用してハードウェアで部分的または完全に実装することができる。本開示に従ってシステムの実装にソフトウェアまたはハードウェアを使用するかどうかは、システムの速度及び／または効率要件、特定の機能、ならびに、利用する特定のソフトウェアまたはハードウェアシステムまたはマイクロプロセッサまたはマイクロコンピュータシステムに依存する。

【0232】

さらなる別の実施形態では、開示される方法は、記憶媒体に格納することができ、コントローラ及びメモリと協働してプログラムされた汎用コンピュータ、専用コンピュータ、マイクロプロセッサ及び同様のもの上で実行されるソフトウェアで部分的に実施することができる。これらの例では、本開示のシステム及び方法は、アプレット、ジャバ（ＪＡＶＡ）（登録商標）またはＣＧＩスクリプトなどのパーソナルコンピュータに組み込まれたプログラムとして、サーバまたはコンピュータワークステーション上に常駐するリソースとして、専用測定システム、システムコンポーネントまたは同様のものに組み込まれたルーチンとして実施することができる。また、システムは、ソフトウェア及び／またはハードウェアシステムにシステム及び／または方法を物理的に組み込むことによっても実装することができる。

【0233】

本開示は、特定の規格及びプロトコルを参照して、態様、実施形態及び／または構成で実装されるコンポーネント及び機能について説明するが、態様、実施形態及び／または構成は、そのような規格及びプロトコルに制限されない。本明細書で言及されない他の同様の規格及びプロトコルも存在し、本開示に含まれるものと考えられる。その上、本明細書で言及される規格及びプロトコルならびに本明細書で言及されない他の同様の規格及びプロトコルは、本質的に同じ機能を有するより速いまたはより効果的な均等物に定期的に取って代わられる。同じ機能を有するそのような置換規格及びプロトコルは、本開示に含まれる均等物と考えられる。

【0234】

さまざまな態様、実施形態及び／または構成での本開示は、本明細書に描写及び記載されるように実質的にコンポーネント、方法、プロセス、システム及び／または装置を含み、さまざまな態様、実施形態、構成実施形態、サブコンビネーション及び／またはそのサブセットを含む。当業者であれば、本開示を理解した後で、開示される態様、実施形態及び／または構成をどのように作成し使用するか理解されよう。さまざまな態様、実施形態及び／または構成での本開示は、本明細書に描写及び／または記載されていないアイテムなしで、または、本明細書のさまざまな態様、実施形態及び／または構成で、デバイス及びプロセスを提供することを含み、例えば、性能を向上させ、容易に実装を実現し、及び／または、実装コストを削減するために、前のデバイスまたはプロセスで使用された可能性があるようなアイテムがない場合も含む。

【0235】

前述の論考は、例示と説明を目的として提示してきた。前述は、本明細書に開示される１つまたは複数の形態に本開示を制限することを意図しない。前述の発明を実施するための形態では、例えば、本開示を合理化する目的で、１つまたは複数の態様、実施形態及び／または構成で、本開示のさまざまな特徴が一緒に分類される。本開示の態様、実施形態及び／または構成の特徴は、上記で論じられたもの以外の代替の態様、実施形態及び／または構成で組み合わせることができる。本開示のこの方法は、請求項が各請求項に明確に列挙されているものより多くの特徴を要求するという意図を反映するものとして解釈してはならない。むしろ、以下の請求項が反映するように、発明の態様は、単一の前述の開示される態様、実施形態及び／または構成のすべての特徴よりも少ないことにある。したがって、以下の請求項は、本明細書によって、この発明を実施するための形態に組み込まれ、各請求項は、本開示の別々の好ましい実施形態としてそれ自体を主張する。

【0236】

その上、説明には１つまたは複数の態様、実施形態及び／または構成の説明、ならびに、ある変形形態及び変更形態が含まれるが、例えば、本開示を理解した後で、当業者の技能及び知識の範囲内となり得るように、他の変形形態、組合せ及び変更形態は本開示の範囲内である。許可される範囲の代替の態様、実施形態及び／または構成を含む権利を得ることを意図し、そのような代替の、交換可能な及び／または均等な構造、機能、範囲または工程が本明細書で開示されるか否かにかかわらず、いかなる特許可能な対象物も公的に献納することを意図することなく、特許請求されたものに対する代替の、交換可能な及び／または均等な構造、機能、範囲または工程を含む。

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図1F】

【図1G】

【図1H】

【図1I】

【図1J】

【図4G】

【図4H】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図6F】

【図6G】

【図6H】

【図6I】

【図6J】

【図10】

【図11】

【図12】

【図14】

【図15】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図31A】

【図31B】

【図32A】

【図32B】

【図35A】

【図35B】

【図37】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図4C】

【図4D】

【図4E】

【図4F】

【図5A】

【図5B】

【図7A】

【図7B】

【図7C】

【図7D】

【図7E】

【図8】

【図9】

【図13A】

【図13B】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図29】

【図30】

【図33】

【図34A】

【図34B】

【図36】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】