JP2006511100A - プラグイン・ソフトウエアを用いて移動体プラットフォームの機能を拡張するための方法及びシステム - Google Patents

Abstract

無線通信システム用又は他の製品用の移動体端末のプラットフォームの機能を拡張あるいは変更するための方法及びシステム。該システムは、機能を提供するソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、プラットフォーム内において、該少なくとも１つのインタフェースを介して、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有するプラットフォーム・ドメインを含んでいる。該システムはまた、アプリケーション・ソフトウエアと共に使用され、少なくとも１つのインタフェースを介して、プラットフォーム・ドメインのソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するプラグイン・ソフトウエアを含んでいる。

Description

本発明は、概して無線通信に関し、より詳細には、本発明は、基本的機能を変更せずに、無線通信システム用の移動体端末のプラットフォームの機能を拡張及び変更するための方法及びシステムに関する。

高度な構造化能力（configurability）をもたらすプラットフォームは、多くのエンド・ユーザ用の移動体製品の製造者及び他のプラットフォームの顧客にとって魅力的なオプションである。構造化能力は、高いレベルの機能に関して後述する場合に非常に重要である。すなわち、ある種の顧客はそのような機能を望み、そのような機能を自宅で開発するのを好む場合が多いが、他の顧客は彼らの製品にそのような機能を含めることに全く関心が無い場合である。

しかしながら、高度な構造化能力を提供する移動体端末のプラットフォームは、プラットフォームのプロバイダに多くの困難をもたらす。例えば、顧客に彼ら固有の構成に特化したプラットフォームの資料を提供することによって、プロバイダは、そのプラットフォームに追加されるあらゆる高レベルの機能をサポートし、様々な顧客が要求するかも知れない多数の構成をサポートしなければならない。また、プラットフォームの構成の全てが適切に動作することが期待されるわけではないので、プラットフォームのプロバイダが、追加された機能が顧客に望まれるように動作するのを保証するために、特定の構成それぞれをテストすることが必要となる。加えて、多くの場合において、プラットフォームに提供されている他の機能を削除したときに、追加した機能がもはや適切に動作しないように、追加される機能は、プラットフォームに提供されている他の機能に依存し、かつ他の機能に対して論理的従属関係を有しているであろう。

その上、プラットフォームのプロバイダが、そのプラットフォーム独自の情報（proprietary）の詳細事項を維持したいと望むことがよくある。これを達成するためには、プラットフォームのプロバイダは、顧客や他のあらゆる関係者にコードのベースを公開すべきではない。その代わり、顧客がプラットフォームを、定義されたインタフェースと定義された振る舞いとを有する単なる“ブラック・ボックス”と見なすのが好ましい。

しかしながら、高度の構造化能力を有するプラットフォームは、プラットフォーム独自の情報の詳細事項を維持することに関して、困難さをもたらす。例えば、プラットフォームのプロバイダにとって、サード・パーティと高レベルのプラットフォームへのアドオンを開発するよう契約することは、一般的な慣行である。プラットフォームのプロバイダは、プラットフォームと共に供給されるプラットフォーム用のアプリケーションを開発するかもしれない。このような事態の典型的な例は、高レベルのグラフィック・ライブラリとして実現されることが多い、ユーザ・インタフェースの外観及び雰囲気（look and feel）を制御する機能のような、製品に特有の機能に関して生じる。外観及び雰囲気はブランド特有であるので、この機能は製品及びブランド間で異なるであろう。

しかしながら、サード・パーティと高レベルのアドオンを開発するよう契約すると、そのパーティは機能を開発するためにそのプラットフォームのコードのベースへのアクセスを必要とし、プロバイダが独自の情報をサード・パーティに開示することを余儀なくさせるであろう。

加えて、プラットフォームが構成されて顧客に供給された後で、プラットフォームの機能はテストされ、安定化されて固定される。しかしながら、顧客が、供給されたプラットフォームの設計によって除外された、プラットフォームの変更、拡張及び構成に関して付加的要件を持っている場合がある。例えば、プラットフォームを特定の要求に合わせるように、提供されたプラットフォームの様々な部分を変更したい、あるいは供給されたプラットフォームに含まれる機能よりも強力な機能、すなわち、プラットフォームのプロバイダがプラットフォームの領域外だとみなした機能を追加したいと、顧客が望むかもしれない。加えて、基本的プラットフォーム・アセンブリの構成でプラットフォームのプロバイダから提供されるものよりも、より詳細なレベルでのプラットフォームの機能の構成、あるいはエンド・ユーザが支払いに用意する金額に基づいて、プラットフォームに機能を追加又は削除するためのある種の最終段階でのコンフィグレーションの実行を望むかもしれない。

概して、移動体端末及び他の製品用の現在のプラットフォームは、プラットフォームの機能を拡張、削除、あるいは変更可能とするための有効な手順を提供しない。

本発明は、無線通信システム用又は他の製品用の移動体端末のプラットフォームの機能を拡張あるいは変更可能とする、方法及びシステムを提供する。製品用のプラットフォームの機能を拡張及び／又は変更するためのシステムは、機能を提供するソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントの機能へのアクセスを提供する少なくとも１つのインタフェースを有するインタフェース・コンポーネントとを有するプラットフォーム・ドメインを含み、アプリケーション・ドメイン・ソフトウエアが、前記プラットフォーム内において、前記少なくとも１つのインタフェースを介して、インストールされ、ロードされ及び実行されるのを可能とする。該システムはまた、アプリケーション・ソフトウエアによって使用され、少なくとも１つのインタフェースを介して、プラットフォーム・ドメインのソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するプラグイン・ソフトウエアを含んでいる。

