プロセッサ間通信プロトコル
プロセッサ間通信（ＩＰＣ）プロトコルネットワークは、少なくとも１つのＩＰＣクライアント（１０２）とＩＰＣサーバ（１０８）を含む。ＩＰＣプロトコルは、ＩＰＣクライアント（１０２）がＩＰＣサーバ（１０８）に登録して、ソフトウェア・アーキテクチャ、オペレーティング・システム、ハードウェア等が何であるかという制約を受けずに自由に両者が通信する手段を提供する。本発明の１実施例によるＩＰＣプロトコルは、サーバを基にしたＩＰＣ通信管理フレームワークにおいて動的ＩＰＣノード構成を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的に電子分野に関し、特には、プロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の、多くのネットワーク要素（部品）からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信（ＩＰＣ）と呼ばれる。
【０００３】
近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。ＩＰＣの一例はＰＣＩＡＧＰコントローラ（ＰＡＣ）であって、Ｈｏｓｔ‐ｔｏ‐ＰＣＩブリッジ、ＤＲＡＭコントローラ、およびデータ経路とＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）インタフェイスを集積する。ＩＰＣの別例はＯＭＡＰ（登録商標）プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル（物理層）では設計自由度はほとんどない。
【０００４】
例えば、ＰＡＣプラットフォームは閉構造で、オペレーティング・システムのＴＡＰＩ層に埋め込まれており、ＩＰＣコードは開発者にはアクセスできない。従って、これらのプラットフォームは部品システムには拡張しないので、ＩＰＣ源の動的割り当てをできないだけでなく、ＩＰＣ源の動的割り当て、ハードウェア・サポート機能、マルチノード・ルーチングをできない。
【０００５】
リアルタイム処理アプリケーション等のアプリケーションにおける１つの問題は、異なるプロセッサ上のサービスの発見及びIPC要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する１つの側面は、無線通信装置における移動体アプリケーション(MA)等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにIPCデータを輸送し、そして、そのデータを対象のMAに再度ルーチングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう１つの側面は、専用リンク(ポート)を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るIPCプロトコルに対するニーズが、当分野に存在する。
【発明を実施するための最良の形態】
【０００６】
本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。
【０００７】
本明細書は、本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
【０００８】
IPCをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、IPCにより、その２つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、IPCは、異なるプロセッサ間において信頼性の高い通信を提供する。
【０００９】
IPCハードウェアは、異なるプロセッサをIPCネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。IPCネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる(例えば、IPCアドレス)。また、データパケットは、本発明の一実施形態におけるIPCネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する必要がある。また、好適には、パケットは、従来の周期的冗長検査(CRC)手法を用いて、エラーが無いかチェックされる。本発明のIPCネットワークのネットワークアクティビティは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ネットワーク等のIP輸送層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のIPCは、TCP/IPネットワークのようにゲートウェイにより小規模なネットワークに分割されない。
【００１０】
次に、図1において、本発明の実施形態に基づくIPCネットワーク100を示す。IPCネットワーク100には、複数のIPCクライアント102-106及び、幾つかの実例として、共有メモリ110、ユニバーサル非同期受信機／送信機(UART)112及びユニバーサル・シリアル・バス(USB)114等の異なるIPC物理リンクを用いて、IPCクライアント102-106に接続されたIPCサーバ108が含まれる。本発明のIPCにより、IPCクライアント102-106は、現IPCサーバ108と折衝して役割を交替し得ることに留意されたい。IPCクライアント102-106が、IPCサーバになるように折衝して新しいIPCサーバになる場合、残りの全てのIPCクライアントは、IPCサーバの変更があった場合、サーバのIPアドレスを変更するように指示される。
【００１１】
図2において、本発明の実施形態に基づくIPCサーバ108(又はIPCクライアント102-108)のIPCスタック200を示す。IPCスタック200は、オペレーティングシステム(OS)の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズにサポートを提供するように設計されている。IPCスタックは、次の3つの主な層から構成される。即ち、
(1)IPCプレゼンテーション・マネージャ(202)：この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間において異なるデータタイプを変換するために用いられる。
【００１２】
(2)IPCセッション・マネージャ(204)：この層は、IPCスタックと全システムコンポーネントとの間における全着信/発信IPCトラフィック用の中央リポジトリである。IPCセッション・マネージャ204は、幾つかの機能を有する。即ち、IPCコンポーネントを参加させるためのコンポーネントIDの割当て；IPCデータを隠蔽する必要があるかどうかの判断；IPCデータのルーチング、IPCトラフィックの終止；IPCプロセッサ用のプレースホルダ；IPCアドレスの提供、IPCクライアントの割当及び認証等を有する。
【００１３】
IPCトランスポート層(208)：IPCセッション・マネージャ(層)204内に配置される。IPCトランスポート層208は、異なるプロセッサ間において、IPCデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、IPCトランスポート層208は、IPCメッセージを、IPCネットワーク100上のそれらの最終宛先にルーチングする役割を担う。トランスポート層のルーチング機能は、IPCサーバ上でのみ使用可能である。
【００１４】
IPCルータブロック(210)：宛先コンポーネント（図示せず）にIPCデータを輸送する。着信IPCメッセージは、とりわけ、音声及びモデム等の発生元コンポーネントID、IPCメッセージOPコードを搬送する。本発明の実施形態によれば、固有のOPコードが、IPCネットワークに接続された音声及びモデム等の各コンポーネント/ソフトウェア・スレッドに割り当てられることに留意されたい(例えば、図５の502参照)。IPCセッション・マネージャ204は、ルータブロック210に依拠して、IPCデータを正しいコンポーネント（１つ又は複数）に送る。
【００１５】
(3)デバイス・インターフェイス層(206)：IPC物理対論理IPCチャネルを管理する役割を果たす。その主な機能は、スタックIPCがハードウェアに依存しなくなるように、IPCハードウェアを完全に抽出することである。デバイス・インターフェイス層206は、直下のIPCリンクの物理帯域幅を管理して全IPC論理チャネルをサポートする。着信経路において、デバイス・インターフェイス層206は、異なる物理チャネル110-114からデータを傍受して、それらを残りのIPCスタックに渡す。発信経路上では、デバイス・インターフェイス層206は、IPC論理チャネルのデータローディングを、それらを適切な物理チャネル上に送ることによって管理する。また、デバイス・インターフェイス層206は、同じIPCチャネルに属するIPCパケットの連結を行い、その後、それらをIPCハードウェアに送る。チャネル要件は、IPCセッション・マネージャ204とIPCデバイス・インターフェイス層206との間で事前に折衝される。デバイス・インターフェイス層206は、ハードウェアポートを備え、これは、IPCクライアント102-106とのデバイス・インターフェイスを提供する。
【００１６】
図3において、IPCコンポーネントID割当てルーチンを示す。IPC通信に加わりたい新しいコンポーネントは、いずれも、(例えば、セッション・マネージャ204等の)そのIPCセッション・マネージャから、ステップ302において、IPC識別番号(ID)をまず要求することによって、そうしなければならない。すると、ローカル・セッション・マネージャ(例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ)は、新しいIPCコンポーネントのIPCサーバ・セッション・マネージャを呼出し、ステップ304において、コンポーネントID割当てを行う。本発明の実施形態によれば、コンポーネントIDは、動的であり、セッション・マネージャによって割り当てられる。主なIPCサーバ位置は、最も可能性が高いのは、主AP上である。各IPCノードは、好適には、固有のIPCノードIDを有し、セッション・マネージャは、そのデータベース中に、各関係IPCノード用の以下の情報を保持する。即ち、
IPCノードタイプ：例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
【００１７】
IPCアドレス：IPCノードのIPCアドレス
データタイプ：IPCノードのデータタイプ
OPコードリスト：これは、コンポーネントが申し込んだ全IPCメッセージOPコードのリストである。
【００１８】
コンポーネントID：全コンポーネントIDのリスト
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。動的ルーチング表402には、ノードタイプ、IPCアドレス/ポート#情報、データタイプ及び申込みリストが含まれる。コンポーネント・ルーチング・テーブル404には、OPコード情報と各特定のOPコードに申し込んだ全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
【００１９】
図5において、本発明の実施形態に基づくIPCスタックが、ソフトウェア・スレッド等(例えば、音声等)のコンポーネントにIPCチャネルを如何に提供するかのブロック図を示す。コンポーネント502は、まず、ステップ504において、IPCチャネルを要求する。図5に示すセッション・マネージャは、定義されたAPIを用いて、ステップ506において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層(デバイスインターフェイス)は、データチャネル508等のハードウェア資源を要求する。要求に応答して、図5に示すセッション・マネージャは、ステップ510において、要求側にIPCチャネルを与える。次に、コンポーネント502は、割り当てられたチャネル508上でそのデータを送る。そして、デバイス層は、IPCネットワークにデータを転送する。論理から物理チャネルIDへのマッピングは、IPCデバイス・インターフェイスの機能である。
【００２０】
次に、図6において、IPCクライアント初期化における第１ステップは、IPCクライアント602とIPCサーバ604との間において、登録要求(ステップ606)を送信することである。そして、IPCサーバ604は、ステップ608において、IPCクライアント602による要求を認証する。この後、IPCアドレスが、IPCクライアントに送信され、ステップ610において登録が完了する。IPCクライアントのセッション・マネージャは、ステップ612において、その動的ルーチング表のコピーをIPCサーバに送る。
【００２１】
IPCクライアント初期化プロセス時に行われる詳細なステップを図7に示す。クライアント・セッション・マネージャ(セッション(クライアント)としてテーブルに示す)は、ステップ702において、IPCサーバのセッション・マネージャ(セッション(サーバ)としてテーブルに示す)に設定要求を送る。ステップ704において、認証は、IPCサーバのセッション・マネージャによって要求される。そして、IPCクライアントとIPCサーバとの間の認証は、ステップ706で実行される。
【００２２】
設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ702において、設定要求に応答して、セッションサーバは、要求側にIPCアドレスを割り当てる。また、もしなければ、要求側用の動的ルーチング表を設定する。そして、ステップ708において、要求側に設定指示を送る。設定指示パラメータには、サーバのIPCアドレス及びクライアントの新規に割り当てられたIPCアドレスが含まれる。
【００２３】
設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御/データを要求し得る。そして、セッションクライアントは、ステップ710において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、ステップ710における設定指示確認メッセージの受信時、パラメータを有さず、セッションサーバは、新規に設定されたセッションクライアントへのIPCストリームを起動し得る。そして、セッションサーバは、ステップ712及び714において、セッションクライアントに設定更新メッセージを送る。これによって、図7に示す両セッションクライアントは、それらのそれぞれの動的ルーチング表（図示せず）を更新し、ステップ716及び718において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、全ての参加したIPCが、更新されたことを確認する。
【００２４】
パケットは、IPCセッション・マネージャによって受信される時、送信元コンポーネントID、宛先ID、チャネルID及びBP又はAPのタイプが含まれるデータの形態でやって来る。IPCセッション・マネージャは、宛先IDが挿入されていない場合、宛先コンポーネントIDを付加する。また、IPCセッション・マネージャは、IPCアドレスを挿入する。受信されたメッセージOPコードに基づき宛先IDを発見するのは、IPCセッション・マネージャである。宛先IDは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいIPCメッセージOPコードに申し込む(例えば、音声コンポーネントが、IPCセッション・マネージャに要求を送信することによって音声メッセージに申し込む)度に、動的に更新される。
【００２５】
図8において、コンポーネントと本発明の実施形態に基づくそのIPCセッション・マネージャとの間における一般的な宛先ID発見シーケンス時の一連のイベントを示す。ステップ802において、コンポーネントは、その送信元ID(宛先IDはない)、宛先BP又はAPのタイプ、及びヘッダ及びデータが含まれるIPCデータを送る。ステップ804において、IPCセッション・マネージャは、対応する動的ルーチング表を検索し、正しい宛先アドレスを見つけるために、IPCデータヘッダOPコード、及び宛先BP又はAPのタイプを見る。ステップ806において、IPCセッション・マネージャは、コンポーネントのIPCアドレスを挿入し、それをデバイス層に送る。
【００２６】
図9において、IPCコンポーネント初期化時に行われる代表的なステップを示す。BPが、図9に示すIPCサーバによって一旦設定されると、コンポーネント902等のコンポーネントは、異なるサービスに申し込み得る。コンポーネントは、ステップ904において、音声や映像等の機能にそれら自体申し込む。そして、コンポーネント申込み情報は、IPCセッション・マネージャに送られ、(IDがまだ割り当てられていない場合)コンポーネントIDの生成が行われ、また、特定のI PCアドレス用動的ルーチング表の生成又は更新が行われる(ステップ906)。ステップ908において、セッション・マネージャは、ステップ906からの情報でIPCサーバを更新する。ステップ908において、更新された動的ルーチング表を受信すると、ステップ912において、更新の確認が、IPCサーバによってIPCクライアントに送信される。サーバが、一旦呼び出されると、新しい動的ルーチング表更新内容は、関係する全プロセッサステップ910に一斉送信される。
【００２７】
図10において、同じコンポーネント初期化プロセスを、コンポーネント(クライアント)1002と、クライアント・セッション・マネージャ1004としても知られているセッション(クライアント)と、サーバ・セッション・マネージャ1006としても知られているセッション(サーバ)との間に示す。ステップ1008におけるコンポーネント設定要求は、コンポーネント(クライアント)1002によって送信される。要求に応答して、クライアント・セッション・マネージャ1004は、デバイス層（図示せず）と論理チャネルを取り決める。また、クライアント・セッション・マネージャ1004は、コンポーネントIDを割当て、その動的ルーチング表（図示せず）に新しいOPコードリストを付加する。ステップ1010において、クライアント・セッション・マネージャ1004は、パラメータとして、コンポーネントID及びチャネルIDが含まれる設定応答を送る。設定応答に応じて、コンポーネント(クライアント)1002は、そのID及びチャネルIDをクライアントのセッション・マネージャ1004から受信する。
【００２８】
一旦クライアント・セッション・マネージャ1004が、ステップ1008における設定要求に対して、ステップ1010で返信すると、クライアント・セッション・マネージャ1004は、ステップ1012において、セッションサーバ(サーバ・セッション・マネージャ)1006に設定更新要求を送る。設定更新要求のパラメータは、動的ルーチング表（図示せず）において行われた何らかの新しい変更である。サーバのセッション・マネージャ1006は、そのIPCアドレス用の動的ルーチング表を更新する。そして、ステップ1016において、サーバのセッション・マネージャ1006は、全てのIPCクライアント（図示せず）に設定更新内容を送り、その間、ステップ1014において、クライアントのセッション・マネージャ1004に設定更新指示を送る。サーバのセッション・マネージャ1006は、サーバが、送られた変更でそのルーチングテーブルを更新したことを確認する。
【００２９】
パラメータ(１つ又は複数)として動的ルーチング表を含むステップ1016の設定更新メッセージにおいて、セッションサーバ1006は、動的ルーチング表を更新し、ステップ1018において、設定更新確認メッセージを送る。そして、サーバは、参加した全IPCが更新されたことを確認する。
【００３０】
IPCセッション・マネージャは、着信及び発信IPCパケットのルーチング経路を決定する。発信パケットのルートは、コンポーネントのIPCアドレスによって決定される。宛先アドレスが、ローカルプロセッサのそれであると分かった場合、オペレーティングシステム(OS)へのIPCのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルIPCクライアント用であると分かった場合、パケットは、IPCスタックに送られ、更に処理(例えば、隠蔽)される。宛先コンポーネントが、IPCパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、隠蔽は不要であり、パケットは、通常のOSメッセージ呼出し(例えば、マイクロソフト・メッセージ・キュー等)を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の修正について心配する必要はない。必要なことは、それらのメッセージ書き込み方法を、むしろOS特有の設計からIPC呼出しに変更することだけである。
【００３１】
着信パケットの場合、メッセージの宛先アドレスが、IPCサーバのものと等しくない場合、着信パケットは、妥当なIPCクライアントにルーチングされる。着信パケットのルーチングは、IPCサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先IDが、有効なコンポーネントIDに又は0XFFに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。
【００３２】
IPCルータブロック(例えば、図2におけるIPCルータブロック210参照)は、宛先コンポーネントにIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントID、及び音声やモデム用等のIPCメッセージOPコードを搬送する。IPCセッション・マネージャは、そのコンポーネント・ルーチング・テーブルに依拠して、正しいコンポーネント(１つ又は複数)にIPCデータを送る。動的ルーチング表及びコンポーネント・ルーチング・テーブルは、双方共、IPCサーバ/クライアントによって更新される。
【００３３】
起動時、各コンポーネントは、そのセッション・マネージャにそれ自体登録して、IPCコンポーネントIDを取得しなければならない。更にまた、音声やモデム等の着信IPCメッセージを申し込まなければならない。この情報は、コンポーネント・ルーチング・テーブルに記憶され、IPCセッション・マネージャによって用いられる。
【００３４】
図11に示すように、コンポーネント(例えば、ソフトウェア・スレッド)1102が、ステップ1104において、そのデータ要求をIPCセッション・マネージャに送る場合、宛先IPCノード(例えば、BP)についてチェックが行われる。IPCノードが、IPCメッセージOPコードをサポートしない場合、エラー応答が、コンポーネント1102に返される。エラー応答に加えて、IPCセッション・マネージャは、その特定のOPコードを受信し得る全IPCノードの更新内容を返す。メッセージをIPCノード(１つ又は複数)のどれに転送するか判断するのは、コンポーネント次第である。IPCセッション・マネージャ1106は、引き続きIPCヘッダ情報によるデータの隠蔽を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、IPCネットワークに配置されていると判断した場合、IPCネットワーク上で送られる。
【００３５】
図12において、本発明の実施形態に基づくIPCデータヘッダ1202を示す。このヘッダには、送信元及び宛先IPCアドレス、送信元ポート、IPCルータによって提供された宛先ポート、IPCトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元IPCコンポーネント及び宛先IPCコンポーネントが含まれる。メッセージOPコード、メッセージ長及びIPCデータは、コンポーネント1204によって提供される。
【００３６】
本発明の実施形態に基づく代表的なIPCデータ要求を図13に示す。ステップ1302において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びOPコードが含まれる。コンポーネントは、その宛先OPコードをサポートするノードタイプを検索する。ノードタイプが0xFFに等しい場合、セッション・マネージャ(図13において、”セッション”として示す)は、引き続き、全ての参加したIPC用の全ノードテーブルにコンポーネント情報を送信する。OPコードフィールドが、0xFFに等しい場合、図13に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するOPコードリストをコンポーネントに送る。他方、OPコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のOPコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。
【００３７】
ステップ1304において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが0xFFに等しい場合、ノードテーブルが、コンポーネントに返される。OPコードフィールドが0xFFに等しい場合、OPコードのリストは、コンポーネントに返される。しかしながら、OPコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ1306において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、IPCメッセージOPコード、IPCメッセージデータ、チャネルID及びコンポーネントIDが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、OPコードがサポートされるかどうか判断する。ノードタイプがOPコードをサポートしない場合、コンポーネント更新指示は、ステップ1308において送られる。しかしながら、ノードタイプがOPコードをサポートする場合、データ要求が、ステップ1310においてデバイス層に送られる。データ要求パラメータには、IPCメッセージ、チャネルID及びIPCヘッダが含まれる。
【００３８】
デバイス層は、チャネルIDに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート#ヘッダ情報に基づき、IPCハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、1312においてセッション・マネージャに送られる。ステップ1314において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、IPCメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のIPCメッセージを送信し得る。
【００３９】
ステップ1316において、デバイス層は、IPCメッセージデータ及びIPCヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先IPCヘッダをチェックし、ローカルIPCアドレスと異なる場合、セッション・マネージャは、正しいIPCノードにメッセージを送る(ルーチングする)。ステップ1310において、セッション・マネージャは、予約チャネルIDと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントIDをチェックし、それが0xFFに等しい場合、そのOPコードに申し込んだ全コンポーネントにメッセージをルーチングする。ステップ1318において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、IPCデータを受信する。
【００４０】
IPCスタックは、全ての関係するIPCノード間での通信のために予約制御チャネルを用いる。起動時、IPCサーバのセッション・マネージャは、このリンクを用いて、IPCクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのAPとBP間において制御情報を搬送するために用いられる。
【００４１】
図14において、IPCスタック(IPCスタック及びIPCスタックサーバとして示す)とIPCハードウェアとの間に配置された制御チャネル1402-1406を示す。また、制御チャネル情報1408は、異なるIPCハードウェア間でデータを送信する時、データパケット1410と共に送信される。IPCクライアントは、初期的には、IPC制御チャネル上でその設定要求を一斉送信する。IPCスタックサーバは、一斉送信を受信し、そのクライアント用のIPCアドレスで応答する。このIPCアドレスは、その特定のプロセッサ(AP又はBP)用の動的ルーチング表に対応付けられる。
【００４２】
IPCアプリケーション・プログラム・インターフェイス(API)
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインターフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの申込みが、IPCアドレスに属するダイナミック・データ・ルーチング・テーブルにおいて用いられる。
【００４３】
OpenChannelKeep()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
【００４４】
OpenChannel()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
【００４５】
OpenChannelWThru()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
【００４６】
CloseChanneI()
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
【００４７】
ChannelGrant()
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
【００４８】
ChannelError()
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
【００４９】
DataChannetRequest()
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
【００５０】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５１】
2)IPCセッション・マネージャとIPCデバイス・インターフェイス間
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインターフェイスマネージャにチャネル優先権要求を送る。
【００５２】
CloseChannel()
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
【００５３】
ChannelGrant()
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
【００５４】
DataChannelRequest()
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５５】
3)IPCセッション・マネージャからIPCプレゼンテーション・マネージャへ
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
【００５６】
4)IPCハードウェア/IPCスタックインターフェイス
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、aChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
【００５７】
CloseChannel()
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
【００５８】
ChannelGrant()
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
【００５９】
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
【００６０】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００６１】
図15において、IPCネットワークを用いて互いに通信を行うベースバンドプロセッサ(BP)1502及びアプリケーションプロセッサ(AP)1504を有する(例えば、携帯電話等)無線通信装置1500等の電子装置のブロック図を示す。本発明のIPCプロトコルは、通信装置1500等のシステム中の複数のプロセッサ間において、通信を提供する。IPCは、専用通信システム(PCS)アプリケーション等のMAサーバへの移動体アプリケーション(MA)クライアント(例えば、iDENTM_WLAN)の登録を可能にし、また、２つのMAが、それ自体のMA内で、どんなソフトウェア・アーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。
【００６２】
IPCプロトコルは、任意のIPC準拠MAをIPCリンクに動的に付加し通信を行わせる。従って、IPCネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のIPCは、ソフトウェア・コンポーネントがIPCスタック(図15に示さず)と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。
【００６３】
本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。
【図面の簡単な説明】
【００６４】
【図１】本発明の実施形態に基づくIPCネットワークを示す図。
【図２】本発明の実施形態に基づくIPCスタックを示す図。
【図３】本発明の実施形態に基づくIPCコンポーネントIPC割当てを示す図。
【図４】本発明の実施形態に基づく主IPCテーブルを示す図。
【図５】本発明の実施形態に基づくチャネルアロケーションを示す図。
【図６】本発明の実施形態に基づくIPCクライアント初期化ルーチン時に関与するステップを強調表示して示す図。
【図７】本発明の実施形態に基づくIPCクライアント初期化時に関与するステップを強調表示して示すもう１つの図。
【図８】本発明の実施形態に基づく第１レベルのIPC隠蔽を強調表示して示す図。
【図９】本発明の実施形態に基づくIPCコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１０】本発明の実施形態に基づくコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１１】本発明の実施形態に基づくIPCクライアントとIPCサーバとの間のIPCデータ転送を示す図。
【図１２】本発明の実施形態に基づくIPCデータヘッダを示す図。
【図１３】本発明の実施形態に基づくIPCデータ要求時に行われるステップを示す図。
【図１４】本発明の実施形態に基づくIPCネットワークを示す図。
【図１５】本発明の実施形態に基づく無線通信装置等の電子装置を示す図。
【技術分野】
【０００１】
本発明は一般的に電子分野に関し、特には、プロセッサ間通信（ＩＰＣ）のプロトコル／ネットワークに関する。
【背景技術】
【０００２】
ほとんどの電子システムは、システムを形成するハードウェアやソフトウェア等の、多くのネットワーク要素（部品）からなる。ほとんどのシステムにおいて、異なるネットワーク要素それ自身の間と同時に、ネットワーク要素を形成する異なる部品との間の通信に対応する層を有する。この層は一般的にプロセッサ間通信（ＩＰＣ）と呼ばれる。
【０００３】
近年、プロセッサ間通信を行う幾つかのプロトコルが導入されている。ＩＰＣの一例はＰＣＩＡＧＰコントローラ（ＰＡＣ）であって、Ｈｏｓｔ‐ｔｏ‐ＰＣＩブリッジ、ＤＲＡＭコントローラ、およびデータ経路とＡｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）インタフェイスを集積する。ＩＰＣの別例はＯＭＡＰ（登録商標）プラットフォームである。これらのプラットフォームではいずれも、すべてのサポートがハードウェアレベル以上の場合は多くの設計自由度を得られず、低レベル部品やチャネルレベル（物理層）では設計自由度はほとんどない。
【０００４】
例えば、ＰＡＣプラットフォームは閉構造で、オペレーティング・システムのＴＡＰＩ層に埋め込まれており、ＩＰＣコードは開発者にはアクセスできない。従って、これらのプラットフォームは部品システムには拡張しないので、ＩＰＣ源の動的割り当てをできないだけでなく、ＩＰＣ源の動的割り当て、ハードウェア・サポート機能、マルチノード・ルーチングをできない。
【０００５】
リアルタイム処理アプリケーション等のアプリケーションにおける１つの問題は、異なるプロセッサ上のサービスの発見及びIPC要求の迅速な処理に対する要件である。これらの状況において、良好なサポートを保証する１つの側面は、無線通信装置における移動体アプリケーション(MA)等の異なるアプリケーションの仕事を埋め合わせ、対象のMAへのデータの送付に先立ち共同処理をサポートすることである。この共同処理サポートには、通常、コプロセッサにIPCデータを輸送し、そして、そのデータを対象のMAに再度ルーチングし得るスマート・ハードウェア・ポートが必要である。良好なサポートを保証するもう１つの側面は、専用リンク(ポート)を用いて、異なるMA上のソフトウェア・コンポーネントに特定のソフトウェアサービスを搬送することによる。今日、これらの方法は、動的でもなく、実行時設定可能でもない。従って、以上のことから、従来技術におけるこれら幾つかの欠点に対する解決策を提供し得るIPCプロトコルに対するニーズが、当分野に存在する。
【発明を実施するための最良の形態】
【０００６】
本発明の特徴は、詳細に添付の請求項に記載されている。本発明は、添付図面を併用して行われる以下の説明を参照すると最も良く理解し得る。図面の幾つかの図では、同様な参照数字は、同様な要素を表す。
【０００７】
本明細書は、本発明の特徴を定める請求項で終わるが、本発明は、図面の図と共に以下の説明を考察すると、理解が深まると思われる。
IPCは、システムにおいて動作する異なるプロセッサが互いに通信を行うために必要なサポートを提供する。例えば、アプリケーションプロセッサ(AP)及びベースバンドプロセッサ(BP)が含まれる無線通信装置に用いる二重プロセッサ(又は多重プロセッサ)無線アーキテクチャにおいて、IPCは、プロセッサが互いに効率的に通信を行うために必要なサポートを提供する。IPCは、AP又はBPの設計に何らかの制約を課すことなく、このサポートを提供する。
【０００８】
IPCをそのプロセッサ間通信スタックとして採用するあらゆるプロセッサは、IPCにより、その２つが、共通のオペレーティング・システム及びメモリを共有する同じプロセッサコア上で実際に動作しているかの如く共存し動作し得る。通信装置において複数のプロセッサを用いることが標準になりつつある中で、IPCは、異なるプロセッサ間において信頼性の高い通信を提供する。
【０００９】
IPCハードウェアは、異なるプロセッサをIPCネットワークに接続する物理接続を提供する。本発明の一実施形態において、データパケットは、好適には、異なるホスト間において非同期的に輸送される。IPCネットワークに接続されるプロセッサは、それらの物理及び論理アドレスが、静的に又は動的に割り当てられる(例えば、IPCアドレス)。また、データパケットは、本発明の一実施形態におけるIPCネットワーク内で任意の方向に流れ得ることから、パケットは、それらが到達しようとしているプロセッサの宛先アドレスを搬送する必要がある。また、好適には、パケットは、従来の周期的冗長検査(CRC)手法を用いて、エラーが無いかチェックされる。本発明のIPCネットワークのネットワークアクティビティは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ネットワーク等のIP輸送層を用いるインターネット・ネットワーク上に存在するものとある程度類似し得るが、本発明のIPCは、TCP/IPネットワークのようにゲートウェイにより小規模なネットワークに分割されない。
【００１０】
次に、図1において、本発明の実施形態に基づくIPCネットワーク100を示す。IPCネットワーク100には、複数のIPCクライアント102-106及び、幾つかの実例として、共有メモリ110、ユニバーサル非同期受信機／送信機(UART)112及びユニバーサル・シリアル・バス(USB)114等の異なるIPC物理リンクを用いて、IPCクライアント102-106に接続されたIPCサーバ108が含まれる。本発明のIPCにより、IPCクライアント102-106は、現IPCサーバ108と折衝して役割を交替し得ることに留意されたい。IPCクライアント102-106が、IPCサーバになるように折衝して新しいIPCサーバになる場合、残りの全てのIPCクライアントは、IPCサーバの変更があった場合、サーバのIPアドレスを変更するように指示される。
【００１１】
図2において、本発明の実施形態に基づくIPCサーバ108(又はIPCクライアント102-108)のIPCスタック200を示す。IPCスタック200は、オペレーティングシステム(OS)の下で一体化されるように、また、コンポーネントトラフィックのプロセッサ間通信ニーズにサポートを提供するように設計されている。IPCスタックは、次の3つの主な層から構成される。即ち、
(1)IPCプレゼンテーション・マネージャ(202)：この層は、異なるシステムコンポーネント(例えば、ソフトウェア・スレッド)間において異なるデータタイプを変換するために用いられる。
【００１２】
(2)IPCセッション・マネージャ(204)：この層は、IPCスタックと全システムコンポーネントとの間における全着信/発信IPCトラフィック用の中央リポジトリである。IPCセッション・マネージャ204は、幾つかの機能を有する。即ち、IPCコンポーネントを参加させるためのコンポーネントIDの割当て；IPCデータを隠蔽する必要があるかどうかの判断；IPCデータのルーチング、IPCトラフィックの終止；IPCプロセッサ用のプレースホルダ；IPCアドレスの提供、IPCクライアントの割当及び認証等を有する。
【００１３】
IPCトランスポート層(208)：IPCセッション・マネージャ(層)204内に配置される。IPCトランスポート層208は、異なるプロセッサ間において、IPCデータを輸送する目的のために、極めて基本的な周期的冗長検査を行う。更に、IPCトランスポート層208は、IPCメッセージを、IPCネットワーク100上のそれらの最終宛先にルーチングする役割を担う。トランスポート層のルーチング機能は、IPCサーバ上でのみ使用可能である。
【００１４】
IPCルータブロック(210)：宛先コンポーネント（図示せず）にIPCデータを輸送する。着信IPCメッセージは、とりわけ、音声及びモデム等の発生元コンポーネントID、IPCメッセージOPコードを搬送する。本発明の実施形態によれば、固有のOPコードが、IPCネットワークに接続された音声及びモデム等の各コンポーネント/ソフトウェア・スレッドに割り当てられることに留意されたい(例えば、図５の502参照)。IPCセッション・マネージャ204は、ルータブロック210に依拠して、IPCデータを正しいコンポーネント（１つ又は複数）に送る。
【００１５】
(3)デバイス・インターフェイス層(206)：IPC物理対論理IPCチャネルを管理する役割を果たす。その主な機能は、スタックIPCがハードウェアに依存しなくなるように、IPCハードウェアを完全に抽出することである。デバイス・インターフェイス層206は、直下のIPCリンクの物理帯域幅を管理して全IPC論理チャネルをサポートする。着信経路において、デバイス・インターフェイス層206は、異なる物理チャネル110-114からデータを傍受して、それらを残りのIPCスタックに渡す。発信経路上では、デバイス・インターフェイス層206は、IPC論理チャネルのデータローディングを、それらを適切な物理チャネル上に送ることによって管理する。また、デバイス・インターフェイス層206は、同じIPCチャネルに属するIPCパケットの連結を行い、その後、それらをIPCハードウェアに送る。チャネル要件は、IPCセッション・マネージャ204とIPCデバイス・インターフェイス層206との間で事前に折衝される。デバイス・インターフェイス層206は、ハードウェアポートを備え、これは、IPCクライアント102-106とのデバイス・インターフェイスを提供する。
【００１６】
図3において、IPCコンポーネントID割当てルーチンを示す。IPC通信に加わりたい新しいコンポーネントは、いずれも、(例えば、セッション・マネージャ204等の)そのIPCセッション・マネージャから、ステップ302において、IPC識別番号(ID)をまず要求することによって、そうしなければならない。すると、ローカル・セッション・マネージャ(例えば、コンポーネントが接続されているクライアントに配置されたセッション・マネージャ)は、新しいIPCコンポーネントのIPCサーバ・セッション・マネージャを呼出し、ステップ304において、コンポーネントID割当てを行う。本発明の実施形態によれば、コンポーネントIDは、動的であり、セッション・マネージャによって割り当てられる。主なIPCサーバ位置は、最も可能性が高いのは、主AP上である。各IPCノードは、好適には、固有のIPCノードIDを有し、セッション・マネージャは、そのデータベース中に、各関係IPCノード用の以下の情報を保持する。即ち、
IPCノードタイプ：例えば、特定のBP又はAP、無線ローカルエリアネットワーク(WLAN)AP等。
【００１７】
IPCアドレス：IPCノードのIPCアドレス
データタイプ：IPCノードのデータタイプ
OPコードリスト：これは、コンポーネントが申し込んだ全IPCメッセージOPコードのリストである。
【００１８】
コンポーネントID：全コンポーネントIDのリスト
次に、図4において、全ての主IPCテーブルと共にIPCスタックを示す。動的ルーチング表402には、ノードタイプ、IPCアドレス/ポート#情報、データタイプ及び申込みリストが含まれる。コンポーネント・ルーチング・テーブル404には、OPコード情報と各特定のOPコードに申し込んだ全てのコンポーネントとをリンクする情報が含まれる。最後に、チャネル資源テーブル406には、物理チャネルIDのリストとの各チャネルIDのリンクが含まれる。
【００１９】
図5において、本発明の実施形態に基づくIPCスタックが、ソフトウェア・スレッド等(例えば、音声等)のコンポーネントにIPCチャネルを如何に提供するかのブロック図を示す。コンポーネント502は、まず、ステップ504において、IPCチャネルを要求する。図5に示すセッション・マネージャは、定義されたAPIを用いて、ステップ506において、コンポーネントの要求をデバイス層と折衝する。そして、デバイス層(デバイスインターフェイス)は、データチャネル508等のハードウェア資源を要求する。要求に応答して、図5に示すセッション・マネージャは、ステップ510において、要求側にIPCチャネルを与える。次に、コンポーネント502は、割り当てられたチャネル508上でそのデータを送る。そして、デバイス層は、IPCネットワークにデータを転送する。論理から物理チャネルIDへのマッピングは、IPCデバイス・インターフェイスの機能である。
【００２０】
次に、図6において、IPCクライアント初期化における第１ステップは、IPCクライアント602とIPCサーバ604との間において、登録要求(ステップ606)を送信することである。そして、IPCサーバ604は、ステップ608において、IPCクライアント602による要求を認証する。この後、IPCアドレスが、IPCクライアントに送信され、ステップ610において登録が完了する。IPCクライアントのセッション・マネージャは、ステップ612において、その動的ルーチング表のコピーをIPCサーバに送る。
【００２１】
IPCクライアント初期化プロセス時に行われる詳細なステップを図7に示す。クライアント・セッション・マネージャ(セッション(クライアント)としてテーブルに示す)は、ステップ702において、IPCサーバのセッション・マネージャ(セッション(サーバ)としてテーブルに示す)に設定要求を送る。ステップ704において、認証は、IPCサーバのセッション・マネージャによって要求される。そして、IPCクライアントとIPCサーバとの間の認証は、ステップ706で実行される。
【００２２】
設定要求のパラメータには、ノードタイプ及びデータタイプが含まれる。ステップ702において、設定要求に応答して、セッションサーバは、要求側にIPCアドレスを割り当てる。また、もしなければ、要求側用の動的ルーチング表を設定する。そして、ステップ708において、要求側に設定指示を送る。設定指示パラメータには、サーバのIPCアドレス及びクライアントの新規に割り当てられたIPCアドレスが含まれる。
【００２３】
設定指示の受信に応答して、セッションクライアントに取り付けられたコンポーネントは、クライアントのセッション・マネージャから制御/データを要求し得る。そして、セッションクライアントは、ステップ710において、セッションサーバに設定指示確認メッセージを送る。“設定指示確認”メッセージは、ステップ710における設定指示確認メッセージの受信時、パラメータを有さず、セッションサーバは、新規に設定されたセッションクライアントへのIPCストリームを起動し得る。そして、セッションサーバは、ステップ712及び714において、セッションクライアントに設定更新メッセージを送る。これによって、図7に示す両セッションクライアントは、それらのそれぞれの動的ルーチング表（図示せず）を更新し、ステップ716及び718において、セッションサーバに設定更新確認メッセージを送る。設定更新確認メッセージを受信すると、セッションサーバは、全ての参加したIPCが、更新されたことを確認する。
【００２４】
パケットは、IPCセッション・マネージャによって受信される時、送信元コンポーネントID、宛先ID、チャネルID及びBP又はAPのタイプが含まれるデータの形態でやって来る。IPCセッション・マネージャは、宛先IDが挿入されていない場合、宛先コンポーネントIDを付加する。また、IPCセッション・マネージャは、IPCアドレスを挿入する。受信されたメッセージOPコードに基づき宛先IDを発見するのは、IPCセッション・マネージャである。宛先IDは、ルックアップテーブルに基づく。このルックアップテーブルは、コンポーネントが新しいIPCメッセージOPコードに申し込む(例えば、音声コンポーネントが、IPCセッション・マネージャに要求を送信することによって音声メッセージに申し込む)度に、動的に更新される。
【００２５】
図8において、コンポーネントと本発明の実施形態に基づくそのIPCセッション・マネージャとの間における一般的な宛先ID発見シーケンス時の一連のイベントを示す。ステップ802において、コンポーネントは、その送信元ID(宛先IDはない)、宛先BP又はAPのタイプ、及びヘッダ及びデータが含まれるIPCデータを送る。ステップ804において、IPCセッション・マネージャは、対応する動的ルーチング表を検索し、正しい宛先アドレスを見つけるために、IPCデータヘッダOPコード、及び宛先BP又はAPのタイプを見る。ステップ806において、IPCセッション・マネージャは、コンポーネントのIPCアドレスを挿入し、それをデバイス層に送る。
【００２６】
図9において、IPCコンポーネント初期化時に行われる代表的なステップを示す。BPが、図9に示すIPCサーバによって一旦設定されると、コンポーネント902等のコンポーネントは、異なるサービスに申し込み得る。コンポーネントは、ステップ904において、音声や映像等の機能にそれら自体申し込む。そして、コンポーネント申込み情報は、IPCセッション・マネージャに送られ、(IDがまだ割り当てられていない場合)コンポーネントIDの生成が行われ、また、特定のI PCアドレス用動的ルーチング表の生成又は更新が行われる(ステップ906)。ステップ908において、セッション・マネージャは、ステップ906からの情報でIPCサーバを更新する。ステップ908において、更新された動的ルーチング表を受信すると、ステップ912において、更新の確認が、IPCサーバによってIPCクライアントに送信される。サーバが、一旦呼び出されると、新しい動的ルーチング表更新内容は、関係する全プロセッサステップ910に一斉送信される。
【００２７】
図10において、同じコンポーネント初期化プロセスを、コンポーネント(クライアント)1002と、クライアント・セッション・マネージャ1004としても知られているセッション(クライアント)と、サーバ・セッション・マネージャ1006としても知られているセッション(サーバ)との間に示す。ステップ1008におけるコンポーネント設定要求は、コンポーネント(クライアント)1002によって送信される。要求に応答して、クライアント・セッション・マネージャ1004は、デバイス層（図示せず）と論理チャネルを取り決める。また、クライアント・セッション・マネージャ1004は、コンポーネントIDを割当て、その動的ルーチング表（図示せず）に新しいOPコードリストを付加する。ステップ1010において、クライアント・セッション・マネージャ1004は、パラメータとして、コンポーネントID及びチャネルIDが含まれる設定応答を送る。設定応答に応じて、コンポーネント(クライアント)1002は、そのID及びチャネルIDをクライアントのセッション・マネージャ1004から受信する。
【００２８】
一旦クライアント・セッション・マネージャ1004が、ステップ1008における設定要求に対して、ステップ1010で返信すると、クライアント・セッション・マネージャ1004は、ステップ1012において、セッションサーバ(サーバ・セッション・マネージャ)1006に設定更新要求を送る。設定更新要求のパラメータは、動的ルーチング表（図示せず）において行われた何らかの新しい変更である。サーバのセッション・マネージャ1006は、そのIPCアドレス用の動的ルーチング表を更新する。そして、ステップ1016において、サーバのセッション・マネージャ1006は、全てのIPCクライアント（図示せず）に設定更新内容を送り、その間、ステップ1014において、クライアントのセッション・マネージャ1004に設定更新指示を送る。サーバのセッション・マネージャ1006は、サーバが、送られた変更でそのルーチングテーブルを更新したことを確認する。
【００２９】
パラメータ(１つ又は複数)として動的ルーチング表を含むステップ1016の設定更新メッセージにおいて、セッションサーバ1006は、動的ルーチング表を更新し、ステップ1018において、設定更新確認メッセージを送る。そして、サーバは、参加した全IPCが更新されたことを確認する。
【００３０】
IPCセッション・マネージャは、着信及び発信IPCパケットのルーチング経路を決定する。発信パケットのルートは、コンポーネントのIPCアドレスによって決定される。宛先アドレスが、ローカルプロセッサのそれであると分かった場合、オペレーティングシステム(OS)へのIPCのマッピングは、セッション・マネージャ内で実行される。宛先アドレスが、ローカルIPCクライアント用であると分かった場合、パケットは、IPCスタックに送られ、更に処理(例えば、隠蔽)される。宛先コンポーネントが、IPCパケットを送信するコンポーネントとして、同じプロセッサ上に配置されている場合、隠蔽は不要であり、パケットは、通常のOSメッセージ呼出し(例えば、マイクロソフト・メッセージ・キュー等)を介して渡されることに留意されたい。このように、コンポーネントは、それらのメッセージ入力方式の修正について心配する必要はない。必要なことは、それらのメッセージ書き込み方法を、むしろOS特有の設計からIPC呼出しに変更することだけである。
【００３１】
着信パケットの場合、メッセージの宛先アドレスが、IPCサーバのものと等しくない場合、着信パケットは、妥当なIPCクライアントにルーチングされる。着信パケットのルーチングは、IPCサーバのセッション・マネージャによって処理される。そうでない場合、メッセージは、コンポーネント宛先IDが、有効なコンポーネントIDに又は0XFFに設定されているかどうかに応じて、正しいコンポーネント又は複数のコンポーネントに転送される。
【００３２】
IPCルータブロック(例えば、図2におけるIPCルータブロック210参照)は、宛先コンポーネントにIPCデータを輸送する。着信IPCメッセージは、とりわけ、発生元コンポーネントID、及び音声やモデム用等のIPCメッセージOPコードを搬送する。IPCセッション・マネージャは、そのコンポーネント・ルーチング・テーブルに依拠して、正しいコンポーネント(１つ又は複数)にIPCデータを送る。動的ルーチング表及びコンポーネント・ルーチング・テーブルは、双方共、IPCサーバ/クライアントによって更新される。
【００３３】
起動時、各コンポーネントは、そのセッション・マネージャにそれ自体登録して、IPCコンポーネントIDを取得しなければならない。更にまた、音声やモデム等の着信IPCメッセージを申し込まなければならない。この情報は、コンポーネント・ルーチング・テーブルに記憶され、IPCセッション・マネージャによって用いられる。
【００３４】
図11に示すように、コンポーネント(例えば、ソフトウェア・スレッド)1102が、ステップ1104において、そのデータ要求をIPCセッション・マネージャに送る場合、宛先IPCノード(例えば、BP)についてチェックが行われる。IPCノードが、IPCメッセージOPコードをサポートしない場合、エラー応答が、コンポーネント1102に返される。エラー応答に加えて、IPCセッション・マネージャは、その特定のOPコードを受信し得る全IPCノードの更新内容を返す。メッセージをIPCノード(１つ又は複数)のどれに転送するか判断するのは、コンポーネント次第である。IPCセッション・マネージャ1106は、引き続きIPCヘッダ情報によるデータの隠蔽を行い、その後、そのデータは、セッション・マネージャが、宛先コンポーネントは、ローカルプロセッサではなく、IPCネットワークに配置されていると判断した場合、IPCネットワーク上で送られる。
【００３５】
図12において、本発明の実施形態に基づくIPCデータヘッダ1202を示す。このヘッダには、送信元及び宛先IPCアドレス、送信元ポート、IPCルータによって提供された宛先ポート、IPCトランスポートによって提供された長さ及びチェックサム情報、並びにセッション・マネージャによって提供された送信元IPCコンポーネント及び宛先IPCコンポーネントが含まれる。メッセージOPコード、メッセージ長及びIPCデータは、コンポーネント1204によって提供される。
【００３６】
本発明の実施形態に基づく代表的なIPCデータ要求を図13に示す。ステップ1302において、コンポーネントは、更新要求を送る。好適には、コンポーネント更新パラメータには、ノードタイプ及びOPコードが含まれる。コンポーネントは、その宛先OPコードをサポートするノードタイプを検索する。ノードタイプが0xFFに等しい場合、セッション・マネージャ(図13において、”セッション”として示す)は、引き続き、全ての参加したIPC用の全ノードテーブルにコンポーネント情報を送信する。OPコードフィールドが、0xFFに等しい場合、図13に示すセッション・マネージャは、引き続き、規定されたノードタイプに属するOPコードリストをコンポーネントに送る。他方、OPコードが特定の値を有する場合、セッション・マネージャは、引き続き、ノードタイプが、その特定のOPコードをサポートする又はサポートしないかどうかに対応する真の又は偽の値をコンポーネントに送る。
【００３７】
ステップ1304において、コンポーネント更新指示は、コンポーネントに送られる。ノードタイプが0xFFに等しい場合、ノードテーブルが、コンポーネントに返される。OPコードフィールドが0xFFに等しい場合、OPコードのリストは、コンポーネントに返される。しかしながら、OPコードが特定の値である場合、真の又は偽のメッセージが返される。ステップ1306において、コンポーネントデータ要求が行われる。コンポーネントデータ要求用のパラメータには、ノードタイプ、IPCメッセージOPコード、IPCメッセージデータ、チャネルID及びコンポーネントIDが含まれる。コンポーネントデータ要求において、セッション・マネージャは、ノードタイプをチェックし、OPコードがサポートされるかどうか判断する。ノードタイプがOPコードをサポートしない場合、コンポーネント更新指示は、ステップ1308において送られる。しかしながら、ノードタイプがOPコードをサポートする場合、データ要求が、ステップ1310においてデバイス層に送られる。データ要求パラメータには、IPCメッセージ、チャネルID及びIPCヘッダが含まれる。
【００３８】
デバイス層は、チャネルIDに基づき、データ要求メッセージを送るようにスケジュール設定する。デバイス層は、ポート#ヘッダ情報に基づき、IPCハードウェアを選択する。一旦データが投入されると、データ確認メッセージが、1312においてセッション・マネージャに送られる。ステップ1314において、セッション・マネージャは、引き続き、コンポーネントデータ確認メッセージをコンポーネントに送る。コンポーネントは、確認を待ち、その後、更に、IPCメッセージを送信し得る。一旦データ確認が受信されると、コンポーネントは、引き続き、次のIPCメッセージを送信し得る。
【００３９】
ステップ1316において、デバイス層は、IPCメッセージデータ及びIPCヘッダが含まれるデータ指示メッセージを送る。セッション・マネージャは、メッセージの宛先IPCヘッダをチェックし、ローカルIPCアドレスと異なる場合、セッション・マネージャは、正しいIPCノードにメッセージを送る(ルーチングする)。ステップ1310において、セッション・マネージャは、予約チャネルIDと共にデバイス層にデータ要求を送る。セッション・マネージャは、宛先コンポーネントIDをチェックし、それが0xFFに等しい場合、そのOPコードに申し込んだ全コンポーネントにメッセージをルーチングする。ステップ1318において、セッション・マネージャは、コンポーネントデータ指示メッセージを送り、コンポーネントは、IPCデータを受信する。
【００４０】
IPCスタックは、全ての関係するIPCノード間での通信のために予約制御チャネルを用いる。起動時、IPCサーバのセッション・マネージャは、このリンクを用いて、IPCクライアントに又はその逆にメッセージを一斉送信する。通常動作時、この制御チャネルは、全てのAPとBP間において制御情報を搬送するために用いられる。
【００４１】
図14において、IPCスタック(IPCスタック及びIPCスタックサーバとして示す)とIPCハードウェアとの間に配置された制御チャネル1402-1406を示す。また、制御チャネル情報1408は、異なるIPCハードウェア間でデータを送信する時、データパケット1410と共に送信される。IPCクライアントは、初期的には、IPC制御チャネル上でその設定要求を一斉送信する。IPCスタックサーバは、一斉送信を受信し、そのクライアント用のIPCアドレスで応答する。このIPCアドレスは、その特定のプロセッサ(AP又はBP)用の動的ルーチング表に対応付けられる。
【００４２】
IPCアプリケーション・プログラム・インターフェイス(API)
以下に、本発明のIPCプロトコル用APIの幾つかを列記する。
1)IPCセッション・マネージャからコンポーネントインターフェイスへ
CreateComponentInst()
IPCセッション・マネージャにコンポーネントデータベースを生成する。コンポーネントデータタイプ(ビッグ・エンディアン対リトル・エンディアン)等の情報及びメッセージOPコードの申込みが、IPCアドレスに属するダイナミック・データ・ルーチング・テーブルにおいて用いられる。
【００４３】
OpenChannelKeep()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。チャネルは、CloseChannel()が発行されるまで予約される。コンポーネントは、IPCセッション・マネージャにQoS要求を送る。コンポーネントIDがまだ割り当てられていない場合、IPCチャネルは、それを割り当てる(例えば、ChannelGrant())。
【００４４】
OpenChannel()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。パラメータは、OpenChannelKeep()基本要素に用いられるものと同じである。
【００４５】
OpenChannelWThru()
IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。これは、このチャネル上では、その隠蔽を止めることを意味するチャネル経由の書き込み要求である(例えば、非UDP_AT命令)。
【００４６】
CloseChanneI()
IPCチャネルを閉じよという要求。コンポーネントは、チャネルをもはや必要としない。そして、資源は、開放される。
【００４７】
ChannelGrant()
チャネルが要求側に与えられる。チャネルIDは、まだ、それが割り当てられていない場合、IPCセッション・マネージャによって割り当てられる。
【００４８】
ChannelError()
チャネルエラーが発生した。チャネルが閉じられ、要求側に通知される。
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。このメッセージは、IPCプレゼンテーション・マネージャによって対象のコンポーネントに送信される。これには、制御チャネルデータも含まれる。
【００４９】
DataChannetRequest()
要求側が、開かれたチャネルに関するデータを送りたい。これには、制御チャネルデータも含まれる。
【００５０】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５１】
2)IPCセッション・マネージャとIPCデバイス・インターフェイス間
OpenChannel()
論理IPCチャネルを開く。そして、それが利用可能な場合、ChannelGrant()が発行される。IPCセッション・マネージャは、IPCデバイスインターフェイスマネージャにチャネル優先権要求を送る。
【００５２】
CloseChannel()
IPC論理チャネルを閉じよという要求。コンポーネントは、もはやチャネルが必要ないと判断する。
【００５３】
ChannelGrant()
論理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した。(例えば、着信データに関するCRC障害又は物理チャネル障害)
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
【００５４】
DataChannelRequest()
要求側が、論理チャネルに関するデータを送りたい。
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００５５】
3)IPCセッション・マネージャからIPCプレゼンテーション・マネージャへ
ChannetDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。情報は、正しいデータフォーマットで対象のコンポーネントに転送される。
【００５６】
4)IPCハードウェア/IPCスタックインターフェイス
OpenChannel()
物理IPCチャネルを開く。そして、それが利用可能な場合、aChannelGrant()が発行される。IPCセッション・マネージャは、IPCハードウェアにチャネル優先権要求を送る。
【００５７】
CloseChannel()
IPC物理チャネルを閉じよという要求。コンポーネントは、もはやチャネルを必要としない。
【００５８】
ChannelGrant()
物理チャネルが、要求側に与えられる。
ChannelError()
チャネルエラーが発生した(例えば、着信データに関するCRC障害又は物理チャネル障害)。
【００５９】
ChannelDataIndication()
要求側は、チャネルに関するデータを送付すべきであると警告される。
DataChannetRequest()
要求側が、物理チャネルに関するデータを送りたい。
【００６０】
ChannelClose()
IPCチャネルを閉じよという要求。チャネル不活動タイマが切れ、タイムアウトに関連するチャネルが閉じられる。これは、チャネルエラーによることもある。
【００６１】
図15において、IPCネットワークを用いて互いに通信を行うベースバンドプロセッサ(BP)1502及びアプリケーションプロセッサ(AP)1504を有する(例えば、携帯電話等)無線通信装置1500等の電子装置のブロック図を示す。本発明のIPCプロトコルは、通信装置1500等のシステム中の複数のプロセッサ間において、通信を提供する。IPCは、専用通信システム(PCS)アプリケーション等のMAサーバへの移動体アプリケーション(MA)クライアント(例えば、iDENTM_WLAN)の登録を可能にし、また、２つのMAが、それ自体のMA内で、どんなソフトウェア・アーキテクチャ、オペレーティング・システム、ハードウェアに各々依存するかという制限を一切伴わず自由に通信するための手段を提供する。
【００６２】
IPCプロトコルは、任意のIPC準拠MAをIPCリンクに動的に付加し通信を行わせる。従って、IPCネットワークは、コンパイル時間に一切依存せずに、即ち、他のいずれのソフトウェアも前提とせずに形成される。本発明のIPCは、ソフトウェア・コンポーネントがIPCスタック(図15に示さず)と通信を行うための標準的な方法を提示し、また、スタック下のハードウェアは、コンポーネントが通信を行うための異なるリンクを選択し得るように抽出される。
【００６３】
本発明の好適な実施形態について例示し説明したが、本発明がそれに限定されないことは明らかである。数多くの修正、変更、バリエーション、置き換え及び等価物が、添付の請求項によって定義される本発明の精神及び範囲から逸脱することなく、当業者には起こり得る。
【図面の簡単な説明】
【００６４】
【図１】本発明の実施形態に基づくIPCネットワークを示す図。
【図２】本発明の実施形態に基づくIPCスタックを示す図。
【図３】本発明の実施形態に基づくIPCコンポーネントIPC割当てを示す図。
【図４】本発明の実施形態に基づく主IPCテーブルを示す図。
【図５】本発明の実施形態に基づくチャネルアロケーションを示す図。
【図６】本発明の実施形態に基づくIPCクライアント初期化ルーチン時に関与するステップを強調表示して示す図。
【図７】本発明の実施形態に基づくIPCクライアント初期化時に関与するステップを強調表示して示すもう１つの図。
【図８】本発明の実施形態に基づく第１レベルのIPC隠蔽を強調表示して示す図。
【図９】本発明の実施形態に基づくIPCコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１０】本発明の実施形態に基づくコンポーネント初期化時に行われるステップを強調表示して示す図。
【図１１】本発明の実施形態に基づくIPCクライアントとIPCサーバとの間のIPCデータ転送を示す図。
【図１２】本発明の実施形態に基づくIPCデータヘッダを示す図。
【図１３】本発明の実施形態に基づくIPCデータ要求時に行われるステップを示す図。
【図１４】本発明の実施形態に基づくIPCネットワークを示す図。
【図１５】本発明の実施形態に基づく無線通信装置等の電子装置を示す図。
【特許請求の範囲】
【請求項１】
ＩＰＣサーバと、
同ＩＰＣサーバに接続されたＩＰＣクライアントとからなり、
同ＩＰＣクライアントは、
プレゼンテーション・マネージャと、
同プレゼンテーション・マネージャに接続されたセッション・マネージャと、
同セッション・マネージャに接続されたデバイス・インターフェイスと、を有するＩＰＣスタックを含み、
ＩＰＣクライアントがＩＰＣサーバと通信するためにＩＰＣスタックを使用する、プロセッサ間通信(IPC)ネットワーク。
【請求項２】
少なくとも１つのコンポーネントがＩＰＣクライアントと接続している請求項1に記載のIPCネットワーク。
【請求項３】
少なくとも１つのコンポーネント間で異なるデータタイプを言い換えるために前記プレゼンテーション・マネージャが使用される、請求項２に記載のIPCネットワーク。
【請求項４】
少なくとも１つのコンポーネントのために、前記セッション・マネージャが部品ＩＤを割り当てる請求項２に記載のIPCネットワーク。
【請求項５】
少なくとも１つのコンポーネントに割り当てられる部品ＩＤは動的であって再割り当てが可能な請求項4に記載のIPCネットワーク。
【請求項６】
前記セッション・マネージャが、コンポーネント・ルーチング表を有するＩＰＣルータブロックを更に備え、該コンポーネント・ルーチング表は、前記セッション・マネージャがＩＰＣデータを特定のオプコードでリンクされた１つ以上のコンポーネントに送信するために使用される、請求項２に記載のIPCネットワーク。
【請求項７】
少なくとも１つのＩＰＣハードウェアが装置インタフェイスに接続され、同装置インタフェイスは少なくとも１つのＩＰＣハードウェアを抽出し、それによってＩＰＣスタックはハードウェアから独立する、請求項１に記載のIPCネットワーク。
【請求項８】
第１のプロセッサがＩＰＣサーバとして働き、第２のプロセッサがＩＰＣクライアントとして働く工程と、
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中にＩＰＣスタックを備えるＩＰＣネットワークを介して該ＩＰＣサーバとＩＰＣクライアントとの間で通信する工程と、からなる第１と第２のプロセッサ間でＩＰＣを行う方法。
【請求項９】
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中のＩＰＣスタックが、
プレゼンテーション・マネージャと、
同プレゼンテーション・マネージャに接続されたセッション・マネージャと、
同セッション・マネージャに接続されたデバイス・インターフェイスと、
を含む、請求項８に記載の方法。
【請求項１０】
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中のセッション・マネージャが動的ルーチング表を備え、
同ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中の動的ルーチング表を使用して、同ＩＰＣクライアントからＩＰＣサーバへ送信されるデータを適切にルーチングする工程、を更に含む請求項９に記載の方法。
【請求項１】
ＩＰＣサーバと、
同ＩＰＣサーバに接続されたＩＰＣクライアントとからなり、
同ＩＰＣクライアントは、
プレゼンテーション・マネージャと、
同プレゼンテーション・マネージャに接続されたセッション・マネージャと、
同セッション・マネージャに接続されたデバイス・インターフェイスと、を有するＩＰＣスタックを含み、
ＩＰＣクライアントがＩＰＣサーバと通信するためにＩＰＣスタックを使用する、プロセッサ間通信(IPC)ネットワーク。
【請求項２】
少なくとも１つのコンポーネントがＩＰＣクライアントと接続している請求項1に記載のIPCネットワーク。
【請求項３】
少なくとも１つのコンポーネント間で異なるデータタイプを言い換えるために前記プレゼンテーション・マネージャが使用される、請求項２に記載のIPCネットワーク。
【請求項４】
少なくとも１つのコンポーネントのために、前記セッション・マネージャが部品ＩＤを割り当てる請求項２に記載のIPCネットワーク。
【請求項５】
少なくとも１つのコンポーネントに割り当てられる部品ＩＤは動的であって再割り当てが可能な請求項4に記載のIPCネットワーク。
【請求項６】
前記セッション・マネージャが、コンポーネント・ルーチング表を有するＩＰＣルータブロックを更に備え、該コンポーネント・ルーチング表は、前記セッション・マネージャがＩＰＣデータを特定のオプコードでリンクされた１つ以上のコンポーネントに送信するために使用される、請求項２に記載のIPCネットワーク。
【請求項７】
少なくとも１つのＩＰＣハードウェアが装置インタフェイスに接続され、同装置インタフェイスは少なくとも１つのＩＰＣハードウェアを抽出し、それによってＩＰＣスタックはハードウェアから独立する、請求項１に記載のIPCネットワーク。
【請求項８】
第１のプロセッサがＩＰＣサーバとして働き、第２のプロセッサがＩＰＣクライアントとして働く工程と、
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中にＩＰＣスタックを備えるＩＰＣネットワークを介して該ＩＰＣサーバとＩＰＣクライアントとの間で通信する工程と、からなる第１と第２のプロセッサ間でＩＰＣを行う方法。
【請求項９】
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中のＩＰＣスタックが、
プレゼンテーション・マネージャと、
同プレゼンテーション・マネージャに接続されたセッション・マネージャと、
同セッション・マネージャに接続されたデバイス・インターフェイスと、
を含む、請求項８に記載の方法。
【請求項１０】
ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中のセッション・マネージャが動的ルーチング表を備え、
同ＩＰＣサーバとＩＰＣクライアントとのそれぞれの中の動的ルーチング表を使用して、同ＩＰＣクライアントからＩＰＣサーバへ送信されるデータを適切にルーチングする工程、を更に含む請求項９に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２００７−５２６５４４（Ｐ２００７−５２６５４４Ａ）
【公表日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【出願番号】特願２００６−５１７６０１（Ｐ２００６−５１７６０１）
【出願日】平成１６年６月２４日（２００４．６．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２０２１２
【国際公開番号】ＷＯ２００５／００６１３３
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【出願日】平成１６年６月２４日（２００４．６．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２０２１２
【国際公開番号】ＷＯ２００５／００６１３３
【国際公開日】平成１７年１月２０日（２００５．１．２０）
【出願人】（３９０００９５９７）モトローラ・インコーポレイテッド (649)
【氏名又は名称原語表記】ＭＯＴＯＲＯＬＡ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]