JP2011123570A - 情報処理装置、サーバ装置、配布システム、受信方法、プログラムモジュール提供方法 - Google Patents

Abstract

【課題】ＯＳＧｉのサービス化、及び受信したバンドルの区分を実現することができる情報処理装置、サーバ装置、配布システム、受信方法、プログラムモジュール提供方法を提供する。
【解決手段】ＯＳＧｉフレームワークを内部ロジック部分としてのサービス側（２１２）と、ＧＵＩとしてのアプリケーション側（２２２）との２つに分け、それぞれ別個に稼働させ、サービス側（２１２）の管理バンドル（２１４）によってバンドルの配布を受信し、受信したバンドルを分別して保存する。
【選択図】図２

Description

本発明は、ＯＳＧｉフレームワークに稼働するプログラムモジュールであるバンドルの配布を受信する情報処理装置、受信方法、プログラムモジュールを配布するサーバ装置、配布システム、及びプログラムモジュール提供方法に関する。

ＯＳＧｉサービスプラットフォームは、ＷＡＮからＬＡＮやデバイスに様々なサービスを配信する標準規格の策定を目的として設立されたＯＳＧｉ（Open Services Gateway Initiative）が提唱する規格である。この規格では、Ｊａｖａ（登録商標）仮想マシン（以下、ＪａｖａＶＭという）上のフレームワークにより、様々なサービスの配信と実行の環境の提供を実現している。

このＯＳＧｉサービスプラットフォームでは、サービスを提供するアプリケーション等はバンドルと呼ばれる。ＯＳＧｉフレームワークは、このようなバンドルのインストール、アップデート、アンインストール、スタート、ストップを管理、制御するＬＣＭ（Life Cycle Management）として総称される機能を備えている。

このＯＳＧｉフレームワークでは、ある特定のサービスを利用するときに、用意されたバンドルをダウンロードして取り込むことで様々な装置やアプリケーションの利用あるいは制御が可能となる。

「OSGi Service Platform, Release4」, http://www.osgi.org/ Download/Release4V40 , 2005年10月

ＯＳＧｉフレームワークを含むＪａｖａプロセスを、オペレーティングシステム（ＯＳ）のサービスプロセス（又はデーモンプロセス）として稼働させる場合はＧＵＩの扱いが問題となる。サービスプロセスでは通常、ＯＳへのログインユーザのデスクトップ上にＧＵＩを表示することができないためである。

本発明は、斯かる事情に鑑みてなされたものであり、主たる目的は、ＯＳＧｉのサービス化、及び受信したプログラムモジュールの区分を実現することができる情報処理装置、受信方法、サーバ装置、配布システム、及びプログラムモジュール提供方法を提供することを目的とする。

本発明の情報処理装置は、演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるようにしてある情報処理装置において、前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能し、前記第１の管理手段は、プログラムモジュールを受信し、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成してあることを特徴とする。

また、本発明の情報処理装置は、前記第１の管理手段は、プログラムモジュールを受信したことを前記第２の管理手段に通知する機能を有することを特徴とする。

また、本発明の情報処理装置は、前記第１及び第２の管理手段は、それぞれ前記第１及び第２のフレームワークにプログラムモジュールをインストール又は更新する機能を有することを特徴とする。

また、本発明の情報処理装置は、前記第２の管理手段は、プログラムモジュール更新情報の通知に係る指示を受付ける機能と、自フレームワークで更新したプログラムモジュールに係る情報を収集する機能と、前記第１のフレームワークで更新したプログラムモジュールに係る情報を、前記第１の管理手段へ要求し、該第１の管理手段から受信する機能と、前記第１及び第２のフレームワークで更新したプログラムモジュールに係る情報を通知する機能とを有し、前記第１の管理手段は、自フレームワークで更新したプログラムモジュールに係る情報を収集して前記第２の管理手段へ送信する機能を有することを特徴とする。

また、本発明の情報処理装置は、前記第２の管理手段は、前記プログラムモジュール更新の通知が完了したことを前記第１の管理手段へ送信する機能を有し、前記第１の管理手段は、受信した通知の完了をサーバ装置に送信する機能を有することを特徴とする。

また、本発明の情報処理装置は、前記第１の管理手段は、プログラムモジュールに含む該プログラムモジュールを識別するための識別情報、又はサーバ装置から受信した前記識別情報に基づいて、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成されていることを特徴とする。

また、本発明の情報処理装置は、前記プログラムモジュールはＯＳＧｉフレームワークで稼働するバンドルであり、前記第１の管理手段は、受信したプログラムモジュールをそれぞれのＭＡＮＩＦＥＳＴファイルに基づいて分別して保存するように構成されていることを特徴とする。

