JP2012507091A - インターラクティブなプロキシミティディスプレイのテザーのための装置、方法およびシステム - Google Patents

Abstract

インターラクティブなプロキシミティディスプレイのテザー（ＩＰＤＴ）のための装置、方法およびシステムは、ソースとターゲットデバイス間でインターラクティブ通信とディスプレイのテザーを与えるインターラクティブなプロキシミティディスプレイのテザー（ＩＰＤＴ）を教示する。ＩＰＤＴは、ユーザがターゲットデバイスのより大型のディスプレイでソースモバイルデバイスを使用することを可能にする。例えば、ユーザはｉＰｈｏｎｅなどのソースデバイスを使用し、ＩＰＤＴによって実行されたビデオゲームを送信し、ターゲットとしてより大型のディスプレイデバイスを使用し、様々なアプリケーションを動作させる際に、特にゲーム環境において、より大きい有用性を与える。加速度計の使用を可能にするｉＰｈｏｎｅなどのデバイスはＩＰＤＴで強化され、それによってデバイス全体が入力（例えば、ゲーム）コントローラとして動作可能となり、ユーザにアプリケーションへの入力を制御する（例えば、ゲームを制御する）ことを可能にすると共にアプリケーションの結果を十分に閲覧することを可能にする。
【選択図】図１

Description

（関連出願）
本出願人は、２００８年１０月２７日に提出され、「インターラクティブなプロキシミティディスプレイのテザーのための装置、方法およびシステム」という名称を有する米国仮特許出願シリアル番号第６１／１０８，５６５号、弁護士ドケット番号１９６２６−００２ＰＶと、２００８年１１月１９日に提出され、「インターラクティブなプロキシミティディスプレイのテザーのための装置、方法およびシステム」という名称を有する米国仮特許出願シリアル番号第６１／１１６，１７５号、弁護士ドケット番号１９６２６−００２ＰＶ１と、２００９年２月１１日に提出され、「リモートでインターラクティブなリアルタイム共同プレイのための装置、方法およびシステム」という名称を有する米国仮特許出願シリアル番号第６１／１５１，８３２号、弁護士ドケット番号１９６２６−００４ＰＶと、に対する米国特許法第１１９条に基づく優先権をここに主張する。

上記出願の内容全部は参照されてここで明示的に結合される。
（分野）
本発明は、一般に、インターラクティブディスプレイのための装置、方法およびシステムに係り、特に、インターラクティブなプロキシミティディスプレイのテザー（以下、「ＩＰＤＴ」）のための装置、方法およびシステムに関する。

任天堂ゲームボーイ、任天堂ＤＳ、ソニーＰＳＰなどの携帯型ゲーム環境と、ｉＰｈｏｎｅ、Ｐａｌｍ、ブラックベリー、及び／又は、その他のデバイスなどの移動通信電話機はユーザが移動しながらゲームをすることを可能にする。これらのデバイスは、典型的に、携帯可能な大きさの画面を有してユーザが移動中にゲームをすることを可能にする。

インターラクティブなプロキシミティディスプレイのテザー（ＩＰＤＴ）はユーザがターゲットデバイスのより大型のディスプレイでソースデバイスを使用することを可能にする。ＩＰＤＴは、ｉＰｈｏｎｅなどのソースデバイスにターゲットであるより大型のディスプレイデバイスを使用することを可能にする際に特に有益であり、それは様々なアプリケーションを動作させるにあたって、特にゲーム環境においてより大きい有用性を与える。加速度計の使用を可能にし、それによって全体として入力（例えば、ゲーム）コントローラとして動作可能であるｉＰｈｏｎｅなどのデバイスは、ユーザにアプリケーションへの入力を制御する（例えば、ゲームを制御する）ことを可能にすると共にアプリケーションの結果を十分に閲覧することを可能にすることによってＩＰＤＴで強化される。例えば、バーチャルゴルフゲームをする時は、ユーザはｉＰｈｏｎｅでゴルフスイングをシミュレートし、ｉＰｈｏｎｅは入力装置として使用可能であるが、ユーザはスイング中にｉＰｈｏｎｅでスイングを見ることができない。

ＩＰＤＴは、アップルｉＰｈｏｎｅなどの（但し、これには限定されない）より小さいモバイルデバイスが、大画面コンピュータ、ラップトップ、セットトップボックス、ケーブルボックス、テレビなどの他のデバイスでその表示を送ることを可能にする。ｉＰｈｏｎｅなどのモバイルデバイスを使用した多数のユーザ間におけるインターラクティブなゲーミングは、ＩＰＤＴを介して送信及び相互作用する能力から同様に利益を得る。また、スライドショーのプレゼンテーションなどのビジネス及びパーソナルのプロダクティビティアプリケーションは、ＩＰＤＴによって強化されたアプリケーションから利益を得て、これによってユーザが殆ど全ての便利でアクセス可能なターゲットデバイスを彼らのソースデバイスの延長として使用することを可能にする。

添付の付録と図面は、本開示に従って様々な非限定的で実例である発明の側面を例示している。

インターラクティブなプロキシミティディスプレイのテザー（以下、「ＩＰＤＴ」）の動作のある実施例におけるリアルタイム共同プレイシステムを有するＩＰＤＴと関連エンティティとの間のデータフローの実施の全体ブロック図である。 ＩＰＤＴ動作の実施例におけるＩＰＤＴシステムコンポーネント実装を与える。 図３Ａ−３Ｆは、ＩＰＤＴ動作の実施例のインターラクティブなプロキシミティディスプレイのテザー機能の側面を示す論理フロー図とスクリーンショットの実例を与える。 ＩＰＤＴ動作の実施例においてインターラクティブなプロキシミティディスプレイのテザー機能のデータフォーマットの実例を示すブロック図である。 図５Ａ−５Ｄは、ＩＰＤＴ動作の実施例における共同プレイＩＰＤＴの実施例を示す図である。 図６Ａ−６Ｂは、ＩＰＤＴ動作の実施例におけるリアルタイム共同プレイの側面を示す論理フロー図である。 図７Ａ−７Ｃは、ＩＰＤＴ動作におけるある実施例の購読プロセスとＩＰＤＴの他の実施例の側面の図である。 ある実施例におけるゴルフクラブとして構成されたＩＰＤＴ筺体の実施例の図である。 ＩＰＤＴコントローラの実施例を示すブロック図である。

図面の各参照符号の先頭番号は参照符号が紹介及び／又は詳述されている図を示している。このため、参照符号１０１の詳細な説明は図１に存在、及び／又は、紹介されている。参照符号２０１は図２などに紹介されている。

本開示はインターラクティブなプロキシミティディスプレイのテザー（以下、「ＩＰＤＴ」）のための装置、方法およびシステムの実施を詳述する。ＩＰＤＴは、ユーザの電話機でインターラクティブアプリケーションを実施して、ターゲットデバイス、及び／又は、別のユーザ電話機でテザーし、これによってユーザは電話機のゲーミングアプリケーションを起動するローカル画面を、より大型のディスプレイ装置に投射することができる。

例えば、ある実施例においては、ＩＰＤＴは、アップルのｉＰｈｏｎｅのＯＳ、グーグルのアンドロイドのＯＳ、ブラックベリーのＯＳなどのスマートホンのプラットフォーム上で様々なモバイルデバイスで実行可能である。ある実施例においては、かかるモバイルデバイスを操作するユーザは、そのモバイルデバイスからｉＧｏｌｆゲーム等のＩＰＤＴゲーミングアプリケーションをプレイすることを選択する。ユーザが、例えば、モバイルデバイス画面メニューからＩＰＤＴコンポーネントアイコンをクリックすることによってＩＰＤＴアプリケーションを開始すると、モバイルデバイスはローカル・エリア・ネットワーク内で利用可能なターゲットデバイスをクエリする。例えば、ある実施例においては、モバイルデバイスは、ブルートゥースの範囲内で登録されたラップトップ、デスクトップ、プロジェクタ、テレビなどを検索する。ユーザは、その後、利用可能なターゲットデバイスの検索結果リストを与えられるか、選択を入力する。ある実施例においては、ユーザはテレビを選択し、モバイルデバイスは通信チャネルを確立し、テレビでテザーする。ある実施例においては、モバイルデバイスのゲーミング画面は、テレビの大型ディスプレイに投射され、テレビにリアルタイムにインターラクティブにビデオゲーミング画面を表示した状態で、ユーザにリモートゲームコントローラとしてモバイルデバイスを操作することを可能にする。

ある実施例においては、リモートディスプレイテザーコンポーネントを初期化する要求を受信することと、テザーターゲットデバイスをクエリすることと、選択されたテザーターゲットデバイスに対する通信チャネルを構成することと、選択されたテザーターゲットデバイスの種類を決定することと、選択されたテザーターゲットデバイスがプロセッサベースである場合は通信チャネルを通じてリモートディスプレイのインスタンスを作成することと、選択されたテザーターゲットデバイスがプロセッサベースである場合はソースデバイスにインターラクティブテザーアプリケーションのインスタンスを作成することと、制御入力に基づいてデータを生成することと、通信チャネルを通じてリモートディスプレイを駆動するために生成されたデータを送ることと、を有する。

ＩＰＤＴユーザ、管理者、サーバ、データ、貨幣構造、ハードウェア構造、ネットワークフレームワークなどの特定の需要、及び／又は、特徴に依存して、大量の柔軟性とカスタム化を容易にするＩＰＤＴの様々な実施例が具現化可能であることを理解すべきである。本開示は、主としてビデオゲーミングアプリケーションのコンテクストにおけるＩＰＤＴの実施例を説明する。しかし、ここで記載された本システムは、広範囲の他の用途または実施例のために直ちに構成され／カスタマイズされることが可能であることを理解すべきである。例えば、ＩＰＤＴの側面は、暗号通信、人工知能シミュレーション、リモートアクセスプレゼンテーションなどに対して構成可能である。ＩＰＤＴは、一般のネットワーク管理アプリケーションとネットワークプロトコル設計のための他の実施例に更に適用されてもよいことを理解すべきである。

図１は、ＩＰＤＴ動作におけるある実施例においてＩＰＤＴシステムと関係エンティティとの間のデータフローの実施の全体ブロック図である。図１において、ソースデバイス１１０を操作するユーザ１０５、リモートディスプレイ１２５を有するターゲットデバイス１２０、ＩＰＤＴデータベース１１９およびシステム管理者１３０が通信ネットワーク１１３を介して相互作用するように示されている。

ある実施例においては、ユーザ１１０は、ソースデバイス１１０を使用してソースデバイスのソースディスプレイ１１５の画面をターゲットデバイス１２０のリモートディスプレイ１２５と接続して共有する操作を行う。ソースデバイス１１０は、モバイルデバイス、専用ゲーム機、汎用計算機などの（但し、これらに限定されない）様々な異なるデバイスと技術を含んでもよい。ターゲットデバイス１２０は、例えば、モバイル電話機、専用ゲーム機、汎用計算機、ゲームコンソール、セットトップボックス、ケーブルボックス、ビデオディスプレイなどのデバイスと技術を含んでもよい。例えば、図１に示すように、ある実施例において、ソースデバイス１１０は、アップル社のｉＰｈｏｎｅなどの携帯電話機で、ターゲットデバイス１２０はディスプレイ画面１２５を有するコンピュータであってもよい。別の例では、ソースデバイス１１０は、（図８の実施例で更に示されているように）ゴルフゲーム用のゴルフクラブ、テニスゲーム用のテニスラケット、魚釣りゲーム用の釣竿、野球ゲーム用の野球のバットなどのゲーム器具形状を有する筺体に保護されたアップルのｉＰｈｏｎｅなどのモバイルデバイスであってもよい。

ＩＰＤＴは、通信ネットワーク１１３を通じて、ＷｉＦｉ、ブルートゥース、３Ｇセルラー、イーサネット、物理的テザー（例えば、モニタまたはテレビへの接続を与えるｉＰｈｏｎｅビデオＡＶからドックコネクタケーブル）などの広範囲のプロトコルに基づいて接続を容易にする。ある実施例においては、通信ネットワーク１１３は、インターネット、ワイド・エリア・ネットワーク（ＷＡＮ）、電話ネットワーク、ローカル・エリア・ネットワーク（ＬＡＮ）、ピア・ツー・ピア（Ｐ２Ｐ）接続などであってもよい。ある実施例においては、ソース装置１１０は、図４の実施例に更に示すように、通信ネットワーク１１３を介して制御情報とデータペイロードを交換するためにターゲットデバイス１２０を検出し、ハンドシェークし、対話してもよい。例えば、ある実施例においては、通信ネットワーク１１３は、ソースデバイス１１０がそのソースディスプレイ１１５をターゲットデバイスのリモートディスプレイ１２５に投射するように通信路を与え、その一つはクライアントデバイス１１２にも通信チャネルを開いている。このようにして、一以上のクライアントデバイスとの通信と共に、比較的小型のソースデバイスはターゲットデバイスのより大型のディスプレイを駆動し、リモートデバイス１２５を使用してソースデバイスによるテザー及びインターラクティブ制御を可能にする。別の実施例においては、ＩＰＤＴは、ターゲットデバイス１２０のより大型のリモートディスプレイ１２５を介して一以上のソースデバイス１１０によってゲームのインターラクティブ制御を与えるインターラクティブコントロール手段を実行してもよい。例えば、ある実施例においては、ユーザ１０５は、ターゲットデバイスに表示されたゲーミングアプリケーションを別のユーザ１０５と共同プレイする。このようにして、ソースデバイスは、図５Ａ乃至５Ｄに示すある実施例に更に示すように、互いに、そして、異なるモードでターゲットデバイスと通信するように構成されてもよい。

ある実施例においては、ソースデバイス１１０、ターゲットデバイス１２０などのＩＰＤＴエンティティは、ＩＰＤＴデータベース１１９と通信する。幾つかの実施例においては、分散ＩＰＤＴデータベースは、ターゲットデバイス１２０、及び／又は、ソースデバイス１１０と筺体が一体であってもよい。別の実施例においては、ＩＰＤＴエンティティは、通信ネットワーク１１３を介してリモートＩＰＤＴデータベース１１９にアクセスすることができる。ある実施例においては、ＩＰＤＴエンティティは、記憶用データベース１１９にデータを送信してもよく、データは、ユーザアカウント情報、アプリケーションデータ、プロトコルデータ、アプリケーション履歴などであるが、これらに限定されない。

ある実施例においては、ＩＰＤＴデータベース１１９は、（例えば、アップル社、インテル、ソニーなどの）ハードウェアベンダー、（例えば、任天堂、ゲームキューブ、ゲームボーイなどの）ゲーミングアプリケーションベンダー、（例えば、プレイステーションネットワーク、ＷｉｉＣｏｎｎｅｃｔ２４などの）サービスベンダーなどの様々なベンダーに接続された一以上のオンラインデータベースであってもよく、かかるベンダーから更新ハードウェアドライバ情報、新しいゲーミングアプリケーションパッケージ及びサービスを取得してもよい。ある実施例においては、ソースデバイス１１０、及び／又は、ターゲットデバイス１２０は、連続的、間欠的、及び／又は、定期的に、更新ユーザプロフィール、更新ソフトウェアプログラム、更新コマンド命令などの更新をＩＰＤＴデータベース１１９から、テルネットＦＴＰ、ＨＴＴＰ転送、Ｐ２Ｐ通信などの様々な接続プロトコルを介してダウンロードする。

更なる実施例においては、ターゲットデバイス１２０とソースデバイス１１０は通信ネットワーク１１３を介してオンラインゲーミングサーバ１３０に接続する。例えば、ある実施例において、ユーザ１０５は、ターゲットデバイス１２０にローカルで表示される、オンラインゲーミングサーバ１３０におけるインターネットゲームコミュニティ（例えば、ＦＡＳＴなど）に加入するのにソースデバイス１１０を使用する。

ある実施例においては、システム管理者１４０は、通信ネットワーク１１３を介して定期保守、サービス障害、システム更新、データベース再開、セキュリティ監視などのために、ＩＰＤＴエンティティと通信してもよい。例えば、ある実施例においては、システム管理者は、システム設定、ペアレンタルコントロールなどを構成するために、ターゲットデバイス１２０と直接に動作するユーザであってもよい。別の実施例においては、システム管理者は、インターネットゲーミングのサーベースベンダーであってもよい。

図２は、ＩＰＤＴ動作のある実施例におけるＩＰＤＴシステムコンポーネントの例を示している。ＩＰＤＴデバイス２０１は、幾つかの機能的モジュール及び／又はデータ記憶部を有してもよい。ＩＰＤＴ制御部２０５は、ＩＰＤＴ動作の幾つかの実施例において中心的役割を果たし、ＩＰＤＴモジュールを介してターゲットデバイス及び／又はクライアントデバイスへ、ターゲットデバイス及び／又はクライアントデバイスから、ターゲットデバイス及び／又はクライアントデバイス間でデータ及び／又は命令の受信、生成、及び／又は、分配を組織するように機能し、ある場合には外部エンティティとシステムとの通信を実現する。

