JP2008523464A - 特定形式の無線コンピュータ装置用にカスタム化されたソフトウェアアプリケーションを自動的に構築する方法 - Google Patents

Abstract

カスタム化ソフトウェアアプリケーションを、次の（ａ）、（ｂ）、（ｃ）により、特定形式の無線コンピュータ装置用に構築することができる。（ａ）その形式の無線コンピュータ装置の属性を自動的に決定する。（ｂ）ソフトウェア構成部品ライブラリからのその形式の無線コンピュータ装置と適合可能なソフトウェア構成部品を（ａ）で決定された属性の値に基づいて自動的に決定する。（ｃ）その適合可能なソフトウェア構成部品をそのアプリケーションの特注の、その形式の無線コンピュータ装置と適合可能なビルドを生成するために自動的に統合する。属性はメタデータであることが可能である。この手法により、機能豊富なネットワークアプリケーションを広い様々な形式の無線コンピュータ装置に対して自動的に構築することができる。

Description

本発明は、特定形式の無線コンピュータ装置用のカスタム化ソフトウェアアプリケーションを自動的に構築する方法に関する。本発明は、ネットワーク志向の機能豊富なアプリケーションを多数の無線コンピュータ装置に迅速かつ効率的に提供する。

（定義）
本明細書で使用される定義は以下のとおりである。

移動電話機：物理的な電線またはその他の物理的な結線またはケーブル構造を通してではなく、無線技術により空中を通して電話網に接続されるタイプの電話機。

携帯電話機、ハンドセット（Mobile phone、Phone、Mobile、Mobile Handset、Handset）：移動電話機の一タイプ。

移動通信網：移動電話機が、電話機による通話または通信網上のデータまたはサービスへのアクセス等の機能を運用し提供できるよう、移動電話機への無線接続を提供する通信網。

移動通信網事業者（Mobile Network Operator、ＭＮＯ）：移動通信網およびその通信網上で移動電話機を使用する加入者またはユーザを運用する会社または機関。

グローバル移動通信網または携帯電話通信網：世界の移動通信網事業者によって運用される全ての移動通信網の総和。

無線通信網：クライアントコンピュータ装置に無線接続を提供する通信網。無線通信網は、Ｗｉ−Ｆｉ、ＷｉＭＡＸおよびグローバル移動通信網を含む。

サーバ：１つ以上のクライアントコンピュータ装置から接続され、サービス要求に応じてそれらへの情報提供、データベース検索およびトランザクション処理等のネットワーク化されたアプリケーションサービス、フィーチャおよび機能を提供するために存在するネットワーク化されたコンピュータ装置。各サーバには一般に多数のクライアントが存在し、通常各クライアントはサーバより小型でコンピュータ能力が小さい。

サービス：通常、サーバが、通信網に接続された1つ以上のクライアントコンピュータ装置に提供するネットワーク化されたコンピュータサービス、フィーチャおよび機能。サービスは、情報提供、データベース検索およびトランザクション処理を含む。そのようなサービスは、通信網中に集中配備するのがアーキテクチャ上実際的であり、クライアントのコンピュータに配備するのはクライアントの規模や能力から通常非実際的である。

クライアント：通信網志向アプリケーションのフィーチャおよび機能をアプリケーションユーザ即ちコンシューマに配信する通信網に接続されるコンピュータ装置。通常、クライアントはサーバに接続し、サーバに要求する。

通信網アプリケーション：通信網志向型のアプリケーションまたはサービス。エンドユーザ即ちコンシューマへのアプリケーションインタフェース機能を持つクライアント上で実行するソフトウェアの組み合わせによって提供され、クライアントが通信網を介してアクセスするサーバ上のソフトウェアが提供するサービスにより支援され補完される。

無線コンピュータ装置：無線通信網を介して通信網へ接続するタイプのクライアント。そのような装置に、携帯電話機、携帯情報端末（ＰＤＡ）、ゲーム操作盤（例えば、ソニーＰＳＰ）またはその他の無線で通信網に接続されるクライアントコンピュータ装置がある。無線コンピュータ装置のタイプは、その製造業者、型、バージョン、オペレーティングシステム、ファームウェアのバージョンによりさらに規定される。

無線装置または無線クライアント：無線コンピュータ装置の一タイプ。

ソフトウェアアプリケーション：無線コンピュータ装置に無線で配信される、またはそこにプリインストールされた、クライアント・ソフトウェア・アプリケーション。

ソフトウェア構成部品：無線コンピュータ装置用にカスタム化され、装置適応型アーキテクチャ（Device Adaptive Architecture、ＤＡＡ）ソフトウェアライブラリの部分をなすソフトウェアアプリケーションの構成部品を形成するソフトウェアの個々の単位。

携帯コンテンツ：電子的生産物を表現するデジタルファイルおよびデータ。携帯電話機により使用され、そこで消費され、再生され、眺められ、描写される。例として、着信音／着信曲、壁紙／写真、スクリーンセーバ／アニメーション、リアルトーン／トゥルートーン、全曲ダウンロード、ビデオ、ＳＭＳ ＆ ＭＭＳ警報、携帯ゲーム、およびその他多くの現行および今後出現する携帯電話機消費型の娯楽および情報生産物がある。

メタデータ：データまたはデータ集合の個々の項目であり、階層的に関係付けられることもある。無線コンピュータ装置、無線通信網、ソフトウェア構成部品、通信網アプリケーションまたは携帯コンテンツの属性または動作を記述する。

執筆の時点では、世界には携帯電話機がパソコン（ＰＣ）より多く存在している。携帯電話機の性質は、一般的に言って、スイッチがオン状態にあってその所有者の使っている時間がＰＣより長いことである。これらのハンドセットは、世界の広大な携帯通信網にそしてそれを通してインターネットに接続されているならば、ユーザに並々ならぬ数の通信網アプリケーションを配信する何とも抵抗し難いプラットホームを提供する、豊富な機能と高能力なハードウェアを備え、強化の一途にあるコンピュータである。

グローバル移動通信網は、種々雑多なオペレーティングシステムとプラットホームを備えた膨大な数の無線コンピュータ装置が接続され、通信網アプリケーションが配信可能な、最初の通信網の例である。ＰＣが支配的なインターネット網は、クライアント用オペレーティングシステムとプラットホームの変異形が遥かに少ないため、グローバル移動通信網とは大きく異なる。インターネット上のクライアントは極めて強力なコンピュータ装置ではあるが、マイクロソフト社やアップル社等からの少数のオペレーティングシステムが支配的であるため、それらは概ね互いに似通っている。このため、マイクロソフト社のウインドウズまたはそれに次ぐ１つまたは２つの最有力クライアントアーキテクチャ上にでもＰＣインターネット用通信網アプリケーションのクライアント構成部品を構築するならば、同じように動作する通信網アプリケーションが非常に高い割合の既存装置に配備可能となり、したがって技術的に実行可能で商業的に成功しそうな製品を持つことになる。ＰＣインターネットの世界ではさらに、特定のオペレーティングシステムまたはプラットホームを使用する通信網アプリケーションのクライアント部を構築するよう選択すれば、類似のユーザグループを非常に効果的にターゲットにできる。例えば、企業の経理部長用の通信網アプリケーションを構築する場合、マイクロソフト社のウインドウズに適合可能なクライアントソフトウェアを構築すれば、これらの大多数をサポートできることになろう。

グローバル移動通信網ではそうはいかない。ＰＣインターネット上に存在するより遥かに多くの無線クライアント用オペレーティングシステムとプラットホームの変異形が存在する。その結果、また携帯電話機の機能高度化とフィーチャ追加の開発速度が極めて早いこともあって、その振る舞いにアクセスし制御するのに使用されるオペレーティングシステムとプラットホームが変化するよりずっと早く、装置の振る舞いが変化する。これに加え、同じまたは非常に似通った無線装置を使用するユーザグループを、彼らの役割によって識別しターゲットとすることは実現可能ではない。

一般に、通信網アプリケーションが運用できる無線クライアントが多いほど、多くの顧客を対象にできるので、アプリケーションプロバイダにとってそれだけ経済的機会が多くなる。この理由から、そのような通信網アプリケーションのプロバイダにとって、できるだけ多くのクライアントにソフトウェアを配備できることが特別な関心事となる。

通信網アプリケーションとサービスはネットワーク化されたＰＣの世界では一般化しており、インターネットの大きさ、したがって潜在的ユーザ数により、非常に大きいビジネス機会を提供する。アプリケーションのクライアント部を実行するソフトウェアを構造化する方法は今日僅かしかない。それらは以下のものである。