本発明のサーバ装置は、プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、外部に提供するように構成してあることを特徴とする。

本発明の配布システムは、サーバ装置、及び該サーバ装置と通信可能に接続されているクライアント装置を含み、前記サーバ装置から前記クライアント装置へプログラムモジュールを配布する配布システムにおいて、前記サーバ装置は、プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、配布するように構成しており、前記クライアント装置は、演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるように構成しており、前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能し、前記第１の管理手段は、外部から配布されるプログラムモジュールを受信し、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成してあることを特徴とする。

本発明の受信方法は、演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるようにしており、前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能する情報処理装置に、プログラムモジュールを受信する方法であって、前記第１の管理手段が、プログラムモジュールを受信するステップと、前記第１の管理手段が、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するステップとを含むことを特徴とする。

本発明のプログラムモジュール提供方法は、プログラムモジュールを提供するサーバ装置によってプログラムモジュールを外部に提供する方法において、プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、外部に提供するステップを備えることを特徴とする。

本発明では、第１及び第２の管理手段は、異なるフレームワーク上で稼働し、かつお互いに通信可能に構成される。第１の管理手段は、サーバ装置から配布されるプログラムモジュールを受信し、受信したプログラムモジュールをそれぞれ第１又は第２のフレームワーク用のプログラムモジュールに分別して保存する。これにより、クライアントとなる情報処理装置は、サーバ装置から配布したプログラムモジュールを受信した場合、プログラムモジュールを異なる仮想マシンに振り分け、それぞれ適切にインストールすることができる。

本発明では、第１の管理手段は、プログラムモジュールを受信したことを第２の管理手段に通知する。これにより、第２の管理手段がプログラムモジュールの更新を検知することが可能である。

本発明では、クライアントとなる情報処理装置は、サーバ装置からプログラムモジュールを受信した場合、第１及び第２の管理手段によってインストール又は更新することができる。

本発明では、第１及び第２の管理手段によってプログラムモジュールの更新情報を収集して、第１の管理手段によって更新情報をユーザに通知する。これにより、ユーザはプログラムモジュールを利用できるようになったことを知ることができる。

本発明では、前記プログラムモジュール更新情報の通知が完了したことをサーバ装置に通知することができる。

本発明では、第１の管理手段は、プログラムモジュールに含まれる識別情報、又は前記サーバ装置から受信した識別情報に基づいて、受信したプログラムモジュールを分別して保存する。これにより、プログラムモジュールは適切に分別される。

本発明では、第１の管理手段は、プログラムモジュールが含んでいるＭＡＮＩＦＥＳＴファイルに基づいてプログラムモジュールを分別して保存する。

本発明によれば、ＯＳＧｉのサービス化、及び受信したプログラムモジュール（バンドル）の適切な区分を実現することができ、複数の仮想マシンにそれぞれ稼働している複数のＯＳＧｉフレームワークを有する情報処理装置においても、受信したバンドルを分別して適切に保存することができる。

本発明の実施の形態に係るバンドル配布システムの構成を示すブロック図である。 本発明の実施の形態に係るバンドル配布システムの機能構成を示すブロック図である。 本発明の実施の形態に係る管理サーバが実行するバンドル配布処理の手順の一例を示すフローチャートである。 本発明の実施の形態に係るクライアント端末が実行するバンドル受信処理の手順の一例を示すフローチャートである。 本発明の実施の形態に係るクライアント端末が実行するバンドル受信処理の手順の一例を示すフローチャートである。 本発明の実施の形態に係るバンドル配布システムの機能構成を示すブロック図である。 本発明の実施の形態に係るバンドル配布システムの機能構成を示すブロック図である。 本発明の実施の形態に係るクライアント端末が受信したバンドル更新情報をユーザに通知する処理を示すフローチャートである。 クライアント端末の表示部に表示されるバンドル更新情報の通知に係る画面例を示す模式図である。

以下に、本発明をその実施の形態を示す図面に基づいて詳述する。
図１は、本発明の実施の形態に係るバンドル配布システムの構成を示すブロック図である。図示するように、本実施の形態に係るバンドル配布システムは、プログラムモジュールなどのソフトウェアリソースを配布する管理サーバ１と、複数のクライアント端末２，２...と、管理サーバ１及び複数のクライアント端末２，２...を接続するネットワーク３とを含む。複数のクライアント端末２，２...は、管理サーバ１から配布したソフトウェアリソースをネットワーク３を介して受信する。クライアント端末２は、有線によりネットワーク３に接続するものであっでもよいし、アクセスポイントＡＰを介して無線によりネットワーク３に接続するものであっでも良い。

管理サーバ１は、サーバコンピュータを用い、ＣＰＵ（Central Processing Unit）１０と、ＨＤ（Hard Disk）１１と、ＲＡＭ（Random Access Memory）１２と、通信部１３とを含む。

