JP2006127399A - アプリケーションプラットフォーム提供システム及び方法並びにそのプログラム - Google Patents

Abstract

【課題】 アプリケーションを動作させるための特定のアプリケーションプラットフォームを備えていない機器であっても、あたかも機器で動作しているのと同等の機能を実現することのできるアプリケーションプラットフォーム提供システムを得る。
【解決手段】 Ｊａｖａ（登録商標）アプリケーション２０６からのアクセス要求に対して、組み込み機器アクセスサービス２０５は、組み込み機器１００へのアクセス要求を行う。組み込み機器アクセスモジュール１０２は、サーバ２００からのアクセス要求を受けた場合、処理結果を組み込み機器アクセスサービス２０５に応答する。組み込み機器アクセスサービス２０５は、この処理結果をＪａｖａ（登録商標）アプリケーション２０６に応答する。
【選択図】 図１

Description

この発明は、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、特定のアプリケーションプラットフォームと所定のアプリケーションとを有するサーバとを備え、所定のアプリケーションから見るとあたかもそのアプリケーションが機器上で動作しているように見えるような機能を実現するアプリケーションプラットフォーム提供システム及び方法並びにプログラムに関するものである。

組み込み機器向けのアプリケーション実行環境に関する仕組みとしては、ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（ｈｔｔｐ：／／ｗｗｗ．ｏｓｇｉ．ｏｒｇ）がある。このＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍでは動的なモジュールの入れ替えなどをサポートしている。
また、オブジェクト指向プログラミングに基づいた携帯形情報処理装置用のソフトウェアの構築方法を提供するものがあった（例えば、特許文献１参照）。

特開平１１−３１２０７９号公報

上記のＯＳＧｉ Ｓｅｒｖｉｃｅ ＰｌａｔｆｏｒｍではＪａｖａ（登録商標）をベースとしており、上述したように動的なモジュールの入れ替えなど、比較的高機能な処理を必要とするため、実行環境としてＣｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＣＤＣ）；ＪＳＲ−３６、ＪＳＲ−２１８／Ｆｏｕｎｄａｔｉｏｎ Ｐｒｏｆｉｌｅ（ＦＰ）；ＪＳＲ−４６のサブセットを要求している（ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ， Ｒｅｌｅａｓｅ３ Ｐ４２７−４７８ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）。しかしながら、ＣＤＣは比較的リソースに余裕のあるデバイス向けのものであり、リソースに制限のある携帯電話のようなデバイスではＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍの仕組みを利用することができなかった。また、上記特許文献１では、携帯形情報処理装置において、現在実行されているタスクに応じて制御アプリケーションのコンフィギュレーションを動的に変化させる方法を開示しているが、このような、特定のアプリケーションプラットフォームを備えていない携帯電話といった機器におけるアプリケーションの実行については示されていなかった。

この発明は上記のような課題を解決するためになされたもので、アプリケーションを動作させるための特定のアプリケーションプラットフォームを備えていない機器であっても、サーバ上のアプリケーションから見るとあたかも機器で動作しているのと同等の機能を実現することのできるアプリケーションプラットフォーム提供システム及び方法並びにそのプログラムを得ることを目的とする。

この発明に係るアプリケーションプラットフォーム提供システムは、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、特定のアプリケーションプラットフォームと所定のアプリケーションとを有するサーバとを備え、特定のアプリケーションプラットフォーム上で動作し、アプリケーションから機器固有の処理に関するアクセス要求があった場合、このアクセス要求に基づいて機器への処理要求を行い、かつ、機器より処理結果を受信した場合は、これをアプリケーションに応答するアクセスサービスをサーバ側に設け、アクセスサービスからの処理要求を受けた場合は、機器固有の処理を行い、その処理結果をアクセスサービスに対して応答するアクセスモジュールを機器側に設けたものである。

この発明のアプリケーションプラットフォーム提供システムは、アプリケーションからのアクセス要求に対してサーバ側のアクセスサービスと機器側のアクセスモジュールとによって処理するようにしたので、サーバ上のアプリケーションから見るとあたかも機器上で動作しているのと同等の機能を実現することができる。

実施の形態１．
図１は、この発明の実施の形態１によるアプリケーションプラットフォーム提供システムを示す構成図である。
図において、アプリケーションプラットフォーム提供システムは、組み込み機器（機器）１００とサーバ２００とこれらを接続するためのネットワーク３００からなる。組み込み機器１００は、実行環境となるリソースに制限を有する機器であり、組み込みＯＳ１０１、組み込み機器アクセスモジュール（アクセスモジュール）１０２を備え、組み込み機器アクセスモジュール１０２は、リソースアクセス部１０３と組み込み機器側通信部１０４を備えている。サーバ２００は、実行環境となるリソースに余裕のあるコンピュータであり、サーバＯＳ２０１、Ｊａｖａ（登録商標）ＶＭ２０２、ＯＳＧｉフレームワーク２０３、バンドル２０４、組み込み機器アクセスサービス（アクセスサービス）２０５を備えている。また、バンドル２０４は、Ｊａｖａ（登録商標）アプリケーション２０６を有し、組み込み機器アクセスサービス２０５は、リソースアクセスＩ／Ｆ部２０７とサーバ側通信部２０８とを備えている。

組み込み機器１００における組み込みＯＳ１０１は、組み込み機器アクセスモジュール１０２といった組み込み機器１００のソフトウェアが動作するためのオペレーティングシステムである。リソースアクセス部１０３は、組み込み機器１００のファイルやネットワークといったリソースにアクセスするためのモジュールである。組み込み機器側通信部１０４は、ネットワーク３００を介してサーバ２００との通信を行うための、組み込み機器１００側の通信インタフェースである。また、組み込み機器側通信部１０４は、サーバ２００からの接続待ちを行えるものとする。

サーバ２００におけるサーバＯＳ２０１は、サーバ２００において全てのソフトウェアが動作する際の基本となるオペレーティングシステムである。Ｊａｖａ（登録商標）ＶＭ２０２は、サーバＯＳ２０１上で動作するＪａｖａ（登録商標）仮想マシンである。また、ＯＳＧｉフレームワーク２０３は、Ｊａｖａ（登録商標）ＶＭ２０２上で動作するフレームワークであり、動的なモジュールのインストール／アンインストール、開始、停止、更新などアプリケーションのライフサイクルの管理とＯＳＧｉフレームワーク２０３上にインストールされているアプリケーションを、同じくＯＳＧｉフレームワーク２０３にインストールされているアプリケーションから利用できる仕組みなどを提供する。

バンドル２０４は、ＯＳＧｉフレームワーク２０３においてＪａｖａ（登録商標）アプリケーション２０６の動的な入れ替えを行うための単位となるものであり、通常、バンドル２０４はＪＡＲファイルとして提供され、Ｊａｖａ（登録商標）アプリケーション２０６はこのバンドル２０４に入れられている。組み込み機器アクセスサービス２０５は、Ｊａｖａ（登録商標）アプリケーション２０６から、組み込み機器１００へのリソースアクセス要求を受けた場合、リソースアクセス用オブジェクトを生成すると共に、このリソースアクセス用オブジェクトに基づいて組み込み機器１００への処理要求を行う機能を有している。リソースアクセスＩ／Ｆ部２０７は、Ｊａｖａ（登録商標）アプリケーション２０６が組み込み機器１００のリソースにアクセスするためのインタフェースを提供する機能部であり、サーバ側通信部２０８は、ネットワーク３００を介して組み込み機器１００と通信を行うためのサーバ２００側の通信部である。

次に、実施の形態１の動作について説明する。
尚、組み込み機器１００のリソースにアクセスする必要がない処理に関してはサーバ２００上で行われるため、この処理についての説明は省略する。

先ず、サーバ２００では、組み込み機器アクセスサービス２０５が動作しており、サーバ側通信部２０８を使用して組み込み機器アクセスモジュール１０２からの接続を待っている。サーバ側通信部２０８と組み込み機器側通信部１０４との通信は、直接、ＴＣＰ／ＩＰ上で行ってもよいし、ＨＴＴＰやＳＩＰ等のプロトコル上のように同様なものでも構わない。

次に、組み込み機器１００が起動して組み込み機器アクセスモジュール１０２が開始されると、組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用して、組み込み機器アクセスサービス２０５に接続しにいく。接続に失敗した場合は設定ファイル等（図示しない）で指定された間隔でリトライする。設定ファイルにはリトライ間隔のほか、サーバ２００のＩＰアドレス、接続待ちをしているポート番号、組み込み機器を識別するための組み込み機器ＩＤを記述しておく。

次に、組み込み機器アクセスモジュール１０２は組み込み機器側の情報を組み込み機器アクセスサービス２０５に送信する。組み込み機器側の情報としては組み込み機器のＩＰアドレス、接続待ちを行うポート番号、組み込み機器ＩＤからなる。組み込み機器アクセスモジュール１０２は、組み込み機器側の情報を送信した後は一旦サーバ２との接続を切り、今度は先ほど組み込み機器側の情報として送ったポート番号で接続を待つ。
次に、組み込み機器１００側の情報を受け取った組み込み機器アクセスサービス２０５は、組み込み機器ＩＤをキーとして組み込み機器１００のＩＰアドレスおよび接続待ちを行うポート番号を登録する。

次に、バンドル２０４を組み込み機器アクセスサービス２０５を使用し、組み込み機器ＩＤを指定してインストールする。組み込み機器アクセスサービス２０５は、ＯＳＧｉフレームワーク２０３の機能を使用してバンドル２０４をＯＳＧｉフレームワーク２０３に登録する。このとき、組み込み機器アクセスサービス２０５は、バンドル２０４をインストールした際にＯＳＧｉフレームワーク２０３から得られるバンドルＩＤを先ほど受け取った組み込み機器ＩＤと対応させて保存しておく。ここで、バンドル２０４はネットワーク３００越しにインストールしてもよいし、サーバ２００のローカルファイルシステムからインストールしてもよい。バンドル２０４のインストールに関してはＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍで規定しているのでここではその説明を省略する。

次に、ＯＳＧｉフレームワーク２０３の機能を利用してＪａｖａ（登録商標）アプリケーション２０６を起動させる。ここで、Ｊａｖａ（登録商標）アプリケーション２０６がそのプログラム中で組み込み機器１００が提供するリソースにアクセスする場合を考える。組み込み機器１００が提供するリソースとしてはファイルやネットワークがある。Ｊａｖａ（登録商標）でいえばＦｉｌｅクラスやＳｏｃｋｅｔクラスなどである。通常、Ｊａｖａ（登録商標）アプリケーションではまず各クラスのオブジェクトをそのクラスのコンストラクタを使用して生成する。例えばＦｉｌｅオブジェクトを生成したい場合は
Ｆｉｌｅ ｆ ＝ ｎｅｗ Ｆｉｌｅ（ファイル名）；
となる。