１．「特注（Custom Build）アプリケーション」
通信網アプリケーションのクライアントとして動作可能なエンドユーザコンピュータ装置（ＰＣ等）は一般に、ソフトウェアプログラムが実行可能なプラットホームを提供する。これらプラットホームの代表的なものは、コンピュータのオペレーティングシステム（例えば、マイクロソフトＷｉｎｄｏｗｓ（登録商標）、ＬＩＮＵＸ、ＭａｃＯＳ、ＵＮＩＸ(登録商標）、等）であるか、または、それらオペレーティングシステム上の、ソフトウェアプログラムの実行が可能なプラットホーム層（Ｊａｖａ(登録商標）等）である。特注アプリケーションは、これらプラットホームの１つの上で実行可能なソフトウェアで構築される。アプリケーション中のソフトウェアがプラットホームに要求を出し、これを受けてプラットホームがそのアプリケーションへのサービス（例えば、ウインドウの描画または通信網を介する情報の送信、等）を実行する。

これらのプラットホームは、通常、特注アプリケーションに利用可能な非常に豊かなフィーチャの集合を有しており、実際、コンピュータの全てのフィーチャと利便性を提供するのが普通である。そのため特注アプリケーションは非常に豊富なユーザインタフェースや広範な機能を提供でき、クライアントに可能なことは何でも実行できるのが普通である。そのようなアプリケーションの例は（それほど通信網向きではないが）、よく知られるＷｏｒｄ，Ｅｘｃｅｌ、およびＰｏｗｅｒＰｏｉｎｔ等、マイクロソフトＯｆｆｉｃｅのツール類である。

マイクロソフトＷｉｎｄｏｗｓ（登録商標）等のＰＣプラットホームが支配的であるため、特注アプリケーションを開発してそれを世界のＰＣの多くの上で成功裡に実行することが可能である。しかし、アプリケーションを１つ以上のプラットホーム上で実行する必要があると、そのアプリケーションをそのプラットホームに移植する必要があるか、またはプラットホームが大きく異なるならば、アプリケーションの完全な書き直しが必要になる。アプリケーションの移植や書き直しは非常に大きいコストのかかる技術作業であり、アプリケーションにフィーチャを追加する毎に必要な努力が増大する。

以上を要約すれば、特注アプリケーションは、可能な最も豊かなフィーチャ集合および最良のインタフェースをエンドユーザ経験に供するが、これらのアプリケーションは、１つのプラットホームから別のプラットホームへの移植に伴う技術的困難さのため、比較的少数のプラットホームで利用できるだけである。

この手法の問題は、通信網アプリケーションのクライアント部が新しいクライアントプラットホームに完全に移植されないならば、新しいクライアントプラットホーム上で実行できないことである。この点はＰＣの世界ではうまくいっている。そこでは、アプリケーションを移植する必要が余り無く、いずれにせよ僅かなクライアントプラットホームしか存在せず、新しいクライアントプラットホームは極く僅かである。しかし、これに比べて、グローバル移動通信網では、その無数の現存のオペレーティングシステムと無線装置の形式、および新たに市場参入するクライアント装置のかって無い速さの絶え間ない流れにより、極めて複雑な問題を呈する。

２．「ＷＷＷ（World Wide Web）アプリケーション」
ＷＷＷは元々は通信網ベースの文書間参照および案内システムとして設計されたものであり、ユーザがリンクを辿って１つの文書から、地球の反対側の別コンピュータ上にあるかもしれない別の文書へと閲覧することを可能にする。この技術は、文書を書くのに使用するハイパーテキストマークアップ言語(Hyper-text mark-up language、ＨＴＭＬ)と呼ばれる標準マークアップ言語とＨＴＭＬブラウザとにより、簡明なものとなった。ＨＴＭＬブラウザは、ＨＴＭＬ文書を表示したり、ＨＴＭＬハイパーテキストリンクを使用して文書間を航行可能にする、ユーザクライアント上で実行するソフトウェアアプリケーションである。

ＨＴＭＬブラウザが、殆どのクライアントコンピュータ用に時をおかずに作成されたので、本技術は非常にポピュラになった。これは、ネットワーク化されたユーザ全てが、同一の拡大し続ける世界的広がりをもった情報と文書からなるライブラリに接続されたということである。またそれは、情報を刊行したい人々がその文書をＨＴＭＬで一度マークアップすれば、その文書を世界中のネットワーク化された膨大な数のコンピュータからアクセス可能にできるということである。

時の経過とともに、ユーザはますます多くをこのＷＷＷ技術に要求し、多くのフィーチャが追加された。新しいフィーチャには、表示されたページ中に埋め込まれる少量のソフトウェア（アプレットとスクリプト）を付加する能力が含まれた。そのソフトウェアは、クライアント能力をさらによく活用し、より機能的なアプリケーションを構築できるようにした。その他のフィーチャとして、データ収蔵用の形式、およびサーバ上にあるソフトウェアサービスへの通信網経由による収蔵データの提示、が含まれた。

最終結果として、非常に高能力の通信網アプリケーションがＷＷＷサーバ上に配備可能となり、ブラウザを使用する世界の大部分のクライアントコンピュータがそのアプリケーションにアクセスし運用できるようになった。これは特注アプリケーションの対極を示すものであった。というのは、ＷＷＷアプリケーションを使用しては、特注アプリケーション同様の機能豊富なアプリケーションをクライアント上に構築することはできないが、しかし、異なるプラットホーム毎の移植を必要とせずに、世界のＰＣクライアントコンピュータの大部分の上で実行が可能だからであった。

このタイプのＷＷＷアプリケーションに特有の妥協事項は、ＨＴＭＬブラウザがプラットホームであり、それを通して通信網アプリケーションのクライアント部がクライアント能力にアクセスすることである。ＨＴＭＬブラウザは、しかし、クライアントオペレーティングシステムの著しく僅かな機能と通常極く非力なフィーチャにしかアクセスしない。その結果、ＷＷＷアプリケーションで実行可能なフィーチャの範囲は、特注アプリケーションより数も少なく豊かさの欠けたものとなる。加えて、ＨＴＭＬは全てのＨＴＭＬブラウザによって共通に解釈されるべき標準であるため、ＷＷＷアプリケーションに利用可能なフィーチャは全てのクライアントプラットホームに共通のフィーチャということになる。これは無線移動通信網において、携帯クライアントのフィーチャが非常に急速に発展しているためそれが共通にならないばかりでなく、異なる無線装置間で共通ではない、最新のフィーチャを含むフィーチャを使用する通信網アプリケーションを配備するのが望ましいという、問題を提起する。

ＷＷＷアプリケーションが、より豊かなフィーチャおよびより高度なクライアント特有のアプリケーションコード、例えばマイクロソフトＡｃｔｉｖｅＸまたはＪａｖａ(登録商標）コードの埋め込みによる、を配備できる方法が存在する。これの効果は、アプリケーションが（埋め込みコードの性質に応じて）、ＷＷＷアプリケーションと特注アプリケーションとの、またはＷＷＷアプリケーションと一度作ればどこでも実行可能（Write Once, Run Anywhere）型アプリケーションとの組み合わせになること、およびこれら２つのタイプのアプリケーションの問題点と限界を組み合わせた問題点と限界を持つことである。

３．「一度作ればどこでも実行可能なアプリケーション」
一度作ればどこでも実行可能型アプリケーションは、特注アプリケーションとＷＷＷアプリケーションの世界からの最良のフィーチャを提供することを意図する。名前からわかるように、そのアプリケーションは一度定義されると、同一の一貫した、機能豊かなアプリケーションが多くのプラットホーム上で、アプリケーションを移植する必要も無く実行できる。これは、２つの方法の１つで達成される。

ｉ）「仮想マシーン」
仮想マシーンは、クライアント自身のプラットホーム（オペレーティングシステム等）に乗っかって、一度作ればどこでも実行可能型アプリケーションを実行する中間介在型のソフトウェアプラットホームである。これは、仮想マシーンによってアプリケーションソフトウェアを行単位で読み、命令をクライアントプラットホーム本来の対応する要求へと直ちに翻訳することにより、達成される。

この手法の最終結果は、仮想マシーンが重要なクライアントプラットホームのいずれについても作成されるなら、その仮想マシーンに適合可能な１つのコンピュータプログラムを開発すれば、そのアプリケーションを各クライアントプラットホームへ移植する必要も無く、（より多くのクライアントプラットホームのフィーチャにアクセスできるので）ＷＷＷアプリケーションよりも機能的にはるかに豊富なユーザ経験を創出できるようにできることである。この技術の例は、サンマイクロシステム社のＪａｖａ(登録商標）である。

本手法の問題は、クライアントソフトウェアが何らかの内的複雑性を有すると（例えば、性格が厳密である、ソフトウェアスレッドを利用する、準実時間的なグラフィックスである、またはその他何らかの実時間的特質を有する、等）、異なる複数タイプのクライアントについてアプリケーションが同様の性能を確保することが格段に困難になることである。これが、携帯Ｊａｖａ(登録商標）ゲームが全てのＪａｖａ(登録商標）クライアントでは実行できず、ユーザ経験が同じであることを確保するべくゲーム作成者によって特にテストされた僅かなもののみで実行できる理由である。これが、プログラマたちがしばしば、「一度作ってどこでもデバッグ（Write Once, Debug Anywhere）」と言う所以である。仮想マシーン技術を使用する限りこの問題は決して除去できない。

ii）「疑似コードコンパイラ」
疑似コードコンパイラは、同様の成果を別の方法を使用して達成する。仮想マシーン同様、アプリケーションを表現するソフトウェアは一度だけ書かれ、他のソフトウェアが解釈可能な高水準形式で表現される。しかし、アプリケーションコードをその場で翻訳する仮想マシーンプラットホームを全ての対象クライアントに配備するのではなく、アプリケーションコードがクライアントに送信される前に、コンパイラがアプリケーションを通して読み、クライアントのオペレーティングシステムプラットホーム用の、そこで直接実行可能なアプリケーションを構築（コンパイル）する。

こうして、豊かなフィーチャを持つ１つのアプリケーションを開発できれば、それ用のコンパイラが存在するどのクライアントででもそれが実行可能となる。そのようなシステムの例は、サイベース（Ｓｙｂａｓｅ）社のＰｏｗｅｒＢｕｉｌｄｅｒである。（これは、ちなみに、そのＰ−Ｃｏｄｅ技術を使用して仮想マシーン構造用のバージョンをも提供できる。）
これら両手法の問題は、すべての対象プラットホーム用に書き直されねばならないのが、これらの場合はコンパイラまたはインタープリタであることを除けば、特注アプリケーションの問題と同じである。特注アプリケーション同様、僅かなオペレーティングシステムしか存在しないＰＣの世界では、それは大きい問題ではない。しかし、コンパイラまたはインタープリタを先ず配信できないことにはアプリケーションを配信できない移動通信網の世界では、殆ど乗り越え不可能な障害となる。それは回避不能のどうしようもないジレンマである。

これらの３つの方法を要約すると、ＰＣ通信網アプリケーションは以下により開発できる。

・豊富なフィーチャおよび機能を要求するが、少数タイプのクライアントプラットホームで実行できればよいならば、特注（Custom Build）アプリケーション、または、
・一度だけ定義しどこででも実行したい、しかしユーザ経験は限定されても構わないならば、ＷＷＷアプリケーション、または、
・一度だけ定義し多くのプラットホーム上で実行したいならば、一度作ればどこでも実行可能型アプリケーション。

携帯電話機の世界では、環境は大きく異なる。主要な違いは以下のとおりである。

・遥かに多くの携帯装置が、多くの異なる移動通信網に接続して使用されている。

・遥かに多くの携帯電話機製造業者が存在し、その携帯電話機の各々が複数のクライアントプラットホームを使用することが見込まれ、結果としてアプリケーションの実行が必要なクライアントプラットホームのより多くの変異形が存在する。

・携帯電話機の能力は、ますます多くのフィーチャの追加に伴って非常に急速に変化している。最終結果は、非常によく似たものになり勝ちなＰＣクライアントとは全く異なり、２つの異なる携帯電話機は非常に異なる能力を持ったものとなり得る。

携帯電話技術を使用して配信される通信網アプリケーションの経済的将来性を最大化するための要求事項は、以下のものである。

・アプリケーションをできるだけ多くの携帯装置で実行できるようにする。

・アプリケーションを、新しい電話機がリリースされたとき、できるだけ早急にそれらの上でサービス開始できるようにする。

・同じアプリケーション定義をどこででも実行するというに止まらず、アプリケーションが各携帯装置のフィーチャを最大限に、かつ最も適切なフィーチャを活用できるようにする。

世界の携帯電話機の殆どは、無線アプリケーションプロトコル（Wireless Application Protocol、ＷＡＰ）または拡張ＨＴＭＬ（eXtended HTML、ｘＨＴＭＬ）ブラウザを実装されている。このヴラウザおよび関連する文書ベースのマークアップ言語は、ＷＷＷアプリケーションの構造と直接的に対照可能である。この携帯電話技術を使用すると、世界の殆どすべてのハンドセット上で実行可能な通信網アプリケーションを開発することができる。問題は、ＷＷＷアプリケーションへの制約同様、ＷＡＰおよびｘＨＴＭＬが各携帯電話機能力の極く僅かな部分集合しか使用できないことである。これらの技術は電話機の最も高度なフィーチャにはアクセスしないので、これらの技術を使用して最も機能豊かなユーザ経験を開発することは不可能である。

携帯電話機の大きい割合が今や、アプリケーションの配備に応じるクライアントプラットホームを持っている。非常に重要なことには、これらはＪａｖａ(登録商標）（またはＪａｖａ(登録商標）２携帯エディション−Ｊ２ＭＥ）、ＳｙｍｂｉａｎおよびＢｒｅｗを含む。Ｊａｖａ(登録商標）は、これらの技術の中では最も広く採用されているが、ＳｙｍｂｉａｎおよびＢｒｅｗと同様、その技術で構築したアプリケーションは未だ厳しい問題と限界を有する。数百の異なる携帯通信網上に数千もの種々形式の電話機約２０億個が存在する。これがＪａｖａ(登録商標）プラットホームおよびクライアントアプリケーションの構築に一般に次のような問題を提起する。

・電話機が異なるとＪａｖａ(登録商標）のバージョンが異なる。

・電話機が異なるとＪａｖａ(登録商標）のバグが異なる。

・電話機が異なるとＪａｖａ(登録商標）プラットホームの構成部分の実装が異なる。

・電話機毎に、オペレーティングシステムおよびファームウェアの多くの異なる版を有する。これは、形式が同じでも製造後の年数が異なる電話機では動作に違いがあることを意味する。

・同じ電話機がいくつかの識別名でもって存在し得る（例えば、ＭＮＯブランドの電話機）。

・電話機毎に、画面サイズ、画素数、色の深み、キーボード制御およびソフトキー特性等の物理的特性が異なる。

・電話機毎に、プロセッサ速度および記憶サイズ等のコンピュータ能力が異なる。

・電話機毎に、Ｊａｖａ(登録商標）を介して表示される媒体ファイルおよび形式の集合（例えば、オーディオ、画像、ビデオ、アニメーション等）が異なる。これらが、電話機がユーザに使用させる元々の、画面の壁紙設定等の、電話機アプリケーションでの形式と異なることもしばしばである。

・電話機毎に、ソフトウェアの限界が異なる（２つの電話機が同じメモリ量を持ちながら、アプリケーションで使用できる量が異なる）。

・電話機毎に、電話機のオペレーティングシステムが扱うことができる媒体ファイルと形式の集合が異なり、これらが、Ｊａｖａ(登録商標）または電話機上でアプリケーションを実行するプラットホームが扱うことができるものと異なることもある。

・電話機は通信網接続を多くの異なった方法で扱い、技術が異なり、設定が異なり、ユーザプロンプトが異なり、設定が送信され電話機によって扱われる方法が異なり、接続を管理する方法が異なり得る。

・電話機が異なると通信網能力や取り扱い法も異なる（例えば、ＣＳＤ、ＧＰＲＳ、２Ｇ、２．５Ｇ、３Ｇ、ＷＡＰ、ＳＭＳ、ブルートゥース、赤外、Ｗｉ−Ｆｉ、ＷｉＭＡＸ等）。

以上は、Ｊａｖａ(登録商標）等のソフトウェア言語連結型プラットホームが世界の電話機の大多数で利用でき、またそれが、アプリケーションの配備に役に立ちかつ豊かなユーザ経験創出のために電話機の高度なフィーチャを使用できるプログラミング言語を提供できるとしても、現実には多くの相違点を舵取りし緩和するために、電話機毎の特注アプリケーションが必要であることを意味する。

装置毎に最適化された非常に機能豊富なアプリケーションを、大多数の無線コンピュータ装置に迅速かつ効率的に配信するという挑戦に対応できる既存の技術、プラットホームまたは方法は未だ存在しない。

以上で見たように全ての電話機はある程度異なるため、電話機毎の最も高度なフィーチャを使用するアプリケーションを大多数の電話機に配信する唯一の方法は、異なるハンドセット毎に特注アプリケーションを配信することである。この問題に対して従来からの手法を使用するとすれば、どの手法を用いようと、最終結果は不規則で管理しようもなく大量の移植となろう。こうして、新しい電話機毎にアプリケーション構築に使用する新しいコードの「流れ」に行き着くことになろう。これは非常に高価であり、ソースコードの流れが加わるほど、保守はますます困難になる。最終結果は、装置毎にアプリケーションのソースコードをチューニングしたアプリケーションを構築することは禁止的に高価なものになるということである。新しい手法が必要とされていることは明らかである。

カスタム化ソフトウェアアプリケーションは特定形式の無線コンピュータ装置に対して、（ａ）その形式の無線コンピュータ装置の属性を自動的に決定する、（ｂ）ソフトウェア構成部品のライブラリからのその形式の無線コンピュータ装置と適合可能なソフトウェア構成部品を（ａ）で決定した属性値に基づいて自動的に決定する、そして（ｃ）それらの適合可能なソフトウェア構成部品を自動的に結合して、その形式の無線コンピュータ装置に適合可能な、そのアプリケーションにカスタム化されたビルドを生成する、ことにより構築可能である。属性はメタデータであることができる。

この手法により、多種多様な形式の無線コンピュータ装置用に、機能豊富な通信網アプリケーションを自動的にコンパイルすることが可能になる。装置適応型アーキテクチャ（Device Adaptive Architecture、ＤＡＡ）と称する本発明の実施により、携帯電話技術を使用する無線コンピュータ装置にソフトウェアアプリケーションを配信する利便性と経済的見通しを最大化する要求が満される。これにより、
・そのソフトウェアアプリケーションが最大限の携帯装置上で実行できるようになり、
・そのソフトウェアアプリケーションが、リリースされた新しい電話機上で速やかにサービス開始可能となり、
・同じアプリケーション定義をどこででも実行できるに止まらず、そのソフトウェアアプリケーションが携帯装置毎のフィーチャを最大限にかつ最も適切なフィーチャを活用できるようになる。一層の詳細と様相を、添付の請求項で規定する。

本発明について、装置適応型アーキテクチャの実現法に言及しながら説明するものとする。最も機能豊富なネットワークアプリケーションを最大多数の無線クライアントに最も効率的な方法で配備するためのプラットホームを構築するという挑戦であるＤＡＡ法の原則は、以下のものである。

・ハンドセット毎に、ユーザ経験を最大化する特有のアプリケーションが必要である。

・電話機の能力やフィーチャ間の相違は、ソフトウェアではなく、主にメタデータで記述され表現される。ハンドセットサービス開始プロセスがハンドセット毎に集めるメタデータの例を「付録１−ハンドセットのメタデータ」に見ることができる。メタデータが装置毎にどう異なるかの例も示される。

・各電話機間の相違の参照点は、電話機の表現に使用されるメタデータである（「付録１−ハンドセットのメタデータ」を参照のこと）。このメタデータは、最終的には、ソフトウェアアプリケーションの構成に使用される個々のソフトウェア構成部品を選ぶのに使用されるのであるが、ソフトウェアアプリケーションを抹消や再構築できるようにする参照点はその電話機用のメタデータである。

・特定ハンドセット用のソフトウェアアプリケーションは、一方ではその装置特有の能力や個性の記述に使用されるメタデータ（「付録１−ハンドセットのメタデータ」を参照のこと）を使用し、他方ではその装置に適合するアプリケーションに動的にコンパイルできるソフトウェア構成部品ライブラリの記述に使用されるメタデータ（「付録２−ハンドセットのソフトウェア構成部品ライブラリ」を参照のこと）を使用して、装置適応型アーキテクチャソフトウェアにより自動的に構築される。ソフトウェア構成部品ライブラリは、大規模で低粒度な単位ではなく、小規模なソフトウェア構成部品が満載されている。各ソフトウェア構成部品は、機能および各ソフトウェア構成部品を構成する方法を記述するメタデータならびに装置の属性を記述するメタデータを基に、ソフトウェアアプリケーションの一部を構成するよう選択することもできる。「付録３−ハンドセットメタデータのソフトウェア構成部品へのマッピングの例」を参照のこと。

・ハンドセット用のカスタム化ソフトウェアアプリケーションの構築に使用されるハンドセット毎の特有の性質を記述するメタデータを、プラットホームに追加することができる、高速な方法。ハンドセットが、現存のソフトウェア構成部品の変更の必要がなく、それらの組み合わせを使用してサービス開始を行う場合は、それはハンドセットのメタデータを構成するだけで達成される。もし新しいまたは現存のソフトウェアコードが改造を要するならば、関連する記述内容のメタデータを持つ新しいまたは現存のソフトウェア構成部品がライブラリに追加されるかまたは変更される。

・ライブラリ中ではまだ利用可能でない方法と技術を使用して機能を実装するハンドセットが発見されたとき、新しいまたは現存のソフトウェア構成部品をライブラリ中に追加または変更することができる、高速な方法。そのソフトウェアを含む新しいファイルをライブラリ中のファイルシステムに置くことにより、新しいまたは変更されたソフトウェア構成部品を速やかに追加することができる。これは、ソフトウェア構成部品が使用される条件またはソフトウェアアプリケーションのビルド中で使用するための構成方法を記述するメタデータによって補足される。

・この新しくサポートされるハンドセットに、そのハンドセット特有のソフトウェアの開発量を最低限に抑えて、多くの異なる通信網アプリケーションを配備できるようにする追加的なメタデータおよびその表層でのマークアップ構文法。「付録４−エンドユーザアプリケーションのメタデータおよびマークアップ」を参照のこと。

・実装後、ソフトウェアアプリケーションを電話機上で動的に変更する能力。

・クライアントが、ユーザ特有の一層のチューニングが可能なよう、その状態と鍵となるパラメータをサーバに報告できるようにする能力。例えば、ソフトウェアアプリケーションはクライアントがそのとき利用可能な持続的および動的なヒープメモリ空間を決定するテストを実行できる。これは、許容最大メモリサイズの超過を回避するために、クライアントのソフトウェアアプリケーションになされるデッキサイズの変更に影響を及ぼし得る。

・ソフトウェアアプリケーションの一意的事例毎の記録保存。

新しいハンドセットをサポートするために先ずなすべきことは、試運転用にそのハンドセットを入手することである。そのハンドセットのプラットホームで利用可能な中核パッケージを識別する簡単で一般的なテストアプリケーションをハンドセットにダウンロードする。この情報を使用して、ハンドセットの能力に見合ったテストアプリケーションを動的に選択する。このテストアプリケーションが、ハンドセットの能力とフィーチャを電子的に調べるためにハンドセットにダウンロードされ、またほかの電話機でみつかったバグ履歴のテストも含んでいる。このテストアプリケーションは、テスト結果を、その電話機の多くの属性および個性を表現するメタデータの集合として蓄積する。その後このメタデータはデータ記憶装置に書き込まれ、その電話機の形式およびそビルドに対応付けられる（「付録１−ハンドセットのメタデータ」を参照のこと）。

それから、ハンドセットの種々の能力および個性について人手による調査とテストが行われ、その結果が同様にデータ記憶装置にそのハンドセットと対応付けて格納され、テストアプリケーションからの初期のデータ集合を補充する。全ての情報が取得され全ての初期テストが完了すると、この新しいハンドセット用に特注ソフトウェアを構築するためにアプリケーションプラットホームを使用するに足る十分なデータが得られる。

そのハンドセット用のソフトウェアアプリケーションの構築には使用されない、その他種々のハンドセット特有の情報も収集される。この情報は、そのハンドセット用に構築したソフトウェアアプリケーションの運用を支援するシステムで使用するために収集される。例えば、通信網設定値が記憶される特定ハンドセット上のロケーションを記録して、アプリケーションの適当な時点でユーザがハンドセット特有のガイダンスにより援助を受けれるようにする。「付録１−ハンドセットのメタデータ」の「ユーザ支援特性」を参照のこと。

装置適応型アーキテクチャ（ＤＡＡ）の中心部には、ハンドセット、時にはハンドセット／携帯通信網の組み合わせ、毎にソフトウェアアプリケーションを動的に構築するエンジンが存在する。ＤＡＡはハンドセットの能力を表現するメタデータを読み取り、そしてこれらの能力をライブラリ中のソフトウェア構成部品の能力および構成オプションを記述するメタデータと相互参照する。「付録３−ハンドセットメタデータのソフトウェア構成部品へのマッピングの例」を参照のこと。その後、ＤＡＡは、要求されたように構成され選ばれたソフトウェア構成部品を、そのハンドセット、時には携帯通信網との組み合わせ、用の特製のクライアント用ソフトウェアアプリケーションに結合する。

するとこれは、この特定ハンドセット用に特注のソフトウェアアプリケーションに相当したものとなり、機能的なエンドユーザアプリケーションそのものというより、実際にはむしろアプリケーションを実行するためのプラットホームになる。言い換えれば、上記の実行により、アプリケーション実行プラットホームが動的かつ自動的に構築されるということである。このアプリケーション実行プラットホームがそのハンドセットにダウンロードされ、それ自身メタデータで定義されるアプリケーションに対して、エンドユーザアプリケーションまたはサービスを実際に実現するよう要求する。「付録４−エンドユーザアプリケーションのメタデータおよびマークアップ」を参照のこと。アプリケーションを記述するこのメタデータはその後、生成されたアプリケーション実行プラットホームソフトウェアに加えられ、最終的に、ハンドセットに実装されて実行するときに、エンドユーザアプリケーションを実現するソフトウェアプログラムとなる。

ソフトウェアアプリケーションが特定のハンドセット用に構築される都度、このアプリケーションの事例がビルドの保存記録に格納される。保存記録は、ソフトウェアアプリケーションの各バージョン用の数百もの異なったビルドを履歴記録として保存する。履歴としてのビルドは、ＤＡＡの動的構築プロセスをハンドセットメタデータおよびソフトウェア構成部品のバージョンとその時点で有効な関連メタデータを使用して再実行させさえすればいつでも作り直し可能である。

このソフトウェアアプリケーションのビルドの候補はその後、アプリケーションが新しいハンドセット上で正しく動作することを確認するために、人によるシステムテストを受ける。これは、完全な成功裡に決着する場合もあれば、ハンドセットメタデータの変更、アプリケーションの再構築とリセットに終わる場合もあり、またソフトウェア構成部品のあるものが保全のため改造に付される、または新しいソフトウェア構成部品が構築され次いでアプリケーションの再構築、および次いでのリセットに終わる場合もある。最終的に、完全に機能するソフトウェアアプリケーションがこのハンドセット用に利用可能となり、それがシステムテストに合格したとき、エンドユーザによる実際の使用のための生産システムへと供される。

ハンドセットが接続される特定の携帯通信網もまた、そのハンドセットのアプリケーションのビルドに影響を及ぼし得る。ＤＤＡにとって、要求に応じてＭＮＯ用の正しいビルドをハンドセットに供し得るためには、ＭＮＯおよびその通信網構成を詳細に理解することが、ハンドセットを詳細に理解するのと同様非常に重要である。詳細については「付録５−通信網事業者のメタデータ」を参照のこと。

通信網を介するソフトウェアアプリケーションのダウンロードを要求するためにユーザ装置がシステムに接続すると、ハンドセットはシステムにそのユーザエージェントプロフィール（User Agent Profile、ＵＡＰｒｏｆ）を通知する。これは電話機製造業者、モデルおよびファームウェアを記述する。ハンドセットが要求するソフトウェアアプリケーションを、ユーザが接続する携帯通信網に合わせて、ときには彼らがＭＮＯと交わす支払い契約（プリペイドか月払い契約か、等）にさえ合わせて、カスタム化しなければならない場合もある。この状況では、ハンドセットが接続する携帯通信網が何であるかは、要求ＳＭＳの中で見つかるＭＮＯ情報、ＳＭＳが辿って来た経路、その要求がＭＮＯ基幹通信網の検索（利用可能なら、ＳＳ７／ＨＩＲ、等）を介して通ってきたＭＮＯゲートウェイのＩＰアドレス、ＭＮＯ番号割り当て範囲に対応する電話番号（ＭＳＩＳＤＮ）の検索、およびポーティッド番号データベースによって検出されるか、またはダウンロードに先立って単純に画面上でユーザに質問することにより、検出される。システムはそれが利用可能な最も信頼できる方法を使用する。ユーザエージェントプロフィールが、接続してきたハンドセットによるダウンロードに対して提示するべき、正しい、既に生成済のアプリケーション選択への鍵である。なお、ユーザエージェントプロフィールがＭＮＯの詳細および支払い契約の形式と結びついていることもある。

エンドユーザへの請求書作成またはエンドユーザの追跡、またときには起こるエンドユーザ支援を実行する目的から、全てのハンドセットによりダウンロードされたソフトウェアアプリケーションの事例、およびそのソフトウェアアプリケーションの事例が実装された全てのハンドセットの携帯電話番号（ＭＳＩＳＤＮ）を、一意的かつ個別的に識別できることが重要である。これを実行するため、ダウンロード前またはダウンロード時に、ＤＡＡは一意の参照番号をソフトウェアアプリケーションに組み込む。この参照番号は、エンドユーザがソフトウェアアプリケーションを要求する間に彼らから（例えば、アプリケーションを要求するＳＭＳ、またはウェブの書式上に集積されたＭＳＩＳＤＮ、等から）取得されるユーザのＭＳＩＳＤＮと、サーバのデータ記憶装置において対応付けられる。今やクライアント中に存在するソフトウェアアプリケーションがその後サーバからのサービスを要求するとき、それは一意のソフトウェアアプリケーション事例ＩＤを自動的に提供する。ＭＳＩＳＤＮが要求されると、それを調べるのにその一意の事例ＩＤを使用することができる。

以上では、ＤＡＡによって自動的に生成されるソフトウェアアプリケーションが、製造業者、装置形式および時にはファームウェア（組み込み装置ソフトウェア）のバージョンにより、またはその装置が接続された携帯通信網により識別されるよう、携帯電話機毎にどのように特注構築されるかを議論した。装置がソフトウェアアプリケーション取得の目的でサーバに接続されると、サーバはこれらの可変の属性を決定し、この電話機に適したアプリケーションを選択する。

しかし、ユーザがハンドセットを取得するときに、そのようなソフトウェアアプリケーションがその携帯電話機上に存在するよう、それらをユーザ電話機にプリインストールしておくことと関連する大きい商業上のチャンスが存在する。

ユーザが電話機を取得する前にアプリケーションを携帯電話機にプリインストールできる場所は一般に２つある。１つは、その供給者（または製造契約業者）によるその装置の製造においてである。もう１つは、エンドユーザへのサプライチェーンにおける装置の構成／提供施設においてである（携帯電話機卸業者または小売業者）。

これらのいずれの状況でも、携帯電話機はある時点で、携帯電話機を使えるように設定する（設定を制御する）装置に接続される（または、接続することができる）。この時点で、われわれのシステムはその設定制御装置とインタフェースを持ち、そのハンドセットにプリインストールされるどのソフトウェアアプリケーションのバージョンにもアクセスするようにする。

このようにして、適切なソフトウェアアプリケーションは、携帯装置上にそれを設定できるようにする設定制御装置からの利用が可能となる。しかし、ハンドセットに実装されたアプリケーションが携帯電話機のＭＳＩＳＤＮにアクセスできないこともあり得るので、これは、一意のソフトウェアアプリケーションを、アプリケーションの内部に組み込みの一意の事例ＩＤ参照（この事例ＩＤ参照は、サーバへ返送することができ、そこで（例えば）請求書作成の目的で、ユーザのＭＳＩＳＤＮと関連付けることができる）を付して、１つ１つの装置毎に提供するのとは異なる。そうではなく、そのアプリケーションは、同一の提供業者、モデル、ファームウェアおよび時にはそれらが接続される／接続されるであろう携帯通信網を共有する全ての携帯電話機に共通であろう。したがって、ＭＳＩＳＤＮへのこの関連付けは、ソフトウェアアプリケーションが携帯電話機に実装された後で、後付け的に行われる必要がある。これはつぎのように実行される。

１．携帯電話機／通信網の組み合わせに固有のソフトウェアアプリケーションが、携帯電話機設定制御装置とインタフェースを持ち、それが必要とする全てのソフトウェアアプリケーションのビルドおよび提供業者／モデル／ファームウェア／ソフトウェアアプリケーションバージョン毎の関連する通信網情報を供給して、正しいものが選択されインストールされるようにすることにより、電話機にプリインストールされる。

２．携帯電話機がエンドユーザによって取得される。

３．エンドユーザがその装置をスイッチオンし、ソフトウェアアプリケーションを見つけ、それを開始する。

４．ソフトウェアアプリケーションがサーバに接続すると、それは自分自身をプリインストールされたアプリケーションであると述べ（関連するアプリケーション事例ＩＤ無しで要求することにより）、この装置へのこのソフトウェアアプリケーションの選択に使用される属性に関連する情報（提供業者／モデル／ファームウェア／通信網、等）を提示する。

５．この情報は、サーバが、関連する一意のＩＤを持つ事例記録をこのソフトウェアアプリケーション用に作成できるようにし、またこの一意の参照をこのソフトウェアアプリケーションの事例に割り当てれるようにするのに十分である。この一意のＩＤは通信網を介してソフトウェアアプリケーションに戻され、アプリケーションはこのＩＤをローカルに保存し、その後の全てのサーバサービス要求においてそれを提示する（それが最初からソフトウェアアプリケーションに組み込まれていたかのように）。

６．サーバは、以上で始めに示したデータから、コンテンツアプリケーションがそのハンドセット用の正しいタイプおよび形式の携帯コンテンツを配信できるよう、その装置に適合したコンテンツタイプが何かを決定することもできる。

７．このようにしてエンドユーザは、電話機のＭＳＩＳＤＮを要求しなくてもシステムが利用可能な、ソフトウェアアプリケーションの全ての部分を使用することができる。

８．ユーザが、ＭＳＩＳＤＮを必要とするソフトウェアアプリケーション部分にアクセスし、そのＭＳＩＳＤＮがソフトウェアアプリケーションからアクセス可能であると、それは読み取られてサーバへの要求の一部としてサーバへ送信される。そして、それはサーバのデータベースに書き込まれ、そこでアプリケーション参照ＩＤと関連付けられる。したがって、ソフトウェアアプリケーションからそれを再び送信することは要求されないであろう。

９．ユーザが、ＭＳＩＳＤＮを要求するソフトウェアアプリケーション部分にアクセスし、そのＭＳＩＳＤＮがそのソフトウェアアプリケーションからアクセス可能でないと、ハンドセットと組み合わせたソフトウェアアプリケーションの能力に依存して、以下の場合が発生する。

ａ）もしハンドセットがソフトウェアアプリケーションにＳＭＳを送信する能力を与えると、ＳＭＳがソフトウェアアプリケーションの一意の事例ＩＤを含むサーバに送られる。このＳＭＳがサーバに受信され、サーバはその一意のアプリケーション事例ＩＤを、入力ＳＭＳからそれが決定したＭＳＩＳＤＮと関連付けることができるようにする。

ｂ）もしソフトウェアアプリケーションが携帯通信網に接続するのに使用する方法が、ＭＳＩＳＤＮをサーバへ転送することを許すならば（例えば、接続するＭＳＩＳＤＮを要求ヘッダー上に置く特別なモデムを介して、または通信のヘッダー中のＭＳＩＳＤＮを提供できるＭＮＯ通信ゲートウェイを介して）、サーバがＭＳＩＳＤＮを検出し、これを使用してサーバのデータベース中でＭＳＩＳＤＮとアプリケーション事例ＩＤとを関連付けることができる。

ｃ）もしａ）もｂ）も利用可能でないなら、ソフトウェアアプリケーションはユーザにＭＳＩＳＤＮをアプリケーションのユーザインタフェースに手動で入力するよう依頼しなければならない。これが行われ、サーバへ送信される。サーバはこのソフトウェアアプリケーションのＭＳＩＳＤＮをそのアプリケーションの一意の事例ＩＤと関連付けることができる。この方法が使用される場合、セキュリティまたはＭＳＩＳＤＮの正確さを確実にするためにサーバによって実行される追加の工程があってもよい。例えば、入力されたＭＳＩＳＤＮに対して、ユーザが何らかの購買フィーチャをアンロックすべくソフトウェアアプリケーションに入るのに必要なＰＩＮ番号を返送する工程である。

この装置適応型アーキテクチャを使用して構築されたソフトウェアアプリケーションは、エンドユーザには非常に応答性がよいように見える。これの理由は、エンドユーザアプリケーションを定義するのに使用されるメタデータおよびマークアップ言語（「付録４−エンドユーザアプリケーションのメタデータおよびマークアップ」を参照のこと）がローカルなクライアント上で、ソフトウェアアプリケーション中にデータとして記憶されているからである。これは、このクライアント用にＤＡＡによって生成されたアプリケーション実行プラットホームが、エンドユーザアプリケーションを実行してかつこのように高速に見えるようにするためにこのローカルな資源を使用することを意味する。

ニュースまたは呼び出し音等のコンテンツのリストを表示するソフトウェアアプリケーションは、それらのコンテンツ構造をエンドユーザアプリケーションのメタデータ定義内にキャッシュするのにこの機構を利用することができる。これは、エンドユーザがアプリケーションを実行するとき、コンテンツのリストにアクセスするのにサーバへの接続を要しないため、非常に高速に見えるであろうことを意味する。

クライアントのソフトウェアアプリケーションは、エンドユーザアプリケーションを表現するメタデータのどの構成部品でも更新を要求することができる。これはアプリケーションが、無線で完全に更新可能であることを意味する。これは、１つのメニューにおけるコンテンツのリストを更新するという単純な要求から、エンドユーザアプリケーション中の全てのコンテンツを更新するまたはエンドユーザアプリケーションの定義全体そのものを更新する、将来的には、ソフトウェアアプリケーションの全性質を効率的に変える、という要求にまで及ぶ。

エンドユーザアプリケーションは、メニュー、サブメニュー、ルックアンドフィール（見た目）要素、画面構成配置およびアプリケーションの任意のコンテンツ参照を定義するデータファイル形式またはデッキ形式でパッケージ化されている。画面はＸＭＬで定義され、それら画面中の資源やコンテンツへのＸＭＬ参照を使用する。画面定義はコンテンツおよび表現資源とともに格納され、ソフトウェアアプリケーションとまとめるために２進情報に変換される。デッキは他のデッキから参照することができる。参照されたデッキが要求されしかしクライアント上に無いと、それはサーバに要求される。各デッキは、データストリームからロードされる。そのデータストリームは、ソフトウェアアプリケーション中に格納されたファイルであるか、ローカルメモリに格納されたレコードであるか、またはサーバからストリーム転送されるファイルである。

各デッキまたはデッキ中の項目は、それを失効にできたり、ローカルなデッキではなくサーバからダウンロードされた新しいバージョンが使用されるようにするために、オプションの有効期限を有する。これはケイ線や日々に変わるニュースのようなフィーチャを提供するのに効果的である。ユーザが、有効期限が設定されかつ過ぎたデッキを利用するエンドユーザアプリケーションの一部を使用するときはいつでも、サーバからの更新機構が働く。

更新頻度の予想やハンドセット上の各ロケーション中の利用可能な空間に依存して、異なったデータの格納には異なったタイプのデッキが使われる。動的なデッキ中の項目はそれほど動的ではないデッキ中の項目に取って代わることができる。（例えば、アプリケーションに格納されたシステムデッキ中の構成は、サーバから流れてきてデッキに適用されたその後の変更によって取って代わられ得る）。

サーバはまたアプリケーション中の任意のデッキを無効にする能力を有する。これはソフトウェアアプリケーションがサーバへの接続を行うときに実行され得る。これは、サーバにエンドユーザアプリケーションを新規化または更新させる効果を持つ。サーバは、クライアント上の要素を参照し新しい要素を提供することにより、要素への更新を行う。

ソフトウェアアプリケーションが資源をダウンロードするために通信網を介してサーバに接続しその資源がダウンロードされるまでの間の待ちがある場合、クライアントアプリケーションはアニメーションおよび進捗バーを表示することができる。そのアニメーションは見た目の面白さをいくらかでも提供し、感じられる待ち時間を軽減する目的のものである。進捗バーは、進捗の度合いをある程度示すものである。クライアントプラットホーム上にアニメーションライブラリが存在しない場合、これらのライブラリはソフトウェアアプリケーション中で提供される。それらは、クライアントプラットホームの、Ｘ／Ｙ座標を使用して、クライアント画面の各部分に完全なまたは部分的な図を配備する能力を使用して構築される。これらのイメージプロット間にタイミングをとって結合すると、アニメーションのように見える。

ハンドセットおよび携帯通信網に対応して記録されたメタデータの一部として含まれるものに、特定携帯通信網についての適切な通信網接続の設定、これらの通信網設定をハンドセットに無線で配信するメカニズム、およびそのハンドセット／ＭＮＯの組み合わせが設定を必要としそうかの見込みに関する情報がある。

この情報を使用して、プラットホームは、それが行われていないようならば、ハンドセットへの通信設定の実施を自動的に試みることができ、またはエンドユーザに彼ら自身への設定の送信を開始する機会を提供できる。それはまた任意の追加の人手による構成についての指令を与えることができる。それが与えられると、エンドユーザからの設定を要求する。

クライアントのソフトウェアアプリケーションによってなされるサーバへの全ての要求はサーバの運用ログ中に記録される。エンドユーザのアプリケーションメタデータ定義中で追跡が必要とマークされた、クライアントのソフトウェアアプリケーションへの全ての行動は、運用ログへの記録と同様の目的でサーバに知らされる。これは、顧客の利用について収集された豊富なデータのおかげで非常に洗練された顧客対応管理が実行可能であることを意味する。例えば、この非常に豊富な運用データは、システム運用の鍵となる１セットの性能指標とみなし得る。

クライアントアプリケーションの全てのエラーはクライアントソフトウェアアプリケーションによって記録され、クライアントが成功裡にサーバと交信できる次の機会にサーバに渡される。これにより、クライアントソフトウェアアプリケーションの一般ハンドセット群における実行状況の詳細な図を構築することができ、ハンドセットが呈する動向を任意の感度で探すのに使用ができる。この情報はまた、ハンドセットメタデータの調整を伴う処置を要するバグを持ち込んだ特定の新しくリリースされたハンドセットファームウェアのバージョンを識別するのに使用することもできる。

システムはグラフィカルツールである完全なサービス管理スイートを含んでおり、これがオムニフォン社のパートナが彼等自身のシステムを管理することを可能にする。これらのツールは、エンドユーザアプリケーションを制御し、様々な構成をとるメタデータを見る窓である。サービス、例えば、アプリケーションの流れまたはコンテンツ構造、のメタデータ要素を単に変更することにより、アプリケーションの性質を変更することができる。

クライアントとサーバとの間の全ての相互作用が記録されるため、システムはクライアントとサーバとの間を通過するデータトラフィックの完全な量を知る。これは、通信網のデータ使用が関連するコストを有するとき意味を持っており、任意のソフトウェアアプリケーションによってサーバとの間を行き来して転送された全バイト数がわかれば、使用水準がどうであったか、その結果、コストがどうであるべきか、を算出可能である。

サーバは、システムがまだ見たことがなく、システムと相性のよくない新しい電話機の使用を監視する。新しいハンドセットがソフトウェアアプリケーションをダウンロードしようとし、プラットホームが適当なものを見つけられないとき、システムはシステム管理者に通知する。加えて、このような装置個々からの要求の計数値が、どの装置が次にサービス開始させるべく最も重要であるかを潜在的なユーザ数に基づいてシステム管理者にわかるよう、保持される。

サーバは、クライアントソフトウェアアプリケーションに容易に追加可能な「友人に送る」フィーチャを実現する。使用時に、それは「友人に送る」オプションをハンドセットのメニュー上に表示する。選択されると、ユーザは友人のＭＳＩＳＤＮを、可能ならば時にはかれらの電話機のアドレス帳経由で、入力することができ、オプションとして挨拶を入力することもできる。このユーティリティは、そのアプリケーションを指定された友人に送信するようサーバに告げる。これはＷＡＰプッシュまたはＭＭＳのような技術を使用して実行される。

ソフトウェアアプリケーションは、現存のエンドユーザアプリケーションのユーザベースに同報される広告文の表示を可能にする。ユーザの全てまたは部分集合がソフトウェアアプリケーションを介して広告文を受信する標的となることを可能にする。広告文は、サーバプッシュとして配信されるメッセージであり、適切な画面上では派手に目立つ。これは、サーバがエンドユーザアプリケーションをサーバプッシュを有効化することにより利用可能と記述される柔軟性により容易化される。

ＤＡＡは携帯電話機（または現実には無線コンピュータ装置）にアプリケーションを配信するのに適当なだけではない。それは、アプリケーションが多数の（非無線クライアントコンピュータ装置を含む）クライアントコンピュータ装置に対して構築され配信されるよう要求される状況に対して有効である。ここで、
・要求されたアプリケーションが全ての装置について類似している、
・装置の多くのものの間には多くの相違点はあるが、それらは基本的には同じであり、クライアント間の相違はメタデータで記述可能であって、装置適応型アーキテクチャによってアーキテクチャを構築するのに使用可能である、
・配備されるアプリケーションは装置間の相違を理解できることから利益を得、可能な最良の機能性およびフィーチャを各装置に与える。

・アプリケーションは一度あるいは可能な限り少ない回数だけ記述され／提示されるべきである。そして、装置毎に要求されるカスタム化アプリケーションを構築するためには、装置特性を表現するメタデータが使用されるのであり、伝統的な移植の実行によって到達した、アプリケーションのバージョン毎に記述され、各装置毎にアプリケーションによって要求される相違点が使用されるのではない。

付録１−ハンドセットのメタデータ
本節は、ハンドセットサービス開始フェーズ間の各ハンドセット用に集積されたメタデータの型の詳細を含む。メタデータは論理的にグループ化され、説明される。装置が異なるとメタデータがどう変り得るかについて様々な例が提示される。

ハンドセットのサービス開始を可能にするために集積されたメタデータ、およびその結果としてのハンドセットへの豊かなアプリケーションの配信は常態的に変化する。これは、ハンドセットのリリースされる新しいフィーチャおよび機能、ならびにその結果としてのハンドセットから集積されるメタデータを継続的に発展させる必要があるためである。

付録２−ハンドセットのソフトウェア構成部品ライブラリ
この付録は、ハンドセットのアーキテクチャの構築中に選択すべき、装置適応型アーキテクチャによって利用される、ライブラリ中のソフトウェア構成部品のタイプと性質をリストする。これらの構成部品は、ハンドセットの定常的な進化とその結果としての新しく更新されたソフトウェア構成部品への要求により定常的に変化している。

中核的な構成部品
ハンドセットの中核的な構成部品を以下に列挙する。

・オーディオプレーヤ構成部品
・アニメーション構成部品
・文字列表示構成部品
・イメージ表示構成部品
・リスト表示構成部品
・評価構成部品
・テキストフィールド構成部品
・ＨＴＴＰ通信構成部品
・ブラウザオープン構成部品
・ＳＭＳ送信構成部品
・コマンド（ソフトキー）オプション構成部品
・ＧＺＩＰ構成部品
・メモリパーシステンス（ＲＭＳ）構成部品
・ビデオプレーヤ構成部品
・ファイルパーシステント構成部品
・チェックボックス構成部品
・ラジオボタン構成部品
・ＳＭＳ受信構成部品
・ブルートゥース通信構成部品
構成部品の変異形
各構成部品はいくつかの変異形を持つ。代表的な例を以下に示す。

・オーディオプレーヤ構成部品の変異形−常に以下の１つ
・オーディオプレーヤなし
・「標準」ＭＭＡＰＩオーディオプレーヤ
・Ｓａｍｕｓｕｎｇオーディオプレーヤ
・ＶＳＣＬ（Ｖｏｄａｆｏｎｅ）オーディオプレーヤ
・Ｓｉｅｍｅｎｓオーディオプレーヤ
・ＨＴＴＰ通信構成部品の変異形−以下の任意の組み合わせ
・「標準」
・ユーザ識別子がクッキー中にあり／ユーザ識別子がＵＲＬ中にあり
・信頼できない接続の恐れ
・同時接続を扱え
・ＳＭＳ送信構成部品の変異形
・要求に、ポート番号あり／ポート番号なし
・「標準」ＷＭＡ
・Ｓｉｅｍｅｎｓ ＳＭＳ変異形
・Ｓａｍｕｓｕｎｇ ＳＭＳ変異形
・メッセージパディングあり／メッセージパディングなし（装置固有のバグの取り扱い）
・ブラウザオープン構成部品の変異形
・Ｊａｖａ(登録商標）からＷＡＰをオープンできない
・Ｊａｖａ(登録商標） ＨＴＴＰ接続のテストが未だならば、Ｊａｖａ(登録商標）からＷＡＰをオープンだけできる
・Ｊａｖａ(登録商標）からＷＡＰをオープンできるが、Ｊａｖａ(登録商標） ＨＴＴＰ接続が必要
・ＷＡＰ設定を使用してＪａｖａ(登録商標）からＷＡＰをオープンできる
サブ構成部品
各構成部品／構成部品の変異形は、異なるによって制御できるいくつかのサブ構成部品を持つ。例を以下に示す。

・オーディオプレーヤ構成部品
・適切なコンテンツ／コンテンツタイプのオーディオプレーヤの作成構成部品
・オーディオプレーヤ開始構成部品
・オーディオプレーヤ停止構成部品
・オーディオ再生終了検出構成部品
・オーディオプレーヤ破壊構成部品
・ＨＴＴＰ通信構成部品
・ＵＲＬ作成構成部品
・ＨＴＴＰヘッダ作成構成部品
・接続作成構成部品
・ＨＴＴＰ要求作成構成部品
・ＨＴＴＰ状態検出構成部品
・ＨＴＴＰ構成部品の再試行
・ＳＭＳ送信構成部品
・ＳＭＳオブジェクト作成構成部品
・ＳＭＳ接続作成構成部品
・ＳＭＳ送信構成部品
・メモリパーシステンス（ＲＭＳ）
・レコード作成
・レコード読み取り
・レコード更新
・レコード消去
・レコード分割
・レコード統合
・アニメーション構成部品
・アニメーション表示
・アニメーションサイズ
・アニメーション優先
・アニメーション速度
・コマンド（ソフトキー）サブ構成部品
・ＪＡＲ中の画面のオープン
・ＲＭＳに格納された画面のオープン
・現在のデッキ中の画面のオープン
・ＨＴＴＰ経由でデッキをダウンロードし、画面をオープン
・ＳＭＳの送信
・ＷＡＰブラウザ中のＵＲＬのオープン
付録３−ハンドセットメタデータのソフトウェア構成部品へのマッピングの例
ライブラリ中のいずれのソフトウェア構成部品も、任意の数の装置特性と関連付けることができる。特性との関連付けは、下記のテストのいずれに基づくことがあってもよい。

・直接特性存在テスト（例えば、このソフトウェア構成部品が適合可能または使用されるには、特性Ａが存在しなければならない）
・比較特性値テスト（例えば、このソフトウェア構成部品が使用されるには、特性ＢはＸより大きい値を持たねばならない）
・ソフトウェア構成部品の特性値と対照しての装置特性値の比較テスト（例えば、ソフトウェア構成部品が使用されるには、装置特性Ｃはそのソフトウェア構成部品の特性ＳＣより小さい値を持たねばならない）
・適合可能なソフトウェア構成部品の最も適切な集合が選択されるようにする評価メカニズム（例えば、１つ以上のソフトウェア構成部品が適合可能な場合、構成部品属性ＳＣが最大値を有するソフトウェア構成部品を選択することにより、目的に最も適合するものを選択せよ）
・以上の任意の組み合わせ
これらの特性がライブラリソフトウェア構成部品にマッピングされる方法の例を本節で示す。

ビルド（Build)
オーディオプレーヤ構成部品
・名前がワイルドカード「device.package.*」に一致する装置特性の設定に基づいて、インクルードして使用するオーディオパッケージを選択
・装置が１つ以上のオーディオパッケージをサポートするなら、オーディオタイプの選択幅の最も広いものをサポートするパッケージが自動的に選択される。この決定は、「device.package.*」によってサポートされるオーディオプレーヤ構成部品変異形と対照して記述される、サポートされるパッケージのリストを比較することにより行われる。

・電話機がdevice.build.properties.audio.incapable特性によって示されるオーディオに対応していないなら、オーディオプレーヤ構成部品を除外
・使用可能なオーディオが存在しないなら、「プリビュー使用不可」構成部品をインクルード
ＨＴＴＰ通信構成部品（接続作成サブ構成部品）
・device.build.properties.connection.primer特性の設定に従って、付加的な接続（プライマ）要求を含める
ＳＭＳ送信構成部品
・device.build.properties.sms.port.requiredおよびdevice.build.sms.truncated特性に従ってＳＭＳ要求を構築する
アニメーション構成部品
・装置特性（ハンドセットグループ、使用可能な動的メモリ）に基づいて資源が制限されるとき、カンバスの代わりに書式を使用する
ブラウザオープニング構成部品
・装置に対するdevice.packages.midp.2.0の存在により表示される、ハンドセットで機能がサポートされる場合のみ、プラットホーム要求サブ構成部品を含める。

・しかし、device.properties.connection.platform-request.http.fails.afterまたはdevice.properties.connection.platform-request.http.fails.beforeのいずれかが設定されているなら、構成部品を除外
チューニング(Tuning)
あるソフトウェア構成部品は、インクルード後、装置メタデータの特性に従ってさらにチューニングされる。例として、以下のものがある。

ＨＴＴＰ通信構成部品（接続作成サブ構成部品）
・device.properties.http.primer.delay.beforeおよびdevice.properties.http.primer.delay.after特性の値に基づいて、プライマ接続の試行および主接続の手順を制御する。

・device.properties.http.primer.delay.beforeおよびdevice.properties.http.primer.delay.after特性の値に基づいて、プライマ接続の試行と主接続の試行との間の時間遅延を制御する。

・device.build.properties.connection.primer.reverse.first.connectionに従ってこれらの順序を切り替える。

アニメーション構成部品
・装置の画面の大きさおよび使用可能なメモリがそこに納まる一組の範囲のサイズに従って、正しいサイズのアニメーションを選択する。

・特性（グループメンバーシップ、画面の大きさ、使用可能な動的メモリ）に記述される使用可能な資源に従ってアニメーションのフレーム速度を調整する。

・アニメーションの滑らかさとハンドセット上で発生するその他の処理とのバランスをとるために、使用可能な資源に従ってアニメーションのスレッド優先順を調整する。特性（グループメンバーシップ、使用可能な動的メモリ）を調査することにより制御される。

メモリパーシステンス（ＲＭＳ）構成部品
・この構成部品は、個々のレコードの最大サイズおよびレコード数を制御することにより、特定装置に対してチューニングされる。これはハンドセット特性device.properties.recordstore.max-record-sizeおよびdevice.properties.recordstore.max-sizeより制御される。

・これは、アプリケーションが基底記憶装置においてデータがどのように分割されているかを知ることを要すること無く、このソフトウェア構成部品を介してデータが持続されることを可能にする。データがいくつかのレコードに分割されることも可能である。

付録４−エンドユーザアプリケーションのメタデータおよびマークアップ
以下では、装置適応型アーキテクチャの上で構築された、エンドユーザ用の画面定義の例を提示する。これらの例は、画面の３つの中核となるタイプ−形式、カンバスおよびリストを示す。これらの拡張マークアップ言語（ＸＭＬ）記述は、アプリケーション画面を完全に記述しており、画面の表現アスペクトの制御およびアプリケーションを通してのコマンドフローの制御に、この定義がどのように使用されるかを示す。これは、無線クライアント通信網アプリケーションのクライアント部が、ソフトウェアコードを書くことなく定義され構築される効果的なメカニズムである。

これらの例で示される特定のフィーチャのいくつかは、
・表示およびユーザ相互作用オブジェクトが含まれ得る
・PlayerおよびImagesのようなより洗練されたオブジェクトを含ませ制御することができる
・変数を設定することができ、読むことができる
・変数についてテスト条件をチェックすることができる
・標準ＭＩＤＰオブジェクトの全ての属性への完全なアクセスが可能である
・コマンドボタンが他の画面を参照する。それらの画面はクライアント上にすでに存在するか、またはサーバから自動的にロードされなければならないことがあってもよい。

付録５−通信網事業者のメタデータ
動作調整用にシステム中で使用される鍵となるメタデータおよび特定ユーザのＭＮＯ能力に従うビルドを以下に列挙する。

システム動作は、ハンドセットアプリケーションが通信する移動体ネットワークのゲートウェイ能力に合わせて調整されなければならない。ＤＡＡは、以下に示されるメタデータを通して各ＭＮＯゲートウェイを理解する。

Claims (31)

1. 特定形式の無線コンピュータ装置用にカスタム化されたソフトウェアアプリケーションを自動的に構築する方法であって、当該方法が、
   （ａ）前記特定形式の無線コンピュータ装置の属性を自動的に決定する工程と、
   （ｂ）前記工程で決定された属性に基づいて、前記特定形式の無線コンピュータ装置と適合可能なソフトウェア構成要素を、ソフトウェア構成要素のライブラリから自動的に決定する工程と、
   （ｃ）前記特定形式の無線コンピュータ装置と適合可能なカスタム化されたソフトウェアアプリケーションの構成を生成するために、適合可能なソフトウェア構成要素を自動的に結合する工程と、
   を備えることを特徴とする方法。
2. 決定された前記ソフトウェア構成要素の属性と適合可能なソフトウェア構成要素を決定する前記工程は、前記特定形式の無線コンピュータ装置の属性値と該ソフトウェア構成要素の属性値と比較する工程を含むことを特徴とする請求項１に記載の方法。
3. 前記特定形式の無線コンピュータ装置の属性がメタデータとして定義されることを特徴とする請求項１または２に記載の方法。
4. 種々の形式の無線コンピュータ装置の属性もまたメタデータとして定義されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記装置が接続される無線ネットワークの属性をメタデータとして決定する工程をさらに含むことを特徴とする請求項４に記載の方法。
6. 種々の無線ネットワークと種々の形式の無線コンピュータ装置との組み合わせの属性をメタデータとして決定する工程をさらに含むことを特徴とする請求項５に記載の方法。
7. 種々の形式の無線コンピュータ装置のメタデータの属性が、装置識別子、市場情報、ネットワーク構成、物理的特性、ネットワーク構成、メディア／コンテンツ能力、ＨＴＴＰ接続、ＳＭＳ通信、Ｊａｖａ(登録商標） ＡＰＩおよびライブラリ、Ｊａｖａ(登録商標）アプリケーションのセキュリティ、ユーザインタフェース能力、ユーザ支援特性の１つ以上を定義することを特徴とする請求項３または４に記載の方法。
8. 無線ネットワークのメタデータの属性が、識別子、開放性、ＳＭＳシステム信頼性、親オペレータＩＤ、提供される契約形式、提供されるデータの接続性、顧客契約の詳細、代表的なネットワーク名の１つ以上を含むことを特徴とする請求項５に記載の方法。
9. 前記特定形式の無線コンピュータ装置または当該装置と接続可能なネットワーク、または当該無線コンピュータ装置と当該ネットワークとの組み合わせ、に関する属性の変化について適合する適当な構成要素が存在し得るよう、前記ライブラリ中のソフトウェア構成要素の機能性が限定されることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 各ソフトウェア構成要素は、前記アプリケーションのカスタム化された構成の一部として使用されるときの事例および条件を記述するメタデータによって参照されることを特徴とする請求項１に記載の方法。
11. 前記無線コンピュータ装置のメタデータと、各ソフトウェア構成要素の参照によるメタデータとを照合することにより、前記特定形式の無線コンピュータ装置と適合可能なソフトウェア構成要素を自動的に決定する工程を含むことを特徴とする請求項１０に記載の方法。
12. 前記特定形式の無線コンピュータ装置と適合可能なソフトウェア構成要素の自動的な決定が、前記無線ネットワークの属性のメタデータと、各ソフトウェア構成要素の参照によるメタデータとを照合することにより実行されることを特徴とする請求項１１に記載の方法。
13. 前記無線コンピュータ装置の属性に応じて、前記適合可能なソフトウェア構成要素を構成する工程を備えることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 前記ライブラリ中の前記適合可能なソフトウェア構成要素が、前記ソフトウェアアプリケーションのカスタム化されたバージョンにコンパイルされることを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. 新しいまたは別のアプリケーションを表現する追加のメタデータとマークアップシンタックスを使用し、前記特定形式の無線コンピュータ装置用に新しくアプリケーションを生成することにより、当該特定形式の無線コンピュータ装置のための別のアプリケーションがカスタム化されることを特徴とする請求項１４に記載の方法。
16. 前記特定形式の無線コンピュータ装置のメタデータの属性は、当該特定形式の携帯電話機にダウンロードした試験アプリケーションによって自動的に決定されることを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
17. 前記特定形式の無線コンピュータ装置のメタデータの属性が手動試験によってさらに決定されることを特徴とする請求項１６に記載の方法。
18. 前記特定形式の無線コンピュータ装置用に生成された前記アプリケーションのメタデータの属性は手動試験が可能であり、当該特定形式の無線コンピュータ装置用に調整されることを特徴とする請求項１７に記載の方法。
19. 前記アプリケーションのカスタム化されたビルドは、実行するアプリケーションが埋め込まれたアプリケーション実行プラットホームであることを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
20. エンドユーザアプリケーションを得るために、該アプリケーションの定義と前記アプリケーション実行プラットホームとが結合されることを特徴とする請求項１９に記載の方法。
21. 前記エンドユーザアプリケーションはメタデータマークアップ言語で定義されることを特徴とする請求項２０に記載の方法。
22. 前記エンドユーザアプリケーションは実行可能なソフトウェアを含むことが可能であることを特徴とする請求項２１に記載の方法。
23. 前記無線コンピュータ装置の前記特定の形式が、製造業者、モデルおよび該形式の電話機に配備されたファームウェアの関数であることを特徴とする請求項１から２２のいずれか１項に記載の方法。
24. 前記無線コンピュータ装置の前記特定の形式が、無線コンピュータ装置が接続する移動体通信網の関数でもあることを特徴とする請求項２３に記載の方法。
25. 前記カスタム化されたアプリケーションが、携帯電話用のコンテンツポータル（論説、ニュース、呼び出し音、壁紙、およびその他の形式の携帯電話用のコンテンツを扱う）、賭け、出会い、バンキング、位置情報、住所氏名録、ゲーム、チャット、ピアツーピアアプリケーションのグループから選択された通信網アプリケーションであることを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
26. 請求項１に記載の方法を実行することにより、カスタム化されたソフトウェアアプリケーションの構築に適応可能なアプリケーション配信プラットホームを構築する方法であって、
    （ａ）前記アプリケーションに関連するソフトウェア構成要素のライブラリを構築する工程と、
    （ｂ）種々の無線コンピュータ装置の属性のライブラリを構築する工程と、
    （ｃ）与えられた形式の無線コンピュータ装置の属性を決定する手段を前記プラットホームに提供する工程と、
    （ｄ）前記の属性を前記アプリケーションに関連するソフトウェア構成要素のライブラリを形成するソフトウェア構成要素の属性と自動的に比較する手段を前記プラットホームに提供する工程と、
    （ｅ）前記形式の無線コンピュータ装置と適合可能なソフトウェア構成要素を自動的に決定する手段を前記プラットホームに提供する工程と、
    （ｆ）前記形式の無線コンピュータ装置に適した、前記アプリケーションのカスタム化された構成を提供するために、前記プラットホームに、適合可能なソフトウェア構成要素を結合する手段を提供する工程と、
    を備えることを特徴とする方法。
27. 請求項１に記載の方法を使用して構築されたことを特徴とするコンピュータプログラム。
28. コンテンツを無線コンピュータ装置にダウンロードする方法であって、該方法が、コンテンツをダウンロードするために請求項２７に記載のコンピュータプログラムを実行する工程を備えることを特徴とする方法。
29. アプリケーションを無線コンピュータ装置に配信する方法であって、該方法が、
    （ａ）前記無線コンピュータ装置がサーバに接続する工程と、
    （ｂ）前記サーバが、前記無線コンピュータ装置に適合するようカスタム化され、請求項１に記載の方法を使用して得られたアプリケーションを前記無線コンピュータ装置に提供できるよう、前記無線コンピュータ装置と適合可能なソフトウェア構成要素を構築する工程と、
    （ｃ）前記カスタム化したアプリケーションを前記無線コンピュータ装置にインストールする工程と、
    を備えることを特徴とする方法。
30. 請求項２９に記載の方法を使用して配信されたアプリケーションを実行することが可能な無線コンピュータ装置。
31. 請求項２９に記載の方法を使用してアプリケーションを無線コンピュータ装置に配信するようプログラムされたことを特徴とするサーバ。