JP5074424B2 - 依存関係の通知 - Google Patents

Description

本出願は通信システムに関し、より詳細には、様々なソフトウエア構成要素で構成可能なユーザ装置を備えた通信システムに関する。

今日では、無線通信システムの携帯電話機またはその他の通信デバイスなどのユーザ装置（ＵＥ、user equipment）のソフトウエアの管理に、幾つかの関係者が関わっている。それらのソフトウエアは、アプリケーション、サービス、および、オペレーティグ・システム（ＯＳ）を含むモジュールであってよく、ＵＥに格納されてＵＥに使用される。デバイス製造業者は、ＵＥソフトウエアの稼動版を、そのデバイスの製造時に完成させる。後になって、エンドユーザは、ソフトウエア・アプリケーション等を、例えば、インターネットを介して別の出所からＵＥにダウンロードしてもよい。ＵＥ製造業者、システム事業者、および／または、業務契約によっては、認可された第３者もまた、稼動版ソフトウエアの一部または全部を遠隔から更新してもよい。

ＵＥなどのデバイスが備える複数のアプリケーション間には依存性があるので、そのような更新の後では、ＵＥのアプリケーションのあるものが動作しなくなる場合もある。デバイス中に存在しないまたは存在しなくなった特定のバージョン（版）のソフトウエア・モジュールに依存するアプリケーションを、エンドユーザがダウンロードすることもあるが、その場合、そのようなアプリケーションは多分動作しないであろう。大抵のＵＥに利用可能な限られたメモリ資源を節約するため、複数バージョンのモジュールをＵＥのメモリに保持することは通常はしない。

オープン・モバイル・アライアンス（ＯＭＡ）は、通信デバイスにおけるデバイス管理（ＤＭ、Device Management）のための仕様を開発しており、それらの仕様のバージョン１．１．２および１．２が、通信デバイスの構成、データ、および設定を管理するプロトコルを規定している。ＯＭＡ標準仕様およびその他の情報は、http://www.openmobilealliance.orgにおいて利用可能である。

ＤＭは、ＵＥ構成の管理および様々なＤＭオーソリティ（Authority）の観点からのＵＥの管理オブジェクト（ＭＯ、Management Object）の管理に関与しており、ＵＥ中の初期構成情報の設定、ＵＥ中に持続される情報のその後の更新、ＵＥからの管理情報の読み出し、およびＵＥが生成するイベントおよび警報の処理を含むが、これらに限定されるものではない。そのようなＤＭを使用して、第三者（third party）がエンドユーザに代わってＵＥを設定することができる。通信ネットワーク事業者、サービス提供業者、および企業の情報管理部門などの第三者は、遠隔から、パラメータを設定し、端末を障害診断し、そしてソフトウエアをインストールまたはアップグレードすることができる。例えば、ＭＯは、ＳｙｎｃＭＬ、―これは、ＸＭＬベースの表現プロトコル、同期化プロトコル、およびＤＭプロトコルのマークアップ記述言語仕様である―、に従って記述されてもよく、プロトコルのためのバインディング（binding）およびＤＭのためのデバイス記述フレームワークを転送してもよい。

ＵＥは、例えば、アプリケーション非依存の設定のための接続性ＭＯ（Connectivity MO）を使用して、無線アプリケーション・プロトコル（ＷＡＰ、wireless application protocol）通信ネットワークなどの通信ネットワークに接続することができる。そのような通信ネットワークのための接続性ＭＯは、ＷＡＰインフラストラクチャにアクセスするために必要なパラメータおよび手段に関係する接続情報、―通信ネットワーク・ベアラ（bearer）、プロトコル、ネットワーク・アクセス・ポイント（ＮＡＰ、network access point）・アドレス、およびプロキシ（proxy）・アドレスを含む―、を提供するであろう。接続性ＭＯについては、「ＤＭ接続管理オブジェクト」、http://www.openmobilealliance.org/ftp/Public_documents/TP/Parmanent_documents/OMA-WID_0123-ConnectivityMO-V1_0-20051004-A.zip、ＯＭＡ（２００５年１０月７日）に述べられている。

ＷＡＰプロキシは、ＷＡＰコンテンツにアクセス可能なプロキシであるのみならず、無線転送プロトコル（ＷＴＰ、wireless transport protocol）、無線セッション・プロトコル（ＷＳＰ、wireless session protocol）、および無線転送レイヤ・セキュリティ（ＷＴＬＳ、wireless transport layer security）・プロトコルのためのエンドポイントである。ＷＡＰプロキシは、例えば、無線セッション・プロトコル（ＷＳＰ）・プロキシ機能または無線電話アプリケーション（ＷＴＡ、wireless telephony application）・プロキシ機能などの機能を持つことができる。物理的プロキシは、プロキシ機能を持つ特定のアドレスであり、例えば、インターネット・プロトコル（ＩＰ）・アドレスとＩＰアクセス可能なプロキシのためのポート（port）とを合わせたもの、およびショート・メッセージ・エンティティ（ＳＭＥ）・アドレスとショート・メッセージ・サービス（ＳＭＳ）を介してアクセス可能なプロキシのためのポートとを合わせたものなどである。論理的プロキシは、同じＷＳＰおよびＷＴＬＳコンテキストを共有してもよい（共有セッション識別子値空間）物理的プロキシの集合である。