この実施の形態では上記の処理を次のように行う。即ち、先ずＪａｖａ（登録商標）アプリケーション２０６では、ＯＳＧｉフレームワーク２０３の機能を利用して組み込み機器アクセスサービス２０５を取り出し、リソースアクセスＩ／Ｆ部２０７を利用してリソースアクセス用オブジェクトを取り出す。リソースアクセス用オブジェクトは、本来生成したいＦｉｌｅクラスのサブクラスのオブジェクトとして生成される。実際には
Ｆｉｌｅ ｆ ＝ 組み込みアクセスサービス．ｇｅｔＥＤＲＡＦｉｌｅ（ファイル名）
のようになる。
ここでＥＤＲＡ（Ｅｍｂｅｄｅｄ Ｄｅｖｉｃｅ Ｒｅｓｏｕｒｃｅ Ａｃｃｅｓｓ）はメソッド名の重複を防ぐために付けたものである。そしてその後に生成したいオブジェクトのクラス名、コンストラクタで指定するパラメータを指定する。上述した通り、リソースアクセス用オブジェクトは本来生成したいクラスのサブクラスであるので、生成したあとは本来のクラスとまったく同様に扱うことが可能となる。

ここでリソースアクセス用オブジェクトの生成処理手順について説明する。
図２は、この処理手順を示す説明図である。尚、図中の括弧付き数字の処理は、以下の（１）〜（９）に対応している。また、これ以降の説明において、図中の数字と実施の形態中の説明は対応しているものとする。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、ＯＳＧｉフレームワーク２０３の機能を利用して組み込み機器アクセスサービス２０５を取り出す。
（２）更に、Ｊａｖａ（登録商標）アプリケーション２０６は、組み込み機器アクセスサービス２０５から上記したようなｇｅｔＥＤＲＡＸＸＸ（パラメータ）メソッドを使用してリソースアクセス用オブジェクトの取り出し要求を出す（ＸＸＸはリソースへのアクセスがあるクラス名、パラメータはそのクラスのコンストラクタと同じフォーマット）。

（３）組み込み機器アクセスサービス２０５は、リソースアクセス用オブジェクトを生成する。このときパラメータとして組み込み機器アクセスサービス２０５とリソースアクセス用オブジェクトの取り出しで渡されたパラメータを渡す。
ここで、設定ファイル等によりリソースアクセス用オブジェクトを生成するのではなく、本来生成したいクラスのオブジェクトを生成して返すようにしてもよい。本来のクラスのオブジェクトを生成した場合は以下の処理は行われず、リソースにアクセスがあった場合はＪａｖａ（登録商標）アプリケーション２０６が動作している同一の機器上のリソースにアクセスすることになる。このようにすることにより、組み込み機器アクセスサービスを利用してリソースにアクセスするＪａｖａ（登録商標）アプリケーション２０６を変更することなく、比較的リソースに余裕があり、ＯＳＧｉフレームワーク２０３が動作するような組み込み機器でそのまま動作させることも可能となる。

（４）リソースアクセス用オブジェクトは、組み込み機器アクセスサービス２０５に対して、組み込み機器アクセスモジュール１０２に、このリソースアクセス用オブジェクトが生成されたというコマンドを送るように依頼する。このときパラメータとして、（ａ）このリソースアクセス用オブジェクトを識別するためのリソースアクセス用オブジェクトＩＤ、（ｂ）組み込み機器アクセスモジュール１０２に要求するコマンド（ここではコンストラクタなので例えば”ｃｏｎｓｔｒｕｃｔ”となる）とパラメータからなる文字列、（ｃ）コマンドに付随するデータ、（ｄ）このリソースアクセス用オブジェクト（ｔｈｉｓ）を渡す。以下、このリソースアクセス用オブジェクトが使用される度に、このパラメータを使用してコマンドが送られる。ここでリソースアクセス用オブジェクトＩＤの書式の例を以下に示す。
クラス名＋このオブジェクトのハッシュコード値＋現在の時間の一部
（時間の一部はハッシュコード値が特定の桁に足りない分を時間の最後から補う）

（５）組み込み機器アクセスサービス２０５は、組み込み機器アクセスモジュール１０２から結果が返ってきたときにリソースアクセス用オブジェクトに結果を通知できるように上記（ａ）をキーとして上記（ｄ）を保存しておく。そして、組み込み機器アクセスサービス２０５は、サーバ側通信部２０８を使って組み込み機器アクセスモジュール１０２に対し、渡されたパラメータに従いコマンドデータを送信する。このとき送信されるコマンドデータの書式の例を以下に示す。
（ｅ）のサイズ４バイト＋（ｅ）＋（ｃ）のサイズ４バイト＋（ｃ）
（（ｅ）は（ａ）＋” ”＋（ｂ））

サーバ側通信部２０８は、要求されたデータ送信を行う前に、組み込み機器アクセスサービス２０５に登録されているバンドル２０４がインストールされた際に指定された組み込み機器ＩＤに対応するＩＰアドレス、ポート番号で接続を行い、この接続した通信路に対してデータ送信を行う。以降の各通信処理において通信路が確保されていない場合はこの処理を行うものとする。

（６）組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用してコマンドデータを受信し、このコマンドデータを解析し、対応するリソースの準備を行う。
（７）組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用してリソースが準備できたかどうかの結果を結果データとして組み込み機器アクセスサービス２０５に送信する。結果データの書式の例を以下に示す。
（ａ）のサイズ４バイト＋（ａ）＋結果のサイズ４バイト＋結果

（８）組み込み機器アクセスサービス２０５は、サーバ側通信部２０８を使用して結果データを受信する。そしてこの結果データに含まれる（ａ）に対応する（ｄ）を取り出し、この保存領域をクリアした後、取り出したリソース用オブジェクトに結果を渡す。
リソースアクセス用オブジェクトは、結果を受け取り、この結果をチェックし、問題がなければコンストラクタでの処理を終了する。一方、問題が発生していれば例外をスローまたはその他の方法で結果を返す（本来生成したいクラスのコンストラクタのＡＰＩに依存する）。
（９）組み込み機器アクセスサービス２０５は、（８）の結果を受けて、（３）で生成したリソースアクセス用オブジェクトまたは例外を返す。

次に、リソースアクセス用オブジェクトを使用して組み込み機器１００のリソースにアクセスする場合の処理手順について説明する。これはリソースアクセス用オブジェクトへのメソッド呼び出しという形で行われる。
リソースアクセス用オブジェクトのメソッド呼び出しには以下の２つのパターンがある。
・戻り値が数値や文字列などのネットワークを通して送信可能なものである場合
・戻り値が入力ストリームなどネットワークを通して送信不可能なものである場合
以下にそれぞれの場合のメソッド呼び出しの処理手順について説明する。

図３は、戻り値がネットワークを通して送信可能なものである場合の処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、リソースアクセス用オブジェクトのメソッドを呼び出す。
（２）リソースアクセス用オブジェクトは、組み込み機器アクセスサービス２０５に対して、組み込み機器アクセスモジュール１０２に、Ｊａｖａ（登録商標）アプリケーション２０６から呼び出されたメソッドに対応するコマンドを送るように、リソースアクセス用オブジェクトの生成処理手順（４）で説明した方法で依頼する。
（３）組み込み機器アクセスサービス２０５は、リソースアクセス用オブジェクトの生成処理手順（５）で説明したようにリソースアクセス用オブジェクトを保存し、渡されたパラメータに従ってコマンドデータを送信する。
（４）組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用してコマンドデータを受信し、このコマンドデータを解析し、リソースアクセス部１０３を使用してリソースにアクセスし、結果を取り出す。

（５）組み込み機器アクセスモジュール１０２は、この結果をリソースアクセス用オブジェクトの生成処理手順（７）で説明したように結果データを送信する。
（６）組み込み機器アクセスサービス２０５は、リソースアクセス用オブジェクトの生成処理手順（８）で説明したように、送られてきた結果データからリソースアクセス用オブジェクトＩＤと結果とを取り出し、このリソースアクセス用オブジェクトＩＤに対応する保存しておいたリソースアクセス用オブジェクトを取り出し、保存領域をクリアした後、取り出したリソースアクセス用オブジェクトに結果を渡す。
（７）リソースアクセス用オブジェクトは、渡された結果をメソッドの戻り値としてリターンする。

次に、戻り値がネットワークを通して送信不可能なものである場合の処理手順について説明する。
図４は、この処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、リソースアクセス用オブジェクトのメソッドを呼び出す。
（２）リソースアクセス用オブジェクトは、戻り値用オブジェクトを生成する。このときパラメータとして組み込み機器アクセスサービス２０５とリソースアクセス用オブジェクトの生成処理手順（４）で説明したリソースアクセス用オブジェクトＩＤを渡す。
（３）戻り値用オブジェクトは、組み込み機器アクセスサービス２０５に対して、組み込み機器アクセスモジュール１０２に、（２）で受け取ったリソースアクセス用オブジェクトＩＤに関連した戻り値用オブジェクトが生成されたというコマンドを送るように依頼する。このときパラメータとして、（ａ）この戻り値用オブジェクトを識別するための戻り値用オブジェクトＩＤ（書式の例としてはリソースアクセス用オブジェクトの生成処理手順（４）で説明したリソースアクセス用オブジェクトＩＤと同じ）、（ｂ）組み込み機器アクセスモジュール１０２に要求するコマンドおよび（２）で受け取ったリソースアクセス用オブジェクトＩＤ（ここではコンストラクタなので例えば”ｃｏｎｓｔｒｕｃｔ”＋” ”＋リソースアクセス用オブジェクトＩＤとなる）とパラメータからなる文字列、（ｃ）コマンドに付随するデータ、（ｄ）この戻り値用オブジェクト（ｔｈｉｓ）を渡す。

（４）組み込み機器アクセスサービス２０５は、リソースアクセス用オブジェクトの生成処理手順（５）で説明したように（リソースアクセス用オブジェクトの生成処理手順（５）ではリソースアクセス用オブジェクトであるが、ここでは戻り値用オブジェクトになる）、戻り値用オブジェクトを保存し、渡されたパラメータに従って組み込み機器アクセスモジュール１０２にコマンドデータを送信する。
（５）組み込み機器アクセスモジュール１０２は、コマンドデータを受信し、このコマンドデータを解析し、対応する戻り値用リソースの準備を行う。
（６）組み込み機器アクセスモジュール１０２は、戻り値用リソースが準備できたかどうかの結果を結果データとして、リソースアクセス用オブジェクトの生成処理手順（７）で説明した書式で、組み込み機器アクセスサービス２０５に送信する。