製品用のプラットフォームの機能を拡張及び／又は変更するための方法は、機能を提供するソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントへのアクセスを提供する少なくとも１つのインタフェースを有するインタフェース・コンポーネントとを有するプラットフォーム・ドメインを提供することを含み、アプリケーション・ドメイン・ソフトウエアが、前記プラットフォーム内において、前記少なくとも１つのインタフェースを介して、インストールされ、ロードされ及び実行されるのを可能とする。該方法はまた、少なくとも１つのインタフェースを介して、プラットフォーム・ドメインのソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するためにアプリケーション・ソフトウエアと共にプラグイン・ソフトウエアを提供することを含んでいる。

本発明のその他の利点及び特定の詳細事項は、添付の図面と共に以下に記載する詳細な説明から明らかになるであろう。

図１は、本発明の原理を説明するのに役立つ、無線通信システムの移動体端末用のプラットフォーム・システムの概略を示すブロック図である。全体を参照番号１０で示すプラットフォーム・システムは、移動体端末プラットフォーム・アセンブり１２と、移動体端末プラットフォーム・アセンブリ内にロードされ、インストールされ、実行された１つ以上のアプリケーション（すなわち、アプリケーション・ソフトウエア）１４を含んでいる。プラットフォーム・システム１０は、全体を破線１６で示す移動体端末に組み込まれるように構成されている。移動体端末プラットフォーム・アセンブリ１２は、ソフトウエア・サービス・コンポーネント２２、ハードウエア・コンポーネント２４及びインタフェース・コンポーネント２６を含んでいる。ソフトウエア・サービス・コンポーネント２２は、インタフェース・コンポーネント２６を介してユーザに提供されるサービスを供与する、複数のよく構成された機能的ソフトウエアユニットを含んでいる。図１に示した代表的なシステムでは、複数のソフトウエアユニットは、複数の縦（垂直）方向の機能的スタック３０−３８を備えている。

図１に示された代表的システムでは、ハードウエア・コンポーネント２４は、機能的ソフトウエア・スタック３０−３８のそれぞれに関連しており、かつそれらによって制御されるハードウエア・ブロック４０−４８のセットを備えている。インタフェース・コンポーネント２６は、１つ以上のアプリケーション１４を移動体端末プラットフォーム・アセンブリ１２内にロードし、インストールし、実行するためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を少なくとも１つ含み、移動体端末プラットフォーム・アセンブリをそれを使用するアプリケーションから分離させ、かつアプリケーションに様々な他のサービスを提供する、ミドルウエア・サービス・レイヤを備えている。

プラットフォーム・システム１０の移動体端末プラットフォーム・アセンブリ１２は、アプリケーション・ソフトウエア１４（本明細書で使用される“アプリケーション・ソフトウエア”という用語は、ユーザが利用できることを望む可能性がある機能を提供するあらゆるソフトウエアであってよい）から分離させ、完成されまとまったユニットとして、設計され、実現され（アセンブルされ）テストされる。従ってユーザは、彼等自身のアプリケーション・ソフトウエアを開発すること、そうでなければ取得することができ、プラットフォーム・システム１０を完成させるために、後でそのソフトウエアを移動体端末プラットフォーム・アセンブリ１２に追加することができる。そのため移動体端末プラットフォーム・アセンブリ１２は、販売されるかそうでなければ複数の様々なユーザに譲渡され得、その各ユーザは、彼等自身のプラットフォーム・システムに対する特定の要件を満足させるべく、彼等自身のアプリケーション・ソフトウエアをアセンブリにロードし、インストールし、実行することによってプラットフォーム・システム１０を完成させることができる。

図２は、本発明の原理を説明するのに更に役立つ、図１の移動体端末プラットフォーム・アセンブリ１２を展開した一例を概略的に示すブロック図である。図２に示されたように、移動体端末プラットフォーム・アセンブリ１２は、メインＣＰＵ５０内で実行されているソフトウエアによって制御される。メインＣＰＵ５０は、マイクロプロセッサ、マイクロプログラマブルプロセッサ、又はＤＳＰ（デジタル・シグナル・プロセッサ）のようなプロセッサを１つ以上含んでいてもよい。ソフトウエア・コンポーネント２２のソフトウエア・スタック３０〜３８のそれぞれは、各スタックに関連したハードウエア・ユニットを動作させるために、ハードウエア駆動ソフトウエア６０〜６８を含んでいる。移動体端末プラットフォーム・アセンブリ１２及びプラットフォーム・システム１０の更なる詳細事項は、本願と譲渡人が同じ米国特許出願第１０／３５９８３５号明細書に記載されており、該明細書を参照により本明細書に組み込む。

移動体端末プラットフォーム・アセンブリ１２に組み込まれているソフトウエアは、好ましくはソフトウエアの構成が分かりやすくなるような方法で配置され、その結果、ソフトウエアの設計が一層容易となり、アップグレードあるいは修正が一層簡単になる。図３は、本発明の原理を説明するのに更に役立つ、移動体端末プラットフォーム・アセンブリ１２のソフトウエア・アーキテクチャの概略を示すブロック図である。