ＯＭＡ仕様によれば、接続性ＭＯイネーブラ（enabler）は、ＤＭクライアントによって公表されそしてＤＭサーバの対象とされてもよいＤＭオブジェクト・スキーマの集合を既定することにより、無線データ接続の管理に対処する。オブジェクト・スキーマは３つの部分を持つ。すなわち、最上位の管理オブジェクト―これは、ベアラに中立である―、ベアラ特有のパラメータ集合、および製造供給元（vendor）特有のパラメータを公表するサブツリー（sub-tree）、である。クライアント・プロビジョニング（client provisioning、ＣＰ）を使用してブートされた（bootstrapped）接続パラメータは、その後、ＤＭサーバ、―これは、標準化されたＤＭパッケージを使用して、新しいプロキシおよびＮＡＰを追加することができる―、を通してアドレスを指定したり、管理することができる。プロビジョニングは、デバイス中のＷＡＰクライアントなどのクライアントを設定するためのプロセスであり、一般に、無線による（over the air、ＯＴＡ）プロビジョニングおよび、例えば、加入者識別子モジュール（ＳＩＭ、subscriber identity module）・カードによる、その他のプロビジョニングの両方が含まれる。

図１に描かれるように、ＤＭ管理オーソリティ（ＭＡ、Management Authority）１０２は、例えば、１つ以上のデバイスにデータ接続パラメータを配備（provision）するために、ＤＭサーバ１０４に要求を出す。ＤＭサーバ１０４は、サーバ開始通知（Server-Initiated Notification）をＵＥ１０６に送信し、ＵＥ１０６はＤＭサーバ１０４とのＤＭセッションを確立し、ＤＭサーバ１０４はＵＥにその時点の設定（これは、デバイス特有の拡張部を含んでもよい）について問い合わせる。ＤＭサーバ１０４は、ＤＭ ＭＡ１０２によって規定された要求条件に適合するよう、ＵＥの設定を調整するＤＭコマンドを送信する。ＵＥ１０６およびＤＭサーバ１０４はそれらのＤＭセッションを終了し、そしてＵＥは設定された接続パラメータを使用して通信ネットワーク・データ・サービスにアクセスすることができる。ＤＭ ＭＡまたはＤＭサーバは、ＵＥがパラメータを使用するときにＵＥがそれらを使用できるよう、接続パラメータを「スマート・カード」の類に格納してもよい。

ＵＥ中のファームウェアを更新するための取組みがＯＭＡに存在する。例えば、ファームウェア更新ＭＯの候補イネーブラのバージョン１．０は、携帯デバイス中のファームウェア更新をサポートするＭＯおよびそれらの所要動作を規定する。当然のことながら、「ファームウェア」は、通常、読み出し専用メモリ（ＲＯＭ）から使用されるコンピュータ・プログラミング命令であり、そして「ソフトウエア」は、通常、読み／書きメモリから使用されるコンピュータ・プログラミング命令である。ＯＭＡの候補ファームウェア更新ＭＯはＯＭＡ ＤＭイネーブラを使用し、そして代替のダウンロード・メカニズム（無線による（ＯＴＡ）ＯＭＡダウンロードなど）をサポートする。これは、移動装置が備えるファームウェアの更新を管理するために必要となる、ＵＥ中のＤＭクライアントとＤＭサーバとの間のインタフェースを表わす。

ＯＭＡは、ソフトウエア構成要素管理オブジェクト（ＳＣｏＭＯ、Software Component Management Object）作業項目を開発中である。ＤＭとＳＣｏＭＯがあれば、アプリケーションの完全な作業セットであるとＭＡが決定した全ての必要なソフトウエアを遠隔からインストールすることが、最終的に可能となるであろう。
また、ＳＣＯＭＯアーキテクチャ（ドラフトバージョン１．０、２００５年１２月１３日発行、ＯＭＡ−ＡＤ−ＳＣＯＭＯ−Ｖ１＿０−２００５１２１３−Ｄ）によれば、ソフトウエアコンポーネント・マネージメント・アーキテクチャについての要求条件が定義されている。このソフトウエアコンポーネント・マネージメント・アーキテクチャは、ＯＭＡ ＤＭ ｖ１．２仕様規格によって提供された各種機能に基づいて構成されているため、これらの機能を使用できる。ＯＭＡ ＤＭ ｖ１．２仕様規格によれば、クライアントデバイスにおける特別のソフトウエアコンポーネント管理能力について定義されている。
ヘイズ・ジュニアによる米国特許出願公開ＵＳ２００５／０２２８８４７Ａ１によれば、ＯＭＡ ＤＭ警報を使用してＯＭＡ ＤＭサーバに対してクライアントコマンドやリクエストを送信し、ＯＭＡサーバにおいて管理動作を開始させるための方法、システム及びコンピュータプログラムが記載されている。
ＯＭＡデバイス・管理・規格化オブジェクトの候補バージョン１．２（２００５年６月７日発行）、ＯＭＡ−ＴＳ−ＤＭ−ＳｔｄＯｂｊ−Ｖ１＿２−２００５０６０７−Ｃによれば、ＯＭＡ ＤＭ デバイス記述フレームワークを使用する複数の管理オブジェクトが定義されている。複数の管理オブジェクトのいくつかは、ＯＭＡ ＤＭに準拠したデバイスによって義務化されているが、残りのいくつかはオプションとなっている。
サンマイクロシステムズによる欧州特許出願公開ＥＰ１４８７１７９Ａ２によれば、プロビジョン可能なエンティティについての複数の依存関係を調整する方法と、デジタルコンテンツをクライアントに提供するサーバを含むシステムとが記載されている。当該クライアントは、デジタルコンテンツを受信するのに先立って、デジタルコンテンツを実行するための依存関係を示したリストを含むデスクリプタを識別するように構成されている。
バークハルト他による米国特許出願公開ＵＳ２００４／００３４８５０Ａ１によれば、コンポーネントベースのソフトウエアをサービスパッケージに記憶されている複数のファイルを使用して更新する方法が記載されている。このサービスパッケージには、複数のインストラクションセット（命令セット）が含まれており、それぞれ当該ソフトウエアのコンポーネントの状態や動作コンテキストに対応している。

