JP6312842B2 - 異機種環境においてデータ通信を支援するためのシステム及び方法、並びにプログラム - Google Patents

Description

著作権表示
本特許文献の開示の一部は、著作権保護を受ける素材を含む。著作権所有者は、特許文献又は特許開示が米国特許商標庁の特許ファイル又は記録にある通りの、何人による複写にも異議はないが、しかしそうでなければ全てのいかなる著作権も留保する。

開示される実施形態は、一般的に情報技術に関し、特に、排他的でなくデータ通信に関する。

スマートフォン及びタブレットなどのモバイル技術の成功は、新技術、例えばスマートハードウェア及びモノのインターネット（ＩｏＴ）の爆発的な開発につながる。例えば、スマート家電、スマート監視デバイス及び無人飛行機（ＵＡＶ）を含むスマートハードウェアは、より良いユーザ体験を達成するために、異なるモバイルプラットフォームと共に用いることができる。

様々な無線技術が、インターネットなどのネットワーク資源にデバイスを接続するために使用できる。通信リンクは、例えば、Ｗｉ−Ｆｉ技術を用い、無線ネットワークアクセスポイントを介して確立されても良い。Ｗｉ−Ｆｉリンクは、クライアント／サーバモデルに基づいているが、開発が容易であり、且つ大きなバラツキのあるアプリケーションを支援するのに足る十分な帯域幅を提供することができる。例えば、Ｗｉ−Ｆｉ技術に基づいた標準ソケットを使用し、外部ルータを備えたネットワークを通じて通信を確立することができる。

しかしながら、Ｗｉ−Ｆｉ技術は、ＴＣＰ／ＩＰトランスポートプロトコルを支援するために本格的なオペレーティングシステムを必要とする可能性がある。従って、Ｗｉ−Ｆｉ技術に基づいたデバイスは、このオペレーティングシステムを支援するために高実行能力を備えたプロセッサを有する必要があり得、それは、デバイスにとって利用可能な資源のかなりの量を消費する可能性がある。

更に、Ｗｉ−Ｆｉ技術は、高セキュリティ要件を備えたアプリケーションには理想的ではない。Ｗｉ−Ｆｉ技術を用いると、デバイスは、ネットワーク上で露出される可能性があり、それは、悪意のある攻撃を被り易い。また、Ｗｉ−Ｆｉ技術は、大量のデータをリアルタイムで搬送する（例えば、ビデオブロードキャスティングを実行する）のには適していない場合がある。何故なら、その無線プロトコルは、他の無線プロトコルのように妨害され易く、且つデータ搬送における遅延を受ける可能性があるからである。更に、Ｗｉ−Ｆｉ技術による高エネルギ消費は、スマートデバイスのバッテリ寿命を著しく低減する可能性がある。

代替として、Ｂｌｕｅｔｏｏｔｈ技術が、短距離少量データ通信を支援するために使用され得る。Ｂｌｕｅｔｏｏｔｈ通信接続は、実現するのが簡単であり、且つネットワークを確立するのが容易である。また、Ｂｌｕｅｔｏｏｔｈ技術は、比較的電力消費が少なく、且つ高い通信セキュリティを享受する。

しかしながら、Ｂｌｕｅｔｏｏｔｈ技術は、帯域幅が小さい（例えば、約１Ｍｂｉｔ）ので、リアルタイムの大量データ伝送を実行するためには適していない。また、Ｂｌｕｅｔｏｏｔｈプロトコルスタックは、複雑で取り扱うのが難しく、通常Ｂｌｕｅｔｏｏｔｈモジュールの購入を必要とする、即ち、余分なハードウェアコストを伴う。更に、Ｂｌｕｅｔｏｏｔｈ技術のユーザ体験は、実際の使用の前にデバイスが対にされる必要があるので、理想的ではない。

従って、より良いユーザ体験を達成するために、異なるモバイルプラットフォームとスマートデバイスを容易に、確実に、且つ安全に接続する必要がある。これは、本発明の実施形態が取り組むように意図されている一般的な領域である。