ある実施例においては、ＩＰＤＴ制御部２０５は、別のモジュール及び／又はデータベースと別個にＩＰＤＴシステムに収納され、別の実施例においては、他のモジュール及び／又はデータベースの幾つかまたは全ては、ＩＰＤＴ制御部に収納され、及び／又はＩＰＤＴ制御部の一部として構成される。ＩＰＤＴ制御部の動作、モジュールおよびデータベースの実施に関しては更に詳細に以下に説明する。

ある実施例においては、ＩＰＤＴ制御部２０５は、一以上のインターフェースコンポーネント、及び／又は、モジュールと結合されてもよい。ある実施例においては、ＩＰＤＴ制御部は、ユーザインターフェース（ＵＩ）２１０、保守インターフェース２１２、及び電源インターフェース２１４に結合される。ユーザインターフェース２１０は、ユーザ入力および表示アプリケーション状態、及び／又は、他の出力を受信するように構成されてもよい。ＵＩは、例えば、ユーザが、ＩＰＤＴシステム設定を調整すること、通信方法及び／又はプロトコルを選択すること、リモートディスプレイモードを開始すること、モバイルデバイスアプリケーションの特徴機能を実行すること、可能なターゲット／クライアントデバイスを識別することなどを可能にする。ある実施例においては、ユーザインターフェース２１０は、キーボード、マウス、スタイラス、タッチスクリーン、デジタルディスプレイなどを含むが、これらには限定されない。ある実施例においては、保守インターフェース２１２は、例えば、定期点検と修理を構成し、システム更新データを受信し、システムの振る舞いを報告するなどしてもよい。ある実施例においては、電源インターフェース２１４は、例えば、ＩＰＤＴ制御部２０５を、組込み電池、及び／又は、外部電源に接続する。

ある実施例においては、ＩＰＤＴ制御部は、デバイスアプリケーションソフトウェアを起動するように構成されたアプリケーションエンジン２６０に更に結合される。ある実施例においては、アプリケーションエンジン２６０は、アプリケーション状態の構成を更新するために、一以上の集積センサから派生したセンサ入力情報を受信し、その情報を解釈する。ある実施例においては、更新アプリケーション状態データは、ディスプレイの実施例に依存してターゲット、クライアント、及び／又は、ソースデバイスに転送される。例えば、アプリケーションエンジンによって起動されたアプリケーションは、動作感知モバイルデバイスを介して制御されるビデオゲームを有し、転送ビデオゲームデータを表示するように構成されたラップトップとの通信チャンネルを確立するのにＩＰＤＴを使用する。

ある実施例においては、ＩＰＤＴ制御部２０５は、センサ入出力（Ｉ／Ｏ）コンポーネント２２５とインターフェース接続し、及び／又は、そこからの信号を処理するように構成されたセンサモジュール２２０に更に結合される。センサＩ／Ｏコンポーネント２２５は、ユーザの操作、環境状況などによって刺激され、センサモジュール２２０、及び／又は、他のＩＰＤＴコンポーネントによって受信、及び／又は、処理される電気信号を生成し、それは次いでアプリケーションによって使用可能な入力制御を生成するように動作する。様々な異なるセンサはＩＰＤＴ動作と互換性があり、動作状態、音量、体積、ピッチ、圧力、風力、温度、データ転送速度、照度、位置、高さ、天気、水分レベル、湿度などを計測するように構成された、トランスデューサ、加速度計、温度計、風力計、湿度計、マイクロホンなどの（但し、これらには限定されない）センサＩ／Ｏコンポーネント２２５と一体であってもよい。ある実施例においては、センサモジュール２２０は、アプリケーションエンジン２６０によって起動されるアプリケーションに適した形態でセンサＩ／Ｏコンポーネント２２５から受信した信号を構成してもよい。別の実施例においては、アプリケーションエンジン２６０は、一以上の起動しているアプリケーションのアプリケーション状態を更新する処理を行うために、センサＩ／Ｏコンポーネント２２５から直接に信号を受信してもよい。例えば、ある実施例においては、ユーザは、（図８の実施例に更に示すように）ゴルフクラブのＩＰＤＴリモート制御デバイス筺体を使用してもよい。ユーザは本当のゴルフクラブをフィールドでスイングするようにリモート制御デバイスをスイングし、センサＩ／Ｏ２２５はクラブの動作信号を検出してセンサモジュール２２０に適した信号（例えば、スイングの速度と方向を示す加速度計からの電気パルスなど）を転送してもよい。センサモジュール２２０は、受信信号を処理及び分析し、移動の特徴、例えば、移動方向、移動速度、移動レベルなどを記述するデータを生成し、そのデータをＩＰＤＴ制御部２０５に転送してもよい。例えば、ある実施例においては、ｉＰｈｏｎｅＳＤＫツールキット、及び／又は、実行時間ライブラリがインストールされ、かかる動作にアクセス及び解釈するのに使用される。

ある実施例においては、ＩＰＤＴ制御部２０５は、通信Ｉ／Ｏコンポーネント２３５とインターフェース接続、及び／又は、そこからの信号を処理するように構成された通信モジュール２３０に更に結合されてもよい。通信Ｉ／Ｏコンポーネント２３５は、通信モジュール２３０と協働、及び／又は、通信モジュール２３０によって、様々な異なる通信プロトコル、及び／又は、フォーマットを介して電子通信の送信を容易にするコンポーネントを含んでもよい。通信Ｉ／Ｏコンポーネント２４０は、例えば、ポート、スロット、アンテナ、増幅器などを含んでもよく、上記方法のいずれかを介して、モバイルデバイスアプリケーション状態の側面の表示内容、及び／又は、表示方法をリモートディスプレイに命令する表示命令の送信を容易にする。

通信モジュール２３０、及び／又は、通信Ｉ／Ｏコンポーネント２３５が互換性を有する通信プロトコル、及び／又は、フォーマットは、ＧＳＭ、ＧＰＲＳ、Ｗ−ＣＤＭＡ、ＣＤＭＡ、ＣＤＭＡ２０００、ＨＳＤＰＡ、イーサネット、ＷｉＦｉ、ブルートゥース、ＵＳＢなどを含んでもよいが、これらには限定されない。様々な実施例において、通信Ｉ／Ｏコンポーネント２３５は、ＦＴＰ、ＴＣＰ／ＩＰ、ＳＭＴＰ、ショートメッセージ・ピア・ツー・ピア（ＳＭＰＰ）などの（但し、これらには限定されない）ネットワーク通信プロトコルに従って、例えば、アプリケーション内のデータ、移転、ネットワーク、メディアアクセスコントロール、及び／又は、物理レイヤーフォーマットを構成するように機能してもよい。通信モジュール２３０と通信Ｉ／Ｏ２３５は、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ＶｏＩＰ及び／又は同様のデータフォーマット及び／又はプロトコルを実施及び／又は翻訳するように更に構成可能である。通信Ｉ／Ｏ２３５は、ＩＰＤＴシステムと共に及び／又はＩＰＤＴシステム内で有線及び／又は無線通信を容易にするために、一以上のポート、ジャック、アンテナなどを更に収納してもよい。例えば、上述の例において、ＩＰＤＴ制御部２０５は、制御デバイスの移動の受信センサデータ特徴を通信モジュール２３０に送信してもよく、そのデータは、その後、通信Ｉ／Ｏ２３５を介して外部エンティティ（ターゲットデバイスなど）に送信されてもよい。

様々なデータ転送プロトコルは、例えば、ＴＣＰ／ＩＰ、及び／又は、ＨＴＴＰポスト、ＦＴＰプットコマンドなどのより高いプロトコルなどのＩＰＤＴ接続として使用されてもよい。ある実施例においては、通信モジュール２３０は、ワールド・ワイド・ウエブに公開されるアプリケーション状態データを構成するウエブ・サーバ・ソフトウエアを有してもよい。公開されたアプリケーション状態データは、ある実施例において、アドビフラッシュなどのマルチメディアプラグインに従って構成されるなど、統合ビデオ、アニメーション、リッチインターネットアプリケーションなどとして表示されてもよい。別の実施例においては、通信モジュール２３０は、リモートクライアント上の閲覧のためのアプリケーション状態データを構成するように装備される、Ｃｉｔｒｉｘ、バーチャル・ネットワーク・コンピューティング（ＶＮＣ）などのリモート・アクセス・ソフトウェアなどを有してもよい。

ある実施例においては、ＩＰＤＴ制御部２０５は、ＩＰＤＴデータを格納及び維持するように構成された複数のデータベースに更に結合される。アプリケーションデータベース２４０は、アプリケーションデータ、ユーザＩＤ、設定、構成、保存ゲーム、ゲーム状態、アプリケーションインターフェース要素などを含んでもよい。プロトコルデータベース２４５は、ワールド・ワイド・ウエブ上の公開に適する通信プロトコル、及び／又は、データ構成に関連し、リモート・アクセス・ソフトウェア設定などにおいてクライアントデバイスとサーバデバイスの間で共有するデータを含んでもよい。ユーザデータベース２５０は、ユーザ、アプリケーション履歴、システム構成などに関連する、アカウント情報、連絡情報、プロフィール情報、ハードウェアデバイスの識別、顧客構内設備（ＣＰＥ）などに関する情報を含んでもよい。ハードウェアデータベース２４５は、例えば、ユーザデバイス、ディスプレイデバイス、ターゲットデバイス、電子メールサーバ、ユーザ電話デバイス、ＣＰＥ、ゲートウエイ、ルータ、ユーザ端末など（但し、これらには限定されない）ＩＰＤＴシステムが通信するハードウェアデバイスに関する情報を含んでもよい。ハードウェアデータベース２２８は、様々なＩＰＤＴ関連エンティティのいずれかに使用されるハードウェアデバイスと通信するのに適した通信プロトコル、データフォーマットなどを特定する。

ある実施例においては、ＩＰＤＴデータベースは、アレイ、ハッシュ（リンクされた）リスト、ストラクト、構成テキストファイル（例えば、ＸＭＬ）、テーブルなど様々な基準データ構成を使用して具現化可能である。例えば、ある実施例においては、ユーザデータベース２５０のユーザプロフィールに対するＸＭＬは、以下の例に類似する形態を採ってもよい。
<User>
< Quasi-static info>
<User_ID>123-45-6789</User_ID>
<Hardware ID>SDASFK45632_iPhone 3.0 </Hardware ID>
<Census info>John Smith; 123 Maple Dr., Smalltown, CA 92676; (123)456-7890; jsmith@email.com; 55 years; male; white; married; 2 children; etc.
</Census info>
...
</Quasi-static info>
<Dynamic info>
<Application history>
<Last login >
<Server ID>US-CA-ADD00089</Server ID>
<Time> 19:33:25 08-30-2009 </Time>
...
</Last login>
...
</Application history>
</Dynamic info>
</User>
図３Ａは、ＩＰＤＴ動作の実施例におけるインターラクティブなリモートディスプレイのテザー機能の側面を示す論理フロー図である。ある実施例においては、リモートディスプレイのテザーを希望するユーザは、ＩＰＤＴコンポーネントで実施されるアプリケーションを使用する。ある実施例においては、ＩＰＤＴコンポーネントは、ソフトウェア開発キット（ＳＤＫ）、及び／又は、ＩＰＤＴが有益なアプリケーションに含まれるオブジェクトライブラリとして具現化される。ある実施例においては、ＩＰＤＴコンポーネントを組み込むどんなプログラムも、ソースデバイスで利用可能及び／又はソースデバイスにダウンロードおよびインストールが可能であり、そこでユーザがＩＰＤＴアプリケーションを起動する選択肢を有し３００、ユーザがＩＰＤＴアプリケーションを初期化する要求を提出することができる３０２。例えば、ある実施例においては、ユーザは、ｉＰｈｏｎｅのメニューからＩＰＤＴアイコンを選択することによってＩＰＤＴモバイルデバイスからの「リモートゲームコントロール」アプリケーションを初期化し、図３Ｄの画面３７０の実施例で示すように、ＩＰＤＴゲーミングアプリケーションを入力することができる。一旦アプリケーションが選択されてそのインスタンスの作成を開始し、ソースデバイスが通信チャネルの全てを介して適切なテザーデバイスを検索すると、ＩＰＤＴコンポーネントは、図３Ｄの画面３７２の実施例で示すように、テザーターゲットをクエリしてもよい３１０。ある実施例においては、ＩＰＤＴコンポーネントは、ハードウェアデータベースのソースデバイス通信スタックにおける登録デバイス及び／又は通信チャネルに基づいて、及び／又は、ゼロ構成プロトコルに基づいて、及び／又は、ユーザが提出したターゲット情報に基づいて、図３Ｂに更に示すように、ローカル・エリア・ネットワーク内で利用可能なターゲットデバイスを検索してもよい。

ある実施例においては、ソースデバイスは、図３Ｄの画面３７３の実施例に示すように、ユーザが選択をする３３５潜在的テザーターゲットのリストをユーザに提供することができる３３０。ターゲットデバイスを選択する際に、ソースデバイスは、図３Ｄの画面３７５と３７８の実施例に示すように、そして、図３Ｃに更に示すように、テザーターゲット３４０の種類に基づいて、選択されたテザーターゲットに接続してもよい。一旦ＩＰＤＴが確立されると、ＩＰＤＴは、ＩＰＤＴを容易にするために追加クライアントを組み込もうとする３６５。さもなければ、ソースデバイスとターゲットデバイスは（図３Ｄの画面３８０の実施例に示すように）ＩＰＤＴで処理してもよい３６７。この種のＩＰＤＴは図５Ａ−５Ｄの例で後述するように、共同プレイＩＰＤＴを容易にするように拡張されてもよく、ターゲットデバイスが、例示された共同プレイＩＰＤＴの実施例に対してサーバの責任を負う。

図３ＢはＩＰＤＴ動作の実施例においてテザーターゲットのクエリの側面を示している。ある実施例においては、ユーザがターゲットデバイスの表示を提出すると３１５、ＩＰＤＴは、ユーザが提出した情報に基づいてターゲットデバイスを検索する３１６。例えば、ある実施例においては、ユーザは、モバイルデバイスを介してターゲットデバイスの既知のＩＰアドレス、ＭＡＣアドレス、頭字語、ハードウェアラベル、デジタル署名、ドライバ証明書、ゼロ構成情報などを入力し、モバイルデバイスは対応する表示に対してローカル・エリア・ネットワークの利用可能な範囲内で検索してもよい。ユーザが提出した表示がなければ、ＩＰＤＴは、ハードウェアデータベースに通信スタックをクエリするかどうかを決定してもよい３１８。例えば、ある実施例においては、ＩＰＤＴは、ユーザにメッセージを表示してユーザからデータベースにクエリするかどうかを決定するための指示を受けることができる。そうであれば、ＩＰＤＴは、ソースデバイスと互換性がある登録されたデバイス／通信チャネルに対して通信スタックでクエリを形成してもよい３２０。そうでなければ、ＩＰＤＴは、例えば、サービスロケーションプロトコル（ＳＬＰ）、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）、ジニ、ブルートゥースサービスディスカバリープロトコル、ＷＳ−ディスカバリー、ＵＤＰやボンジュールなどを使用するプロプラエタリディスカバリープロトコルなどの（但し、これらには限定されない）ゼロ構成プロトコルによってローカル・エリア・ネットワークの範囲内で適当なターゲットデバイスを突き止める検索を開始してもよい３２２。

ある実施例においては、テザーターゲットデバイスは、ゼロ構成ネットワークを介してその利用可能性を提供してサーバに公開し、例えば、アップルＳＤＫはボンジュールサービスを作成することができる。例えば、ある実施例においては、サービスを作成してテザーターゲットを公開するボンジュールに基づくＣ＋＋実装は、以下と同様の形態を採ることができる。
//Creating the Bonjour Service

CFNetService netService=CFNetServiceCreate(NULL, CFSTR(""), type, name, port);
...

//Publishing the Server

void init (CFNetServiceRef netService)
{
CFStreamError error; CFNetServiceClientContext context = { o, NULL, NULL, NULL, NULL };

CFNetServiceSetClient(netService, registerCallback, &context);
CFNetServiceScheduleWithRunLoop(netService, CFRunLoopGetCurrent(),
kCFRunLoopCommonModes);
CFNetServiceRegister(netService, NULL);
if (CFNetServiceRegister(netService, &error) == false) {
CFNetServiceUnscheduleFromRunLoop(netService,
CFRunLoopGetCurrent(),kCFRunLoopCommonModes);
CFNetServiceSetClient(netService, NULL, NULL);
CFRelease(netService);
}
}
...
別の実施例に対し、テザーターゲットとしてサービスを作成してサービス情報を提供するＵＤＰを使用するプロプラエタリディスカバリープロトコルに基づくＣ／Ｃ＋＋実装は、は、以下と同様の形態を採ることができる。
//Broadcast Service Information
...
SOCKET sock;
sock = socket(AF_INET,SOCK_DGRAM,o);