そうは言うものの、ＤＭおよびＳＣｏＭＯは、アプリケーション間の依存関係、―例えば、エンドユーザがダウンロードしてもよいアプリケーション―、を考慮に入れることができない。アプリケーションが必要とするソフトウエア構成要素のインストールを、ＵＥが通知または要求するための標準的な手法は存在しない。

本発明の態様によれば、コンピュータ・サーバを備える通信システムにおいて、ユーザ装置（ＵＥ）を動作させる方法が提供される。本方法は、ソフトウエアコンポーネント（構成要素）がＵＥから消失したかをＵＥによって判定する工程、およびソフトウエア構成要素が消失したと判定された場合、消失したソフトウエア構成要素を要求するためのリクエストをコンピュータ・サーバに送信する工程を含む。さらに別の態様によれば、サーバは、リクエストに含まれてもよい設定情報、―ＵＥ製造業者、モデル、および／またはバージョンなど―、に基づいて、消失した構成要素を決定する。ＵＥ中に現存するアプリケーションの一覧リストを含んでもよい追加情報を求める要求をＵＥに送信することにより、ＵＥ中のソフトウエアの依存関係をさらに調査することができる。要求および／または追加情報に基づいて、少なくとも１つのソフトウエア構成要素を、適用可能なセキュリティ・ポリシーにも基づくことになろうが、ＵＥに提供することができる。

本発明のさらに別の態様によれば、通信システムは、コンピュータ・サーバおよびＵＥを備えるが、そのＵＥは、コンピュータ・サーバを選択して通信することができ、そしてＵＥ中に存在するソフトウエア構成要素を実行するように構成されたプロセッサを備える。そのＵＥは、ソフトウエア構成要素がＵＥから消失したとプロセッサが決定した場合、消失したソフトウエア構成要素を提供するサーバに第１の要求を送信するように構成されている。そして、サーバは、第１の要求に基づいて、ＵＥに提供されるべき少なくとも１つのソフトウエア構成要素を決定するように構成される。

最初に、本説明は、単に説明の容易さのために、主にＯＭＡ ＤＭの観点から記述されることを理解されたい。この説明が、ＯＭＡ ＤＭに限定されると解されないようにされたい。ＵＥから消失したソフトウエア構成要素を特定してそれと同じものをＵＥにダウンロードするために使用されるメカニズムとは別に、ＵＥが通知することができ、そして消失したソフトウエア構成要素のインストールを要求できることは好ましいことであり、そして、その能力が標準的なメカニズムに適合していることは好都合なことである。

本発明者達には、ほんの一例として、ＯＭＡ ＤＭ ＳＣｏＭＯ、―これは、一般には、ＭＡ１０２がＵＥ１０６中のソフトウエアを管理できるようにするものであるが―、は、ＤＭサーバ１０４およびＭＡ１０２がＵＥ１０６中に存在するアプリケーションの一覧リストも取得できるように構成可能であることがわかった。ＭＡ１０２およびＤＭサーバ１０４は、例えば、ＯＭＡ ＤＭプロトコルを使用して、ＵＥの製造業者、ＵＥのモデル、バージョン、ＯＳなど、その他の設定情報も取得することができる。そのような一覧リストは、インストールされたソフトウエア構成要素およびそれらのバージョンについての識別情報を含むことができる。当然のことながら、ＤＭサーバ１０４がそのようなリストを実際に取得することを許されるかは、アプリケーション・セキュリティ・ポリシーに依存し得る。以下でより詳細に説明するように、ＭＡ１０２は、そのとき、ＤＭサーバ１０４が受信した一覧リストをどちらが含んでよいか、どのソフトウエア・アプリケーション―またはより一般的にはソフトウエア構成要素―が、修正、追加、アップグレード、または消去されるべきか、を設定情報に基づいて決定することができ、そしてＵＥ１０６が然るべく調整されるよう、ＤＭサーバ１０４と調整することができる。

ＯＭＡ ＤＭ環境においては、意思決定は通常ＤＭサーバのレベルでは行われず、ＭＡが意思決定を行って、それからＤＭサーバが行動を遂行することは理解されよう。ＵＥは、様々なＭＡとそれぞれのＤＭサーバを持つこともできる。例えば、携帯電話機が、無線通信ネットワーク運用業者のＭＡによって、その運用業者のＯＭＡ ＤＭサーバのいくつかを介して管理され、そして電話機ユーザの雇用者のＭＡによって、別のＯＭＡ ＤＭサーバを介して管理されることがあってもよい。運用業者は、その運用業者の通信ネットワークへの接続について責任を持って管理することができ、これには最も低廉なローミング設定のローミング・リストを維持することが含まれ、これは、ユーザがその運用業者に加入するのに有効である。雇用者は、そのデバイス上の全ての企業アプリケーションについて、責任を持って追跡し、管理することができる。電話機ユーザもまた、ＯＭＡ ＤＭサーバについては全く知ることなく、別のソフトウエアをデバイスにダウンロードしてインストールするよう決定してよい。

