JP2015207273A - 機能拡張方法、機能拡張プログラム、及び端末装置 - Google Patents

Abstract

【課題】機能拡張を迅速に行う。【解決手段】機能拡張方法において、端末装置が、１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、前記端末装置が制御する他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する。【選択図】図５

Description

本発明は、機能拡張方法、機能拡張プログラム、及び端末装置に関する。

ウェブブラウザ相当の機能を持つ実行環境において、その上で動作するＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＨＴＭＬ）５やＪａｖａｓｃｒｉｐｔ（登録商標）等のプログラミング言語を用いたアプリケーション（以下、「アプリ」と略称する）の開発が行われるようになってきている。また、アプリの実行環境に標準で搭載されていない端末の機能を利用したい場合は、その実行環境に機能を追加するプラグインを開発して拡張を行っている。また、アプリは、通信ネットワーク上に接続されたアプリサーバ等から配信されたり、端末上にあって適宜切り替えることで取得することができ、またアクセスの有無に応じてアンインストールされる。

特開２００５−２７５６６４号公報 特表２０１２−５０７０６０号公報 特開２００８−３１０４９９号公報 特開２０００−１９４５６２号公報

しかしながら、アプリ等の実行環境に機能を追加するプラグインを開発して機能拡張を行う場合、例えばＡｎｄｒｏｉｄ（登録商標）等のモバイルＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）では、プログラムが動的にライブラリをリンクする機能がない。そのため、実行環境に必要なプラグインを予め組み込んで静的にリンクしなければならない。

また、従来では、動的にプラグインをロードやアンロードすることができない。そのため、新たなプラグインを追加したい場合は、一旦実行中のアプリ実行プログラム（実行環境）を停止したり、アンインストールして、新たなプラグインを静的リンクしたアプリ実行プログラムに差し替える必要があった。

また、Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（ＧＰＳ，全地球測位網）等のセンシング機能を用いて現在位置に基づくアプリの切り替えを行う場合、実行環境の停止やアプリの再インストール等により、それまでの状態が保持できず、再設定を行う等の手間が生じた。

一つの側面では、本発明は、機能拡張を迅速に行うことを目的とする。

一つの態様では、機能拡張方法は、端末装置が、１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、前記端末装置が制御する他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する。

一つの側面として、機能拡張を迅速に行うことができる。

第１実施形態における機能拡張システムの概略構成例を示す図である。 第１実施形態における端末装置の機能構成の一例を示す図である。 端末装置のハードウェア構成の一例を示す図である。 第１実施形態における機能拡張処理の概要を説明するための図である。 第１実施形態における機能拡張処理（アプリ開始時）の一例を示すシーケンスである。 第１実施形態における機能拡張処理（アプリ実行中）の一例を示すシーケンスである。 第１実施形態における機能拡張処理（アプリ終了時）の一例を示すシーケンスである。 第１実施形態に適用される各種データ例を示す図である。 第２実施形態における機能拡張システムの概略構成例を示す図である。 第２実施形態における端末装置の機能構成の一例を示す図である。 第２実施形態における機能拡張処理の概要を説明するための図である。 第２実施形態における機能拡張処理（アプリ開始時）の一例を示すシーケンスである。 第２実施形態における機能拡張処理（アプリ実行中）の一例を示すシーケンスである。 第２実施形態における機能拡張処理（アプリ終了時）の一例を示すシーケンスである。 第２実施形態に適用される各種データ例を示す図である。 第３実施形態における機能拡張処理の概要を説明するための図である。 第３実施形態における機能拡張処理（アプリ実行中）の一例を示すシーケンスである。 第３実施形態における機能拡張処理（リスト更新）の一例を示すシーケンスである。 第３実施形態における機能拡張処理（第４のプラグイン呼び出し）の一例を示すシーケンスである。 第３実施形態に適用される各種データ例を示す図である。 第４実施形態における端末装置の機能構成の一例を示す図（その１）である。 第４実施形態における端末装置の機能構成の一例を示す図（その２）である。 第４実施形態における機能拡張処理の概要を説明するための図（その１）である。 第４実施形態における機能拡張処理の概要を説明するための図（その２）である。 第４実施形態における機能拡張処理の概要を説明するための図（その３）である。 第４実施形態における機能拡張処理の概要を説明するための図（その４）である。 状態条件判定部における機能構成の一例を示す図である。 状態条件判定部の処理内容を説明するための図である。 状態条件判定処理の一例を示すフローチャートである。 第４実施形態における機能拡張処理（条件定義登録）の一例を示すシーケンスである。 第４実施形態における機能拡張処理（条件イベント発生）の一例を示すシーケンスである。 第４実施形態におけるノードツリーの一例を示す図（その１）である。 第４実施形態におけるノードツリーの一例を示す図（その２）である。 内部イベントと条件設定の具体例を示す図である。

以下、図面に基づいて実施形態を説明する。

＜第１実施形態における機能拡張システムの概略構成例＞
図１は、第１実施形態における機能拡張システムの概略構成例を示す図である。図１に示す機能拡張システム１０は、アプリサーバ１１と、拡張機能プラグインサーバ１２と、１又は複数の端末装置１３−１〜１３−ｎ（以下、必要に応じて「端末装置１３」という）とを有する。アプリサーバ１１、拡張機能プラグインサーバ１２、及び端末装置１３は、例えばＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）やインターネット等に代表される通信ネットワーク１４によりデータの送受信が可能な状態で接続される。通信ネットワーク１４は、有線でも無線でもよく、これらの組み合わせでもよい。

アプリサーバ１１は、例えば端末装置１３が使用するアプリ一式（例えば、アプリ（例えば、処理を実行するためのソフトウェアやプログラム、ツール等）やアプリが利用する予定の機能をリストにした機能情報リスト等）を管理する。また、アプリサーバ１１は、場所等の所定の状態毎に利用可能なアプリ一式や場所等の所定の状態で利用可能な機能をリストにした機能情報リスト等を管理してもよい。アプリサーバ１１は、例えば場所等の所定の状態に対応して実行できる１又は複数のアプリ（例えば、モバイルアプリ）等を有し、端末装置１３からのアプリや他の情報の取得要求等に応じて、要求に対応するアプリ等を通信ネットワーク１４を介して端末装置１３に配信する。なお、本実施形態におけるアプリは、必ずしも一つの周辺機器１５だけを利用するものではなく、複数の周辺機器１５を利用して一つの役に立つアプリとなっている場合もある。例えば、ある環境中における周辺機器１５の例としての「赤外線センサ」と「照明」とを用いて、人が席に着いたときに、その席の照明をＯＮにするアプリ等であるがこれに限定されるものではない。

拡張機能プラグインサーバ１２は、例えば予め設定された拡張機能プラグイン（後述する第２のプラグイン）を保管する。例えば、拡張機能プラグインサーバ１２は、端末装置１３が接続する１又は複数の周辺機器（例えば、センサ）１５−１〜１５−ｎ（以下、必要に応じて「周辺機器１５」という）に対するプラグインの機能を実現するプログラムを保管する。拡張機能プラグインサーバ１２は、端末装置１３からの機能の取得要求等に応じて対応する機能を通信ネットワーク１４を介して端末装置１３に配信する。

上述したアプリサーバ１１や拡張機能プラグインサーバ１２は、例えば１つのサーバ（例えば、提供サーバ等）であってもよい。また、アプリサーバ１１や拡張機能プラグインサーバ１２は、例えばＰｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ（ＰＣ）等でもよく、一以上の情報処理装置を有するクラウドコンピューティングにより構成されるクラウドサーバ等であってもよいが、これに限定されるものではない。

端末装置１３は、アプリから周辺機器１５を接続制御する場合に、アプリを実行する実行環境に周辺機器１５の種別に関わらず共通する第１のプラグインを予め組み込み配置する。また、端末装置１３は、各周辺機器１５の各機器それぞれを制御するプログラムが格納された拡張機能プラグインを第２のプラグインとして、第１のプラグインを介して、アプリの実行環境に接続して配置する。

端末装置１３は、拡張機能プラグイン（第２のプラグイン）を用いて周辺機器１５を利用する。また、端末装置１３は、配信されたアプリが使う周辺機器１５を利用する上で必要な拡張機能プラグイン（第２のプラグイン）がない場合に、その必要な拡張機能プラグインをアプリサーバ１１に要求して取得する。

端末装置１３は、他の周辺機器１５を追加する場合には、他の周辺機器１５に対応する拡張機能プラグインを第１のプラグインを介して、アプリの実行環境に接続して配置する。また、端末装置１３は、周辺機器１５を制御する拡張機能プラグインを削除する場合には、アプリの実行環境と第１のプラグインの接続関係を維持しつつ、削除する周辺機器に対応する拡張機能プラグインを削除する。これにより、端末装置１３は、アプリが周辺機器１５を利用するための機能拡張を迅速に行うことができる。

例えば、端末装置１３は、アプリ実行部へのライブラリの動的読み込みを行うことができないＯＳにおいて、スクリプトで記述されたアプリを実行するアプリ実行部に第１のプラグインを予め組み込んでおく。また、端末装置１３は、例えば拡張機能を実行する拡張機能プラグインと、拡張機能プラグインのＯＳへのインストール状態を管理し、第１のプラグインと拡張機能プラグインとの通信を中継する拡張機能プラグイン管理部とを用いて、スクリプトに提供する機能を拡張するための複数の拡張機能の組み込みや取り外しを、アプリ実行部を実行したまま可能とする。

端末装置１３は、例えばタブレット端末、スマートフォン等のモバイル端末等であるが、これに限定されるものではなく、ＰＣやノート型ＰＣ、ゲーム機器、カメラ（撮像装置）、音楽再生装置等でもよい。

周辺機器１５は、例えばマイクやプロジェクタ、スキャナ、カメラ電子ボード、携帯情報端末機能を持つ腕時計や頭部に装着するディスプレイ等のようなウェアラブル端末等であるが、これに限定されるものではない。周辺機器１５は、例えば端末装置１３の中の加速度センサ等であってもよい。本実施形態における周辺機器１５とは、機器そのものだけでなく、例えば端末装置１３に搭載されたＯＳが提供する機能やセンサデータを取得する機能であってもよい。端末装置１３に搭載されたＯＳが提供する機能としては、例えばある所定の時刻にイベントを発行する機能があり、拡張機能プラグイン（第２のプラグイン）は、この機能を利用しアプリへ通知するプログラムを内蔵するが、これに限定されるものではない。また、端末装置１３に搭載されたセンサデータを取得するＯＳの機能を周辺機器１５として用いた拡張機能プラグイン（第２のプラグイン）の検知機能としては、例えば端末装置１３のセンサにより歩いたり、止まったこと等を検知する機能があるが、これに限定されるものではない。ここで、検知に用いられるセンサとしては、例えば加速度センサ、地磁気センサ、ジャイロセンサ、近接センサ、照度センサ、音量センサ、温度センサ、湿度センサ、気圧センサ、赤外線センサ、歩行センサ、活動量計、埃センサ、煙センサ、ガスセンサ、放射線量計、衝撃センサ、ウィルスセンサ、塩分センサ、味覚センサ等があるが、これに限定されるものではない。

周辺機器１５は、拡張機能プラグイン（第２のプラグイン）を介して、端末装置１３のアプリ実行部において、アプリによる各種制御が行われる。

例えば、第１実施形態では、端末装置１３の位置情報に対応して実行可能な周辺機器１５の情報を取得し、取得した周辺機器の情報に基づいて、周辺機器に対応する第２のプラグインの接続制御を行う。また、第１実施形態では、位置情報だけでなく、端末装置１３の位置や時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む状態変化に対応して、現在の状態で実行可能な周辺機器１５の情報を取得してもよい。

＜第１実施形態＞
次に、上述した機能拡張システム１０を用いた第１実施形態について具体的に説明する。

＜第１実施形態における端末装置１３の機能構成例＞
図１に示す端末装置１３の機能構成例について図を用いて説明する。図２は、第１実施形態における端末装置の機能構成の一例を示す図である。図２に示す端末装置１３は、入力部２１と、出力部２２と、記憶部２３と、アプリ実行部２４と、拡張機能プラグイン管理部２５と、通信部２６とを有する。

入力部２１は、ユーザ等から本実施形態における機能拡張処理に関する各種設定情報等の入力等を受け付ける。なお、入力部２１は、キーボードやマウス、タッチパネル等の入力インターフェースから入力された各種情報や指示の入力等を受け付けることができるが、これに限定されるものではない。

出力部２２は、入力部２１により入力された各種設定情報、入力された指示に対応する処理を実行した結果等を画面に表示してユーザに提示する。出力部２２は、例えばディスプレイやモニタ、タッチパネル等であるが、これに限定されるものではない。

記憶部２３は、本実施形態における端末装置１３の処理で必要な各種情報を記憶する。記憶部２３は、例えばユーザ等から入力された設定情報、アプリ、プラグイン情報、アプリサーバ１１や拡張機能プラグインサーバ１２と接続するためのアドレス情報や認証情報等を記憶するが、これに限定されるものではなく、実行結果や履歴情報エラー情報等を記憶してもよい。

アプリ実行部２４は、記憶部２３に記憶されたモバイルアプリや、アプリサーバ１１からダウンロードしたり、アプリサーバ１１から配信されたモバイルアプリを実行する。アプリ実行部２４には、予め第１のプラグイン３１が組み込まれている。アプリ実行部２４は、例えばアプリが利用する拡張機能情報（機能情報リスト）を第１のプラグイン３１へ渡したり、モバイルアプリに対して拡張機能共通のインターフェースを提供してもよい。

拡張機能プラグイン管理部２５は、例えば各周辺機器１５のそれぞれに対応する拡張機能プラグイン（第２のプラグイン）３２を、第１のプラグイン３１を介してアプリの実行環境に接続して配置する。また、拡張機能プラグイン管理部２５は、端末装置１３が制御する他の周辺機器１５を追加する場合には、アプリの実行環境と第１のプラグイン３１との接続関係を維持しつつ、他の周辺機器に対応する拡張機能プラグイン３２を第１のプラグイン３１を介してアプリの実行環境に接続して配置する。また、拡張機能プラグイン管理部２５は、端末装置１３が制御している周辺機器１５を制御する拡張機能プラグイン３２を削除する場合には、アプリの実行環境と第１のプラグイン３１の接続関係を維持しつつ、削除する周辺機器１５に対応する拡張機能プラグイン３２を削除する。

アプリ実行部２４に組み込まれた第１のプラグイン３１及び拡張機能プラグイン管理部２５は、周辺機器１５が検出する例えば現在の場所等の所定の状態毎に、その状態で利用可能な周辺機器１５を活用する機能を端末装置１３内の機能と同じインターフェースでスクリプトに提供する。第１のプラグイン３１及び拡張機能プラグイン管理部２５は、例えば会議室Ａ等の所定の場所毎に、その場所に付属する周辺機器１５を操作する機能を端末装置１３内の機能と同じインターフェースでスクリプトに提供する。第１のプラグイン３１は、例えば現在の場所等の所定の状態で利用できる機能の一覧である「状態毎の機能情報リスト」を取得し、拡張機能プラグイン管理部２５に渡す。例えば、端末装置１３の現在の場所を状態とする場合は、「状態毎の機能情報リスト」は場所毎の機能情報リストとなる。拡張機能プラグイン管理部２５は、そのリストに基づいて拡張機能プラグイン３２を拡張機能プラグインサーバ１２等から取得する。

また、拡張機能プラグイン３２は、周辺機器１５を制御するだけでなく、例えば周辺機器１５から得られたセンサ情報等を処理して、「どこに近づいた」等の情報を得るプラグインであってもよい。この場合、拡張機能プラグイン３２は、「ある場所にいる」等の場所の条件を満たす場合に、イベントを発行する。上述したアプリ実行部２４は、そのイベントを元に、アプリサーバ１１にアクセスしてアプリを取得してもよい。拡張機能プラグイン３２は、センサ情報等を処理するアルゴリズムを含んだライブラリ、又は第１のプラグインと通信する独立のアプリケーションであってもよい。

通信部２６は、通信ネットワーク１４を介してアプリサーバ１１や拡張機能プラグインサーバ１２、端末装置１３、他の外部装置とアクセスし、データの送受信を行う。

＜端末装置１３のハードウェア構成例＞
次に、端末装置１３のハードウェア構成例について図を用いて説明する。図３は、端末装置のハードウェア構成の一例を示す図である。図３の例において、端末装置１３は、マイクロフォン（以下、「マイク」という）４１と、スピーカ４２と、表示部４３と、操作部４４と、センサ部４５と、電力部４６と、無線部４７と、近距離通信部４８と、補助記憶装置４９と、主記憶装置５０と、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）５１と、ドライブ装置５２とを有し、これらはシステムバスＢで相互に接続されている。

マイク４１は、ユーザが発した音声や、その他の音を入力する。スピーカ４２は、通話相手先の音声を出力したり、着信音等の音を出力する。マイク４１及びスピーカ４２は、例えば、通話機能等により通話相手と会話するとき等に用いることができるが、これに限定されるものではなく、音声による情報の入出力に用いることができる。

