モバイル・デバイスおよびサービスを管理する統合された方法および装置
エンドツーエンドIPプロトコルを使用して、非IP OTAプロトコルを適用させる、1つのデータ・プロセッサまたは複数のデータ・プロセッサによって実行可能な方法、システム、ネットワーク・ノード、およびコンピュータ・プログラムが本願明細書において開示される。この方法は、非IPエンティティからメッセージを受信することと、メッセージおよびコンテンツ表現にXMLのようなマークアップ言語を使用することであって、XMLマークアップ言語メッセージにおいて非IPプロトコル・コンテンツが、コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別されることと、このXMLメッセージを送ることとを含む。XMLを使用する段階は、好ましくは、XMLメッセージのレシーバがその内容を抽出できるよう、XMLのMeta要素を使用してXMLメッセージの中に受信されたコンテンツをカプセル化することを含む。非IPエンティティから受信されるメッセージは、IS−683メッセージであってもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の好適な実施形態は、一般的に無線通信システムおよび方法に関し、特に何ら限定する例示ではないが携帯電話のようなモバイル・デバイスへ情報を配信するためのオーバーザエア（over−the−air：OTA）デバイス管理手順に関する。
【背景技術】
【０００２】
モバイル・デバイスの機能が加速する速さで進化するにつれ、モバイル・デバイス上でのサービスおよび性能をコンフィギュレーションおよびメンテナンスすることは、複雑で時間のかかる作業となる。例えば、ワイヤレス・アプリケーション・プロトコル（Wireless Application Protocol：WAP）、CDMAおよびデータ接続を可能とさせるには、複数の設定のコンフィギュレーションが必要となる。現在利用可能な限られた機能についてでさえも、自分のモバイル・デバイスのコンフィギュレーション方法を知らないユーザもいる。
【０００３】
別の使用ケースとして、モバイル・デバイスへの新しいサービスのOTAプロビジョニングおよび管理がある。ブラウジング、マルチメディア・メッセージング、モバイルEメールおよびカレンダー同期等の高度のモバイル・サービスでは、正確なモバイル・デバイスの設定が必要となる。デバイス設定およびアプリケーションを遠隔で管理するプロセスをデバイス管理と称する。
【０００４】
OTA管理は、3GPP2 OTASP／OTAPA、OMA（Open Mobile Alliance）Device Management（OMA DM）および3GPP2 IOTA−DM規格（IOTA−DMは、「IP based over−the−air device management（IPベースのオーバーザエア・デバイス管理）」を表わしている）で定義されている。
【０００５】
現在、モバイル・デバイスを遠隔管理する非インターネット・プロトコルベースの技術もある。例えば、IS−683規格（TIA／EIA−683−C、スペクトラム拡散システムにおける移動局のオーバーザエア・サービス・プロビジョニング（Over−the−Air Service Provisioning of Mobile Stations in Spread Spectrum Systems）、2003年3月）では、移動局を遠隔で管理するエア・インターフェース・シグナリングを採用するプロトコルを定義している。非IPプロトコルを使用する別の例としては、プロプライエタリのショート・メッセージ・サービス（Short Message Service：SMS）ベースのプロトコルの使用が挙げられる。
【０００６】
デバイス管理は、モバイル・サービスの広い採用を手助けすることを意図しており、加入者が新しいサービスに簡単に申し込みができるようなメカニズムを提供する。これは、ネットワーク・オペレータに対し、新しいサービスおよび管理プロビジョン・サービスを導入する早くて簡単な方法を、変更に対して動的に調節し一定レベルのサービスを保証することによって可能とさせる。
【０００７】
2003年6月、OMAは、SyncML DM（同期マークアップ言語デバイス管理（Synchronization markup language device management））に基づいて、OMA Device Management（OMA DM） Version 1.1.2規格をリリースした。これに関しては下掲非特許文献１〜９を参照するとよい。
【０００８】
OMA DMは、3Gモバイル・デバイスおよびその後の世代のOTA管理ニーズのために統合された拡張可能なフレームワークを提供する。この規格には、SyncML DMプロトコルに基づいたOMA DMプロトコル仕様が含まれる。このプロトコルは、基本的な考慮事項がモバイル・デバイスのリソースおよび帯域幅制限に関連するものである、OTA管理用に最適化されている。
【０００９】
メカニズムとしてのOMA DMは、非常に用途が広く様々なデータ・オブジェクトのタイプを管理するために使用することができる。このデータ・オブジェクトは、単純な数値またはテキスト・パラメータのものもあれば、本質的にバイナリのものもある。数値オブジェクトには、アクセス・ポイント・アドレスおよびプロキシ設定などの接続パラメータを含めることができる。また、バイナリ・オブジェクトには、セキュリティ・キー、データのブロック、またはソフトウェア・モジュールを含めることができる。
【００１０】
このプロトコルは、初期プロビジョニングにWAP 2.0ブートストラップを使用し、初期プロビジョニング後の継続する管理には一連のDMプロトコル仕様を使用する。
【００１１】
現在、オーバーザエアでモバイル・サービスを管理する統一された方法がない。本発明以前には利用可能でなかったが必要とされるものは、ネットワーク・サービス・プロバイダが単純なメカニズムを使用してモバイル・デバイスおよびサービスを管理する統合された方法である。OMA DM、IOTA−HCM、IS−683、独自のOTA、OTAテレサービスなどのような現在利用可能な様々なOTA管理用の規格は、このニーズを満足のいく態様で満たしていない。
【非特許文献１】OMA SyncML HTTP Binding, Version 1.1.2, OMA, June 12, 2003、
【非特許文献２】OMA SyncML OBEX Binding, version 1.1.2, OMA, June 12, 2003、
【非特許文献３】OMA SyncML Device Management Protocol, version 1.1.2, OMA, June 12, 2003. http://www.openmobilealliance.org/releasejprogram/enabler_releases.html、
【非特許文献４】OMA SyncML Representation Protocol, Device Management usage, version 1.1.2, OMA, June 12, 2003、
【非特許文献５】OMA SyncML Device Management Bootstrap, version 1.1.2, OMA, June 12, 2003、
【非特許文献６】OMA SyncML DM DDF DTD (SyncML_dm_ddf_vl 11_20021 OO2.dtd), version 1.1.2, OMA, June 12, 2003、
【非特許文献７】OMA SyncML Device Management Tree and Descriptions, version 1.1.2, OMA, June 12, 2003、
【非特許文献８】OMA SyncML Device Management Notification Initiated Session, version 1.1.2, OMA, June 12, 2003、OMA SyncML Device Management Security, version 1.1.2, OMA, June 12, 2003、
【非特許文献９】OMA SyncML WSP Binding, version 1.1.1, OMA, June 12, 2003
【好適な実施形態のまとめ】
【００１２】
本発明について現在好適である様々な実施形態によれば、上述の問題や他の問題が解決され、他のメリットが実現される。
【００１３】
エンドツーエンドIPプロトコルを使用して、非IP OTAプロトコルを取り扱う、1つのデータ・プロセッサまたは複数のデータ・プロセッサによって実行可能な方法、システム、およびコンピュータ・プログラムが開示される。この方法は、非IPエンティティからメッセージを受信すること；メッセージおよびコンテンツ表現にマークアップ言語を使用すること（ただしここで、マークアップ言語メッセージにおいて非IPプロトコル・コンテンツが、コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別される）；および、このメッセージを送ることを含む。マークアップ言語を使用する段階は、好ましくは、マークアップ言語メッセージのレシーバがその内容を抽出できるように、Meta要素を使用してマークアップ言語メッセージの中に受信されたコンテンツをカプセル化することを含む。非IPエンティティから受信されるメッセージは、制限されない例として、IS−683メッセージであってもよい。
【００１４】
本発明の一側面は、エンドツーエンドIPプロトコルを使用して、非IP OTAプロトコルを取り扱うよう動作可能なネットワーク・ノードである。このネットワーク・ノードは、非IPプロトコル・コンテンツを含むメッセージを受信するレシーバと、XMLマークアップ言語メッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される非IPプロトコル・コンテンツを、XMLの「Meta」要素を用いてXMLマークアップ言語メッセージの中にカプセル化するよう、メッセージおよびコンテンツ表現のためのXMLなどのマークアップ言語と共に動作可能なプロセッサを含む。このMeta要素はメタコンテンツ・タイプを「非IPプロトコル名」として記述する。このネットワーク・ノードはさらに、非IPプロトコル・コンテンツを含むXMLメッセージを受信側に対して無線ネットワークを介して送信するトランスミッタを含む。
【００１５】
本発明のさらなる側面は、非IPクライアントと、エンドツーエンドIPプロトコルを使用して、非IPプロトコル・コンテンツ・メッセージを含むマークアップ言語メッセージを受信するレシーバとを有する移動局である。この移動局は、さらにメタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語「Meta」要素の存在に応じて、受信されたメッセージから非IPベースのコンテンツ・メッセージを抽出するよう、メッセージおよびコンテンツ表現のためのマークアップ言語によって動作可能なプロセッサを含む。
【００１６】
本発明のさらなる側面は、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードである。このネットワーク・ノードは、非IPプロトコル・コンテンツを含むメッセージを受信するためのレシーバ手段であって、XMLメッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される非IPプロトコル・コンテンツを、マークアップ言語の「Meta」要素を用いてXML言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現のための拡張可能なマークアップ言語（Extensible Markup Language：XML）などのマークアップ言語によって動作可能なデータ・プロセッサ手段に接続されたレシーバ手段を含む。このMeta要素は、メタコンテンツ・タイプを「非IPプロトコル名」として記述する。このネットワーク・ノードはさらに、非IPプロトコル・コンテンツを含むXMLメッセージを受信側に対し無線ネットワークを介して送信するための、データ・プロセッサ手段に接続されたトランスミッタ手段をさらに含む。
【００１７】
本発明のさらなる側面は、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、非IPエンティティからメッセージを受信するステップと、メッセージおよびコンテンツ表現にマークアップ言語を使用するステップであって、メッセージにおいて非IPプロトコル・コンテンツが「Meta」要素を用いて識別され、Meta要素がコンテンツタイプを「非IPプロトコル名」として記述するものであるステップと、このメッセージを「Meta」要素と共に送るステップとを含む方法を提供する。
【００１８】
本発明の本好適な実施形態の上述および別の側面は、以下の発明を実施するための最良の形態を添付の図面とともに読むことでさらに明らかになるであろう。
【好適な実施形態の詳細な説明】
【００１９】
はじめに述べると、本発明の実施形態は、異なるOTAプロトコルを統合するために使用することができるため、モバイル・デバイスおよびサービスを管理する統一された方法となる。特に、本発明の実施形態は非インターネット・プロトコル（非IP）管理プロトコルをIPベースのプロトコルを用いて扱えるようにしている。
【００２０】
本発明の実施形態は、異なるネットワークにおけるOTA管理のための、および、このようなネットワークにあるヘテロジニアスなモバイル・デバイスとのOTA管理のための、統合されたアプローチを実現するために、IPベースのプロトコルを使用することを可能とする。本発明の好適な実施形態を使用することで、無線サービス・プロバイダは、自身のネットワークおよびサービス・ドメインにおいて提供されるモバイル・デバイスおよびサービスを管理する統一されたメカニズムを自由に有することができるようになる。
【００２１】
本発明の好適な実施形態は、レガシー・システムで使用された非IPプロトコルとの後方互換を達成するため、特別なメタタイプならびに特別なDMプロトコルの使用法を用いる。これにより、異なったネットワークで様々な機能のあるモバイル・デバイスを管理するために、マークアップ言語ベース（すなわち、XMLベース）のDMプロトコルを使用することが可能となる。
【００２２】
本発明の好適な実施形態を使用すると、レガシー・モバイル・システムの既存のコンポーネントを再利用することによって、コスト削減をもたらすことができる。
【００２３】
また、本発明の好適な実施形態を使用することにより、サービス・ドメインにおいて提供されたモバイル・サービスをサービス・プロバイダが管理する統合された方法が提供され、レガシーな機能、ならびに第3世代（3G）機能および次世代の機能を統合する手助けとなる。
【００２４】
本発明の好適な実施形態は、モバイル・デバイスに実装できる。レガシーな機能をサポートするために、既存のソフトウェア・コンポーネントを再利用して、モバイル・デバイスの中に統合されたエンティティを展開することができる。したがって、3Gおよび次世代の新しい機能を統合することができる。よって、本発明の好適な実施形態は、レガシーな機能および新しい機能の両方をサポートし、この両方に適用する統合されたメカニズムを提供する。CDMAモバイル・デバイスには、OTASP／OTAPAコンポーネントを再利用できる。
【００２５】
本発明の実施形態を適切な技術状況に置くため、例としてのCDMAネットワークにおけるDM用のネットワーク・アーキテクチャを示す図1を参照する。CDMAインターフェースのみが示されているが、OMA DM仕様は、低電力RF（例えば、Bluetooth（商標））および赤外線（例えば、IrDA）などのローカルアクセス技術全体のDMもサポートする。また、IOTA−DM用のエンドツーエンド・アーキテクチャを示す図2を参照すると、移動装置（ME）とも称される携帯電話などの移動局（MS）1およびセルラー（例えば、CDMA）無線ネットワークのような無線ネットワーク22を介してMS1に接続されるDMサーバ2が備えられている。
【００２６】
一般に、MS1の様々な実施形態には、携帯電話、無線通信機能を有する携帯情報端末（PDA）、無線通信機能を有する携帯用コンピュータ、無線通信機能を有するデジタルカメラのようなイメージ・キャプチャ・デバイス、無線通信機能を有するゲーム・デバイス、無線通信機能を有する音楽格納および再生機器、無線インターネット・アクセスおよびブラウジングを可能とさせるインターネット家電、およびこれらの機能の組み合わせを組み込んだ携帯用ユニットまたは端末を含むことができるがこれに限定されない。また、非携帯用デバイスもこれらの教示の範囲内である。
【００２７】
これらの図において、MS1は、DMクライアント10を備えているものとし、このDMクライアントはDMのメッセージおよびコマンドを処理し、権限の付与を行ない、DM管理ツリーへのアクセスを扱う。管理オブジェクト12は、アプリケーションおよびサービスに関連づけられるパラメータ、ソフトウェア・オブジェクト、コンフィギュレーション・データ・ブロックなどを含む。管理オブジェクト12は、階層ツリーにおいて論理的に関連するグループ（またはサブツリー）として構成される。またMS1は、アプリケーション14も含むものとされる。
【００２８】
DMサーバ2は、MS1におけるサービスおよびアプリケーションを管理するネットワークにおいてのエンティティである。DMサーバ2は、DMコマンドを発行し、DMクライアント10からの応答を正しく翻訳する。DMサーバ2は、デバイス・デスクリプション・フレームワーク（Device Description Framework ：DDF）16ドキュメントを含むDMデータベース2Aを備えている。本発明の好適な限定されない実施形態におけるDDF 16ドキュメントは、デバイス中の管理オブジェクトのプロパティを記述するXMLドキュメント（拡張可能なマークアップ言語（XML）1.0（2版）W3C勧告、バージョン1.1.2、ワールドワイドウェブ・コンソーシアム（Extensible Markup Language （XML）1.0（Second Edition），W3C Recommendation，Version 6−October−2000，World Wide Web Consortium））である。
【００２９】
OMA DMプロトコル（OMA SyncML Device Management Protocol，version 1.1.2，OMA，June 12，2003）は、管理フレームワークおよびMS1とDMサーバ2と称されるネットワーク・エンティティとの間で交換される一連のメッセージを定義する。
【００３０】
また完全に示すと、図1には例えば、ANSI−41ネットワーク30、インターネット・プロトコル（IP）ネットワーク32を含む様々なネットワーク（N／W）がある。ANSI−41ネットワーク30には、メッセージング・センター（MC）34、ホーム・ロケーション・レジスタ（HLR）36、オーバーザエア機能（OATF）38、およびモバイル・スイッチング・センタ／ビジタ・ロケーション・レジスタ・ペア（MSC／VLR）40が接続されている。MC34は、DMサーバ2に接続され、一方でMSC／VLR40は、基地局コントローラ／パケット制御機能（BSC／PCF）42に接続され、IPネットワーク32に関連するパケット・データ・サポート・ノード（PDSN）44も同様に基地局コントローラ／パケット制御機能（BSC／PCF）42に接続されている。また、IPネットワーク32は、さまざまな権限付与、認証、アカウンティング（AAA）機能46、48およびホーム・エージェント（HA）50に関連している。HA50は、IPネットワーク32をDMサーバ2に接続する。DMサーバ2の上方には、コンフィギュレーション管理機能60A、サービス管理60B、CDMA OTAサービス・プロビジョニング（OTA Service Provisioning：OTASP）およびOTAパラメータ管理（OTA Parameter Administration：OTAPA）60C、エンタープライズ管理60D、ならびにソフトウェア理60Eを含む複数の管理機能60の例が示されている。
【００３１】
また図2において、MS1と無線ネットワーク22との間、およびDMサーバ2と無線ネットワーク22との間に、適切なハイパーテキスト・トランスファー・プロトコル（Hyper Text Transfer Protocol：HTTP）、オブジェクト・エクスチェンジ・プロトコル（Object Exchange Protocol ：OBEX）、およびショート・メッセージ・サービス（Short Message Service：SMS）70Aおよび70Bがそれぞれ置かれている。
【００３２】
本発明の側面は、IPベースのプロトコルを使用した非IP管理プロトコルの取り扱いに関する。制限されない例において、非IP管理プロトコルはIS−683メッセージのコンテンツに記されている（IS−683は、3GPPではC.S0016として知られる、cdma2000システムにおけるOTAプロビジョニングおよびOTAパラメータ管理のためのTIA／EIAおよび3GPPプロトコルである）。
【００３３】
図3は、典型的なIS−683メッセージを扱う場合の、少なくとも1つの非IPクライアント20と、DMクライアント10と、無線ネットワーク22（例えば、CDMAネットワークまたはBluetooth（商標）ネットワーク）と、IPベース・サーバ24と、少なくとも1つの非IPネットワーク・エンティティ26との間のメッセージ・フローを示している。
【００３４】
ここで、IPベースのプロトコルを使用した非IP管理プロトコルの扱いを更に具体的に述べる。現在のIPベースの管理プロトコルは、広い範囲の非IPプロトコルとの後方互換をサポートしていないことが注目される。しかし、統合されたフレームワークでは、IPプロトコルのみならず非IPプロトコルも扱うことが必要となる。
【００３５】
本発明の側面によれば、メッセージおよびコンテンツの表現のためのXMLを使用するエンドツーエンドIPプロトコルを用いて、非IP OTAプロトコルを扱うことができる。XMLメッセージにおいて、非IPプロトコルのコンテンツはXMLの「Meta」要素を用いて識別される。
【００３６】
図3に示される本発明による方法の実施形態は、Meta要素がコンテンツタイプを「非IPプロトコル名」として記述する。例えば、使用されるXMLプロトコルがSyncMLに基づくものであり、非IPプロトコルがIS−683の場合、コンテンツタイプは「syncml-dm:cdma-is683」として表現できる。Nokia−Ericsson OTA（例えばhttp://www.forum.nokis.com/main/l,6566,l_47_50,00.htmlを参照）として知られるがこれに限定されないような独自のプロトコルについては、「syncml-dm:nokia-ota」のように表現できる。
【００３７】
論理的な流れ図としても見ることのできる図3の処理は以下のとおりである。
【００３８】
ステップA。IPベース・サーバ24がIS−683リクエスト・メッセージなどのような非IPプロトコル・メッセージを傍受し、上記のように「Meta」要素を使用してこの非IPプロトコル・メッセージをXMLメッセージの中にカプセル化する。
【００３９】
ステップB。カプセル化された非IPメッセージを有するXMLメッセージが、無線ネットワーク22を介してDMメッセージとしてDMクライアント10に送られる。
【００４０】
ステップC。XMLの可能なDMクライアント10がこのDMメッセージを受信し、Metaタイプを非IPメッセージ・コンテンツとして識別し、このメタコンテンツを抽出する。コンテンツのエンコーディングは、フォーマット要素を用いて「Meta」要素の中で指定できる。
【００４１】
ステップD。XMLの可能なDMクライアント10がMS1の中の非IPクライアント20を呼び出し、非IPプロトコル・フォーマットでメタコンテンツを非IPクライアント20へ渡す。一般的な場合において、MS1は複数の非IPクライアント20を含んでいることがあり、この場合、DMクライアント10が受信されたメッセージからデスティネーションの非IPクライアント20の識別を決定し、メタデータを正しいデスティネーションである非IPクライアントにルートするということは注意すべきである。また、上記のようにIPベース・サーバ24によって傍受および処理されるメッセージ（IS−683または他のタイプのメッセージ）を送る複数の非IPネットワーク・エンティティ26があり得ることも一般的であることも注意されたい。
【００４２】
ステップE。非IPクライアント20がメタコンテンツを含むメッセージを処理し、応答を送ることができる。この応答シーケンスは、ステップA、B、CおよびDと同じシーケンスに従う。すなわち、ステップFで、先に述べたようにDMクライアント10が「Meta」要素を使用して非IP応答をXMLメッセージの中にカプセル化する。ステップGにおいて、DMメッセージがIPベース・サーバ24に送られ、このIPベース・サーバがメタコンテンツを抽出し（ステップH）、適切なIS−683応答メッセージにフォーマットし、非IPネットワーク・エンティティ26に送り返す（ステップI）。
【００４３】
上記ステップCおよびXML表現のためにSyncMLを使用するとき、XMLメッセージの中で「Exec」コマンドを指定し、Execコマンドのターゲットを非IPプロトコル用の管理ツリー中のノードとして指定することによって、非IPクライアント20を呼び出すことができる。
【００４４】
非IPプロトコルが3GPP2 IS−683の場合、ノード名はIS−683によって指定することができる。例えば、このノードのユニフォーム・リソース・インジケータ（Uniform Resource Indicator：URI）は、「./root/...cdma/is-683」とすることができる。
【００４５】
図4は、上記の方法およびシステムに従ったエンドツーエンド・メッセージの表現の例を示している。
【００４６】
図3の様々な方法ステップは、MS1、IPベース・サーバ24およびDMクライアント20のような、図3の注目のノードに配置された適切にプログラミング可能なデータ・プロセッサによってインプリメントすることができる。
【００４７】
本発明の実施形態において、非IP・エンティティ26から受信されたメッセージは、IS−683メッセージを含むことができ、IS−683プロトコルの別のバージョンを含むことができるということが理解できる。
【００４８】
本発明の実施形態において、XMLメッセージは、URIおよび／または「コマンド」のようなメタコンテンツの処理のためのさらなる情報を含むことができるということが理解できる。この「コマンド」は、メタタイプを扱うためにXMLメッセージのレシーバの中のプロセスを呼び出す1つ以上のコマンドのようなものであり、メタデータは、Base64（b64）エンコードされたもの、または「Format」要素で指定されるような別の形式でエンコードされたものとすることができる。
【００４９】
また、本発明の実施形態において、非IPプロトコル・エンティティ26から受信されるメッセージには、例として、Nokia−Ericsson OTAメッセージ（上記参照）を含めることができるということが理解できる。
【００５０】
さらに、XMLメッセージは、SyncML DM、またはOMA DMメッセージを含むことができ、XMLプロトコルは3GPP2 IOTA−DMメッセージを含むことができる。
【００５１】
本発明の実施形態を使用すると、ソフトウェア・コンポーネントの再利用によって大幅なコスト削減が提供されるということが理解できよう。各ネットワークに対して一般的に何千ものデバイスがあり、開発者は既存の機能のためにコードを再び記述する代わりに、高度な技術および機能に焦点を当てることができ、よってキャリアが、本願明細書に記された共通の統合されたプロビジョニング・メカニズムを使用して、これらの高度な機能およびサービスをモバイル・ユーザに提供することができる。
【００５２】
上記記載は、本発明を実施するため、発明者らにより現時点で考慮された最良の方法および装置について、余すところなく情報を提供する限定の意図を有しない例を示す記載であるが、前述の記載に鑑みて、添付図面および特許請求の範囲とともに併せ読むことにより、種々の変更および改作が可能であることは、関連技術における当業者に理解されよう。いくつかの例を除いて、他の同様または同一のメッセージ形式、コンテンツ表現等を当業者は使用することができる。
【００５３】
しかし、本発明の教示によるこれらすべておよび同等の変更は、本発明の実施形態の範囲内のものである。
【００５４】
さらに、本発明の好適な実施形態のいくつかの機能は、他の機能を対応させて用いることなく有利に使用できる。したがって、前述の記載は単に本発明の実施形態の原理および教示を説明するものに過ぎず、これを限定するものではない。
【図面の簡単な説明】
【００５５】
【図１】CDMAベースのDMネットワーク・アーキテクチャの簡略ブロック図である。
【図２】IOTA−DMのエンドツーエンド・アーキテクチャを示す図である。
【図３】非IP DMメッセージの例、この場合制限されない例であるIS−683DMメッセージを適用させるためのメッセージ・フローを示す図である。
【図４】図3の例による、エンドツーエンドのメッセージ・フォーマットの表現を示す図である。
【技術分野】
【０００１】
本発明の好適な実施形態は、一般的に無線通信システムおよび方法に関し、特に何ら限定する例示ではないが携帯電話のようなモバイル・デバイスへ情報を配信するためのオーバーザエア（over−the−air：OTA）デバイス管理手順に関する。
【背景技術】
【０００２】
モバイル・デバイスの機能が加速する速さで進化するにつれ、モバイル・デバイス上でのサービスおよび性能をコンフィギュレーションおよびメンテナンスすることは、複雑で時間のかかる作業となる。例えば、ワイヤレス・アプリケーション・プロトコル（Wireless Application Protocol：WAP）、CDMAおよびデータ接続を可能とさせるには、複数の設定のコンフィギュレーションが必要となる。現在利用可能な限られた機能についてでさえも、自分のモバイル・デバイスのコンフィギュレーション方法を知らないユーザもいる。
【０００３】
別の使用ケースとして、モバイル・デバイスへの新しいサービスのOTAプロビジョニングおよび管理がある。ブラウジング、マルチメディア・メッセージング、モバイルEメールおよびカレンダー同期等の高度のモバイル・サービスでは、正確なモバイル・デバイスの設定が必要となる。デバイス設定およびアプリケーションを遠隔で管理するプロセスをデバイス管理と称する。
【０００４】
OTA管理は、3GPP2 OTASP／OTAPA、OMA（Open Mobile Alliance）Device Management（OMA DM）および3GPP2 IOTA−DM規格（IOTA−DMは、「IP based over−the−air device management（IPベースのオーバーザエア・デバイス管理）」を表わしている）で定義されている。
【０００５】
現在、モバイル・デバイスを遠隔管理する非インターネット・プロトコルベースの技術もある。例えば、IS−683規格（TIA／EIA−683−C、スペクトラム拡散システムにおける移動局のオーバーザエア・サービス・プロビジョニング（Over−the−Air Service Provisioning of Mobile Stations in Spread Spectrum Systems）、2003年3月）では、移動局を遠隔で管理するエア・インターフェース・シグナリングを採用するプロトコルを定義している。非IPプロトコルを使用する別の例としては、プロプライエタリのショート・メッセージ・サービス（Short Message Service：SMS）ベースのプロトコルの使用が挙げられる。
【０００６】
デバイス管理は、モバイル・サービスの広い採用を手助けすることを意図しており、加入者が新しいサービスに簡単に申し込みができるようなメカニズムを提供する。これは、ネットワーク・オペレータに対し、新しいサービスおよび管理プロビジョン・サービスを導入する早くて簡単な方法を、変更に対して動的に調節し一定レベルのサービスを保証することによって可能とさせる。
【０００７】
2003年6月、OMAは、SyncML DM（同期マークアップ言語デバイス管理（Synchronization markup language device management））に基づいて、OMA Device Management（OMA DM） Version 1.1.2規格をリリースした。これに関しては下掲非特許文献１〜９を参照するとよい。
【０００８】
OMA DMは、3Gモバイル・デバイスおよびその後の世代のOTA管理ニーズのために統合された拡張可能なフレームワークを提供する。この規格には、SyncML DMプロトコルに基づいたOMA DMプロトコル仕様が含まれる。このプロトコルは、基本的な考慮事項がモバイル・デバイスのリソースおよび帯域幅制限に関連するものである、OTA管理用に最適化されている。
【０００９】
メカニズムとしてのOMA DMは、非常に用途が広く様々なデータ・オブジェクトのタイプを管理するために使用することができる。このデータ・オブジェクトは、単純な数値またはテキスト・パラメータのものもあれば、本質的にバイナリのものもある。数値オブジェクトには、アクセス・ポイント・アドレスおよびプロキシ設定などの接続パラメータを含めることができる。また、バイナリ・オブジェクトには、セキュリティ・キー、データのブロック、またはソフトウェア・モジュールを含めることができる。
【００１０】
このプロトコルは、初期プロビジョニングにWAP 2.0ブートストラップを使用し、初期プロビジョニング後の継続する管理には一連のDMプロトコル仕様を使用する。
【００１１】
現在、オーバーザエアでモバイル・サービスを管理する統一された方法がない。本発明以前には利用可能でなかったが必要とされるものは、ネットワーク・サービス・プロバイダが単純なメカニズムを使用してモバイル・デバイスおよびサービスを管理する統合された方法である。OMA DM、IOTA−HCM、IS−683、独自のOTA、OTAテレサービスなどのような現在利用可能な様々なOTA管理用の規格は、このニーズを満足のいく態様で満たしていない。
【非特許文献１】OMA SyncML HTTP Binding, Version 1.1.2, OMA, June 12, 2003、
【非特許文献２】OMA SyncML OBEX Binding, version 1.1.2, OMA, June 12, 2003、
【非特許文献３】OMA SyncML Device Management Protocol, version 1.1.2, OMA, June 12, 2003. http://www.openmobilealliance.org/releasejprogram/enabler_releases.html、
【非特許文献４】OMA SyncML Representation Protocol, Device Management usage, version 1.1.2, OMA, June 12, 2003、
【非特許文献５】OMA SyncML Device Management Bootstrap, version 1.1.2, OMA, June 12, 2003、
【非特許文献６】OMA SyncML DM DDF DTD (SyncML_dm_ddf_vl 11_20021 OO2.dtd), version 1.1.2, OMA, June 12, 2003、
【非特許文献７】OMA SyncML Device Management Tree and Descriptions, version 1.1.2, OMA, June 12, 2003、
【非特許文献８】OMA SyncML Device Management Notification Initiated Session, version 1.1.2, OMA, June 12, 2003、OMA SyncML Device Management Security, version 1.1.2, OMA, June 12, 2003、
【非特許文献９】OMA SyncML WSP Binding, version 1.1.1, OMA, June 12, 2003
【好適な実施形態のまとめ】
【００１２】
本発明について現在好適である様々な実施形態によれば、上述の問題や他の問題が解決され、他のメリットが実現される。
【００１３】
エンドツーエンドIPプロトコルを使用して、非IP OTAプロトコルを取り扱う、1つのデータ・プロセッサまたは複数のデータ・プロセッサによって実行可能な方法、システム、およびコンピュータ・プログラムが開示される。この方法は、非IPエンティティからメッセージを受信すること；メッセージおよびコンテンツ表現にマークアップ言語を使用すること（ただしここで、マークアップ言語メッセージにおいて非IPプロトコル・コンテンツが、コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別される）；および、このメッセージを送ることを含む。マークアップ言語を使用する段階は、好ましくは、マークアップ言語メッセージのレシーバがその内容を抽出できるように、Meta要素を使用してマークアップ言語メッセージの中に受信されたコンテンツをカプセル化することを含む。非IPエンティティから受信されるメッセージは、制限されない例として、IS−683メッセージであってもよい。
【００１４】
本発明の一側面は、エンドツーエンドIPプロトコルを使用して、非IP OTAプロトコルを取り扱うよう動作可能なネットワーク・ノードである。このネットワーク・ノードは、非IPプロトコル・コンテンツを含むメッセージを受信するレシーバと、XMLマークアップ言語メッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される非IPプロトコル・コンテンツを、XMLの「Meta」要素を用いてXMLマークアップ言語メッセージの中にカプセル化するよう、メッセージおよびコンテンツ表現のためのXMLなどのマークアップ言語と共に動作可能なプロセッサを含む。このMeta要素はメタコンテンツ・タイプを「非IPプロトコル名」として記述する。このネットワーク・ノードはさらに、非IPプロトコル・コンテンツを含むXMLメッセージを受信側に対して無線ネットワークを介して送信するトランスミッタを含む。
【００１５】
本発明のさらなる側面は、非IPクライアントと、エンドツーエンドIPプロトコルを使用して、非IPプロトコル・コンテンツ・メッセージを含むマークアップ言語メッセージを受信するレシーバとを有する移動局である。この移動局は、さらにメタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語「Meta」要素の存在に応じて、受信されたメッセージから非IPベースのコンテンツ・メッセージを抽出するよう、メッセージおよびコンテンツ表現のためのマークアップ言語によって動作可能なプロセッサを含む。
【００１６】
本発明のさらなる側面は、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードである。このネットワーク・ノードは、非IPプロトコル・コンテンツを含むメッセージを受信するためのレシーバ手段であって、XMLメッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される非IPプロトコル・コンテンツを、マークアップ言語の「Meta」要素を用いてXML言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現のための拡張可能なマークアップ言語（Extensible Markup Language：XML）などのマークアップ言語によって動作可能なデータ・プロセッサ手段に接続されたレシーバ手段を含む。このMeta要素は、メタコンテンツ・タイプを「非IPプロトコル名」として記述する。このネットワーク・ノードはさらに、非IPプロトコル・コンテンツを含むXMLメッセージを受信側に対し無線ネットワークを介して送信するための、データ・プロセッサ手段に接続されたトランスミッタ手段をさらに含む。
【００１７】
本発明のさらなる側面は、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、非IPエンティティからメッセージを受信するステップと、メッセージおよびコンテンツ表現にマークアップ言語を使用するステップであって、メッセージにおいて非IPプロトコル・コンテンツが「Meta」要素を用いて識別され、Meta要素がコンテンツタイプを「非IPプロトコル名」として記述するものであるステップと、このメッセージを「Meta」要素と共に送るステップとを含む方法を提供する。
【００１８】
本発明の本好適な実施形態の上述および別の側面は、以下の発明を実施するための最良の形態を添付の図面とともに読むことでさらに明らかになるであろう。
【好適な実施形態の詳細な説明】
【００１９】
はじめに述べると、本発明の実施形態は、異なるOTAプロトコルを統合するために使用することができるため、モバイル・デバイスおよびサービスを管理する統一された方法となる。特に、本発明の実施形態は非インターネット・プロトコル（非IP）管理プロトコルをIPベースのプロトコルを用いて扱えるようにしている。
【００２０】
本発明の実施形態は、異なるネットワークにおけるOTA管理のための、および、このようなネットワークにあるヘテロジニアスなモバイル・デバイスとのOTA管理のための、統合されたアプローチを実現するために、IPベースのプロトコルを使用することを可能とする。本発明の好適な実施形態を使用することで、無線サービス・プロバイダは、自身のネットワークおよびサービス・ドメインにおいて提供されるモバイル・デバイスおよびサービスを管理する統一されたメカニズムを自由に有することができるようになる。
【００２１】
本発明の好適な実施形態は、レガシー・システムで使用された非IPプロトコルとの後方互換を達成するため、特別なメタタイプならびに特別なDMプロトコルの使用法を用いる。これにより、異なったネットワークで様々な機能のあるモバイル・デバイスを管理するために、マークアップ言語ベース（すなわち、XMLベース）のDMプロトコルを使用することが可能となる。
【００２２】
本発明の好適な実施形態を使用すると、レガシー・モバイル・システムの既存のコンポーネントを再利用することによって、コスト削減をもたらすことができる。
【００２３】
また、本発明の好適な実施形態を使用することにより、サービス・ドメインにおいて提供されたモバイル・サービスをサービス・プロバイダが管理する統合された方法が提供され、レガシーな機能、ならびに第3世代（3G）機能および次世代の機能を統合する手助けとなる。
【００２４】
本発明の好適な実施形態は、モバイル・デバイスに実装できる。レガシーな機能をサポートするために、既存のソフトウェア・コンポーネントを再利用して、モバイル・デバイスの中に統合されたエンティティを展開することができる。したがって、3Gおよび次世代の新しい機能を統合することができる。よって、本発明の好適な実施形態は、レガシーな機能および新しい機能の両方をサポートし、この両方に適用する統合されたメカニズムを提供する。CDMAモバイル・デバイスには、OTASP／OTAPAコンポーネントを再利用できる。
【００２５】
本発明の実施形態を適切な技術状況に置くため、例としてのCDMAネットワークにおけるDM用のネットワーク・アーキテクチャを示す図1を参照する。CDMAインターフェースのみが示されているが、OMA DM仕様は、低電力RF（例えば、Bluetooth（商標））および赤外線（例えば、IrDA）などのローカルアクセス技術全体のDMもサポートする。また、IOTA−DM用のエンドツーエンド・アーキテクチャを示す図2を参照すると、移動装置（ME）とも称される携帯電話などの移動局（MS）1およびセルラー（例えば、CDMA）無線ネットワークのような無線ネットワーク22を介してMS1に接続されるDMサーバ2が備えられている。
【００２６】
一般に、MS1の様々な実施形態には、携帯電話、無線通信機能を有する携帯情報端末（PDA）、無線通信機能を有する携帯用コンピュータ、無線通信機能を有するデジタルカメラのようなイメージ・キャプチャ・デバイス、無線通信機能を有するゲーム・デバイス、無線通信機能を有する音楽格納および再生機器、無線インターネット・アクセスおよびブラウジングを可能とさせるインターネット家電、およびこれらの機能の組み合わせを組み込んだ携帯用ユニットまたは端末を含むことができるがこれに限定されない。また、非携帯用デバイスもこれらの教示の範囲内である。
【００２７】
これらの図において、MS1は、DMクライアント10を備えているものとし、このDMクライアントはDMのメッセージおよびコマンドを処理し、権限の付与を行ない、DM管理ツリーへのアクセスを扱う。管理オブジェクト12は、アプリケーションおよびサービスに関連づけられるパラメータ、ソフトウェア・オブジェクト、コンフィギュレーション・データ・ブロックなどを含む。管理オブジェクト12は、階層ツリーにおいて論理的に関連するグループ（またはサブツリー）として構成される。またMS1は、アプリケーション14も含むものとされる。
【００２８】
DMサーバ2は、MS1におけるサービスおよびアプリケーションを管理するネットワークにおいてのエンティティである。DMサーバ2は、DMコマンドを発行し、DMクライアント10からの応答を正しく翻訳する。DMサーバ2は、デバイス・デスクリプション・フレームワーク（Device Description Framework ：DDF）16ドキュメントを含むDMデータベース2Aを備えている。本発明の好適な限定されない実施形態におけるDDF 16ドキュメントは、デバイス中の管理オブジェクトのプロパティを記述するXMLドキュメント（拡張可能なマークアップ言語（XML）1.0（2版）W3C勧告、バージョン1.1.2、ワールドワイドウェブ・コンソーシアム（Extensible Markup Language （XML）1.0（Second Edition），W3C Recommendation，Version 6−October−2000，World Wide Web Consortium））である。
【００２９】
OMA DMプロトコル（OMA SyncML Device Management Protocol，version 1.1.2，OMA，June 12，2003）は、管理フレームワークおよびMS1とDMサーバ2と称されるネットワーク・エンティティとの間で交換される一連のメッセージを定義する。
【００３０】
また完全に示すと、図1には例えば、ANSI−41ネットワーク30、インターネット・プロトコル（IP）ネットワーク32を含む様々なネットワーク（N／W）がある。ANSI−41ネットワーク30には、メッセージング・センター（MC）34、ホーム・ロケーション・レジスタ（HLR）36、オーバーザエア機能（OATF）38、およびモバイル・スイッチング・センタ／ビジタ・ロケーション・レジスタ・ペア（MSC／VLR）40が接続されている。MC34は、DMサーバ2に接続され、一方でMSC／VLR40は、基地局コントローラ／パケット制御機能（BSC／PCF）42に接続され、IPネットワーク32に関連するパケット・データ・サポート・ノード（PDSN）44も同様に基地局コントローラ／パケット制御機能（BSC／PCF）42に接続されている。また、IPネットワーク32は、さまざまな権限付与、認証、アカウンティング（AAA）機能46、48およびホーム・エージェント（HA）50に関連している。HA50は、IPネットワーク32をDMサーバ2に接続する。DMサーバ2の上方には、コンフィギュレーション管理機能60A、サービス管理60B、CDMA OTAサービス・プロビジョニング（OTA Service Provisioning：OTASP）およびOTAパラメータ管理（OTA Parameter Administration：OTAPA）60C、エンタープライズ管理60D、ならびにソフトウェア理60Eを含む複数の管理機能60の例が示されている。
【００３１】
また図2において、MS1と無線ネットワーク22との間、およびDMサーバ2と無線ネットワーク22との間に、適切なハイパーテキスト・トランスファー・プロトコル（Hyper Text Transfer Protocol：HTTP）、オブジェクト・エクスチェンジ・プロトコル（Object Exchange Protocol ：OBEX）、およびショート・メッセージ・サービス（Short Message Service：SMS）70Aおよび70Bがそれぞれ置かれている。
【００３２】
本発明の側面は、IPベースのプロトコルを使用した非IP管理プロトコルの取り扱いに関する。制限されない例において、非IP管理プロトコルはIS−683メッセージのコンテンツに記されている（IS−683は、3GPPではC.S0016として知られる、cdma2000システムにおけるOTAプロビジョニングおよびOTAパラメータ管理のためのTIA／EIAおよび3GPPプロトコルである）。
【００３３】
図3は、典型的なIS−683メッセージを扱う場合の、少なくとも1つの非IPクライアント20と、DMクライアント10と、無線ネットワーク22（例えば、CDMAネットワークまたはBluetooth（商標）ネットワーク）と、IPベース・サーバ24と、少なくとも1つの非IPネットワーク・エンティティ26との間のメッセージ・フローを示している。
【００３４】
ここで、IPベースのプロトコルを使用した非IP管理プロトコルの扱いを更に具体的に述べる。現在のIPベースの管理プロトコルは、広い範囲の非IPプロトコルとの後方互換をサポートしていないことが注目される。しかし、統合されたフレームワークでは、IPプロトコルのみならず非IPプロトコルも扱うことが必要となる。
【００３５】
本発明の側面によれば、メッセージおよびコンテンツの表現のためのXMLを使用するエンドツーエンドIPプロトコルを用いて、非IP OTAプロトコルを扱うことができる。XMLメッセージにおいて、非IPプロトコルのコンテンツはXMLの「Meta」要素を用いて識別される。
【００３６】
図3に示される本発明による方法の実施形態は、Meta要素がコンテンツタイプを「非IPプロトコル名」として記述する。例えば、使用されるXMLプロトコルがSyncMLに基づくものであり、非IPプロトコルがIS−683の場合、コンテンツタイプは「syncml-dm:cdma-is683」として表現できる。Nokia−Ericsson OTA（例えばhttp://www.forum.nokis.com/main/l,6566,l_47_50,00.htmlを参照）として知られるがこれに限定されないような独自のプロトコルについては、「syncml-dm:nokia-ota」のように表現できる。
【００３７】
論理的な流れ図としても見ることのできる図3の処理は以下のとおりである。
【００３８】
ステップA。IPベース・サーバ24がIS−683リクエスト・メッセージなどのような非IPプロトコル・メッセージを傍受し、上記のように「Meta」要素を使用してこの非IPプロトコル・メッセージをXMLメッセージの中にカプセル化する。
【００３９】
ステップB。カプセル化された非IPメッセージを有するXMLメッセージが、無線ネットワーク22を介してDMメッセージとしてDMクライアント10に送られる。
【００４０】
ステップC。XMLの可能なDMクライアント10がこのDMメッセージを受信し、Metaタイプを非IPメッセージ・コンテンツとして識別し、このメタコンテンツを抽出する。コンテンツのエンコーディングは、フォーマット要素を用いて「Meta」要素の中で指定できる。
【００４１】
ステップD。XMLの可能なDMクライアント10がMS1の中の非IPクライアント20を呼び出し、非IPプロトコル・フォーマットでメタコンテンツを非IPクライアント20へ渡す。一般的な場合において、MS1は複数の非IPクライアント20を含んでいることがあり、この場合、DMクライアント10が受信されたメッセージからデスティネーションの非IPクライアント20の識別を決定し、メタデータを正しいデスティネーションである非IPクライアントにルートするということは注意すべきである。また、上記のようにIPベース・サーバ24によって傍受および処理されるメッセージ（IS−683または他のタイプのメッセージ）を送る複数の非IPネットワーク・エンティティ26があり得ることも一般的であることも注意されたい。
【００４２】
ステップE。非IPクライアント20がメタコンテンツを含むメッセージを処理し、応答を送ることができる。この応答シーケンスは、ステップA、B、CおよびDと同じシーケンスに従う。すなわち、ステップFで、先に述べたようにDMクライアント10が「Meta」要素を使用して非IP応答をXMLメッセージの中にカプセル化する。ステップGにおいて、DMメッセージがIPベース・サーバ24に送られ、このIPベース・サーバがメタコンテンツを抽出し（ステップH）、適切なIS−683応答メッセージにフォーマットし、非IPネットワーク・エンティティ26に送り返す（ステップI）。
【００４３】
上記ステップCおよびXML表現のためにSyncMLを使用するとき、XMLメッセージの中で「Exec」コマンドを指定し、Execコマンドのターゲットを非IPプロトコル用の管理ツリー中のノードとして指定することによって、非IPクライアント20を呼び出すことができる。
【００４４】
非IPプロトコルが3GPP2 IS−683の場合、ノード名はIS−683によって指定することができる。例えば、このノードのユニフォーム・リソース・インジケータ（Uniform Resource Indicator：URI）は、「./root/...cdma/is-683」とすることができる。
【００４５】
図4は、上記の方法およびシステムに従ったエンドツーエンド・メッセージの表現の例を示している。
【００４６】
図3の様々な方法ステップは、MS1、IPベース・サーバ24およびDMクライアント20のような、図3の注目のノードに配置された適切にプログラミング可能なデータ・プロセッサによってインプリメントすることができる。
【００４７】
本発明の実施形態において、非IP・エンティティ26から受信されたメッセージは、IS−683メッセージを含むことができ、IS−683プロトコルの別のバージョンを含むことができるということが理解できる。
【００４８】
本発明の実施形態において、XMLメッセージは、URIおよび／または「コマンド」のようなメタコンテンツの処理のためのさらなる情報を含むことができるということが理解できる。この「コマンド」は、メタタイプを扱うためにXMLメッセージのレシーバの中のプロセスを呼び出す1つ以上のコマンドのようなものであり、メタデータは、Base64（b64）エンコードされたもの、または「Format」要素で指定されるような別の形式でエンコードされたものとすることができる。
【００４９】
また、本発明の実施形態において、非IPプロトコル・エンティティ26から受信されるメッセージには、例として、Nokia−Ericsson OTAメッセージ（上記参照）を含めることができるということが理解できる。
【００５０】
さらに、XMLメッセージは、SyncML DM、またはOMA DMメッセージを含むことができ、XMLプロトコルは3GPP2 IOTA−DMメッセージを含むことができる。
【００５１】
本発明の実施形態を使用すると、ソフトウェア・コンポーネントの再利用によって大幅なコスト削減が提供されるということが理解できよう。各ネットワークに対して一般的に何千ものデバイスがあり、開発者は既存の機能のためにコードを再び記述する代わりに、高度な技術および機能に焦点を当てることができ、よってキャリアが、本願明細書に記された共通の統合されたプロビジョニング・メカニズムを使用して、これらの高度な機能およびサービスをモバイル・ユーザに提供することができる。
【００５２】
上記記載は、本発明を実施するため、発明者らにより現時点で考慮された最良の方法および装置について、余すところなく情報を提供する限定の意図を有しない例を示す記載であるが、前述の記載に鑑みて、添付図面および特許請求の範囲とともに併せ読むことにより、種々の変更および改作が可能であることは、関連技術における当業者に理解されよう。いくつかの例を除いて、他の同様または同一のメッセージ形式、コンテンツ表現等を当業者は使用することができる。
【００５３】
しかし、本発明の教示によるこれらすべておよび同等の変更は、本発明の実施形態の範囲内のものである。
【００５４】
さらに、本発明の好適な実施形態のいくつかの機能は、他の機能を対応させて用いることなく有利に使用できる。したがって、前述の記載は単に本発明の実施形態の原理および教示を説明するものに過ぎず、これを限定するものではない。
【図面の簡単な説明】
【００５５】
【図１】CDMAベースのDMネットワーク・アーキテクチャの簡略ブロック図である。
【図２】IOTA−DMのエンドツーエンド・アーキテクチャを示す図である。
【図３】非IP DMメッセージの例、この場合制限されない例であるIS−683DMメッセージを適用させるためのメッセージ・フローを示す図である。
【図４】図3の例による、エンドツーエンドのメッセージ・フォーマットの表現を示す図である。
【特許請求の範囲】
【請求項１】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、
非IPエンティティからメッセージを受信すること；
メッセージおよびコンテンツ表現にマークアップ言語を使用することであって、ここで、メッセージの中で非IPプロトコル・コンテンツが、コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別されること；および
前記メッセージを前記「Meta」要素と共に送ること
を含む方法。
【請求項２】
前記マークアップ言語の使用は、前記Meta要素を使用することによってマークアップ言語メッセージの中に受信されたコンテンツをカプセル化することを含む、請求項1に記載の方法。
【請求項３】
前記非IPエンティティから受信された前記メッセージが、IS−683プロトコルの異なるバージョンを含む該IS−683メッセージを含む、請求項1に記載の方法。
【請求項４】
前記マークアップ言語メッセージが、少なくとも1つのURIおよび1つ以上のコマンドをからなるメタコンテンツの前記処理のための追加情報を含み、少なくとも1つのコマンドが、前記メタコンテンツを扱うための前記マークアップ言語メッセージの前記レシーバにおいてプロセスを呼び出す、請求項1に記載の方法。
【請求項５】
メタデータがフォーマット要素によって指定されたフォーマットによりエンコードされる、請求項1に記載の方法。
【請求項６】
前記フォーマットがbase64（b64）エンコードされたものである、請求項5に記載の方法。
【請求項７】
前記非IPエンティティから受信された前記メッセージがNokia−Ericsson OTAメッセージを含む、請求項1に記載の方法。
【請求項８】
前記マークアップ言語メッセージがSyncML DMメッセージを含む、請求項1に記載の方法。
【請求項９】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項1に記載の方法。
【請求項１０】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項1に記載の方法。
【請求項１１】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードであって、
非IPプロトコル・コンテンツを含むメッセージを受信するレシーバと、
マークアップ言語メッセージの受け取り対象となり得るレシーバに非IPプロトコル・コンテンツとして識別される該非IPプロトコル・コンテンツを、メタコンテンツ・タイプを「非IPプロトコル名」として記述する「Meta」要素を用いて前記マークアップ言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現用のマークアップ言語と共に動作可能なプロセッサと、
前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対し無線ネットワークを介して送信するトランスミッタと
を具備する、ネットワーク・ノード。
【請求項１２】
前記受信されたメッセージがIS−683プロトコル・メッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項１３】
前記マークアップ言語メッセージが、前記メタコンテンツの処理に関する追加情報を含む、請求項11に記載のネットワーク・ノード。
【請求項１４】
前記追加情報がURIを含む、請求項13に記載のネットワーク・ノード。
【請求項１５】
前記追加情報が、前記マークアップ言語メッセージの前記レシーバにおいて前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項13に記載のネットワーク・ノード。
【請求項１６】
前記メタコンテンツがbase64（b64）エンコードされたものである、請求項11に記載のネットワーク・ノード。
【請求項１７】
前記メタコンテンツのエンコーディングが、前記マークアップ言語メッセージの一部を含む「Format」要素によって指定される、請求項11に記載のネットワーク・ノード。
【請求項１８】
前記受信されたメッセージがNokia−Ericsson OTAメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項１９】
前記マークアップ言語がメッセージSyncML DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２０】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２１】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２２】
非IPクライアントと、
エンドツーエンドIPプロトコルを使用して、非IPプロトコル・オーバーザエア（Over−the−Air：OTA）コンテンツ・メッセージを含むマークアップ言語メッセージを受信するレシーバと、
メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素の存在に応じて、前記受信されたマークアップ言語メッセージからの非IPベースのコンテンツ・メッセージを抽出するように、メッセージおよびコンテンツ表現のためのマークアップ言語と共に動作可能なプロセッサと
を含む、移動局。
【請求項２３】
前記プロセッサに接続され、非IPプロトコル・コンテンツ応答メッセージを含むマークアップ言語メッセージを該非IPプロトコル・コンテンツ・メッセージの発信元に対して送信する、トランスミッタをさらに含む、請求項22に記載の移動局。
【請求項２４】
前記プロセッサが、さらに、前記抽出された非IPベース・コンテンツ・メッセージを前記非IPクライアントへ向けるよう動作可能であり、前記非IPプロトコル・コンテンツ応答メッセージが該非IPクライアントによって発信される、請求項23に記載の移動局。
【請求項２５】
前記非IPプロトコル・コンテンツ・メッセージが、IS−683プロトコル・メッセージを含む、請求項22に記載の移動局。
【請求項２６】
前記マークアップ言語メッセージが前記メタコンテンツの処理に関する追加情報を含む、請求項22に記載の移動局。
【請求項２７】
前記追加情報がURIを含む、請求項26に記載の移動局。
【請求項２８】
前記追加情報が前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項26に記載の移動局。
【請求項２９】
前記メタコンテンツがbase64（b64）エンコードされたものである、請求項22に記載の移動局。
【請求項３０】
前記メタコンテンツのエンコーディングが、前記マークアップ言語メッセージの一部を含む「Format」要素によって指定される、請求項22に記載の移動局。
【請求項３１】
前記非IPプロトコル・コンテンツ・メッセージが、Nokia−Ericsson OTAメッセージを含む、請求項22に記載の移動局。
【請求項３２】
前記マークアップ言語メッセージがSyncML DMメッセージを含む、請求項22に記載の移動局。
【請求項３３】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項22に記載の移動局。
【請求項３４】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項22に記載の移動局。
【請求項３５】
ネットワーク・ノードの一部を含むコンピュータが、以下の動作：非IPプロトコル・コンテンツを含むメッセージを受信すること；メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素を用い、マークアップ言語メッセージの受け取り対象となり得るレシーバに非IPプロトコル・コンテンツとして識別される前記非IPプロトコル・コンテンツを該マークアップ言語メッセージの中にカプセル化すること；および前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対して送信すること；を行なうことによって、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うための、コンピュータ・プログラム命令を格納するコンピュータ可読データ記憶媒体。
【請求項３６】
以下の動作：エンドツーエンドIPプロトコルを使用して、非IPプロトコル・オーバーザエア（Over−the−Air：OTA）コンテンツ・メッセージを含むマークアップ言語メッセージを受信すること；およびメタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素の存在に応じて、前記受信されたマークアップ言語メッセージから前記非IPベース・コンテンツ・メッセージを抽出すること、を非IPクライアントを有する移動局の一部を含むコンピュータに行なわせるコンピュータ・プログラム命令を格納するコンピュータ可読データ記憶媒体。
【請求項３７】
カプセル化された非IPプロトコル・コンテンツ応答メッセージを含むマークアップ言語メッセージを前記非IPプロトコル・コンテンツ・メッセージの発信元に対して送信する動作をさらに含む、請求項36に記載のコンピュータ可読データ記憶媒体。
【請求項３８】
前記抽出された非IPベース・コンテンツ・メッセージを前記非IPクライアントに向ける動作をさらに含み、前記非IPプロトコル・コンテンツ応答メッセージが前記非IPクライアントによって発信される、請求項37に記載のコンピュータ可読データ記憶媒体。
【請求項３９】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードであって、
非IPプロトコル・コンテンツを含むメッセージを受信するためのレシーバ手段であって、マークアップ言語メッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される該非IPプロトコル・コンテンツを、メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素を用いて前記マークアップ言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現のためのマークアップ言語によって動作可能なデータ・プロセッサ手段に接続されているレシーバ手段と、
前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対し無線ネットワークを介して送信するために、前記データ・プロセッサ手段に接続されているトランスミッタ手段と
を具備する、ネットワーク・ノード。
【請求項４０】
前記受信されたメッセージがIS−683プロトコル・メッセージを含む、請求項39に記載のネットワーク・ノード。
【請求項４１】
前記マークアップ言語メッセージが、前記メタコンテンツの処理に関する追加情報を含む、請求項39に記載のネットワーク・ノード。
【請求項４２】
前記追加情報が、少なくとも1つのURI、および前記マークアップ言語メッセージの前記レシーバにおいて前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項41に記載のネットワーク・ノード。
【請求項４３】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、
非IPエンティティからメッセージを受信するステップと、
メッセージおよびコンテンツ表現にマークアップ言語を使用するステップであって、メッセージの中で非IPプロトコル・コンテンツが、前記コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別されるステップと、
前記メッセージを前記「Meta」要素と共に送るステップと
を含む方法。
【請求項４４】
前記メッセージを受信する前記ステップがIS−683プロトコル・メッセージを受信する、請求項43に記載の方法。
【請求項４５】
マークアップ言語を使用する前記ステップが、前記メタコンテンツの処理に関する前記メッセージからの追加情報を使用する段階を含む、請求項43に記載の方法。
【請求項４６】
前記追加情報を使用する段階が、少なくとも1つのURI、および前記マークアップ言語メッセージの前記レシーバの中において前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを使用する段階を含む、請求項45に記載の方法。
【請求項１】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、
非IPエンティティからメッセージを受信すること；
メッセージおよびコンテンツ表現にマークアップ言語を使用することであって、ここで、メッセージの中で非IPプロトコル・コンテンツが、コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別されること；および
前記メッセージを前記「Meta」要素と共に送ること
を含む方法。
【請求項２】
前記マークアップ言語の使用は、前記Meta要素を使用することによってマークアップ言語メッセージの中に受信されたコンテンツをカプセル化することを含む、請求項1に記載の方法。
【請求項３】
前記非IPエンティティから受信された前記メッセージが、IS−683プロトコルの異なるバージョンを含む該IS−683メッセージを含む、請求項1に記載の方法。
【請求項４】
前記マークアップ言語メッセージが、少なくとも1つのURIおよび1つ以上のコマンドをからなるメタコンテンツの前記処理のための追加情報を含み、少なくとも1つのコマンドが、前記メタコンテンツを扱うための前記マークアップ言語メッセージの前記レシーバにおいてプロセスを呼び出す、請求項1に記載の方法。
【請求項５】
メタデータがフォーマット要素によって指定されたフォーマットによりエンコードされる、請求項1に記載の方法。
【請求項６】
前記フォーマットがbase64（b64）エンコードされたものである、請求項5に記載の方法。
【請求項７】
前記非IPエンティティから受信された前記メッセージがNokia−Ericsson OTAメッセージを含む、請求項1に記載の方法。
【請求項８】
前記マークアップ言語メッセージがSyncML DMメッセージを含む、請求項1に記載の方法。
【請求項９】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項1に記載の方法。
【請求項１０】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項1に記載の方法。
【請求項１１】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードであって、
非IPプロトコル・コンテンツを含むメッセージを受信するレシーバと、
マークアップ言語メッセージの受け取り対象となり得るレシーバに非IPプロトコル・コンテンツとして識別される該非IPプロトコル・コンテンツを、メタコンテンツ・タイプを「非IPプロトコル名」として記述する「Meta」要素を用いて前記マークアップ言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現用のマークアップ言語と共に動作可能なプロセッサと、
前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対し無線ネットワークを介して送信するトランスミッタと
を具備する、ネットワーク・ノード。
【請求項１２】
前記受信されたメッセージがIS−683プロトコル・メッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項１３】
前記マークアップ言語メッセージが、前記メタコンテンツの処理に関する追加情報を含む、請求項11に記載のネットワーク・ノード。
【請求項１４】
前記追加情報がURIを含む、請求項13に記載のネットワーク・ノード。
【請求項１５】
前記追加情報が、前記マークアップ言語メッセージの前記レシーバにおいて前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項13に記載のネットワーク・ノード。
【請求項１６】
前記メタコンテンツがbase64（b64）エンコードされたものである、請求項11に記載のネットワーク・ノード。
【請求項１７】
前記メタコンテンツのエンコーディングが、前記マークアップ言語メッセージの一部を含む「Format」要素によって指定される、請求項11に記載のネットワーク・ノード。
【請求項１８】
前記受信されたメッセージがNokia−Ericsson OTAメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項１９】
前記マークアップ言語がメッセージSyncML DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２０】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２１】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項11に記載のネットワーク・ノード。
【請求項２２】
非IPクライアントと、
エンドツーエンドIPプロトコルを使用して、非IPプロトコル・オーバーザエア（Over−the−Air：OTA）コンテンツ・メッセージを含むマークアップ言語メッセージを受信するレシーバと、
メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素の存在に応じて、前記受信されたマークアップ言語メッセージからの非IPベースのコンテンツ・メッセージを抽出するように、メッセージおよびコンテンツ表現のためのマークアップ言語と共に動作可能なプロセッサと
を含む、移動局。
【請求項２３】
前記プロセッサに接続され、非IPプロトコル・コンテンツ応答メッセージを含むマークアップ言語メッセージを該非IPプロトコル・コンテンツ・メッセージの発信元に対して送信する、トランスミッタをさらに含む、請求項22に記載の移動局。
【請求項２４】
前記プロセッサが、さらに、前記抽出された非IPベース・コンテンツ・メッセージを前記非IPクライアントへ向けるよう動作可能であり、前記非IPプロトコル・コンテンツ応答メッセージが該非IPクライアントによって発信される、請求項23に記載の移動局。
【請求項２５】
前記非IPプロトコル・コンテンツ・メッセージが、IS−683プロトコル・メッセージを含む、請求項22に記載の移動局。
【請求項２６】
前記マークアップ言語メッセージが前記メタコンテンツの処理に関する追加情報を含む、請求項22に記載の移動局。
【請求項２７】
前記追加情報がURIを含む、請求項26に記載の移動局。
【請求項２８】
前記追加情報が前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項26に記載の移動局。
【請求項２９】
前記メタコンテンツがbase64（b64）エンコードされたものである、請求項22に記載の移動局。
【請求項３０】
前記メタコンテンツのエンコーディングが、前記マークアップ言語メッセージの一部を含む「Format」要素によって指定される、請求項22に記載の移動局。
【請求項３１】
前記非IPプロトコル・コンテンツ・メッセージが、Nokia−Ericsson OTAメッセージを含む、請求項22に記載の移動局。
【請求項３２】
前記マークアップ言語メッセージがSyncML DMメッセージを含む、請求項22に記載の移動局。
【請求項３３】
前記マークアップ言語メッセージがOMA DMメッセージを含む、請求項22に記載の移動局。
【請求項３４】
マークアップ言語プロトコルが3GPP2 IOTA−DMメッセージを含む、請求項22に記載の移動局。
【請求項３５】
ネットワーク・ノードの一部を含むコンピュータが、以下の動作：非IPプロトコル・コンテンツを含むメッセージを受信すること；メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素を用い、マークアップ言語メッセージの受け取り対象となり得るレシーバに非IPプロトコル・コンテンツとして識別される前記非IPプロトコル・コンテンツを該マークアップ言語メッセージの中にカプセル化すること；および前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対して送信すること；を行なうことによって、エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うための、コンピュータ・プログラム命令を格納するコンピュータ可読データ記憶媒体。
【請求項３６】
以下の動作：エンドツーエンドIPプロトコルを使用して、非IPプロトコル・オーバーザエア（Over−the−Air：OTA）コンテンツ・メッセージを含むマークアップ言語メッセージを受信すること；およびメタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素の存在に応じて、前記受信されたマークアップ言語メッセージから前記非IPベース・コンテンツ・メッセージを抽出すること、を非IPクライアントを有する移動局の一部を含むコンピュータに行なわせるコンピュータ・プログラム命令を格納するコンピュータ可読データ記憶媒体。
【請求項３７】
カプセル化された非IPプロトコル・コンテンツ応答メッセージを含むマークアップ言語メッセージを前記非IPプロトコル・コンテンツ・メッセージの発信元に対して送信する動作をさらに含む、請求項36に記載のコンピュータ可読データ記憶媒体。
【請求項３８】
前記抽出された非IPベース・コンテンツ・メッセージを前記非IPクライアントに向ける動作をさらに含み、前記非IPプロトコル・コンテンツ応答メッセージが前記非IPクライアントによって発信される、請求項37に記載のコンピュータ可読データ記憶媒体。
【請求項３９】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱うよう動作可能なネットワーク・ノードであって、
非IPプロトコル・コンテンツを含むメッセージを受信するためのレシーバ手段であって、マークアップ言語メッセージの受け取り対象となり得るレシーバにその非IPプロトコル・コンテンツとして識別される該非IPプロトコル・コンテンツを、メタコンテンツ・タイプを「非IPプロトコル名」として記述するマークアップ言語の「Meta」要素を用いて前記マークアップ言語メッセージの中にカプセル化するように、メッセージおよびコンテンツ表現のためのマークアップ言語によって動作可能なデータ・プロセッサ手段に接続されているレシーバ手段と、
前記非IPプロトコル・コンテンツを含む前記マークアップ言語メッセージを受信側に対し無線ネットワークを介して送信するために、前記データ・プロセッサ手段に接続されているトランスミッタ手段と
を具備する、ネットワーク・ノード。
【請求項４０】
前記受信されたメッセージがIS−683プロトコル・メッセージを含む、請求項39に記載のネットワーク・ノード。
【請求項４１】
前記マークアップ言語メッセージが、前記メタコンテンツの処理に関する追加情報を含む、請求項39に記載のネットワーク・ノード。
【請求項４２】
前記追加情報が、少なくとも1つのURI、および前記マークアップ言語メッセージの前記レシーバにおいて前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを含む、請求項41に記載のネットワーク・ノード。
【請求項４３】
エンドツーエンドIPプロトコルを使用して、非IPオーバーザエア（Over−the−Air：OTA）プロトコルを取り扱う方法であって、
非IPエンティティからメッセージを受信するステップと、
メッセージおよびコンテンツ表現にマークアップ言語を使用するステップであって、メッセージの中で非IPプロトコル・コンテンツが、前記コンテンツタイプを「非IPプロトコル名」として記述する「Meta」要素を用いて識別されるステップと、
前記メッセージを前記「Meta」要素と共に送るステップと
を含む方法。
【請求項４４】
前記メッセージを受信する前記ステップがIS−683プロトコル・メッセージを受信する、請求項43に記載の方法。
【請求項４５】
マークアップ言語を使用する前記ステップが、前記メタコンテンツの処理に関する前記メッセージからの追加情報を使用する段階を含む、請求項43に記載の方法。
【請求項４６】
前記追加情報を使用する段階が、少なくとも1つのURI、および前記マークアップ言語メッセージの前記レシーバの中において前記メタコンテンツを扱うためのプロセスを呼び出す少なくとも1つのコマンドを使用する段階を含む、請求項45に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００８−５１４０７９（Ｐ２００８−５１４０７９Ａ）
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００７−５３１８５０（Ｐ２００７−５３１８５０）
【出願日】平成１７年５月３１日（２００５．５．３１）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１５２８
【国際公開番号】ＷＯ２００６／０３０２６１
【国際公開日】平成１８年３月２３日（２００６．３．２３）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１７年５月３１日（２００５．５．３１）
【国際出願番号】ＰＣＴ／ＩＢ２００５／００１５２８
【国際公開番号】ＷＯ２００６／０３０２６１
【国際公開日】平成１８年３月２３日（２００６．３．２３）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]