char broadcast = '1';

int sres =
setsockopt(sock,SOL_SOCKET,SO_BROADCAST,&broadcast,sizeof(broadcast))

if (sres < o)
{
closesocket(sock);
return o;
}
struct sockaddr_in recv;

int len = sizeof( struct sockaddr_in);
char msg[] ="IPDT PC V1.01";
recv.sin_family = AF_INET;
recv.sin_port = htons(MYPORT);
recv.sin_addr.s_addr = INADDR_BROADCAST;

sendto(sock,sendMSG,strlen(msg)+i,o,(sockaddr *)&recv,sizeof(recv));
...
ある実施例においては、かかるクエリがヌル結果を返すと３１５、ＩＰＤＴは検索が失敗であることを示すメッセージをユーザに表示し、ユーザの要求があると３１０を続ける。クエリが少なくとも１つの結果を返すと３１５、ＩＰＤＴは、利用可能なターゲットデバイスのリスト３２５を生成して３３０を続ける。

図３Ｃは、ＩＰＤＴ動作の実施例のテザーターゲットとの接続の側面を示している。ＩＰＤＴは、ターゲットが物理的テザーであるかどうかを決定する３４２。例えば、大型テレビに直接に差し込まれるドックコネクタケーブルへのｉＰｈｏｎｅビデオＡＶなどの直接的なオーディオ／ビデオ接続で、物理的テザー３４２を介してターゲットデバイスが接続されている場合、ＩＰＤＴアプリケーションは、物理的テザーを介してより大型のディスプレイデバイスにソースデバイス３４４の表示に関連付けられたデータの通信を開始し、アプリケーションはより大型のディスプレイを最大限に利用し続ける３４９。代替的な実施例においては、物理的テザーは、ＷｉＦｉを介して接続されるＷｉＦｉＹＷ−２アダプターを有するカシオＸＪ−Ｓ５７である。ある実施例においては、ソースデバイスは、例えば、コンポーネントＶｉｄｅｏＳ−Ｖｉｄｅｏ、ＨＤＭＩ、ＶＧＡ、ＤＶＩ、ＤｉｓｐｌａｙＰｏｒｔなどの（但し、これらに限定されない）様々なフォーマットで物理的テザーを介してデータをターゲットデバイスに送信する。

ある実施例においては、ターゲットが物理的テザーでなければ３４２、ＩＰＤＴはターゲットがプロセッサベースのデバイス／エンティティであるかどうか決定する３５０。そうでなければ、テザーが失敗であることを示すメッセージをユーザに表示し、ＩＰＤＴはユーザの要求の際に３３０で処理を行ってもよい。ある実施例においては、リモートデバイスがプロセッサベースのデバイスであれば３５０、ソースデバイスは、ターゲットデバイスがリモートデバイスとして補足的アプリケーションコードを実行することができるかどうかを認識してもよい。例えば、リモートデバイスが分散オブジェクト指向アプリケーションを起動しているかどうか３５１、リモートデバイスがウエブサーバを起動しているかどうか３５２、リモートデバイスが（例えば、ｃｉｔｒｉｘ、ＶＮＣなど）リモートディスプレイクライアント３５３またはウエブブラウザ３５４を起動しているかどうかである。既に説明したように、デバイスは（例えば、ボンジュール、ＳＬＰ、ＵＰｎＰ、ジニ、ブルートゥースサービスディスカバリープロトコル、ＷＳ−ディスカバリー、ＵＤＰを使用するプロプラエタリディスカバリープロトコルなどの）ゼロ構成プロトコルに基づいてブロードキャストしている場合またはプロプラエタリ通信要求に応答している場合、テザーターゲットはプロセッサベースである。

ある実施例においては、ターゲットコンピュータがウエブブラウザを起動している場合３５４、ソースデバイスはウエブサーバを起動する。例えば、ソースデバイスがＵＮＩＸを実行するｉＰｈｏｎｅである場合、アパッチ情報サーバはＩＰＤＴコンポーネントの一部であり、その情報サーバのインスタンスが作成されてもよい。その点で、ソースデバイスは、ボンジュールなどのゼロ構成ネットワークプロトコルを介してＩＰアドレスを提供及び／又はそれ自体を登録することができ、ユーザはソースデバイス上でウエブサーバへナビゲートするのにターゲットマシン上のウエブブラウザを使用してもよい。ある実施例においては、ｉＰｈｏｎｅはソースデバイスであり、アパッチウエブサーバを起動し、ターゲットデバイス（例えば、ラップトップ）のユーザはＷｉＦｉ接続でｉＰｈｏｎｅ上のウエブサーバのＩＰアドレスへナビゲートする。この点で、カスタム通信チャネルはソースデバイスとターゲットデバイスの間で確立され３４７、ソースデバイスは、リモートターゲットのインスタンスを作成するために、例えば、ターゲットウエブブラウザが実行可能なアプリケーションを提供するために３４８、そのウエブサーバを介して命令を与える。この点で、ソースアプリケーションは、ＩＰＤＴアプリケーションを使用し３４９、そのソースディスプレイをリモートディスプレイに与える経路としてカスタムアプリケーションチャンネルを使用してもよい。例えば、ソースデバイスウエブサーバは、ターゲットデバイスにリモートディスプレイ閲覧能力を与えるＪａｖａ及び／又はフラッシュアプレットを有してもよい。別の実施例として、ＴｉｇｈｔＶＮＣ・Ｊａｖａビューア・アプレットは、ターゲットウエブブラウザによってリモートｉＰｈｏｎｅアパッチウエブサーバからダウンロードされ、（例えば、ＩＰアドレス、設定ユーザ／パスワード鍵などの）構成でインスタンス作成され、ソースデバイスに接続されたＶＮＣサーバに接続する。このようにして、ターゲットデバイスウエブブラウザはソースデバイスのためのリモートディスプレイになる。ある実施例においては、ソースデバイスウエブサーバは、ターゲットデバイスウエブブラウザにそのウインドウを画面のフルサイズまで広げるように命令してもよく、その結果、ソースデバイスで表示を映しながら拡大閲覧領域を提供する。

ある実施例においては、ターゲットデバイスが、ボンジュールなどを介して接続可能なビジュアル・ネットワーク・コンピューティング（ＶＮＣ）、アップルのリモートディスプレイ技術などのリモートデスクトップ共有コンポーネントを既に有する場合３５３、ユーザは（例えば、ＩＰアドレス、ユーザ／パスワード、オペレーティングシステムの適切な領域にアクセスするヘルプなど）ターゲットデバイスに何を入力するかを命令する画面で接続終了し、カスタム通信チャネルを構成するように促される３４７。ある実施例においては、ソースデバイスは、アップルＯＳ・Ｘファインダーアプリケーションの共有領域において閲覧可能となり、画面共有のために選択されるＩＰＤＴコンポーネントの一部としてＶＮＣサーバを接続し、それによって、ソースデバイスのディスプレイをターゲットに投射するためにリモートターゲットのインスタンスを作成する３４８。この点で、ＩＰＤＴアプリケーションは、３４９を実行し続けることができる。例えば、ある実施例において、ボンジュールに基づくサービスに接続するｉＰｈｏｎｅのためのＣ＋＋実装は、以下と同様の形態を採ることができる。

// Connecting to a Service

NSNetService *service;
NSInputStream *istream = nil;
NSOutputStream *ostream = nil;

[service getInputStream:&istream outputStream:&ostream];
if (istream && ostream)
{

// ...

}
ある実施例においては、ターゲットデバイスが、ソースデバイス３５２と通信するように構成されたカスタムアプリケーション３５１、及び／又は、ウエブサーバのどちらかを起動している場合は、ソースデバイスには、それが交信可能な幾つかのチャネルを有する。分散オブジェクト指向アプリケーションの場合には、接続を確立するためにオブジェクト指向方法発呼がターゲットアプリケーションに送信されてもよい。これらのカスタムアプリケーションは、上述したように、同様のリモートディスプレイ技術を使用してもよい。別の実施例においては、ソースアプリケーションが、ＯｐｅｎＧＬ、フラッシュ、及び／又は、アップルのＯＳ・Ｘ開発ＳＤＫなどのグラフィックス作成エンジンを使用し、かかるグラフィックスライブラリスケールがデバイス表示能力に依存し、ソースデバイスが入力装置として使用され、ターゲットデバイスはソースデバイスに保存されたＩＰＤＴアプリケーションのよりロバストなバージョンを起動できる。

多くの方法でＩＰＤＴアプリケーションのよりロバストなバージョンがターゲットデバイスに提供可能である。ある実施例においては、ＩＰＤＴソースアプリケーションは、アプリケーションの多数のバージョンを有するディレクトリを有し、より精巧なバージョンをターゲットデバイスに転送する。別の実施例においては、ＩＰＤＴソースアプリケーションは、ウエブリンクを有し、ターゲットデバイスに自動的により精巧なアプレット、及び／又は、アプリケーションをダウンロードさせ、それをインストールさせてインスタンスを作成させる。ＩＰＤＴアプリケーションのターゲットバージョンのインスタンスの作成に際して、ソースＩＰＤＴアプリケーションは、通信チャネル３４７を介して送信されるユーザ入力信号だけをインスタンス作成されたリモートターゲットに提供し、リモートアプリケーションがそれらの命令を解釈してよりロバストな方法でアプリケーションを実行する３４８。例えば、制御部としてｉＰｈｏｎｅを使用する（例えば、ｉＧｏｌｆの）ゲームはターゲットのラップトップにロードされたよりロバストなバージョンのｉＧｏｌｆを有し、ｉＰｈｏｎｅソースデバイスの加速度計入力を使用してターゲットデバイスのゲームの実行を指示する。

図３Ｄ−３Ｆは、ＩＰＤＴ動作においてＩＰＤＴゲーミングアプリケーションの側面を示す、アップルｉＰｈｏｎｅからのスクリーンショットの例である。図３Ｄでは、ユーザは、ＩＰＤＴゲーミングアプリケーション３７０を実行するオプションが提供され、「対戦」を選択すると、ユーザはゲーミング接続オプションのリストを提供される３７２。ある実施例においては、ユーザは「ブルートゥース」を選択すると、ＩＰＤＴはＷｉＦｉ３７３を介して別のｉＰｈｏｎｅまたは他のテザーターゲットデバイスを検索し、利用可能なテザーターゲットのリストをユーザに提供する３７５。ユーザはその後テザーターゲットを選択し３７８、そのテザーターゲットに接続する３８０。（別のｉＰｈｏｎｅの場合に）テザーターゲットへの接続を確立すると、ＩＰＤＴアプリケーションはソースデバイスとテザーターゲットの両方に使用されてもよい３８２と３８３。ある実施例においては、ＩＰＤＴアプリケーションは、３８３に示し、図５Ａ−５Ｄと開示を通じて更に詳細に説明されるように、２人以上のユーザがゲームを共同プレイすることを容易にする。

ある実施例においては、図３Ｅに示すように、ユーザが「対戦」メニュー３７２の「ロビーリスト」を選択すると、ＩＰＤＴはゲーミングホストサーバ３７４の利用可能な「ロビー」リストを提供する。ユーザがロビーを選択する際に、ＩＰＤＴはホストサーバ３７６／３７８に接続してユーザデバイス３８２／３８３にテレビゲームをロードする。別の実施例においては、図３Ｆに示すように、ユーザが３７０で「マーケット」を選択すると、ＩＰＤＴアプリケーションは販売用のゲーミング特徴機能を提供してもよい３８６。別の実施例においては、ユーザが３７０で「ソーシャル」を選択する場合には、ＩＰＤＴアプリケーションは、ユーザのゲームミングフィードを公開するオプションを（例えば、Ｆａｃｅｂｏｏｋなどを通じて）提供してもよい３８８。

ある実施例においては、ＩＰＤＴアプリケーションが使用されている場合、ソースデバイスは様々なデータ形式でターゲットデバイスに制御情報とデータペイロードを送信する。図４は、ＩＰＤＴ動作の実施例においてソースデバイスからターゲットデバイスに送信されるデータ形式の例を示している。ある実施例においては、ソースデバイスは、メッセージの種類４０５、シーケンス番号４０６、承認番号４０７、データオフセット４０８、データ長４０９、チェックサム４１０、オプション４１１、データペイロード４１２などのフィールドを含むバイナリーデータパケット４０２を通じてプロセッサベースのターゲットデバイスにデータを送信してもよい。データ４１２は、加速度計情報、（画面を押す）ポインタの座標、画像、ＧＰＳ情報、ユーザ情報などを含むが、これらには限定されない。例えば、ある実施例においては、データ４１２は、ユーザＩＤ、デバイスＩＤなどを含む６４バイトのユーザ情報フィールド、三次元座標（ｘ、ｙ、ｚ）、６４バイトの緯度／経度値、６４バイトのポインタ座標値（ｘ、ｙ）、３２バイトの画像の長さの値を含む９６バイトの加速度計情報、および、画像の生データやビデオ時間情報などの可変長を有するデータに類似する形態を採ることができる。ある実施例においては、画像の生データは、ＶＮＣビデオ伝送データフォーマット、及び／又は、ＶＮＣビデオ伝送データストリームを分離するポインタに従って生成および送信される。ある実施例においては、ポインタは、ファイルシステムの.vncファイルへ示し、ホスト、ポート、パスワード、オプション（例えば、ビット深さ、マウス設定、スケール、エミュレーション、クリップボードなど）、およびセッションなどのエクステンションを特定するように当該ファイルのコンテンツを組み込む。ある実施例においては、リモート・フレームバッファ・プロトコル（ＲＦＢ）が使用され、それは、ここで参照されて共に明示的に結合される、リモート・フレームバッファ・プロトコル、トリスタン・リチャードソン（ＲｅａｌＶＮＣ社）、２００９年１０月２６日、＜http://www.realvnc.com/docs/rfbproto.pdf.＞およびディスプレイ・フィルタ・レファレンスにおけるバーチャル・ネットワーク・コンピューティング＜http://www.wiresshark.org/docs/dfref/v/vnc.html.＞において見ることができる。

別の実施例においては、ソースデバイスとターゲットデバイスは、コモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ（ＣＯＲＢＡ４２０）機構を介してデータを交換する。例えば、ソースデバイスとターゲットデバイスは一連のオブジェクトを定義し、これらは、加速度計の状態、デバイス位置の情報を含むＧＰＳ、画面におけるユーザインタラクションの情報を含むポインタ、スクリーンストリームを含む画面、及び／又は、データストリームと所与のアプリケーションに関する構造を含む他のデータ構造に関する情報であるが、これらには限定されない。ある実施例においては、ソース／クライアントデバイス４２２は、オブジェクトレファレンス４２５、オブジェクト要求ブローカー４２９を起動する生成スタブコード４２７とインターフェース接続し、ネットワーク接続４３０を介してターゲットデバイス４４５と通信する。ターゲットデバイスは、オブジェクト実装４４０、ターゲットデバイス側オブジェクト要求ブローカー４３５を起動する生成スケルトンコード４３７を含むことができる。例えば、ある実施例においては、ＣＯＲＢＡの下でデータオブジェクトを定義するＣ＋＋実装は以下と同様の形態を採ることができる。
//Define Accelerometer Data Object

class AccelerometerDataService : public PortableServer::RefCountServantBase
{
public:
AccelerometerDataService();
virtual -AccelerometerDataService();
virtual CORBA: :Boolean Update( CORBA: :Long x,
CORBA: :Longy,
CORBA: :Longz);
};

...
CORBA:: Boolean AccelerometerDataServicexUpdate (
CORBA:: Long x,
CORBA: :Long y,
CORBA: :Long z)
{

return true;
}
ある実施例においては、ＣＯＲＢＡの下でサーバに接続するＣ＋＋実装は以下と同様の形態を採ることができる。

//Connecting to the Server
...
CORBA_ORB_var orb=CORBA_ORB_init(argc, argv);
const char* refFile="AccelerometerDataService.ref ';
if stream in;
in.open(refFile);
CORBA_Object_var obj=orb->string_to_object(s);

AccelerometerDataServiceads = AccelerometerDataService::_narrow(obj);
ads->update(x,y,z);
...
図５Ａは、ソースデバイス５５０が通信ネットワーク５５５でターゲットデバイス５５１と通信路を確立する共同プレイを有するインターラクティブなプロキシミティディスプレイのテザー（以下、「共同プレイＩＰＤＴ」）の実施例を示している。ある実施例においては、ターゲットデバイス３５１は、ケーブル５５７を介してディスプレイデバイス５５３に接続され、ターゲットディスプレイデータをディスプレイデバイスに送るように構成されている。さもなければ、ターゲットデバイス５５１はターゲットのディスプレイで、または、デュアルモニタ実装としてディスプレイデバイス５５３と組み合わせて共同プレイＩＰＤＴデータを表示してもよい。