本明細書で説明されるのは、異機種環境においてデータ通信を支援できるシステム及び方法である。システムは、第１のデバイスと第２のデバイスとの間の接続を確立することができ、接続は、プロトコルに基づき、プロトコルは、ホストモード又はアクセサリモードを１つ又は複数の接続されたデバイスと関連付ける。更に、第１のデバイス上のコントローラは、第２のデバイスと関連するデバイスタイプを決定することができ、且つ第１のデバイスと第２のデバイスとの間のデータ通信を取り扱うために、第２のデバイスと関連する決定されたデバイスタイプに基づいて、第１のデバイスを、ホストモード又はアクセサリモードのいずれかに決定することができる。

本発明の様々な実施形態による、異なるデバイス間のデータ通信を確立する例示的な図である。 本発明の様々な実施形態による、異機種環境においてデータ通信を支援する例示的な図である。 本発明の様々な実施形態による、接続されたデバイス用のデバイスタイプを決定する例示的な図である。 本発明の様々な実施形態による、異機種環境においてＩＯＳデバイスと接続するためにアクセサリモードを用いる第三者デバイスの例示的な図である。 本発明の様々な実施形態による、異機種環境においてＡＮＤＲＯＩＤデバイスと接続するためにホストモードを用いる第三者デバイスの例示的な図である。 本発明の様々な実施形態による、異機種環境においてデータ通信を支援するフローチャートを示す。

本発明は、添付の図面の図において、限定ではなく例として示され、図において、同様の参照符号は、同様の要素を示す。本開示において、「ある（ａｎ）」、「１つの（ｏｎｅ）」、又は「幾つかの」実施形態への言及は、必ずしも同じ実施形態に対してではなく、かかる言及は、少なくとも１つを意味する。

下記のような本発明の説明は、データ通信プロトコル用の例として、ユニバーサルシリアルバス（ＵＳＢ）プロトコルを用いる。他のタイプのデータ通信プロトコルが、制限なしに使用可能であることが、当業者には明らかであろう。

本発明の様々な実施形態に従って、システム及び方法は、デバイス、例えば第三者スマートハードウェアと、Ａｎｄｒｏｉｄプラットフォーム及びＩＯＳプラットフォームなどの異なるモバイルプラットフォームに基づいたデバイスとの間の接続を取り扱うことができる。

図１は、本発明の様々な実施形態による、異なるデバイス間のデータ通信を確立する例示的な図である。図１に示されているように、データ通信環境１００は、デバイス１０１及びデバイス１０２を含み、それらのデバイスは、接続部１１０を介してデータを交換することができる。

接続部１１０は、データ通信プロトコル１２０、例えばユニバーサルシリアルバス（ＵＳＢ）プロトコルに基づくことができる。ＵＳＢプロトコルは、ＵＳＢバスを用いるが、ＵＳＢバス上のただ１つのデバイスだけがホストモードであることができるようにし、ホストモードにおけるデバイスは、バスに電力を供給し、且つホストモードにおけるデバイスと接続する他のデバイスを列挙する。

ＵＳＢプロトコルは、高帯域、低待ち時間、及び低コストという利点を有する。従って、ＵＳＢプロトコルは、リアルタイムビデオブロードキャスティングなどの大量のリアルタイムデータ伝送を支援するために用いることができる。更に、ＵＳＢバスは、ホットプラグ及び柔軟な電力供給を支援し、且つプロセッサ周辺装置を支援するために用いることができる。

更に、接続部１１０は、Ｗｉ−Ｆｉプロトコル及びＢｌｕｅｔｏｏｔｈプロトコルなどの他の通信プロトコルに基づくことができる。また、ＵＳＢインターフェースは、充電インターフェースとして用いることができる。

図１に示されているように、デバイス１０１は、コントローラ１０３を含むことができ、コントローラ１０３は、デバイス１０１と関係のある接続部１１０の状態を制御する。例えば、状態は、ホストモード（例えば、ＵＳＢプロトコルによって規定されるようなＨＯＳＴモード）又は接続されたデバイス１０１〜１０２と関連付けることができるアクセサリモード（例えば、ＤＥＶＩＣＥモード）のいずれかとすることができる。

本発明の様々な実施形態によれば、ひとたびデバイス１０２が、デバイス１０１と物理的に接続されると、コントローラ１０３は、デバイス１０２と関連するデバイスタイプを決定することができる。例えば、コントローラ１０３は、ベンダー識別子（ＶＩＤ）及び製品識別子（ＰＩＤ）のうち少なくとも１つなどのデバイス記述子に基づいて、デバイスと関連するデバイスタイプを決定することができる。