（７）組み込み機器アクセスサービス２０５は、リソースアクセス用オブジェクトの生成処理手順（８）で説明したように（リソースアクセス用オブジェクトの生成処理手順（８）ではリソースアクセス用オブジェクトＩＤであるが、ここでは戻り値用オブジェクトＩＤになる）、送られてきた結果データから戻り値用オブジェクトＩＤと結果を取り出し、この戻り値用オブジェクトＩＤに対応する保存しておいた戻り値用オブジェクトを取り出し、保存領域をクリアしたあと、取り出した戻り値用オブジェクトに結果を渡す。
戻り値用オブジェクトは、結果を受け取り、この結果をチェックし、問題がなければコンストラクタでの処理を終了する。一方、問題が発生していれば例外をスローまたはその他の方法で結果を返す（呼び出されたメソッドのＡＰＩに依存する）。
（８）リソースアクセス用オブジェクトは（７）の結果を受けて、（２）で生成した戻り値用オブジェクトまたは例外または結果（例えばｎｕｌｌや−１など）を返す。

以上のような方法により、Ｊａｖａ（登録商標）アプリケーションはリソースにアクセスする必要があるクラスを使用する場合に、そのオブジェクトの生成方法を変更する以外は通常のプログラミングと同様に行うことができる。またコンストラクタの代わりに呼ばれるメソッドもコンストラクタとほぼ同様な書式で記述することができるため、ネットワーク越しに実行するための特別なＡＰＩを学習・使用する必要もない。

以上のように、実施の形態１のアプリケーションプラットフォーム提供システムによれば、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、特定のアプリケーションプラットフォームと所定のアプリケーションとを有するサーバとを備え、サーバは、特定のアプリケーションプラットフォーム上で動作し、アプリケーションから機器固有の処理に関するアクセス要求があった場合、アクセス要求に基づいて機器への処理要求を行い、かつ、機器より処理結果を受信した場合は、処理結果をアプリケーションに応答するアクセスサービスとを備え、機器は、アクセスサービスからの処理要求を受けた場合は、機器固有の処理を行い、その処理結果をアクセスサービスに対して応答するアクセスモジュールを備えたので、サーバ上のアプリケーションから見るとあたかも機器上で動作しているのと同等の機能を実現することができる。

また、実施の形態１のアプリケーションプラットフォーム提供システムによれば、アクセスサービスは、所定のアプリケーションから機器のリソースアクセス要求を受けた場合、リソースアクセス用オブジェクトを生成すると共に、リソースアクセス用オブジェクトに基づいて機器への処理要求を行うようにしたので、機器側のリソースに対して、サーバ上のアプリケーションは、ネットワーク等を意識することなくアクセスすることができる。

また、実施の形態１のアプリケーションプラットフォーム提供システムによれば、アクセスモジュールは、サーバからのアクセス要求の接続待ちを行い、アクセスサービスは、機器への処理要求が発生した場合に、アクセスモジュールに対して接続を行うようにしたので、アプリケーションから機器への要求はサーバが要求するタイミングで行うことができるため、アクセスに対する応答を直ちに得ることができる。

また、実施の形態１のアプリケーションプラットフォーム提供システムによれば、特定のアプリケーションプラットフォームは、Ｊａｖａ（登録商標）ＶＭと当該Ｊａｖａ（登録商標）ＶＭ上で動作する所定のフレームワークからなり、所定のアプリケーションはＪａｖａ（登録商標）アプリケーションとしたので、リソースに制限がありＪａｖａ（登録商標）ＶＭを動作させることができない組み込み機器であっても適用することができる。

また、実施の形態１のアプリケーションプラットフォーム提供方法によれば、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、特定のアプリケーションプラットフォームと所定のアプリケーションとを有するサーバとを備え、アプリケーションから機器固有の処理に関するアクセス要求があった場合、特定のアプリケーションプラットフォーム上で動作するアクセスサービスが、アクセス要求に基づいて機器への処理要求を行い、機器は、アクセスサービスからの処理要求に基づいて機器固有の処理を行って、その処理結果をアクセスサービスに対して応答し、アクセスサービスは、機器より処理結果を受信した場合は、処理結果をアプリケーションに応答するようにしたので、サーバ上のアプリケーションから見るとあたかも機器上で動作しているのと同等の機能を提供することができる。

また、実施の形態１のアプリケーションプラットフォーム提供プログラムによれば、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器を構成するコンピュータと、特定のアプリケーションプラットフォームと所定のアプリケーションとを有するサーバを構成するコンピュータとを、サーバを構成するコンピュータ上で、特定のアプリケーションプラットフォーム上で動作し、アプリケーションから機器固有の処理に関するアクセス要求があった場合、アクセス要求に基づいて機器への処理要求を行い、かつ、機器より処理結果を受信した場合は、処理結果をアプリケーションに応答するアクセスサービスとして機能させ、機器を構成するコンピュータ上で、アクセスサービスからの処理要求を受けた場合は、機器固有の処理を行い、その処理結果をアクセスサービスに対して応答するアクセスモジュールとして機能させるようにしたので、サーバ上のアプリケーションから見るとあたかも機器上で動作しているのと同等の機能を実現するプログラムを提供することができる。

実施の形態２．
図５は、この発明の実施の形態２によるアプリケーションプラットフォーム提供システムを示す構成図である。
実施の形態２は、組み込み機器１００ａとサーバ２００ａとネットワーク３００からなる。組み込み機器１００ａは、組み込みＯＳ１０１、組み込み機器アクセスモジュール（アクセスモジュール）１０２ａとネイティブライブラリ１０５を備え、組み込み機器アクセスモジュール１０２ａは、リソースアクセス部１０３と組み込み機器側通信部１０４とネイティブライブラリアクセス部１０６を備えている。この組み込み機器１００ａにおいて、組み込みＯＳ１０１、リソースアクセス部１０３、組み込み機器側通信部１０４は、実施の形態１と同様の構成であるため、これらの説明は省略する。

サーバ２００ａは、サーバＯＳ２０１、Ｊａｖａ（登録商標）ＶＭ２０２、ＯＳＧｉフレームワーク２０３、バンドル２０４ａ、組み込み機器アクセスサービス（アクセスサービス）２０５ａを備えている。バンドル２０４ａは、Ｊａｖａ（登録商標）アプリケーション２０６とネイティブライブラリ２０９とを備え、組み込み機器アクセスサービス２０５は、リソースアクセスＩ／Ｆ部２０７とサーバ側通信部２０８とネイティブライブラリアクセスＩ／Ｆ部２１０を備えている。ここで、ネイティブライブラリ２０９およびネイティブライブラリアクセスＩ／Ｆ部２１０以外の構成は、実施の形態１と同様であるため、これらの説明は省略する。

組み込み機器１００ａにおけるネイティブライブラリ１０５は、組み込み機器１００ａ上で動作するネイティブライブラリであり、サーバ２００ａ側のネイティブライブラリ２０９がインストールされたものである。ネイティブライブラリアクセス部１０６は、ネイティブライブラリ１０５にアクセスするための組み込み機器アクセスモジュール１０２ａに備えられたネイティブライブラリアクセス部である。即ち、組み込み機器アクセスモジュール１０２ａは、サーバ２００ａ側からのネイティブライブラリ呼び出し要求を受けた場合は、ネイティブライブラリへのアクセスを行う機能を有している。

サーバ２００ａにおけるネイティブライブラリ２０９は、例えば、サーバＯＳ２０１上で動作するネイティブライブラリであり、組み込み機器１００ａにインストールされるネイティブライブラリである。ネイティブライブラリアクセスＩ／Ｆ部２１０は、組み込み機器アクセスサービス２０５ａに備えられた、Ｊａｖａ（登録商標）アプリケーション２０６がネイティブライブラリ１０５にアクセスするためのインタフェースを提供するものである。即ち、組み込み機器アクセスサービス２０５ａは、Ｊａｖａ（登録商標）アプリケーション２０６から、ネイティブライブラリへのアクセス要求を受けた場合は、組み込み機器１００ａへのネイティブライブラリ呼び出し要求を行う機能を有している。

本実施の形態の構成は以上のようになっており、以下、サーバ上で動作するＪａｖａ（登録商標）アプリケーション２０６が組み込み機器１００ａ上で動作するネイティブライブラリ１０５にアクセスする実行手順について説明する。
Ｊａｖａ（登録商標）アプリケーション２０６を起動させるまでの処理は実施の形態１と同様であるためここでの説明は省略する。
ここでＪａｖａ（登録商標）アプリケーション２０６がそのプログラム中でネイティブライブラリ１０５にアクセスする場合を考える。Ｊａｖａ（登録商標）ではネイティブライブラリにアクセスするためには、まずネイティブライブラリのロードを行う必要がある。ここではネイティブライブラリを組み込み機器１００ａにインストールし、使用できるようにロードする処理を行うことになる。

図６は、ネイティブライブラリのロード処理を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、ＯＳＧｉフレームワーク２０３の機能を利用して組み込み機器アクセスサービス２０５ａを取り出す。
（２）更に、Ｊａｖａ（登録商標）アプリケーション２０６は、組み込み機器アクセスサービス２０５ａにネイティブライブラリのロード要求を出す。このときパラメータとしてネイティブライブラリ名を渡す。
（３）更に、組み込み機器アクセスサービス２０５ａはパラメータで与えられたネイティブライブラリ名を使用して、Ｊａｖａ（登録商標）アプリケーション２０６に対応するバンドル２０４ａからネイティブライブラリ２０９を取り出す。

（４）更に、組み込み機器アクセスサービス２０５ａはコマンドデータを組み込み機器アクセスモジュール１０２ａに対し送信する。このとき送信されるコマンドデータの書式の例を以下に示す。
（ｄ）のサイズ４バイト＋（ｄ）＋（ｃ）のサイズ４バイト＋（ｃ）
ここで（ａ）は組み込み機器アクセスサービスを示すＩＤで、例えば全てのバイトを０にしたＩＤである。また、（ｂ）は組み込み機器アクセスモジュール１０２ａに要求するコマンドでここでは”ｌｏａｄＬｉｂｒａｒｙ”となる。更に、（ｃ）は（３）で取り出したネイティブライブラリ、（ｄ）は（ａ）＋” ”＋（ｂ）である。
サーバ側通信部２０８は要求されたデータ送信を行う前に、組み込み機器アクセスサービス２０５ａに登録されているバンドル２０４ａがインストールされた際に指定された組み込み機器ＩＤに対応するＩＰアドレス、ポート番号で接続を行い、この接続した通信路に対してデータ送信を行う。以降の各通信処理において通信路が確保されていない場合はこの処理を行うものとする。