ある実施例においては、ターゲット５５１の処理能力に依存して、ソースデバイス５５０は、共同プレイＩＰＤＴのためのクライアントの機能性を容易にする表示用データをターゲットデバイス５５１に送信しながら通信／処理を実行するサーバの機能性を駆動することができる。代わりに、ソースデバイス５５０は、ターゲットデバイス５５１にデータ処理機能を負担させ、サーバの機能性を容易にしてもよい。この場合、ソースデバイス５５０はクライアントの機能性を容易にするだろうが、ターゲットデバイス５５１は共同プレイＩＰＤＴのためにサーバの機能性を容易にするだろう。

ある実施例においては、第２のモバイルデバイス‐クライアントデバイス５５２は、共同プレイＩＰＤＴに組み込まれる。ある実施例においては、クライアントデバイス５５２の通信路が、ソースデバイス５５０と通信ネットワーク５５６で確立される。一旦通信路が確立されると、クライアントデバイスは、デバイスのユーザ操作を検知してＩＰＤＴでソースデバイス５５０にデータを送信するように構成されてもよい。ソースデバイス５５０がサーバの機能性を容易にしている場合、ソースデバイス５５０は、クライアントデバイス５５２からのデータを処理し、表示用にターゲットデバイス５５１に転送してもよい。一方、ソースデバイス５５０がクライアントの機能性を容易にしてターゲットデバイス５５１がサーバの機能性を容易にしている場合、ソースデバイス５５０は、クライアントデバイス５５２からユーザ操作データを中継する経路として単純に動作する。ある実施例においては、共同プレイＩＰＤＴは、クライアントデバイス５５２とソースデバイスは、ターゲットデバイス５５１またはディスプレイデバイス５５３によって表示されるパーシステントプラットホームゲームプレイと相互作用することを容易にするように構成される。例えば、ある実施例においては、各デバイス５５０と５５２とのユーザインタラクションは、それぞれ第１及び第２のアバター５５８と５５９によって表された、ｉＧｏｌｆゲームにおいてリアルタイムで表示される。

図５Ｂは共同プレイＩＰＤＴの別の実施例を示している。ある実施例においては、ソースデバイス５６０とターゲットデバイス５６１は、通信ネットワーク５６５で通信路を確立する。ソースデバイス５６０とターゲットデバイス５６１も、どちらのデバイスがサーバの機能性を容易にし、どちらのデバイスが上述したようにサーバの機能性を容易にするのかを交渉する。しかしながら、ソースデバイス５６０を通じて通信路を確立して共同プレイＩＰＤＴと通信するクライアントデバイス５６２の代わりに、ソース／ターゲットデバイスのクライアント／サーバの機能性が確立された後で、クライアントデバイス５６２が通信ネットワーク３６６でターゲットデバイス５６１を通じて通信路を確立して共同プレイＩＰＤＴと通信する。そこで、図５Ｂの共同プレイＩＰＤＴは、クライアントデバイス５６２とソースデバイスが、ターゲットデバイス５６１またはディスプレイデバイス５６３によって表示されるパーシステントプラットホームゲームプレイで相互作用することを容易にする。例えば、各デバイス５６０と５６２とのユーザインタラクションは、それぞれ第１及び第２のアバター５６８と５６９で表された、ｉＧｏｌｆゲームにおいてリアルタイムで表示されてもよい。

図５Ｃは共同プレイＩＰＤＴの代替的な実施例を示している。ソースデバイス５７０とターゲットデバイス５７１は、上述したように、通信ネットワーク５７４でサーバ／クライアントの機能性を確立する。しかしながら、クライアントデバイス５７２−Ａは、通信ネットワーク５７６でクライアントデバイス５７２−Ｂと最初に接続することによって共同プレイＩＰＤＴに参加し、クライアントデバイス５７２−Ｂが次に共同プレイＩＰＤＴを達成するためにターゲットデバイス３７１に参加してもよい。ある実施例においては、ターゲットデバイス５７１がサーバの機能性を容易にし、それにより、ソースデバイス５７０とクライアントデバイス５７２−Ａ／５７２−Ｂからのユーザ入力の処理を駆動する。一旦クライアントデバイスデータがターゲットデバイス５７１によって処理されると、ターゲットデバイス５７１は、そのディスプレイで及び／又はテザーされたディスプレイ５７４Ａを介して、パーシステントプラットホームゲームプレイを表示してもよい。ある場合には、ターゲットデバイス５７１は、クライアントデバイス５７２Ｂまたはテザーされたディスプレイ５７３Ｂにおける表示用に表示データをクライアントデバイス５７２Ｂに返送してもよい。例えば、各デバイス５７０と５７２Ａとのユーザインタラクションは、第１と第２のアバター５７８と５７９によって表される、ｉＧｏｌｆゲームにおいてリアルタイムでディスプレイ５７３−Ａ／５７３Ｂにパーシステントプラットホームゲームプレイとして表示されてもよい。

図５Ｄは、図５Ｃに示す実施例と類似の共同プレイＩＰＤＴの別の実施例を示している。ある実施例においては、ターゲットデバイス５８１は、サーバの機能性の代わりにクライアントの機能性を容易にし、本実施例においてソースデバイス５８０によって容易にされる。そのため、ソースデバイス５８０は、クライアントデバイス５８２Ｂと５８１を通じて通信される通信ネットワーク５８４、５８５および５８６を介してクライアントデバイス５８２Ａと同様に、ソースデバイス５８０からユーザインタラクションデータを受信および処理する。一旦受信すると、ソースデバイス５８０は、ユーザインタラクションデータを処理して処理済のユーザインタラクションデータをターゲット５８１とクライアント５８２Ｂに表示用に返信する。例えば、各デバイス５８０と５８２Ａとのユーザインタラクションは、第１と第２のアバター５７８と５７９によって表される、ｉＧｏｌｆゲームにおいてリアルタイムで、パーシステントプラットホームゲームプレイとしてディスプレイ５８３−Ａ及び／又は５８３Ｂに表示されてもよい。

図６Ａは、共同プレイＩＰＤＴ動作のある実施例における論理フロー全体の実施例を示している。図示された論理フローは、利用可能なクライアントデバイスと同様に、モバイルソースデバイスをリモートディスプレイとしてのターゲットデバイスに結合するのにＣｉｔｒｉｘまたはＶＮＣなどのリモート・アクセス・ソフトウェアを使用する共同プレイＩＰＤＴの実施例に関する。ユーザは、モバイルデバイスをつけることやアプリケーションアイコンを選択することなどしてモバイルソースデバイスアプリケーション６０１を使用してもよい。ある実施例においては、アプリケーションとリモート・アクセス・ソフトウェアの両方がモバイルソースデバイスで使用される。リモートディスプレイターゲットデバイスのアプリケーションは、モバイルデバイスをつけることやアプリケーション（例えば、リモート・アクセス・ソフトウェア）を選択することなどによっても使用可能となる６０４。モバイルソースデバイス及び／又はリモートディスプレイターゲットデバイスは、例えば、相手をピングすることによって６０７、相手デバイスへのデータリンクをチェックしてもよいし、データリンクが確立されたかどうかについて決定がなされてもよい６１０。そうでなければ、モバイルソースデバイス、及び／又は、リモートディスプレイターゲットデバイスは、例えば、ネットワーク接続を修理及び／又はリフレッシュすること、ユーザインターフェースを介してエラーメッセージを提供すること、ユーザに通信コンポーネントをチェックすることを要求することによってなどを行うことによって６１３、データリンクの確立を再試行してもよい。

一旦ソースデバイスとターゲットが実行可能な通信路を確立すると、共同プレイＩＰＤＴは追加のクライアントデバイスが共同プレイＩＰＤＴ６１６組み込み用に利用可能であるかどうかチェックしてもよい。そうであれば、通信路が確立される６０７−６１０。そうでなければ、センサコンポーネントは、モバイルソースデバイスのアプリケーション構成６２２にユーザインタラクション更新をもたらすセンサ入力６１９を受信してもよい。例えば、ある実施例においては、センサ入力は、加速度計によって検出可能な動き状態を含んでもよい。この動き状態は、ビデオゲームなどのモバイルデバイスアプリケーションのコンテクストでアバターまたは他の仮想エンティティの仮想的な動き状態に翻訳されてもよい。送信期間が終了したかどうかについて決定がなされてもよい６２５。そうでなければ、ユーザのソース／クライアントデバイスは、期間を待機して６２８、新しい入力がセンサ６３１から受信されたかどうかをチェックする。そうであれば、ユーザデバイスは、センサ入力、及び／又は、対応する最新のアプリケーション構成を表示信号キャッシュ６３４に追加して新しいセンサ入力６１９を受信処理してもよい。そうでなければ、ユーザのソース／クライアントデバイスが６２５に戻って、送信期間が終了したかどうかをチェックしてもよい。一旦送信期間が終了するとユーザのソース／クライアントデバイスは、現在、及び／又は、最新のアプリケーション状態６３８に対応する表示信号メッセージを構成する。例えば、ある実施例においては、表示信号は、現在、及び／又は、最新の位置、及び／又は、ビデオゲームにおけるアバターの動き状態を表してもよい。

ソースデバイスがサーバの機能性を容易にする実施例においては、ユーザのソース／クライアントデバイスはＣｉｔｒｉｘ、ＶＮＣなどのソースデバイスでリモート・アクセス・ソフトウェアを更新し６４１、対応する表示信号をリモートディスプレイターゲットデバイスに送信してもよい６４４。ターゲットデバイス６４４のリモートディスプレイは、次いで、ディスプレイの画面６４７などのように表示信号のビジュアライゼーションを与えてもよい。共同プレイＩＰＤＴ動作６５０を続行するかどうかに関して決定がなされてもよい。そうであれば、ユーザのソース／クライアントデバイスは、更なるセンサ入力６１９を受信する。さもなければ、共同プレイＩＰＤＴが完了する６５３。

図６Ｂは、共同プレイＩＰＤＴ動作の別の実施例における論理フロー全体の実施例を示している。図６Ｂに示す論理フローは、例えば、モバイルデバイスアプリケーションデータをインターネットに接続されたターゲットデバイスによる検索に供するためにウエブサイトに公開することによって、モバイルソースデバイスをリモートディスプレイターゲットデバイスと結合するのにウエブサーバーソフトウェアを使用するユーザのソース／クライアントデバイスの実施例に関する。ユーザは、例えば、モバイルソース／クライアントデバイスをつけること、アプリケーションアイコンを選択することなどによって、ユーザのソース／クライアントデバイスアプリケーション６５６を使用してもよい。ある実施例においては、アプリケーションとウエブサーバーソフトウェアの両方がモバイルデバイスで使用されてもよい。ユーザのソース／クライアントデバイスのセンサコンポーネントは、モバイルデバイスアプリケーション構成６６２に更新をもたらすセンサ入力６５９を受信してもよい。ＨＴＴＰ要求などのウエブクライアントデータ要求が受信されたかどうかについて決定がでなされてもよい６６５。そうでなければ、ユーザのソース／クライアントデバイスは、期間を待機して６６８、新しい入力がセンサから受信されたかどうかをチェックしてもよい６７２。そうであれば、次に、ユーザのソース／クライアントデバイスは、最新のセンサ入力及び／又は対応するアプリケーション構成を表示信号キャッシュに追加して６７５、新しいセンサ入力を受信処理してもよい６５９。さもなければ、ユーザのソース／クライアントデバイスは、ウエブクライアントデータ要求が受信されたかどうかをチェックするために、６６５に戻ってもよい。代替的実施例においては、ウエブクライアントデータ要求が受信されたかどうかに拘らず、ユーザのソース／クライアントデバイスは表示信号をターゲットデバイスに送信してもよい。この実施例においては、ユーザのソース／クライアントデバイスは表示信号を中間記憶部に送信してもよい。記憶部は、その後、ウエブクライアントデータ要求の受信を監視したり、一以上の現在または過去の表示信号を、データ要求を提供するウエブクライアントに提供したりしてもよい。

一旦ウエブクライアントデータ要求が受信されると、ユーザのソース／クライアントデバイスは、現在及び／又は最新のアプリケーション状態６７８に対応する表示信号メッセージを構成してもよい。構成された表示信号は、ウエブサーバーソフトウェア６８１を介してワールド・ワイド・ウエブ上で公開されてもよい。公開アプリケーション状態コンテンツは、例えば、アプリケーション状態データがホストされる６８４のウエブサイトにアクセスすることによって、一以上のリモートディスプレイターゲットデバイスによってアクセスされてもよい。ある実施例においては、アプリケーション状態データは、アドビフラッシュなどのマルチメディアプラグインに従って構成された、統合ビデオ、アニメーション、リッチインターネットアプリケーションなどとしてウエブサイトに表現されてもよい。リモートディスプレイにアプリケーション状態の表示を更新するかどうかについて６８７で決定がなされてもよい。そうであれば、追加のセンサ入力が６５９で受信される。そうでなければ、共同プレイＩＰＤＴセッションは終了する６９０。

図７Ａは、共同プレイＩＰＤＴの支払いモデルを示すブロック図である。ある実施例においては、中央サービス７０５は購読７１０を介して、あるいは、個別の購入ベースで提供アプリケーション７１５を提供してもよい。例えば、提供は、アップルアプリストアなどのサービスを介して設定金額（例えば、各アプリケーション１．９９ドル）で購入される必要があるまたは購読サービスを介してアクセス提供可能である。ある実施例においては、サービスアプリケーションはソースデバイスにダウンロードされてもよい。一旦購入されたサービスアプリケーションは、鍵の組に基づいて特定期間、無料でゲーム／提供７２０をダウンロードするように動作してもよい。例えば、サービスアプリケーション７０５の購入日は提供７１５を与える根拠として使用されてもよい。例えば、２００９年１月１日にアプリストアを通してサービスアプリケーション（例えば、ｉＰｌａｙ）が購入され、購入されたｉＰｌａｙのバージョンは１年の購読（例えば、１９．９９ドル）である場合、２０１０年１月１日まで入手されたどんな提供もｉＰｌａｙアプリケーションの中で承認鍵にアクセスするように働き、その鍵がその年の終わりに期限が切れる。

図７Ｂは、共同プレイＩＰＤＴの画面を示すブロック図である。ある実施例においては、購読モデルは、それ自身のアプリケーション７２５で包装されて、アイコンとスプラッシュスクリーンを含む完全なアプリケーションとしてソースデバイス７２７上で実行される。購読モデルのｉＴｅｎｎｉｓなどの提供７３０は、使用説明書７４０とゲーム画面を有する完全なアプリケーションとして働く。提供の固定バージョンは購読外となれば、チャック式外観７３５を有し、新規購読の下で解放されてもよい。

インターラクティブ拡張
共同プレイＩＰＤＴへの別の特長はアプリケーションとの相互作用を拡張することができる特徴を伴う。かかる拡張は電子ゲームの領域で特に有益である。例えば、ｉＰｈｏｎｅなどのソースデバイスが大画面コンピュータなどのターゲットデバイスにテザーされている場合、ソースデバイスは通信テザーでその表示情報を送信するとゲームデータ／命令をターゲットデバイスに中継するゲームコントローラ入力装置になってもよい。例えば、ユーザはテニスラケットと同等のものとしてｉＰｈｏｎｅを使用し、ＩＰＤＴコンポーネントで容易にされるｉＴｅｎｎｉｓアプリケーションの提供を通じて仮想テニスゲームをプレイする。ラケットを振るためのテニスラケットハンドルとしてｉＰｈｏｎｅを使用することを超えて、ｉＰｈｏｎｅ３Ｄ加速度計がガットの力学を取得するために測定される場合には、タッチスクリーンを使用することによってＩＰＤＴは特徴機能を更に広げることができる。例えば、ある実施例においては、ユーザは、ゲームで余分のパワー増加を得るためにｉＰｈｏｎｅを振るときに、ラケット上に仮想テニスガットを一緒に鋏む。さらに、ユーザは、ラケットのガットの緩急を付けるのにマルチタッチジェスチャーを使用して、それはＩＰＤＴアプリケーションの追加入力として使用され、ゲームの力学（例えば、ガットを緩めてパワーを増強するが、精度を減少させる）に影響を与える。