デバイス１０２と関連する決定されたデバイスタイプに基づいて、コントローラ１０３は、第１のデバイスと第２のデバイスとの間のデータ通信を取り扱うために、デバイス１０１を、ホストモード又はアクセサリモードのいずれかに決定することができる。例えば、デバイス１０１は、デフォルトとしてホストモード（例えば、ＵＳＢ ＨＯＳＴ ＭＯＤＥ）に決定することができる。

次に、接続部１１０を介して、デバイス１０１は、デバイス１０２上のアプリケーション１０４に１つ又は複数のビデオデータを送信し、且つデバイス１０２上のアプリケーション１０４から１つ又は複数のコマンドを受信することができる。

図２は、本発明の様々な実施形態による、異機種環境においてデータ通信を支援する例示的な図である。図２に示されているように、デバイス２０１は、異機種環境２００において異なるタイプのデバイスと接続することができる。

本発明の様々な実施形態に従って、これらの異なるタイプのデバイス（又は端末）は、異なるＵＳＢインターフェースを用いても良い。様々なＵＳＢインターフェース間の差異故に、第三者ハードウェアは、異なるタイプのデバイス（又は端末）に接続するために異なるタイプのコネクタを提供する必要があり得、それは、工業デザイン用の困難を増加させ、且つより多くのハードウェアコストをもたらす。

例えば、ＡＮＤＲＯＩＤデバイスは、ＭＩＣＲＯ ＵＳＢ標準に基づいたソケットを用いても良く、一方でＩＯＳデバイスは、ＬＩＧＨＴＮＩＮＧ標準に基づいたソケットを用いる。ＭＩＣＲＯ ＵＳＢインターフェース及びＬＩＧＨＴＮＩＮＧインターフェースの両方を支援するために、第三者ハードウェアは、異なるソケット、即ちＡＮＤＲＯＩＤデバイスに接続するためのＭＩＣＲＯ ＵＳＢソケット及びＩＯＳデバイスに接続するためのＬＩＧＨＴＮＩＮＧソケットを提供する必要があり得る。

本発明の様々な実施形態によれば、システムは、異機種環境２００において、デバイス２０１を異なるタイプのデバイスと接続するために同じソケットを用いることができる。

図２に示されているように、デバイス２０１は、ＩＯＳデバイス２０３及びＡｎｄｒｏｉｄデバイス２０２と接続するためのソケット２２０を用いることができる。例えば、デバイス２０１は、外部の物理インターフェース、例えばＵＳＢ ＴＹＰＥ Ａソケットを提供する第三者アクセサリとすることができる。また、デバイス２０１は、ＵＳＢオンザゴー（ＯＴＧ）周辺装置を備えたプロセッサを有することができ、ＵＳＢ ＯＴＧは、ＵＳＢ ＨＯＳＴ ＭＯＤＥに決定される。

ＵＳＢケーブルが、ＡＮＤＲＯＩＤデバイス２０２をデバイス２０１と接続するために使用され、コネクタ２１２が、ＭＩＣＲＯ ＵＳＢソケット２１１にプラグ接続され、コネクタ２１３が、ＵＳＢ ＴＹＰＥ Ａソケット２２０にプラグ接続され得る。代替として、異なるＵＳＢケーブルが、ＩＯＳデバイス２０３をデバイス２０１と接続するために使用され、コネクタ２２２が、ＬＩＧＨＴＮＩＮＧタイプソケット２１１にプラグ接続され、コネクタ２２３が、ＵＳＢ ＴＹＰＥ Ａソケット２２０にプラグ接続され得る。

更に、第三者デバイス２０１が、充電インターフェースとしてもまた使用され得る、ＵＳＢ ＴＹＰＥ Ａソケット２２０などのソケットを用いることが有益である。何故なら、ユーザが、異なるモバイルデバイス２０２〜２０３を第三者デバイス２０１と接続するために当初の充電ケーブルを使用することができるからである。