（５）組み込み機器アクセスモジュール１０２ａは、組み込み機器側通信部１０４を使用してコマンドデータを受信し、このコマンドデータを解析し、コマンドデータに含まれるネイティブライブラリを組み込みＯＳ１０１にロードさせる。
（６）組み込み機器アクセスモジュール１０２ａは、組み込み機器側通信部１０４を使用してネイティブライブラリがロードできたかの結果を結果データとして組み込み機器アクセスサービス２０５ａに送信する。結果データの書式の例を以下に示す。
（ａ）のサイズ４バイト＋（ａ）＋結果のサイズ４バイト＋結果
（７）組み込み機器アクセスサービス２０５ａは、サーバ側通信部２０８を使用して結果データを受信する。そしてこの結果データに含まれる結果を取り出し、この結果をＪａｖａ（登録商標）アプリケーション２０６に返す。

ここでネイティブライブラリ２０９のロードは組み込み機器アクセスサービス２０５ａが持つＩ／ＦをＪａｖａ（登録商標）アプリケーション２０６が使用して行ったが、これを実施の形態１と同じようにリソースアクセス用オブジェクトを使用して行うこともできる。この場合はまずネイティブライブラリをロードする場合に使用するＳｙｓｔｅｍクラスのリソースアクセス用オブジェクトを取り出し、このリソースアクセス用オブジェクトのｌｏａｄＬｉｂｒａｒｙ（Ｓｔｒｉｎｇ）メソッドを使用することによって行うことができる。これの手順については実施の形態１で説明したのでここでは省略する。

次に、Ｊａｖａ（登録商標）アプリケーション２０６がそのプログラム中でネイティブライブラリ１０５にアクセスする実行手順について説明する。
一般的に、Ｊａｖａ（登録商標）では、ネイティブライブラリはＪＮＩ（Ｊａｖａ（登録商標） Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）を用いて作成される。このため本実施の形態でもネイティブライブラリとのＩ／ＦはＪＮＩを用いることとする。ここではＪＮＩとするがネイティブライブラリのＩ／Ｆとして独自のものでも構わない。
ネットワーク３００越しにネイティブライブラリ１０５が提供するメソッドを呼び出す場合、Ｊａｖａ（登録商標）アプリケーション２０６が呼び出したメソッドを元に、組み込み機器アクセスサービス２０５ａで対応するＪＮＩに基づいた関数名を作り出し、ネットワーク３００を通してその関数名とパラメータを送信する。そして、送られてきたデータを元に組み込み機器アクセスモジュール１０２ａが対応するネイティブライブラリ１０５の関数を呼び出す。

しかし、組み込み機器アクセスモジュール１０２ａにおいて、メソッドに対応する関数名さえ分かればネイティブライブラリ１０５からメソッドに対応する関数のポインタは取り出せるが、パラメータの個数とタイプの組み合わせは無限にあるため、取り出した関数をキャストすることができず、よって関数呼び出しが出来ないという問題がある。
この解決手段として以下の２つの方法が考えられる。
・パラメータの個数を制限するためにメソッドで使用するパラメータは配列の１個のみとし、かつ配列で与えるパラメータのタイプをオブジェクトとする。そしてネイティブライブラリ側でパラメータを配列から取り出し、取り出したオブジェクトを目的のタイプにキャストして使用する（定型パラメータ方式とする）。
・組み込み機器アクセスサービス２０５ａ側でＪａｖａ（登録商標）アプリケーション２０６が呼び出すメソッドの情報を元に、ネイティブライブラリ１０５にアクセスできるようなモジュールを動的に生成し、このモジュールを組み込み機器アクセスモジュール１０２ａに送り、組み込み機器アクセスモジュール１０２ａはこのモジュールを使用してネイティブライブラリ１０５が提供する関数を呼び出す（動的コンパイル方式とする）。

以下に、これらの方式の処理手順について説明する。
先ず、定型パラメータ方式について説明する。
定型パラメータ方式ではネイティブメソッドを以下の書式にする必要がある。
可視性修飾子 Ｏｂｊｅｃｔ メソッド名（Ｏｂｊｅｃｔ［］ ａｒｇｓ）
可視性修飾子は、例えばｐｕｂｌｉｃやｐｒｉｖａｔｅなどである。次のＯｂｊｅｃｔはリターン値のためのもの、そしてメソッド名と続き、最後にパラメータの配列となる。

図７は、定型パラメータ方式の処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、組み込み機器アクセスサービス２０５ａのネイティブライブラリアクセスＩ／Ｆ部２１０を利用して、ネイティブライブラリ１０５が提供するメソッドの呼び出し要求を行う。呼び出し要求のメソッドの例を以下に示す。
ｐｕｂｌｕｃ Ｏｂｊｅｃｔ ｉｎｖｏｋｅ（Ｏｂｊｅｃｔ ｏｂｊ，Ｓｔｒｉｎｇ ｍｅｔｈｏｄｎａｍｅ，Ｏｂｊｅｃｔ［］ ａｒｇｓ）
ここでパラメータの内容は、
ｏｂｊ−メソッドを呼び出すオブジェクト（実際にはｔｈｉｓを指定）。
ｍｅｔｈｏｄｎａｍｅ−呼び出すメソッドの名前。
ａｒｇｓ−メソッドに設定するパラメータの配列。１番目のパラメータはａｒｇｓ［０］へ、２番目のパラメータはａｒｇｓ［１］へ、以下同様。パラメータがない場合はｎｕｌｌを指定する。
また戻り値としてはメソッドのリターン値を格納するためのＯｂｊｅｃｔになる。

（２）組み込み機器アクセスサービス２０５ａは与えられたパラメータから、このメソッドに対応する関数名を組み立てる。またパラメータで与えられたｏｂｊ、ａｒｇｓの各要素に対してＩＤを割り当てる。割り当てるＩＤは実施の形態１でリソースアクセス用オブジェクトに割り当てたＩＤと同じ書式とする。そして組み込み機器アクセスモジュール１０２ａに対しネイティブメソッド対応関数呼び出し要求用のデータを送信する。このデータの書式の例を以下に示す。
（ｅ）のサイズ４バイト＋（ｅ）＋（ｆ）のサイズ４バイト＋（ｆ）
ここで（ａ）はｏｂｊのＩＤ
（ｂ）はコマンド（ここでは”ｉｎｖｏｋｅ”となる）
（ｃ）は関数名
（ｄ）はａｒｇｓ［０］のＩＤ＋” ”＋ａｒｇｓ［１］のＩＤ＋” ”＋ａｒｇｓ［２］のＩＤ＋・・・
（ｅ）は（ａ）＋” ”＋（ｂ）
（ｆ）は（ｃ）＋” ”＋（ｄ）
である。

（３）組み込み機器アクセスモジュール１０２ａでは、送られてきた関数名から関数を取り出す。関数の型は以下のようになる。
ｊｏｂｊｅｃｔ ＪＮＩＣＡＬＬ 関数名（ＪＮＩＥｎｖ ＊ｅｎｖ，ｊｏｂｊｅｃｔ ｔｈｉｓＣｌａｓｓ，ｊｏｂｊｅｃｔＡｒｒａｙ ｐａｒａｍｓ）
ここで、第一パラメータはＪＮＩポインタで、メソッドの呼び出しやフィールドへのアクセスなどネイティブ側からＪａｖａ（登録商標）の情報にアクセスする場合はこのＪＮＩポインタを使用する。第二パラメータはｔｈｉｓポインタ、第三パラメータはメソッドのパラメータで、ネイティブメソッドのパラメータをオブジェクトの配列にしたことからｊｏｂｊｅｃｔＡｒｒａｙになる。
（４）更に、組み込み機器アクセスモジュール１０２ａでは、（２）で送られてきたｏｂｊのＩＤとａｒｇｓの各ＩＤを、関数のパラメータとして与えるｔｈｉｓＣｌａｓｓに設定する。ａｒｇｓに関しては更にｐａｒａｍｓに設定する。
（５）更に、組み込み機器アクセスモジュール１０２ａでは、ネイティブライブラリアクセス部１０６を使用して（３）で取り出した関数に（４）で準備した各パラメータを与えて呼び出す。
（６）ネイティブライブラリ１０５において関数を実行する。もしこの中でフィールドやオブジェクトにアクセスが発生した場合の処理は（７）〜（１１）のようになる。
（７）パラメータで与えられたＪＮＩポインタを使用してＪＮＩでアクセスする。

（８）ネイティブライブラリ１０５がＪａｖａ（登録商標）の情報にアクセスする場合、パラメータで与えられたｔｈｉｓＣｌａｓｓやｐａｒａｍｓの各要素にアクセスする場合は（４）で設定したＩＤとその処理コマンドを組み込み機器アクセスサービス２０５ａに送信する。また新規オブジェクトを生成する場合は仮ＩＤとその処理コマンドを組み込み機器アクセスサービス２０５ａに送信する。仮ＩＤは例えば（４）で使用したＩＤと同じ桁分の”１”などを使用する（”０”はネイティブライブラリをロードする際に組み込み機器アクセスサービス２０５ａのＩＤとして使用しているため使用できないが、通常のＩＤに割り当てられるようなＩＤ以外の値なら特に問題ない）。ここで組み込み機器アクセスサービス２０５ａに送信するデータの書式の例を以下に示す。
（ｇ）のサイズ４バイト＋（ｇ）＋（ｈ）のサイズ４バイト＋（ｈ）
ここで（ｇ）はパラメータで与えられたｊｏｂｊｅｃｔのＩＤまたは仮ＩＤ
（ｈ）はコマンド名＋” ”＋第一パラメータの型＋” ”＋第一パラメータの値＋” ”＋第二のパラメータの型＋” ”＋第二パラメータの値＋・・・
または”ｇｅｔｆｉｅｌｄ”＋” ”＋フィールド名
ここで、パラメータの値としては
・パラメータの型がオブジェクトの場合はＩＤ
・パラメータの型がプリミティブの場合は値を文字列にしたもの
となる。

（９）組み込み機器アクセスサービス２０５ａでは送られてきたデータから対応する処理を実行する。
（１０）そして、組み込み機器アクセスサービス２０５ａでは実行結果を組み込み機器アクセスモジュール１０２ａに送信する。ここで組み込み機器アクセスモジュール１０２ａに送信するデータの書式の例を以下に示す。
（ｇ）のサイズ４バイト＋（ｇ）＋（ｉ）のサイズ４バイト＋（ｉ）
ここで（ｉ）はコマンドに対する戻り値である。戻り値がオブジェクトの場合はＩＤ、それ以外の場合はプリミティブ（戻り値をもらう関数は戻り値のタイプを知っているので、戻り値をポインタで渡せばキャストして値を得ることができる）となる。
（１１）組み込み機器アクセスモジュール１０２ａはＪＮＩで定義されているタイプで値を返す。