図３に示されているように、ソフトウエア・サービス・コンポーネント２２は、上記で説明したように、複数の縦の、機能的ソフトウエア・スタックに組織化されているのに加え、ミドルウエア・サービス・レイヤ２６のソフトウエアとソフトウエア・サービス・コンポーネント２２のソフトウエアとが共に、全体が参照番号７０で示される階層化アーキテクチャを画定するように複数の横（水平）のレイヤを画定するようにも配置されており、階層化アーキテクチャ７０において、高いレベルのサービス・レイヤから低いレベルのサービス・レイヤに降順でレイヤが配置されている。

このソフトウエア・アーキテクチャは、縦に区切られた複数のソフトウエア・レイヤを補完する横に区切られた複数の機能的ソフトウエア・ユニットを含む点で、ＩＳＯ／ＯＳＩ（ＩＳＯ開放型システム間相互接続）標準モデルと異なっている。横方向の区切りは、独立したモジュール型（サービス）コンポーネントの生成に大きく寄与している。

階層化アーキテクチャの最も高いレベルのレイヤは、インタフェース・コンポーネント２６の一部であるミドルウエア・サービス・レイヤ２６である。ソフトウエア・サービス・コンポーネント２２のレイヤは、アプリケーション・サービスを提供するアプリケーション・サーバ・レイヤ８０と、プラットフォームに特有のアプリケーションのサービスを提供するプラットフォーム・サービス・レイヤ８２と、セッション・プロトコル及びアプリケーション特有のプロトコルを提供するプラットフォーム・プロトコル・レイヤ８４と、音声アクセス／制御、データ通信転送プロトコル、メッセージ転送プロトコルなどを提供するトランスポート・レイヤ８６と、外部データＩＦアクセス、構造化記憶サービス及び他のローレベル・プラットフォーム・サポート・サービスを提供するデータ・アクセス・レイヤ８８と、論理ドライバ・レイヤ９０と、ハードウエアの依存性をまとめる物理ドライバ・レイヤ９２とを含んでいる。加えて、ソフトウエア・サービス・コンポーネント２２は、プラットフォーム・アセンブリによって要求される汎用的サービスを提供する、基本システムサービス・レイヤ９４を含んでいる。

下側の２つのレイヤ９０及び９２は、ソフトウエアとハードウエアとの間の依存性を分離させるハードウエア・アブストラクション・レイヤ（ＨＡＬ）を構成する。物理ドライバ・レイヤだけがハードウエアの詳細事項（すなわち、ＡＳＩＣハードウエアのどのレジスタが割り当てられるか）と関連している。論理ドライバ・レイヤ９０は、ハードウエアについての論理マッピングを提供する。すなわち、このレイヤは、移動体端末プラットフォーム・アセンブリのハードウエア及びソフトウエアの部品間のブリッジを提供する。

ソフトウエア自体は、図３に明確に示された、モジュール１０２、１０４，１０６などの複数のソフトウエア・モジュールに組織化される。ソフトウエア・サービス・コンポーネント２２において、単一のモジュールは、１つの縦方向の機能的スタック内にだけあり、そのスタック内の１つの横方向レイヤにだけ存在し得る。各レイヤは１つから多数のモジュールを含んでいてもよく、特定のスタック内の特定のレイヤ内の全てのモジュールは、抽象化（abstraction）レベルが同じである。様々なモジュール間の通信は、ソフトウエアのモジュールからモジュールへのアクセスについての基本的規則のセットに従う、ソフトウエア・バックプレーン（ＳｗＢＰ）１１２によって達成される。これらの規則の概略は以下の通りである。

−ソフトウエア・モジュールは、自身のレイヤの下側をインタフェースする全てのレイヤの機能を呼び出してもよい。
−例えば、イベント情報やデータストリームなどを保持するシリアル化されたデータフローの方向についての制限は無い。それらはあらゆる方向に行ける。
−ソフトウエア・モジュールは、モジュールが属するレイヤとは無関係に、自身のレイヤの上側をインタフェースする（ＳｗＢＰ １１２において）レイヤの機能を呼び出すことは決してない。
−ソフトウエア・モジュールは、同じ縦方向スタック内で自身のレイヤをインタフェースするレイヤの機能を呼び出してもよい。
−ソフトウエア・モジュールは、別の縦方向スタック内の同じレイヤ内のソフトウエア・モジュールの機能を呼び出してもよい（この能力は、縦方向スタック内のレイヤの数を制限することを許可される）。

様々なモジュールとＳｗＢＰ １１２内のインタフェースとの間には強い結合は無い。その結果、モジュール及び／又はインタフェースの実現を、インタフェースのクライアントに影響を与えることなく自由に変更できる。これによりプラットフォーム・アセンブリ内の他のモジュールに影響を与えずに、個々のモジュールの追加、削除又は変更が可能となるので、これは重要な能力である。移動体端末プラットフォーム・アセンブリ内でのモジュール間の内部通信を可能とするＳｗＢＰソフトウエアの構造を含む、階層化アーキテクチャの更なる詳細事項は、譲渡人が同じ米国特許出願第１０／３５９９１１号明細書に記載されており、該明細書を参照により本明細書に組み込む。