デバイス２０１が、Ａｎｄｒｏｉｄデバイス２０２と接続された後で、デバイス２０１は、Ａｎｄｒｏｉｄデバイス２０２上のアプリケーション２０４とデータを交換するために、通信インターフェース、例えばＡｎｄｒｏｉｄオープンアクセサリ（ＡＯＡ）インターフェースを用いることができる。また、デバイス２０１は、デバイス２０１がＩＯＳデバイス２０２と接続された後で、ＩＯＳデバイス２０２上のアプリケーション２０５とデータを交換するために、通信インターフェース、例えばＭａｄｅ ｆｏｒ ＩＯＳ（ＭＦＩ）インターフェースを用いることができる。

図３は、本発明の様々な実施形態による、接続されたデバイスのデバイスタイプを決定する例示的な図である。図３に示されているように、第三者デバイス用のコントローラは、異機種環境３００において、接続されたデバイスと関連するデバイスタイプを検出すること、例えば接続されたデバイスが、Ａｎｄｒｏｉｄデバイスか又はＩＯＳデバイスかどうかを決定することができる。

ステップ３０１において、第三者デバイスは、第三者デバイス上のソケットへのコネクタのプラグ接続を検出することができる。第三者デバイス上のコントローラは、デバイス用のベンダー識別子（ＶＩＤ）及び製品識別子（ＰＩＤ）のうち少なくとも１つなど、デバイス用のデバイス記述子を（要求及び）取得することができる。

ステップ３０２において、コントローラは、検出された記述子が、ＩＯＳ記述子と一致するかどうか（例えば、ＶＩＤが「０５ＡＣ」かどうか）をチェックすることができる。ステップ３０３において、コントローラは、検出された記述子がＩＯＳ記述子と一致する場合に（即ち、ＶＩＤが０５ＡＣである）、デバイスがＩＯＳデバイスであると決定することができる。

本発明の様々な実施形態に従って、システムは、接続されたデバイスが、開システムに関連しているかどうかをチェックする前に、接続されたデバイスが、閉システムに関連しているかどうかをチェックすることができる。その理由は、ＩＯＳシステムなどの閉システム用のデバイスが、１つ又は複数の一意の記述子を有すると考えられ、一方で同じ推論が、ＡＮＤＲＯＩＤシステムなどの開システムには必ずしも真だとは限らない場合があることである。

換言すれば、ＩＯＳ記述子以外のデバイス記述子を備えた接続されたデバイスは、ＩＯＳデバイスではない。他方で、ＡＮＤＲＯＩＤ記述子以外のデバイス記述子を備えた接続されたデバイスが、実際にはＡＮＤＲＯＩＤデバイスであるという可能性がある。

ステップ３０４において、検出された記述子がＩＯＳ記述子と一致しない場合に（即ち、ＶＩＤは「０５ＡＣ」ではない）、コントローラは、検出された記述子が、ＡＮＤＲＯＩＤ記述子と一致するかどうか（例えば、ＶＩＤ：ＰＩＤが、「１８Ｄ１：２Ｄ００」又は「１８Ｄ１：２Ｄ０１」であるかどうか）をチェックすることができる。

ステップ３０５において、コントローラは、検出された記述子が、ＡＮＤＲＯＩＤ記述子と一致する場合に（即ち、ＶＩＤ：ＰＩＤが、「１８Ｄ１：２Ｄ００」又は「１８Ｄ１：２Ｄ０１」である）、デバイスがＡＮＤＲＯＩＤデバイスであると決定することができる。

更に、たとえ検出された記述子がＡＮＤＲＯＩＤ記述子と一致しない場合でも、接続されたデバイスが、実際にはＡＮＤＲＯＩＤデバイスである可能性がある。ステップ３０６において、コントローラは、明示的に通信を開始するために、接続されたデバイスにＡＯＡ制御コマンドを送信することができる。次に、ステップ３０７において、コントローラは、成功的な肯定応答（ＡＣＫ）が、接続されたデバイスから受信されたかどうかをチェックすることができる。成功的な肯定応答（ＡＣＫ）が、受信された場合に、コントローラは、デバイスがＡＮＤＲＯＩＤデバイスであると決定することができる。そうでなければ、ステップ３０８において、コントローラは、デバイスを無視し、デバイスのタイプが未知であると見なしても良い。

図４は、本発明の様々な実施形態による、異機種環境においてＩＯＳデバイスと接続するためにアクセサリモードを用いる第三者デバイスの例示的な図である。図４に示されているように、デバイス４０１は、異機種環境４００においてデバイス４０２と接続することができる。