（１２）ネイティブライブラリ１０５は関数の戻り値を返す。戻り値のタイプはｊｏｂｊｅｃｔとなる。
（１３）組み込み機器アクセスモジュール１０２ａは、結果を組み込み機器アクセスサービス２０５ａに送信する。結果データの書式の例を以下に示す。
（ａ）のサイズ４バイト＋（ａ）＋（ｊ）のサイズ４バイト＋（ｊ）
ここで（ｊ）はメソッド呼び出しの戻り値であるＯｂｊｅｃｔのＩＤ
（１４）組み込み機器アクセスサービス２０５ａは、送られてきた結果データのＯｂｊｅｃｔをリターン値として返す。

次に動的コンパイル方式について説明する。
動的コンパイル方式では定型パラメータ方式のようなネイティブメソッドの書式に対する制限はない。
図８は、動的コンパイル方式の処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、組み込み機器アクセスサービス２０５ａのネイティブライブラリアクセスＩ／Ｆ部２１０を利用して、ネイティブライブラリ１０５が提供するメソッドの呼び出しを行う。呼び出し要求のメソッドの例を以下に示す。
ｐｕｂｌｉｃ Ｏｂｊｅｃｔ ｉｎｖｏｋｅ（Ｏｂｊｅｃｔ ｏｂｊ，Ｓｔｒｉｎｇ ｍｅｔｈｏｄｎａｍｅ，Ｓｔｒｉｎｇ ｒｅｔｕｒｎｔｙｐｅ，
Ｓｔｒｉｎｇ［］ ａｒｇｓｔｙｐｅｓ，Ｏｂｊｅｃｔ［］ ａｒｇｓ）
ここでパラメータの内容は
ｏｂｊ−メソッドを呼び出すオブジェクト（実際にはｔｈｉｓを指定）
ｍｅｔｈｏｄｎａｍｅ−呼び出すメソッドの名前
ｒｅｔｕｒｎｔｙｐｅ−戻り値のタイプ
ａｒｇｓｔｙｐｅ−メソッドに設定するパラメータのタイプの配列
ａｒｇｓ−メソッドに設定するパラメータの配列。タイプがプリミティブの場合はそのプリミティブに対応するクラスで設定する。
また、戻り値としてはメソッドのリターン値を格納するためのＯｂｊｅｃｔである。タイプがプリミティブの場合はそのプリミティブに対応するクラスで返されるので、Ｊａｖａ（登録商標）アプリケーション２０６は返されたクラスからプリミティブに変換する必要がある。
ここで、戻り値およびパラメータのタイプはＪＮＩのＪａｖａ（登録商標）のシグニチャ記号と同じものを使ってもよいし、独自のものを使ってもよい。

（２）組み込み機器アクセスサービス２０５ａは与えられたパラメータから、このメソッドに対応する関数名を組み立てる。またパラメータで与えられたｏｂｊおよびａｒｇｓで与えられた各要素の中でタイプがクラスであるものに対してＩＤを割り当てる。割り当てるＩＤは実施の形態１でリソースアクセス用オブジェクトに割り当てたＩＤと同じ書式とする。また、与えられたパラメータから、ネイティブライブラリにアクセスするためのネイティブライブラリアクセス用モジュールのソースを生成する。このとき、既に同じメソッドに対するネイティブライブラリアクセス用モジュールが作成されていたら、この後の処理と（３），（４）の処理は行わない（既にこのメソッドに対するネイティブライブラリアクセス用モジュールがインストールされているため）。ソースの内容はネイティブメソッド用の関数を取り出し、組み込み機器アクセスモジュール１０２ａから受け取ったデータをネイティブメソッド用関数のパラメータに合わせてキャストまたはオブジェクトを生成し、そのパラメータを使用してネイティブメソッドに対応する関数を呼び出すというものとなる。そして、このソースをコンパイルし、ネイティブライブラリアクセス用モジュールを生成する。

（３）組み込み機器アクセスサービス２０５ａは、（２）で生成したネイティブライブラリアクセス用モジュールを組み込み機器アクセスモジュール１０２ａにインストールするようにコマンドデータを送信する。
（４）そして、組み込み機器アクセスモジュール１０２ａは送られてきたコマンドデータを解析し、送られてきたネイティブライブラリアクセス用モジュールを適切な場所に保存し、保存したネイティブライブラリアクセス用モジュールをロードする。図５ではこのネイティブライブラリアクセス用モジュールはネイティブライブラリアクセス部１０６の部分に対応することになる。
（５）次に、組み込み機器アクセスサービス２０５ａは組み込み機器アクセスモジュール１０２ａに対してネイティブメソッド対応関数呼び出し要求用のデータを送信する。このデータの書式の例を以下に示す。
（ｅ）のサイズ４バイト＋（ｅ）＋（ｆ）のサイズ４バイト＋（ｆ）
ここで（ａ）はｏｂｊのＩＤ
（ｂ）はコマンド（ここでは”ｉｎｖｏｋｅ”となる）
（ｃ）はネイティブライブラリアクセス用モジュールの関数名
（ｄ）はａｒｇｓ［０］のＩＤ（クラスの場合）またはａｒｇｓ［０］の値（プリミティブの場合）＋” ”＋ａｒｇｓ［１］のＩＤまたはａｒｇｓ［１］の値＋” ”＋ａｒｇｓ［２］のＩＤまたはａｒｇｓ［２］の値＋・・・
（ｅ）は（ａ）＋” ”＋（ｂ）
（ｆ）は（ｃ）＋” ”＋（ｄ）
である。

（６）組み込み機器アクセスモジュール１０２ａは送られてきた関数名からネイティブライブラリアクセス用モジュールの関数を取り出す。
（７）そして、組み込み機器アクセスモジュール１０２ａは組み込み機器アクセスサービス２０５ａから送られてきたデータをバイトの配列に読み込み、これをパラメータとしてネイティブライブラリアクセス用モジュールの関数を呼び出す。
（８）ネイティブライブラリアクセス用モジュールは自身の生成時に指定されたネイティブメソッドに対応するネイティブライブラリの関数を取り出す。
（９）そして、ネイティブライブラリアクセス用モジュールはパラメータで与えられたバイトの配列からネイティブライブラリの関数のパラメータに対応するデータを順番に取り出し、このデータから関数に与えるパラメータの生成（タイプがクラスの場合）または値の取り出し（タイプがプリミティブの場合）を行う。

（１０）そして、ネイティブライブラリアクセス用モジュールは（８）で取り出した関数に（９）で準備した各パラメータを与えて呼び出す。
（１１）ネイティブライブラリ１０５において関数を実行する。
（１２）ネイティブライブラリ２０９は関数の戻り値をネイティブライブラリアクセス用モジュールに返し、更にネイティブライブラリアクセス用モジュールはその値を組み込み機器アクセスモジュール１０２ａに返す。
（１３）そして、組み込み機器アクセスモジュール１０２ａは結果を組み込み機器アクセスサービス２０５ａに送信する。この結果データの書式の例を以下に示す。
（ａ）のサイズ４バイト＋（ａ）＋（ｇ）のサイズ４バイト＋（ｇ）
ここで（ｇ）はＩＤ（戻り値のタイプがクラスの場合）または値（戻り値のタイプがプリミティブの場合）。
更に、組み込み機器アクセスサービス２０５ａは戻り値をＪａｖａ（登録商標）アプリケーション２０６に返す。このとき組み込み機器アクセスモジュール１０２ａから送られてきた戻り値がＩＤの場合はそのＩＤで特定されるＯｂｊｅｃｔ、値の場合はその値（プリミティブ）に対応するクラスのＯｂｊｅｃｔが返される。

以上のような方法により、Ｊａｖａ（登録商標）アプリケーションはネイティブライブラリを使用する場合に、ネットワークを意識することなく使用することが可能となる。

以上のように、実施の形態２のアプリケーションプラットフォーム提供システムによれば、アクセスサービスは、所定のアプリケーションから、機器上で動作するネイティブライブラリへのアクセス要求を受けた場合、機器へのネイティブライブラリ呼び出し要求を行い、アクセスモジュールは、ネイティブライブラリ呼び出し要求を受けた場合は、ネイティブライブラリへのアクセスを行うよう構成したので、機器側のネイティブライブラリに対して、サーバ上のアプリケーションは、ネットワーク等を意識することなくアクセスすることができる。

実施の形態３．
図９は、この発明の実施の形態３によるアプリケーションプラットフォーム提供システムを示す構成図である。
実施の形態３は、特定のアプリケーションプラットフォームを備えていない機器として携帯電話の例であり、携帯電話１００ｂとサーバ２００ｂとネットワーク３００からなる。携帯電話１００ｂは、携帯電話用ＯＳ１０７、携帯電話用Ｊａｖａ（登録商標）ＶＭ１０８、携帯電話アクセスモジュール（アクセスモジュール）１０２ｂを備え、携帯電話アクセスモジュール１０２ｂは、携帯電話リソースアクセス部１０３ａと携帯電話側通信部１０４ａを備えている。携帯電話用ＯＳ１０７は、携帯電話１００ｂの各種のソフトウェアを動作させるためのオペレーティングシステムであり、携帯電話用Ｊａｖａ（登録商標）ＶＭ１０８は、携帯電話用ＯＳ１０７上で動作するＪａｖａ（登録商標）ＶＭである。この携帯電話用Ｊａｖａ（登録商標）ＶＭ１０８は、サーバ２００ｂ上で動作するＪａｖａ（登録商標）ＶＭ２０２と比べて提供する機能が少なく、このため、携帯電話用Ｊａｖａ（登録商標）ＶＭ１０８ではＯＳＧｉフレームワークを動作させることができない。携帯電話アクセスモジュール１０２ｂは、携帯電話１００ｂのリソースにアクセスするためのアクセスモジュールであり、携帯電話リソースアクセス部１０３ａは、リソースにアクセスする機能部、携帯電話側通信部１０４ａは、２００ｂとの通信を行うための通信部である。また、この携帯電話側通信部１０４ａは、サーバ２００ｂからの接続待ちは行えないものとする。