ＣＰＵ１０は、ＨＤ１１に記憶されている後述のオペレーティングシステム、ＪａｖａＶＭ、サーバコンピュータを管理サーバ１として動作させるためのサーバプログラムなどのサーバプログラム１ＰをＲＡＭ１２に読み出して実行することにより、後述にて説明する特有の機能を実現する。

ＨＤ１１には、上述のように各種のコンピュータプログラムを記憶しているほか、ＣＰＵ１０が処理のために参照するデータが記憶されていてもよい。ＲＡＭ１２には、ＣＰＵ１０が上述のように各種コンピュータプログラムを実行する際に展開されたコードが記憶される。

通信部１３は、ネットワーク３のプロトコルに応じた通信を実現するネットワークコントローラ機能を実現する。ＣＰＵ１０は、通信部１３により、情報をパケット化して送信し、ネットワーク３を介して受信されるパケットから情報を抽出することが可能である。

クライアント端末２は、パーソナルコンピュータや携帯電話などを用いることができ、ＣＰＵ２０と、ＨＤ２１と、ＲＡＭ２２と、通信部２３とを含む。ＨＤ２１の代わりにフラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）を用いても良い。

ＣＰＵ２０は、ＨＤ２１に記憶されている後述のオペレーティングシステム、ＪａｖａＶＭ、パーソナルコンピュータをクライアント端末２として動作させるためのクライアントプログラムなどのクライアントプログラム２ＰをＲＡＭ２２に読み出して実行することにより、後述にて説明する特有の機能を実現する。

ＨＤ２１には、上述のように各種のコンピュータプログラムを記憶しているほか、ＣＰＵ２０が処理に参照するデータが記憶されていてもよい。ＲＡＭ２２には、ＣＰＵ２０が上述のように各種コンピュータプログラムを実行する際に展開されたコードが記憶される。

通信部２３は、ネットワーク３のプロトコルに応じた通信を実現するネットワークコントローラ機能を実現する。ＣＰＵ２０は、通信部２３により、情報をパケット化して送信し、ネットワーク３を介して受信されるパケットから情報を抽出することが可能である。

図２は本実施の形態に係るバンドル配布システムの機能構成を示すブロック図である。管理サーバ１及びクライアント端末２それぞれのＣＰＵ１０、２０は、コンピュータプログラムを読み出して実行することにより、図２に示すような各機能ブロックを実現する。

図２に示すように、管理サーバ１は、機能的には、サーバ側オペレーティングシステム（ＯＳ）１０１と、サーバ側ＯＳ１０１上で稼働するサーバ側ＪａｖａＶＭ１０２と、サーバ側ＪａｖａＶＭ１０２上に実装されたＯＳＧｉに従ったフレームワークであるサーバ側ＯＳＧｉ１０３と、サーバ側ＯＳＧｉ１０３に実装されてさまざまな機能を提供するプログラムとして動作するサーバ側バンドル１０４と、サーバ側ＯＳＧｉ１０３に実装されて前記バンドル１０４を管理する管理バンドルとして動作するサーバ側ＭＡＦ（マルチエージェントフレームワーク）１０５とを備える。また、管理サーバ１は、該管理サーバ１と接続されているクライアント端末２へ配布するソフトウェアリソースとして、複数のバンドルからなるバンドル群１０６を有する。

クライアント端末２は、機能的には、クライアント端末側オペレーティングシステム（ＯＳ）２００と、クライアント端末側ＯＳ２００上で稼働するサービス側ＪａｖａＶＭ２１１によるサービス側ＶＭシステム２０１と、クライアント端末側ＯＳ２００上で稼働するサービス側ＪａｖａＶＭ２２１によるアプリケーション側（以下、アプリ側と呼ぶ）ＶＭシステム２０２とを備える。サービス側ＶＭシステム２０１では、サービス側ＪａｖａＶＭ２１１上に実装されたＯＳＧｉに従ったフレームワークであるサービス側ＯＳＧｉ２１２と、サービス側ＯＳＧｉ２１２に実装されて動作するサービス側バンドル２１３と、サービス側ＯＳＧｉ２１２に実装されて前記サービス側バンドル２１３を管理する管理バンドルとして動作するサービス側ＭＡＦ２１４とを備える。アプリ側ＶＭシステム２０２では、アプリ側ＪａｖａＶＭ２２１上に実装されたＯＳＧｉに従ったフレームワークであるアプリ側ＯＳＧｉ２２２と、アプリ側ＯＳＧｉ２２２に実装されて動作するアプリ側バンドル２２３と、アプリ側ＯＳＧｉ２２２に実装されて前記アプリ側バンドル２１３を管理する管理バンドルとして動作するアプリ側ＭＡＦ２２４とを備える。