図２を参照すると、多数のアプリケーション２０１−１、・・・、２０１−ＮがＵＥ１０６中に存在する。アプリケーション２０１は、ソフトウエアコンポーネント（構成要素）２０３、例えば、ダイナミック・リンク・ライブラリ（ＤＬＬ）など、―より一般的には、特定のインタフェース識別子をサポートする任意のファイル―、をロードするよう、ＯＳ２０２、すなわち、アプリケーション管理部、に要求する。構成要素２０３がＵＥ１０６から消失した（これを点線で示す）場合、もしそのような要求が適用可能なセキュリティ・ポリシーによって許されるならば、ＯＳはＤＭクライアント２０４にリクエスト（要求）を送信し、ＤＭクライアント２０４が通信ネットワーク２１０中のＤＭサーバ１０４に要求を送信することができるようにする。ＤＭクライアント２０４は、その要求に、ＵＥのデバイス・タイプとモデル、バージョン、および場合によってはＵＥが使用するローカル言語に関する情報を含ませる。

ＤＭサーバ１０４は、そのＤＭサーバが問題を解決―例えば、消失した構成要素２０３を返答することにより―できるかどうかを決定するために、ＭＡ１０２に代わって設定情報を使用してもよい。ＤＭサーバ１０４がもっと多くの情報をＵＥ１０６から必要な場合、ＤＭサーバ１０４は、ＵＥ１０６にインストールされた全てのアプリケーションおよび構成要素についての、例えば、ＳＣｏＭＯクライアント２０５からの、一覧リストを求める要求を、ＤＭクライアント２０４に送信してもよい。ＤＭサーバ１０４が解決できる場合、ＤＭサーバ１０４は、消失した構成要素を提供する―例えば、正しいバージョンにアップグレードするまたは消失した構成要素２０３を新しくインストールする―ために、ＤＭクライアント２０４およびＳＣｏＭＯクライアント２０５を使用することができる。

この種の自動解決―すなわち、ユーザとの相互作用なしでの要求への対応―がＤＭサーバ１０４によってサポートされていない場合、ＤＭサーバ１０４は、ＤＭクライアント２０４を使用して、ＵＥ１０６のユーザに進め方について問い合わせることができる。それは、例えば、解決できないことをユーザに知らせることであってもよく、または、ＤＭサーバ１０４が、例えば、ユニフォーム・リソース・ローケータ（ＵＲＬ）アドレスなどのウェブ・リンクをユーザにプッシュして、ユーザが消失した構成要素２０３を購入しおよび／または人手でもってインストールできるようにすることもできよう。

ＤＭサーバ１０４が、消失した構成要素を自動的に更新またはインストールできる場合、ＤＭクライアント２０４またはＳＣｏＭＯクライアント２０５は、構成要素２０３がインストールされたことをＯＳ２０２に知らせることができる。その場合、ＯＳ２０２は、消失した構成要素２０３をどこで見つけるかを、すなわち、そのメモリ位置を、アプリケーション２０１に知らせることができる。この場合、当然のことながら、アプリケーション２０１は、アプリケーション２０１が構成要素２０３を要求したとき、ＵＥがそれを持っていなかったことを知る必要はない。

図３は、通信システムにおいてＵＥ１０６を動作させる、本発明に従う方法のフローチャートである。ＵＥは、好ましくは、例えば、エンドユーザがアプリケーションを開始しようとしたときに、ソフトウエア構成要素が消失したことを自ら決定する（工程３０２）。例えば、マイクロソフトのウインドウズ・モバイル環境では、アプリケーションの立上げ時に、そのアプリケーションの実行に必要な特定のＤＬＬをアプリケーションが要求してもよい。別の事例では、アプリケーションは、立上げ時に、必要な特定のアプリケーション・プログラム・インタフェース（ＡＰＩ）に出会うことを期待してもよい。ＤＬＬの類の構成要素は、バージョンが異なっていても同じ名前を持つことが多く、従って、新しいアプリケーションがインストールされるとき、構成要素の１つのバージョンが同じ名前を持つ別のバージョンで置き換えられることがあり得る。アプリケーションが成功裡に開始されなかったとＵＥが決定した場合、消失したソフトウエア構成要素を特定するのは通常はＯＳ２０２である。

構成要素が消失したと決定した場合、ＵＥ１０６は、システム中のサーバ―ＤＭサーバ１０４およびＭＡ１０２など―に要求を送り、構成要素（例えば、ＤＬＬ）が消失したことをサーバに知らせる。ＵＥが送った要求は、好ましくは、ＵＥ設定情報、例えば、ＵＥ製造業者、モデル、バージョン、オペレーティング・システムのタイプ、およびオペレーティング・システムのバージョンの少なくとも１つ、を含む。その要求に基づいて、サーバ１０４が、それ自らのみでかまたはＭＡ１０２と協働して、単純に、消失した構成要素をＵＥに提供できるようにしてもよい（工程３０６）。当然のことながら、要求の送信は適用可能なセキュリティ・ポリシーに依存し得る。