サーバ２００ｂにおいて、組み込み機器アクセスサービス（アクセスサービス）２０５ｂは、携帯電話１００ｂへの処理要求が発生した場合に、携帯電話アクセスモジュール１０２ｂからの接続要求待ちを行い、その携帯電話アクセスモジュール１０２ｂから接続要求があった場合にアクセス要求を行うよう構成されている。これ以外の構成は実施の形態１のサーバ２００と同様であるため、ここでの説明は省略する。

次に、実施の形態３の動作について説明する。
先ず、サーバ２００ｂでは、組み込み機器アクセスサービス２０５ｂが動作しており、サーバ側通信部２０８を使用して携帯電話アクセスモジュール１０２ｂからの接続を待っている。
次に、携帯電話１００ｂ上で携帯電話アクセスモジュール１０２ｂを動作させる。すると携帯電話アクセスモジュール１０２ｂは、携帯電話側通信部１０４ａを使用して、組み込み機器アクセスサービス２０５ｂに接続しにいく。
更に、携帯電話アクセスモジュール１０２ｂは、組み込み機器アクセスサービス２０５ｂに対し、自身に対するリソースアクセス要求の有無をチェックするために、ＨＴＴＰ要求を行う。リソースアクセス要求の有無のチェックは定期的に行う方法や、例えばリソースアクセス要求がないという応答があった直後の再チェックではウェイト時間を長くし、リソースアクセス要求があった直後の再チェックは短時間のウェイトもしくは直ちに再チェックを行うといった方法が考えられる。即ち、携帯電話アクセスモジュール１０２ｂは、組み込み機器アクセスサービス２０５ｂからのそれまでのアクセス要求の有無に応じて接続要求の頻度を変更するようにしてもよい。

このＨＴＴＰ要求はＧＥＴまたはＰＯＳＴで行われる。このときパラメータとしてこのＨＴＴＰ要求がリソースアクセス要求の有無のチェックを示すコマンドと自身のＩＤを含む。ここでリソースアクセス要求の有無のチェックを示すコマンドをなくしてＩＤだけをパラメータとしてもよい。
これらのパラメータはクエリーに設定され送信される。もしＰＯＳＴで要求する場合はクエリーの代わりにエンティティ部分に格納して送信することも可能である。

次に、サーバ２００ｂの組み込み機器アクセスサービス２０５ｂは、このＨＴＴＰ要求を調査し、このＨＴＴＰ要求に含まれるＩＤに対するリソースアクセス要求があるかをチェックし、ある場合はリソースアクセス要求を、ない場合はリソースアクセス要求がないというデータをＨＴＴＰ応答として返す。リソースアクセス要求がある場合についての処理は後述する。

次に、バンドル２０４を組み込み機器アクセスサービス２０５ｂを使用して、携帯電話アクセスモジュール１０２ｂのＩＤを指定してインストールする。
組み込み機器アクセスサービス２０５ｂは、ＯＳＧｉフレームワーク２０３の機能を使用してバンドル２０４をＯＳＧｉフレームワーク２０３に登録する。このとき組み込み機器アクセスサービス２０５ｂはバンドル２０４をインストールした際にＯＳＧｉフレームワーク２０３から得られるバンドルＩＤを先ほど受け取ったＩＤと対応させて保存しておく。
次に、ＯＳＧｉフレームワーク２０３の機能を利用してＪａｖａ（登録商標）アプリケーション２０６を起動させる。Ｊａｖａ（登録商標）アプリケーション２０６ではＯＳＧｉフレームワーク２０３の機能を利用して組み込み機器アクセスサービス２０５ｂを取り出し、リソースアクセスＩ／Ｆ部２０７を利用してリソースアクセス用オブジェクトを取り出す。リソースアクセス用オブジェクトの生成処理手順について以下に説明する。

図１０は、リソースアクセス用オブジェクトの生成処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、ＯＳＧｉフレームワーク２０３の機能を利用して組み込み機器アクセスサービス２０５ｂを取り出す。このとき組み込み機器アクセスサービス２０５ｂはＯＳＧｉフレームワーク２０３の機能を利用して、自身の取り出しを行ったＪａｖａ（登録商標）アプリケーションに対応するバンドルのバンドルＩＤを取り出すことができる。このバンドルＩＤを使用してバンドル２０４をインストールした際に保存しておいた携帯電話アクセスモジュール１０２ｂのＩＤを取り出し、今後Ｊａｖａ（登録商標）アプリケーション２０６からの要求があった場合には携帯電話アクセスモジュール１０２ｂのＩＤを使用することが可能になる。

（２）更に、Ｊａｖａ（登録商標）アプリケーション２０６は、組み込み機器アクセスサービス２０５ｂから実施の形態１で説明したようなｇｅｔＥＤＲＡＸＸＸ（パラメータ）メソッドを使用してリソースアクセス用オブジェクトの取り出し要求を出す。
（３）組み込み機器アクセスサービス２０５ｂは、リソースアクセス用オブジェクトを生成する。このときパラメータとして組み込み機器アクセスサービス２０５ｂとリソースアクセス用オブジェクトの取り出しで渡されたパラメータを渡す。

（４）リソースアクセス用オブジェクトは、組み込み機器アクセスサービス２０５ｂに対して、携帯電話アクセスモジュール１０２ｂに、このリソースアクセス用オブジェクトが生成されたというリソースアクセス要求を知らせるための設定を行うよう依頼する。このとき渡されるパラメータとしては（ａ）自分自身、（ｂ）このリソースアクセス用オブジェクトのＩＤ、（ｃ）リソースのクラス名もしくはクラス名に対応するＩＤ。但しＩＤの場合は予め携帯電話アクセスモジュール１０２ｂとの間で取り決めておく必要がある。そして（ｄ）リソース用オブジェクトのＩＤ、（ｅ）メソッドのパラメータとなる。
ここで（ｂ）リソースアクセス用オブジェクトのＩＤは実施の形態１で説明したようなリソースアクセス用オブジェクトＩＤのようなユニークなＩＤであるならどのようなものでもかまわない。
また、本実施の形態では、（ｄ）リソース用オブジェクトのＩＤ（携帯電話側の実際のリソースに対応するオブジェクトとリソースアクセス用オブジェクトを対応させるためのＩＤ。実施の形態１ではこれをリソースアクセス用オブジェクトＩＤと言っている）は実施の形態１のように組み込み機器アクセスサービス２０５ｂ側で決めるのではなく、実際にリソースに対応するオブジェクトを用意する側（本実施の形態では携帯電話アクセスモジュール１０２ｂ）が決定するので、ここでは未決定であることを示す値（たとえば−１など）を設定する。

また、（ｅ）メソッドのパラメータはプリミティブや文字列の場合はそのままで、オブジェクトの場合はそのオブジェクトのリソース用オブジェクトのＩＤを設定する。パラメータは受け取り側でどのようなデータの型であるかを判断できるのでバイトに変換して転送し、受け取り側で元の型に直すようにしてもよい。またパラメータがオブジェクトの場合はＩＤを送ることになるが、本実施の形態ではパラメータに設定できるオブジェクトは携帯電話アクセスモジュール１０２ｂで用意されたオブジェクトに対応するリソースアクセス用オブジェクトのみとする。
そして、組み込み機器アクセスサービス２０５ｂは、携帯電話アクセスモジュール１０２ｂにリソースアクセス要求があることを（１）で取り出した携帯電話アクセスモジュール１０２ｂのＩＤに対応させて設定しておく。また（ｂ）のＩＤをキーとして（ａ）リソースアクセス用オブジェクトを設定しておく。これは携帯電話アクセスモジュール１０２ｂからの応答をリソースアクセス用オブジェクトに知らせるためである。

（５）携帯電話アクセスモジュール１０２ｂは、上述したように、自身に対するリソースアクセス要求の有無をチェックするために、ＨＴＴＰ要求を行う。ここでは携帯電話側通信部１０４ａは接続待ちを行えないために、サーバ２００ｂに接続して要求を出し、応答を受ける標準的なプロトコルであるＨＴＴＰを使用しているが、ＨＴＴＰと同じように要求を出して応答を受けるような通信方式であるならばどのようなものでもかまわない。
（６）組み込み機器アクセスサービス２０５ｂは、ＨＴＴＰ要求で送られてきたパラメータをチェックし、携帯電話アクセスモジュール１０２ｂのＩＤに対するリソースアクセス要求が設定されているかをチェックし、設定されていない場合はリソースアクセス要求がないというデータをＨＴＴＰ応答として返す。ここではリソースアクセス要求が設定されているので、リソースアクセス要求としてリソースアクセス用オブジェクトに対応するリソース用オブジェクトの生成という要求をＨＴＴＰ応答として返す。このとき送られるデータの書式の例を以下に示す。
（ｂ）＋（ｃ）＋（ｄ）＋（ｅ）
ここで（ｂ）、（ｃ）、（ｄ）、（ｅ）は上記（４）で説明したものである。

（７）携帯電話アクセスモジュール１０２ｂはＨＴＴＰ応答を受信し、リソースアクセス要求の有無をチェックし、リソースアクセス要求があった場合には送られてきたデータを元に、そのリソース用オブジェクトの生成を行う。
（８）そして、携帯電話アクセスモジュール１０２ｂは、リソース用オブジェクトが生成できたかどうかの結果をＨＴＴＰ要求として組み込み機器アクセスサービス２０５ｂに送信する。このときリソース用オブジェクトが生成できた場合は生成したリソース用オブジェクトのＩＤを決定し、このＩＤと生成したリソース用オブジェクトを対応付けて保存しておく。そして、このＩＤを組み込み機器アクセスサービス２０５ｂに送信する。一方、生成できなかった場合は、生成できなかったことを示す値（例えば−１など）を送信する。ここで行うＨＴＴＰ要求としてはＧＥＴもしくはＰＯＳＴで行われる。ＧＥＴの場合はクエリーに設定することになるが、文字列でデータを送る必要があるため、ＰＯＳＴのエンティティとして送る方が望ましい。またこのとき送られるデータの書式の例を以下に示す。
（ｂ）＋データサイズ＋データ
（ｂ）は（４）で説明したものである。データには上記したＩＤまたは生成できなかったことを示す値が設定される。

（９）組み込み機器アクセスサービス２０５ｂはＨＴＴＰ要求を受け取り、このＨＴＴＰのセッションを完了させるためにＨＴＴＰ応答を返す。このＨＴＴＰ応答はＨＴＴＰのセッションを正常に終わらすためのものなので特にデータなどは必要ない。
（１０）そして、組み込み機器アクセスサービス２０５ｂは、送られてきたＨＴＴＰ要求の（ｂ）から対応するリソースアクセス用オブジェクトを取り出し、データをこのリソースアクセス用オブジェクトに渡す。リソースアクセス用オブジェクトは組み込み機器アクセスサービス２０５ｂから渡されたデータをチェックし、ＩＤであれば次のアクセス時に使うため（（ｄ）として使用）にこのＩＤを保存しておく。また、もし生成出来なかったことを示す値であった場合はエラーを返すか例外をスローする。この動作は生成される元のクラスのコンストラクタのＡＰＩに依存する。
（１１）ここでリソースアクセス用オブジェクトのコンストラクタが終わるので、組み込み機器アクセスサービス２０５ｂはリソースアクセス用オブジェクトをＪａｖａ（登録商標）アプリケーション２０６に渡す。