表示部４３は、ユーザに対してＯＳや各種アプリケーションで設定された画面を表示する。また、表示部４３は、タッチパネルディスプレイ等でもよく、その場合には表示部４３は、入出力部としての機能を有する。

表示部４３は、例えばＬｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ（ＬＣＤ）や有機Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ（ＥＬ）等のディスプレイである。

操作部４４は、表示部４３の画面に表示された操作ボタンや端末装置１３の外部に設けられた操作ボタン等である。操作ボタンは、例えば電源ボタンや音量調整ボタンでもよく、所定の順番で配列された文字入力用の操作キー等でもよい。

ユーザは、例えば表示部４３の画面上で所定の操作を行ったり、上述した操作ボタンを押すことで、表示部４３により画面上のタッチ位置が検出される。また、表示部４３は、画面上にアプリ実行結果やコンテンツやアイコン、カーソル等を表示することができる。

センサ部４５は、端末装置１３のある時点又は継続的な動作を検出する。例えば、センサ部４５は、端末装置１３の傾き角度、加速度、方向、位置等を検出するが、これに限定されるものではない。なお、センサ部４５としては、例えば傾きセンサや加速度センサ、ジャイロセンサ、Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ（ＧＰＳ）、地磁気センサ、近接センサ、照度センサ、音量センサ、温度センサ、湿度センサ、気圧センサ、赤外線センサ、歩行センサ、活動量計、埃センサ、煙センサ、ガスセンサ、放射線量計、衝撃センサ、ウィルスセンサ、塩分センサ、味覚センサ等であるが、これに限定されるものではない。

電力部４６は、端末装置１３の各構成に対して電力を供給する。電力部４６は、例えばバッテリ等の内部電源であるが、これに限定されるものではない。電力部４６は、電力量を常時又は所定の時間間隔で検出し、電力量の残量等を監視することもできる。

無線部４７は、例えばアンテナ等を用いて基地局からの無線信号（通信データ）を受信したり、アンテナを介して無線信号を基地局に送信する通信データの送受信部である。

近距離通信部４８は、例えば赤外線通信やＷｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信手法を用いて、他の端末装置１３等のコンピュータと近距離通信を行うことができる。上述した無線部４７及び近距離通信部４８は、他のコンピュータとのデータの送受信を可能とする通信インタフェースである。

補助記憶装置４９は、例えばＨａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）やＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等のストレージ手段である。補助記憶装置４９は、ＣＰＵ５１からの制御信号に基づき、本実施形態における実行プログラム（機能拡張プログラム）や、コンピュータに設けられた制御プログラム等を記憶し、必要に応じて入出力を行う。補助記憶装置４９は、ＣＰＵ５１からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込むことができる。

主記憶装置５０は、ＣＰＵ５１からの指示により補助記憶装置４９から読み出された実行プログラム等を格納したり、プログラム実行中に得られる各種情報等を記憶する。主記憶装置５０は、例えばＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）やＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）等である。

ＣＰＵ５１は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）等の制御プログラム、及び主記憶装置５０に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御することで、出力制御における各処理を実現する。

具体的には、ＣＰＵ５１は、例えば操作部４４等から得られるプログラムの実行指示等に基づき、補助記憶装置４９にインストールされたプログラムを実行させることにより、主記憶装置５０上でプログラムに対応する処理を行う。例えば、ＣＰＵ５１は、アプリ実行部２４によるスクリプトの実行、拡張機能プラグイン管理部２５によりプラグインの配置、実行、削除、通信部２６によるデータの送受信等の処理を行う。ＣＰＵ５１における処理内容は、上述した内容に限定されるものではない。ＣＰＵ５１により実行された内容は、必要に応じて補助記憶装置４９等に記憶される。

ドライブ装置５２は、例えば記録媒体５３等を着脱自在にセットすることができ、セットした記録媒体５３に記録された各種情報を読み込んだり、所定の情報を記録媒体５３に書き込むことができる。ドライブ装置５２は、例えば媒体装填スロット等であるが、これに限定されるものではない。

記録媒体５３は、上述したように実行プログラム等を格納するコンピュータで読み取り可能な記録媒体である。記録媒体５３は、例えばフラッシュメモリ等の半導体メモリであってもよい。また、記録媒体５３は、ＵＳＢメモリ等の可搬型記録媒体であってもよいが、これに限定されるものではない。

本実施形態では、上述したコンピュータ本体のハードウェア構成に実行プログラム（例えば、機能拡張プログラム等）をインストールすることで、ハードウェア資源とソフトウェアとが協働して本実施形態における表示処理等を実現することができる。

また、上述した表示処理に対応する機能拡張プログラムは、例えば装置上で常駐している状態であってもよく、起動指示により起動させてもよい。

＜第１実施形態における機能拡張処理の概要＞
図４は、第１実施形態における機能拡張処理の概要を説明するための図である。図４の例では、アプリサーバ１１と、拡張機能プラグインサーバ１２と、端末装置１３の各処理内容が概略的に示されている。

第１実施形態において、端末装置１３は、アプリの一例であるモバイルアプリ６１と、アプリ実行部２４と、第１のプラグイン３１と、拡張機能プラグイン管理部２５と、拡張機能プラグイン（第２のプラグイン）３２ａ，３２ｂとを有する。拡張機能プラグイン３２ａは、例えばディスプレイによる通知機能や音声発話機能、目線検出機能等であり、Ｂｌｕｅｔｏｏｔｈ（登録商標）等により周辺機器１５−１と接続されている。また、拡張機能プラグイン３２ｂは、動き検出機能であり、例えば加速度センサ１５−２等と接続されている。

モバイルアプリ６１は、例えばＨＴＭＬ５、Ｊａｖａｓｃｒｉｐｔ等の所定のプログラミング言語を用いて開発されたアプリの一例であり、ウェブアプリ等でもよい。モバイルアプリ６１は、アプリサーバ１１から取得してもよく、記憶部２３等に記憶されていてもよい。

アプリ実行部２４は、アプリ実行環境の一例であり、上述したモバイルアプリ等を実行する。アプリ実行部２４は、例えばＨＴＭＬ５とＪａｖａｓｃｒｉｐｔプログラムを実行するＷｅｂブラウザのような仮想マシンであるが、これに限定されるものではない。

第１実施形態における機能拡張処理では、アプリ実行部２４や他の機能（ソフトウェア機能）を動作させたまま、必要な拡張機能のインストールやアンインストールを可能にする。そのため、第１の実施形態では、例えばアプリ実行部２４に予め１つのプラグイン（第１のプラグイン３１）を組み込んでおき、モバイルアプリ６１に共通のインターフェース（ＩＦ）を提供する。また、端末装置１３は、拡張機能の管理機能（拡張機能プラグイン管理部２５）を有し、インストール時やアンインストール時にモバイルアプリ６１と各拡張機能（拡張機能プラグイン３２）との通信を中継する。

例えば、拡張機能プラグイン管理部２５は、アプリサーバ１１から得られるモバイルアプリ６１が利用する予定の状態毎の機能情報リスト６２にあり、インストールされていない拡張機能を拡張機能プラグインサーバ１２から取得しインストールを行う端末装置１３内の機能管理を行う。

拡張機能プラグイン３２は、例えば端末装置１３内のセンシング機能や周辺機器１５を利用するためのインターフェースの拡張を行う。また、拡張機能プラグイン３２は、例えば、端末装置１３内の拡張機能プラグイン管理とプログラム間通信を行う共通のインターフェースを持たせた独立アプリケーション（第２のプラグイン）である。

なお、図４の例において、拡張機能プラグインサーバ１２に端末種別の項目が設けられている。これは、例えばＡ社製の端末装置とＢ社製の端末装置とにおいて、Ａ社製の端末装置では独自のマイコンを搭載し、その中のプログラムで加速度センサデータ等を処理して歩行検知ができるが、Ｂ社製の端末装置ではマイコンがなく加速度センサデータ等を処理する端末のＣＰＵ上で動作するプログラムで歩行検知を実行する場合がある。このような場合に、拡張機能プラグインのＡ社版は、マイコンと通信するプログラムになり、Ｂ社の端末装置は加速度センサの値を取って処理するプログラムになる。このように、実行内容が異なるため、端末種種別毎に異なる拡張機能プラグインが予め用意され、機種に対応する拡張機能プラグインが拡張機能プラグインサーバ１２から提供される。

＜第１実施形態における機能拡張処理の一例を示すシーケンス＞
図５は、第１実施形態における機能拡張処理（アプリ開始時）の一例を示すシーケンスである。図５の例では、モバイルアプリ６１、アプリ実行部２４、アプリサーバ１１、第１のプラグイン３１、拡張機能プラグイン管理部２５、拡張機能プラグイン（第２のプラグイン）３２、及び拡張機能プラグインサーバ１２を用いた処理の一例を示している。

図５の例では、例えばユーザからの指示やＧＰＳ機能を用いたジオフェンシング等により、ある場所（位置）に入ったというイベントをモバイルアプリ６１の切り替えトリガとしてモバイルアプリ６１を開始する。ジオフェンシング機能は、拡張機能プラグイン（第２のプラグイン）３２として実行され、拡張機能プラグインから第１のプラグイン３１を介してイベントをアプリ実行部２４に発行してもよい。なお、モバイルアプリ６１の開始は、これに限定されるものではなく、例えばユーザの画面操作等の所定の動作をトリガとしてモバイルアプリ６１を開始してもよい。なお、イベントは、モバイルアプリ６１の開始や停止、切替だけに用いるのではなく、その情報をモバイルアプリ６１に通知し、それをモバイルアプリ６１が受けて利用してもよい。例えば、ユーザが入った場所に関連する情報を提示する等に利用することができる。

図５の例において、ある場所に入った場合等の状態変化情報に基づいてモバイルアプリ６１の切り替えイベントがアプリ実行部２４に入力される（Ｓ０１）。アプリ実行部２４は、実行対象のモバイルアプリ６１が記憶部２３にあるか否かを判断し、記憶部２３にない場合にアプリサーバ１１にアプリ取得要求を行う（Ｓ０２）。取得要求時のパラメータとしては、場所情報（位置情報）等であるが、これに限定されるものではない。

次に、アプリ実行部２４は、アプリサーバ１１から場所情報に関連付けられたモバイルアプリ６１一式（例えば、アプリやアプリに対応する機能情報リスト等）を受信する（Ｓ０３）。なお、アプリ実行部２４は、記憶部２３にモバイルアプリ６１が存在する場合は、アプリサーバ１１にアクセスせずに記憶部２３から対象のモバイルアプリ６１を取得する。

次に、アプリ実行部２４は、アプリＩＤを生成し、モバイルアプリ６１一式から取り出した機能情報リストに登録して第１のプラグイン３１に送信する（Ｓ０４）。機能情報リストは、例えばそのモバイルアプリ６１が使う拡張機能のリストを意味する。

第１のプラグイン３１は、機能情報リストを拡張機能プラグイン管理部２５に登録する（Ｓ０５）。拡張機能プラグイン管理部２５は、後述するインストール済み機能情報リストと比較し、インストールされていない機能を拡張するため、拡張機能プラグインサーバ１２に取得要求を行う（Ｓ０６）。取得要求時のパラメータとしては、例えば機能名、機種名、バージョン情報等があるが、これに限定されるものではない。拡張機能プラグイン管理部２５は、拡張機能プラグインサーバ１２から未インストール機能一式を受信する（Ｓ０７）。

次に、拡張機能プラグイン管理部２５は、受信した未インストール機能一式に基づいて、端末装置１３内の機能プログラム（拡張機能プラグイン３２）をインストールし（Ｓ０８）、対応するプラグイン名（一意名）等を登録する（Ｓ０９）。Ｓ０９の処理では、例えばプラグイン名以外にもバージョン情報等を登録することができる。

次に、拡張機能プラグイン管理部２５は、アプリ実行部２４に対して準備完了通知を行う（Ｓ１０）。アプリ実行部２４は、拡張した機能に対応するモバイルアプリ６１に処理を開始させる（Ｓ１１）。

図６は、第１実施形態における機能拡張処理（アプリ実行中）の一例を示すシーケンスである。図６の例では、モバイルアプリ６１、アプリ実行部２４、第１のプラグイン３１、拡張機能プラグイン管理部２５、及び拡張機能プラグイン３２を用いた処理の一例を示している。

図６の例において、モバイルアプリ６１は、例えば第１のプラグイン３１等に対して機能名と指示で呼び出す（Ｓ２１）。例えば、機能名「歩行検出」に対して、指示「歩行開始イベント通知」等で呼び出す。第１のプラグイン３１は、呼び出しＩＤを生成し、生成した呼び出しＩＤやコールバック関数（例えば、プログラム中で、呼び出し先が処理を実行して完了した時やエラーが発生した時に、呼び出し元に通知するために、予め指定しておく関数）等を保存する。

ここで、第１のプラグイン３１は、拡張機能プラグイン管理部２５を呼び出す（Ｓ２２）。拡張機能プラグイン管理部２５は、機能情報リスト６２を参照して機能名からプラグイン名（一意名）を取得し、対応する端末装置１３内の拡張機能プラグイン３２を呼び出す（Ｓ２３）。拡張機能プラグイン３２は、指示に従って処理を実行し、処理の完了通知や、状態変更イベント等の発行を行う（Ｓ２４）。

次に、拡張機能プラグイン管理部２５は、第１のプラグイン３１に出力する（Ｓ２５）。第１のプラグイン３１は、呼び出しＩＤからコールバック関数を特定し、コールバック関数を呼び出し、モバイルアプリ６１にイベントが発行された旨の情報等を出力する（Ｓ２６）。上述したような条件変更は、例えば場所やユーザの状況等に応じて実行するアプリを切り替える場合に必要となる。

図７は、第１実施形態における機能拡張処理（アプリ終了時）の一例を示すシーケンスである。図７の例では、アプリ実行部２４、モバイルアプリ６１、第１のプラグイン３１、拡張機能プラグイン管理部２５、及び拡張機能プラグイン３２を用いた処理の一例を示している。また、図７の例では、ある場所（位置情報）から離れる（退く）場合に発生するイベントをトリガとしてモバイルアプリ６１を終了する例を示しているが、モバイルアプリ６１終了時の処理を行うトリガは、これに限定されるものではない。例えば、「教室Ａで１時限目が開始」というような、場所と時間との組み合わせ条件をイベントとしてもよく、またセンサ情報により検出した「車で移動開始」といった場所に限らない状況によるイベントでもよい。

図７の例において、ある場所から離れたことを検知することで発生したアプリ切り替えイベントがアプリ実行部２４に入力されると（Ｓ３１）、モバイルアプリ６１に該当アプリの停止指示を出力する（Ｓ３２）。モバイルアプリ６１は、指示されたアプリを停止し、停止が完了した旨の通知をアプリ実行部２４に出力する（Ｓ３３）。

アプリ実行部２４は、停止したモバイルアプリ６１に対応する機能情報リストの削除要求を第１のプラグイン３１に出力する（Ｓ３４）。削除要求時のパラメータとしては、例えばアプリＩＤ等があるが、これに限定されるものではない。

次に、第１のプラグイン３１は、アプリ実行部２４から取得した機能情報リストの削除要求を受け取ると、その内容を拡張機能プラグイン管理部２５に出力する（Ｓ３５）。拡張機能プラグイン管理部２５は、指定アプリＩＤの機能情報リスト削除、残りの機能情報リスト（残リスト）とインストール済み機能情報リストとの照合を行い、不要機能の抽出を行う。不要機能とは、例えば所定時間以上使用されていない機能やバージョンが古い機能等があるが、これに限定されるものではない。

そして、拡張機能プラグイン管理部２５は、端末装置１３内の不要な拡張機能プラグイン３２を呼び出し、その不要な拡張機能プラグイン３２をアンインストールする（Ｓ３６）。拡張機能プラグイン管理部２５は、アンインストールされた拡張機能プラグイン３２に対応する情報をインストール済み機能情報リストから削除する（Ｓ３７）。なお、不要な拡張機能プラグイン３２は、上述したように必ずアンインストールするのではなく、停止した状態で再度利用されるまでそのまま保存しておいてもよい。

上述した図７の例では、端末装置１３が制御する周辺機器に対応する第２のプラグインを削除する場合に、アプリケーションの実行環境と第１のプラグインとの接続関係を維持しつつ、削除対象の周辺機器に対応する第２のプラグインが削除される。

＜第１実施形態に適用される各種データ例＞
図８は、第１実施形態に適用される各種データ例を示す図である。図８（Ａ）は、第１のプラグイン３１で管理されるデータ例を示す。図８（Ｂ）は、拡張機能プラグイン管理部２５で管理されるデータ例を示す。

図８（Ａ）に示す第１のプラグイン３１のデータには、アプリＩＤ毎のモバイルアプリ６１が利用する機能情報リスト６２ａが存在する。機能情報リスト６２ａの項目としては、例えば「機能」、「バージョン等条件」等があるが、これに限定されるものではない。機能は、対応するアプリＩＤが利用する１又は複数の機能を識別するための情報である。バージョン等条件は、その機能を利用するためのアプリのバージョン情報等の各種条件を示す情報である。