ミドルウエア・サービス・レイヤ・コンポーネント２６は、移動体端末プラットフォーム・アセンブリ１２内のソフトウエアと、プラットフォーム・アセンブリ内にロードされ、インストールされ、実行されるアプリケーション・ソフトウエアとの間に明確なインタフェースを提供し、加えて、移動体端末プラットフォーム・アセンブリ１２をまとまったものとし、該アセンブリ１２をミドルウエア・サービス・レイヤ・コンポーネントによってアプリケーションから分離させ、アプリケーション１４に様々な他のサービスを提供するよう働く。

図４Ａは、インタフェース・コンポーネント２６のミドルウエア・サービス・レイヤを詳細に示す論理ブロック図である。図４に示されているように、ミドルウエア・サービス・レイヤは、例えば、Java（登録商標）実行（Java（登録商標） ExE）環境ＡＰＩドメイン２０２、オープン・アプリケーション・フレームワーク（ＯＡＦ）ＡＰＩドメイン２０４、オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメイン２０６及びＵＩツールキットＡＰＩドメイン２０８などの非ネイティブ環境を含む複数のＡＰＩドメインを備えている。

ミドルウエア・サービス・レイヤ内のＡＰＩを通じて、移動体端末プラットフォーム・アセンブリ１２は、複数のアプリケーション環境をサポートする。図４Ａの代表的な実施形態では、ミドルウエア・サービス・レイヤは、ネイティブ・アプリケーション（特定のプロセッサ及びその命令セットで動作するようにコンパイルされているアプリケーション）用と、Java（登録商標） Ｊ２ＭＥ ＣＬＤＣ／ＭＩＤＰ（Java（登録商標） 2 マイクロエディション接続制限された機器の構成／移動体情報機器プロファイル：Java（登録商標） 2 Micro Edition Connected Limited Device Configuration/Mobile Information Device Profile）アプリケーションなどの非ネイティブ・アプリケーション用の環境をサポートする。各実行環境はそれ自体の特性を有し、以下に応じて定義される。

−アプリケーションが開発される方法（プログラミング言語のサポート、コンパイル及びリンク）。
−アプリケーションが実行される方法（例えば、インタープリタあるいはネイティブ・コードの実行）。
−提供される機能サービス。
−使用の際の考えられる制限。

多数のアプリケーション環境の代替を提供することで、コスト、使用の容易さ、販売時期、機能セット、サイズ、携帯性などの要求が異なる幅広い製品への対応が容易となる。ＡＰＩドメインそれぞれは複数のソフトウエア・モジュールを含み、様々なドメインの詳細事項は、譲渡人が同じ米国特許出願第１０／３５９７７２号明細書に記載されており、該明細書を参照により本明細書に組み込む。

図４Ｂは、アプリケーション・ドメイン５００及びミドルウエア・ドメイン５０１の実施例を示している。ここではプラグインＡ５１０とプラグインＢ５１２の２つのプラグインが示されており、ミドルウエア・ドメイン５０１のオープン・プラットフォームＡＰＩ５１４を拡張及び／又は変更するために、両方ともアプリケーション・ドメイン５００内にある。プラグインＡ５１０はオープン・プラットフォームＡＰＩ５１４だけに依存していても良いが、プラグインＢ５１２はプラグインＡ５１０並びにオープン・プラットフォームＡＰＩ５１４に依存していても良い。ネイティブ・アプリケーション５０８及び非ネイティブ・アプリケーション５０６の両方は、プラグインＡ５１０、プラグインＢ５１２並びにオープン・プラットフォームＡＰＩ（ＯＰＡ）５１４に依存していても良い。非ネイティブ環境（例えば、Java（登録商標）仮想マシン）の場合、アプリケーション５０６が非ネイティブ環境５０４に依存しているという意味で、アプリケーションの依存性は非直接的である。非ネイティブ環境５０４は、プラグインＡ５１０、プラグインＢ５１２又はオープン・プラットフォームＡＰＩ５１４に依存している。

図５は、本発明の代表的実施形態による、オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメイン２０６の主要なソフトウエア・モジュールを示すブロック図である。図示されたように、ＯＰＡドメイン２０６は５つのモジュール：ネイティブ環境マネージメント（ＮＥＭ）モジュール２３０、ネイティブ・アプリケーション・コア（ＮＡＣ）モジュール２３２、ＯＰＡインタフェース及びハンドラ・モジュール２３４、ミドルウエア・サポート・サービス・モジュール２３６及びＯＰＡインタフェース及びハンドラ・モジュール２３８を含んでいる。

ネイティブ環境マネージメント・モジュール２３０は、プラットフォーム・システム１０内のネイティブ・アプリケーションの制御を受け持つ。ネイティブ・アプリケーションに関する制御コマンドを受け取り、システム内で現在実行中のネイティブ・アプリケーションの情報を把握する。

ネイティブ・アプリケーション・コア・モジュール２３２は、そうでなければアプリケーション自体が処理する必要がある、スレッド化及びメッセージの複雑な処理を管理し引き受ける。ＮＡＣモジュール２３２はまた、メッセージのルーティング／フィルタリング及びメッセージに関連するリソース処理を含む、実行時の複雑な処理からアプリケーションを開放するための、ＯＳの詳細な実施態様を単純化することによってＯＳの独立性を達成するために働く。ネイティブ・アプリケーション・コアの更に別の重要な役割は、アプリケーションの起動及びシャットダウン段階での詳細事項と、メッセージの処理における詳細事項を単純化することである。

ミドルウエア・サポート・サービス・モジュール２３６は、例えば、オブジェクトの管理及びリソースの監視などの、様々なハンドラに共通なあるいは集中化されるべきサービスをＯＰＡドメインに提供する。