本実施の形態では、バンドル（サーバ側バンドル１０４、サービス側バンドル２１３、アプリ側バンドル２２３）は、ＯＳＧｉフレームワークにインストールされ、Ｊａｖａアプリケーションの動的な入れ替えを行うための単位となるものである。通常、バンドルはＪＡＲファイルとして提供され、Ｊａｖａアプリケーションはこのバンドルに入れられている。

なお、ここでは、管理サーバ１はバンドルをソフトウェアリソースとしてクライアント端末２へ配布する例を挙げて説明するが、これに限らない。管理サーバ１はバンドル、フラグメントバンドル（OSGi Core.「3.14 Fragment Bundles」）、ディプロイメントパッケージ （OSGi Cmpn.「114 Deployment Admin Specification」）、及びファイルなどのソフトウェアリソースも配布することができる。

また、バンドルは、メタ情報を記述したテキストファイルである「ＭＡＮＩＦＥＳＴファイル」をＪＡＲファイル内に含んでおり、該ＭＡＮＩＦＥＳＴファイルの情報で管理サーバ１及びクライアント端末２からバンドルを識別することが可能である。管理サーバ１からクライアント端末２に配布するバンドルのＭＡＮＩＦＥＳＴファイルでは、各バンドルをサービス側又はアプリ側のいずれのＯＳＧｉフレームワーク上で動作させるかを指定する指定情報も含む。

本実施の形態ではＭＡＦのサービス化のために、各クライアント端末２上のＯＳＧｉフレームワークは、サービスとして実行されるものであるサービス側ＯＳＧｉ２１２（即ち内部ロジック側のＯＳＧｉフレームワーク）と、アプリケーションとして実行されるものであるアプリ側ＯＳＧｉ２２２（即ちＧＵＩ側のＯＳＧｉフレームワーク）との、計２つに分かれている。ＯＳＧｉフレームワークをサービス側とアプリケーション側との２つに分ける場合、ＯＳＧｉフレームワークにインストールされるバンドルもサービス側とアプリケーション側との２つのバンドル群に分ける。なお、バンドルを分けるとき、クラス間の依存性が複雑になることが予想されるので、各バンドルに含めるパッケージの構成については、ＧＵＩ表示を行うクラスを含むパッケージ以外のすべてのパッケージを両バンドルに含め、ＧＵＩ表示を行うクラスを含むパッケージは、ＧＵＩ側のバンドルにのみ含んでもよい。

分けられた各バンドルをどちらのＯＳＧｉフレームワーク上で動作させるかを指定するため、例えばクライアント端末２側のインストールフォルダの構成は以下のとおりとする。

<MAF_HOME> // クライアント端末側のインストールフォルダ
├service // サービス側ＯＳＧｉフレームワークの実行フォルダ
│ ├bundles
│ └configuration
└application // アプリケーション側ＯＳＧｉフレームワークの実行フォルダ
├bundles
└configuration

上述のように構成される配布システムにおいて、管理サーバ１からクライアント端末２へバンドルを配布する処理手順を、フローチャートを参照して説明する。図３は本実施の形態に係る管理サーバ１が実行するバンドル配布処理の手順の一例を示すフローチャートである。図４、図５は本実施の形態に係るクライアント端末２が実行するバンドル受信処理の手順の一例を示すフローチャートである。

管理サーバ１は、動作しているとき、ネットワーク３を介してクライアント端末２と通信可能に接続されている。管理サーバ１のサーバ側ＭＡＦ１０５は、図３に示すように、クライアント端末２から出力される端末情報を受信したか否かを判断する（ステップＳ１０）。サーバ側ＭＡＦ１０５は、クライアント端末２から端末情報を受信していないと判断した場合（ステップＳ１０：ＮＯ）、そのまま処理を終了する。クライアント端末２から端末情報を受信したと判断した場合（ステップＳ１０：ＹＥＳ）、ステップＳ１１へ進む。