次に、Ｊａｖａ（登録商標）アプリケーション２０６が取り出したリソースアクセス用オブジェクトを使用して携帯電話１００ｂのリソースにアクセスする場合の処理を説明する。
図１１は、このリソースアクセスの処理手順を示す説明図である。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、リソースアクセス用オブジェクトのメソッドを呼び出す。
（２）リソースアクセス用オブジェクトは、組み込み機器アクセスサービス２０５ｂに対して、携帯電話アクセスモジュール１０２ｂに、Ｊａｖａ（登録商標）アプリケーション２０６から呼び出されたメソッドに対応するリソースアクセス要求を知らせるための設定を行うよう依頼する。そして組み込み機器アクセスサービス２０５ｂは、携帯電話アクセスモジュール１０２ｂにリソースアクセス要求があることを設定しておく。
（３）携帯電話アクセスモジュール１０２ｂは、自身に対するリソースアクセス要求の有無をチェックするために、ＨＴＴＰ要求を行う。

（４）組み込み機器アクセスサービス２０５ｂは、ＨＴＴＰ要求を受け取り、携帯電話アクセスモジュール１０２ｂに対するリソースアクセス要求が設定されているかをチェックし、設定されているリソースアクセス要求をＨＴＴＰ応答として返す。このとき送られるデータの書式の例としては、本実施の形態のリソースアクセス用オブジェクトの生成処理で説明したものと同一である。但し、今回はリソース用オブジェクトのＩＤは、リソースアクセス用オブジェクトの生成時に携帯電話アクセスモジュール１０２ｂから渡されたリソース用オブジェクトのＩＤを使用する。
（５）携帯電話アクセスモジュール１０２ｂは、ＨＴＴＰ応答に設定されているリソースアクセス要求を取り出し、要求されたリソースアクセスを実行する。
（６）携帯電話アクセスモジュール１０２ｂは、リソースアクセスの実行結果をＨＴＴＰ要求として組み込み機器アクセスサービス２０５ｂに送信する。このとき、戻り値がプリミティブや文字列などネットワークを通して直接送信可能なものはそのままもしくはバイトとして送り、オブジェクトの場合はこのオブジェクトのＩＤを決定し、このＩＤとオブジェクトを対応付けて保存しておき、このＩＤを送る。

（７）組み込み機器アクセスサービス２０５ｂはＨＴＴＰ要求を受け取り、このＨＴＴＰのセッションを完了させるためにＨＴＴＰ応答を返す。
（８）そして組み込み機器アクセスサービス２０５ｂは送られてきたＨＴＴＰ要求をチェックし、リソースアクセスの実行結果をリソースアクセス用オブジェクトに渡す。
（９）リソースアクセス用オブジェクトは、渡された結果をメソッドの戻り値としてリターンする。このとき、戻り値がプリミティブや文字列の場合は（バイトに変換されて送られてきた場合は元の型に変換する必要がある）そのままリターンし、オブジェクトの場合はそのオブジェクトに対応するリソースアクセス用オブジェクトを送られてきたＩＤと組み込み機器アクセスサービス２０５ｂをパラメータとして生成し、この生成したリソースアクセス用オブジェクトをリターンする。

以上のような方法により、携帯電話のようにリソースに制限があり、接続待ちを行えないような機器に対しても、Ｊａｖａ（登録商標）アプリケーション２０６はリソースにアクセスする必要があるクラスを使用する場合に、そのオブジェクトの生成方法を変更する以外は通常のプログラミングと同様に行うことができ、またコンストラクタの代わりに呼ばれるメソッドもコンストラクタとほぼ同様な書式で記述することができるため、ネットワーク３００越しに実行するための特別なＡＰＩを学習・使用する必要もないため、Ｊａｖａ（登録商標）アプリケーションプログラマはリソースに制限のある機器を意識することなしにＯＳＧｉフレームワーク環境上のプログラムを作成することができる。

以上のように、実施の形態３のアプリケーションプラットフォーム提供システムによれば、アクセスサービスは、機器への処理要求が発生した場合に、アクセスモジュールからの接続要求待ちを行い、アクセスモジュールから接続要求があった場合にアクセス要求を行うようにしたので、機器側の負荷を軽くすることができるため、携帯電話といったリソースに制限があり接続待ちが行えない機器であっても適用することができる。

また、実施の形態３のアプリケーションプラットフォーム提供システムによれば、アクセスモジュールは、アクセスサービスからのそれまでのアクセス要求の有無に応じて、接続要求の頻度を変更するようにしたので、機器の処理への影響を最小限に抑えながら、機器側へのアクセス要求に対する応答の遅れも小さくすることができる。

また、実施の形態３のアプリケーションプラットフォーム提供システムによれば、機器として携帯電話としたので、リソースに制限のある機器が携帯電話であっても適用することができる。

実施の形態４．
図１２は、この発明の実施の形態４によるアプリケーションプラットフォーム提供システムを示す構成図である。
実施の形態４は、組み込み機器１００とサーバ２００ｃとネットワーク３００からなる。ここで、組み込み機器１００およびネットワーク３００については、実施の形態１の組み込み機器１００およびネットワーク３００と同様の構成であるため、ここでの説明は省略する。

サーバ２００ｃは、サーバＯＳ２０１、Ｊａｖａ（登録商標）ＶＭ２０２ａ、ＯＳＧｉフレームワーク２０３、バンドル２０４、バンドルインストールサービス２１１からなる。ここで、サーバＯＳ２０１、ＯＳＧｉフレームワーク２０３およびバンドル２０４は、実施の形態１と同様であるため、ここでの説明は省略する。Ｊａｖａ（登録商標）ＶＭ２０２ａには、リソースアクセスクラス管理部（アクセス管理部）２１２が設けられている。このリソースアクセスクラス管理部２１２は、組み込み機器１００側の処理についての情報を有し、Ｊａｖａ（登録商標）アプリケーション２０６から処理要求があった場合、前記の情報に基づいてその処理が組み込み機器１００での処理であるかを判定し、そうであった場合は、組み込み機器１００へのアクセス要求を行い、かつ、組み込み機器１００より処理結果を受信した場合は、その処理結果をＪａｖａ（登録商標）アプリケーション２０６に応答する機能を有している。また、リソースアクセスクラス管理部２１２は、組み込み機器１００との通信を行うためのサーバ側通信部２０８を備えている。即ち、リソースアクセスクラス管理部２１２は、組み込み機器１００のリソースへのアクセスを伴うクラスについてはＪａｖａ（登録商標）ＶＭ２０２で提供されるクラスの代わりとして使用され、Ｊａｖａ（登録商標）ＶＭ２０２で提供されるＪａｖａ（登録商標）ＡＰＩと同一のインタフェースを持つものである。バンドルインストールサービス２１１は、自身を通してインストールされたバンドルの情報をリソースアクセスクラス管理部２１２に通知するためのものである。

次に、実施の形態４の動作について説明する。
以下、サーバ２００ｃ上で動作するＪａｖａ（登録商標）アプリケーション２０６が組み込み機器１００のリソースにアクセスする実行手順について説明する。
先ず、リソースアクセスクラス管理部２１２は、サーバ側通信部２０８を使用して組み込み機器アクセスモジュール１０２からの接続を待っている。
次に、組み込み機器１００が起動して組み込み機器アクセスモジュール１０２が開始されると、組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用してリソースアクセスクラス管理部２１２に接続しに行く。接続に失敗した場合は設定ファイル等（図示しない）で指定された間隔でリトライする。

次に、組み込み機器アクセスモジュール１０２は、組み込み機器側の情報をリソースアクセスクラス管理部２１２に送信する。組み込み機器側の情報としては組み込み機器１００のＩＰアドレス、接続待ちを行うポート番号、組み込み機器ＩＤからなる。組み込み機器アクセスモジュール１０２は組み込み機器側の情報を送信した後は一旦サーバ２００との接続を切り、今度は先ほど組み込み機器側の情報として送ったポート番号で接続を待つ。
次に、組み込み機器側の情報を受け取ったリソースアクセスクラス管理部２１２は組み込み機器ＩＤをキーとして組み込み機器のＩＰアドレスおよび接続待ちを行うポート番号を登録する。

次に、バンドル２０４をバンドルインストールサービス２１１を使用し、組み込み機器ＩＤを指定してインストールする。バンドルインストールサービス２１１は、ＯＳＧｉフレームワーク２０３の機能を使用してバンドル２０４をＯＳＧｉフレームワーク２０３に登録する。このときバンドルインストールサービス２１１はバンドル２０４が指定された組み込み機器ＩＤに対応するということをリソースアクセスクラス管理部２１２に通知する。これによりバンドル２０４に関連するＪａｖａ（登録商標）アプリケーション２０６がリソースアクセスクラス管理部２１２が提供するリソースアクセスクラスを使用した場合に、どの組み込み機器へアクセスすればよいかが分かるようになる。

次に、ＯＳＧｉフレームワーク２０３の機能を利用してＪａｖａ（登録商標）アプリケーション２０６を起動させる。
Ｊａｖａ（登録商標）アプリケーション２０６が組み込み機器１００のリソースにアクセスする場合、Ｊａｖａ（登録商標）アプリケーション２０６は、何も意識することなく通常のＪａｖａ（登録商標）ＡＰＩを使用する。リソースへのアクセスを伴うクラスを使用した場合には、それはリソースアクセスクラス管理部２１２が処理することになる。即ち、リソースアクセスクラス管理部２１２は、Ｊａｖａ（登録商標）アプリケーション２０６からＪａｖａ（登録商標）ＡＰＩに対して処理要求があった場合、予め設けられた組み込み機器１００側での処理を示す情報に基づき、その処理が組み込み機器１００へのリソースアクセスが必要であるか否かを判断する。ここで、組み込み機器１００のリソースアクセスが不要な処理であった場合は、サーバ２００ｃ上でその処理を行う。一方、組み込み機器１００のリソースアクセスが必要であった場合は次の処理を行う。
先ず、Ｊａｖａ（登録商標）アプリケーション２０６を提供するバンドル２０４が組み込み機器ＩＤを指定してインストールされたのかをチェックする。もし組み込み機器ＩＤを指定してインストールされていなかった場合はローカルのリソースを使用することになり、この処理をＪａｖａ（登録商標）ＶＭ２０２ａに依頼する。一方、組み込み機器ＩＤが指定されていた場合は、その組み込み機器ＩＤで特定される組み込み機器１００と通信を行い、リソースアクセスを行うことになる。