また、共同プレイＩＰＤＴは自宅ユーザ（例えば、ゲーム）プロフィールと進歩に使用されてもよい。このようにして、（例えば、ｉＭｅｅ）などのユーザのアバターとアカウントは、ターゲットデバイスがインターネットに接続不能及び／又はその能力がないかその他の点ではユーザプロファイルにアクセスする場合であっても、ソースデバイスでアクセスされてもよい。ある実施例においては、プロフィールは、インターネットのサービスからｉＰｈｏｎｅなどのソースデバイスにキャッシュ及び／又はミラーされる。これらの設定は、ターゲットデバイスに転送、及び／又は、テザーでアクセスされてもよい。更に、かかるアバターと設定は他のＩＰＤＴアプリケーション提供と対話するのに使用されてもよい。例えば、二人の異なるユーザからのｉＰｈｏｎｅなどの二台以上のソースデバイスは、同時に、単一のターゲットデバイスにテザーされて、ターゲットアプリケーション上で単一のアプリケーションスペースを共有するように許可されてもよい。例えば、二台のソースデバイスの一つは、ホストアプリケーションとして機能し、もう一方のソースデバイスとの通信を受け付けることができる。従って、各ユーザが仮想的なアバターを有する実施例においては、２つのアバターは、ターゲットディスプレイの共用スペースで同時に制御されてもよい。更に、そのような即興のターゲット仮想スペースは当事者間の取引のソースであってもよい。例えば、アバターはデジタルオブジェクト（例えば、ゲームの強化兵器及び／又は装置のための金貨）に対するデジタルキャッシュなどの貴重なデジタルアセットを取り引きしてもよい。ある実施例においては、ｉＰｈｏｎｅなどの全ソースを収納する一般的なマルチプレイヤーディスプレイ、プレイヤーは単一のターゲットデバイス上で見られるかもしれないが、ソースデバイスのディスプレイは各ユーザに私的な別のビューを有してもよい。かかる実施例においては、ユーザは、ターゲットディスプレイ上の共通領域で対話し、それら自身のパーソナルディスプレイの上で二次的及び／又はプライベート／秘密戦略活動に従事してもよい。

別の実施例においては、大型コンピュータディスプレイまたはテレビのような単一のターゲットディスプレイは卓球またはテニスのような高い運動ゲームを２人以上のプレイヤーがプレイすることを許容するだろう。別の実施例においては、ＩＰＤＴは、ソースデバイスが殆ど全てのターゲットデバイスを即興プレゼンテーションディスプレイデバイスに替えることを可能にする。

図７Ｃは、ある実施例における共同プレイＩＰＤＴの異なるアプリケーションの側面を示している。これらはゴルフ、ボーリング、ビリヤード、野球、シャッフルボード、釣りなどのゲームを含むが、これらに限定されるものではない。

図８は、ある実施例におけるゴルフクラブとして構成された共同プレイＩＰＤＴ筺体の実施例を示している。アップルｉＰｈｏｎｅなどのモバイルデバイスは、ゴルフゲームのゴルフクラブ、テニスゲームのテニスラケット、魚釣りゲームの釣竿、野球ゲームの野球用バットなどのゲーム用器具として形成された筺体に固定可能である。

ＩＰＤＴ制御部
図９は、ブロック図にＩＰＤＴ制御部９０１の発明的側面を示している。この実施例においては、ＩＰＤＴ制御部９０１は、ネットワーク技術を通じたコンピュータとの対話及び／又は他の関連データを統合、処理、格納、検索、提供、識別、命令、生成、適合、及び／又は、助長する機能を有する。

通常、人、及び／又は、他のシステムであるユーザは、情報処理を容易にするために、情報技術システム（例えば、コンピュータ）を使用する。代わりに、コンピュータは、情報を処理するのにプロセッサを使用する。かかるプロセッサ９０３は、中央演算処理装置（ＣＰＵ）と呼ばれる場合がある。プロセッサの一形態はマイクロプロセッサと呼ばれる。ＣＰＵは、様々な動作を可能にする命令として作用するバイナリーコード信号を送信するのに通信回路を使用する。これらの命令は、メモリ９２９（例えば、レジスタ、キャッシュメモリ、ランダムアクセスメモリなど）の様々なプロセッサがアクセス可能で動作可能な領域において、操作的及び／又は他の命令とデータを包含及び／又は参照するデータ命令であってもよい。かかる通信命令は、バッチ（例えば、命令のバッチ）にプログラムとして、及び／又は、所望の操作を容易にするデータコンポーネントとして、格納及び／又は送信されてもよい。これらの保存された命令コード（例えば、プログラム）は、所望の操作を実行するためにＣＰＵ回路コンポーネントと他のマザーボード、及び／又は、システムコンポーネントを使用してもよい。ある種のプログラムはコンピュータのＣＰＵによって実行可能なコンピュータオペレーティングシステムである。オペレーティングシステムは、ユーザがコンピュータ情報技術とリソースにアクセス及び操作することを可能及び容易にする。情報技術システムに使用される幾つかのリソースは、データがコンピュータに送入出される入出力機構、データを保存可能なメモリストレージ、及び、情報を処理可能なプロセッサを含む。これらの情報技術システムは、データベースプログラムで容易化され、その後の検索、分析、および操作のデータを収集するのに使用されてもよい。これらの情報技術システムは、ユーザが様々なシステムコンポーネントにアクセス及び操作するインターフェースを提供する。

ある実施例においては、ＩＰＤＴ制御部９０１は、ユーザ入力装置９１１、周辺機器９１２、選択的な暗号プロセッサデバイス９２８、及び／又は、通信ネットワーク９１３から一以上のユーザなどの（ただしこれらに限定されない）エンティティに接続され、及び／又は、通信することができる。

ネットワークは、グラフトポロジーにおいてクライアント、サーバおよび中間ノードの相互連結と共同動作を有すると一般に考えられている。本出願で使用される「サーバ」という用語は、一般に、通信ネットワークでリモートユーザの要求を処理および応答するコンピュータ、他のデバイス、プログラムまたはそれらの組み合わせを意味することに留意すべきである。サーバは要求する「クライアント」にその情報を提供する。ここで使用される「クライアント」という用語は、一般に、要求を処理及び作成して通信ネットワークでサーバからの応答を取得及び処理するコンピュータ、プログラム、他のデバイス、ユーザ、及び／又は、それらの組み合わせである。情報を容易化及び処理し、ソースユーザから目的ユーザまでの情報の移動を要求及び／又は助長するコンピュータ、他の装置、プログラムまたはそれらの組み合わせは、一般に、「ノード」と呼ばれている。ネットワークは、一般に、ソースポイントから目的地までの情報の転送を容易にすると考えられている。ソースから目的地までの情報の送信を促進する仕事を特に負うノードは、一般に「ルータ」と呼ばれている。ネットワークには、ローカル・エリア・ネットワーク（ＬＡＮ）、ピコネットワーク、ワイド・エリア・ネットワーク（ＷＡＮ）、ワイヤレスネットワーク（ＷＬＡＮｓ）など多くの形態がある。例えば、インターネットは、多数のネットワークの結合であるとして一般に受け入れられており、これによってリモートクライアントとサーバが互いにアクセスして協働することができる。

ＩＰＤＴ制御部９０１は、メモリ９２９に接続されたコンピュータ組織９０２などのコンポーネントを含む（但し、それらに限定されない）コンピュータシステムに基づくことができる。

コンピュータ組織
コンピュータ組織９０２は、クロック９３０、中央演算処理装置（「ＣＰＵ」及び／又は「プロセッサ」（特に断らない限り、これらの用語は開示中交換可能に使用される））９０３、メモリ９２９（例えば、リードオンリーメモリ（ＲＯＭ）９０６、ランダムアクセスメモリ（ＲＡＭ）９０５など）、及び／又は、インターフェースバス９０７を有し、常にではないがごく頻繁に、全てはシステムバス９０４を介して、命令（例えば、バイナリーコード信号）が通信、動作、格納などの効果を与えるために移動する導電及び／又は伝送回路経路を有する一以上の（マザー）ボード９０２上で、相互接続及び／又は交信する。選択的に、コンピュータ組織は、内部電源９８６に接続されてもよい。選択的に、暗号プロセッサ９２６は、システムバスに接続されてもよい。システムクロックは、典型的に、水晶発振器を有し、コンピュータ組織の回路経路を通ってベース信号を生成する。クロックは、典型的に、システムバスと、コンピュータ組織において内部接続された他のコンポーネントのためにベース操作周波数を増減する様々なクロック乗算器に結合されている。コンピュータ組織にけるクロックと様々なコンポーネントは、システムに亘って情報を具体化する信号を駆動する。コンピュータ組織に亘る情報を具体化する命令のこのような送受信は、一般に通信と呼ばれている。これらの通信命令は、本コンピュータ組織を越えて通信ネットワーク、入力装置、他のコンピュータ組織、周辺機器などへ更に送信、受信され、返信及び応答の通信の原因となる。もちろん、上記コンポーネントの幾つかは、互いに直接接続され、ＣＰＵに接続され、及び／又は、様々なコンピュータシステムによって例示されるように採用された様々な変形において組織されてもよい。

ＣＰＵは、ユーザ及び／又はシステムが生成した要求を実行するプログラムコンポーネントを実行するのに適した少なくとも一の高速データプロセッサを有する。しばしば、プロセッサ自体が、統合システム（バス）コントローラ、メモリ管理制御装置、浮動小数点ユニット、およびグラフィック処理装置、デジタル信号処理装置などの専門処理サブユニットなどの（但し、これらには限定されない）様々な専門処理装置を組み込んでいる。

また、プロセッサは、内部高速アクセスアドレス付けが可能なメモリを有してもよく、メモリ５２９を、プロセッサ自身を超えてマップ付け及びアドレス付けしてもよい。内部メモリは、高速レジスタ、様々なレベルのキャッシュメモリ（例えば、レベル１、２、３など）、ＲＡＭなどを含んでもよいが、これらには限定されない。プロセッサは、このメモリに、命令アドレスを介してアクセス可能なメモリアドレススペースの使用を通じてアクセスし、それはプロセッサが作成及び解読可能で、それによりプロセッサはメモリ状態を有する特定のメモリアドレススペースに回路経路をアクセスさせることができる。ＣＰＵは、ＡＭＤのＡｔｈｌｏｎ、Ｄｕｒｏｎ及び／又はＯｐｔｅｒｏｎ、ＡＲＭのアプリケーション、埋め込みおよび安全なプロセッサ、ＩＢＭ及び／又はモトローラのドラゴンボールとＰｏｗｅｒＰＣ、ＩＢＭとソニーのセルプロセッサ、インテルのセレロン、コア（２）デュオ、Ｉｔａｎｉｕｍ、ペンティアム、Ｘｅｏｎ及び／又はＸＳｃａｌｅ、及び／又は、その他の類似のプロセッサなどのマイクロプロセッサであってもよい。ＣＰＵは、伝導及び／又は伝送路（例えば（印刷）電子及び／又は光回路）を通じて移動する命令を通じてメモリと対話し、従来のデータ処理技術に従って保存された命令（即ち、プログラムコード）を実行させる。そのような命令送信は。ＩＰＤＴ制御部内と様々なインターフェースを越えた通信を容易にする。処理要件が、より高速及び／又は大容量を必要としている場合には、分散プロセッサ（例えば、分散ＩＰＤＴ）、メインフレーム、マルチコア、パラレル、及び／又は、スーパーコンピュータアーキテクチャが同様に使用されてもよい。代替的に、展開要件がより優れた携帯性を必要とする場合には、より小さいパーソナルデジタルアシスタント（ＰＤＡ）が使用されてもよい。

特定の実施例に依存して、ＩＰＤＴの特徴は、ＣＡＳＴのＲ８０５１ＸＣ２マイクロコントローラ、インテルのＭＣＳ５１（即ち、８０５１マイクロコントローラ）などのマイクロコントローラを具現化することによって達成可能である。また、ＩＰＤＴのある特徴機能を実施するために、幾つかの特徴機能の実装は、特定用途向け集積回路（「ＡＳＩＣ」）、デジタル信号処理（「ＤＳＰ」）、フィールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）、及び／又は、類似の埋め込み技術などの埋め込みコンポーネントに依存してもよい。例えば、ＩＰＤＴコンポーネントコレクション（分散又はその他の点）、及び／又は、特徴機能は、マイクロプロセッサ、及び／又は、埋め込みコンポーネントを介して、例えば、ＡＳＩＣ、コプロセッサ、ＤＳＰ、ＦＰＧＡなどを介して、実施可能である。代替的に、ＩＰＤＴの幾つかの実施例は、様々な特徴機能または信号処理を構成及び達成する埋め込みコンポーネントであってもよい。

特定の実施例では、埋め込みコンポーネントは、ソフトウェア解決、ハードウェア解決、及び／又は、ハードウェア／ソフトウェア解決の両方の幾つかの組み合わせを含むことができる。例えば、ここで説明するＩＰＤＴの特徴機能は、「論理ブロック」と呼ばれるプログラム可能な論理コンポーネントと、高性能ＦＰＧＡ・Ｖｉｒｔｅｘシリーズ及び／又はＸｉｌｉｎｘ製の低価格Ｓｐａｒｔａｎシリーズのようにプログラム可能な相互接続を含む半導体素子であるＦＰＧＡの実施を通じて達成可能である。論理ブロックと相互接続は、ＦＲＧＡが製造された後で、ＩＰＤＴの特徴機能の幾つかを実装するために、顧客または設計者によってプログラムが可能である。プログラム可能な相互接続の階層構造は、論理ブロックが必要に応じてＩＰＤＴシステム設計者／管理者によって、１チッププログラム可能なブレッドボードのように、相互接続されるのを可能にする。ＦＰＧＡの論理ブロックは、ＡＮＤやＸＯＲなどの基本論理ゲートの機能、あるいは、解読機または単純数学機能などのより複雑な組み合せ機能を実行するようにプログラム可能である。殆どのＦＰＧＡでは、論理ブロックはメモリ要素も有し、それは単純なフリップフロップまたはより完全なメモリのブロックであってもよい。ある場合には、ＩＰＤＴは通常のＦＰＧＡで開発され、ＡＳＩＣ実装と類似する固定バージョンに移行されてもよい。代替的実施例または変形例においては、ＩＰＤＴ制御部特徴機能が、ＦＰＧＡの代わりにまたはＦＰＧＡに追加して、最終的なＡＳＩＣに移行する。ある実施例では、前述の埋め込みコンポーネントとマイクロプロセッサの全てがＩＰＤＴのための「ＣＰＵ」及び／又は「プロセッサ」であるとみなされてもよい。

電源
電源９８６は、アルカリ、リチウム水素化物、リチウムイオン、リチウムポリマー、ニッケルカドミウム、太陽電池などのパワーセルなど、小型電子回路ボード素子に電源供給するためのどんな標準形式であってもよい。他の種類の交流又は直流電源も同様に使用可能である。太陽電池の場合、ある実施例においては、太陽電池がフォトニックエネルギーを得ることができる隙間が設けられる。パワーセル９８６は、少なくとも一つの相互接続されたＩＰＤＴの以下のコンポーネントに接続され、それによって全ての以下のコンポーネントに電流を与える。ある実施例においては、電源９８６はシステムバスコンポーネント９０４に接続される。代替的実施例においては、Ｉ／Ｏ９０８インターフェースの接続を通じて外部電源９８６が提供される。例えば、ＵＳＢ及び／又はＩＥＥＥ１３９４接続は、接続によりデータと電源の両方を運ぶため、適当な電源である。

インターフェースアダプター
インターフェースバス９０７は、多くのインターフェースアダプターを受容、接続及び／又は通信することができ、常にではないが従来は入出力インターフェース（Ｉ／Ｏ）９０８、ストレージインターフェース９０９、ネットワークインターフェース９１０などの（ただしこれらには限定されない）アダプターカードの形態であった。選択的に、暗号プロセッサインターフェース９２７もインターフェースバスに接続されてもよい。インターフェースバスは、コンピュータ組織の他のコンポーネントと同様にインターフェースアダプターの相互通信を与える。インターフェースアダプターは互換性のあるインターフェースバスに適合している。インターフェースアダプターは、従来、スロットアーキテクチャを介してインターフェースバスに接続している。従来のスロットアーキテクチャ波使用可能であり、アクセラレーティッド・グラフィックス・ポート（ＡＧＰ）、カードバス、（拡張）業界標準アーキテクチャ（（Ｅ）ＩＳＡ）、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）、ＮｕＢｕｓ、ペリフェラル・コンポーネント・インターコネクト（拡張）（ＰＣＩ（Ｘ））、ＰＣＩエクスプレス、ＰＣメモリーカード国際協会（ＰＣＭＣＩＡ）などを含むが、これらには限定されない。

ストレージインターフェース９０９は、ストレージデバイス９１４、リムーバブルディスクデバイスなどの（但し、これらには限定されない）多くのストレージデバイスを受容、通信、及び／又は、接続することができる。ストレージインターフェースは、（ウルトラ）（シリアル）アドバンストテクノロジーアタッチメント（パケットインターフェース）（（ウルトラ）（シリアル）ＡＴＡ（ＰＩ））、（拡張）インテグレーティッドドライブエレクトロニクス（（Ｅ）ＩＤＥ）、米国電気電子技術者学会（ＩＥＥＥ）１３９４、ファイバーチャネル、スモールコンピュータシステムズインターフェース（ＳＣＳＩ）、ユニバーサルシリアルバス（ＵＳＢ）などを含む（但し、これらには限定されない）接続プロトコルを使用することができる。