サーバ側ＭＡＦ１０５は、受信した端末情報からクライアント端末２のバンドル情報を抽出し、抽出したバンドル情報と配布するソフトウェアリソースとして保持しているバンドル群１０６に係る情報とを比較する（ステップＳ１１）。サーバ側ＭＡＦ１０５は、例えば、保持しているバンドル群１０６にクライアント端末２が有さないバンドルを含んでいるか否か、即ちバンドル群１０６に更新するバンドルを含んでいるか否かを判断する（ステップＳ１２）。バンドル群１０６に更新するバンドルを含んでいないと判断した場合（ステップＳ１２：ＮＯ）、そのまま処理を終了する。一方、サーバ側ＭＡＦ１０５は、バンドル群１０６に更新するバンドルを含んでいると判断した場合（ステップＳ１２：ＹＥＳ）、更新するバンドルと通知情報とを含むバンドル更新情報を管理サーバ１からクライアント端末２へ送信する（ステップＳ１３）。このようにクライアントにバンドルの追加（インストール）をするだけでなく、バンドルの更新（変更を含み、具体的にはバージョンアップまたはダウンに対応）、削除（アンインストール）も可能である。ここで、管理サーバは、各クライアント（サービス／アプリ）がどのバンドルのどのバージョンをインストールして稼働させるべきであるかを記述した「定義」を有している。サーバ側ＭＡＦ１０５は、この「定義」とクライアントからの端末情報とを比較する（ステップＳ１１）。「定義」にはあるがクライアントには存在しないバンドルがある場合にはクライアントへの当該バンドルの追加または更新を、「定義」には無いがクライアントには存在するバンドルがある場合にはクライアントからの当該バンドルの削除を、それぞれ通知する（ステップＳ１３）。もちろん追加または更新の場合は、該当するバンドル１０６も一緒にクライアントに送信する（ステップＳ１３）。

一方、クライアント端末２は、電源オンとなって動作を開始すると、クライアント端末側ＯＳ２００が起動し、サービス側ＯＳＧｉ２１２を実行する。図４に示すように、サービス側ＯＳＧｉ２１２は設定に従いサービス側ＭＡＦ２１４およびその他バンドル２１３を開始した場合、サービス側ＭＡＦ２１４は、端末情報の送信要求があるか否かを判断する（ステップＳ２０）。ここで、端末情報の送信要求は、ユーザによって指示されてもよいし、周期的あるいは日時指定で発火するタイマープログラムによって指示されてもよいし、または、起動などのイベントトリガーによって指示されてもよい。

サービス側ＭＡＦ２１４は、端末情報の送信要求がないと判断した場合（ステップＳ２０：ＮＯ）、そのまま処理を終了する。端末情報の送信要求があると判断した場合（ステップＳ２０：ＹＥＳ）、サービス側端末情報（サービス側ＯＳＧｉフレームワークおよびＪａｖａＶＭに係る情報）を収集する（ステップＳ２１）。そして、アプリ側が起動しているかどうかを判定する（ステップＳ２２）。アプリ側が起動していれば（ステップＳ２２：ＹＥＳ）、サービス側ＭＡＦ２１４は、端末情報の送信をアプリ側ＭＡＦ２２４に要求する（ステップＳ２３）。

アプリ側ＯＳＧｉ２２２がユーザによってスタートされ、設定に従いアプリ側ＭＡＦ２２４およびその他バンドル２２３を開始している場合、アプリ側ＭＡＦ２２４は端末情報送信要求を受信したときに、アプリ側端末情報（アプリ側ＯＳＧｉフレームワークおよびＪａｖａＶＭに係る情報）を収集して、サービス側ＭＡＦ２１４へ送信する。サービス側ＭＡＦ２１４は、アプリ側端末情報を受信すると、受信したアプリ側端末情報を送信するアプリ側端末情報とする（ステップＳ２４）。一方、アプリ側ＯＳＧｉ２２２が実行されておらず、サービス側ＭＡＦ２１４は、起動していないと判定した場合（ステップＳ２２：ＮＯ）、サービス側ＭＡＦ２１４は、過去受信したアプリ側端末情報があるか否かを判定する（ステップＳ２５）。

サービス側ＭＡＦ２１４は、過去受信したアプリ側端末情報があると判定した場合（ステップＳ２５：ＹＥＳ）、直近で受信した過去のアプリ側端末情報を送信するアプリ側端末情報とする（ステップＳ２６）。サービス側ＭＡＦ２１４は、アプリ側端末情報を過去一度も取得していないと判定した場合（ステップＳ２５：ＮＯ）、送信するアプリ側端末情報を「なし」とする（ステップＳ２７）。

ここでは、サービス側ＯＳＧｉ２１２とアプリ側ＯＳＧｉ２２２との間の通信はＪａｖａ ＲＭＩ（Java Remote Method Invocation API)を使用する。その他の通信プロトコルも利用可能である。Ｊａｖａ ＲＭＩは、Ｊａｖａで書かれたものであり、異なるＪａｖａＶＭにあるオブジェクトのメソッドを呼び出す機能を果たすためのＪａｖａアプリケーションプログラミングインタフェースである。

サービス側ＭＡＦ２１４は、図５に示すように、サービス側端末情報及びアプリ側端末情報を管理サーバ１へ送信し（ステップＳ２８）、所定の時間内にバンドル更新情報を受信したか否かを判定する（ステップＳ２９）。サービス側ＭＡＦ２１４は、所定の時間内にバンドル更新情報を受信しないと判断した場合（ステップＳ２９：ＮＯ）、そのまま処理を終了する。