Ｊａｖａ（登録商標）アプリケーション２０６が組み込み機器１００のリソースにアクセスする場合の処理手順は以下のようになる。
（１）Ｊａｖａ（登録商標）アプリケーション２０６は、通常のＪａｖａ（登録商標）ＡＰＩで提供されるメソッドを使用する。
（２）リソースアクセスクラス管理部２１２は、Ｊａｖａ（登録商標）アプリケーション２０６に対応する組み込み機器ＩＤから保存しておいたＩＰアドレスとポート番号を取り出し、サーバ側通信部２０８を使用して組み込み機器１００に接続する。
（３）リソースアクセスクラス管理部２１２は、呼び出されたメソッドに対応するコマンドとメソッドで与えられたパラメータを送信する。
（４）組み込み機器アクセスモジュール１０２は、組み込み機器側通信部１０４を使用して（３）で送られたデータを受け取り、このデータで指定された処理を行う。
（５）組み込み機器アクセスモジュール１０２は、（４）の結果を送信する。
（６）リソースアクセス管理部２１２は、結果を受け取り、メソッドの戻り値に応じて結果を処理し、戻り値をリターンもしくは例外をスローする。
尚、ここで各通信でやり取りされるデータの書式は実施の形態１〜３で説明したものを使用できるため、ここでの説明は省略する。

以上のような方法により、Ｊａｖａ（登録商標）アプリケーション２０６は組み込み機器１００のリソースにアクセスする必要があるクラスを使用する場合にも、全く意識する必要がない。

以上のように、実施の形態４のアプリケーションプラットフォーム提供システムによれば、所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、特定のアプリケーションプラットフォームを有するサーバとを備え、サーバは、特定のアプリケーションプラットフォームに設けられ、機器側の処理についての情報を有し、所定のアプリケーションから処理要求があった場合、その情報に基づいて処理が機器での処理であるかを判定し、そうであった場合は、機器へのアクセス要求を行い、かつ、機器より処理結果を受信した場合は、処理結果をアプリケーションに応答するアクセス管理部を備え、機器は、アクセス管理部からの処理要求を受けた場合は、機器固有の処理を行い、その処理結果をアクセス管理部に対して応答するアクセスモジュールを備えたので、アプリケーションからのアクセス要求が組み込み機器１００への固有の処理を伴うものであった場合でも、これはリソースアクセスクラス管理部によって自動的にアクセス要求されるため、アプリケーションは、機器における処理であるかを全く意識せずアクセス要求を送出することができる。

尚、上記実施の形態４において、組み込み機器１００の代わりに実施の形態３のような携帯電話１００ｂであってもよい。また、実施の形態３、４では、機器側のリソースアクセスの場合を説明したが、実施の形態２で説明したようなネイティブライブラリへのアクセスであってもよい。即ち、上記実施の形態１〜４を適宜組み合わせた構成としてもよい。
また、上記各実施の形態では、特定のアプリケーションプラットフォームとしてＪａｖａ（登録商標）ＶＭ２０２やＯＳＧｉフレームワーク２０３の例を説明したが、特にこれらに限定されるものではない。即ち、機器側ではリソースの制限により動作させることが不可能なもの（各実施の形態ではＪａｖａ（登録商標）ＶＭ）を利用するもの（各実施の形態ではＯＳＧｉフレームワーク）を提供するような構成であればどのようなものあっても適用可能である。

この発明の実施の形態１によるアプリケーションプラットフォーム提供システムを示す構成図である。 この発明の実施の形態１におけるリソースアクセス用オブジェクトの生成処理手順を示す説明図である。 この発明の実施の形態１における戻り値がネットワークを通して送信可能なものである場合の処理手順を示す説明図である。 この発明の実施の形態１における戻り値がネットワークを通して送信不可能なものである場合の処理手順を示す説明図である。 この発明の実施の形態２によるアプリケーションプラットフォーム提供システムを示す構成図である。 この発明の実施の形態２におけるネイティブライブラリのロード処理を示す説明図である。 この発明の実施の形態２による定型パラメータ方式の処理手順を示す説明図である。 この発明の実施の形態２による動的コンパイル方式の処理手順を示す説明図である。 この発明の実施の形態３によるアプリケーションプラットフォーム提供システムを示す構成図である。 この発明の実施の形態３によるリソースアクセス用オブジェクトの生成処理手順を示す説明図である。 この発明の実施の形態３によるリソースアクセスの処理手順を示す説明図である。 この発明の実施の形態４によるアプリケーションプラットフォーム提供システムを示す構成図である。

符号の説明

１００，１００ａ，１００ｃ 組み込み機器、１００ｂ 携帯電話、１０２，１０２ａ 組み込み機器アクセスモジュール、１０２ｂ 携帯電話アクセスモジュール、１０５ ネイティブライブラリ、２００，２００ａ，２００ｂ，２００ｃ サーバ、２０２ Ｊａｖａ（登録商標）ＶＭ、２０３ ＯＳＧｉフレームワーク、２０５，２０５ａ，２０５ｂ 組み込み機器アクセスサービス、２０６ Ｊａｖａ（登録商標）アプリケーション、２１２ リソースアクセスクラス管理部。

Claims (11)

1. 所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、前記特定のアプリケーションプラットフォームと前記所定のアプリケーションとを有するサーバとを備え、
   前記サーバは、
   前記特定のアプリケーションプラットフォーム上で動作し、前記アプリケーションから前記機器固有の処理に関するアクセス要求があった場合、当該アクセス要求に基づいて前記機器への処理要求を行い、かつ、前記機器より処理結果を受信した場合は、当該処理結果を前記アプリケーションに応答するアクセスサービスとを備え、
   前記機器は、
   前記アクセスサービスからの処理要求を受けた場合は、機器固有の処理を行い、その処理結果を前記アクセスサービスに対して応答するアクセスモジュールを備えたアプリケーションプラットフォーム提供システム。
2. アクセスサービスは、所定のアプリケーションから機器のリソースアクセス要求を受けた場合、リソースアクセス用オブジェクトを生成すると共に、当該リソースアクセス用オブジェクトに基づいて前記機器への処理要求を行うことを特徴とする請求項１記載のアプリケーションプラットフォーム提供システム。
3. アクセスサービスは、所定のアプリケーションから、機器上で動作するネイティブライブラリへのアクセス要求を受けた場合、前記機器へのネイティブライブラリ呼び出し要求を行い、
   アクセスモジュールは、前記ネイティブライブラリ呼び出し要求を受けた場合は、前記ネイティブライブラリへのアクセスを行うことを特徴とする請求項１記載のアプリケーションプラットフォーム提供システム。
4. アクセスモジュールは、サーバからのアクセス要求の接続待ちを行い、アクセスサービスは、機器への処理要求が発生した場合に、前記アクセスモジュールに対して接続を行うことを特徴とする請求項１から請求項３のうちのいずれか１項記載のアプリケーションプラットフォーム提供システム。
5. アクセスサービスは、機器への処理要求が発生した場合に、前記アクセスモジュールからの接続要求待ちを行い、当該アクセスモジュールから接続要求があった場合に前記アクセス要求を行うことを特徴とする請求項１から請求項３のうちのいずれか１項記載のアプリケーションプラットフォーム提供システム。
6. アクセスモジュールは、アクセスサービスからのそれまでのアクセス要求の有無に応じて、接続要求の頻度を変更することを特徴とする請求項５記載のアプリケーションプラットフォーム提供システム。
7. 所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、前記特定のアプリケーションプラットフォームを有するサーバとを備え、
   前記サーバは、
   前記特定のアプリケーションプラットフォームに設けられ、機器側の処理についての情報を有し、前記所定のアプリケーションから処理要求があった場合、前記情報に基づいて当該処理が前記機器での処理であるかを判定し、そうであった場合は、前記機器へのアクセス要求を行い、かつ、前記機器より処理結果を受信した場合は、当該処理結果を前記アプリケーションに応答するアクセス管理部を備え、
   前記機器は、
   前記アクセス管理部からの処理要求を受けた場合は、機器固有の処理を行い、その処理結果を前記アクセス管理部に対して応答するアクセスモジュールを備えたアプリケーションプラットフォーム提供システム。
8. 特定のアプリケーションプラットフォームは、Ｊａｖａ（登録商標）ＶＭと当該Ｊａｖａ（登録商標）ＶＭ上で動作する所定のフレームワークからなり、所定のアプリケーションはＪａｖａ（登録商標）アプリケーションであることを特徴とする請求項１から請求項７のうちいずれか１項記載のアプリケーションプラットフォーム提供システム。
9. 機器は、携帯電話であることを特徴とする請求項１から請求項８のうちのいずれか１項記載のアプリケーションプラットフォーム提供システム。
10. 所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器と、前記特定のアプリケーションプラットフォームと前記所定のアプリケーションとを有するサーバとを備え、
    前記アプリケーションから前記機器固有の処理に関するアクセス要求があった場合、前記特定のアプリケーションプラットフォーム上で動作するアクセスサービスが、前記アクセス要求に基づいて前記機器への処理要求を行い、
    前記機器は、前記アクセスサービスからの処理要求に基づいて機器固有の処理を行って、その処理結果を前記アクセスサービスに対して応答し、
    前記アクセスサービスは、前記機器より処理結果を受信した場合は、当該処理結果を前記アプリケーションに応答するアプリケーションプラットフォーム提供方法。
11. 所定のアプリケーションが動作するための特定のアプリケーションプラットフォームを持たない機器を構成するコンピュータと、前記特定のアプリケーションプラットフォームと前記所定のアプリケーションとを有するサーバを構成するコンピュータとを、
    前記サーバを構成するコンピュータ上で、前記特定のアプリケーションプラットフォーム上で動作し、前記アプリケーションから前記機器固有の処理に関するアクセス要求があった場合、当該アクセス要求に基づいて前記機器への処理要求を行い、かつ、前記機器より処理結果を受信した場合は、当該処理結果を前記アプリケーションに応答するアクセスサービスとして機能させ、
    前記機器を構成するコンピュータ上で、前記アクセスサービスからの処理要求を受けた場合は、機器固有の処理を行い、その処理結果を前記アクセスサービスに対して応答するアクセスモジュールとして機能させるためのアプリケーションプラットフォーム提供プログラム。

Images