図８（Ｂ）に示す拡張機能プラグイン管理部２５のデータには、端末装置１３にインストールされた拡張機能プラグイン３２の情報であるインストール済み機能情報リスト６２ｂが存在する。また、第１のプラグイン３１から取得した、アプリＩＤ毎の機能情報リスト６２ａが存在する。

例えば、アプリＩＤ＝０００１が「ｎｏｔｉｆｙ」機能を開始する場合に、拡張機能プラグイン管理部２５で「ｎｏｔｉｆｙ」機能に対応する拡張機能プラグイン３２がインストールされ、図８（Ｂ）に示すように、その拡張された「ｎｏｔｉｆｙ」機能に対応するプラグイン名（一意名）とバージョン情報等の条件がインストール済み機能情報リスト６２ｂに登録される。これにより、アプリＩＤ＝０００１のアプリで、インストールされた「ｎｏｔｉｆｙ」機能が実行可能となる。

また、第１実施形態において、モバイルアプリ６１終了時には、例えば図８（Ａ）に示す第１のプラグイン３１の対象のアプリに関する機能情報リスト６２ａが削除され、また上述した拡張機能プラグイン管理部２５の対象のアプリに関する機能情報リスト６２ａが削除される。また、拡張機能プラグイン管理部２５が保持する全ての機能情報リスト６２ａ，６２ｂにない機能の拡張機能プラグインがアンインストールされ、図８（Ｂ）に示すインストール済み機能情報リスト６２ｂから削除される。図８（Ａ），（Ｂ）に示す各データは、例えばアプリＩＤ毎に設定されているが、これに限定されるものではない。

上述したように、第１実施形態によれば、アプリ実行部２４や他の機能を動作させたまま、必要な拡張機能のインストールやアンインストールを可能にする。そのため、アプリが周辺機器を利用するための機能拡張を迅速に行えるようにすることができる。

例えば、第１実施形態では、端末装置１３は、実行プログラムへのライブラリの動的読み込みを行うことができないＯＳ等において、アプリ実行部２４に予め組み込む一つの第１のプラグイン３１と、拡張機能を実行する拡張機能プラグイン（第２のプラグイン）３２とを有する。また、端末装置１３は、拡張機能プラグイン３２のＯＳへのインストール状態を管理し、第１のプラグイン３１と拡張機能プラグイン３２との通信を中継する拡張機能プラグイン管理部２５により、スクリプトに提供する機能を拡張するための複数の拡張機能の組み込み・取り外しを、アプリ実行部２４を実行したまま可能とする。

また、第１実施形態では、端末装置１３が、アプリサーバ１１等の外部装置から実行するモバイルアプリ６１とセットでそのモバイルアプリ６１が利用する機能情報リスト６２を取得する。また、モバイルアプリ６１実行時に、機能情報リスト６２に基づいて、拡張機能プラグイン管理部２５が拡張機能プラグイン３２のインストール状況を確認し、インストールされていない拡張機能プラグイン３２を拡張機能プラグインサーバ１２等の外部装置から取得してインストールする。また、端末装置１３は、モバイルアプリ６１が実行終了されたとき、対応する機能情報リスト６２も拡張機能プラグイン管理部２５から削除し、拡張機能プラグイン管理部２５が保持する全ての機能情報リスト６２になくなった拡張機能プラグイン３２はアンインストールする。

これにより、第１実施形態では、例えば実行するアプリや場所によって異なる拡張機能を利用したいときに、アプリ実行部２４を停止して実行プログラム毎に差し替える必要がなくなる。また、第１実施形態では、例えば場所等のセンサ処理情報に応じて、アプリを切り替えて、そのときの端末装置１３の状態に応じたサービスを提供することを、シームレスに行うことができる。

＜第２実施形態における機能拡張システムの概略構成例＞
次に、第２実施形態について説明する。図９は、第２実施形態における機能拡張システムの概略構成例を示す図である。なお、図９に示す機能拡張システム１０'において、上述した第１実施形態における機能拡張システム１０と同様の構成については、同一の符号を付するものとし、具体的な説明は省略する。

図９に示す機能拡張システム１０'は、アプリサーバ１１'と、拡張機能プラグインサーバ１２'と、１又は複数の端末装置１３'−１〜１３'−ｎ（以下、必要に応じて「端末装置１３'」という）と、１又は複数のサーバ１６−１〜１６−ｎ（以下、必要に応じて「サーバ１６」という）と、拡張機能プラグイン管理装置１７とを有する。アプリサーバ１１'、拡張機能プラグインサーバ１２'、端末装置１３'、サーバ１６、及び拡張機能プラグイン管理装置１７は、通信ネットワーク１４によりデータの送受信が可能な状態で接続される。

アプリサーバ１１'は、例えば端末装置１３'が使用するモバイルアプリ一式を保管する。また、アプリサーバ１１'は、場所等の所定の状態毎に利用可能なモバイルアプリ一式や場所等の所定の状態で利用可能な機能情報リスト等を管理してもよい。アプリサーバ１１'は、例えば場所等の所定の状態に対応して実行できる１又は複数のアプリ等を有し、端末装置１３'からのアプリや他の情報の取得要求等に応じて、要求に対応するアプリ等を通信ネットワーク１４を介して端末装置１３'に配信する。

なお、本実施形態におけるモバイルアプリは、必ずしも一つの周辺機器１５、周辺機器１５'や一つのサーバ１６だけを利用するものではなく、複数の周辺機器１５や周辺機器１５'、サーバ１６を利用して一つの役に立つモバイルアプリとなっている場合もある。例えば、ある環境中におけるサーバ１６と周辺機器１５の例としての「メールサーバ」と「照明」とを用いて、メールが到着したら照明をＯＮにするモバイルアプリ等があるがこれに限定されるものではない。

拡張機能プラグイン管理装置１７は、端末装置１３'の第１のプラグインとネットワークを介して接続し、拡張機能プラグイン（上述した第２のプラグイン又は後述する第３のプラグイン）を配置し、端末装置１３'から拡張機能プラグインを利用可能とする。

拡張機能プラグインサーバ１２'は、例えば予め設定された拡張機能プラグイン（上述した第２のプラグイン又は後述する第３のプラグイン）を保管する。例えば、拡張機能プラグインサーバ１２'は、拡張機能プラグイン管理装置１７が接続する１又は複数の周辺機器（例えば、センサ）１５'−１〜１５'−ｎ（以下、必要に応じて「周辺機器１５'」という）、又はサーバ１６に対する拡張機能プラグインを保管する。拡張機能プラグインサーバ１２'は、拡張機能プラグイン管理装置１７からの機能の取得要求等に応じて対応する機能を通信ネットワーク１４を介して拡張機能プラグイン管理装置１７に配信する。

アプリサーバ１１'、拡張機能プラグインサーバ１２'、サーバ１６、及び拡張機能プラグイン管理装置１７は、例えばＰＣ等でもよく、一以上の情報処理装置を有するクラウドコンピューティングにより構成されるクラウドサーバ等であってもよいが、これに限定されるものではない。

端末装置１３'は、アプリから周辺機器１５'又はサーバ１６を接続制御する場合に、モバイルアプリを実行するアプリ実行部２４に周辺機器１５又はサーバ１６の種別に関わらず共通する第１のプラグインを予め組み込み配置する。また、端末装置１３'は、拡張機能プラグイン管理装置１７に指示して、各周辺機器１５'又は各サーバ１６の各機器それぞれを制御するプログラムが格納された拡張機能プラグインを第２のプラグインとして、又は、各サーバを制御するプログラムが格納された拡張機能プラグインを第３のプラグインを配置させ、第１のプラグインと拡張機能プラグイン管理装置１７を介して、拡張機能プラグインをアプリの実行環境に接続する。

端末装置１３'は、周辺機器１５'又はサーバ１６を接続して利用するための拡張機能プラグインを拡張機能プラグイン管理装置１７を介してアプリ実行部２４に接続し、周辺機器１５'又はサーバ１６を利用する。また、拡張機能プラグイン管理装置１７は、周辺機器１５'又はサーバ１６を利用する上で必要な機能がない場合に、その必要な機能を拡張機能プラグインサーバ１２'に要求して対応する機能を取得する。

端末装置１３'は、他の周辺機器１５'又はサーバ１６を追加する場合には、拡張機能プラグイン管理装置１７に指示して、他の周辺機器１５'又はサーバ１６に対応する拡張機能プラグインを配置させ、第１のプラグインを介して、アプリの実行環境に接続する。また、端末装置１３'は、周辺機器１５'又はサーバ１６を制御する拡張機能プラグインを削除する場合には、アプリの実行環境と第１のプラグインの接続関係を維持しつつ、拡張機能プラグイン管理装置１７に指示して、削除する周辺機器１５'又はサーバ１６に対応する拡張機能プラグインを削除する。これにより、端末装置１３'は、モバイルアプリが周辺機器１５'又はサーバ１６を利用するための機能拡張を迅速に行うことができる。

サーバ１６は、例えばメールサーバやニュースサーバ等の他システムであるが、これに限定されるものではない。第２実施形態において、拡張機能プラグイン（第３のプラグイン）は、例えばサーバ１６のような、他のシステムの変化を検知し通知する機能であるが、これに限定されるものではない。例えば、メールサーバに新着メールがあったこと、ニュースサーバに新着ニュースがあったこと等、サーバ１６からの通知情報の少なくとも一つを発行する機能等がある。サーバ１６は、拡張機能プラグイン（第３のプラグイン）を介して、端末装置１３のアプリ実行部において、アプリ等による各種制御が行われる。

第２実施形態において、例えばユーザは、端末装置１３を持って移動し、様々な場所で周辺機器１５'又はサーバ１６等を利用することが想定される。このような場合、場所に応じて利用できる周辺機器１５又はサーバ１６は異なり、周辺機器１５'又はサーバ１６との接続インターフェースも異なる。この場合、従来では、それぞれの場所に応じたアプリと、アプリ実行プログラムと、プラグインとのセットを準備する必要があった。

そこで、第２実施形態では、例えば会議室Ａ等の所定の場所等の状態毎に、その場所に付属する周辺機器１５'を操作する機能（場所等の状態依存機能）やサーバ１６を制御する機能等を、第１実施形態に示した端末装置１３内の機能と同じインターフェースを拡張機能プラグイン管理部で用意して通信ネットワーク１４上に公開する。なお、第２実施形態では、第１実施形態における拡張機能プラグイン管理部に対応して実行される処理を（端末内）拡張機能プラグイン管理部とし、通信ネットワーク１４上で実行される拡張機能プラグイン管理部と同じ処理を（ネットワーク上）拡張機能プラグイン管理部とする。

例えば、（ネットワーク上）拡張機能プラグイン管理部は、その場所にある外部装置（ＰＣ）等の拡張機能プラグイン管理装置１７に設けられ、場所等の状態に付属する周辺機器１５又はサーバ１６は、アプリサーバ１１や外部装置等に接続される。なお、拡張機能プラグイン管理装置１７、サーバ１６、アプリサーバ１１'、拡張機能プラグインサーバ１２'は一つの外部装置（ＰＣ等）でもよい。また、場所等の状態に付属する周辺機器１５'又はサーバ１６への制御等は、（ネットワーク上）拡張機能プラグイン管理部を介して端末装置１３'から、モバイルアプリ等により実行される。

上述したように、第２実施形態では、端末装置１３'が、１又は複数のサーバ１６を制御するアプリケーションの実行環境に、サーバ１６に共通する第１のプラグインを接続し、サーバ１６のそれぞれに対応する第３のプラグインを、第１のプラグインを介してアプリケーションの実行環境に接続されるように配置する。また、端末装置１３'が制御する他のサーバを追加する場合に、アプリケーションの実行環境と第１のプラグインとの接続関係を維持しつつ、他のサーバに対応する第３のプラグインを、拡張機能プラグイン管理装置１７と第１のプラグインを介してアプリケーションの実行環境に接続する。

また、端末装置１３'が制御するサーバ１６に対応する第３のプラグインを削除する場合に、アプリケーションの実行環境と第１のプラグインとの接続関係を維持しつつ、削除対象のサーバに対応する第３のプラグインを削除する。

また、上述したように、第２実施形態では、端末装置１３'が、１又は複数の周辺機器１５'を制御するアプリケーションの実行環境に、周辺機器１５'とサーバ１６に共通する第１のプラグインを接続し、周辺機器１５'のそれぞれに対応する第２のプラグイン又はサーバ１６のそれぞれに対応する第３のプラグインを、拡張機能プラグイン管理装置１７と第１のプラグインを介してアプリケーションの実行環境に接続されるように配置する。また、端末装置１３'が制御する他の周辺機器を追加する場合に、アプリケーションの実行環境と第１のプラグインとの接続関係を維持しつつ、他の周辺機器に対応する第２のプラグインを、拡張機能プラグイン管理装置１７と第１のプラグインを介してアプリケーションの実行環境に接続する。

また、端末装置１３'が制御する周辺機器１５'に対応する第３のプラグイン又はサーバ１６に対応する第３のプラグインを削除する場合に、アプリケーションの実行環境と第１のプラグインとの接続関係を維持しつつ、削除対象のサーバに対応する第２のプラグインを削除する。

＜第２実施形態における端末装置１３'の機能構成例＞
図１０は、第２実施形態における端末装置の機能構成の一例を示す図である。なお、以下の説明では、第１実施形態における端末装置１３と異なる部分について具体的に説明する。また、図１０に示す端末装置１３'において、図２に示す第１実施形態における端末装置１３と同様の構成については、同一の番号を付するものとし、ここでの具体的な説明は省略する。

図１０に示す端末装置１３'は、入力部２１と、出力部２２と、記憶部２３と、アプリ実行部２４と、（端末内）拡張機能プラグイン管理部２５−１と、通信部２６とを有する。第２実施形態において、アプリ実行部２４は、端末装置１３'が所定の場所に入った場合に、その位置情報に対応させてアプリの切り替えイベントが発生した場合に、アプリサーバ１１からモバイルアプリを取得したり、モバイルアプリに対応する機能情報リストの取得を行う。この場合、アプリ実行部２４は、例えば場所情報等を送信して、場所に対応するモバイルアプリ等を取得する。

アプリ実行部２４は、上述した（端末内）拡張機能プラグイン管理部２５−１や（ネットワーク上）拡張機能プラグイン管理部２５−２に拡張機能情報（例えば、機能情報リスト６２）を渡す。また、アプリ実行部２４は、（端末内）拡張機能プラグイン管理部２５−１や（ネットワーク上）拡張機能プラグイン管理部２５−２とアプリ間を中継する。ここで、（端末内）拡張機能プラグイン管理部２５−１は、機能情報リストに基づいて（端末内）拡張機能プラグイン（第２のプラグイン）３２−１を拡張機能プラグインサーバ１２'等から取得し、インストールしたりアンインストールしたりする。また、（端末内）拡張機能プラグイン管理部２５−１は、第１のプラグイン３１と（端末内）拡張機能プラグイン（第２のプラグイン）３２−１間通信（例えば、アプリからの呼び出しやアプリへのイベント）を中継する。

また、（ネットワーク上）拡張機能プラグイン管理部２５−２は、端末装置１３'の通信部２６から送信された機能情報リスト６２（その場所等の所定の状態にある機能の一覧である「所定の状態における機能情報リスト６２」）を受信する。また、（ネットワーク上）拡張機能プラグイン管理部２５−２は、受信した機能情報リスト６２に基づいて場所毎に登録された（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２又は拡張機能プラグイン（第３のプラグイン）３３を通信ネットワーク１４を介して拡張機能プラグインサーバ１２等から取得し、所定の装置等に配置する。また、（ネットワーク上）拡張機能プラグイン管理部２５−２は、第１のプラグイン３１と（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２との間の通信（例えば、アプリからの呼び出しやアプリへのイベント）、又は（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３との間の通信を中継する。アプリ実行部２４は、インストール等により実行準備が完了すると、アプリを実行する。

なお、（端末内）拡張機能プラグイン管理部２５−１は、端末装置１３'が制御する他の周辺機器１５を追加する場合には、アプリの実行環境と第１のプラグイン３１との接続関係を維持しつつ、他の周辺機器に対応する（端末内）拡張機能プラグイン３２−１を第１のプラグイン３１を介してアプリの実行環境に接続して配置する。また、（端末内）拡張機能プラグイン管理部２５−１は、端末装置１３'が制御している周辺機器１５を制御する（端末内）拡張機能プラグイン３２−１を削除する場合には、アプリの実行環境と第１のプラグイン３１の接続関係を維持しつつ、削除する周辺機器１５に対応する（端末内）拡張機能プラグイン３２−１を削除する。

また、（ネットワーク上）拡張機能プラグイン管理部２５−２も（端末内）拡張機能プラグイン管理部２５−１と同様に、アプリの実行環境と第１のプラグイン３１との接続関係を維持しつつ、周辺機器１５'又はサーバ１６に対応する（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２又は（ネットワーク上）拡張機能プラグイン３３（第３のプラグイン）の追加や削除を行うことができる。