そのような要求は標準化されたプロトコルに従って行われるのが、これが必要というのではないが、一般には好ましい。標準化された要求をＵＥがＭＡ１０２に送信する１つの手法は、ＯＭＡ ＤＭを介して一般的な警報（Generic alert）機能を使用することである。一般的警報メッセージを介して、ＵＥ１０６は、ＭＡへのＯＭＡ ＤＭセッションを開始し、消失したファイルの名前およびそのファイルがＤＭサーバおよびＭＡに必要であることを送信することができる。

ＯＭＡ ＤＭ環境では、ＤＭサーバ１０４は追加情報―これは、ＵＥ１０６中に存在する幾つかのまたは全てのソフトウエア構成要素の一覧リストを含んでもよい―を取得する必要があってもよい。例えば、ＤＭサーバ１０４は、ＯＭＡ ＳＣｏＭＯ―これは、一般に、ＭＡ１０２がＵＥ１０６中のソフトウエアを管理し、追加情報を求める要求をＵＥ１０６に送信する（工程３０８）ことを可能にする―を使用することができる。ＳＣｏＭＯは、ＵＥに存在する全てのインストールされたアプリケーションおよび構成要素のリストを、ＤＭサーバが取得することができる手法の一例である。ＤＭ ＭＡ１０２は、その情報に基づいて、要求がサポートされるかどうか、およびファイルをエンドユーザおよびデバイスに提供するためにどのような可能性があるかを決定することができる（工程３１０）が、これは、ＵＥのセキュリティ・ポリシー、業務契約、加入プロビジョン、等にも依存する。

以上に説明されたように、リストは、インストールされたソフトウエア構成要素およびそれらのバージョンについての識別情報―識別子、名前、バージョン、状態、およびＵＥ中に存在する全ての構成要素の状態を含む―を含むことができる。当然のことながら、それらの情報はＳＣｏＭＯ以外のメカニズムを介して取得することもでき、例えば、ＵＥのファイル・システム中の全ての存在するファイルのダンプとして、またはＪａｖａ(登録商標)仕様要求（ＪＳＲ、Java Specification Request(登録商標)）またはオープン・サービス・ゲートウェイ・イニシアティブ（ＯＳＣｉ、Open Service Gateway Initiative）仕様を介して取得することができる。以下に説明するように、ＯＳＧｉおよびＪＳＲ−２３２は機能的にＯＭＡ ＳＣｏＭＯに非常に似ており、この応用を目的として相互に交換可能である。

サーバまたはＭＡは、それ自らが、消失した構成要素をＵＥ１０６に提供することができる、またはＵＥのエンドユーザはそれを先ず購入する必要があるかもしれない。例えば、消失したリソースを回復することは全く不可能でさえあってもよく、エンドユーザは、ＵＥまたはアプリケーションがサポートされなくなった旨を、そして新しいデバイスまたはアプリケーションを購入すべき旨を、適当な情報メッセージを介して通知されてもよい。消失したリソースまたはアップグレードをサーバ／ＭＡが有している場合、それはオンラインで直接そして途切れなくＵＥに提供され、エンドユーザはアプリケーションの開始の遅れを感知するだけかもしれない。あるいは、消失した構成要素が提供される前に、エンドユーザは先ず許可を求められてもよく、またはＵＥはアプリケーションの開始に失敗するかもしれないが、消失した構成要素を要求してインストールし、それからエンドユーザがアプリケーションを再開始できてもよい。例えば、ＵＥにウェブサイトへのリンク―エンドユーザがウェブブラウザを介してそれにアクセスし、必要なソフトウエア構成要素をインストールできる―が送信されてもよい。

ＵＥは、ソフトウエア構成要素が消失した旨の要求を送信するための許可をエンドユーザに求めてもよい。エンドユーザが要求を通知されるべきか、要求を送信する許可を求められるべきか、または全く通知されないかを、セキュリティ・ポリシーが規定してもよい。例えば、企業環境中で提供されたＵＥのエンドユーザは、例えば、ＵＥのアンチウイルス構成要素を更新する必要がある場合は全く通知されないかもしれないが、運用業者が固定されていないＵＥは、おそらく、運用業者がＤＭサーバまたはＭＡなどのサーバに要求を送信しようとする前に、エンドユーザの許可を先ず要求するであろう。アプリケーションの立上げ時にソフトウエア構成要素が消失したとＵＥ１０６が決定したとき、自動要求（すなわち、エンドユーザの許可を求めない要求）がなされるべきか、どのようにしてエンドユーザは要求を（とにかく）知らせられるべきか、そして最後に、ＵＥはどのＭＡへの要求送信を許可されるかを決定するために、ＵＥはローカル・セキュリティ・ポリシーを読み出そうとするであろう。ＵＥは幾つかのＭＡによって管理されてもよいが、それらの内の１つだけまたは少数が、要求を受信することを許可してもよい。