ネイティブ拡張プラグイン・モジュール２３８は、プラットフォーム・アセンブリ１２のプロバイダに柔軟な拡張性を提供する。このプラグインは、実際にはエンド・ユーザ機器の製造者又は別の者によって書かれたアプリケーション・ソフトウエア１４に、付加的インタフェース及び付加的サービスを提供することによって、プラットフォーム・アセンブリの機能を拡張する。

図５はプラグインをオープン・プラットフォームＡＰＩ（ＯＰＡ）ドメイン２０６のモジュールとして示す論理的ブロック図であるが、図６は本発明の別の代表的実施形態による、複数のオープン・プラットフォームＡＰＩモジュール２４２、２４４、２４６及び２４８と、プラグイン・モジュール２５０とを有する、オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメイン２４０のより一般的に表す論理的ブロック図である。この論理図では、プラグイン２５０は、オープン・プラットフォームＡＰＩ２４０に組み込まれているようにも示されている。なぜなら、顧客からみると、プラグイン２５０は、プラットフォーム・アセンブリのミドルウエア・サービス・コンポーネント２６０内のオープン・プラットフォームＡＰＩの一部として振る舞い、かつ見えるであろう。しかしながら、現実には、プラグイン２５０はプラットフォーム・アセンブリ１２の最上層にあるアプリケーション・ソフトウエア・ドメイン２７０内で動作するスタンドアロンのエンティティを含んでおり、プラットフォーム・アセンブリによって提供される機能を使用する。このように、実施態様から見ると、図６Ｂの実施態様の図に示されているように、プラグインはぷラットフォー、う・アセンブリの上に位置し、プラットフォーム・アセンブリにアクセスするためにオープン・プラットフォームＡＰＩを使用している。

プラグインは、プラットフォーム・アセンブリによってサポートされるアプリケーション・ソフトウエアの仕組みの全てをサポートし、プラットフォーム・アセンブリ内で定義されるアプリケーション・モデルに従う。換言すれば、プラグインは、オープン・プラットフォームＡＰＩによってエクスポートされた提供されたＯＰＡサービスと同じパラダイムに追随する。これらは以下のものを含むがそれらに限定されない：
・インタフェース及びコンポーネントがどのように定義され動作するかという点についての、コンポーネント・モデル・コンプライアンス。プラグインはコンポーネントとして実現され、定義された機能又は方法に基づいたインタフェースを通じて、最終製品のアプリケーション・ソフトウエアにそのサービスを提供するであろう。
・ネーミングの約束事のコンプライアンス。プラグインはインタフェース方法について、オープン・プラットフォームＡＰＩと同じネーミングの約束事を用いる。また、これらインタフェース方法におけるパラメータ及び定義されるタイプの両方は、オープン・プラットフォームＡＰＩで使用されるネーミングの約束事に従う。
・望まれないイベント処理のコンプライアンス。プラグインは、プラットフォームと同じ方法で生じ得る機能の間違った振る舞いを処理する。そのようなエラーについての情報は、オープン・プラットフォームＡＰＩにおけるのと同じパラダイムに従って、アプリケーション・ソフトウエアに届けられるであろう。
・メッセージ・モデル・コンプライアンス。プラグインは、非同期要求、コールバック、及びフル・メッセージ・モード・サービスからの結果を届けるのに２つのモードをサポートするであろう。
・オブジェクト及びインタフェースに基づいたパラダイム。

上記で述べた最後の前の点に関して、メッセージ・モデル・コンプライアンスは、プラグインの振る舞い及びプラグインがどのように構成されるかについて大きな影響を持っている。特に、プラットフォーム・アセンブリのメッセージ・モデルは、非同期サービス要求の結果及びイベント申し込みの結果を受信する目的で、アプリケーション・ソフトウエアにデュアル・モードを提供する。デュアル・モードは、コールバック機構（コールバック・モード）を介して、あるいはメッセージ・キュー（フル・メッセージ・モード）を介してのいずれかで結果を受け取ったのかを意味する。これはプラットフォーム・アセンブリの顧客用ソフトウエアの開発者がアプリケーションの機能の特性に応じて、様々なメッセージ・モデルに従って様々なアプリケーションを構造化するのに、柔軟性と自由度をもたらす。

アプリケーションはメッセージ・モードを決定し、該モードにおいてアプリケーションは、実行することあるいは実行しないことにより非同期の結果、すなわちリターン文を受信するであろう。アプリケーションが結果をコールバック・モードで受信するよう決定した場合、アプリケーションは非同期サービス要求を完了させた後で実行制御を返す。フル・メッセージ・モードに移行することが決定された場合、アプリケーションはサービス要求の後に実行制御を返さないが、メッセージ・キューをポーリングし、自身でメッセージ処理コードをマニュアルで呼び出す。この解決策の別の利点は、特定の問題あるいはコンテクストにおいて望ましい場合に、実行時のあらゆる時点でコールバック・モードとフル・メッセージ・モードとの間の変更をアプリケーションが実際に行っても良いことである。

プラグイン・モデルはメッセージ・モデルのデュアル・モードに従い、この柔軟性を顧客のアプリケーション・ソフトウエアに気付かせずに提供する。本発明の代表的実施形態によれば、このコンプライアンスを達成するためのシーケンスは、コールバック・モードのシーケンス３１０を概略的に示す図７Ａと、フル・メッセージ・モードのシーケンス３２０を概略的に示す図７Ｂに示されている。シーケンスの図は、オープン・プラットフォームＡＰＩ（ＯＰＡ）３１６、プラグイン（又はユーティリティ）３１４及びサービスを要求しているアプリケーション３１２の間の相互作用を表している。