また、拡張機能プラグイン３２−１，３２−２は、周辺機器１５'を制御するだけでなく、例えば周辺機器１５'から得られたセンサ情報等を処理して、「どこに近づいた」等の情報を得るプラグインであってもよい。この場合、拡張機能プラグイン３２−１，３２−２は、「ある場所にいる」等の場所の条件を満たす場合に、イベントを発行する。

また、拡張機能プラグイン３３は、サーバ１６の変化をアプリに通知するプラグインであってもよい。この場合、拡張機能プラグイン３３は、例えばメールの新着があった場合に、イベントを発行する。

上述したアプリ実行部２４は、そのイベントを元に、対応するモバイルアプリを実行したり、対応するモバイルアプリがない場合にアプリサーバ１１'からモバイルアプリを取得してもよい。

通信部２６は、通信ネットワーク１４を介してアプリサーバ１１'や拡張機能プラグインサーバ１２'、端末装置１３'、他の外部装置とアクセスし、データの送受信を行う。更に、第２実施形態における通信部２６は、（ネットワーク上）拡張機能プラグイン管理部２５−２との通信を行う。

第２実施形態において、第１のプラグイン３１は、アプリ実行部２４が実行するモバイルアプリが利用する機能を記載した機能情報リストを取得し、取得した機能情報リストから周辺機器１５又は周辺機器１５'を利用できる機能が、端末内又はネットワーク上にない場合に、（端末内）拡張機能プラグイン管理部２５−１又は（ネットワーク上）拡張機能プラグイン管理部２５−２に指示し、周辺機器１５又は周辺機器１５'に対応する第２のプラグインを端末内又はネットワーク上から選択して取得させてもよい。

＜第２実施形態における機能拡張処理の概要＞
図１１は、第２実施形態における機能拡張処理の概要を説明するための図である。上述したように、第２実施形態では、（端末内）拡張機能プラグイン管理部２５−１と、通信ネットワーク１４上で実行される（ネットワーク上）拡張機能プラグイン管理部２５−２とを有する。

第２実施形態において、（ネットワーク上）拡張機能プラグイン管理部２５−２は、例えば、その場所にある外部装置（ＰＣ）等の拡張機能プラグイン管理装置１７に設けられ、周辺機器１５'又はサーバ１６は、例えば、拡張機能プラグイン管理装置１７等の外部装置に接続される。また、場所等の所定の状態に付属する周辺機器１５'−３，１５'−４又はメールサーバ１６−１への制御等は、（ネットワーク上）拡張機能プラグイン管理部２５−２を介して端末装置１３'のモバイルアプリ６１により実行される。

第２実施形態では、端末装置１３'が場所情報を通知すると、通知された場所情報（位置情報）等の状態毎のアプリサーバ１１'が、機能情報リスト６２として、端末内機能情報リストとその状態における機能情報リストとを結合させて、端末装置１３に配信する。なお、アプリサーバ１１'は、状態別毎に、アプリとそのアプリが利用する機能情報リスト１１ａ'を定義することができる。

端末装置１３'では、第１のプラグイン３１等が機能管理を行い、機能情報リスト６２を参照して、各機能をモバイルアプリ６１から利用可能にする。例えば、第２実施形態では、機能情報リスト６２に各機能のアクセス先の項目を設け、対象となる機能のアクセス先として端末内（例えば「ｌｏｃａｌ」）であるか、ネットワーク上（例えば「ｗｓ：／／＊＊＊」）であるかを設定可能とする。なお、ネットワーク上に対する設定において、例えばｈｔｔｐプロトコル等でアクセスする場合には、ＵＲＬ等が設定されるが、これに限定されるものではない。

また、第１のプラグイン３１は、機能情報リスト６２を受けて、端末内の機能情報とネットワーク上の機能情報リストに分割し、アクセス先が端末内（ｌｏｃａｌ）の機能情報は（端末内）拡張機能プラグイン管理部２５−１へ送り、アクセス先がｌｏｃａｌ以外である場合は（ネットワーク上）拡張機能プラグイン管理部２５−２へ送る。

拡張機能プラグイン管理部２５−１は、（端末内）拡張機能プラグイン（第２のプラグイン）３２−１ａ，３２−１ｂを有し、拡張機能プラグイン３２−１ａ，３２−１ｂは、上述した第１実施形態における拡張機能プラグイン３２ａ，３２ｂと同様の機能を有する。

第２実施形態において、機能情報リスト６２には、例えば図１１に示すように、場所等の所定の状態に付属する（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２ａ，３２−２ｂが提供する機能の情報（例えば、ディスプレイ（ｄｉｓｐｌａｙ）機能（ＯＮ／ＯＦＦ制御）や人検出機能（ＯＮ／ＯＦＦ制御）等）が含まれている。また、機能情報リスト６２には、図１１に示すように、例えばメールサーバ１６−１等の他システムの変化を検知し通知する（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３が提供する機能の情報が含まれている。（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３が提供する機能としては、例えばメールチェッカ機能、新着ニュースチェッカ機能等があるが、これに限定されるものではない。

（ネットワーク上）拡張機能プラグイン管理部２５−２は、（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２ａ，３２−２ｂを拡張機能プラグインサーバ１２'等から取得する。また、（ネットワーク上）拡張機能プラグイン管理部２５−２は、（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３を拡張機能プラグインサーバ１２'等から取得する。これにより、端末装置１３'は、（ネットワーク上）拡張機能プラグイン管理部２５−２に（ネットワーク上）拡張機能プラグイン３２−２ａ，３２−２ｂ，３３を追加することで、図１１に示すディスプレイ機能や人検出機能、メールチェック機能等、その場所に応じた適切な機能等を使用することができる。なお、端末装置１３'のハードウェア構成等については、上述した第１実施形態における端末装置１３'と同様の構成を用いることができるため、ここでの説明は省略する。

＜第２実施形態における機能拡張処理の一例を示すシーケンス＞
図１２は、第２実施形態における機能拡張処理（アプリ開始時）の一例を示すシーケンスである。図１２の例では、モバイルアプリ６１、アプリ実行部２４、アプリサーバ１１'、第１のプラグイン３１、拡張機能プラグイン管理部２５、（端末内）拡張機能プラグイン（第２のプラグイン）３２−１、（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３、拡張機能プラグインサーバ１２'、及びサーバ１６を用いた処理の一例を示している。また、拡張機能プラグイン管理部２５は、（端末内）拡張機能プラグイン管理部２５−１と、場所等の所定の状態に付属する周辺機器が接続された装置等に設けられた（ネットワーク上）拡張機能プラグイン管理部２５−２とがある。

図１２の例では、第１実施形態と同様に、例えばユーザからの指示やＧＰＳ機能を用いたジオフェンシング等により、ある場所（位置）に入ったというような状態変化イベントをアプリ切り替えトリガとしてモバイルアプリを開始する。

図１２の例において、ある場所に入った場合、位置情報に基づいて場所イベント等の状態変化イベントがアプリ実行部２４に入力される（Ｓ４１）。アプリ実行部２４は、実行対象のモバイルアプリが記憶部２３にあるか否かを判断し、記憶部２３にない場合にアプリサーバ１１'にモバイルアプリ取得要求を行う（Ｓ４２）。取得要求時のパラメータとしては、場所情報（位置情報）等であるが、これに限定されるものではない。

次に、アプリ実行部２４は、アプリサーバ１１'から場所等の現在状態情報に関連付けられたモバイルアプリ一式を受信する（Ｓ４３）。なお、アプリ実行部２４は、記憶部２３にモバイルアプリが存在する場合は、アプリサーバ１１'にアクセスせずに記憶部２３から対象のモバイルアプリを取得する。次に、アプリ実行部２４は、アプリＩＤを生成し、モバイルアプリ一式から取り出した機能情報リスト６２に追加して第１のプラグイン３１に送信する（Ｓ４４）。

第１のプラグイン３１は、アクセス先が端末装置１３'内（ｌｏｃａｌ）の機能情報リストを抽出して（端末内）拡張機能プラグイン管理部２５−１に登録する（Ｓ４５）。また、第１のプラグイン３１は、アクセス先が端末装置１３'外（ネットワーク上）の機能情報リストを抽出し（ネットワーク上）拡張機能プラグイン管理部２５−２に登録する（Ｓ４６）。

（端末内）拡張機能プラグイン管理部２５−１は、インストール済み機能情報リストと比較し、インストールされていない機能を拡張機能プラグインサーバ１２'に取得要求を行う（Ｓ４７）。取得要求時のパラメータとしては、例えば機能名、機種名、バージョン情報等があるが、これに限定されるものではない。（端末内）拡張機能プラグイン管理部２５−１は、拡張機能プラグインサーバ１２'から未インストール拡張機能プラグイン一式を受信する（Ｓ４８）。

また、（ネットワーク上）拡張機能プラグイン管理部２５−２は、インストール済み機能情報リスト６２と比較し、インストールされていない機能を拡張機能プラグインサーバ１２'に取得要求を行う（Ｓ４９）。取得要求時のパラメータとしては、上述したように機能名、機種名、バージョン情報等である。（ネットワーク上）拡張機能プラグイン管理部２５−２は、拡張機能プラグインサーバ１２'から未インストール機能一式を受信する（Ｓ５０）。

次に、（端末内）拡張機能プラグイン管理部２５−１は、（端末内）拡張機能プラグイン３２−１をインストールし（Ｓ５１）、対応するプラグイン名（一意名）を登録する（Ｓ５２）。また同様に、（ネットワーク上）拡張機能プラグイン管理部２５−２は、（ネットワーク上）拡張機能プラグイン管理部２５−２が設けられた装置等に対し、（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２又は（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３をインストールする（Ｓ５３）。図１２では、Ｓ５３の処理の一例として（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３をインストールする。（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３は、チェックするサーバ１６へのアクセス確認を行い（Ｓ５４）、サーバ１６からのアクセス許可を受信した場合（Ｓ５５）、対応するプラグイン名（一意名）を登録する（Ｓ５６）。

次に、（端末内）拡張機能プラグイン管理部２５−１及び（ネットワーク上）拡張機能プラグイン管理部２５−２は、共にアプリ実行部２４に対して準備完了通知を行う（Ｓ５７，Ｓ５８）。アプリ実行部２４は、拡張した機能に対応するモバイルアプリ６１に処理を開始させる（Ｓ５９）。

なお、（端末内）拡張機能プラグイン管理部２５−１及び（ネットワーク上）拡張機能プラグイン管理部２５−２における処理は、何れか一方の処理を行うだけでもよい。

図１３は、第２実施形態における機能拡張処理（モバイルアプリ実行中）の一例を示すシーケンスである。図１３の例では、モバイルアプリ６１、アプリ実行部２４、第１のプラグイン３１、拡張機能プラグイン管理部２５（（端末内）拡張機能プラグイン管理部２５−１及び（ネットワーク上）拡張機能プラグイン管理部２５−２）、（端末内）拡張機能プラグイン（第２のプラグイン）３２−１、及び（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３を用いた処理の一例を示している。

図１３の例において、モバイルアプリ６１は、例えば第１のプラグイン３１等に対して機能名と指示で呼び出す（Ｓ６１）。例えば、機能名「歩行検出」に対して、指示「歩行開始イベント通知」等で呼び出す。第１のプラグイン３１は、呼び出しＩＤを生成し、コールバック関数等を保存し、機能情報リストを参照する。

ここで、機能のアクセス先が端末装置１３'内（ｌｏｃａｌ）の場合、第１のプラグイン３１は、（端末内）拡張機能プラグイン管理部２５−１を呼び出す（Ｓ６２）。（端末内）拡張機能プラグイン管理部２５−１は、プラグイン名（一意名）を参照して、対応する（端末内）拡張機能プラグインを呼び出す（Ｓ６３）。（端末内）拡張機能プラグイン３２−１は、指示に従って処理を実行し、処理の完了通知や、状態イベント等の発行を行う（Ｓ６４）。

次に、（端末内）拡張機能プラグイン管理部２５−１は、第１のプラグイン３１に出力する（Ｓ６５）。第１のプラグイン３１は、呼び出しＩＤからコールバック関数を特定し、コールバック関数を呼び出し、モバイルアプリ６１に出力する（Ｓ６６）。

また、機能のアクセス先が端末装置１３外（ネットワーク上アドレス）の場合、第１のプラグイン３１は、（ネットワーク上）拡張機能プラグイン管理部２５−２を呼び出す（Ｓ６７）。（ネットワーク上）拡張機能プラグイン管理部２５−２は、プラグイン名（一意名）を参照して、対応する（ネットワーク上）拡張機能プラグイン３２−２又は（ネットワーク上）拡張機能プラグイン３３を呼び出す（Ｓ６８）。図１３では、Ｓ６８の処理の一例として、（ネットワーク上）拡張機能プラグイン３３を呼び出している。

（ネットワーク上）拡張機能プラグイン３３は、例えば呼び出しによりチェック対象のサーバ１６にアクセスして更新情報の確認等を行い（Ｓ６９）、その確認結果を受信して（Ｓ７０）、状態変更イベント等の発行等を行う（Ｓ７１）。

次に、（ネットワーク上）拡張機能プラグイン管理部２５−２は、第１のプラグイン３１に出力する（Ｓ７２）。第１のプラグイン３１は、呼び出しＩＤからコールバック関数を特定して、コールバック関数によりモバイルアプリ６１に出力する（Ｓ７３）。これにより、アプリ実行部２４は、状態変更を知ることができる。

図１４は、第２実施形態における機能拡張処理（アプリ終了時）の一例を示すシーケンスである。図１４の例では、アプリ実行部２４、モバイルアプリ６１、第１のプラグイン３１、拡張機能プラグイン管理部２５（（端末内）拡張機能プラグイン管理部２５−１及び（ネットワーク上）拡張機能プラグイン管理部２５−２）、（端末内）拡張機能プラグイン（第２のプラグイン）３２−１、及び（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３を用いた処理の一例を示している。また、図１４の例では、第１実施形態と同様に、ある場所（位置情報）から離れる（退く）場合に発生するイベントをトリガとしてモバイルアプリを終了する例を示している。

図１４の例において、ある場所から離れたことを検知することで発生したモバイルアプリ切り替えイベントがアプリ実行部２４に入力されると（Ｓ８１）、モバイルアプリ６１に該当アプリの停止指示を出力する（Ｓ８２）。モバイルアプリ６１は、指示されたモバイルアプリを停止し、停止が完了した旨の通知をアプリ実行部２４に出力する（Ｓ８３）。

アプリ実行部２４は、機能情報リストの削除要求を第１のプラグイン３１に出力する（Ｓ８４）。削除要求時のパラメータとしては、例えばアプリＩＤ等があるが、これに限定されるものではない。

次に、第１のプラグイン３１は、アプリ実行部２４から取得した機能情報リストの削除要求を受け取ると、その内容を（端末内）拡張機能プラグイン管理部２５−１に出力する（Ｓ８５）。（端末内）拡張機能プラグイン管理部２５−１は、指定アプリＩＤの機能情報リスト６２ａを削除し、残った機能情報リスト６２ａとインストール済み機能情報リスト６２ｂとの照合を行い、不要機能の抽出を行う。そして、端末装置１３内の不要な（端末内）拡張機能プラグイン３２−１をアンインストールする（Ｓ８６）。

（端末内）拡張機能プラグイン３２−１は、アンインストール時に（端末内）拡張機能プラグイン３２−１に対応するプラグイン名（一意名）を（端末内）拡張機能プラグイン管理部２５−１のインストール済み機能情報リスト６２ｂから削除させる（Ｓ８７）。

また、第１のプラグイン３１は、（ネットワーク上）拡張機能プラグイン管理部２５−２に対しても指定アプリＩＤの機能情報リストの削除要求を行い（Ｓ８８）、（ネットワーク上）拡張機能プラグイン管理部２５−２は、指定アプリＩＤの機能情報リスト６２ａを削除し、残った機能情報リストとインストール済み機能情報リスト６２ｃとの照合を行う。そして、不要な機能の抽出を行って、ネットワーク上の不要な（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２又は（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３をアンインストールする（Ｓ８９）。図１４の例では、Ｓ８９の処理の一例として（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３をアンインストールする例を示している。

（ネットワーク上）拡張機能プラグイン３２−２は、アンインストール時に（ネットワーク上）拡張機能プラグイン（第２のプラグイン）３２−２又は（ネットワーク上）拡張機能プラグイン（第３のプラグイン）３３に対応するプラグイン名（一意名）を（ネットワーク上）拡張機能プラグイン管理部２５−２のインストール済み機能情報リスト６２ｃから削除させる（Ｓ９０）。

＜第２実施形態に適用される各種データ例＞
図１５は、第２実施形態に適用される各種データ例を示す図である。図１５（Ａ）は、第１のプラグイン３１で管理されるデータ例を示し、図１５（Ｂ）は、（端末内）拡張機能プラグイン管理部２５−１で管理されるデータ例を示し、図１５（Ｃ）は、（ネットワーク上）拡張機能プラグイン管理部２５−２で管理されるデータ例を示す。