ＯＭＡ ＤＭ環境では、ＤＭクライアント２０４、すなわち、ＵＥ１０６中のＤＭ管理エンティティ（ＭＥ）、は、エンドユーザとのセキュリティ許可の相互作用を処理することができよう。例えば、ＭＥはＵＥのユーザ・インタフェース（ＵＩ）を介して、「あなたが開始したアプリケーションは構成要素が失われています。それを自動的にダウンロードしてもよいですか（Ｙ／Ｎ）？」などの、問題を提示してもよい。例えば、適当な警報に対してエンドユーザが打鍵またはその他の動作で応答することによりダウンロードの許可を選ぶと、ＵＥ１０６はＭＡ１０２に通知要求を送信する。この要求は、消失したソフトウエア構成要素を特定してもよく、オプションとしてバージョンを特定するための情報およびオプションとして言語を特定するための情報を含んでもよい。

例えば、消失したソフトウエア構成要素に経費が掛かる場合、ＭＡ１０２は、ＯＭＡ ＤＭユーザ相互作用コマンドを使用して、消失したファイルの購入を彼／彼女が所望するかを、エンドユーザに尋ねてもよいであろう。多言語をサポートするＵＥについては、ＭＡは、エンドユーザが既定言語（default language）として設定した言語で質問ができるべきであろう。さらに、消失した構成要素にはＵＩ構成要素が含まれてもよく、そのため、ＭＡは消失した構成要素をＵＥの既定言語で配信するのがよいであろう。

ＵＥの要求に応答するどのイベントにおいても、ＤＭサーバ１０４および／またはＭＡ１０２などのサーバは、可能ならば、消失したソフトウエア構成要素を提供する（工程３０６）ことによりＵＥ１０６を設定する。消失した構成要素は、例えば、ＯＭＡ ＤＭ ＳＣｏＭＯを介するなど、任意の適切な手法で提供されてよい。使用可能なもう１つの配信メカニズムがＪａｖａ（登録商標）仕様要求（ＪＳＲ）ＪＳＲ−２３２で既定されており、これは、ＯＴＡプロトコルに対してＯＭＡ ＤＭを使用することを述べている。ＪＳＲ−２３２は、ＯＭＡ ＤＭ ＳＣｏＭＯ仕様が公開される前に仕様化されたと理解されようが、ＪＳＲ−２３２はＳＣｏＭＯ仕様の事前公開バージョンを使用している。当業者には理解できるように、ＳＣｏＭＯおよびＪＳＲ−２３２仕様とは別の手法で、消失したソフトウエアへの要求を適切に規定することも可能である。

さらに、消失したソフトウエアへの要求が、ＯＭＡ ＤＭ ＳＣｏＭＯまたはＪＳＲ−２３２もしくはそれらとは別途に規定されているかどうかとは独立に、その要求をＯＭＡ ＤＭ一般的警報として規定することができる。ＭＥはＯＭＡ ＤＭセッションを開始し、そのような消失ソフトウエア一般的警報を送信する。ＤＭサーバ１０４はそこでその要求を処理する方法を決定するであろう。ＤＭサーバ１０４は、消失したソフトウエア構成要素のインストールを開始するために、例えば、ＯＭＡ ＤＭ ＳＣｏＭＯかまたはＪＳＲ−２３２かを使用できよう。

消失したソフトウエアの適切なＯＭＡ ＤＭ一般的警報メッセージの事例的な定義は以下のようになる。すなわち、

図４は、本願で説明されたような、消失したソフトウエアのダウンロードを要求可能なＵＥを使用できる通信システムのブロック図である。ＵＥが、ＩＥＥＥ８０２．１１、ＷｉＭＡＸ（ＩＥＥＥ８０２．１６）などの無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を介してインターネットなどの通信ネットワークに接続されてもよく、そして図４に示されるブロックに加えて、ＵＥが３ＧＰＰと相互作用するＷＬＡＮとを使用してもよいことが理解されよう。ＵＥ１０６は、通信ネットワーク２１０と通信するが、これは、通常、ＧＳＭ／ＥＤＧＥネットワークなどの無線アクセス・ネットワーク（ＲＡＮ）４０４およびコア・ネットワークのエンティティ―これには、在圏ＧＰＲＳサポート・ノード（ＳＧＳＮ）４０６、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）４０８、およびホーム・ロケーション・レジスタ（ＨＬＲ）４１０が含まれる―を含む。ＧＧＳＮ４０８は、インターネットおよび公衆交換電話ネットワークなど、他の通信ネットワーク、および、ＷＡＰインフラストラクチャ４１２など、他のエンティティと通信する。ＲＡＮ４０４は、通常、１つ以上の基地局（ＢＳ）および基地局制御装置、すなわち、ノードＢおよび無線ネットワーク制御装置（ＲＮＣ、radio network controller）、を備え、それらは従来型である。ＲＮＣは、例えば、無線アクセス・ベアラ設定、ＢＳ間のダイバーシティ・ハンドオーバを含む、様々な無線ネットワーク機能を制御する。より一般的には、各ＲＮＣはＵＥへのまたはＵＥからの呼を適当なＢＳ―これは、ダウンリンク（すなわち、基地局から移動機に向かう、または順方向の）およびアップリンク（すなわち、移動機から基地局に向かう、または逆方向の）のチャンネルを通して相互に通信する―を介して管理する。各ＢＳは、地理的な領域にサービスするが、それらの領域は、１つ以上のセルに分割され、通常、専用の電話回線、光ファイバ・リンク、マイクロウェーブ・リンク等でそれに対応するＲＮＣに結ばれる。コア・ネットワーク・エンティティは、多くのタイプのデータを処理するように構成される。通常のＧＳＭ／ＥＤＧＥネットワークでは、ＧＧＳＮ４０８において、データ・フローを管理するためのパケット・データ・プロトコル（ＰＤＰ）コンテキストが、ＵＥ１０６からの要求に応えて設定、すなわち活性化、される。ＵＥはまた、無線ローカル・エリア・ネットワークへのアクセスを介して、通信ネットワークに接続することもできることが理解されよう。