ネットワークインターフェース９１０は、通信ネットワーク９１３を受容、通信及び／又は接続することができる。通信ネットワーク９１３を通して、ＩＰＤＴ制御部はユーザ９３３ａによってリモートクライアント９３３ｂ（例えば、ウエブブラウザを有するコンピュータ）を通じてアクセス可能となる。ネットワークインターフェースは、直接接続、イーサネット（太型、細型、ツイストペア１０／１００／１０００ベースＴなど）、トークンリング、ＩＥＥＥ８０２．１１ａ−ｘなどの無線接続などを含む（但し、これらには限定されない）接続プロトコルを使用することができる。処理要件が、より高速及び／又は大容量を必要としている場合には、分散ネットワークコントローラ（例えば、分散ＩＰＤＴ）、アーキテクチャが同様にＩＰＤＴコントローラによって要求される通信帯域幅をプール、ロードバランス及び／又は他の点で増加するのに使用されてもよい。通信ネットワークは、直接接続、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、オペレーティング・ミッションズ・アズ・ノーズ・オン・ザ・インターネット（ＯＭＮＩ）、機密保護されたカスタム接続、ワイド・エリア・ネットワーク（ＷＡＮ）、（例えば、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）、Ｉモードなどの（但し、これらには限定されない）プロトコルを使用する）無線ネットワークなどの一つ及び／又はこれらの組み合わせであってもよい。ネットワークインターフェースは、入出力インターフェースの特定の形態とみなすことができる。更に、多数のネットワークインターフェース９１０は、様々な通信ネットワークの種類９１３と接続するのに使用されてもよい。例えば、多数のネットワークインターフェースは、ブロードキャスト、マルチキャスト、及び／又は、ユニキャストネットワークにおける通信を可能にするのに使用される。

入出力インターフェース（Ｉ／Ｏ）９０８は、ユーザ入力装置９１１、周辺機器９１２、暗号プロセッサデバイス９２８などを受容、通信及び／又は接続してもよい。Ｉ／Ｏは、以下の（但し、これらには限定されない）接続プロトコルを使用してもよい。オーディオはアナログ、デジタル、モノラル、ＲＣＡ、ステレオなど、データはアップルデスクトップバス（ＡＤＢ）、ＩＥＥＥＩ３９４ａ−ｂ、シリアル、ユニバーサルシリアルバス（ＵＳＢ）、赤外線、ジョイスティック、キーボード、ｍｉｄｉ、光学、ＰＣＡＴ、ＰＳ／２、パラレル、無線、ビデオインターフェースはアップルデスクトップコネクタ（ＡＤＣ）、ＢＮＣ、同軸、コンポーネント、コンポジット、デジタル、デジタルビジュアルインターフェース（ＤＶＩ）、ハイデフィニッションマルチメディアインターフェース（ＨＤＭＩ）、ＲＣＡ、ＲＦアンテナ、Ｓ−ビデオ、ＶＧＡなど、無線は８０２．１１ａ／ｂ／ｇ／ｎ／ｘ、ブルートゥース、符号分割多重接続（ＣＤＭＡ）、グローバルシステムフォーモバイルコミュニケーション（ＧＳＭ）、ＷｉＭａｘなどである。ある典型的な出力装置はビデオディスプレイを有してもよく、それは、ビデオインターフェースから信号を受け入れるインターフェース（例えば、ＤＶＩ回路とケーブル）を有するブラウン管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）ベースのモニタを通常有する。ビデオインターフェースは、コンピュータ組織によって生成された情報を合成し、ビデオメモリフレームで合成情報に基づいてビデオ信号を生成する。別の出力装置は、ビデオインターフェースから信号を受け入れるテレビである。通常、ビデオインターフェースは（例えば、ＲＣＡコンポジットビデオケーブルを受け入れるＲＣＡコンポジットビデオコネクタやＤＶＩディスプレイケーブルを受け入れるＤＶＩコネクタなどの）ビデオディスプレイインターフェースを受け入れるビデオ接続インターフェースを通じて合成ビデオ情報を提供する。

ユーザ入力装置９１１は、カードリーダ、ドングル、指紋リーダ、グローブ、グラフィックスタブレット、ジョイスティック、キーボード、マウス、リモートコントロール、網膜リーダ、トラックボール、トラックパッドなどであってもよい。

周辺機器９１２は、Ｉ／Ｏ及び／又はネットワークインターフェース、ストレージインターフェースなどの他の類似のファシリティに接続及び／又は通信してもよい。周辺機器は、オーディオデバイス、カメラ、（例えば、コピープロテクションのためにデジタル署名などで安全な取引を確保する）ドングル、（付加された機能性のための）外部プロセッサ、ゴーグル、マイクロホン、モニタ、ネットワークインターフェース、プリンタ、スキャナ、ストレージデバイス、ビデオデバイス、ビデオソース、バイザーなどであってもよい。

ユーザ入力装置と周辺機器は使用可能であるが、ＩＰＤＴ制御部は、埋め込み、専用、及び／又は、モニターレス（即ち、ヘッドレス）のデバイスとして具現化可能であることに留意すべきであり、ネットワークインターフェース接続に亘ってアクセスが提供される。

マイクロコントローラ、プロセッサ９２６、インターフェース９２７、及び／又は、デバイス９２８などの（但し、これらには限定されない）暗号ユニットは、ＩＰＤＴ制御部に取り付け、及び／又は、交信することができる。モトローラ社製ＭＣ６８ＨＣ１６マイクロコントローラは、暗号装置用に、及び／又は、暗号装置内で使用可能である。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚ構成で１６ビットの乗算及び蓄積命令を利用し、５１２ビットのＲＳＡ私有鍵操作を実行するのに１秒かからない。暗号装置は、匿名取引を可能にするのと同様に、相互作用機関から通信の認証を提供する。ＣＰＵの一部として暗号装置が構成されてもよい。同等なマイクロコントローラ、及び／又は、プロセッサも使用可能である。他の商業的に利用可能な特定暗号プロセッサは、ブロードコムのＣｒｙｐｔｏＮｅｔＸと他のセキュリティプロセッサ、ｎＣｉｐｈｅｒのｎＳｈｉｅｌｄ、セーフネットのルーナＰＣＩ（例えば、７１００）シリーズ、セマフォーコミュニケーションズの４０ＭＨｚロードランナー１８４、Ｓｕｎの暗号アクセラレータ（例えば、アクセラレータ６０００ＰＣＩｅボード、アクセラレータ５００ドータカード）、５００＋ＭＢ／ｓの暗号命令を実行可能なビアナノプロセッサ（例えば、Ｌ２１００、Ｌ２２００、Ｕ２４００）ライン、ＶＬＳＩ技術の３３ＭＨｚ６８６８などを含む。

メモリ
一般に、プロセッサがストレージ及び／又は情報検索に影響を与えることを可能にする機械化及び／又は実施例はメモリ９２９と見なされる。しかしながら、メモリは、代替可能な技術リソースであるので、多くのメモリの実施例が代わりにまたは協働して使用可能である。ＩＰＤＴ制御部、及び／又は、コンピュータ組織は、メモリ９２９の様々な形態を使用可能であることを理解すべきである。例えば、オンチップＣＰＵメモリ（例えば、レジスタ）、ＲＡＭ、ＲＯＭ及びその他のストレージデバイスの機能性が紙パンチテープまたは紙パンチカード機構によって提供可能であるように、コンピュータ組織は構成されてもよい。もちろん、そのような実施例は非常に遅い動作速度をもたらすだろう。典型的な構成において、メモリ９２９は、ＲＯＭ９０６、ＲＡＭ９０５、ストレージデバイス９１４を有する。ストレージデバイス９１４はどんな従来のコンピュータシステムの記憶装置でもよい。ストレージデバイスはドラム、（固定及び／又はリムーバブル）磁気ディスクドライブ、光磁気ドライブ、光ドライブ（即ち、ブルーレイ、ＣＤＲＯＭ／ＲＡＭ／書き込み可能な（Ｒ）／書き換え可能な（ＲＷ）、ＤＶＤＲ／ＲＷ、ＨＤ ＤＶＤ Ｒ／ＲＷなど）、デバイスアレイ（例えば、独立ディスク冗長アレイ（ＲＡＩＤ）、ソリッドステートメモリーデバイス（ＵＳＢメモリ、ソリッドステートドライブ（ＳＳＤ）など）、他のプロセッサ可読記憶媒体、及び／又は、その他の類似のデバイスを含んでもよい。従って、コンピュータ組織は、一般に、メモリを必要とし、それを利用する。

コンポーネットコレクション
メモリ９２９は、オペレーティングシステムコンポーネント９１５（オペレーティングシステム）、情報サーバコンポーネント９１６（情報サーバ）、ユーザインターフェースコンポーネント９１７（ユーザインターフェース）、ウエブブラウザコンポーネント９１８（ウエブブラウザ）、データベース９１９、メールサーバコンポーネント９２１、暗号サーバコンポーネント９２０（暗号サーバ）、ＩＰＤＴコンポーネント９３５など（即ち、まとめてコンポーネントコレクション）などの（但し、これらには限定されない）プログラム、及び／又は、データベースコンポーネント、及び／又は、データのコレクションを含む。これらのコンポーネントは、ストレージデバイス、及び／又は、インターフェースバスを介してアクセス可能なストレージデバイスに格納及びアクセスされてもよい。コンポーネントコレクションにおける非従来のプログラムコンポーネントはローカルストレージデバイス９１４に通常格納されるが、それらは、周辺機器、ＲＡＭ、通信ネットワークを通したリモートストレージファシリティ、ＲＯＭ、様々な形態のメモリ等のメモリにロード、及び／又は、格納されてもよい。

オペレーティングシステム
オペレーティングシステムコンポーネント９１５は、ＩＰＤＴ制御部の操作を容易にする、実行可能なプログラムコンポーネントである。通常、オペレーティングシステムは、Ｉ／Ｏ、ネットワークインターフェース、周辺機器、記憶装置などのアクセスを容易にする。オペレーティングシステムは、アップルマッキントッシュＯＳ・Ｘ（サーバ）、ＡＴ＆Ｔプラン９、ＢｅＯＳ、ＵｎｉｘとＵｎｉｘ−ｌｉｋｅシステム分散（ＡＴ＆ＴのＵＮＩＸ、ＦｒｅｅＢＳＤ、ＮｅｔＢＳＤ、ＯｐｅｎＢＳＤなどのバークレーソフトウェア配布（ＢＳＤ）変形、ＲｅｄＨａｔやＵｂｕｎｔｕなどのリナックス分散）及び／又は同様のオペレーティングシステムなどの高度にフォルトトレラントで、スケーラブルで、安全なシステムである。しかしながら、アップルマッキントッシュＯＳ、ＩＢＭＯＳ／２、マイクロソフトＤＯＳ、マイクロソフト・Ｗｉｎｄｏｗｓ２０００／２００３／３．ｉ／９５／９８／Ｃｅ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／Ｖｉｓｔａ／ＸＰ（サーバ）、パームＯＳなどの、より限定的及び／又は安全性の低いオペレーティングシステムも使用可能である。オペレーティングシステムは、それ自身を含むコンポーネントコレクションの他のコンポーネントと送受信することができる。ごく頻繁に、オペレーティングシステムは、他のプログラムコンポーネント、ユーザインターフェースなどと通信する。例えば、オペレーティングシステムは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び又は、提供することができる。オペレーティングシステムは、一旦ＣＰＵによって実行されると、通信ネットワーク、データ、Ｉ／Ｏ、周辺機器、プログラムコンポーネント、メモリ、ユーザ入力装置などとの対話を可能にする。オペレーティングシステムは、ＩＰＤＴ制御部に通信ネットワーク９１３を介して他のエンティティと交信することを可能にする通信プロトコルを提供することができる。様々な通信プロトコルが、マルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャストなどの（但し、これらには限定されない）相互作用のサブキャリア伝送機構としてＩＰＤＴ制御部で使用可能である。

情報サーバ
情報サーバコンポーネント９１６は、ＣＰＵによって実行される格納されたプログラムコンポーネントである。情報サーバは、アパッチ・ソフトウェア・ファウンデーションのアパッチ、マイクロソフトのインターネット・インフォメーション・サーバなどの（但し、これらには限定されない）従来のインターネット情報サーバであってもよい。情報サーバは、アクティブ・サーバ・ページ（ＡＳＰ）、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（objective-）Ｃ（＋＋）、Ｃ＃及び／又は．ＮＥＴ、コモン・ゲートウェイ・インターフェイス（ＣＧＩ）スクリプト、ダイナミック（Ｄ）ハイパーテキストマークアップ言語（ＨＴＭＬ）、フラッシュ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、プラクティカル・エクストラクション・レポート・ラングエージ（パール）、ハイパーテキストプリプロセッサ（ＰＨＰ）、パイプス、パイソン、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、ＷｅｂＯｂｊｅｃｔｓなどのファシリティを介してプログラムのコンポーネントの実行を可能にする。情報サーバは、安全な通信プロトコルを提供してもよく、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュアソケットレイア（ＳＳＬ）、メッセージングプロトコル（例えば、アメリカオンライン（ＡＯＬ）、インスタントメッセンジャー（ＡＩＭ）、アプリケーションエクスチェンジ（ＡＰＥＸ）、ＩＣＱ、インターネット・リレー・チャット（ＩＲＣ）、マイクロソフトネットワーク（ＭＳＮ）メッセンジャーサービス、プレゼンス・アンド・インスタント・メッセージング・プロトコル（ＰＲＩＭ）、インターネットエンジニアリングタスクフォースの（ＩＥＴＦの）セッション・イニシエーション・プロトコル（ＳＩＰ）、インスタント・メッセージング・アンド・プレゼンス・レバレージング・エクステンションズのＳＩＰ（ＳＩＭＰＬＥ）、オープンＸＭＬベースのエクステンシブルメッセージングアンドプレゼンスプロトコル（ＸＭＰＰ）（即ち、ジャバーまたはオープンモバイルアライアンス（ＯＭＡ）のインスタント・メッセージング・アンド・プレゼンス・サービス（ＩＭＰＳ））、Ｙａｈｏｏ！インスタントメッセンジャーサービスなどを含むが、これらには限定されない。情報サーバは、ウエブページの形態で結果をウエブブラウザに提供し、他のプログラムコンポーネントとの対話を通じてウエブページを操作および生成する。ＨＴＴＰ要求のドメインネームシステム（ＤＮＳ）解決部分が特定の情報サーバに解決された後で、情報サーバは、ＨＴＴＰ要求の残りに基づいてＩＰＤＴ制御部の特定の場所で情報の要求を解決する。例えば、http://123.124.125.126/mylnformation.htmlの要求は、ＤＮＳサーバによって解決される情報サーバへの要求「123.124.125.126」のＩＰ部分をそのＩＰアドレスで有しているかもしれないし、その情報サーバは、次いで、その要求の「/myInformation.html」部分に対するｈｔｔｐ要求を更にパースし、情報「mylnformation.html」を有するメモリの場所に解決するかもしれない。また、プロトコルを提供する他の情報は、ＦＴＰ通信アクロスポート２１などの様々なポートで使用可能である。情報サーバは、それ自身及び／又は類似のファシリティを含むコンポーネントコレクションにおいて他のコンポーネントと送受信してもよい。ごく頻繁に、情報サーバはＩＰＤＴデータベース９１９、オペレーティングシステム、他のプログラムコンポーネント、ユーザインターフェース、ウエブブラウザなどと通信する。

ＩＰＤＴデータベースへのアクセスは、（ＣＧＩなど）の以下に列挙されるスクリプト言語や（ＣＯＲＢＡ、ＷｅｂＯｂｊｅｃｔｓなどの）以下に列挙されるアプリケーション間通信チャンネルを通じて幾つかのデータベースブリッジ機構を通じて達成可能である。ウエブブラウザを通じたどんなデータ要求も、ＩＰＤＴによって要求されると、ブリッジ機構を通して適切なグラマーにパースされる。ある実施例においては、情報サーバは、ウエブブラウザによってアクセス可能なウエブ形態を与えるだろう。ウエブ形態で供給されたフィールドになされた入力は、特定のフィールドに入力されたものとしてタグ付けされ、パースされる。入力されたタームは、フィールドタグと共に送信され、それは、適当なテーブル及び／又フィールドに向けられたクエリを生成するようにパーサに命令する。ある実施例においては、パーサは、タグ付けされたテキスト入力に基づいて適当な加入／選択コマンドで検索ストリングをインスタンス作成することによって標準ＳＱＬでクエリを生成する。結果コマンドは、ブリッジ機構を通じてクエリとしてＩＰＤＴに提供される。クエリからクエリ結果を生成する際に、結果はブリッジ機構を通じて送信され、ブリッジ機構によって新しい結果ウエブページの生成とフォーマットのためにパースされる。かかる新しい結果ウエブページは、その後、それを要求ウエブブラウザに供給する情報サーバに提供される。