一方、サービス側ＭＡＦ２１４は、所定の時間内にバンドル更新情報を受信したと判定した場合（ステップＳ２９：ＹＥＳ）、受信したバンドルをサービス側とアプリ側に分別して、それぞれ所定の場所に保存する（ステップＳ３０）。具体的には、サービス側ＭＡＦ２１２は、受信したバンドルのＭＡＮＩＦＥＳＴファイルから各バンドルをサービス側又はアプリ側のＯＳＧｉフレームワーク上で動作させるかを指定する指定情報を読み出して、指定情報がサービス側ＯＳＧｉフレームワーク上で動作させると指定するバンドルを、サービス側ＯＳＧｉ２１２の実行フォルダに配置し、指定情報がアプリ側ＯＳＧｉフレームワーク上で動作させると指定するバンドルを、アプリ側ＯＳＧｉ２２２の実行フォルダに配置することで、バンドルを保存する。なお、上記の実行フォルダに同名のバンドルファイルがあれば、該同名のバンドルを上書きする。

次に、サービス側ＭＡＦ２１４は、アプリ側ＭＡＦ２２４と通信可能か否かを判定する（ステップＳ３１）。アプリ側ＭＡＦ２２４が開始しておらず、アプリ側ＭＡＦ２２４と通信できないと判定した場合（ステップＳ３１：ＮＯ）、ステップＳ３１を繰り返す。アプリ側ＭＡＦ２２４と通信できると判断されるまで、ステップＳ３１が繰り返される。アプリ側ＭＡＦ２２４が開始されており、アプリ側ＭＡＦ２２４と通信できると判定した場合（ステップＳ３１：ＹＥＳ）、サービス側ＭＡＦ２１４は、バンドル更新情報の受信をアプリ側ＭＡＦ２２４へ通知する（ステップＳ３２）。バンドル更新情報の受信に係る通知を受けたアプリ側ＭＡＦ２２４は、バンドル更新情報の受信をユーザに通知し、処理を終了する（ステップＳ３３）。

ここで、本実施の形態に係る受信したバンドルの保存処理及び保存したバンドルのインストールの詳細について説明する。図６、図７は本実施の形態に係るバンドル配布システムの機能構成を示すブロック図である。図６はクライアント端末２が受信したバンドルを保存している様子、図７はクライアント端末２が受信したバンドルをインストールした様子をそれぞれ示した。

図６はクライアント端末２が受信したバンドルを保存している様子を示した。図６に示した例では、サービス側ＭＡＦ２１４は、受信した複数のバンドルそれぞれのＭＡＮＩＦＥＳＴファイルから指定情報を読み出す。サービス側ＭＡＦ２１４は、バンドルＡ、Ｂの指定情報がサービス側ＯＳＧｉフレームワークを指定すると判断して、バンドルＡ、Ｂをサービス側ＯＳＧｉ２１２の実行フォルダに配置する。サービス側ＭＡＦ２１２は、バンドルＣ、Ｄの指定情報がアプリ側ＯＳＧｉフレームワークを指定すると判断して、バンドルＣ、Ｄをアプリ側ＯＳＧｉ２２２の実行フォルダに配置する。このように区分されて保存されているバンドルはまだインストールされない。図６では、バンドルＡ、Ｂを、サービス側のバンドル群２１５、バンドルＣ、Ｄをアプリ側バンドル群２２５でそれぞれ示す。

なお、アプリ側で更新するバンドルは、サービス側ＭＡＦ２１４によってアプリ側ＯＳＧｉ２２２の実行フォルダに配置されてバンドル更新情報の通知を実行してから、ステップＳ３３で更新すべきバンドルの存在を知らされたユーザの指示にしたがってアプリ側ＭＡＦ２２４によってインストールすることができる。サービス側で更新するバンドルはサービス側ＭＡＦ２１４によってインストールされる。このインストールも同様にユーザの指示により実行することができる。ユーザからの指示を待たずに自動的にインストールするようにしてもよく、自動的にインストールするか否かをユーザによる設定にしたがって切り替えるようにしてもよい。図７に示した例では、バンドルＡ、Ｂはサービス側ＯＳＧｉ２１２にインストールされ、バンドルＣ、Ｄはアプリ側ＯＳＧｉ２２２にインストールされている。

次に、本実施の形態に係るバンドル更新情報の通知に係る処理の詳細について説明する。図８は、本実施の形態の配布システムを構成するクライアント端末が受信したバンドル更新情報をユーザに通知する処理を示すフローチャートである。図８のフローチャートに示す通知処理は、通常、図５のバンドル更新情報の受信に係る通知処理が実行された後、実行させる処理である。なお、アプリ側ＭＡＦ２２４は、図８のフローチャートに示す処理を繰り返し実行する。