図５は、通信デバイス１０６のブロック図であり、ＲＡＮ４０４中のＢＳと無線信号を交換するのに適した送受信機５０２を備える。それらの信号によって運ばれる情報はプロセッサ５０４によって処理されるが、これは、１つ以上のサブプロセッサを備えてもよく、以上で説明したＭＯに従ってデバイス１０６の動作を遂行するために、１つ以上のソフトウエア・アプリケーションを実行する。端末へのユーザ入力は、キーボード５０６またはその他のデバイスを通して与えられる。ソフトウエア・アプリケーションは適当なアプリケーション・メモリ５０８に格納されてもよく、そのデバイスはまた、適当なメモリ５１０中の所望の情報をダウンロードおよび／またはキャッシュ（cache）してもよい。デバイス１０６はまた、コンピュータ、キーボードなど、他の構成要素をデバイス１０６に接続するのに使用可能なインタフェース５１２を備える。

本発明は多くの利点を持つ。例えば、今日、ＵＥの消失したソフトウエア構成要素の問題に対する標準化された解法は他には存在しない。さらに、例えば、実現上の変化のインパクトを最小化するために、既存の標準仕様を使用してもよい。

本明細書で説明した発明は、適当な命令のセット―これは、コンピュータ・ベースのシステム、プロセッサ内蔵システム、または媒体から命令をフェッチしてその命令を実行することができるその他のシステムなど、命令実行システム、装置、またはデバイスによって、またはそれと結合して、使用される―を格納した任意の形式のコンピュータ可読型記憶媒体内において、完全に具体化されると考えることができる。本明細書での使用では、「コンピュータ可読型媒体」は、命令実行システム、装置、またはデバイスによって、またはそれと結合して、使用するための、プログラムを装備、格納、通信、伝搬または転送することができる任意の手段であってよい。コンピュータ可読型媒体は、例えば、電子的、磁気的、光学的、電磁気的、赤外、または半導体システム、装置、デバイスまたは伝搬媒体であることができるが、それらに限定されるものではない。コンピュータ可読型媒体のより詳細な例（網羅的なリストではないが）は、１つ以上の結線を含む電気的な接続、可搬型コンピュータ・ディスケット、ＲＡＭ、ＲＯＭ、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、および光ファイバを含む。

本発明は、例えば、移動通信デバイスを含む多様な環境において実施可能であることが期待される。以上で説明された手順は、必要に応じて繰り返し実行されることも理解されよう。理解を容易にするために、本発明の態様は、例えば、プログラム可能なコンピュータ・システムの要素によって実行することができる、動作の順序によって説明されている。特有の回路（例えば、特別の機能を実行するように相互接続された個別論理ゲート、または特定用途向け集積回路）により、１つ以上のプロセッサで実行されるプログラム命令により、または両者の組合せにより、多様な動作を実行できるであろうことが理解されよう。

以上に述べたように、本発明は、多くの異なる形式―必ずしもその全てについて以上で説明はしていないが―で具体化されてもよく、全てのそのような形式は本発明の範囲に含まれると思量するものである。本発明の多様な態様の各々について、任意のそのような形式は、説明の動作を実行する「ように構成された論理」、または別案として、説明の動作を実行する「ところの論理」と呼ばれてもよい。用語「含む」および「備える」は、本出願での使用では、述べられた特徴、整数、工程、または構成要素が存在することを指定するものであり、その他の１つ以上の特徴、整数、工程、構成要素またはそれらのグループの存在または付加を排除するものではないことに重々留意されたい。

以上で説明した個々の実施形態は、単に説明のためのものであって、いかなる手法であれ限定するものとは考えないようにされたい。本発明の範囲は、添付の特許の範囲によって決定されるものであり、特許の範囲に帰着する全ての派生形および等価案は本発明に包含されることを意図するものである。

ＤＭ管理オーソリティ、ＤＭサーバ及びユーザ装置の動作例を示した図である。 ユーザ装置のソフトウエア構成例を示した図である。 通信システムにおいてＵＥ１０６を動作させる、本発明に従う方法のフローチャートである。 本願で説明されたような、消失したソフトウエアのダウンロードを要求可能なＵＥを使用できる通信システムのブロック図である。 通信デバイス１０６のブロック図である。

Claims (17)

1. コンピュータ・サーバを含む通信システムにおいてユーザ装置を動作させる方法であって、
   前記ユーザ装置が、特定のインタフェース識別子をサポートしているソフトウエアコンポーネントを使用するアプリケーションが成功裡に起動していないことを判定するとともに、該ユーザ装置から消失した該ソフトウエアコンポーネントを識別するステップと、
   前記ユーザ装置から消失したソフトウエアコンポーネントが識別されると、
   オペレーティングシステムまたはアプリケーションマネージャが、前記ユーザ装置のクライアントに対して内部リクエストを送信するステップと、
   前記クライアントが、前記消失したソフトウエアコンポーネントを要求するための第１のリクエストを前記コンピュータ・サーバに送信するステップと、
   前記第１のリクエストにしたがって前記ソフトウエアコンポーネントを取得してインストールするステップと
   を含むことを特徴とする方法。
