(57)【要約】  異なる実行環境にわたるアプリケーションサービス交換の方法には、第１の実行環境で動作するサーバアプリケーションから、サービスを取り扱うための登録を受信することと、第２の実行環境で動作するクライアントアプリケーションからサービス要求を受信することと、サーバアプリケーションにサービスを要求することと、要求ステップに応じてサーバアプリケーションから結果を受信することと、その結果をクライアントアプリケーションに送出することと、が含まれる。この要約は、サーチャーまたは他の読者が技術的開示の主題を迅速に確認できるようにする要約を要求する規則に従って提供される。この要約は、それが請求項の範囲または意味を解釈または限定するために用いられることはないという認識で提出される。
2007515720.tif 000002
【特許請求の範囲】
【請求項１】
異なる実行環境にわたるアプリケーションサービス交換の方法であって、
第１の実行環境で動作するサーバアプリケーションから、サービスを取り扱うための登録を受信することと、
第２の実行環境で動作するクライアントアプリケーションから前記サービスの要求を受信することと、
前記サーバアプリケーションに前記サービスを要求することと、
前記要求ステップに応じて前記サーバアプリケーションから結果を受信することと、
前記結果を前記クライアントアプリケーションに送出することと、
を含む方法。
【請求項２】
前記ステップが、モバイル機器のプラットフォーム内で実行される、請求項１に記載の方法。
【請求項３】
前記ステップが、前記モバイル機器の前記プラットフォームのプラットフォームサービス管理サポート部によって実行される、請求項２に記載の方法。
【請求項４】
前記クライアントアプリケーションが、前記サーバアプリケーションまたは前記第１の実行環境の位置を知らない、請求項１に記載の方法。
【請求項５】
前記サーバアプリケーションが、前記クライアントアプリケーションまたは前記第２の実行環境の位置を知らない、請求項４に記載の方法。
【請求項６】
前記サービスが、実行環境に中立な方法で指定される、請求項１に記載の方法。
【請求項７】
前記サービスが、文字ストリングを用いて表現される、請求項６に記載の方法。
【請求項８】
前記サービスが、プラットフォームサービス管理サポート部特有の表現によって表現される、請求項１に記載の方法。
【請求項９】
前記登録を受信する前記ステップが、前記プラットフォームサービス管理サポート部の登録部によって実行される、請求項３に記載の方法。
【請求項１０】
前記サービスの前記要求を受信し、前記サービスを要求し、前記結果を受信し、かつ前記結果を送出する前記ステップが、前記プラットフォームサービス管理サポート部のサービスブローカ部によって実行される、請求項３に記載の方法。
【請求項１１】
前記ステップが、モバイル機器のプラットフォームサービス管理サポート部によって実行される、請求項１に記載の方法。
【請求項１２】
前記プラットフォームサービス管理サポート部が、前記モバイル機器のプラットフォームの一部である、請求項１１に記載の方法。
【請求項１３】
前記プラットフォームサービス管理サポート部が、前記モバイル機器のプラグインで実装される、請求項１１に記載の方法。
【請求項１４】
前記プラットフォームサービス管理サポート部が、
前記モバイル機器のプラットフォームの一部として実装される登録部と、
前記モバイル機器のプラグインで実装されるサービスブローカ部と、
を含む、請求項１１に記載の方法。
【請求項１５】
前記クライアントアプリケーションが、少なくとも１つのサービスを指定することと、
前記サーバアプリケーションが、前記クライアントアプリケーションによって指定された前記サービスを前記サーバアプリケーションが取り扱うことができるかどうかを決定することと、
をさらに含む、請求項１に記載の方法。
【請求項１６】
前記サーバアプリケーションが、少なくとも１つのサービスを指定することと、
前記クライアントアプリケーションが、前記サーバアプリケーションによって指定された前記少なくとも１つのサービスが前記クライアントアプリケーションサービス要求に一致するかどうかを決定することと、
をさらに含む、請求項１に記載の方法。
【請求項１７】
異なる実行環境にわたるアプリケーションサービス交換のためのシステムであって、前記システムが、
第１の実行環境と、
前記第１の実行環境において実行されるように構成されたサーバアプリケーションと、
第２の実行環境と、
前記第２の実行環境において実行されるように構成されたクライアントアプリケーションと、
プラットフォームサービス管理サポート部と、
を含み、
前記プラットフォームサービス管理サポート部が、
前記クライアントアプリケーションによる、前記サービスの要求を受信し、
前記サーバアプリケーションに前記サービスを要求し、
前記要求に応答した結果を前記クライアントアプリケーションに送出するように構成されている、システム。
【請求項１８】
前記プラットフォームサービス管理サポート部が、
前記サーバアプリケーションによる、前記サービスを取り扱うための登録を受信し、
前記要求ステップに応じて前記サーバアプリケーションから結果を受信するようにさらに構成された、請求項１７に記載のシステム。
【請求項１９】
前記プラットフォームサービス管理サポート部が、プラットフォームの一部として実装される、請求項１７に記載のシステム。
【請求項２０】
前記プラットフォームサービス管理サポート部が、プラグインで実装される、請求項１７に記載のシステム。
【請求項２１】
前記プラットフォームサービス管理サポート部が、
前記プラットフォームの一部として実装される登録部と、
プラグインで実装されるサービスブローカ部と、
を含む、請求項１７に記載のシステム。
【請求項２２】
前記クライアントアプリケーションが、前記サーバアプリケーションまたは前記第１の実行環境の位置を知らない、請求項１７に記載のシステム。
【請求項２３】
前記サーバアプリケーションが、前記クライアントアプリケーションまたは前記第２の実行環境の位置を知らない、請求項２２に記載のシステム。
【請求項２４】
前記サービスが、実行環境に中立な方法で指定される、請求項１７に記載のシステム。
【請求項２５】
前記サービスが、文字ストリングを用いて表現される、請求項２４に記載のシステム。
【請求項２６】
前記サービスが、プラットフォームサービス管理サポート部特有の表現によって表現される、請求項１７に記載のシステム。
【請求項２７】
前記プラットフォームサービス管理サポート部が、
登録部と、
サービスブローカ部と、
を含む、請求項１７に記載のシステム。
【請求項２８】
前記クライアントアプリケーションが、少なくとも１つのサービスを指定するように構成され、前記サーバアプリケーションが、前記クライアントアプリケーションによって指定された前記サービスを前記サーバアプリケーションが取り扱うことができるかどうかを決定するように構成された、請求項１７に記載のシステム。
【請求項２９】
前記サーバアプリケーションが、少なくとも１つのサービスを指定するように構成され、前記クライアントアプリケーションが、前記サーバアプリケーションによって指定された前記少なくとも１つのサービスが前記クライアントアプリケーションサービス要求に一致するかどうかを決定するように構成された、請求項１７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野
本発明は、一般に、異なる実行環境におけるアプリケーション間の通信、特に、異なる実行環境にわたるアプリケーションサービス交換（application service exchange）に関する。
【背景技術】
【０００２】
関連技術の背景
多くの組み込み型システムにおいて、全てのアプリケーションは、同じネイティブ実行環境において実行される。実行環境によって、サービスがどのようにアクセスされ利用されるか、イベントがどのように受信されるか、メモリなどの共用資源がどのように用いられるか、オペレーティングシステムがどのように動作し、用いられるか、システムでの実行における並列性がどのように達成されるか、ならびに起動および停止の点でアプリケーションがどのように制御されるか、に関して、アプリケーションの可能性および制約が定義される。換言すれば、実行環境が、アプリケーションの実行およびインストールの可能性および制約を定義する。全てのアプリケーションに対して同じ実行環境を利用することは、全てのアプリケーションのための規則がシステム全体にわたって同じであり、かつ実行環境の仕様が単一の組織によって制御されることを含意する。
【０００３】
しかしながら、モバイル機器では、モバイル機器のネイティブ実行環境と並列に存在する追加実行環境（たとえば非ネイティブ実行環境のＪＡＶＡ（登録商標））が導入されている。さらに、多くのモバイル機器プラットフォームの顧客が、独自仕様の実行環境を有し、これらの実行環境が、レガシーアプリケーションにおける顧客の投資を保護するために、モバイル機器プラットフォームに移植される。
【０００４】
ＪＡＶＡ（登録商標）などの標準化された実行環境は、たとえばＪＡＶＡ（登録商標）仕様リクエスト（ＪＳＲ）仕様書を介して、標準化された実行環境と共存する他の実行環境に要件を課す可能性がある。たとえば、ＪＳＲ７５は、ＪＡＶＡ（登録商標）アプリケーションのエンドユーザが電話番号を編集する場合に、システム上の既存の電話帳を呼び出して、所望のコンタクトを選択し、次にＪＡＶＡ（登録商標）アプリケーションの編集フィールドへ電話番号をコピーすることができるようにすべきだと述べている。したがって、ＪＡＶＡ（登録商標）実行環境は、ネイティブ実行環境または別の商用／独自仕様の実行環境で実行される可能性のある任意のアプリケーションに、要件を課す。かかるアプリケーションの特定の設計は、たとえばプラットフォームメーカの制御下にないので、これらの要件は、異なる実行環境のアプリケーションが実行環境境界を越えてサービスを交換できるようにする技術を、必要とする。
【発明の開示】
【課題を解決するための手段】
【０００５】
発明の概要
異なる実行環境にわたるアプリケーションサービス交換の方法には、第１の実行環境で動作するサーバアプリケーションから、サービスを取り扱うための登録を受信することと、第２の実行環境で動作するクライアントアプリケーションからサービスの要求を受信することと、サーバアプリケーションにサービスを要求することと、要求ステップに応じてサーバアプリケーションから結果を受信することと、その結果をクライアントアプリケーションに送出することと、が含まれる。
【０００６】
異なる実行環境にわたるアプリケーションサービス交換のためのシステムには、第１の実行環境と、第１の実行環境において実行されるように構成されたサーバアプリケーションと、第２の実行環境と、第２の実行環境において実行されるように構成されたクライアントアプリケーションと、プラットフォームサービス管理サポート部（platform service management support）が含まれる。プラットフォームサービス管理サポート部は、クライアントアプリケーションによるサービス要求を受信し、サーバアプリケーションにサービスを要求し、要求に応答した結果をクライアントアプリケーションに送出するように構成されている。
【０００７】
本発明のより完全な理解は、添付の図面と共に、次の発明の例示的な実施形態の詳細な説明を参照することによって、得られるであろう。
【発明を実施するための最良の形態】
【０００８】
発明の例示的な実施形態の詳細な説明
ここで、本発明の実施形態を、添付の図面に関連してより完全に説明する。しかしながら、本発明は、多くの異なる形態で具体化が可能であり、本明細書に述べる実施形態に限定されるように解釈されるべきでない。本発明は、現に存在する請求項およびそれらの均等物によって限定されるだけと考えるべきである。
【０００９】
本発明の原理によれば、情報は、プラットフォームサービス管理サポート部を用いるサービスレベルにおいて、クライアントとサーバとの間で交換される。たとえば、サーバは、たとえば上述の例における「電話番号提供（ＳｕｐｐｌｙＰｈｏｎｅＮｕｍｂｅｒ）」などの特定のサービスまたはサービスセットを取り扱うことができるものとして、自身を登録する。任意の実行環境におけるクライアントが電話番号を要求し、かつサーバ登録が存在する場合には、要求は、モバイル機器のプラットフォームサービス管理サポート部を介して、サービスの取り扱いのために登録されたサーバへ転送される。サーバがサービスを実行すると、結果は、プラットフォームサービス管理サポート部を介して、クライアントへ転送される。
【００１０】
完全に異なる実行環境におけるクライアントおよびサーバアプリケーション間の接続を、それぞれの実行環境に特有のレベルにおいてではなく、サービスレベルで定義することによって、実行環境境界を越えた情報交換のための包括的な機構が定義可能である。エンドポイント（すなわちクライアントおよびサーバ）は、互いを知る必要がなく、コンパイル時およびリンク時について互いに独立している（compile-time and link-time independent of one another）。エンドポイントは、プラットフォームサービス管理サポート部についての知識を有し、この管理サポート部に対して適合される必要があるだけである。したがって、プラットフォームサービス管理サポート部は、サービスルータの役割をすることが可能である。サーバの観点からすれば、プラットフォームは、単に要求されたサービスセットを公表する。クライアントの観点からすれば、プラットフォームは、潜在的にアクセス可能なサービスセットを公表する。クライアントはサービスを指定してもよく、サーバは、そのようなサービス要求を取り扱うことができるかどうかを決定してもよい。できる場合には、サーバは、そのサービスを取り扱うことができるものとして登録する。
【００１１】
クライアント（たとえばＪＡＶＡ（登録商標）標準化によって表現された例における）は、サービスを指定し、サーバは、そのような要求を取り扱うことができるかどうかを決定する。クライアント指定ソリューションは、ほとんどのクライアント−サーバ設計といくらか異なる。ほとんどのクライアント−サーバ設計では、クライアントは、特定のサーバによるサービス仕様がクライアントの必要を満たすかどうかを決定するためにチェックする。本発明の様々な実施形態による方法は、両方のケースに取り組む。サービスおよびその機能インタフェースがどのように指定され表現されるかに関する２つの例示的なケースは、次のとおりである。
（１）  サービスが、特定の実行環境にも特定のサービス表現にも結び付けられていない方法で指定される。しかしながら、エンドポイント（すなわちクライアントおよびサーバ）は、プラットフォームサービス管理サポート部に適合しなければならない。インプリメンテーションの観点からすれば、不特定サービス表現を達成する１つの方法は、ストリングを用いることであるが、このストリングは、文字コード体系を除けば、サービス表現および実行環境について中立である。この場合に、たとえば「電話番号」および「アドレス」などの概念は、全てのシステムで共通なデータセマンティクス（data semantics）を表わす。
（２）  サービスが、サービスのプラットフォームサービス管理サポート部表現に結び付けられた方法で指定される。換言すれば、エンドポイント（すなわちクライアントおよびサーバ）は、プラットフォームサービス管理サポート部に適合し、かつサービスが、相互に知られたプラットフォームサービス管理サポート部によってどのように表現されるかを知っていなければならない。
【００１２】
プラットフォームサービス管理サポート部には、２つの部分が含まれる。すなわち、（ａ）どのサーバがどのサービスを実行するかの経過を追うサービス登録部、ならびに（ｂ）クライアントおよびサーバ用の接続点の役割をするサービスブローカ部である。プラットフォームサービス管理サポート部によって、サービス要求は、クライアントからサーバへ転送され、サービス結果は、サーバからクライアントへ転送される。
【００１３】
プラットフォームサービス管理サポート部が、システムにおいて、どこに位置し実装されるかに関する例示的な３つのケースを以下で説明する。プラットフォームサービス管理サポート部が位置する場所の選択によって、クライアントまたはサーバがどのようにプラットフォームサービス管理サポート部を用いるかは影響される必要がない。３つの例示的なプラットフォームサービス管理サポート部の位置は、次のとおりである。
（１）  プラットフォームサービス管理サポート部は、プラットフォームに統合される。
（２）  プラットフォームサービス管理サポート部は、プラグインで実装される（implemented in a plug-in）。
プラグインは、「プラグインモデル（Ｔｈｅ  Ｐｌｕｇ−Ｉｎ  Ｍｏｄｅｌ）」なる名称の米国特許出願第１０／６６５，８３４号明細書により詳細に論じられており、この出願は参照によって援用される。
（３）  プラットフォームサービス管理サポート部の登録部は、プラットフォームに統合され、一方で、プラットフォームサービス管理サポート部のサービスブローカ部は、プラグインで実装される。
【００１４】
上に列挙した３つのプラットフォームサービス管理サポート部の位置のケースのそれぞれは、外部視認性、統合化、プロセスおよび会社戦略の決定に関連して、様々な賛否両論を提示する。たとえば、プラットフォームサービス管理サポート部が、上のケース２またはケース３に従って位置する場合には、たとえば、ネイティブサービスを必要とするＪＡＶＡ（登録商標）  ＪＳＲｓの開発は、全体的なプラットフォームの開発と同期性をもたせる必要はない。
【００１５】
ここで図を参照すると、図３は、本発明の実施形態による、異なる実行環境にわたるアプリケーションサービス交換の概要を示す論理ブロック図である。図３は、プラットフォームに位置するプラットフォームサービス管理サポート部を示すが、プラットフォームサービス管理サポート部が、本発明の原理から逸脱せずに、上述の３つのケースのどれに従って位置してもよいことは、当業者には理解されるであろう。図３には、プラットフォーム３０２を含むシステム３００が示されている。プラットフォーム３０２などのプラットフォームが、「モバイル端末用のプラットフォームシステム（Ｐｌａｔｆｏｒｍ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｌｓ）」なる名称の米国特許出願第１０／３５９，８３５号明細書により詳細に論じられており、この出願は参照によって援用される。
【００１６】
プラットフォーム３０２には、プラットフォームサービス管理サポート部３０５が含まれる。また、実行環境３０４、実行環境３０６および実行環境３０８が、システム３００の一部として示されている。例として、実行環境３０４はＪＡＶＡ（登録商標）実行環境、実行環境３０６は顧客レガシー実行環境、および実行環境３０８はプラットフォーム定義の実行環境とすることが可能である。
【００１７】
実行環境３０４内には、クライアントアプリケーション３１０が示されている。サーバアプリケーション３１２が、実行環境３０８内に示されている。様々な他のアプリケーションがまた、実行環境３０４、３０６および３０８のそれぞれの内部に示されている。プラットフォームサービス管理サポート部３０５には、サービスブローカ部３１４およびサービス登録部３１６が含まれる。また、複数のプラットフォームサービス３１８、３２０、３２２および３２４が、プラットフォーム３０２の一部として示されている。矢印３２６および３２８は、一般に、プラットフォームサービス管理サポート部３０５を介した、クライアントアプリケーション３１０とサーバアプリケーション３１２との間の通信を示し、また矢印３２６および３２８は、サービス要求が、クライアントアプリケーション３１０によってプラットフォームサービス管理サポート部３０５へ転送されること、およびサービス要求が、プラットフォームサービス管理サポート部３０５によってサーバアプリケーション３１２へ転送されることを示している。
【００１８】
図１は、クライアント要求と、クライアント要求のときにサーバが既に作動している場合の、サーバによる要求の履行と、を示すメッセージ図（messaging diagram）である。モバイル機器１００には、実行環境１０２、実行環境１０４およびプラットフォーム１０６が含まれる。実行環境１０２には、サーバアプリケーション１０８が含まれる。実行環境１０４には、クライアントアプリケーション１１０が含まれる。プラットフォーム１０６には、プラットフォームサービス管理サポート部１１２が含まれる。
【００１９】
メッセージ１１４において、サーバアプリケーション１０８は、所定のサービスのためのハンドラとして登録するために、プラットフォーム１０６のプラットフォームサービス管理サポート部１１２を用いる。プラットフォームサービス管理サポート部１１２は、この情報を格納する。サービスは、セマンティックに包括的な方法で（in a semantically generic way）指定される。メッセージ１１６において、クライアントアプリケーション１１０は、プラットフォーム１０６のプラットフォームサービス管理サポート部１１２を用いて、サービスを要求する。クライアントアプリケーション１１０は、どのサーバアプリケーションまたは実行環境がサービスを実行するかを知らない。しかしながら、要求されたサービスを実行するサーバアプリケーションのアイデンティティは、プラットフォームサービス管理サポート部１１２によって知られている。プラットフォームサービス管理サポート部１１２は、どのサーバアプリケーションがサービスを実行するかを知っており、メッセージ１１８で、サービス要求を適切なサーバアプリケーション（すなわちサーバアプリケーション１０８）に転送する。
【００２０】
メッセージ１２０で、サーバアプリケーション１０８はサービスを実行し、サービス結果をプラットフォームサービス管理サポート部１１２に送出する。プラットフォームサービス管理サポート部１１２は、クライアントアプリケーション１１０がサービスを要求したことを知っており、メッセージ１２２で、サービス結果をクライアントアプリケーション１１０に送出する。
【００２１】
再び図を参照すると、図２は、クライアント要求と、クライアント要求のときにサーバが作動していない場合の、サーバによるクライアント要求の履行と、を示すメッセージ図である。ステップ２０２において、サーバアプリケーション１０８は、サーバアプリケーション１０８のインストール時に、プラットフォームサービス管理サポート部１１２におけるサービス登録に必要な情報を供給する。プラットフォームサービス管理サポート部１１２は、この情報を格納する。
【００２２】
メッセージ２０３において、クライアントアプリケーション１１０は、プラットフォーム１０６のプラットフォームサービス管理サポート部１１２を用い、サービスを要求する。クライアントアプリケーション１１０は、どのサーバアプリケーションまたは実行環境がサービスを実行するかを知らない。しかしながら、要求されたサービスを実行するサーバアプリケーションのアイデンティティは、プラットフォームサービス管理サポート部１１２によって知られている。プラットフォームサービス管理サポート部１１２は、どのサーバアプリケーションがサービスを実行するか（すなわちサーバアプリケーション１０８）の経過を追う。図２におけるように、サーバアプリケーション１０８がまだ起動されていない場合には、プラットフォームサービス管理サポート部１１２は、ステップ２０４で、サーバアプリケーションを起動する。メッセージ２０６で、プラットフォームサービス管理サポート部１１２は、サービス要求をサーバアプリケーション１０８に転送する。サーバアプリケーション１０８はサービスを実行し、メッセージ２０８で、サービス結果をプラットフォームサービス管理サポート部１１２に送出する。プラットフォームサービス管理サポート部１１２は、どのクライアントアプリケーションがサービスを要求したか（すなわちクライアントアプリケーション１１０）を知っており、メッセージ２１０で、サービス結果をクライアントアプリケーション１１０に送出する。
【００２３】
たとえば、実行環境によって用いられるアプリケーションを起動する特定の方法ゆえに、図２で示されているように、プラットフォームサービス管理サポート部１１２が自動的にサーバアプリケーション１０８を起動することが望ましくないが、しかしやはり、クライアントアプリケーション１１０がサーバアプリケーション１０８のサービスを要求したときに、サーバアプリケーション１０８がオンデマンドで起動するのが望ましい場合には、サーバアプリケーション１０８の実行環境１０２において、ブローカアプリケーションを用いてもよい。ブローカアプリケーションは、同じ実行環境（たとえば実行環境１０２）における様々なサーバアプリケーションのサービスを知っているであろうし、たとえばプラットフォームサービス管理サポート部１１２からの要求に応じて、サーバアプリケーションをオンデマンドで起動することができるであろう。
【００２４】
本発明の様々な実施形態は、基本的に異なる実行環境の相互接続を可能にし、インプリメンテーションの相違を回避し、任意のアプリケーションサーバによって達成できる要求されたサービスの仕様を広げる、組み込み型モバイル機器プラットフォームのためのダイナミックな方法を提供するように、働く。さらに、本発明の様々な実施形態は、任意の実行環境におけるアプリケーション間の通信のために包括的な方法で用いられてもよい。異なる実行環境間のインプリメンテーションの相違は、情報交換の観点から橋渡しをすることが可能である。さらに、クライアントによって要求されるサービスセットは、サーバによって提供されるサービスセットの指定に対立するものとして指定してもよい。実行環境間の情報交換は、表現依存を回避するために、たとえば文字／ストリングを用いて行なってもよい。さらに、サーバおよびクライアントは、互いを知っている必要はない。異なる実行環境における２つのエンドポイント間に、包括的なサービス要求チャネルを確立できる。さらに、本発明の様々な実施形態は、サーバ駆動およびクライアント駆動両方のサービス仕様をサポートする。
【００２５】
前述の説明は、本発明の実施形態についてである。本発明の範囲は、必ずしもこの説明によって限定されるべきでない。その代りに、本発明の範囲は、請求項およびそれらの均等物によって定義される。
【図面の簡単な説明】
【００２６】
【図１】クライアント要求と、クライアント要求のときにサーバが既に作動している場合の、サーバによる要求の履行と、を示すメッセージ図である。
【図２】クライアント要求と、クライアント要求のときにサーバが作動していない場合の、サーバによる要求の履行と、を示すメッセージ図である。
【図３】本発明の実施形態に従う、異なる実行環境にわたるアプリケーションサービス交換の概要を示す論理ブロック図である。
【図１】
2007515720.tif 000003
【図２】
2007515720.tif 000004
【図３】
2007515720.tif 000005
【国際調査報告】
2007515720.tif 000006
2007515720.tif 000007
2007515720.tif 000008