更に、ひとたびデバイス４０２がデバイス４０１に接続すると、デバイス４０１上のコントローラ４０３は、デバイス４０２用のベンダー識別子（ＶＩＤ）４２１を検出することができる。例えば、ＶＩＤが「０５ＡＣ」である場合に、デバイス４０２は、ＩＯＳデバイスである。ＩＯＳデバイス４０２は、デバイス４０１などの第三者アクセサリと接続するためのＭＦＩ接続インターフェースを提供することができる。ＭＦＩインターフェースは、ＤＥＶＩＣＥ ＭＯＤＥ、ＨＯＳＴ ＭＯＤＥ及びＲＯＬＥ ＳＷＩＴＣＨなどの幾つかのモードを含んでも良い。

デバイス４０１上のコントローラ４０３は、ＨＯＳＴ ＭＯＤＥに入るようにＩＯＳデバイス４０２に命令するためのＲＯＬＥ ＳＷＩＴＣＨコマンドをＩＯＳデバイス４０２に送信することができる。また、デバイス４０１上のコントローラ４０３は、デバイス４０１を、アクセサリモードに決定することができる。例えば、デバイス４０１上のコントローラ４０３は、デフォルトのＵＳＢ ＨＯＳＴ ＭＯＤＥからＵＳＢ ＤＥＶＩＣＥ ＭＯＤＥにＵＳＢ ＯＴＧの役割を逆にすることができる。次に、デバイス４０１は、ホストノード（即ち、ＩＯＳデバイス４０２）がデータ通信を開始するのを待つことができる。

従って、ＵＳＢ ＨＯＳＴ ＭＯＤＥのＩＯＳデバイス４０２は、ＭＦＩインターフェースを利用することによって、デバイス４０１とのデータ接続を確立することができる。例えば、ＩＯＳアプリケーション４０４は、デバイス４０１などの第三者アクセサリとデータを交換するためのＭＦＩ ＥＡ ＮＡＴＩＶＥ ＴＲＡＮＳＰＯＲＴ ＡＰＩインターフェースを利用することができる。

図５は、本発明の様々な実施形態による、異機種環境においてＡＮＤＲＯＩＤデバイスと接続するためにホストモードを用いる第三者デバイスの例示的な図である。図５に示されているように、デバイス５０１は、異機種環境５００においてデバイス５０２と接続することができる。

更に、ひとたびデバイス５０２がデバイス５０１と接続すると、コントローラ５０３は、デバイス５０２用のベンダー識別子（ＶＩＤ）５２１を検出することができる。例えば、ＶＩＤ：ＰＩＤが「１８Ｄ１：２Ｄ００」又は「１８Ｄ１：２Ｄ０１」である場合に、デバイス５０２は、Ａｎｄｒｏｉｄデバイスとして識別される。

ＡＮＤＲＯＩＤデバイス５０２は、第三者アクセサリと接続するためのＡＯＡ接続インターフェースを提供する。また、Ａｎｄｒｏｉｄ ＡＯＡ接続インターフェースは、例えばＵＳＢ ＤＥＶＩＣＥモードを用いて、アクセサリモードで提供することができる。

デバイス５０１は、デフォルトとしてホストモードであるが、ＡＯＡプロトコルに基づいたＡＰＩを介して、データ通信を確立するためのメッセージをＡＮＤＲＯＩＤデバイス５０２に送信することができる。例えば、アプリケーション５０４は、ＡＮＤＲＯＩＤ ＡＰＰであるが、デバイス５０１などの第三者アクセサリとのデータ交換を支援するためにＡＯＡベースＡＰＩを用いることができる。

他方で、ＶＩＤ５２１が認識できない場合に、デバイス５０１は、ＡＯＡモードに入るようにデバイス５０２に明示的に命令するために制御コマンドをデバイス５０２に送信しようと試みても良い。肯定応答（ＡＣＫ）が成功した場合に、コントローラ５０３は、デバイス５０２がＡＯＡモードを支援すると仮定することができ、コントローラは、ＡＯＡに関連するＡＰＩを介して、デバイス５０２とデータを通信することができる。

肯定応答（ＡＣＫ）が成功しない場合、例えばデバイス５０２がデバイス５０１に応答しないか、又はエラーメッセージで応答する場合に、デバイス５０１は、デバイス５０２を無視することを決定しても良い。