１．起動時にクライアント・アプリケーションは実行制御をＯＰＡから受信する。ＯＰＡサービスを初期化する（プラットフォーム・アセンブリの機能）のに使用されるのと同じパラダイムに従って、プラグイン・サービスを初期化することもオプションで要求されるかもしれない。プラグイン・インタフェース“ＩＹ”が呼び出されるとき（すなわち、プラグインからのサービスがアプリケーションによって要求された）、プラグインはタスクを実行することを１つ又はいくつかのＯＰＡサービス・インタフェース“ＩＹ”に依頼するであろう。図７Ａ及び７Ｂに示したように、これらサービス要求ステップは、コールバック・モード及びフル・メッセージ・モードの両方で同一である。

２．顧客のアプリケーションがどのように結果を受信するのを好むかに応じて、図７Ａ及ぶ７Ｂに３１８で示されているように、実行制御をＯＰＡに対して返す（コールバック・モード３１０）、あるいはフル・メッセージ・モード３２０を通じてメッセージをポーリングする。

３．プラットフォーム・アセンブリは、プラグインのためにサービス“ＩＸ”が実行されたのを知っており、例えば、３２２に従って方法Handle Message等のプラグイン方法を呼び出すことによって、プラグインに結果を返すであろう。プラグインは、プラットフォーム・アセンブリからの結果を図７Ａに示されたようなメッセージ形式に変換し、このメッセージをこの場合はＯＰＡ３１６で表されているプラットフォーム・アセンブリに返す。アプリケーションがプラグインにコールバック・モードでだけメッセージを受信するのを望むよう指示した場合には、このステップは省略されても良いことに注意されたい。省略された場合には、処理及び結果を届けるのがスピードアップされるであろう。プラットフォーム・アセンブリはアプリケーションが結果を待つメッセージ・モードを知っており、それに応じて結果を返すであろう。アクティブなモードに応じて、以下の少なくとも２つのシナリオが考えられる：
・図７Ａに従ってアプリケーションがコールバック・モード３１０である場合、結果はコールバック方法“ICBY_OnService”で与えられるであろう。この場合、プラグインは結果を処理しフォーマットするので、結果はプロシージャ・コールを用いてスタックを介して返送される。
・図７Ｂに従ってアプリケーションがフル・メッセージ・モード３２０である場合、結果はHandle_Messageステップ３２２内のプラグインによって生成されたメッセージを用いて届けられるであろう。プラグインがメッセージ形式で結果をＯＰＡ３１６に返すとき、次にＯＰＡは制御をGet_Messageからアプリケーションに返し、それにより結果を届ける。

本発明の原理によるプラグイン・モデルによれば、移動体端末プラットフォームの機能の変更に関する上記の問題は解消される。例えば、高いレベルの機能の実現にＯＰＡプラグインを用いることによって、プラットフォームのプロバイダは、同様のより安定したプラットフォームを提供することができ、該プラットフォームは、エンド・ユーザ製品の要求をカバーすると思われる基本的及び／又はデフォルトのプラットフォーム機能を依然として含んでいる。これにより高いレベルの機能の管理が、アプリケーション・ドメイン並びにエンド・ユーザ製品の製造者及び他の顧客に近づく。なぜなら、標準でないアドオン機能が、特定の関連製品に応じて追加や削除が容易なプラグインとして提供されるからである。

加えて、本発明の実施形態によれば、プラットフォームのコードのベースに関連する独自の情報をサード・パーティや他社に開示する必要無しに、サード・パーティの開発者がアドオン機能を１つ又はいくつかのプラグインとして実現することができる。特に、プラグインはアプリケーション・ドメイン・ソフトウエアのエンティティであるので、サード・パーティの開発者はデフォルト／基本的プラットフォームＡＰＩだけを使用することを選択できる。

上記のようにプラグイン技術を活用することにより、プラットフォーム・アセンブリのプロバイダは、コードのベースの制御され専用化された一部分だけ、すなわち、スタンドアロンのプラグインの１つ又はいくつかを顧客に公開することを選択することができる。プロバイダは、例えば、プラグインをソースコードで顧客に提供することを選択しても良く、顧客はプラグインの機能や振る舞いを調整するために、そのプラグインのコードの変更や修正ができる。

高い機能を有する複数のプラグインを供給することにより、エンド・ユーザ製品の製造者や他の物がプラットフォーム・アセンブリの機能を拡張することが容易となる。プラットフォームのプロバイダが、プラットフォーム・アセンブリの提供する基本的機能の一部とは見なされない、プラットフォーム・アセンブリへの製造者に特有の拡張機能を供給することも可能である。

拡張機能を有する複数のプラグインを供給することにより、例えば、様々な製品から生じる様々な要求にプラットフォーム・アセンブリを仕立てるため、あるいはエンド・ユーザ製品を購入時にカスタマイズするために、プラットフォーム・アセンブリの最終段階でのコンフィグレーションを実行することも容易となる。本発明の実施形態によれば、このプラットフォーム・アセンブリを使用することで、エンド・ユーザ製品の製造者が、プラグインのプラットフォームのプロバイダを用いるか、あるいは機能を工場内で開発するかについての決定を遅らせることが容易となるであろう。