図１５（Ａ）に示す第１のプラグインのデータには、アプリＩＤ毎の機能情報リスト６２ａが存在する。機能情報リスト６２ａの項目としては、上述したように、例えば「機能」、「アクセス先」、「バージョン等条件」等があるが、これに限定されるものではない。図１５（Ａ）の例において、例えばアプリＩＤ＝０００１が有する機能「ｎｏｔｉｆｙ」を開始する場合に、（端末内）拡張機能プラグイン管理部２５−１で、その機能がインストールされ、図１５（Ｂ）に示すように、その機能に対応するプラグイン名（一意名）とバージョン情報等の条件が登録される。ここで、「アクセス先」は、例えば（ネットワーク上）拡張機能プラグイン管理部２５−２のアドレスを示す。

また、例えばアプリＩＤ＝０００１が利用する機能「ｄｉｓｐｌａｙ」を開始する場合に、（ネットワーク上）拡張機能プラグイン管理部２５−２で、インストール済み機能情報リスト６２ｃに「ｄｉｓｐｌａｙ」機能がなければ、（ネットワーク上）拡張機能プラグイン管理部２５−２は拡張機能プラグインサーバ１２'から、その機能の拡張機能プラグインを取得し、インストールする。そして、図１５（Ｃ）に示すように、その機能に対応するプラグイン名（一意名）とバージョン情報等の条件が登録される。これにより、アプリＩＤ＝０００１のモバイルアプリ６１で、インストールされたそれぞれの機能が実行可能となる。

また、第２実施形態では、モバイルアプリ終了時には、例えば図１５（Ａ）に示す第１のプラグイン３１の対象のモバイルアプリに関する機能情報リスト６２ａが削除される。また、上述した（端末内）拡張機能プラグイン管理部２５−１又は（ネットワーク上）拡張機能プラグイン管理部２５−２のそれぞれから対象のモバイルアプリの機能情報リスト６２ａが削除される。また、（端末内）拡張機能プラグイン管理部２５−１が保持する全ての機能情報リスト６２ａ、６２ｂにない機能の拡張機能プラグインが端末装置１３'からアンインストールされ、図１５（Ｂ）に示すインストール済み機能情報リスト６２ｂから削除される。

また、（ネットワーク上）拡張機能プラグイン管理部２５−２が保持する全ての機能情報リスト６２ａ，６２ｃにない機能の拡張機能プラグインがアンインストールされ、図１５（Ｃ）に示すインストール済み機能情報リスト６２ｃから削除される。
なお、図１５（Ａ）〜（Ｃ）に示す各データは、例えばアプリＩＤ毎に設定されているが、これに限定されるものではない。

上述したように第２実施形態によれば、状態毎の拡張機能プラグイン管理を適切に実現することができる。また、上述した第１及び第２実施形態では、機能拡張に対し、実行環境の差し替えを行う必要がない。また、第２実施形態によれば、例えば同じモバイルアプリに対し、異なる拡張機能プラグインが自動的にインストールされ、それぞれが組み合わさって処理を実行することができる。また、処理を実現する拡張機能プラグインがどのように選ばれるかを、モバイルアプリを実行する端末機種や場所によって変えることができる。

また、上述した第１及び第２実施形態では、端末装置１３（１３'）が必要な機能を自動的に読み込むことができるため、モバイルアプリがセンサや周辺機器を利用するための機能拡張を迅速に行うことができる。

＜第３実施形態＞
次に、第３実施形態について説明する。上述した第２実施形態では、アプリサーバ１１'にその状態で利用可能な「その状態における機能情報リスト」を予め準備し、例えば（ネットワーク上）拡張機能プラグイン管理部２５−２が、第１のプラグインから送信されたその情報に基づいて、対応する拡張機能プラグインを実行管理した。第３実施形態では、アクセス先をサーバから指定せず、動的に周囲の機能を検出して使える機能情報リストを保持、更新する。使える機能情報リストとは、インストール済み機能情報リスト及び検出中機能情報リストであり、これらのリストを参照し、モバイルアプリに対応する機能を利用する。

具体的に説明すると、第３の実施形態では、端末外の拡張機能プラグインを管理する拡張機能プラグイン管理装置１７を必要としない。第３実施形態では、端末装置１３''内に（端末外）拡張機能プラグインを設け、（端末外）拡張機能プラグインが自身の機能情報を定期的に、又は、ブロードキャストリクエストを受信して、ブロードキャスト発信する。

また、第３実施形態では、端末装置１３''内に（端末外）拡張機能プラグイン管理部を設け、ブロードキャストを受信し、機能情報を取得して、検出中機能情報リストを更新する等の管理を行う。検出中機能情報リストは、例えば機能名、一意名、バージョン等の情報、及び最新検出時刻等を管理する。また、（端末外）拡張機能プラグイン管理部は、一定時間検出できなくなった、又は利用していて通信が届かなくなった（端末外）拡張機能プラグインを、検出中機能情報リストから削除する。

（端末外）拡張機能プラグイン管理部は、（端末内）拡張機能プラグイン管理部２５−１と同様に、アプリ実行部と第１のプラグイン３１との接続関係を維持しつつ、ブロードキャスト通信により検出した拡張機能プラグインをモバイルアプリから利用可能とすることができる。なお、第３実施形態におけるシステム構成は、第１実施形態における機能拡張システム１０と同様の構成を用いることができるため、ここでの具体的な説明は省略する。

＜第３実施形態における機能拡張処理の概要＞
図１６は、第３実施形態における機能拡張処理の概要を説明するための図である。図１６の例では、アプリサーバ１１''と、端末装置１３''とを有する。また、第３実施形態において、端末装置１３''は、モバイルアプリ６１と、アプリ実行部２４と、（端末内）拡張機能プラグイン管理部２５−１と、（端末外）拡張機能プラグイン管理部２５−３とを有する。なお、第３実施形態において、第１及び第２実施形態に含まれる構成と同様の構成等については、同一の符号を付するものとし、ここでの具体的な説明は省略する。

第３実施形態において、端末装置１３''は、（端末外）拡張機能プラグイン管理部２５−３を有している。（端末外）拡張機能プラグイン管理部２５−３は、端末装置１３''内部に設けられ、図１６に示す周辺機器１５−３，１５−４、メールサーバ１６−１への制御等は、（端末外）拡張機能プラグイン管理部２５−３を介して端末装置１３''のモバイルアプリ６１により実行される。

第３実施形態では、（端末外）拡張機能プラグイン管理部２５−３は、例えば定期的、又はモバイルアプリ開始等の所定のタイミングで、拡張機能プラグインがブロードキャスト発信している機能情報のスキャンや、（端末外）拡張機能プラグイン（第４のプラグイン）を検出するためのリクエストのブロードキャストを行う。通信方式としては、例えば、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ等を用いるが、これに限定されるものではない。

ここで、第４のプラグインとは、上述した第２，３のプラグインの持つ機能に加え、（端末外）拡張機能プラグイン管理部が定期的にブロードキャストリクエストを発行し、第４のプラグインがブロードキャストリクエストを受けてブロードキャストする。なお、第４のプラグイン自身が定期的に自身の機能情報をブロードキャストし、（端末外）拡張機能プラグイン管理部２５−３がその情報を取得してもよい。上述した自身の機能情報とは、例えば機能情報リスト空欄を埋める情報であり、例えば機能、一意名（ＵＲＬやＳｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ（ＳＳＩＤ）等）、バージョン等条件等であるが、これに限定されるものではない。

例えば、端末装置１３''外の周辺機器に接続した（端末外）拡張機能プラグイン（第４のプラグイン）３４−１，３４−２、又はメールサーバ１６−１に接続した（端末外）拡張機能プラグイン（第４のプラグイン）３４−３は、定期的、又は（端末外）拡張機能プラグイン管理部２５−３のリクエストに応じて、自身の機能情報をブロードキャストする。

（端末外）拡張機能プラグイン管理部２５−３は、ブロードキャストされた機能情報を取得し、検出中機能情報リストに同じ情報があるか否かを調べる。同じ情報がなければ、検出中機能情報リストに最終検出時刻と共に追加する。また、（端末外）拡張機能プラグイン管理部２５−３は、検出中機能情報リストで、最終検出時刻から一定時間、時刻が更新されていない機能情報を削除する。

検出中機能情報リストのアクセス先には、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ）アドレスやＭｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）アドレス、ＳＳＩＤ等が設定されるが、これに限定されるものではない。機能名としては、例えば（端末外）拡張機能プラグイン（第４のプラグイン）３４−１，３４−２のディスプレイ機能や人検出機能等であるが、これに限定されるものではない。

（端末外）拡張機能プラグイン管理部２５−３は、検出中機能情報リストに変更があると、第１のプラグイン３１に対し、新たに検出した機能名や、一定期間検出せずリストから削除した機能名を出力する。第１のプラグイン３１は、実行中モバイルアプリと対の機能情報リスト（端末外）のアクセス先情報を、（端末外）拡張機能プラグイン管理部２５−３から取得した情報に基づいて更新する。

更新処理において、第１のプラグイン３１は、例えば新たに検出した機能名がリスト中にあり、アクセス先が空欄であれば「端末外（ｎｅｔ）」と記入する。また、第１のプラグイン３１は、削除した機能名がリスト中にあり、アクセス先が「端末外（ｎｅｔ）」であれば、空欄とする。

＜第３実施形態における機能拡張処理の一例を示すシーケンス＞
次に、第３実施形態における機能拡張処理の一例について説明する。図１７は、第３実施形態における機能拡張処理（アプリ実行中）の一例を示すシーケンスである。図１７の例では、（端末外）拡張機能プラグイン管理部２５−３、（端末外）拡張機能プラグイン（第４のプラグイン）３４、及び第１のプラグイン３１を用いた処理の一例を示している。図１７に示す処理は、モバイルアプリ実行中の拡張機能の増減を行う処理であり、例えば定期的に実行されるが、これに限定されるものではない。

図１７の例において、（端末外）拡張機能プラグイン管理部２５−３は、機能情報のブロードキャストリクエストを（端末外）拡張機能プラグイン（第４のプラグイン）３４に出力する（Ｓ９１）。（端末外）拡張機能プラグイン（第４のプラグイン）３４は、機能情報のブロードキャストを（端末外）拡張機能プラグイン管理部２５−３に出力する（Ｓ９２）。

ここで、検出中機能情報リストにあるプラグインのブロードキャストを受信した場合、（端末外）拡張機能プラグイン管理部２５−３は、そのプラグインの最終検出時刻を更新する（Ｓ９３）。

また、リストにないプラグインのブロードキャスト受信の場合、（端末外）拡張機能プラグイン管理部２５−３は、検出中機能情報リストに追加すると共に、最終検出時刻を記入する（Ｓ９４）。また、（端末外）拡張機能プラグイン管理部２５−３は、追加した機能情報を第１のプラグイン３１に通知する（Ｓ９５）。第１のプラグイン３１は、新たに検出した機能名がリストにあり、アクセス先が未記入であれば、「端末外（ｎｅｔ）」と記入する（Ｓ９６）。

また、定期的に機能情報のブロードキャストを行っている場合に、一定時間検出されていないプラグインがある場合、（端末外）拡張機能プラグイン管理部２５−３は、そのプラグインの機能情報を検出中機能情報リストから削除する（Ｓ９８）。次に、（端末外）拡張機能プラグイン管理部２５−３は、削除した機能情報を第１のプラグイン３１に通知する（Ｓ９９）。第１のプラグイン３１は、削除された機能名がリストにあり、アクセス先が「端末外（ｎｅｔ）」であれば空欄にする（Ｓ１００）。

図１８は、第３実施形態における機能拡張処理（リスト更新）の一例を示すシーケンスである。図１８の例では、モバイルアプリ６１、アプリ実行部２４、第１のプラグイン３１、（端末内）拡張機能プラグイン管理部２５−１、（端末内）拡張機能プラグイン（第２のプラグイン）３２−１、（端末外）拡張機能プラグイン管理部２５−３、（端末外）拡張機能プラグイン（第４のプラグイン）３４、及び拡張機能プラグインサーバ１２を用いた処理の一例を示している。

図１８の例において、モバイルアプリ６１は、機能情報リストを取得してアプリ実行部２４に出力する（Ｓ１０１）。アプリ実行部２４は、機能情報リストを第１のプラグイン３１に出力する（Ｓ１０２）。第１のプラグイン３１は、機能情報リストを（端末内）拡張機能プラグイン管理部２５−１に出力する（Ｓ１０３）。

（端末内）拡張機能プラグイン管理部２５−１は、機能情報ブロードキャストリクエストを（端末内）拡張機能プラグイン（第２のプラグイン）３２−１に出力する（Ｓ１０４）。（端末内）拡張機能プラグイン（第２のプラグイン）３２−１は、リクエストを受け付けて、そのリクエストに対する返信を行う（Ｓ１０５）。（端末内）拡張機能プラグイン管理部２５−１は、インストール済み機能情報リストを更新する（Ｓ１０６）。また、（端末内）拡張機能プラグイン管理部２５−１は、見つからない機能があれば、拡張機能プラグインサーバ１２にアクセスして取得してインストールし（Ｓ１０７）、インストール済み機能情報リストを更新する（Ｓ１０８）。なお、Ｓ１０７の処理は、例えば上述したＳ４７〜Ｓ５１の処理と同様の処理を簡略的に示している。

次に、（端末内）拡張機能プラグイン管理部２５−１は、検出機能情報アクセス先に「ｌｏｃａｌ」と記入して第１のプラグイン３１に出力する（Ｓ１０９）。次に、第１のプラグイン３１は、機能情報リストを（端末外）拡張機能プラグイン管理部２５−３に出力する（Ｓ１１０）。（端末外）拡張機能プラグイン管理部２５−３は、機能情報ブロードキャストリクエストを（端末外）拡張機能プラグイン（第４のプラグイン）３４に送信する（Ｓ１１１）。（端末外）拡張機能プラグイン（第４のプラグイン）３４は、リクエスト付け付けて、そのリクエストに対する返信を行う（Ｓ１１２）。（端末外）拡張機能プラグイン管理部２５−３は、検出中リストを更新し（Ｓ１１３）、検出機能情報アクセス先に「端末外（ｎｅｔ）」と記入して第１のプラグイン３１に出力する（Ｓ１１４）。第１のプラグイン３１は、得られた情報に基づいて機能情報リストを更新して管理する（Ｓ１１５）。

図１９は、第３実施形態における機能拡張処理（第４のプラグイン呼び出し）の一例を示すシーケンスである。図１９の例では、（端末外）拡張機能プラグイン（第４のプラグイン）３４、（端末外）拡張機能プラグイン管理部２５−３、第１のプラグイン３１、アプリ実行部２４、及びモバイルアプリ６１を用いた処理の一例を示している。図１９の例において、Ｓ１２１〜Ｓ１２８の処理は、拡張機能プラグインが利用できた場合の例を示し、Ｓ１３１〜Ｓ１３９の処理は、拡張機能プラグイン呼び出しが到達しなかった場合の例を示している。

図１９の例において、モバイルアプリ６１は、利用する（端末外）拡張機能プラグイン（第４のプラグイン）３４の呼び出しをアプリ実行部２４に出力する（Ｓ１２１）。アプリ実行部２４は、モバイルアプリ６１から受け付けた呼び出しを第１のプラグイン３１に出力する（Ｓ１２２）。第１のプラグイン３１は、アプリ実行部２４から受け付けた呼び出しを（端末外）拡張機能プラグイン管理部２５−３に出力する（Ｓ１２３）。（端末外）拡張機能プラグイン管理部２５−３は、第１のプラグイン３１から受け付けた呼び出しを、（端末外）拡張機能プラグイン（第４のプラグイン）３４に送信する（Ｓ１２４）。ここで、第４のプラグインが利用できると、そのレスポンスを（端末外）拡張機能プラグイン管理部２５−３が受信する（Ｓ１２５）。（端末外）拡張機能プラグイン管理部２５−３は、レスポンスを第１のプラグイン３１に出力する（Ｓ１２６）。第１のプラグイン３１は、受け付けたレスポンスをアプリ実行部２４に出力する（Ｓ１２７）。アプリ実行部２４は、受け付けたレスポンスをモバイルアプリ６１に出力する（Ｓ１２８）。

また、拡張機能プラグイン呼び出しが到達しなかった場合、モバイルアプリ６１は、利用する（端末外）拡張機能プラグイン（第４のプラグイン）３４の呼び出しをアプリ実行部２４に出力する（Ｓ１３１）。アプリ実行部２４は、モバイルアプリ６１から受け付けた呼び出しを第１のプラグイン３１に出力する（Ｓ１３２）。第１のプラグイン３１は、アプリ実行部２４から受け付けた呼び出しを（端末外）拡張機能プラグイン管理部２５−３に出力する（Ｓ１３３）。（端末外）拡張機能プラグイン管理部２５−３は、第１のプラグイン３１から受け付けた呼び出しを、（端末外）拡張機能プラグイン（第４のプラグイン）３４に送信するが、到達できなかった場合に、その旨を示すエラー情報を第１のプラグイン３１に出力する（Ｓ１３４）。第１のプラグイン３１は、エラー情報をアプリ実行部２４に出力する（Ｓ１３５）。アプリ実行部２４は、受け付けたエラー情報をモバイルアプリ６１に出力する（Ｓ１３６）。