クライアント端末２のアプリ側ＭＡＦ２２４は、ユーザからバンドル更新情報の通知要求を受信した（ユーザから更新実行の指示を受けた）か否かを判定する（ステップＳ４０）。アプリ側ＭＡＦ２２４は、ステップＳ４０にてバンドル更新情報の通知要求受信していないと判断した場合（ステップＳ４０：ＮＯ）、そのまま処理を終了する。当該処理は、繰り返し実行されるので、ステップＳ４０へ戻り、通知要求を受信したと判断するまでは、Ｓ４０：ＮＯが繰り返される。

アプリ側ＭＡＦ２２４は、ステップＳ４０にてバンドル更新情報の通知要求を受信したと判断した場合（ステップＳ４０：ＹＥＳ）、サービス側ＭＡＦ２１４と通信可能か否かを判定する（ステップＳ４１）。アプリ側ＭＡＦ２２４は、サービス側ＭＡＦ２１４が開始しておらず、サービス側ＭＡＦ２１４と通信できないと判定した場合（ステップＳ４１：ＮＯ）、そのまま処理を終了する。アプリ側ＭＡＦ２２４は、サービス側ＭＡＦ２１４と通信できると判定した場合（ステップＳ４１：ＹＥＳ）、ユーザからの更新実行指示を伝え、バンドル更新情報の通知をサービス側ＭＡＦ２１４に要求する（ステップＳ４２）。これにより、サービス側／アプリ側それぞれで更新処理が実行され、サービス側はアプリ側に更新結果を送信する。

サービス側ＭＡＦ２１４は、バンドル更新情報の通知要求を受信した場合、直近更新したバンドルに係る情報を収集してアプリ側ＭＡＦ２２４へ送信する。アプリ側ＭＡＦ２２４は、サービス側ＭＡＦ２１４からサービス側のバンドル更新情報を受信した後、直近更新したアプリ側のバンドルに係る情報を収集し、受信したサービス側のバンドル更新情報とともにユーザに通知する（ステップＳ４３）。これによってユーザに更新結果が通知される。図９はクライアント端末２の表示部に表示されるバンドル更新情報の通知に係る画面例を示す模式図である。ステップＳ４３にてバンドル更新情報をユーザに通知する場合、アプリ側ＭＡＦ２２４は、図９に示したようなバンドルの更新情報の確認画面１００を表示させる。確認画面１００では、直近更新したバンドルの名称を表示すると共に、そのバージョン、プロセス、更新日時などをリストして表示する。

アプリ側ＭＡＦ２２４は、アプリ及びサービス側のバンドル更新情報を確認画面１００でユーザに通知した後、通知処理が完了か否かを判定する（ステップＳ４４）。ユーザが確認画面１００の確認ボタンをクリックせず、通知処理の確認指示を受けないと判定した場合（ステップＳ４４：ＮＯ）、ステップＳ４４を繰り返す。通知処理の確認指示を受けたと判断されるまで、ステップＳ４４が繰り返される。ユーザが確認画面１００の確認ボタンをクリックして、通知処理の確認指示を受けたと判定した場合（ステップＳ４４：ＹＥＳ）、アプリ側ＭＡＦ２２４は、通知処理の完了をサービス側ＭＡＦ２１４へ通知することで、ユーザが確認したことをサービス側ＭＡＦ２１４へ送信する（ステップＳ４５）。通知処理の完了に係る通知を受けたサービス側ＭＡＦ２１４は、通知処理の完了（更新結果：更新の成否）を管理サーバ１へ送信し（ステップＳ４６）、処理を終了する。なお、ユーザの確認を待たず管理サーバ１への更新結果の送信を実行することも可能である。その場合、ステップＳ４３の直前に、アプリ側は自身の更新処理が終わった段階で更新結果をサービス側に伝えておく。そして、ステップＳ４３〜４４と、ステップＳ４６とを並行して実施する。

以上、本発明の実施形態を詳述したが、本発明は前記実施形態に限定されるものではなく、本発明の要旨の範囲内で種々の変形実施が可能である。

例えば、通知処理の確認ステップでは、バンドル更新情報をユーザに表示し、ユーザの確認指示を受けた場合、通知処理は完了と判断するが、これに限定されるものではなく、例えば、バンドル更新情報をユーザに表示し、設定した表示時間が経過した後、通知処理は完了と判断してもよい。