上述のように、製品のプラットフォームに高い機能が望まれる場合の１例は、ユーザ・インタフェースの外観及び雰囲気（look and feel）を制御する機能のような、製品に特有の機能に関するものである。進化したユーザ・インタフェースを有する移動体端末及び他の専門的な民生品にとって、ユーザ・インタフェースの外観及び雰囲気は、差別化及び市場における製品の位置付けのために重要なキーであり、そのため、市場での成功のために重要である。従って、移動体端末及び他の製品用のプラットフォームが、製品の外観及び雰囲気を規定するのに多くの自由度を提供するのが望ましい。

ウインドウ化システムのコアを外観及び雰囲気の規定から分離することは、既に証明され広く使用されている概念である。Ｘウインドウ・システムがこれを示し、このタイプのアーキテクチャを用いて、同じウインドウ化システムの最上層に全く異なる外観及び雰囲気のシステムをどのように構成するかについて多くの例がある。一方、所与の実施形態の外観及び雰囲気を変更する能力は限られている。

ＵＩサポートのローレベルではJava（登録商標）ＶＭの移植が従来より行われている。外観及び雰囲気は、高いレベルまでJava（登録商標）でのグラフィカル・オブジェクトの実装によって規定される。ＭＩＤＰ（モバイル情報機器プロファイル）の導入は、グラフィカル・オブジェクトが抽象的レベルでのみ規定される別のアプローチを提案する。外観及び雰囲気は、ＶＭが実行されるその下にあるシステムによって規定される。Java（登録商標）アプリケーションとJava（登録商標）ＶＭの外部で実行される他のアプリケーションとの間で外観及び雰囲気の整合性が達成されれば、同じセットのグラフィカル・オブジェクトが両方で使用できる。これは規定された外観及び雰囲気を有するシステムにとって、複雑ではない。

移動体デバイスにおけるJava（登録商標）ＶＭは、理想的にはＭＩＤＰ仕様に従ったＵＩサポートを提供するために、それが実行されているプラットフォームに依存する。これはJava（登録商標）ＶＭを含む移動体プラットフォームにとっては、ＭＩＤＰサポートもプラットフォームの一部とすべきことを意味する。一方、異なるベンダーからの高度に特徴付けられた民生品のためのプラットフォームにとっては、外観及び雰囲気についてできるだけ高いレベルの制御を提供することが重要である。グラフィカル・オブジェクトの規定の制御によって、最も高いレベルの制御が達成できるのは明らかである。プラットフォームについて、既に記載した手法ではこれら２つの矛盾する要件を満たすことはできない。

しかしながら、本発明の別の代表的実施形態によれば、グラフィカル・オブジェクトのセット及びユーティリティは、オープン・プラットフォームＡＰＩ（ＯＰＡ）内の１つ以上のプラグインとして定義される。１つ以上のプラグインへのインタフェースは、固定する必要がありＭＩＤＰサポートには十分であるが、実装は自由に変更されても良い。

本発明の原理によれば、高レベルのグラフィカル・オブジェクト及びユーティリティの実装は、ネイティブ・アプリケーションとJava（登録商標）等の実行環境との間で共有され得る。同時に、グラフィカル・ユーザ・インタフェースの外観及び振る舞いの、プラットフォームの顧客の制御は非常に高度である。

以上本発明の代表的実施形態について記載したが、本発明はその範囲を逸脱せずに多くの方法で変更できることを理解されたい。例えば、本発明を特定の移動体端末のプラットフォーム・アセンブリに関して主に説明したが、本発明をそのように限定されるのを意図するものではなく、本発明は移動体端末及び他の製品用の他のプラットフォームでも使用され得る。本発明は様々な方法で変更可能であるので、本発明は特許請求の範囲によって規定される程度に限定されるものであると理解されたい。

本発明の原理を説明するのに役立つ、無線通信システムの移動体端末用のプラットフォーム・システムの概略を示すブロック図である。 本発明の原理を説明するのに更に役立つ、図１のプラットフォーム・システムの移動体端末プラットフォーム・アセンブリの概略を示す展開ブロック図である。 本発明の原理を説明するのに更に役立つ、図１及び図２の移動体端末プラットフォーム・アセンブリのソフトウエア・アーキテクチャの概略を示すブロック図である。 図１から３のミドルウエア・サービス・レイヤ・コンポーネントを詳細に示す論理ブロック図である。 図４Ａのブロック図の実施例を示す図である。 オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメインの主要なソフトウエア・モジュールを示すブロック図である。 オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメインの論理的概要を示すブロック図である。 オープン・プラットフォームＡＰＩ（ＯＰＡ）ドメインの実施例の概要を示すブロック図である。 コールバック・モードにおけるメッセージ・モデルへの準拠を達成するための、プラグイン・モデル用のシーケンスを概略的に示す図である。 フル・メッセージ・モードにおけるメッセージ・モデルへの準拠を達成するための、プラグイン・モデル用のシーケンスを概略的に示す図である。

Claims (21)

1. 製品用のプラットフォームの機能を拡張及び／又は変更するためのシステムであって、
   機能を提供するソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントの機能へのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、前記プラットフォーム内において、前記少なくとも１つのインタフェースを介して、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有するプラットフォーム・ドメインと、
   前記アプリケーション・ソフトウエアによって使用され、前記少なくとも１つのインタフェースを介して、前記プラットフォーム・ドメインの前記ソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するプラグイン・ソフトウエアと、を備えることを特徴とするシステム。