図６は、本発明の様々な実施形態に従って、異機種環境においてデータ通信を支援するフローチャートを示す。図６に示されているように、ステップ６０１において、第１のデバイスと第２のデバイスとの間で接続を確立することができ、接続は、プロトコルに基づいており、プロトコルは、ホストモード又はアクセサリモードを１つ又は複数の接続されたデバイスと関連付ける。次に、ステップ６０２において、第１のデバイス上のコントローラは、第２のデバイスと関連するデバイスタイプを決定することができる。更に、ステップ６０３において、第１のデバイス上のコントローラは、第１のデバイスと第２のデバイスとの間のデータ通信を取り扱うために、第２のデバイスと関連する決定されたデバイスタイプに基づいて、第１のデバイスを、ホストモード又はアクセサリモードのいずれかに決定することができる。

本発明の多くの特徴は、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせを用いて、又はそれらの支援で実行することができる。従って、本発明の特徴は、処理システム（例えば、１つ又は複数のプロセッサを含む）を用いて実行されても良い。例示的なプロセッサは、限定するわけではないが、１つ又は複数の汎用マイクロプロセッサ（例えば、シングル又はマルチコアプロセッサ）、特定用途向け集積回路、特定用途向け命令セットプロセッサ、グラフィックス処理ユニット、物理処理ユニット、デジタル信号処理ユニット、コプロセッサ、ネットワーク処理ユニット、オーディオ処理ユニット、暗号化処理ユニットなどを含むことができる。

本発明の特徴は、本明細書で提示される特徴のいずれかを実行するように処理システムをプログラムするために用いることができる命令を自らに記憶した記憶媒体又はコンピュータ可読媒体であるコンピュータプログラムプロダクトを用いて又はその支援で実行することができる。記憶媒体は、限定するわけではないが、フロッピーディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、並びに光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気若しくは光カード、ナノシステム（分子メモリＩＣを含む）、又は命令及び／若しくはデータを記憶するのに適した任意のタイプの媒体若しくはデバイスを含む任意のタイプのディスクを含むことができる。

機械可読媒体のいずれか１つの上に記憶されると、本発明の特徴は、処理システムのハードウェアを制御するための、且つ処理システムが、本発明の結果を利用する他の機構と相互作用できるようにするためのソフトウェア及びファームウェアのうち少なくとも１つに組み込むことができる。かかるソフトウェア又はファームウェアは、限定するわけではないが、アプリケーションコード、デバイスドライバ、オペレーティングシステム及び実行環境／コンテナを含んでも良い。

本発明の特徴はまた、例えば、特定用途向け集積回路（ＡＳＩＣ）及びフィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイスなどのハードウェアコンポーネントを用いるハードウェアにおいて実行されても良い。本明細書で説明される機能を実行するためのハードウェア状態機械の実装形態は、当業者には明らかであろう。

更に、本発明は、本開示の教示に従ってプログラムされた１つ又は複数のプロセッサ、メモリ、及びコンピュータ可読記憶媒体のうち少なくとも１つを含む１つ又は複数の従来の汎用又は専用デジタルコンピュータ、計算デバイス、機械又はマイクロプロセッサを用いて便利な方法で実施されても良い。適切なソフトウェアコーディングは、ソフトウェア分野の当業者には明らかなように、本開示の教示に基づいた熟練したプログラマによって容易に準備することができる。

本発明の様々な実施形態が、上記で説明されたが、それらが、限定ではなく例として提示されたことを理解されたい。形態及び詳細における様々な変更が、本発明の趣旨及び範囲から逸脱せずに、形態及び詳細においてなし得ることが、当業者には明らかであろう。

本発明は、特定の機能の性能及びそれらの機能の関係を示す機能的構造ブロックの助けによって上記で説明された。これらの機能的構造ブロックの境界は、説明の便宜のために、本明細書においてしばしば任意に画定された。特定の機能及びそれらの関係が適切に実行される限り、代替の境界を画定することができる。従って、かかる任意の代替の境界は、本発明の範囲及び趣旨内である。