また、情報サーバは、プログラムコンポーネント、システム、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は、提供してもよい。

ユーザインターフェース
コンピュータインタフェースの機能はある点で自動車操作インターフェースと同様である。ハンドル、ギアシフト、速度計などの自動車操作インターフェース要素は自動車リソース、機能性および状態のアクセス、操作、表示を容易にする。チェックボックス、カーソル、メニュー、スクローラ、ウインドウ（まとめて一般にウィジェットと呼ばれている）などのコンピュータインタラクションインターフェース要素は、同様に、データ、コンピュータハードウェアおよびオペレーティングシステムリソース、機能性および状態のアクセス、操作及び表示を容易にする。操作インターフェースは、一般に、ユーザインターフェースと呼ばれている。グラフィカルユーザインターフェース（ＧＵＩｓ）、例えば、アップルマッキントッシュオペレーティングシステムのアクア、ＩＢＭのＯＳ／２、マイクロソフトのＷｉｎｄｏｗｓ２０００／２００３／３．１／９５／９８／ＣＥ／ミレニアム／ＮＴ／ＸＰ／ビスタ／７（即ち、エアロ）、ＵｎｉｘのＸ−Ｗｉｎｄｏｗｓ（例えば、Ｋデスクトップエンバイロンメント（ＫＤＥ）、ｍｙｔｈＴＶ及びＧＮＵネットワークオブジェクトモデルエンバイロンメント（ＧＮＯＭＥ））、ウエブインターフェースライブラリ（ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、フラッシュ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔなどのインターフェースライブラリ、例えば、（但し、これらには限定されない）Ｄｏｊｏ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、プロトタイプ、ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！ユーザインターフェース、それらのいずれも使用可能である）は、ユーザにベースラインと情報にアクセスして視覚的に表示する手段を与える。

ユーザインターフェースコンポーネント９１７は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ユーザインターフェースは、上述したように、オペレーティングシステム及び／又は操作環境によって、それらと共に、及び／又は、それらの先に提供される、従来のグラフィックユーザインターフェースであってもよい。ユーザインターフェースは、テキスト及び／又はグラフィックファシリティを通じて、プログラムコンポーネント及び／又はシステムファシリティの表示、実行、対話、マニプレーション、及び／又は、操作を与える。ユーザインターフェースは、ユーザがコンピュータシステムに影響を与え、対話し、及び／又は、操作することが可能なファシリティを与える。ユーザインターフェースは、それ自体及び／又は同様のファシリティを含むコンポーネントコレクションにおいて他のコンポーネントと送受信することができる。ごく頻繁に、ユーザインターフェースは、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。ユーザインターフェースは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求及び／又は応答を包含、通信、生成、取得、及び／又は提供してもよい。

ウエブブラウザ
ウエブブラウザコンポーネント９１８は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ウエブブラウザは、マイクロソフトインターネットエクスプローラまたはネットスケープナビゲータなどの従来のハイパーテキスト閲覧アプリケーションであってもよい。安全なウエブブラウジングが、ＨＴＴＰＳ、ＳＳＬなどによって１２８ビット（以上）の暗号化と共に提供可能である。ウエブブラウザは、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、フラッシュ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ウエブブラウザプラグインＡＰＩ（例えば、ＦｉｒｅＦｏｘ、サファリプラグイン及び／又は同様のＡＰＩ）などのファシリティを通じてプログラムコンポーネントの実行を与える。ウエブブラウザ及び類似の情報アクセスツールは、ＰＤＡ、携帯電話、及び／又は、他のモバイルデバイスに統合可能である。ウエブブラウザは、それ自体及び／又は同様のファシリティを含むコンポーネントコレクションの他のコンポーネントと送受信することができる。ごく頻繁に、ウエブブラウザは、情報サーバ、オペレーティングシステム、統合プログラムコンポーネント（例えば、プラグイン）などと通信する。例えば、それは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は提供してもよい。もちろん、ウエブブラウザと情報サーバに代わって、複合アプリケーションが両方の同様の機能を実行するように開発されてもよい。複合アプリケーションは、同様に、ＩＰＤＴが実行可能なノードからユーザ、ユーザ代理人などへの情報の入手と提供に影響を与えるだろう。複合アプリケーションは、標準ウエブブラウザを使用するシステム上では意味がないかもしれない。

メールサーバ
メールサーバコンポーネント９２１は、ＣＰＵ９０３によって実行される、格納されたプログラムコンポーネントである。メールサーバは、ｓｅｎｄｍａｉｌ、マイクロソフトＥｘｃｈａｎｇｅなどの従来のインターネットメールサーバであってもよい。メールサーバは、ＡＳＰ、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（objective-）Ｃ（＋＋）、Ｃ＃及び／又は．ＮＥＴ、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、パール、ＰＨＰ、パイプス、パイソン、ＷｅｂＯｂｊｅｃｔｓなどのファシリティを介してプログラムコンポーネントの実行を可能にする。メールサーバは通信プロトコルを提供してもよく、これらは、インターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）、メッセージング・アプリケーション・プログラミング・インターフェース（ＭＡＰＩ）／マイクロソフトエクスチェンジ、ポスト・オフィス・プロトコル（ＰＯＰ３）、シンプル・メール・トランスファー・プロトコル（ＳＭＴＰ）などを含むが、これらには限定されない。メールサーバは、送信、中継及び／又はＩＰＤＴを通じて及び／又はそれに移動する受信及び発信メールメッセージを発信、転送及び処理することができる。

ＩＰＤＴメールへのアクセスは、個々のウエブサーバーコンポーネント、及び／又は、オペレーティングシステムによって提供された多くのＡＰＩを通して達成可能である。

また、メールサーバは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、情報、及び／又は、応答を包含、通信、生成、取得、及び／又は、提供してもよい。

メールクライアント
メールクライアントコンポーネント９２２は、ＣＰＵ９０３によって実行される、格納されたプログラムコンポーネントである。メールクライアントは、アップルメール、マイクロソフトアントラージュ、マイクロソフトアウトルック、マイクロソフトアウトルックエクスプレス、モジラ、サンダーバードなどの従来のメール閲覧アプリケーションであってもよい。メールクライアントは、ＩＭＡＰ、マイクロソフトエクスチェンジ、ＰＯＰ３、ＳＭＴＰなどの多くの転送プロトコルを提供してもよい。

メールクライアントはそれ自体及び／又は同様のファシリティを含むコンポーネントコレクションの他のコンポーネントと送受信することができる。ごく頻繁に、メールクライアントは、メールサーバ、オペレーティングシステム、他のメールクライアントなどと通信する。例えば、それは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は提供してもよい。一般に、メールクライアントは、電子メールメッセージを構成及び送信するファシリティを提供する。

暗号サーバ
暗号サーバコンポーネント９２０は、ＣＰＵ９０３、暗号プロセッサ９２６、暗号プロセッサインターフェース９２７、暗号プロセッサデバイス９２８などによって実行される、格納されたプログラムコンポーネントである。暗号プロセッサインターフェースは、暗号コンポーネントによる暗号化及び／又は解読要求の迅速性を可能にするが、暗号コンポーネントは従来のＣＰＵで起動してもよい。暗号コンポーネントは提供されたデータの暗号化、及び／又は、復号化を可能にする。暗号コンポーネントは、対称及び非対称（例えば、プリティ・グッド・プロテクション（ＰＧＰ））暗号化及び／又は複合化の両方を可能にする。暗号コンポーネントは、デジタル証明書（例えば、Ｘ．５０９認証フレームワーク）、デジタル署名、デュアル署名、エンベローピング、パスワードアクセス保護、公開鍵管理などの（但し、これらに限定されない）暗号技術を使用してもよい。暗号コンポーネントは、チェックサム、データ暗号化標準（ＤＥＳ）、楕円暗号曲線（ＥＣＣ）、国際データ暗号化アルゴリズム（ＩＤＥＡ）、メッセージダイジェスト５（ＭＤ５は一方向ハッシュ関数）、パスワード、ＲｉｖｅｓｔＣｉｐｈｅｒ（ＲＣ５）、ラインダール、（１９７７年にロン・ライベスト、アディ・シャミルおよびレオナルド・アデルマンによって開発されたインターネット暗号化及び認証システムである）ＲＳＡ、セキュアハッシュアルゴリズム（ＳＨＡ）、セキュアソケットレイア（ＳＳＬ）、セキュアハイパーテキスト転送プロトコル（ＨＴＴＰＳ）などの（但し、これらに限定されない）多数の（暗号化及び／又は復号化）セキュリティプロトコルを容易にする。かかる暗号化セキュリティプロトコルを使用すると、ＩＰＤＴは全ての受信及び／又は発信通信を暗号化できて、より広い通信ネットワークと仮想私設ネットワーク（ＶＰＮ）でノードとして機能することができる。暗号コンポーネントは、「安全な承認」の処理を容易にし、これによってリソースへのアクセスが機密保持プロトコルによって禁止される。暗号コンポーネントは、機密保護されたリソースへの許可されたアクセスを可能にする。また、暗号コンポーネントは、コンテンツのユニークな識別子を提供することができ、例えば、デジタルオーディオファイルに対してユニークな署名を取得するのにＭＤ５ハッシュを使用する。暗号コンポーネントは、コそれ自体及び／又は同様のファシリティを含むンポーネントコレクションの他のコンポーネントと送受信することができる。暗号コンポーネントは、通信ネットワークで情報の安全な送信を可能にし、希望されればＩＰＤＴコンポーネントが安全な取引に従事することを可能にする暗号化体系を提供する。暗号コンポーネントは、ＩＰＤＴでリソースの安全なアクセスを容易にし、リモートシステムで機密保護されたリソースのアクセスを容易にする。即ち、それは機密保護されたリソースのクライアント及び／又はサーバとして働いてもよい。ごく頻繁に、暗号コンポーネントは、情報サーバ、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。暗号コンポーネントは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は、提供してもよい。

ＩＰＤＴデータベース
ＩＰＤＴデータベースコンポーネント９１９は、データベースとその格納データに具現化されてもよい。データベースは、ＣＰＵによって実行される、格納されたプログラムコンポーネントであり、格納されたプログラムコンポーネント部分はＣＰＵに格納データを処理させる。データベースは、オラクルまたはＳｙｂａｓｅなどの従来の、フォルトトレラントで、リレーショナルで、スケーラブルで安全なデータベースでもよい。リレーショナルデータベースはフラットなファイルの拡張である。リレーショナルデータベースは一連の関連テーブルからなる。テーブルはキーフィールドを介して相互接続されている。キーフィールドの使用は、キーフィールドに索引をつけることによってテーブルの組み合わせを可能にする。即ち、キーフィールドは、様々なテーブルからの情報を結合するための次元ピボットポイントとして作用する。関係は、一般に、主キーを合わせることによってテーブル間で維持されたリンクを識別する。主キーはリレーショナルデータベースでユニークにテーブルの行を識別するフィールドを表している。より正確には、それらは一対多の関係の「一」側面でユニークにテーブルの行を識別する。

代替的に、ＩＰＤＴデータベースは、アレイ、ハッシュ、（リンクされた）リスト、ストラクト、ストラクチャードテキストファイル（例えば、ＸＭＬ）、テーブルなどの様々な標準データ構造を使用して具現化されてもよい。かかるデータ構造は、メモリ及び／又は（ストラクチャード）ファイルに格納されてもよい。別の代替例においては、オブジェクト指向データベースは、フロンティア、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅなどのように使用されてもよい。オブジェクトデータベースは、共通の属性によってグループ化、及び／又は、リンク付けされる幾つかのオブジェクトコレクションを含んでもよい。それらは、いくつかの共通の属性によって他のオブジェクトコレクションに関連付けられてもよい。オブジェクト指向データベースは、オブジェクトがデータの単なる断片ではなく所与のオブジェクト内でカプセル化された他の種類の機能性を有する点を除いて、リレーショナルデータベースと同様に働く。ＩＰＤＴデータベースがデータ構造として具現化される場合、ＩＰＤＴデータベース９１９の使用はＩＰＤＴコンポーネント９３５などの別のコンポーネントに統合されてもよい。同様に、データベースは、データ構造、オブジェクト、およびリレーショナル構造の組み合わせとして具現化されてもよい。データベースは、標準データ処理技術を介した無数の変形例において統合及び／又は分散されてもよい。データベースの部分（例えば、テーブル）は、エクスポート及び／又はインポートされ、このようにして分散、及び／又は、統合されてもよい。

ある実施例においては、データベース構成要素９１９は数個のテーブル９１９ａ−ｄを有する。ユーザテーブル９１９ａは、ユーザＩＤ、ユーザ名、ユーザパスワード、連絡情報、ハードウェアＩＤ、ペイロード履歴、ユーザ評価などの（但し、これらには限定されない）フィールドを含むことができる。ハードウェアテーブル９１９ｂは、ハードウェアＩＤ、ハードウェアの種類、ハードウェア名、データフォーマット要件、プロトコル、アドレシング情報、使用履歴、ハードウェア要件、ユーザＩＤなどの（但し、これらには限定されない）フィールドを含むことができる。アプリケーションテーブル９１９ｃは、アプリケーションＩＤ、プロトコルＩＤ、ユーザの種類、アプリケーションの種類、アプリケーションのバージョン、ポリシーＩＤ、アプリケーションの設定、アプリケーションインターフェース、アプリケーション認証などのフィールドを含むことができる。プロトコルテーブル９１９ｄは、プロトコルＩＤ、ユーザＩＤ、プロトコルのバージョン、プロトコル要求、プロトコル互換性などの（但し、これらには限定されない）フィールドを含むことができる。ソーステーブル９１９ｅは、ソース名、ソースＩＤ、ハードウェアＩＤ、ハードウェアの種類、関連アプリケーションなどの（但し、これらには限定されない）フィールドを含むことができる。ターゲットテーブル９１９ｆは、ターゲット名、ターゲットＩＤ、ハードウェアＩＤ、ハードウェアの種類、関連アプリケーションなどの（但し、これらには限定されない）フィールドを含むことができる。

ある実施例においては、ＩＰＤＴデータベースは他のデータベースシステムと対話することができる。例えば、分散データベースシステムを使用すると、検索ＩＰＤＴコンポーネントによるクエリおよびデータアクセスは、ＩＰＤＴデータベース、単一データベースエンティティとしての統合データセキュリティレイヤデータベースの組み合わせを処理することができる。

ある実施例においては、ＩＰＤＴデータベースは他のデータベースシステムと対話することができる。例えば、分散データベースシステムを使用すると、検索ＩＰＤＴコンポーネントによるクエリおよびデータアクセスは、ＩＰＤＴデータベース、単一データベースエンティティとしての統合データセキュリティレイヤデータベースの組み合わせを処理することができる。

ある実施例においては、ユーザプログラムは、ＩＰＤＴを更新する機能を有する様々なユーザインターフェースプリミティブを含むことができる。また、様々なアカウントは、ＩＰＤＴが提供する必要があるかもしれないクライアントの種類と環境に依存してカスタムデータベーステーブルを必要とする場合がある。いかなるニークなフィールドも、キーフィールドとして完全に指定できることに留意すべきである。代替的な実施例においては、これらのテーブルはそれら自身のデータベースとそれらのそれぞれのデータベース制御部（即ち、上記テーブルの各々の個々のデータベース制御部）に分散されている。標準データ処理技術を使用して、幾つかのコンピュータ組織、及び／又は、ストレージデバイスにデータベースを分散してもよい。同様に、分散データベース制御部の構成を様々なデータベースコンポーネント９ｉ９ａ−ｆを統合及び／又は分散することによって変更可能である。ＩＰＤＴは、データベース制御部を介して、各種設定、入力およびパラメータを監視するように構成されてもよい。

ＩＰＤＴデータベースは、それ自身及び／又は類似のファシリティを含むコンポーネントコレクションの他のコンポーネントと送受信することができる。ごく頻繁に、ＩＰＤＴデータベースは、ＩＰＤＴコンポーネント、他のプログラムコンポーネントなどと通信する。データベースは、他のノードとデータに関する情報を包含、保持、及び提供することができる。

ＩＰＤＴ
ＩＰＤＴコンポーネント９３５は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ある実施例においては、ＩＰＤＴコンポーネントは、前述の図面で説明したＩＰＤＴの側面の幾つか及び／又は全てを組み合わせることができる。従って、ＩＰＤＴは、様々な通信ネットワークを介して、情報、サービス、取引などのアクセス、取得および提供に影響を与える。

ＩＰＤＴコンポーネントは、ネットワーク構成、アプリケーションの実装とＩＰＤＴの使用を可能にする。