2. 前記少なくとも１つのインタフェースが、アプリケーション・プログラミング・インタフェースを含むことを特徴とする請求項１に記載のシステム。
3. 前記プラグイン・ソフトウエアが、前記アプリケーション・ソフトウエアのドメインにあり、前記プラットフォーム・ドメイン及び他のプラグイン・ソフトウエアの少なくとも１つの機能を使用するソフトウエアを含むことを特徴とする請求項１に記載のシステム。
4. 前記プラグイン・ソフトウエアが、前記アプリケーション・プログラミング・インタフェースによって移植された提供されるサービスと同じパラダイムに従うことを特徴とする請求項１又は２に記載のシステム。
5. 前記提供されるサービスが、コンポーネント・モデル・コンプライアンス、ネーミングの約束事のコンプライアンス、望まれないイベント処理のコンプライアンス及びメッセージ・モデル・コンプライアンスの少なくとも１つを含むことを特徴とする請求項４に記載のシステム。
6. 前記メッセージ・モデルが、コールバック・モード及びフル・メッセージ・モードを含むことを特徴とする請求項５に記載のシステム。
7. 前記プラグイン・ソフトウエアが、複数のプラグイン・ソフトウエア・モジュールを含むことを特徴とする請求項１に記載のシステム。
8. 前記プラグイン・ソフトウエアが、前記プラットフォームの外観及び雰囲気を規定するグラフィカル・オブジェクトのセット及びユーティリティを定義するプラグイン・ソフトウエアを含むことを特徴とする請求項１に記載のシステム。
9. 前記プラットフォーム・ドメインが、無線通信システム用の移動体端末のプラットフォームを含むことを特徴とする請求項１に記載のシステム。
10. 製品用のプラットフォームの機能を拡張及び／又は変更するための方法であって、
    機能を提供するソフトウエア・サービス・コンポーネントと、該ソフトウエア・サービス・コンポーネントの機能へのアクセスを提供する少なくとも１つのインタフェースを有し、アプリケーション・ドメイン・ソフトウエアが、前記プラットフォーム内において、前記少なくとも１つのインタフェースを介して、インストールされ、ロードされ及び実行されるのを可能とするインタフェース・コンポーネントとを有するプラットフォーム・ドメインを提供するステップと、
    前記少なくとも１つのインタフェースを介して、前記プラットフォーム・ドメインの前記ソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するために前記アプリケーション・ソフトウエアと一緒にプラグイン・ソフトウエアを提供するステップと、
    前記プラグイン・ソフトウエアを介して、前記ソフトウエア・サービス・コンポーネントの機能を拡張及び／又は変更するステップと、を備えることを特徴とする方法。
11. 前記プラグイン・ソフトウエアが、前記アプリケーション・ソフトウエアのドメインにあり、前記プラットフォーム・ドメインの機能を使用するソフトウエアを含むことを特徴とする請求項１０に記載の方法。
12. 前記少なくとも１つのインタフェースが、アプリケーション・プログラミング・インタフェースを含み、前記プラグイン・ソフトウエアが、前記アプリケーション・プログラミング・インタフェースによって移植された提供されるサービスと同じパラダイムに従うことを特徴とする請求項１０に記載の方法。
13. 前記提供されるサービスが、コンポーネント・モデル・コンプライアンス、ネーミングの約束事のコンプライアンス、望まれないイベント処理のコンプライアンス及びメッセージ・モデル・コンプライアンスの少なくとも１つを含むことを特徴とする請求項１２に記載の方法。
14. 前記メッセージ・モデルが、コールバック・モード及びフル・メッセージ・モードを含み、前記アプリケーション・ドメイン・ソフトウエアが、前記コールバック・モードと前記フル・メッセージ・モードとの間の切り換えを行うように構成されていることを特徴とする請求項１３に記載の方法。
15. 前記プラグイン・ソフトウエアが、前記プラットフォームの外観及び雰囲気を規定するグラフィカル・オブジェクトのセット及びユーティリティを定義するプラグイン・ソフトウエアを含み、前記機能を拡張及び／又は変更するステップが、前記プラットフォームの外観及び雰囲気を変更するステップを含むことを特徴とする請求項１０に記載の方法。
16. 前記機能を拡張及び／又は変更するステップが、前記プラットフォームのプロバイダの顧客によって実行されることを特徴とする請求項１０に記載の方法。
17. 前記顧客が、エンド・ユーザ製品の製造者を含むことを特徴とする請求項１６に記載の方法。
18. 前記機能を拡張及び／又は変更するステップが、前記機能を変更するよう契約したサード・パーティによって実行されることを特徴とする請求項１０に記載の方法。
19. 前記機能を拡張及び／又は変更するステップが、前記プラットフォームの前記ソフトウエア・サービス・コンポーネントに対して機能を追加又は削除するステップを含むことを特徴とする請求項１０に記載の方法。
20. 前記プラットフォーム・ドメインが、無線通信システム用の移動体端末のプラットフォームを含むことを特徴とする請求項１０に記載の方法。
21. 前記機能を拡張及び／又は変更するステップが、アプリケーション及び／又は１つから複数のプラグインをダウンロードすることによって実行されることを特徴とする請求項１０に記載の方法。

Images