本発明の前述の記載は、実例及び説明のために提供された。それは、包括的であるようにも、開示された形態に本発明を正確に制限するようにも意図されていない。本発明の幅及び範囲は、上記の例示的な実施形態のいずれによっても制限されるべきではない。多くの修正及び変形が、当業者には明らかであろう。修正及び変形は、開示された特徴の任意の適切な組み合わせを含む。実施形態は、本発明の原理及びその実際的な適用を最も良く説明するために選択及び記載され、それによって、他の当業者が、様々な実施形態のための、且つ考えられる特定の使用に適した様々な修正を備えた本発明を理解できるようにする。本発明の範囲が、以下の請求項及びそれらの均等物によって定義されることが意図されている。

Claims (25)

1. 異機種環境においてデータ通信を支援するための方法であって、
   プロトコルに基づいて、第１のデバイスと第２のデバイスとの間で接続を確立するステップであって、前記プロトコルが、ホストモード又はアクセサリモードを１つ又は複数の接続されたデバイスと関連付けるステップと、
   前記第１のデバイス上のコントローラを介して、前記第２のデバイスと関連するデバイスタイプを決定するステップであって、前記第２のデバイスがＡＮＤＲＯＩＤシステムと関連するかどうかをチェックする前に、前記第２のデバイスがＩＯＳシステムと関連するかどうかをチェックする、デバイスタイプを決定するステップと、
   前記第１のデバイスと前記第２のデバイスとの間のデータ通信を取り扱うために、前記決定されたデバイスタイプに基づいて、前記第１のデバイスを、前記ホストモード又は前記アクセサリモードのいずれかに決定するステップと
   を含む方法。
2. 前記第１のデバイスを異なるタイプのデバイスと接続するために前記第１のデバイス上のソケットを用いるステップを更に含む、請求項１に記載の方法。
3. 前記ソケットが、前記異なるタイプのデバイスと関連する充電インターフェースに適合される、請求項２に記載の方法。
4. 前記第１のデバイスが前記第２のデバイスと接続された後で、第１の通信インターフェースを用いて、前記第１のデバイスと前記第２のデバイスとの間でデータを交換するステップを更に含む、請求項１〜３のいずれか一項に記載の方法。
5. 前記ソケットを介して第３のデバイスを前記第１のデバイスと接続するステップであって、前記第３のデバイスが、前記第２のデバイスと異なるデバイスタイプを有するステップと、
   前記第１のデバイスが前記第３のデバイスと接続された後で、第２の通信インターフェースを用いて、前記第１のデバイスと前記第３のデバイスとの間でデータを交換するステップと
   を更に含む、請求項２〜４のいずれか一項に記載の方法。
6. デバイス記述子を用いて、第２のデバイスと関連する前記デバイスタイプを決定するステップを更に含む、請求項１〜５のいずれか一項に記載の方法。
7. デバイス記述子が、ベンダー識別子（ＶＩＤ）及び製品識別子（ＰＩＤ）のうち少なくとも１つを含む、請求項６に記載の方法。
8. 前記第１のデバイスが、前記ホストモードをデフォルトとするステップを更に含む、請求項１〜７のいずれか一項に記載の方法。
9. 前記第２のデバイスが特定のデバイスタイプにある場合に、前記第１のデバイスを前記ホストモードから前記アクセサリモードに切り替えるステップと、
   ロールスイッチングメッセージを前記第２のデバイスに送信するステップと、
   前記第２のデバイスがデータ通信を開始するのを待つステップと
   を更に含む、請求項８に記載の方法。
10. 前記第１のデバイスが前記ホストモードである場合に、データ通信を開始するために、前記第１のデバイスから前記第２のデバイスにメッセージを送信する、請求項１〜９のいずれか一項に記載の方法。
11. 前記第２のデバイスが、前記第１のデバイスに応答しないか、又はエラーメッセージで応答する場合に、前記第２のデバイスを無視する、請求項１０に記載の方法。
12. １つ又は複数のビデオデータを前記第１のデバイスから前記第２のデバイス上のアプリケーションに送信するステップと、
    前記第１のデバイスを介して、前記第２のデバイス上のアプリケーションから１つ又は複数のコマンドを受信するステップと
    を更に含む、請求項１〜１１のいずれか一項に記載の方法。