ノード間で情報のアクセスを可能にするＩＰＤＴコンポーネントは、アパッチコンポーネント、アッセンブリ、アクティブＸ、バイナリーエクゼキュータブル、（ＡＮＳＩ）（objective-）Ｃ（＋＋）、Ｃ＃及び／又は．ＮＥＴ、データベースアダプター、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、マッピングツール、プロシージャ及びオブジェクト指向開発ツール、パール、ＰＨＰ、パイソン、シェルスクリプト、ＳＱＬコマンド、ウエブアプリケーションサーバエクステンション、ウエブ開発環境およびライブラリ（例えば、マイクロソフトのＡｃｔｉｖｅＸ、アドビ・エア、Ｆｌｅｘ＆Ｆｌａｓｈ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、Ｄｏｊｏ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、Ｐｒｏｔｏｔｙｐｅ、ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、シンプル・オブジェクト・アクセス・プロトコル（ソープ）、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！ユーザインターフェースなど）、ＷｅｂＯｂｊｅｃｔなどの（但し、これらには限定されない）標準開発ツールと言語を使用することによって開発可能である。ある実施例においては、ＩＰＤＴサーバは、通信を暗号化および解読するのに暗号サーバを使用する。ＩＰＤＴコンポーネントは、それ自身及び／又は類似のファシリティを含むコンポーネントコレクションの他のコンポーネントと送受信することができる。ごく頻繁に、ＩＰＤＴコンポーネントは、ＩＰＤＴデータベース、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。ＩＰＤＴは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得及び／又は提供することができる。

分散ＩＰＤＴ
ＩＰＤＴノード制御部コンポーネントの幾つかの構造及び／又は操作は、開発及び／又は配置を容易にするために、幾つかの方法で結合、統合及び／又は分散が可能である。同様に、展開及び／又は配置を容易にするために幾つかの方法でコンポーネントコレクションは結合可能である。これを達成するために、コンポーネントを、共通のコードベースに統合したり、統合された方法で必要に応じて動的にコンポーネットをロード可能なファシリティに統合したりすることができる。

コンポーネントコレクションは、無数の変形例において、標準データ処理及び／又は開発技術を通じて、統合及び／又は分配が可能である。プログラムコンポーネントコレクションにおけるいずれか一つのプログラムコンポーネントの多数のインスタンスは、単一のノードでインスタンス作成されてもよいし、及び／又は、パフォーマンス向上のために負荷のバランス及び／又はデータ処理技術を通じて多数のノードでインスタンス作成されてもよい。全てのプログラムコンポーネントインスタンス及び協働する制御部は、標準データ処理通信技術を通じてそうしてもよい。

ＩＰＤＴ制御部の構成はシステム開発のコンテクストに依存する。予算、容量、位置及び／又は基底ハードウェアリソースの使用などの（但し、これらには限定されない）要因は、配置要件と構成に影響を与える。構成がより整理及び／又は統合されたプログラムコンポネントになるかどうか、より分散された一連のプログラムコンポーネントになるかどうか、及び／又は、統合と分散の構成の何らかの組み合わせとなるかどうかに拘らず、データは通信、取得及び／又は提供されてもよい。プログラムコンポーネントコレクションから共通コードベースに統合されたコンポーネントのインスタンスは、データを通信、取得、及び／又は、提供してもよい。これは、データレフェレンシング（例えば、ポインタ）、内部メッセージング、オブジェクトインスタンス変数通信、共有メモリスペース、変数交換などの（但し、これらには限定されない）アプリケーション内データ処理通信技術を通じて達成可能である。

コンポーネントコレクションコンポーネントが互いに離散的、別個、及び／又は、外面的である場合、データを他のコンポーネントとの間で送受信、取得及び／又は提供することは、アプリケーションプログラムインタフェース（ＡＰＩ）情報交換、（分散）コンポーネントオブジェクトモデル（（Ｄ）ＣＯＭ）、（分散）オブジェクト・リンキング・アンド・エンベッディング（（Ｄ）ＯＬＥ）など）、共通オブジェクトリクエストブローカーアーキテクチャ（ＣＯＲＢＡ）、ローカル及びリモートアプリケーションプログラムインタフェース・ジニ、リモート・メソッド・インボケーション（ＲＭＩ）、ソープ、プロセスパイプ、共有ファイルなどのアプリケーション間データ処理通信技術を通じて達成されてもよい。アプリケーション間通信のための離散的なコンポーネント間またはアプリケーション内通信のための単一コンポーネントのメモリスペース内で送信されるメッセージは、グラマーの作成とパースを通じて容易になる。グラマーは、グラマーの生成とパースの機能性を可能にするｌｅｘ、ｙａｃｃ、ＸＭＬなどの標準開発ツールを使用して開発されてもよく、それは次いでコンポーネント内およびコンポーネント間で通信メッセージの基礎を形成する。例えば、グラマーは、w3c post-http://… Value1などのＨＴＴＰポストコマンドのトークンを認識するように構成されてもよい。ここで、Ｖａｌｕｅ１は、「http://」がグラマー構文の一部であるのでパラメータであるものとして区別され、以下に続くものはポストバリューの一部とみなされる。同様に、かかるグラマーを使用すると、変数「Value1」を「http://」ポストコマンドに挿入し、その後、送信することができる。グラマー構文それ自体は、翻訳及び／又は（例えば、ｌｅｘ、ｙａｃｃなどによって処理される構文説明テキストファイル）パース機構を生成するのに使用されるストラクチャードデータとして提供可能である。また、パース機構が一旦生成、及び／又は、インスタンス作成されると、それはそれ自体が、キャラクタ（例えば、タブ）、図示テキスト、ＨＴＭＬ、ストラクチャードテキストストリーム、ＸＭＬ、及び／又は、同様のストラクチャードデータなどの（但し、これらには限定されない）ストラクチャードデータを処理及び／又はパースすることができる。別の実施例においては、アプリケーション間データ処理プロトコル自体は、通信データをパースするのに使用可能な、統合及び／又は直ちに利用可能なパーサ（例えば、ソープパーサ）を有してもよい。更に、パースグラマーはメッセージパースを越えて使用可能であるが、データベース、データコレクション、データストア、ストラクチャードデータなどをパースするのにも使用可能である。再び、所望の構成は、システム配置のコンテクスト、環境、および要件に依存する。

（表紙、名称、見出し、分野、背景、手段、図面の簡単な説明、詳細な説明、請求の範囲、要約、図面を含む）本出願の全体は、請求の範囲に記載されている発明が実施可能な様々な実施例を例示している。本出願の利点と特徴機能は、実施例の代表例でしかなく、網羅的、及び／又は、限定的ではない。それらは請求された原理の理解と教示を補助するためにのみ提示されている。それらは、請求の範囲に記載された全ての発明を代表していないことを理解すべきである。そのため、開示のある側面はここで説明されていない。代替的な実施例は本発明の特定の部分に対しては提示されていないこと、または、更に記載されていない代替的な実施例が部分的に入手可能であることは、それらの代替的な実施例の放棄とみなされてはならない。それらの記載されていない実施例の多くは、本発明と同一の原理を有し、他のものは均等であることを理解すべきである。従って、他の実施例は、開示の範囲、及び／又は、本旨から逸脱せずに入手でき、機能的、論理的、組織的、構造的、及び／又はトポロジー的な変形であることを理解すべきである。従って、全ての実例、及び／又は、実施例が本開示に亘って非限定的であると考えられる。また、スペースと反復を削減する目的以外では、ここで説明した実施例からここで説明されていないものを類推してはならない。例えば、図に記載されているように及び／又は開示中でプログラムコンポーネント（コンポーネントコレクション）、他のコンポーネント、及び／又は、現在の特徴機能の組み合わせの論理的及び／又はトポロジー的な構造は、固定された操作順序及び／又は配置に限定されず、むしろいかなる開示された順番も例示的で全ての均等物は順番に関わらず開示によって想定されていることを理解すべきである。更に、かかる特徴は順次の実行に限定されず、むしろ非同期に、協働して、平行して、同時に、同期してなどで実行されるいかなる数のスレッド、処理、サービス、サーバなども本開示で想定されていることを理解すべきである。従って、これらの特徴機能の幾つかは、単一の実施例で同時に存在できない点で互いに矛盾する場合がある。同様に、幾つかの特徴機能は本発明の一側面に適用可能であるが、他の側面には適用できない。また、本開示は現在請求されていない他の発明を含む。本出願人は、現在請求されていない発明の全ての権利を留保し、これにはかかる発明を請求する権利、更なる出願、継続出願、一部継続出願、分割出願などをする権利を含む。また、本開示の特長、実施例、実例、機能的、特徴機能、論理的、組織的、構造的、トポロジー的、及び／又は、その他の側面は、請求の範囲に定義されているように、本開示の限定と請求の範囲の均等物の限定と考えてはならないことを理解すべきである。

１１３…通信ネットワーク、１１０…ソースデバイス、１１５…ソースディスプレイ、１１９…ＩＰＤＴ共同プレイＤＢ、１２０…ターゲットデバイス、１２５…リモートディスプレイ、２０５…ＩＰＤＴ共同プレイ制御部

Claims (24)

1. プロセッサによって実行されるインターラクティブなプロキシミティディスプレイのテザー方法は、
   リモートディスプレイテザーコンポーネントを初期化する要求を受信することと、
   テザーターゲットデバイスをクエリすることと、
   テザーターゲットデバイスの選択を取得することと、
   選択されたテザーターゲットデバイスに対する通信チャネルを構成することと、
   前記通信チャネルを通じてリモートディスプレイのインスタンスを作成することと、
   前記選択されたテザーターゲットデバイスの種類を決定することと、
   前記選択されたテザーターゲットデバイスがプロセッサベースである場合は、ソースデバイスでインターラクティブテザーアプリケーションのインスタンスを作成することと、
   制御入力に基づいてデータを生成することと、
   前記通信チャネルを通じて前記リモートディスプレイを駆動するために前記生成されたデータを送ることと、
   を有することを特徴とする方法。
2. テザーターゲットデバイスのクエリは、
   テザーターゲットデバイスの表示を受信することと、
   受信した表示に基づいてテザーターゲットデバイスのローカルエリアネットワークの範囲を検索することと、
   を有することを特徴とする請求項１に記載の方法。
3. テザーターゲットデバイスの表示は、ＩＰアドレス、マックアドレス、頭文字、ハードウェアラベル、デジタル署名およびドライバ証明書のいずれかであることを特徴とする請求項２に記載の方法。
4. テザーターゲットデバイスのクエリは、
   前記データベースの通信スタックにおいて登録されたテザーターゲットデバイスに基づくクエリを形成することを特徴とする請求項１に記載の方法。
5. テザーターゲットデバイスのクエリは、ゼロ構成プロトコルに基づいてテザーターゲットデバイスを配置し、
   前記ゼロ構成プロトコルは、サービスロケーションプロトコル（ＳＬＰ）、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）、ジニ、ブルートゥースサービスディスカバリープロトコル、ＷＳディスカバリー、ＵＤＰとボンジュールを使用したプロプライエタリディスカバリープロトコルのいずれかであることを特徴とする請求項１に記載の方法。
6. 前記クエリに基づいて利用可能なテザーターゲットデバイスのリストを生成することと、
   ユーザインターフェースを介して前記利用可能なテザーターゲットデバイスのリストを提供することと、
   を更に有することを特徴とする請求項１に記載の方法。
7. 前記テザーターゲットデバイスの種類を決定することは、前記テザーターゲットデバイスは物理的テザー又はプロセッサによって可能にされた装置であることを特徴とする請求項１に記載の方法。
8. 前記物理的テザーは、ダイレクトオーディオ／ビデオ接続であることを特徴とする請求項７に記載の方法。
9. 前記テザーターゲットデバイスが物理的テザーである場合は、前記物理的テザーを介してリモートディスプレイでディスプレイミラーモードのインスタンスを作成することを更に有することを特徴とする請求項７に記載の方法。
10. 前記ミラーモードの下で前記物理的テザーを通じて前記ターゲットデバイスに送信されるデータは、コンポーネントビデオＳ−ビデオ、ＨＤＭＩ、ＶＧＡ、ＤＶＩ、ディスプレイポートのいずれかに従うことを特徴とする請求項９に記載の方法。
11. 前記テザーターゲットデバイスが分散オブジェクト指向アプリケーション、ウエブサーバ、リモートディスプレイクライアントおよびウエブブラウザのいずれかを起動しているかどうかを決定することを更に有すること特徴とする請求項７に記載の方法。
12. 前記テザーターゲットデバイスがプロセッサベースの場合に、
    前記テザーターゲットデバイスを接続するカスタム通信チャネルを可能にすることと、
    前記テザーターゲットデバイスのインスタンスを作成する命令を提供することと、
    前記テザーターゲットデバイスでインターラクティブテザーによって実行可能なアプリケーションを使用することと、
    を更に有することを特徴とする請求項７に記載の方法。
13. 前記テザーターゲットデバイスが前記ウエブブラウザを起動している場合に、
    ウエブサーバのインスタンスを作成することと、
    前記テザーターゲットデバイスに接続することと、
    前記ターゲットデバイスのウエブブラウザに対してそのウインドウを前記画面の全サイズまで拡張するように命令することと、
    を更に有することを特徴とする請求項１１に記載の方法。
14. 前記テザーターゲットデバイスが前記リモートデスクトップクライアントを起動している場合は、前記ターゲットデバイスに入力されるものについてユーザに前記接続を完了するように命令する画面でプロンプト表示することを更に有することを特徴とする請求項１１に記載の方法。
15. 前記テザーターゲットデバイスは、分散オブジェクト指向アプリケーションを起動している場合は、グラフィックス作成エンジンを起動することを更に有することを特徴とする請求項１１に記載の方法。
16. 前記インターラクティブテザーによって実行可能なアプリケーションは、
    前記テザーターゲットデバイスにインターラクティブアプリケーションのより精巧なバージョンを転送することと、
    前記テザーターゲットデバイスに自動的にインターラクティブアプリケーションのより精巧なバージョンをダウンロードしてインストールすることを促すことと、
    の一つを有することを特徴とする請求項１２に記載の方法。
17. 前記生成されたデータはバイナリーデータパケットのフォーマットであり、前記バイナリーデータパケットは、メッセージの種類、シーケンス番号、承認番号、データオフセット、データ長、チェックサム、選択肢およびデータペイロードのフィールドを有することを特徴とする請求項１に記載の方法。
18. 前記データペイロードは、加速度計情報、（画面で押圧する）ポインタ座標、画像、ＧＰＳ情報、ユーザ情報などの少なくとも一つを有することを特徴とする請求項１７に記載の方法。
19. 前記生成されたデータは、コモンオブジェクトリクエストブローカーアーキテクチャ（ＣＯＲＢＡ）に基づいて前記テザーターゲットに送信されることを特徴とする請求項１に記載の方法。
20. 前記ＣＯＲＢＡ機構は、複数のオブジェクトに前記生成されたデータをカプセル化することを特徴とする請求項１９に記載の方法。
21. クライアントデバイスをクエリすることと、
    一以上の利用可能なクライアントデバイスの選択を取得することと、
    前記選択されたクライアントデバイスに対して前記通信チャネルで通信を確立することと、
    を更に有することを特徴とする請求項１に記載の方法。
22. リアルタイムで前記通信チャネルを介して前記選択されたクライアントデバイスでデータを交換することを更に有することを特徴とする請求項２１に記載の方法。
23. インターラクティブなプロキシミティディスプレイのテザーシステムは、
    リモートディスプレイテザーによって実行可能なコンポーネントを初期化する要求を受信する手段と、
    テザーターゲットデバイスをクエリする手段と、
    テザーターゲットデバイスの選択を取得する手段と、
    選択されたテザーターゲットデバイスに対する通信チャネルを構成する手段と、
    前記通信チャネルを通じてリモートディスプレイのインスタンスを作成する手段と、
    前記選択されたテザーターゲットデバイスの種類を決定する手段と、
    前記選択されたテザーターゲットデバイスがプロセッサベースである場合は、ソースデバイスでインターラクティブテザーアプリケーションのインスタンスを作成する手段と、
    制御入力に基づいてデータを生成する手段と、
    前記通信チャネルを通じて前記リモートディスプレイを駆動するために前記生成されたデータを送る手段と、
    を有することを特徴とするシステム。
24. 複数の処理命令を格納するプロセッサ可読媒体であって、プロセッサによって発行可能な命令を含み、前記発行可能な命令は、
    リモートディスプレイテザーによって実施可能なコンポーネントを初期化する要求を受信することと、
    テザーターゲットデバイスをクエリすることと、
    テザーターゲットデバイスの選択を取得することと、
    選択されたテザーターゲットデバイスに対する通信チャネルを構成することと、
    前記通信チャネルを通じてリモートディスプレイのインスタンスを作成することと、
    前記選択されたテザーターゲットデバイスの種類を決定することと、
    前記選択されたテザーターゲットデバイスがプロセッサベースである場合は、ソースデバイスでインターラクティブテザーアプリケーションのインスタンスを作成することと、
    制御入力に基づいてデータを生成することと、
    前記通信チャネルを通じて前記リモートディスプレイを駆動するために前記生成されたデータを送ることと、
    を有することを特徴とするプロセッサ可読媒体。