また、バンドルのＭＡＮＩＦＥＳＴファイルに指定情報を含み、サービス側ＭＡＦ２１４は受信したバンドルのＭＡＮＩＦＥＳＴファイルから指定情報を読み出して、バンドルを区分して保存することを例として説明したが、これに限定されるものではなく、指定情報をＭＡＮＩＦＥＳＴファイルに記述する以外に、指定情報はバンドルファイルとは別に「付加情報」として配信されてもよい。例えばサービス側又はアプリ側でバンドルを削除する場合に、削除するバンドルがどちらで稼働しているかを付加情報として配信することができる。

なお、開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上述の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。

１ 管理サーバ
１Ｐ サーバプログラム
２ クライアント端末
２０ ＣＰＵ（演算処理部）
２１ ＨＤ（記憶部）
２Ｐ クライアントプログラム
２００ クライアント端末側ＯＳ（オペレーティングシステム）
２１１ サービス側ＪａｖａＶＭ（第１の仮想マシン）
２１２ サービス側ＯＳＧｉ（第１のフレームワーク）
２１４ サービス側ＭＡＦ（第１の管理手段）
２１５、２２５ バンドル（プログラムモジュール）
２２１ アプリ側ＪａｖａＶＭ（第２の仮想マシン）
２２２ アプリ側ＯＳＧｉ（第２のフレームワーク）
２２４ アプリ側ＭＡＦ（第２の管理手段）

Claims (11)

1. 演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるようにしてある情報処理装置において、
   前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能し、
   前記第１の管理手段は、プログラムモジュールを受信し、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成してある
   ことを特徴とする情報処理装置。
2. 前記第１の管理手段は、プログラムモジュールを受信したことを前記第２の管理手段に通知する機能を有する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第１及び第２の管理手段は、それぞれ前記第１及び第２のフレームワークにプログラムモジュールをインストール又は更新する機能を有する
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第２の管理手段は、
   プログラムモジュール更新情報の通知に係る指示を受付ける機能と、
   自フレームワークで更新したプログラムモジュールに係る情報を収集する機能と、
   前記第１のフレームワークで更新したプログラムモジュールに係る情報を、前記第１の管理手段へ要求し、該第１の管理手段から受信する機能と、
   前記第１及び第２のフレームワークで更新したプログラムモジュールに係る情報を通知する機能と
   を有し、
   前記第１の管理手段は、自フレームワークで更新したプログラムモジュールに係る情報を収集して前記第２の管理手段へ送信する機能を有する
   ことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記第２の管理手段は、前記プログラムモジュール更新の通知が完了したことを前記第１の管理手段へ送信する機能を有し、
   前記第１の管理手段は、受信した通知の完了をサーバ装置に送信する機能を有する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記第１の管理手段は、プログラムモジュールに含む該プログラムモジュールを識別するための識別情報、又はサーバ装置から受信した前記識別情報に基づいて、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成されていることを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記プログラムモジュールはＯＳＧｉフレームワークで稼働するバンドルであり、
   前記第１の管理手段は、受信したプログラムモジュールをそれぞれのＭＡＮＩＦＥＳＴファイルに基づいて分別して保存するように構成されている
   ことを特徴とする請求項６に記載の情報処理装置。
8. プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、外部に提供するように構成してある
   ことを特徴とするサーバ装置。
9. サーバ装置、及び該サーバ装置と通信可能に接続されているクライアント装置を含み、前記サーバ装置から前記クライアント装置へプログラムモジュールを配布する配布システムにおいて、
   前記サーバ装置は、
   プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、配布するように構成しており、
   前記クライアント装置は、演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるように構成しており、
   前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能し、
   前記第１の管理手段は、外部から配布されるプログラムモジュールを受信し、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するように構成してある
   ことを特徴とする配布システム。
10. 演算処理部と記憶部とを備え、前記演算処理部が前記記憶部に記憶してあるプログラムを読み込んで実行することによって、プログラムモジュールの実行プラットフォームとしてそれぞれ稼働する第１及び第２のフレームワークとが作動されるようにしており、前記演算処理部は、前記第１及び第２のフレームワーク上でそれぞれ稼働し、互いに通信可能な第１及び第２の管理手段として機能する情報処理装置に、プログラムモジュールを受信する方法であって、
    前記第１の管理手段が、プログラムモジュールを受信するステップと、
    前記第１の管理手段が、受信したプログラムモジュールを第１又は第２のフレームワーク用のプログラムモジュールに分別して保存するステップと
    を含むことを特徴とする受信方法。
11. プログラムモジュールを提供するサーバ装置によってプログラムモジュールを外部に提供する方法において、
    プログラムモジュールと、該プログラムモジュールを、実行プラットフォームとしての複数のフレームワークのいずれに実装するかを示す情報とを、外部に提供するステップ
    を備えることを特徴とするプログラムモジュール提供方法。

Images