次に、（端末外）拡張機能プラグイン管理部２５−３は、そのプラグインの機能情報を検出中機能情報リストから削除し（Ｓ１３７）、削除した機能情報を第１のプラグイン３１に通知する（Ｓ１３８）。第１のプラグイン３１は、削除された機能名がリストにあり、アクセス先が「端末（ｎｅｔ）」であれば、空欄にする（Ｓ１３９）。

＜第３実施形態に適用される各種データ例＞
図２０は、第３実施形態に適用される各種データ例を示す図である。図２０（Ａ）は、第１のプラグインで管理されるデータ例を示し、図２０（Ｂ）は、（端末内）拡張機能プラグイン管理部２５−１で管理されるデータ例を示し、図２０（Ｃ）は、（端末外）拡張機能プラグイン管理部２５−３で管理されるデータ例を示す。

図２０（Ａ）に示す第１のプラグイン３１のデータには、アプリＩＤ毎の機能情報リスト６２ａが存在する。機能情報リスト６２ａの項目としては、上述したように、例えば「機能」、「アクセス先」、「バージョン等条件」等があるが、これに限定されるものではない。端末装置１３は、モバイルアプリと共にそのアプリが利用する機能情報リスト（モバイルアプリが利用予定の機能情報リスト）６２ｄをアプリ実行部２４が取得すると、機能情報リストを第１のプラグイン３１に出力する。このとき、機能情報リスト６２ｄのアクセス先は空欄である。

第１のプラグイン３１は、機能情報リスト６２ａを（端末内）拡張機能プラグイン管理部２５−１に出力する。（端末内）拡張機能プラグイン管理部２５−１は、インストール済機能情報リスト６２ｂを参照し、インストール済みである機能については、その機能情報リスト６２ａのアクセス先に「ｌｏｃａｌ」と記入する。また、アクセス先が空欄の機能は、拡張機能プラグインサーバ１２に問い合わせし、拡張機能プラグインサーバ１２に一式がある機能があれば取得してインストールする。インストール後は、その機能のアクセス先に「ｌｏｃａｌ」と記入する。（端末内）拡張機能プラグイン管理部２５−１は、変更した機能情報リスト６２ａを第１のプラグイン３１に返却する。

また、第１のプラグイン３１は、機能情報リスト６２ａを（端末外）拡張機能プラグイン管理部２５−３に出力する。（端末外）拡張機能プラグイン管理部２５−３は、検出中機能情報リスト６２ｅを参照し、ある機能については、アクセス先に「ｎｅｔ」と記入する。変更した機能情報リスト６２ａを第１のプラグイン３１に返却する。

ここで、モバイルアプリから機能の呼び出しがあると、第１のプラグイン３１は、機能情報リスト６２ａを参照し、アクセス先が端末内（ｌｏｃａｌ）の機能の呼び出しは、（端末内）拡張機能プラグイン管理部２５−１に送る。

また、アクセス先が「ｎｅｔ」の場合、（端末外）拡張機能プラグイン管理部２５−３に機能の読み出しを送る。アクセス先が空欄の場合は、モバイルアプリにエラーを返す。（端末外）拡張機能プラグイン管理部２５−３は、検出中機能情報リスト６２ｅを参照し、呼び出された機能に対応する一意名を用いて拡張機能プラグイン（第４のプラグイン）３４を呼び出し、レスポンスをアプリへ返却する。なお、呼び出しても拡張機能プラグインに到達できずエラーとなった場合、（端末外）拡張機能プラグイン管理部２５−３は、モバイルアプリへエラー情報を返すと共に、そのプラグイン情報を検出中機能情報リスト６２ｅから削除し、削除情報を第１のプラグイン３１へ送る。第１のプラグイン３１は、リスト中のその機能名のアクセス先を空欄とする。

これにより、アプリＩＤ＝０００１のモバイルアプリ６１で、インストールされたそれぞれの機能が実行可能となる。また、第３実施形態では、モバイルアプリ終了時には、例えば図２０（Ａ）に示す第１のプラグイン３１の対象のモバイルアプリの機能情報リスト６２ａが削除される。また、上述した（端末内）拡張機能プラグイン管理部２５−１又は（端末外）拡張機能プラグイン管理部２５−３のそれぞれから対象のモバイルアプリの機能情報リスト６２ａが削除される。上述した第１〜第３実施形態では、端末装置１３が必要な機能を自動的に読み込むことができるため、モバイルアプリがセンサや周辺機器を利用するための機能拡張を迅速に行うことができる。

＜第４実施形態＞
次に、第４実施形態について説明する。上述した第１〜第３の実施形態では、各周辺機器１５又はサーバ１６に対して共通のプラグイン（第１のプラグイン）と、周辺機器又はサーバ１６毎に個別のプラグイン（拡張機能プラグイン（第２〜第４のプラグイン）とを有することで、アプリを再起動せずに機能を追加したり削除することができる。

更に、第４実施形態では、例えば拡張機能プラグインの中に、例えばｔｒｕｅ／ｆａｌｓｅ等の状態変化をトリガとしてイベントを発行する条件を、各アプリが任意に１又は複数設定できるようにする。更に、第４実施形態では、イベントをモバイルアプリに送るための１又は複数の拡張機能プラグインに跨る条件を自動で分割し、各拡張機能プラグイン等に条件を分配する。

これにより、例えば端末装置１３は、複数のセンシング機能（＝拡張機能プラグイン）等によるセンサ処理の結果から総合的に状態を判定し、アプリの開始や終了等を行うことができる。また、第４実施形態では、ＣＰＵの負荷を低減し、各部間の通信量を下げることができる。例えば、拡張機能プラグイン（第２のプラグイン）は、第１のプラグインから指定された発行条件に基づいて、端末装置１３の位置、時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む通知情報を発行する。また、第４実施形態では、指定された発行条件に基づいて通知情報を生成するか否かの判定処理を、第２のプラグインに対応する周辺機器１５で実行可能な場合に、判定処理を周辺機器で実行させてもよい。

また、第４実施形態では、判定処理のうち、複数の判定処理の結果を組み合わせた複合的な判定処理について、複数の判定処理が何れか同一の第２のプラグインに対応する周辺機器で実行可能な場合に、複数の判定処理とそれら判定処理の結果を組み合わせた複合的な判定処理の一部又は全部を周辺機器１５で実行させてもよい。

＜第４実施形態における端末装置１３の機能構成例＞
図２１，図２２は、第４実施形態における端末装置の機能構成の一例を示す図（その１，その２）である。なお、以下の説明では、第１実施形態における端末装置１３及び第２実施形態における端末装置１３'と異なる部分について具体的に説明する。また、上述した端末装置１３，１３'と同様の構成については、同一の番号を付するものとし、ここでの具体的な説明は省略する。

図２１に示す端末装置１３''ａは、第１実施形態に対応している。端末装置１３''ａは、入力部２１と、出力部２２と、記憶部２３と、アプリ実行部２４と、拡張機能プラグイン管理部２５と、通信部２６と、第１のプラグイン３１と、拡張機能プラグイン（第２のプラグイン）３２ａ，３２ｂとを有する。

また、図２２に示す端末装置１３''ｂは、第２実施形態に対応している。端末装置１３''ｂは、入力部２１と、出力部２２と、記憶部２３と、アプリ実行部２４と、（端末内）拡張機能プラグイン管理部２５−１と、通信部２６と、第１のプラグイン３１と、（端末内）拡張機能プラグイン３２−１とを有する。

また、第４実施形態では、端末装置１３''ａ，１３''ｂ内にツリー条件判定部７１と、状態条件判定部７２とを有する。例えば、図２１、図２２に示す第１のプラグイン３１は、ツリー条件判定部７１−１を有している。また、図２１に示す拡張機能プラグイン管理部２５にもツリー条件判定部７１−２を有している。また、拡張機能プラグイン３２には、状態条件判定部７２−１を有している。

図２１に示す拡張機能プラグイン管理部２５は、拡張機能プラグイン（第２のプラグイン）３２ａ，３２ｂを有し、拡張機能プラグイン３２ｂは、周辺機器１５−３'が有する状態条件判定部７２−１'及びツリー条件判定部７１−２'と通信する。

また、図２２に示す第１のプラグイン３１、（端末内）拡張機能プラグイン管理部２５−１、（ネットワーク上）拡張機能プラグイン管理部２５−２にも、それぞれツリー条件判定部７１−１，７１−２、７１−３を有している。また、（端末内）拡張機能プラグイン３２−１、（ネットワーク上）拡張機能プラグイン３２−２、拡張機能プラグイン（第３のプラグイン）３３は、状態条件判定部７２−１、７２−２，７２−３を有している。拡張機能プラグイン管理装置１７の拡張機能プラグイン（第３のプラグイン）３３は、サーバ１６との接続を行う。

ツリー条件判定部７１は、状態条件判定部７２のｔｒｕｅ／ｆａｌｓｅの組み合わせを判定する。例えば、ツリー条件判定部７１は、多種類のセンサ処理等からの結果で総合的に状態を判別したい場合に、個々の拡張機能プラグインから発生する状態変化のイベントをトリガとして、それぞれの拡張機能プラグインの中の状態の論理積（ＡＮＤ）や論理和（ＯＲ）を利用して個々の条件を判定する。

状態条件判定部７２は、例えばセンサデータ等に基づいて、状態成立／状態不成立の２つの条件により、ｔｒｕｅ／ｆａｌｓｅを変化させる。例えば、状態条件判定部７２は、それぞれの拡張機能プラグインの中の状態が、状態成立／状態不成立の条件として登録された状態に変化したとき、状態成立の状態に変化すればｔｒｕｅ、状態不成立の状態に変化すればｆａｌｓｅと判定する。

例えば、ツリー条件判定の一例として、場所やユーザの状況等に応じて実行するモバイルアプリを切り替える場合、切り替えのトリガはＧＰＳ等の位置情報を処理して拡張機能プラグイン３２からイベントとして発生させ、それを受けてアプリ実行部２４がモバイルアプリを切り替える。また、「何時に場所Ａで人ａが近くにいる場合」等、複合的に条件設定したイベントを発生させたい場合には、各条件をＡＮＤやＯＲで組み合わせて記述する。上述した機能情報リスト等において同じアクセス先であれば、アクセス先の中でＡＮＤ条件を検証した上で、各拡張機能プラグイン管理部２５や各拡張機能プラグイン３２、３３からまとめたイベントを発生することで端末装置１３''ａ，１３''ｂのＣＰＵ等の負荷を低減することができる。

そこで、第４実施形態では、第１のプラグイン３１は、条件の中のＡＮＤやＯＲで結合された各条件のうち、同じアクセス先（例えば、端末内やネットワーク上）又は一意名（例えば、同じ機能プログラム）の部分条件は、分割せずにまとめてその宛先の条件判定部に条件設定する。ここで、ツリー条件判定部７１の上位、下位の関係も定義しておく。各状態条件判定部７２は、条件を満たすか、満たさなくなった時にイベントを上位に発生し、上位はそれを受けて自身の判定を行う。なお、第４実施形態において、各ツリー条件判定部７１でそれぞれ行われるＡＮＤやＯＲで結合された各条件の集まりをノードと呼ぶ。

なお、ＡＮＤやＯＲで結合された条件ツリーの最下端に位置する拡張機能プラグインノードについては、これ自身が状態（真偽値）を保持する。このツリーの末端のノードの状態は、拡張機能プラグイン内が発するセンサイベントによって遷移し、この遷移条件（成立要件、不成立要件）を記述したものを状態条件と呼ぶ。

条件ツリーを第１のプラグイン３１が取得し下位の状態条件判定部７２に条件設定するタイミングは、アプリサーバ１１''から条件ツリーが配信されたときでもよく、又は、アプリ実行部２４の起動時から予め保存していてもよい。

＜第４実施形態における機能拡張処理の概要＞
図２３〜図２６は、第４実施形態における機能拡張処理の概要を説明するための図（その１〜その４）である。図２３〜図２６は、それぞれが部分的に他の構成と異なっている。

図２３の例では、端末装置１３''ａの第１のプラグイン３１や、拡張機能プラグイン管理部２５、機能拡張プラグイン（第２のプラグイン）３２ａにおいて、それぞれツリー条件判定部７１−１，７１−２，７１−３ａを有している。また、拡張機能プラグイン３２ａには、状態条件判定部７２−３ａ−１，７２−３ａ−２を有し、拡張機能プラグイン３２ｂには、状態条件判定部７２−３ｂを有している。なお、図２３の例では、端末装置１３''ａの中にマイコン等を設け、その中にツリー条件判定部７１や状態条件判定部７２を有することで、省電力処理を実現している。

また、図２３の例において、アプリサーバ１１''は、条件ツリー７３として条件成立内部イベント、条件不成立内部イベントが設定されている。ツリー条件判定部７１は、このような内部イベントに対応するｔｒｕｅ／ｆａｌｓｅの状態条件及び条件ツリーを取得して、ツリー条件判定を行うことができる。

また、第４実施形態では、周辺機器１５側に上述した各種条件判定部（ツリー条件判定部７１，状態条件判定部７２）を有してもよい。例えば、図２４の例では、機能拡張プラグイン（第２のプラグイン）３２ａは、周辺機器１５−３'と接続し、周辺機器１５−３'がツリー条件判定部７１−３ａ'、状態条件判定部７２−３a−１'，７２−３a−２'を有している。

また、第４実施形態では、機能拡張プラグイン側と周辺機器側の両方に条件判定部を有してもよい。例えば、図２５の例では、機能拡張プラグイン（第２のプラグイン）３２ａは、ツリー条件判定部７１−３ａ'を有し、周辺機器１５−３'が状態条件判定部７２−３ａ−１'，７２−３ａ−２'を有している。

また、第４実施形態では、通信ネットワーク側に条件判定部を有してもよい。例えば、図２６の例では、端末装置１３''ｂに対し、（ネットワーク上）拡張機能プラグイン管理部２５−２は、ツリー条件判定部７１−３を有する。また、（ネットワーク上）拡張機能プラグイン３２−２ａ，３２−２ｂは、状態条件判定部７２−４ａ，７２−４ｂを有し、拡張機能プラグイン（第３のプラグイン）３３は、状態条件判定部７２−５を有している。

また、図２６の例では、図２４の例と同様に、（端末内）拡張機能プラグイン３２−１ａと接続された周辺機器１５−３'がツリー条件判定部７１−３ａ'、状態条件判定部７２−３ａ−１'，７２−３ａ−２'を有している。

このように、第４実施形態では、ツリー条件判定部７１及び状態条件判定部７２を、端末内外に設置することで、適切な条件判定を行うことができる。

なお、第４実施形態において、例えば拡張機能プラグイン３２は、手の動きのジェスチャやＮｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＮＦＣ）タグを検出する周辺機器とＢｌｕｅｔｏｏｔｈ（登録商標）等により接続して、ジェスチャやＮＦＣの検出をイベントとして発行する。拡張機能プラグイン３２の種類については、これに限定されるものではなく、例えば第１実施形態に示す通知機能や発生機能を有する拡張機能プラグインであってもよい。

また、第４実施形態では、判定条件の中のＡＮＤやＯＲで結合された部分条件のうち、部分条件の中が同じアクセス先（端末内又はネットワーク上）、又は、拡張機能プラグインの同じプラグイン名（一意名）の部分条件は分割せずにまとめてその宛先で条件判定を行わせる。図２３の例では、機能「ｗｒｉｓｔｊｅｓｔｕｒｅ」と「ＮＦＣ」とが同じ一意名（ｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｓｅｔ）であるため、この部分条件を拡張機能プラグイン（第２のプラグイン）３２ａで実行させる。

ＡＮＤやＯＲで結合された複数の条件による複合条件や、それを上述したような割り当て条件で割り当てられた各部分条件は、例えば図２３に示すような条件ツリーにより管理される。ここで、ツリーで結合されたＡＮＤやＯＲ、また「ｗｒｉｓｔｊｅｓｔｕｒｅ」や「ＮＦＣ」、「Ｐｏｓｔｕｒｅ」等は、ノードに相当する。各ツリー条件判定部７１は、条件を満たす場合や、条件を満たさなくなった場合に、対応するイベントを上位ノードに発生させる。上位ノードのツリー条件判定部７１は、それを受けて自身の条件判定を行う。

また、第４実施形態では、図２６に示すように、端末装置１３''ｂは、（ネットワーク上）拡張機能プラグイン管理部２５−２に対してもツリー条件判定部７１−３を設定し、その下位ノードとして拡張機能プラグイン３２−２ａ，３２−２ｂ、３３に対して状態条件判定部７２−４ａ，７４−４ｂ、７３を設定する。

例えば、図２３〜図２５に示す例では、上位ノードである第１のプラグイン３１のツリー条件判定部７１−１は、インストール済み機能情報リストに含まれるアクセス先、この例ではプラグイン名（一意名）を確認し、同一のプラグイン名の機能をまとめて、部分条件判定を依頼する。