2. 前記第１のリクエストには、前記ユーザ装置についての設定情報が含まれ、
   前記設定情報には、前記ユーザ装置を製造した製造業者、前記ユーザ装置のモデル名、前記ユーザ装置のバージョン、前記ユーザ装置のオペレーティングシステムのタイプ、及び、該オペレーティングシステムのバージョンのうち少なくとも１つの情報が含まれている
   ことを特徴とする請求項１に記載の方法。
3. 前記ユーザ装置に対して追加の情報を要求するための第２のリクエストを送信するステップをさらに含み、
   前記追加の情報には、前記ユーザ装置に存在している複数のソフトウエアコンポーネントについてのリストが含まれている
   ことを特徴とする請求項１に記載の方法。
4. 前記リストには、前記ユーザ装置に存在している複数のソフトウエアコンポーネントについての識別情報及びバージョン情報が含まれており、
   前記コンピュータ・サーバは、デバイス管理（ＤＭ）サーバである
   ことを特徴とする請求項３に記載の方法。
5. 少なくとも前記追加の情報に基づいて、前記複数のソフトウエアコンポーネントのうちの少なくとも１つのソフトウエアコンポーネントを前記ユーザ装置へ供給するか否かを決定するステップをさらに含む
   ことを特徴とする請求項３に記載の方法。
6. 前記デバイス管理（ＤＭ）サーバは、セキュリティーポリシーにしたがって前記リストの取得を許可するか否かを決定するステップをさらに含む
   ことを特徴とする請求項４に記載の方法。
7. 前記少なくとも１つのソフトウエアコンポーネントを前記ユーザ装置へ供給するか否かの決定に従って、前記ユーザ装置に対してソフトウエアコンポーネントを供給するステップをさらに含む
   ことを特徴とする請求項５に記載の方法。
8. 前記少なくとも１つのソフトウエアコンポーネントを前記ユーザ装置へ供給するか否かを決定するステップは、管理オーソリティ及びデバイス管理サーバが実行する
   ことを特徴とする請求項５に記載の方法。
9. 前記第１のリクエストを送信するステップは、前記ソフトウエアコンポーネントが消失した旨を管理オーソリティに対して通知するステップを含む
   ことを特徴とする請求項３に記載の方法。
10. 前記ユーザ装置に対して供給すべき少なくとも１つのソフトウエアコンポーネントを前記管理オーソリティが決定するステップを含む
    ことを特徴とする請求項９に記載の方法。
11. 通信システムであって、
    コンピュータ・サーバと、
    ユーザ装置と
    を備え、
    前記ユーザ装置は、前記コンピュータ・サーバを選択して通信するとともに、該ユーザ装置内に存在している複数のソフトウエアコンポーネントを実行するように構成されたプロセッサを備えており、
    前記ユーザ装置は、特定のインタフェース識別子をサポートしているソフトウエアコンポーネントを使用するアプリケーションが成功裡に起動していないことを判定するとともに、該ユーザ装置から消失した該ソフトウエアコンポーネントを前記プロセッサが識別すると、オペレーティングシステムまたはアプリケーションマネージャによって前記ユーザ装置のクライアントに対して内部リクエストを送信し、該クライアントによって該消失したソフトウエアコンポーネントを提供するよう前記コンピュータ・サーバに要求するための第１のリクエストを送信し、該ソフトウエアコンポーネントを取得してインストールするように構成されており、
    前記コンピュータ・サーバは、前記第１のリクエストに基づいて、前記ユーザ装置に対して少なくとも１つのソフトウエアコンポーネントを提供することを決定するように構成されている
    ことを特徴とする通信システム。
12. 前記第１のリクエストには、前記ユーザ装置についての設定情報が含まれ、
    前記設定情報には、前記ユーザ装置を製造した製造業者、前記ユーザ装置のモデル名、前記ユーザ装置のバージョン、前記ユーザ装置のオペレーティングシステムのタイプ、及び、該オペレーティングシステムのバージョンのうち少なくとも１つの情報が含まれている
    ことを特徴とする請求項１１に記載の通信システム。
13. 前記コンピュータ・サーバは、前記ユーザ装置に対して追加の情報を送信するよう要求するための第２のリクエストを送信するように構成されており、
    前記追加の情報には、前記ユーザ装置に存在している複数のソフトウエアコンポーネントについてのリストが含まれている
    ことを特徴とする請求項１１に記載の通信システム。
14. 前記リストには、前記ユーザ装置に存在している複数のソフトウエアコンポーネントについての識別情報及びバージョン情報が含まれている
    ことを特徴とする請求項１３に記載の通信システム。
15. 前記コンピュータ・サーバは、管理オーソリティ又はデバイス管理サーバの少なくとも一方である
    ことを特徴とする請求項１３に記載の通信システム。
16. 前記管理オーソリティ又は前記デバイス管理サーバの少なくとも一方である前記コンピュータ・サーバは、少なくとも前記追加の情報にしたがって、前記消失したと判定されたソフトウエアコンポーネントを前記ユーザ装置に対して提供するよう構成されている
    ことを特徴とする請求項１５に記載の通信システム。
17. 前記消失したと判定されたソフトウエアコンポーネントは、セキュリティーポリシーにしたがって提供される
    ことを特徴とする請求項１６に記載の通信システム。

Images