13. 異機種環境においてデータ通信を支援するためのシステムであって、
    １つ又は複数のマイクロプロセッサと、
    前記１つ又は複数のマイクロプロセッサ上で動作するコントローラであって、前記コントローラが、
    プロトコルに基づき、第１のデバイスと第２のデバイスとの間の接続を確立し、前記プロトコルが、ホストモード又はデバイスモードを１つ又は複数の接続されたデバイスに関連付け、
    前記第２のデバイスと関連するデバイスタイプを決定し、
    前記第１のデバイスと前記第２のデバイスとの間のデータ通信を取り扱うために、前記決定されたデバイスタイプに基づいて、前記第１のデバイスを、ホストモード又はデバイスモードのいずれかに決定するように動作するコントローラと
    を備え、
    前記第２のデバイスと関連する前記デバイスタイプを決定することは、前記コントローラが、前記第２のデバイスがＡＮＤＲＯＩＤシステムと関連するかどうかをチェックする前に、前記第２のデバイスがＩＯＳシステムと関連するかどうかをチェックすることを含む、システム。
14. 前記第１のデバイスを異なるタイプのデバイスと接続するように適合される、前記第１のデバイス上のソケットを更に備える、請求項１３に記載のシステム。
15. 前記ソケットが、前記異なるタイプのデバイスと関連する充電インターフェースに適合される、請求項１４に記載のシステム。
16. 前記第１のデバイスが前記第２のデバイスと接続された後で、前記第１のデバイスが、第１の通信インターフェースを用いて、前記第１のデバイスと前記第２のデバイスとの間でデータを交換する、請求項１３〜１５のいずれか一項に記載のシステム。
17. 第３のデバイスが、前記ソケットを介して前記第１のデバイスと接続され、前記第３のデバイスが、前記第２のデバイスと異なるデバイスタイプを有し、
    前記第１のデバイスが、前記第１のデバイスが前記第３のデバイスと接続された後で、第２の通信インターフェースを用いて、前記第１のデバイスと前記第３のデバイスとの間でデータを交換する、請求項１４〜１６のいずれか一項に記載のシステム。
18. 前記コントローラが、デバイス記述子を用いて第２のデバイスと関連する前記デバイスタイプを決定する、請求項１３〜１７のいずれか一項に記載のシステム。
19. 前記デバイス記述子が、ベンダー識別子（ＶＩＤ）及び製品識別子（ＰＩＤ）のうち少なくとも１つを含む、請求項１８に記載のシステム。
20. 前記第１のデバイスが、前記ホストモードをデフォルトとして構成される、請求項１３〜１９のいずれか一項に記載のシステム。
21. 前記コントローラが、
    前記第２のデバイスが特定のデバイスタイプである場合に、前記第１のデバイスを前記ホストモードから前記デバイスモードに切り替えし、
    ロールスイッチングメッセージを前記第２のデバイスに送信し、
    前記第２のデバイスがデータ通信を開始するのを待つことを更に含む、請求項２０に記載のシステム。
22. 前記第１のデバイスが前記ホストモードである場合に、前記第１のデバイスが、データ通信を開始するために、前記第２のデバイスにメッセージを送信する、請求項１３〜２１のいずれか一項に記載のシステム。
23. 前記第２のデバイスが、前記第１のデバイスに応答しないか、又はエラーメッセージで応答する場合に、前記第１のデバイスが、前記第２のデバイスを無視する、請求項２２に記載のシステム。
24. 前記第１のデバイスが、
    １つ又は複数のビデオデータを前記第１のデバイスから前記第２のデバイス上のアプリケーションに送信し、
    前記第２のデバイス上のアプリケーションから１つ又は複数のコマンドを受信する、請求項１３〜２３のいずれか一項に記載のシステム。
25. コンピュータに、
    プロトコルに基づき、第１のデバイスと第２のデバイスとの間の接続を確立するステップであって、前記プロトコルが、ホストモード又はデバイスモードを１つ又は複数の接続されたデバイスと関連付けるステップと、
    前記第１のデバイス上のコントローラを介して、前記第２のデバイスと関連するデバイスタイプを決定するステップであって、前記第２のデバイスがＡＮＤＲＯＩＤシステムと関連するかどうかをチェックする前に、前記第２のデバイスがＩＯＳシステムと関連するかどうかをチェックする、デバイスタイプを決定するステップと、
    前記第１のデバイスと前記第２のデバイスとの間のデータ通信を取り扱うために、前記決定されたデバイスタイプに基づいて、前記第１のデバイスを、ホストモード又はデバイスモードのいずれかに決定するステップと
    を実行させるプログラム。