例えば、図２３〜図２５の例では、「ＮＦＣ」機能と、「ｗｒｉｓｔｊｅｓｔｕｒｅ」機能とが、同一のプラグイン名（ｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｓｅｔ）であるため、条件ツリーの中で「ＮＦＣ」機能と「ｗｒｉｓｔｊｅｓｔｕｒｅ」機能とにより判定されるＡＮＤ以下の部分状態条件判定処理を依頼する。

なお、第４実施形態では、部分条件判定に対する条件定義を登録することができる。例えば、図２３〜図２５の例において、「ＮＦＣ」機能と、「ｗｒｉｓｔｊｅｓｔｕｒｅ」機能とにおける状態成立内部イベント、状態成立内部イベントを条件定義する。ＮＦＣ機能から、状態成立内部イベント（例えばｉｄｍ０を検出したときに発行するイベント）が発行されると、条件ツリー７３のＮＦＣノードの状態をｔｒｕｅとし、条件不成立内部イベント（例えばｉｄｍ１を検出したときに発行するイベント）が発行されると、条件ツリーのＮＦＣノードの状態をｆａｌｓｅと判定するが、定義内容については、これに限定されるものではない。

また、第４実施形態では、ネットワーク上機能管理への条件の分割も同様に対応することができる。例えば、図２６の例では、「ｄｉｓｐｌａｙ」機能と、「ｈｕｍａｎｄｅｔ」機能と、「ｍａｉｌｃｈｅｃｋｅｒ」機能とが、同一のアクセス先（ｗｓ：／／＊＊＊）である。そのため、例えば、図２６に示す条件ツリー７３の中で「ｄｉｓｐｌａｙ」機能と「ｈｕｍａｎｄｅｔ」機能とにより判定されるＡＮＤ以下の状態条件判定処理を（ネットワーク上）拡張機能プラグイン管理部２５−２に依頼することができる。

＜状態条件判定部における機能構成＞
図２７は、状態条件判定部における機能構成の一例を示す図である。図２８は、状態条件判定部の処理内容を説明するための図である。図２７の例において、状態条件判定部７２は、状態条件登録受付部８１と、状態条件記憶部８２と、状態条件マッチング判定部８３と、状態管理部８４と、機能固有ロジック８５とを有する。

状態条件登録受付部８１は、例えばアプリ実行部２４等で実行される条件ツリー駆動プログラム９０等から第４実施形態を実現するための状態条件の登録を受け付ける。なお、状態条件は、１又は複数受け付けてもよい。状態条件記憶部８２は、受け付けた状態条件を記憶する。

条件ツリー駆動プログラム９０は、例えば上位ノードのツリー条件判定部７１等であってもよい。例えば、条件ツリー駆動プログラム９０は、例えば上述した拡張機能プラグイン管理部２５にあるツリー条件判定部や拡張機能プラグインにあるツリー条件判定部等である。なお、必ずしもこれらのツリー条件判定部から状態条件判定部を利用する必要はない。また、拡張機能プラグイン管理部２５と第１のプラグイン３１とが中継し、アプリ実行部２４等で実行されるアプリから、状態条件を登録し、状態変化イベントを受け取ってもよい。

状態条件マッチング判定部８３は、機能固有ロジック８５から機能固有デバイス（センサ等）９１で得られた情報を取得し、取得した情報と、状態条件記憶部８２に記憶された状態条件にマッチするか否かを判定する。なお、図２７に示す状態条件判定部７２は、一例として、拡張機能プラグイン３２が有する状態条件判定部７２の例を示している。そのため、状態条件判定部７２は、周辺機器１５に対応した機能固有デバイス（センサ等）９１からの情報（例えば、温度センサであれば、所定時間毎の温度等）を受け取る。

状態管理部８４は、状態条件マッチング判定部８３による判定結果が、状態条件にマッチしていた場合に、対応する状態変化イベントを上位のノード（例えば、条件ツリー駆動プログラム９０）等で出力する。

機能固有ロジック８５は、機能固有デバイス９１から得られる情報を取得し、対応する内部イベントを状態条件マッチング判定部８３に送出する。なお、機能固有デバイス９１の種類や数については、これに限定されるものではない。

また、第４実施形態では、例えば図２８に示すように、例えばある状態が成立する時の内部イベント（状態成立内部イベント）と、その状態が不成立となる時の内部イベント（状態不成立内部イベント）のセットを指定することができるが、これに限定されるものではない。第４実施形態では、状態の成立条件と不成立条件を指定し、内部イベントとの合致を評価することで状態値（ｔｒｕｅ、ｆａｌｓｅ）の遷移を行うことができる。なお、図２８の例では、状態成立内部イベントを｛ｔｙｐｅ：'ｄｅｔｅｃｔｅｄ'，'ｎｄｅｆ'：'ａｂｃ'｝とし、状態不成立内部イベントを｛ｔｙｐｅ：'ｄｅｔｅｃｔｅｄ'，'ｎｄｅｆ'：'ｄｅｆ'｝と定義しているが、これに限定されるものではない。

＜状態条件判定処理の一例＞
図２９は、状態条件判定処理の一例を示すフローチャートである。図２９の例において、状態条件判定部７２は、機能固有処理として上述したような機能固有デバイス９１からの情報を受け取り（Ｓ１４１）、それをもとに生成した内部イベント（例えば、所定時間毎の温度）等を発行する（Ｓ１４２）。

次に、状態条件判定部７２は、状態条件記憶部８２に記憶された登録済みの状態条件の数だけ以下の処理を繰り返す（Ｓ１４３）。

状態条件判定部７２は、発行されたイベントが状態成立条件にマッチしたか否かを判断し（Ｓ１４４）、マッチしていない場合（Ｓ１４４において、ＮＯ）、発行されたイベントが状態不成立にマッチしたか否かを判断する（Ｓ１４５）。次に、状態条件判定部７２は、発行されたイベントが状態不成立にマッチしていない場合（Ｓ１４５において、ＮＯ）、未処理の次の状態条件に対して処理を行う。

また、Ｓ１４４の処理において、発行されたイベントが状態成立条件にマッチした場合（Ｓ１４４において、ＹＥＳ）、状態条件判定部７２は、状態条件に対応する状態値が真（ｔｒｕｅ）であるか否かを判断する（Ｓ１４６）。状態条件に対応する状態値が真（ｔｒｕｅ）である場合（Ｓ１４６において、ＹＥＳ）、未処理の次の状態条件に対して処理を行う。また、状態条件に対応する状態値が真（ｔｒｕｅ）でない（ｆａｌｓｅである）場合（Ｓ１４６において、ＮＯ）、状態遷移（ｆａｌｓｅ→ｔｒｕｅ）を行い（Ｓ１４７）、状態遷移通知（状態変化イベント）を上位ノードに通知する（Ｓ１４８）。

また、Ｓ１４５の処理において、発行されたイベントが状態不成立にマッチしている場合（Ｓ１４５において、ＹＥＳ）、状態条件判定部７２は、条件に対応する状態値が偽（ｆａｌｓｅ）であるか否かを判断する（Ｓ１４９）。条件に対応する状態値が偽（ｆａｌｓｅ）である場合（Ｓ１４９において、ＹＥＳ）、状態条件判定部７２は、未処理の次の状態条件に対して処理を行う。

また、Ｓ１４９の処理において、状態条件に対応する状態値が偽（ｆａｌｓｅ）でない（ｔｒｕｅである）場合（Ｓ１４９において、ＮＯ）、状態遷移（ｔｒｕｅ→ｆａｌｓｅ）を行い（Ｓ１５０）、状態遷移通知（状態変化イベント）を上位ノードに通知する（Ｓ１４８）。また、上述したＳ１４８の通知後、未処理の次の状態条件に対して処理を行う。

＜第４実施形態における機能拡張処理の一例を示すシーケンス＞
図３０は、第４実施形態における機能拡張処理（条件定義登録）の一例を示すシーケンスである。図３０の例では、モバイルアプリ６１、アプリ実行部２４、第１のプラグイン３１、拡張機能プラグイン管理部２５（（端末内）拡張機能プラグイン管理部２５−１、（ネットワーク上）拡張機能プラグイン管理部２５−２）、（端末内）拡張機能プラグイン３２−１、及び（ネットワーク上）拡張機能プラグイン３２−２を用いた処理の一例を示している。

図３０の例において、モバイルアプリ６１は、アプリが受信したいイベントの条件定義である、上述したような状態条件の論理積（ＡＮＤ）や論理和（ＯＲ）で記述されたツリー条件定義を第１のプラグイン３１へ出力する（Ｓ１６１）。第１のプラグイン３１は、ツリー判定条件を満たした場合又は満たさなくなった場合に、モバイルアプリ６１がイベントを受け取るコールバック関数を登録する（Ｓ１６２）。Ｓ１６２の処理で登録されるコールバック関数は、例えば第１のプラグイン３１により割り振られた条件定義ＩＤと共に記憶部２３等に記憶される。

第１のプラグイン３１は、ツリー条件の解析やディスパッチ（例えば、複数の処理を内容や用途等に応じて振り分けること）等を行う。第１のプラグイン３１は、ＡＮＤやＯＲ等の演算子と個々の状態条件をノードとする条件定義ツリーを生成する（Ｓ１６３）。また、第１のプラグイン３１は、個々の条件ノードの機能名に対応するアクセス先を機能情報リストから参照し、下位の階層から順に解析して、各ＡＮＤやＯＲのノードで、配下のノードのアクセス先が全て同じ場合に、ＡＮＤやＯＲのノードのアクセス先に同じアクセス先を入力する（Ｓ１６４）。

次に、第１のプラグイン３１は、上位の階層から解析し、アクセス先の入ったノードがあった場合に、そのアクセス先が端末装置１３内（ｌｏｃａｌ）であれば、そのノード以下の条件定義を端末内機能管理へ送信し、ノード以下の部分条件を登録する（Ｓ１６５）。また、アクセス先が端末装置１３外（ネットワーク上アドレスのノード）であれば、そのノード以下の条件定義を（ネットワーク上）拡張機能プラグイン管理部２５−２へ送信し、そのノード以下の部分条件を登録する。

（端末内）拡張機能プラグイン管理部２５−１は、部分条件定義を識別する識別情報（部分条件定義ＩＤ）を生成し、下位ノードから順に、一意名埋め処理を行う（Ｓ１６６）。Ｓ１６６の処理では、例えばあるノードの全配下ノードが同じプラグイン名（一意名）である場合に、そのノードのプラグイン名（一意名）を同じ値にする処理等を行うが、これに限定されるものではない。

第１のプラグイン３１は、一意名埋め処理の結果を受信し（Ｓ１６７）、（端末内）拡張機能プラグイン管理部２５−１に登録したノードに部分条件定義ＩＤを保存する（Ｓ１６８）。また、（端末内）拡張機能プラグイン管理部２５−１は、上層ノードから順に、一意名の（端末内）拡張機能プラグイン３２−１にノード以下部分ツリー条件、及び状態条件を登録する（Ｓ１６９）。（端末内）拡張機能プラグイン３２−１は、部分条件定義ＩＤを生成し（Ｓ１７０）、その結果を（端末内）拡張機能プラグイン管理部２５−１に出力する（Ｓ１７１）、（端末内）拡張機能プラグイン管理部２５−１は、拡張機能プラグイン３２−１に登録したノードに部分条件定義ＩＤを保存する（Ｓ１７２）。

なお、上述した条件定義登録におけるＳ１６５〜Ｓ１７２の処理は、ネットワーク上アドレスのノードに対しても同様に行う（Ｓ１７３）。これにより、（ネットワーク上）拡張機能プラグイン管理部２５−２や（ネットワーク上）拡張機能プラグイン３２−２等に対しても（端末内）拡張機能プラグイン管理部２５−１や（端末内）拡張機能プラグイン３２−１等と同様に対応する部分条件判定を行うための条件定義を登録することができる。

図３１は、第４実施形態における機能拡張処理（条件イベント発生）の一例を示すシーケンスである。図３１の例では、モバイルアプリ６１、アプリ実行部２４、第１のプラグイン３１、（端末内）拡張機能プラグイン管理部２５−１、及び拡張機能プラグイン３２−１を用いた処理の一例を示している。

図３１の例において、（端末内）拡張機能プラグイン３２−１は、状態条件を満たす場合や満たさない場合における状態変化イベントを、（端末内）拡張機能プラグイン管理部２５−１に送信する（Ｓ１８１）。なお、Ｓ１８１の処理における状態変化イベントとしては、例えば部分条件定義ＩＤとｔｒｕｅ又はｆａｌｓｅ等の状態変化情報等であるが、これに限定されるものではない。

（端末内）拡張機能プラグイン管理部２５−１は、部分条件定義ＩＤのノード検索を行い（Ｓ１８２）、当該ノードの直近状態を更新し（Ｓ１８３）、当該ノードから上位層（上位ノード）に対し順番に条件判定を行う（Ｓ１８４）。

次に、（端末内）拡張機能プラグイン管理部２５−１は、自身が判定する部分ツリーの最上位ノード（トップノード）の判定がｔｒｕｅからｆａｌｓｅへ、又は、ｆａｌｓｅからｔｒｕｅへ変化すると、状態変化イベントを第１のプラグイン３１に送信する（Ｓ１８５）。なお、Ｓ１８５の処理における状態変化イベントとしては、例えば（端末内）拡張機能プラグイン管理部２５−１における最上位ノードの部分条件定義ＩＤ、ｔｒｕｅ又はｆａｌｓｅ等の状態変化情報等であるが、これに限定されるものではない。

第１のプラグイン３１は、部分条件定義ＩＤのノードを検索し（Ｓ１８６）、当該ノードの直近状態を更新し（Ｓ１８７）、当該ノードから上位層（上位ノード）に対し順番に条件判定を行う（Ｓ１８８）。また、第１のプラグイン３１は、第１のプラグイン３１における最上位ノードの直近状態が変化した場合、条件定義ＩＤからコールバック関数を取得し（Ｓ１８９）、ｔｒｕｅからｆａｌｓｅへ、又は、ｆａｌｓｅからｔｒｕｅへ状態が変化したことを通知するイベントのコールバック関数呼び出しを行う（Ｓ１９０）。

なお、図３１の例では、（端末内）拡張機能プラグイン管理部２５−１及び（端末内）拡張機能プラグイン３２−１における処理を、（ネットワーク上）拡張機能プラグイン管理部２５−２及び（ネットワーク上）拡張機能プラグイン３２−２、３３における処理にも同様に適用することができるため、ここでの具体的な処理は省略する。

＜条件ツリー（ノードツリー）の一例＞
ここで、上述した第４実施形態における条件ツリー（ノードツリー）の一例について図を用いて説明する。図３２、図３３は、第４実施形態におけるノードツリーの一例を示す図（その１，その２）である。図３２は、ノードツリーの生成例を示す。図３３は、ノードツリーのイベント発行例を示す。なお、図３２，図３３は一例であり、これに限定されるものではない。条件の記述例等については、これに限定されるものではない。

第４実施形態では、例えばノードツリーに対応する全体の条件が図３２（Ａ）に示すような記述式により記述される。このノードの構成は、図３２（Ｂ）に示すように定義することができ、これに対応させて図３２（Ｃ）に示すようなノードツリーを生成することができる。

各ノードの情報としては、例えば「ノードタイプ」、「ノード名」、「アクセス先」、「一意名（プラグイン名）」、「親ノード」、「部分条件定義ＩＤ」、「直近状態」、「配下のノードリスト」、「条件」等があるが、これに限定されるものではない。

ノードタイプは、例えばＡＮＤ、ＯＲ等の演算子やその他の個別の状態条件等を設定することができる。個別の状態条件とは、例えば周辺機器のソフトウェアモジュールやセンサ等に対して設定される条件等である。例えば、ソフトウェアモジュールが、ＮＦＣ部品（機能）の場合には、過去に検知したタグであるか、１０分以内にあるタグを検知したか、あるタグを検知してから別のタグを検知したか等の各条件を設定することができる。また、例えばソフトウェアモジュールが温度検知部品（機能）の場合には、温度が２０度以上か、温度が２０度〜２５度の間かどうか等を状態条件に設定することができるが、状態条件設定については、これに限定されるものではない。

また、これらの状態条件の合致を評価する対象として、例えば各部品の内部イベントがある。内部イベントは、アプリに通知されない部品内のイベントであるため、高頻度で発生してもアプリ側の処理負荷にはならない。また、内部イベントは、部品内で閉じているため、その都度アプリを起こすことがなく、省電力化につながる。

また、第４実施形態では、内部イベントを複数の項目名及び値のセットによって構成し、状態条件もこれにあわせ項目名とそれに対する正規表現等の評価規則のセットからなるものとする。ここで、図３４は、内部イベントと状態条件設定の具体例を示す図である。図３４（Ａ）は、内部イベントの一例を示し、図３４（Ｂ）は、状態条件判定部７２は、判定時に用いられる状態条件の一例を示している。図３４（Ａ）に示す内部イベントの一例では、温度（ｔｅｍｐｅｒａｔｕｒｅ）、湿度（ｈｕｍｉｄｉｔｙ）、時（ｈｏｕｒ）、分（ｍｉｎ）を有しているが種類や数については、これに限定されるものではない。

図３４（Ａ）に示すような内部イベントの値に対し、図３４（Ｂ）に示すような正規表現等を用いて、各状態条件（例えば、気温が２０のとき合致、毎時３０分のとき合致、毎時３０分かつ気温が２０のとき合致等）を設定することができる。このように、第４実施形態では、内部イベントの各項目に対して独立に正規表現による一致評価を行った結果の論理積又は論理和等を評価することによって、柔軟な条件指定が可能となる。なお、状態条件の設定例は、図３４（Ｂ）の例に限定されるものではない。

ノード名は、ノードを識別するための情報である。一意名は、プラグイン名を識別するための識別情報である。親ノードは、１つ上位のノード情報である。トップノードの親ノードには、ｎｕｌｌが設定される。部分条件定義ＩＤは、部分条件判定が設定された場合に、その識別情報が設定される。直近状態は、そのノードの直近の変化の状態を示す情報である。変化がない場合には、ｎｕｌｌが設定される。配下のノードリストは、自己ノードの１つの下の層に配置されたノード情報である。条件は、各ノードにおける条件の情報である。

例えば、図３２（Ｃ）の例では、ノード１，２，３によるツリー条件判定が第１のプラグイン３１のツリー条件判定部７１で実行される処理である。また、図３２（Ｃ）に示すノード２，４，５によるツリー条件判定は、一意名（ｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｅｓｔ）で同一であるため、対応する下位ノード（例えば、拡張機能プラグイン３２）のツリー条件判定部７１で処理が行われ、ノード４，５の状態条件判定は同じ拡張機能プラグイン３２で行われる。また、図３２（Ｃ）に示すノード３の状態条件判定は、一意名（ｃｏｍ．ＡＡＡ．ｘｘ．ｐｏｓｔｕｒｅ）に対応する下位ノードの状態条件判定部７２で処理が行われる。

なお、図３２（Ｃ）に示すようなノードツリーに対して、配下のアクセス先や一意名に対応させて上位ノードのアクセス先や一意名にも同一の情報を格納する一意名埋め処理やアクセス先埋め処理等を行う。例えば配下のノードのアクセス先が「ｌｏｃａｌ」の場合には、上位ノードのアクセス先を「ｎｕｌｌ」から「ｌｏｃａｌ」に変更する等の処理を行う。

上述したように、第４実施形態では、生成したノードツリーにより、各ノードに対応する各状態条件判定部によりそれぞれの条件判定が実施され、上位ノードは、下位ノードの判定結果をツリー条件判定で利用して自己の条件判定を行うことができる。そのためＣＰＵ等の処理負荷を低減することができる。

例えば、下位ノードからイベントが発生した場合には、図３３に示すような流れとなる。なお、図３３の例では、第１のプラグインが有するツリーと、（端末内）拡張機能プラグイン管理部２５−１が有するツリーと、（端末内）拡張機能プラグイン３２−１の一例であるｃｏｍ．ＡＡＡ．ｘｘ．ｐｏｓｔｕｒｅ機能が有するツリーと、（端末内）拡張機能プラグイン３２−１の一例であるｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｅｓｔ機能が有するツリーとが示されている。

第１のプラグインが有するツリーでは、ノード１における条件判定を行う。（端末内）拡張機能プラグイン管理部２５−１が有するツリーでは、ノード１〜３における条件判定を行う。ｃｏｍ．ＡＡＡ．ｘｘ．ｐｏｓｔｕｒｅ機能が有するツリーでは、ノード３における条件判定を行う。ｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｅｓｔ機能が有するツリーでは、ノード２，４，５における条件判定を行う。

（端末内）拡張機能プラグイン管理部２５−１が有するツリーに含まれるノード２は、ｃｏｍ．ＡＡＡ．ｘｘ．ｗｒｉｓｔｅｓｔ機能が有するツリー条件判定部７１からノード２の状態の変化イベントを受け取る。受け取るイベントとしては、例えば「ｅｖｅｎｔｎａｍｅ：ｎｏｄｅ２，ｓｔａｔｅ：ｔｒｕｅ（又はｆａｌｓｅ）」等であるが、これに限定されるものではない。また、（端末内）拡張機能プラグイン管理部２５−１が有するツリーに含まれるノード３は、ｃｏｍ．ＡＡＡ．ｘｘ．ｐｏｓｔｕｒｅ機能が有するツリー条件判定部７１からノード３の状態変化イベントを受け取る。受け取るイベントとしては、例えば「ｅｖｅｎｔｎａｍｅ：ｎｏｄｅ３，ｓｔａｔｅ：ｔｒｕｅ（又はｆａｌｓｅ）」であるが、これに限定されるものではない。

（端末内）拡張機能プラグイン管理部２５−１が有するツリーでは、下位層からノード２及びノード３に対するイベントを受信した場合に、それぞれのノードの直近状態に条件に応じたｔｒｕｅ又はｆａｌｓｅを格納する。また、ノード２，３の直近状態からノード１を評価して、部分定義ＩＤ名のイベントを第１のプラグインへ発行する。これにより、プラグインが有するノード１では、（端末内）拡張機能プラグイン管理部２５−１が有するツリー条件判定結果を用いて状態を判定することができる。

上述したように、第４実施形態では、複数の拡張機能を用いる複合的な条件によるイベントをアプリが利用したい場合に、アプリが利用したい条件はアプリ毎に異なるため、アプリが任意の条件を設定して、その条件のｔｒｕｅ／ｆａｌｓｅの変化時にイベントを発行する状態条件判定部７２を拡張機能プラグイン３２に持たせる。

例えば、第４実施形態では、状態条件判定部７２を第１のプラグイン３１、拡張機能プラグイン管理部２５、拡張機能プラグイン３２にそれぞれ持たせ、条件を上位層の第１のプラグイン３１から下位層の拡張機能プラグイン３２まで分割しながら部分条件として設定していく。各部は、自身に登録された部分条件を満たしたら上位にイベントを送る。これにより、第４実施形態では、例えば状態条件判定部７２を各周辺機器のプラグイン（第２のプラグイン）又は各サーバのプラグイン（第３のプラグイン）で行う構成となるため、アプリ側（第１のプラグイン）の処理負荷を低減し、省電力化することができる。

また、内部イベントは、各状態条件判定部７２の中で閉じたイベントであり、固有のタイミングで発行される。また、状態条件判定部７２は、自らが発行した内部イベントと、登録済みの状態条件を比較することで自らが保有している状態の遷移を行う。この処理は、各状態条件判定部７２の種類等によらないため、全ての条件判定に共通する処理として自動化することができる。つまり、第４実施形態では、状態の保持管理処理を全て自動化できるため、条件判定等の処理を実装する必要がなくなり、開発者の負担が大幅に低減できる。また、内部イベントの形式を工夫することにより、正規表現と組み合わせて柔軟な条件指定が可能となる。

上述したように、本実施形態によれば、アプリが周辺機器又はサーバを利用するための機能拡張を迅速に行えるようにすることができる。例えば、端末装置を周辺機器（センサ等も含む）又はサーバと接続して連携させる場合、その周辺機器又はサーバに対応するプラグインを組み込んでアプリ実行環境をビルドし、端末装置にインストールしている。そして、新たなプラグインを追加したい場合や、予め組み込んだプラグインを削除する場合には、一旦実行中のアプリ実行環境を停止し、インストールされているプラグインが組み込まれたアプリ実行環境をアンインストールして、新たにアプリ実行環境とプラグインの接続関係を再ビルドしてインストールする必要がある。また、従来では、「どの状況条件でどのアプリを実行する」というルールに基づいてアプリ切り替えを行う場合がある。その場合、条件が変わる毎にアプリ実行環境とプラグインの接続関係とを再ビルドするために、アプリ実行環境を一旦停止して再動作させなければならず、配信したモバイルアプリを迅速に実行することができない。

そこで、本実施形態では、例えばアプリの実行環境に周辺機器又はサーバのソフトウェアモジュールにおいて共通する第１のプラグインを接続し、各周辺機器固有の第２のプラグイン又は各サーバ固有の第３のプラグインを第１のプラグインを介して、ウェブアプリの実行環境に接続して配置しておいて、端末装置が制御する他の周辺機器又はサーバを追加する場合に、他の周辺機器又はサーバに対応する第２、第３のプラグインを第１のプラグインを介して、ウェブアプリの実行環境に接続して配置する。また、本実施形態では、端末装置が制御する周辺機器又はサーバを削除する場合には、ウェブアプリの実行環境と第１のプラグインの接続関係を維持しつつ、削除する周辺機器又はサーバに対応する第２、第３のプラグインを削除する。これにより、ウェブアプリがセンサや機器又はサーバを利用するための機能拡張を迅速に行うことができる。

以上、実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、上述した実施例の一部又は全部を組み合わせることも可能である。

なお、以上の実施例に関し、更に以下の付記を開示する。
（付記１）
端末装置が、
１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
前記端末装置が制御する他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、ことを特徴とする機能拡張方法。
（付記２）
前記端末装置が制御する周辺機器に対応する第２のプラグインを削除する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、削除対象の周辺機器に対応する第２のプラグインを削除することを特徴とする付記１に記載の機能拡張方法。
（付記３）
前記端末装置の位置情報に対応して実行可能な周辺機器の情報を取得し、
取得した前記周辺機器の情報に基づいて、前記周辺機器に対応する前記第２のプラグインの接続制御を行うことを特徴とする付記１又は２に記載の機能拡張方法。
（付記４）
前記端末装置の位置や時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む状態変化に対応して、現在の状態で実行可能な周辺機器の情報を取得することを特徴とする付記３に記載の機能拡張方法。
（付記５）
前記第２のプラグインは、
第１のプラグインから指定された発行条件に基づいて、前記端末装置の位置、時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む通知情報を発行し、指定された発行条件に基づいて通知情報を生成するか否かの判定処理を、前記第２のプラグインに対応する周辺機器で実行可能な場合に、前記判定処理を周辺機器で実行させることを特徴とする、付記１乃至４の何れかに記載の機能拡張方法。
（付記６）
前記判定処理のうち、複数の判定処理の結果を組み合わせた複合的な判定処理について、複数の判定処理が同一の第２のプラグインに対応する周辺機器で実行可能な場合に、複数の判定処理とそれら判定処理の結果を組み合わせた複合的な判定処理の一部又は全部を周辺機器で実行することを特徴とする、付記５に記載の機能拡張方法。
（付記７）
前記第１のプラグインは、実行するアプリケーションが利用する機能を記載した機能情報リストを取得し、
取得した前記機能情報リストから前記周辺機器を利用できる機能が内部にない場合に、前記周辺機器に対応する第２のプラグインを選択して取得することを特徴とする付記１乃至６の何れか１項に記載の機能拡張方法。
（付記８）
前記第１のプラグインは、
前記アプリケーションが停止する時に、前記アプリケーションに対応する前記機能情報リストを削除すると共に、保持する機能情報リストにない第２のプラグインを削除することを特徴とする付記７に記載の機能拡張方法。
（付記９）
端末装置が、
１又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、
前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
前記端末装置が制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする機能拡張方法。
（付記１０）
前記端末装置が制御するサーバに対応する第３のプラグインを削除する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、削除対象のサーバに対応する第３のプラグインを削除することを特徴とする付記９に記載の機能拡張方法。
（付記１１）
端末装置が、
ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
前記第４のプラグインは、定期的、又は、リクエストのブロードキャスト発信があったことを受けて、前記端末装置に自己の機能情報をブロードキャスト発信し、
前記端末装置は、該発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、ことを特徴とする機能拡張方法。
（付記１２）
１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
（付記１３）
１又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、
前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
端末装置が制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
（付記１４）
ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
前記第４のプラグインは、定期的、又は、リクエストのブロードキャスト発信があったことを受けて、前記端末装置に自己の機能情報をブロードキャスト発信し、
端末装置は、該発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
（付記１５）
１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
前記プラグイン管理部は、他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。
（付記１６）
１又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
前記プラグイン管理部は、制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。
（付記１７）
ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
前記プラグイン管理部は、前記第４のプラグインにより、定期的、又は、リクエスト要求に対して、ブロードキャスト発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。

１０ 機能拡張システム
１１ アプリサーバ
１２ 拡張機能プラグインサーバ
１３ 端末装置
１４ 通信ネットワーク
１５ 周辺機器
１６ サーバ
１７ 拡張機能プラグイン管理装置
２１ 入力部
２２ 出力部
２３ 記憶部
２４ アプリ実行部
２５ 拡張機能プラグイン管理部（プラグイン管理部）
２６ 通信部
３１ 第１のプラグイン
３２ 拡張機能プラグイン（第２のプラグイン）
３３ 拡張機能プラグイン（第３のプラグイン）
３４ 拡張機能プラグイン（第４のプラグイン）
４１ マイク
４２ スピーカ
４３ 表示部
４４ 操作部
４５ センサ部
４６ 電力部
４７ 無線部
４８ 近距離通信部
４９ 補助記憶装置
５０ 主記憶装置
５１ ＣＰＵ
５２ ドライブ装置
５３ 記録媒体
６１ モバイルアプリ（アプリ）
６２ 機能情報リスト
７１ ツリー条件判定部
７２ 状態条件判定部
７３ 条件ツリー
８１ 状態条件登録受付部
８２ 状態条件記憶部
８３ 条件マッチング判定部
８４ 状態管理部
８５ 機能固有ロジック
９０ 条件ツリー駆動プログラム
９１ 機能固有デバイス（センサ等）

Claims (14)

1. 端末装置が、
   １又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
   前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
   前記端末装置が制御する他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、ことを特徴とする機能拡張方法。
2. 前記端末装置が制御する周辺機器に対応する第２のプラグインを削除する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、削除対象の周辺機器に対応する第２のプラグインを削除することを特徴とする請求項１に記載の機能拡張方法。
3. 前記端末装置の位置情報に対応して実行可能な周辺機器の情報を取得し、
   取得した前記周辺機器の情報に基づいて、前記周辺機器に対応する前記第２のプラグインの接続制御を行うことを特徴とする請求項１又は２に記載の機能拡張方法。
4. 前記端末装置の位置や時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む状態変化に対応して、現在の状態で実行可能な周辺機器の情報を取得することを特徴とする請求項３に記載の機能拡張方法。
5. 前記第２のプラグインは、
   第１のプラグインから指定された発行条件に基づいて、前記端末装置の位置、時刻、端末内部状態の変化、周辺の変化、及び外部からのイベント受信のうち、少なくとも１つを含む通知情報を発行し、指定された発行条件に基づいて通知情報を生成するか否かの判定処理を、前記第２のプラグインに対応する周辺機器で実行可能な場合に、前記判定処理を周辺機器で実行させることを特徴とする、請求項１乃至４の何れかに記載の機能拡張方法。
6. 前記判定処理のうち、複数の判定処理の結果を組み合わせた複合的な判定処理について、複数の判定処理が同一の第２のプラグインに対応する周辺機器で実行可能な場合に、複数の判定処理とそれら判定処理の結果を組み合わせた複合的な判定処理の一部又は全部を周辺機器で実行することを特徴とする、請求項５に記載の機能拡張方法。
7. 端末装置が、
   １又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、
   前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
   前記端末装置が制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする機能拡張方法。
8. 端末装置が、
   ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
   前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
   前記第４のプラグインは、定期的、又は、リクエストのブロードキャスト発信があったことを受けて、前記端末装置に自己の機能情報をブロードキャスト発信し、
   前記端末装置は、該発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、ことを特徴とする機能拡張方法。
9. １又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
   前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
   他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
10. １又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、
    前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
    端末装置が制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
11. ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、
    前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置し、
    前記第４のプラグインは、定期的、又は、リクエストのブロードキャスト発信があったことを受けて、端末装置に自己の機能情報をブロードキャスト発信し、
    前記端末装置は、該発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続する、処理をコンピュータに実行させる機能拡張プログラム。
12. １又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
    前記プラグイン管理部は、他の周辺機器を追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他の周辺機器に対応する第２のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。
13. １又は複数のサーバを制御するアプリケーションの実行環境に、前記サーバに共通する第１のプラグインを接続し、前記サーバのそれぞれに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
    前記プラグイン管理部は、制御する他のサーバを追加する場合に、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記他のサーバに対応する第３のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。
14. ブロードキャストにより通信される１又は複数の周辺機器を制御するアプリケーションの実行環境に、前記周辺機器に共通する第１のプラグインを接続し、前記周辺機器のそれぞれに対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続されるように配置するプラグイン管理部を有し、
    前記プラグイン管理部は、前記第４のプラグインにより、定期的、又は、リクエスト要求に対して、ブロードキャスト発信された機能情報を受け付けて、実行可能な周辺機器の情報を生成し、前記アプリケーションの実行環境と前記第１のプラグインとの接続関係を維持しつつ、前記周辺機器に対応する第４のプラグインを、前記第１のプラグインを介して前記アプリケーションの実行環境に接続することを特徴とする端末装置。

Images