JP6217092B2 - 情報処理装置、システム、情報処理方法及びプログラム - Google Patents

Description

本技術は、プログラムによる機能呼び出し技術に関する。

ある特許文献には、ユーザソフトウエアアプリケーションの能力を制御する技術が開示されている。この技術では、ユーザソフトウエアアプリケーションにおいて許可されていなかった付加的な機能の動作を、所定のコンテントを受け取った場合に許可する。

また、別の特許文献には、サービス定義に基づいてＷｅｂサービスへのアクセスに関する許可ポリシーを定義する技術が開示されている。

このように、ユーザソフトウエアアプリケーションの付加的な機能やＷｅｂサービスへのアクセスを制限すれば、利用者による不当な使用を排除し、ユーザソフトウエアアプリケーションやＷｅｂサービスの提供者側の利益が守られる面がある。

但し、機能の制限によって排除されるのは、利用者側の使用に限られない。例えば、あるオペレーティングシステムでは、Ｗｅｂアプリケーションによって利用できる機能を予め設定し、特定のＷｅｂアプリケーションによる特定機能の利用を制限するようにしている。このようにすれば、プログラムの提供者側で企図する処理を利用者の判断で制限することによって、利用者側の安全性が保たれる。

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

本技術の目的は、一側面では、プログラムによる特定機能の利用を、自動的に制限することを目的とする。

一態様に係る情報処理装置は、プログラムの実行中に、特定機能に係る呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する生成部と、コンテキストに基づいて、呼び出しの許否を判定する判定部とを有する。

一側面としては、プログラムによる特定機能の利用を、自動的に制限できる。

図１は、機能制限システムの利用態様の例を示す図である。 図２は、機能制限システムの利用態様の例を示す図である。 図３は、機能制限システムの構成例を示す図である。 図４は、利用者端末のモジュール構成例を示す図である。 図５は、格納部と制限部と記憶部の構成例を示す図である。 図６は、生成ルールテーブルの例を示す図である。 図７は、判定ルールテーブル例を示す図である。 図８は、シーケンスの例を示す図である。 図９は、シーケンスの例を示す図である。 図１０は、シーケンスの例を示す図である。 図１１は、シーケンスの例を示す図である。 図１２は、検出処理（エンジン監視型）フローの例を示す図である。 図１３は、判定処理フローの例を示す図である。 図１４は、コンテキスト生成処理フローの例を示す図である。 図１５は、実施の形態２に係るシーケンスの例を示す図である。 図１６は、実施の形態２に係るシーケンスの例を示す図である。 図１７は、実施の形態２に係るシーケンスの例を示す図である。 図１８は、実施の形態２に係るシーケンスの例を示す図である。 図１９は、検出処理（ＡＰＩ監視型）フローの例を示す図である。 図２０は、実施の形態３に係る機能制限システムの構成例を示す図である。 図２１は、中継装置のモジュール構成例を示す図である。 図２２は、実施の形態３に係る格納部と制限部と記憶部の構成例を示す図である。 図２３は、実施の形態３に係る利用者端末のモジュール構成例を示す図である。 図２４は、実施の形態３に係るシーケンスの例を示す図である。 図２５は、実施の形態３に係るシーケンスの例を示す図である。 図２６は、実施の形態３に係るシーケンスの例を示す図である。 図２７は、実施の形態３に係るシーケンスの例を示す図である。 図２８は、実施の形態４に係る格納部と制限部と記憶部の構成例を示す図である。 図２９は、実施の形態４に係る利用者端末のモジュール構成例を示す図である。 図３０は、実施の形態４に係るシーケンスの例を示す図である。 図３１は、実施の形態４に係るシーケンスの例を示す図である。 図３２は、実施の形態４に係るシーケンスの例を示す図である。 図３３は、実施の形態４に係るシーケンスの例を示す図である。 図３４は、携帯型情報処理装置のハードウエア構成例を示す図である。

［実施の形態１］
本実施の形態では、状況に係るコンテキストに基づいて、Ｗｅｂアプリケーションに対して利用者端末のオペレーティングシステムで提供するＡＰＩ（Application Program Interface）の呼び出しを制限する。

まず、図１及び２に基づいて、機能制限システムの利用態様について説明する。図１に示す機能制限システムの利用態様は、位置条件とネットワーク条件とに基づいて、コンテキストが判定される例を示している。つまり、この利用態様におけるコンテキストは、利用者端末１００の位置と利用者端末１００が接続するネットワークとによる状況を識別する情報である。また、この利用態様では、コンテキストに基づいて、アドレス帳機能に係るＡＰＩと署名機能に係るＡＰＩとの利用可否が判定される例を示している。

利用者端末１００が社内ネットワークに接続している状況では、コンテキスト「ＣＮＴ＿Ａ」が生成される。そして、コンテキスト「ＣＮＴ＿Ａ」では、すべてのＷｅｂアプリケーションにおいてアドレス帳機能に係るＡＰＩについての判定結果が「利用可」となり、署名機能に係るＡＰＩについての判定結果も「利用可」となる。

つまり、利用者端末１００は、その位置に関わらず、社内ネットワークに接続していれば、あらゆるＷｅｂアプリケーションにおいてアドレス帳の機能と署名の機能とが動作する。この場合には、例えば社員間の連絡や社用文書の発行などが許可される。

利用者端末１００が社内ネットワーク以外に接続し、且つ利用者端末１００が会社敷地内（以下、社内という。）に位置している状況では、コンテキスト「ＣＮＴ＿Ｂ」が生成される。そして、コンテキスト「ＣＮＴ＿Ｂ」では、すべてのＷｅｂアプリケーションにおいてアドレス帳機能に係るＡＰＩについての判定結果が「利用可」となり、署名機能に係るＡＰＩについての判定結果が「利用不可」となる。

つまり、利用者端末１００が社内で社内ネットワーク以外に接続していれば、あらゆるＷｅｂアプリケーションにおいてアドレス帳の機能は動作するが、署名の機能は動作しない。この場合には、例えば社員間の連絡は許可されるが、社用文書の発行は拒否される。

利用者端末１００が社内ネットワーク以外に接続し、且つ利用者端末１００が会社敷地外（以下、社外という。）に位置している状況では、コンテキスト「ＣＮＴ＿Ｃ」が生成される。そして、コンテキスト「ＣＮＴ＿Ｃ」では、すべてのＷｅｂアプリケーションにおいてアドレス帳機能に係るＡＰＩについての判定結果が「利用不可」となり、署名機能に係るＡＰＩについての判定結果も「利用不可」となる。

つまり、利用者端末１００が社外で社内ネットワーク以外に接続していれば、あらゆるＷｅｂアプリケーションにおいてアドレス帳の機能も、署名の機能も動作しない。この場合には、例えば社員間の連絡も、社用文書の発行も拒否される。以上で、図１に示す機能制限システムの利用態様の説明を終える。

図２に示す機能制限システムの利用態様の説明に移る。図２に示す機能制限システムの利用態様は、時刻条件とＷｅｂアプリケーション条件とに基づいて、コンテキストが判定される例を示している。つまり、この利用態様におけるコンテキストは、現在時刻と利用者端末１００で動作しているＷｅｂアプリケーションとによる状況を識別する情報である。

現在時刻が、勤務時間帯内であり、利用者端末１００でＷｅｂアプリケーション「ＡＰＬ＿Ｘ」が動作している状況では、コンテキスト「ＣＮＴ＿Ｄ」が生成される。そして、コンテキスト「ＣＮＴ＿Ｄ」では、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳ（Global Positioning System）機能に係るＡＰＩについての判定結果が「利用可」となり、復号機能に係るＡＰＩについての判定結果も「利用可」となる。

つまり、利用者端末１００は、勤務時間帯内に、Ｗｅｂアプリケーション「ＡＰＬ＿Ｘ」を動作させていれば、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳの機能と復号の機能とが動作する。この場合には、例えば所在位置に関連する秘密文書を閲覧することが許可される。

現在時刻が、勤務時間帯内であり、利用者端末１００でＷｅｂアプリケーション「ＡＰＬ＿Ｘ」が動作していない状況では、コンテキスト「ＣＮＴ＿Ｅ」が生成される。そして、コンテキスト「ＣＮＴ＿Ｅ」では、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳ機能に係るＡＰＩについての判定結果が「利用可」となり、復号機能に係るＡＰＩについての判定結果が「利用不可」となる。

つまり、利用者端末１００は、勤務時間帯内に、Ｗｅｂアプリケーション「ＡＰＬ＿Ｘ」を動作させていなければ、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳの機能は動作するが、復号の機能は動作しない。この場合には、例えば所在位置に関連する一般文書を閲覧することは許可されるが、所在位置に関連する秘密文書を閲覧することは拒否される。

現在時刻が、勤務時間帯外である状況では、コンテキスト「ＣＮＴ＿Ｆ」が生成される。そして、コンテキスト「ＣＮＴ＿Ｆ」では、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳ機能に係るＡＰＩについての判定結果が「利用不可」となり、復号機能に係るＡＰＩについての判定結果も「利用不可」となる。

つまり、利用者端末１００は、勤務時間帯外であれば、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」においてＧＰＳの機能も、復号の機能も動作しない。この場合には、例えば所在位置に関連する一切の文書を閲覧することは許可されない。以上で、機能制限システムの利用態様についての説明を終える。

次に、機能制限システムの構成について説明する。図３に、機能制限システムの構成例を示す。インターネットには、Ｗｅｂアプリケーションを提供するサービスを実現するＷｅｂアプリケーションサーバ３０１ａ乃至ｃが接続されている。利用者端末１００は、Ｗｅｂアプリケーションサーバ３０１ａ乃至ｃと接続する場合には、インターネットを介してＷｅｂアプリケーションサーバ３０１ａ乃至ｃの各々にアクセスする。

また、社内ネットワークは、ルータ３０３を介してインターネットに接続している。社内ネットワークには、社内サーバ３０５が設けられている。利用者端末１００は、社内サーバ３０５と接続する場合には、インターネットと社内ネットワークとを介して社内サーバ３０５にアクセスする。但し、利用者端末１００は、直接社内ネットワークを介して社内サーバ３０５にアクセスするようにしてもよい。

社内サーバ３０５は、利用者端末１００に対して社内サービスを提供する。また、社内サーバ３０５は、利用者端末１００における動作に用いられるデータを配信するようにしてもよい。以上で、機能制限システムの構成についての説明を終える。

次に、利用者端末１００のモジュール構成について説明する。図４に、利用者端末１００のモジュール構成例を示す。利用者端末１００は、オペレーティングシステム（ＯＳ）４０１、Ｗｅｂブラウザ４０５、制限部４０７、格納部４０９、記憶部４１１、送信部４１３、受信部４１５、表示部４１７及び受付部４１９を有している。

オペレーティングシステム４０１は、ＡＰＩ群を備えるフレームワーク４０３を有している。この例で、ＡＰＩ群には、ＧＰＳ機能に係るＡＰＩ４３１ａ、署名機能に係るＡＰＩ４３１ｂ、通信機能に係るＡＰＩ４３１ｃ、復号機能に係るＡＰＩ４３１ｄ、アドレス帳機能に係るＡＰＩ４３１ｅ及び時計機能に係るＡＰＩ４３１ｆが含まれている。但し、他の機能に係るＡＰＩを設けるようにしてもよい。

Ｗｅｂブラウザ４０５は、スクリプトエンジン４５１を含んでいる。スクリプトエンジン４５１は、スクリプトを実行する。Ｗｅｂブラウザ４０５には、プラグイン４５３を追加される場合がある。本実施の形態における一部のモジュールを、プラグイン４５３により実現するようにしてもよい。

制限部４０７は、ＷｅｂアプリケーションによるＡＰＩの利用を制限する。格納部４０９は、制限部４０７の処理に用いられるデータを予め格納する。記憶部４１１は、制限部４０７の処理により生じるデータを記憶する。送信部４１３は、データをインターネットに向けて送信する。受信部４１５は、インターネットからデータを受信する。表示部４１７は、例えば操作に係る画面を表示する。受付部４１９は、例えば利用者の操作によるデータ入力を受け付ける。

更に、図５を用いて、格納部４０９と制限部４０７と記憶部４１１との詳細について説明する。格納部４０９は、この例では生成ルールテーブル、判定ルールテーブル及び検証データを格納する。

生成ルールは、コンテキストを生成するためのルールである。図６に、生成ルールテーブルの例を示す。図６のレコードは、コンテキストを生成するルールに相当する。レコードには、コンテキスト、時刻条件、位置条件、ネットワーク条件及びＷｅｂアプリケーション条件のフィールドが設けられている。

第１レコードには、時刻条件、位置条件及びＷｅｂアプリケーション条件は設定されておらず、ネットワーク条件としては、利用者端末１００が社内ネットワークに接続していることが定められている。従って、第１レコードによれば、現在時刻、利用者端末１００の位置及び利用者端末１００で動作しているＷｅｂアプリケーションの如何に関わらず、利用者端末１００が社内ネットワークに接続していれば、コンテキスト「ＣＮＴ＿Ａ」が生成される。

第１レコードの条件を、例えば条件式「ネットワーク＝社内ネットワーク」で表してもよい。

第２レコードには、時刻条件及びＷｅｂアプリケーション条件は設定されておらず、位置条件としては、利用者端末１００の位置が社内に含まれることが定められ、ネットワーク条件としては、利用者端末１００が社内ネットワーク以外に接続していることが定められている。従って、第２レコードによれば、現在時刻及び利用者端末１００で動作しているＷｅｂアプリケーションの如何に関わらず、利用者端末１００が社内で社内ネットワーク以外に接続していれば、コンテキスト「ＣＮＴ＿Ｂ」が生成される。

第２レコードの条件を、例えば条件式「位置＝社内 ＡＮＤ ネットワーク＝ＮＯＴ 社内ネットワーク」で表してもよい。

第３レコードには、時刻条件及びＷｅｂアプリケーション条件は設定されておらず、位置条件としては、利用者端末１００の位置が社外であることが定められ、ネットワーク条件としては、利用者端末１００が社内ネットワーク以外に接続していることが定められている。

従って、第３レコードによれば、現在時刻及び利用者端末１００で動作しているＷｅｂアプリケーションの如何に関わらず、利用者端末１００が社外で社内ネットワーク以外に接続していれば、コンテキスト「ＣＮＴ＿Ｃ」が生成される。

第３レコードの条件を、例えば条件式「位置＝ＮＯＴ 社内 ＡＮＤ ネットワーク＝ＮＯＴ 社内ネットワーク」で表してもよい。

第４レコードには、位置条件及びネットワーク条件は設定されておらず、時刻条件としては、現在時刻が業務時間帯内であることが定められ、Ｗｅｂアプリケーション条件としては、利用者端末１００が「ｘｘｘ．ｊｐ／ｘｘ」のＵＲＬで特定されるＷｅｂアプリケーション（「ＡＰＬ＿Ｘ」という。）を動作させていることが定められている。従って、第４レコードによれば、利用者端末１００の位置及び利用者端末１００が接続しているネットワークの如何に関わらず、業務時間中にＷｅｂアプリケーション「ＡＰＬ＿Ｘ」を動作させていれば、コンテキスト「ＣＮＴ＿Ｄ」が生成される。

第４レコードの条件を、例えば条件式「現在時刻＞始業時刻 ＡＮＤ 現在時刻＜終業時刻 ＡＮＤ Ｗｅｂアプリケーション＝ｘｘｘ．ｊｐ／ｘｘ」で表してもよい。

第５レコードには、位置条件及びネットワーク条件は設定されておらず、時刻条件としては、現在時刻が業務時間帯内であることが定められ、Ｗｅｂアプリケーション条件としては、利用者端末１００が「ｘｘｘ．ｊｐ／ｘｘ」のＵＲＬで特定されるＷｅｂアプリケーション（「ＡＰＬ＿Ｘ」という。）を動作させていないことが定められている。従って、第５レコードによれば、利用者端末１００の位置及び利用者端末１００が接続しているネットワークの如何に関わらず、業務時間中にＷｅｂアプリケーション「ＡＰＬ＿Ｘ」を動作させていなければ、コンテキスト「ＣＮＴ＿Ｅ」が生成される。

第５レコードの条件を、例えば条件式「現在時刻＞始業時刻 ＡＮＤ 現在時刻＜終業時刻 ＡＮＤ Ｗｅｂアプリケーション＝ＮＯＴ ｘｘｘ．ｊｐ／ｘｘ」で表してもよい。

第６レコードには、位置条件、ネットワーク条件及びＷｅｂアプリケーション条件は設定されておらず、時刻条件としては、現在時刻が業務時間帯外であることが定められている。従って、第６レコードによれば、利用者端末１００の位置、利用者端末１００が接続しているネットワーク及び利用者端末１００で動作しているＷｅｂアプリケーションの如何に関わらず、業務時間外であれば、コンテキスト「ＣＮＴ＿Ｆ」が生成される。

第６レコードの条件を、例えば条件式「現在時刻＜始業時刻 ＯＲ 現在時刻＞終業時刻」で表してもよい。図６の例では、生成ルールをレコード形式で表したが、上述のように条件式形式で表してもよい。

図５の説明に戻って、格納部４０９に格納されている判定ルールは、ＡＰＩの利用可否の判定に用いられるルールである。

図７に、判定ルールテーブルの例を示す。図７におけるレコードは、判定ルールに相当する。レコードには、コンテキスト、Ｗｅｂアプリケーション、アドレス帳機能に係るＡＰＩ、署名機能に係るＡＰＩ、ＧＰＳ機能に係るＡＰＩ及び復号機能に係るＡＰＩのフィールドが設けられている。

Ｗｅｂアプリケーションのフィールドは、当該判定ルールを適用するＷｅｂアプリケーションを限定する場合に用いられる。具体的には、当該判定ルールを適用するＷｅｂアプリケーションを提供するサービスのＵＲＬが設定される。従って、このＵＲＬは、Ｗｅｂアプリケーションを特定する情報であるとともに、Ｗｅｂアプリケーションを提供するサービスを特定する情報でもある。

アドレス帳機能に係るＡＰＩ、署名機能に係るＡＰＩ、ＧＰＳ機能に係るＡＰＩ及び復号機能に係るＡＰＩには、各ＡＰＩの利用の可否が設定される。

第１レコードは、コンテキスト「ＣＮＴ＿Ａ」に基づき、すべてのＷｅｂアプリケーションに対して、アドレス帳機能に係るＡＰＩが、「利用可」であることを示している。同様に、署名機能に係るＡＰＩは、「利用可」であるが、ＧＰＳ機能に係るＡＰＩは、「利用不可」であり、復号機能に係るＡＰＩも、「利用不可」であることを示している。

従って、第１レコードによれば、例えば任意のＷｅｂアプリケーションが、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ａ」に基づいて許可される。同様に、任意のＷｅｂアプリケーションが、署名機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ａ」に基づいて許可され、一方、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ａ」に基づいて拒否され、復号機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ａ」に基づいて拒否される。

第２レコードは、コンテキスト「ＣＮＴ＿Ｂ」に基づき、すべてのＷｅｂアプリケーションに対して、アドレス帳機能に係るＡＰＩが、「利用可」であることを示している。同様に、署名機能に係るＡＰＩは、「利用不可」であり、ＧＰＳ機能に係るＡＰＩも、「利用不可」であり、復号機能に係るＡＰＩも、「利用不可」であることを示している。

従って、第２レコードによれば、例えば任意のＷｅｂアプリケーションが、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｂ」に基づいて許可される。同様に、任意のＷｅｂアプリケーションが、署名機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｂ」に基づいて拒否され、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｂ」に基づいて拒否され、復号機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｂ」に基づいて拒否される。

第３レコードは、コンテキスト「ＣＮＴ＿Ｃ」に基づき、すべてのＷｅｂアプリケーションに対して、アドレス帳機能に係るＡＰＩが、「利用不可」であることを示している。同様に、署名機能に係るＡＰＩも、「利用不可」であり、ＧＰＳ機能に係るＡＰＩも、「利用不可」であり、復号機能に係るＡＰＩも、「利用不可」であることを示している。

従って、第３レコードによれば、例えば任意のＷｅｂアプリケーションが、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｃ」に基づいて拒否される。同様に、任意のＷｅｂアプリケーションが、署名機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｃ」に基づいて拒否され、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｃ」に基づいて拒否され、復号機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｃ」に基づいて拒否される。

第４レコードは、コンテキスト「ＣＮＴ＿Ｄ」に基づき、利用者端末１００が「ｚｚｚ．ｊｐ／ｚｚ」のＵＲＬで特定されるＷｅｂアプリケーション（「ＡＰＬ＿Ｚ」という。）に対して、アドレス帳機能に係るＡＰＩが、「利用不可」であることを示している。同様に、署名機能に係るＡＰＩも、「利用不可」であるが、ＧＰＳ機能に係るＡＰＩは、「利用可」であり、復号機能に係るＡＰＩも、「利用可」であることを示している。

従って、第４レコードによれば、例えばＷｅｂアプリケーション「ＡＰＬ＿Ｚ」が、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｄ」に基づいて拒否される。同様に、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」が、署名機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｄ」に基づいて拒否されるが、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｄ」に基づいて許可され、復号機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｄ」に基づいて許可される。

第５レコードは、コンテキスト「ＣＮＴ＿Ｅ」に基づき、利用者端末１００が「ｚｚｚ．ｊｐ／ｚｚ」のＵＲＬで特定されるＷｅｂアプリケーションに対して、アドレス帳機能に係るＡＰＩが、「利用不可」であることを示している。同様に、署名機能に係るＡＰＩも、「利用不可」であるが、ＧＰＳ機能に係るＡＰＩは、「利用可」である。また復号機能に係るＡＰＩは、「利用不可」であることを示している。

従って、第５レコードによれば、例えばＷｅｂアプリケーション「ＡＰＬ＿Ｚ」が、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｅ」に基づいて拒否される。同様に、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」が、署名機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｅ」に基づいて拒否され、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｅ」に基づいて許可される。また、復号機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｅ」に基づいて拒否される。

第６レコードは、コンテキスト「ＣＮＴ＿Ｆ」に基づき、利用者端末１００が「ｚｚｚ．ｊｐ／ｚｚ」のＵＲＬで特定されるＷｅｂアプリケーションに対して、アドレス帳機能に係るＡＰＩが、「利用不可」であることを示している。同様に、署名機能に係るＡＰＩも、「利用不可」であり、ＧＰＳ機能に係るＡＰＩも、「利用不可」であり、復号機能に係るＡＰＩも、「利用不可」であることを示している。

従って、第６レコードによれば、例えばＷｅｂアプリケーション「ＡＰＬ＿Ｚ」が、アドレス帳機能に係るＡＰＩを呼び出そうとした場合には、コンテキスト「ＣＮＴ＿Ｆ」に基づいて拒否される。同様に、Ｗｅｂアプリケーション「ＡＰＬ＿Ｚ」が、署名機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｆ」に基づいて拒否され、ＧＰＳ機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｆ」に基づいて拒否され、復号機能に係るＡＰＩを呼び出そうとした場合にも、コンテキスト「ＣＮＴ＿Ｆ」に基づいて拒否される。

図５の説明に戻って、格納部４０９に格納されている検証データは、Ｗｅｂアプリケーションを提供するＷｅｂアプリケーションサーバ３０１を検証する際に用いられるデータである。検証データは、例えば、ルート証明書である。

制限部４０７は、生成ルール設定部５０１、判定ルール設定部５０３、検証データ登録部５０５、抽出部５０７、検証部５０９、Ｗｅｂアプリケーション登録部５１１、検出部５１３、コンテキスト生成部５１５及び判定部５１７を有している。

生成ルール設定部５０１は、上述した生成ルールテーブルを格納部４０９に格納させる。生成ルール設定部５０１は、例えば、表示部４１７に生成ルールの入力画面を表示させ、生成ルール入力画面に対する入力の操作を受付部４１９で受け付けることによって、利用者に生成ルールを設定させる。あるいは、生成ルール設定部５０１は、インターネットを介して、生成ルールテーブルを配信する装置（例えば、社内サーバ３０５）から生成ルールテーブルをダウンロードするようにしてもよい。利用者は、例えば準備段階で生成ルール設定部５０１を起動し、生成ルールテーブルを用意する。

判定ルール設定部５０３は、上述した判定ルールテーブルを格納部４０９に格納させる。判定ルール設定部５０３は、例えば、表示部４１７に判定ルールの入力画面を表示させ、判定ルール入力画面に対する入力の操作を受付部４１９で受け付けることによって、利用者に判定ルールを設定させる。あるいは、判定ルール設定部５０３は、インターネットを介して、判定ルールテーブルを配信する装置（例えば、社内サーバ３０５）から判定ルールテーブルテーブルをダウンロードするようにしてもよい。利用者は、例えば準備段階で判定ルール設定部５０３を起動し、判定ルールテーブルを用意する。

検証データ登録部５０５は、検証データを所定の機関（例えば認証局）から取得し、格納部４０９に格納させる。利用者は、例えば準備段階で検証データ登録部５０５を起動し、検証データを用意する。

抽出部５０７は、通信状況を監視し、通信に係る情報（接続先ネットワークのＵＲＬやＷｅｂアプリケーションを提供するサービスのＵＲＬなど）を抽出する。また、抽出部５０７は、接続先のネットワークのＵＲＬを記憶部４１１に記憶させる。

本実施の形態では、抽出部（プロキシ型）５０７ａの例について説明する。抽出部（プロキシ型）５０７ａは、Ｗｅｂブラウザ４０５とＷｅｂアプリケーションサーバ３０１との間の通信を中継する。そのため、Ｗｅｂブラウザ４０５は、抽出部（プロキシ型）５０７ａをプロキシに設定しておく。尚、実施の形態２では、抽出部（ＡＰＩ監視型）５０７ｂの例について説明する。

検証部５０９は、Ｗｅｂアプリケーションサーバ３０１からダウンロードされるＷｅｂアプリケーションを検証する。例えば、ＷｅｂアプリケーションがＨＴＭＬ（HyperText Markup Language）５ファイル形式である場合、検証部５０９は、ダウンロードされるＨＴＭＬ５ファイルに相当するＨＴＴＰ（HyperText Transfer Protocol）レスポンスの署名を検証する。検証部５０９は、Ｗｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーション登録部５１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部４１１に記憶させる。検出部５１３は、ＡＰＩの呼び出しの発生を検出する。本実施の形態に係る検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５におけるスクリプトエンジン４５１への働きかけを監視し、ＡＰＩの呼び出しを要する特定のスクリプトを検出することによって、ＡＰＩの呼び出しの発生を検出する。尚、実施の形態２では、検出部（ＡＰＩ監視型）５１３ｂの例について説明する。

コンテキスト生成部５１５は、コンテキストを生成する。判定部５１７は、コンテキストに基づき、ＡＰＩの利用可否の判定を行う。

記憶部４１１は、例えば、ネットワークアドレスとＷｅｂアプリケーションリストとを記憶する。ネットワークアドレスは、接続先ネットワークのＵＲＬである。Ｗｅｂアプリケーションリストは、利用者端末１００で動作しているＷｅｂアプリケーションを提供したサービスのＵＲＬのリストである。動作を終えたＷｅｂアプリケーションについても、当該ＵＲＬが残されるようにしてもよい。以上で、機能制限システムのモジュール構成についての説明を終える。

続いて、図８乃至１１に基づいて、シーケンスについて説明する。まず、図８のシーケンスの例について説明する。このシーケンスは、Ｗｅｂブラウザ４０５からＷｅｂアプリケーションサーバ３０１にアクセスすることを想定している。Ｗｅｂブラウザ４０５から送出されるＨＴＴＰリクエストは、Ｗｅｂブラウザ４０５におけるプロキシの設定に従って、抽出部（プロキシ型）５０７ａに送られる（Ｓ８０１）。このＨＴＴＰリクエストは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬへのアクセス要求に相当する。そして、抽出部（プロキシ型）５０７ａは、ＨＴＴＰリクエストをＷｅｂアプリケーションサーバ３０１に転送する（Ｓ８０３）。

ＨＴＴＰリクエストに対するＨＴＴＰレスポンスは、Ｗｅｂアプリケーションサーバ３０１から抽出部（プロキシ型）５０７ａへ返される（Ｓ８０５）。ＨＴＴＰレスポンスは、例えばＨＴＭＬ５ファイルに相当する。

監視していたＨＴＴＰリクエストとＨＴＴＰレスポンスとに基づいて、抽出部（プロキシ型）５０７ａは、ネットワークアドレスを抽出する処理を行う（Ｓ８０７）。具体的には、抽出部（プロキシ型）５０７ａは、接続先ネットワークのＵＲＬを特定する。このとき、接続先ネットワークのＵＲＬは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬと一致する。抽出した接続先ネットワークのＵＲＬは、前述の通り記憶部４１１に記憶される。この例では、Ｗｅｂアプリケーションサーバ３０１へのアクセスの例を示したが、他の装置にアクセスする場合にも、抽出部（プロキシ型）５０７ａは、ネットワークアドレスを抽出するようにしてもよい。

抽出部（プロキシ型）５０７ａは、検証部５０９に、Ｗｅｂアプリケーションサーバ３０１のＵＲＬとＨＴＴＰレスポンスとを渡す（Ｓ８０９）。ＵＲＬとＨＴＴＰレスポンスとを受けると、検証部５０９は検証処理を行う（Ｓ８１１）。具体的には、検証部５０９は、ＨＴＴＰレスポンスに付されている署名データを検証する。署名データの検証に成功した場合には、Ｗｅｂアプリケーションは真正であると判断される。署名データの検証に失敗した場合には、Ｗｅｂアプリケーションは不正であると判断される。

また、検証部５０９は、ＳＳＬ（Secure Socket Layer）通信の開始時にＷｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーションサーバ３０１の認証に成功した場合には、Ｗｅｂアプリケーションサーバ３０１は真正であり、Ｗｅｂアプリケーションサーバ３０１の認証に失敗した場合には、Ｗｅｂアプリケーションサーバ３０１は不正であると判断される。

検証部５０９は、抽出部（プロキシ型）５０７ａへ検証結果を返す（Ｓ８１３）。検証結果が失敗である場合には、抽出部（プロキシ型）５０７ａは処理を中断する。

検証結果が成功である場合には、抽出部（プロキシ型）５０７ａは、Ｗｅｂアプリケーション登録部５１１にＷｅｂアプリケーションサーバ３０１のＵＲＬを渡す（Ｓ８１５）。Ｗｅｂアプリケーションサーバ３０１のＵＲＬを受けると、Ｗｅｂアプリケーション登録部５１１は、Ｗｅｂアプリケーション登録処理を行う（Ｓ８１７）。具体的には、Ｗｅｂアプリケーション登録部５１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部４１１に記憶されているＷｅｂアプリケーションリストに加える。

そして、抽出部（プロキシ型）５０７ａは、Ｗｅｂブラウザ４０５へＨＴＴＰレスポンスを渡す（Ｓ８１９）。

図９に、続きのシーケンスの例を示す。ＨＴＴＰレスポンスを受けると、Ｗｅｂブラウザ４０５は、ＨＴＭＬ５のデータに対する構文解析や表示等の処理を行う。このとき、Ｗｅｂブラウザ４０５は、ＨＴＭＬ５のデータ中のスクリプトを検出部（エンジン監視型）５１３ａに渡す（Ｓ９０１）。

スクリプトが前述のＡＰＩ群のうちのいずれかのＡＰＩの機能に関する記述を含む場合には、検出部（エンジン監視型）５１３ａは、判定部５１７に当該ＡＰＩについての利用可否の判定を求める。そのため、検出部（エンジン監視型）５１３ａは、判定部５１７に判定リクエスト（ＡＰＩ種別を含む。）を渡す（Ｓ９０３）。

判定リクエストを受けると、判定部５１７は、コンテキスト生成部５１５にコンテキストを生成するリクエストを渡す（Ｓ９０５）。

コンテキストを生成するリクエストを受けると、コンテキスト生成部５１５は、コンテキスト生成処理を行う（Ｓ９０７）。コンテキスト生成部５１５は、ネットワークアドレスの情報を用いる場合に、記憶部４１１からネットワークアドレスを読み出す。また、コンテキスト生成部５１５は、動作しているＷｅｂアプリケーションの情報を用いる場合に、記憶部４１１からＷｅｂアプリケーションリストを読み出す。更に、コンテキスト生成部５１５は、ＡＰＩから取得する情報（例えば、位置情報や時間情報）を用いる場合に、ＡＰＩ４３１を呼び出し（Ｓ９０９）、ＡＰＩ４３１から戻り値（以下、ＡＰＩ戻り値という。）を得る（Ｓ９１３）。そして、コンテキスト生成部５１５は、収集した情報と生成ルールとに基づいてコンテキストを生成する。

生成されたコンテキストは、コンテキスト生成部５１５から判定部５１７に返される（Ｓ９１５）。

コンテキストを受けると、判定部５１７は、利用可否判定処理を行う（Ｓ９１７）。具体的には、判定部５１７は、コンテキストと判定ルールとに基づいて、当該ＡＰＩの利用可否を判定する。そして、判定部５１７は、検出部（エンジン監視型）５１３ａに判定結果を返す（Ｓ９１９）。

図１０に、判定結果が成功である場合のシーケンスの例を示す。検出部（エンジン監視型）５１３ａが成功の判定結果（Ｓ１００１）を受けた場合には、検出部（エンジン監視型）５１３ａは、スクリプトをスクリプトエンジン４５１に渡す（Ｓ１００３）。スクリプトエンジン４５１はＷｅｂブラウザ４０５に含まれるが、便宜的にＷｅｂブラウザ４０５と分けて説明している。

スクリプトエンジン４５１は、当該機能に係るＡＰＩ４３１を呼び出す（Ｓ１００５）。そして、ＡＰＩ４３１は、スクリプトエンジン４５１にＡＰＩ戻り値を返す（Ｓ１００７）。スクリプトエンジン４５１は、検出部（エンジン監視型）５１３ａに処理を戻す（Ｓ１００９）。更に、検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５に処理を戻す（Ｓ１０１１）。それぞれの処理の復帰において、ＡＰＩ戻り値が返されるようにしてもよい。

図１１に、判定結果が失敗である場合のシーケンスの例を示す。検出部（エンジン監視型）５１３ａが失敗の判定結果（Ｓ１１０１）を受けた場合には、検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５にＡＰＩ利用不可の通知を渡す（Ｓ１１０３）。以上でシーケンスについての説明を終える。

続いて、処理の詳細について説明する。まず、検出部（エンジン監視型）５１３ａの処理について説明する。図１２に、検出処理（エンジン監視型）フローの例を示す。検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５からスクリプトを受ける（Ｓ１２０１）。この処理は、図９のＳ９０１に示したステップに相当する。

検出部（エンジン監視型）５１３ａは、受け取ったスクリプトに前述のＡＰＩ群のうちのいずれかのＡＰＩの機能に関する記述が含まれているか否かを判定する（Ｓ１２０３）。スクリプトに前述のＡＰＩ群のいずれのＡＰＩの機能に関する記述も含まれていないと判定した場合には、検出部（エンジン監視型）５１３ａは、スクリプトをスクリプトエンジン４５１に渡す（Ｓ１２０５）。検出部（エンジン監視型）５１３ａは、スクリプトエンジン４５１におけるスクリプト処理の終了を待つ（Ｓ１２０７）。検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５へ処理を戻す（Ｓ１２０９）。

受け取ったスクリプトに前述のＡＰＩ群のうちのいずれかのＡＰＩの機能に関する記述が含まれていると判定した場合には、検出部（エンジン監視型）５１３ａは、判定部５１７に判定リクエストを渡す（Ｓ１２１１）。このとき、判定リクエストに当該ＡＰＩの種別を含める。この処理は、図９のＳ９０３に示したステップに相当する。

検出部（エンジン監視型）５１３ａは、判定部５１７から判定結果を受ける（Ｓ１２１３）。図９のＳ９１９に示したステップに相当する。

そして、検出部（エンジン監視型）５１３ａは、判定結果が成功であるか、あるいは失敗であるかを判定する（Ｓ１２１５）。判定結果が成功であると判定した場合には、検出部（エンジン監視型）５１３ａは、スクリプトエンジン４５１へスクリプトを渡す（Ｓ１２１７）。この処理は、図１０のＳ１００３に示したステップに相当する。

そして、検出部（エンジン監視型）５１３ａは、スクリプトエンジン４５１におけるスクリプト処理の終了を待つ（Ｓ１２１９）。図１０のＳ１００９に示したステップに相当する。

スクリプトエンジン４５１におけるスクリプト処理が終了すると、検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５へ処理を戻す（Ｓ１２２１）。検出部（エンジン監視型）５１３ａは、ＡＰＩ戻り値を返すようにしてもよい。図１０のＳ１０１１に示したステップに相当する。

Ｓ１２１５において判定結果が失敗であると判定した場合には、検出部（エンジン監視型）５１３ａは、Ｗｅｂブラウザ４０５へＡＰＩ利用不可の通知を渡す（Ｓ１２２３）。図１１のＳ１１０３に示したステップに相当する。以上で、検出部５１３の処理についての説明を終える。

次に、判定部５１７の処理について説明する。図１３に、判定処理フローの例を示す。判定部５１７は、判定リクエストを待つ（Ｓ１３０１）。判定リクエストには、判定対象となるＡＰＩ種別が含まれている。判定リクエストを受けると、判定部５１７は、呼び出し元のＷｅｂアプリケーションを特定する（Ｓ１３０３）。判定部５１７は、例えば、抽出部（プロキシ型）５０７ａからＷｅｂアプリケーションサーバ３０１のＵＲＬを取得し、当該ＵＲＬによって呼び出し元のＷｅｂアプリケーションを特定する。あるいは、判定部５１７は、記憶部４１１に記憶されているＷｅｂアプリケーションリストに登録されているＷｅｂアプリケーションサーバ３０１のＵＲＬによって判定対象のＷｅｂアプリケーションを特定する。ＷｅｂアプリケーションリストにＷｅｂアプリケーションサーバ３０１のＵＲＬが複数含まれている場合には、判定部５１７は、最も遅く登録されたＷｅｂアプリケーションサーバ３０１のＵＲＬによって呼び出し元のＷｅｂアプリケーションを特定するようにしてもよい。

判定部５１７は、コンテキストを生成するリクエストを渡す（Ｓ１３０５）。この処理は、図９のＳ９０５に示したステップに相当する。

そして、判定部５１７は、生成されたコンテキストを受ける（Ｓ１３０７）。この処理は、図９のＳ９１５に示したステップに相当する。

判定部５１７は、判定ルールテーブルから、生成されたコンテキストに適合し、更に呼び出し元のＷｅｂアプリケーションにも適合するレコードを特定する（Ｓ１３０９）。判定部５１７は、当該レコードにおいて判定対象のＡＰＩ種別に対応する利用可否を読む（Ｓ１３１１）。Ｓ１３０９とＳ１３１１とは、図９のＳ９１７に示した利用可否判定処理に相当する。

判定部５１７は、検出部（エンジン監視型）５１３ａに判定結果を返す（Ｓ１３１３）。図９のＳ９１９に示したステップに相当する。以上で、判定部５１７の処理についての説明を終える。

次に、コンテキスト生成部５１５の処理について説明する。図１４に、コンテキスト生成処理フローの例を示す。コンテキスト生成部５１５は、コンテキストを生成するリクエストを待つ（Ｓ１４０１）。コンテキストを生成するリクエストを受けると、コンテキスト生成部５１５は、格納部４０９に格納されている生成ルールテーブルのうち、未処理のレコードを１つ特定する（Ｓ１４０３）。コンテキスト生成部５１５は、例えば順次レコードを特定する。

コンテキスト生成部５１５は、未処理の条件のフィールドを１つ特定する。コンテキスト生成部５１５は、例えば順次条件のフィールドを特定する（Ｓ１４０５）。コンテキスト生成部５１５は、当該条件のフィールドに条件があるか否かを判定する（Ｓ１４０７）。当該条件のフィールドに条件がないと判定した場合には、当該条件のフィールドについての判定を行わずに、Ｓ１４１３の処理に移る。

当該条件のフィールドに条件があると判定した場合には、コンテキスト生成部５１５は、当該条件の対象データを取得する（Ｓ１４０９）。時刻条件であれば、時計機能に係るＡＰＩ４３１ｆから現在時刻を取得する。位置条件であれば、ＡＰＩ４３１ａから位置情報を取得する。ネットワーク条件であれば、記憶部４１１からネットワークアドレスを読み取る。Ｗｅｂアプリケーション条件であれば、記憶部４１１のＷｅｂアプリケーションリストから動作している他のＷｅｂアプリケーションのＵＲＬを読み取る。そして、コンテキスト生成部５１５は、対象データが条件に合致するか否かを判定する（Ｓ１４１１）。

対象データが条件に合致すると判定した場合には、コンテキスト生成部５１５は、未処理の条件フィールドがあるか否かを判定する（Ｓ１４１３）。未処理の条件フィールドがあると判定した場合には、Ｓ１４０５の処理に戻る。未処理の条件フィールドがないと判定した場合には、合致しない条件が無いので、コンテキスト生成部５１５は、当該レコードのコンテキストを特定する（Ｓ１４１５）。

一方、Ｓ１４１１で対象データが条件に合致しないと判定した場合には、コンテキストを生成しない。

コンテキスト生成部５１５は、未処理のレコードがあるか否かを判定する（Ｓ１４１７）。未処理のレコードがあると判定した場合には、Ｓ１４０３の処理に戻る。

未処理のレコードがないと判定した場合には、コンテキスト生成部５１５は、Ｓ１４１５で特定したコンテキストを判定部５１７に返す（Ｓ１４１９）。この処理は、図９のＳ９１５に示したステップに相当する。

そして、Ｓ１４０１に戻り、次の生成リクエストを待つ。以上で、コンテキスト生成部５１５の処理についての説明を終える。

本実施の形態によれば、Ｗｅｂアプリケーションによる特定機能の利用を、自動的に制限できる。例えば、利用者端末１００で計測された情報（位置情報や時刻情報など）や秘密に符号処理された情報（暗号化されたデータ、復号されたデータ、署名データなど）が不正使用されることを防ぐことができる。

また、Ｗｅｂアプリケーション又はＷｅｂアプリケーションを提供するサービスに応じて、Ｗｅｂアプリケーションによる特定機能の利用を制限できる。

また、ネットワークとの接続状況に応じて、Ｗｅｂアプリケーションによる特定機能の利用を制限できる。

また、他のＷｅｂアプリケーションの動作状況に応じて、Ｗｅｂアプリケーションによる特定機能の利用を制限できる。

本実施の形態によれば、スクリプトエンジン４５１を監視するので、オペレーティングシステム４０１に依存しない。

［実施の形態２］
実施の形態１で説明した抽出部（プロキシ型）５０７ａに代えて、抽出部（ＡＰＩ監視型）５０７ｂを用いる例を説明する。また、実施の形態１で説明した検出部（エンジン監視型）５１３ａに代えて、検出部（ＡＰＩ監視型）５１３ｂを用いる例についても併せて説明する。

抽出部（ＡＰＩ監視型）５０７ｂは、通信機能に係るＡＰＩ４３１ｃの呼び出しをフックすることによって、通信状況を監視し、通信に係る情報（接続先ネットワークのＵＲＬやＷｅｂアプリケーションを提供するサービスのＵＲＬなど）を抽出する。

また、検出部（ＡＰＩ監視型）５１３ｂは、各機能に係るＡＰＩの呼び出しをフックすることによって、ＡＰＩ４３１の呼び出しの発生を検出する。

図１５乃至１８に基づいて、実施の形態２に係るシーケンスについて説明する。まず、図１５のシーケンスの例について説明する。この例では、ソケットを用いた通信を想定する。この図では、ソケットを用いた通信のシーケンスの一部を示している。例えば、Ｗｅｂブラウザ４０５によるソケットオープンを抽出部（ＡＰＩ監視型）５０７ｂでフックし（Ｓ１５０１）、ソケットオープンを通信機能に係るＡＰＩ４３１ｃに渡す（Ｓ１５０３）。データの送信も、抽出部（ＡＰＩ監視型）５０７ｂを介する（Ｓ１５０５，Ｓ１５０７）。

そして、通信機能に係るＡＰＩ４３１ｃからＷｅｂアプリケーションサーバ３０１へＨＴＴＰリクエストが送出される（Ｓ１５０９）。Ｗｅｂアプリケーションサーバ３０１から返されたＨＴＴＰレスポンスは、通信機能に係るＡＰＩ４３１ｃから抽出部（ＡＰＩ監視型）５０７ｂに渡される（Ｓ１５１１、Ｓ１５１３）。

ＨＴＴＰレスポンスに相当するデータを受信すると、抽出部（ＡＰＩ監視型）５０７ｂは、ネットワークアドレスを抽出する処理を行う（Ｓ１５１５）。具体的には、抽出部（ＡＰＩ監視型）５０７ｂは、接続先ネットワークのＵＲＬを特定する。このとき、接続先ネットワークのＵＲＬは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬと一致する。抽出した接続先ネットワークのＵＲＬは、前述の通り記憶部４１１に記憶される。この例では、Ｗｅｂアプリケーションサーバ３０１へのアクセスの例を示したが、他の装置にアクセスする場合にも、抽出部（ＡＰＩ監視型）５０７ｂは、ネットワークアドレスを抽出するようにしてもよい。

抽出部（ＡＰＩ監視型）５０７ｂは、検証部５０９に、Ｗｅｂアプリケーションサーバ３０１のＵＲＬとＨＴＴＰレスポンスとを渡す（Ｓ１５１７）。ＵＲＬとＨＴＴＰレスポンスとを受けると、検証部５０９は検証処理を行う（Ｓ１５１９）。具体的には、検証部５０９は、ＨＴＴＰレスポンスに付されている署名データを検証する。署名データの検証に成功した場合には、Ｗｅｂアプリケーションは真正であると判断される。署名データの検証に失敗した場合には、Ｗｅｂアプリケーションは不正であると判断される。

また、検証部５０９は、ＳＳＬ通信の開始時にＷｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーションサーバ３０１の認証に成功した場合には、Ｗｅｂアプリケーションサーバ３０１は真正であり、Ｗｅｂアプリケーションサーバ３０１の認証に失敗した場合には、Ｗｅｂアプリケーションサーバ３０１は不正であると判断される。

検証部５０９は、抽出部（ＡＰＩ監視型）５０７ｂへ検証結果を返す（Ｓ１５２１）。検証結果が失敗である場合には、抽出部（ＡＰＩ監視型）５０７ｂは処理を中断する。

検証結果が成功である場合には、抽出部（ＡＰＩ監視型）５０７ｂは、Ｗｅｂアプリケーション登録部５１１にＷｅｂアプリケーションサーバ３０１のＵＲＬを渡す（Ｓ１５２３）。Ｗｅｂアプリケーションサーバ３０１のＵＲＬを受けると、Ｗｅｂアプリケーション登録部５１１は、Ｗｅｂアプリケーション登録処理を行う（Ｓ１５２５）。具体的には、Ｗｅｂアプリケーション登録部５１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部４１１に記憶されているＷｅｂアプリケーションリストに加える。

そして、抽出部（ＡＰＩ監視型）５０７ｂは、Ｗｅｂブラウザ４０５へＨＴＴＰレスポンスを渡す（Ｓ１５２７）。

図１６に、続きのシーケンスの例を示す。Ｗｅｂブラウザ４０５からＡＰＩが呼び出されると、検出部（ＡＰＩ監視型）５１３ｂは当該ＡＰＩ呼び出しをフックする（Ｓ１６０１）。フックする箇所によって、呼び出されるＡＰＩの種別は特定される。

ＡＰＩ呼び出しをフックすると、検出部（ＡＰＩ監視型）５１３ｂは、判定部５１７に当該ＡＰＩについての利用可否の判定を求める。そのため、検出部（ＡＰＩ監視型）５１３ｂは、判定部５１７に判定リクエスト（ＡＰＩ種別を含む。）を渡す（Ｓ１６０３）。

判定リクエストを受けると、判定部５１７は、コンテキスト生成部５１５にコンテキストを生成するリクエストを渡す（Ｓ１６０５）。

コンテキストを生成するリクエストを受けると、コンテキスト生成部５１５は、コンテキスト生成処理を行う（Ｓ１６０７）。コンテキスト生成部５１５は、ネットワークアドレスの情報を用いる場合に、記憶部４１１からネットワークアドレスを読み出す。コンテキスト生成部５１５は、動作しているＷｅｂアプリケーションの情報を用いる場合に、記憶部４１１からＷｅｂアプリケーションリストを読み出す。コンテキスト生成部５１５は、ＡＰＩから取得する情報（例えば、位置情報や時間情報）を用いる場合に、ＡＰＩ４３１を呼び出し（Ｓ１６０９）、ＡＰＩ戻り値を得る（Ｓ１６１３）。そして、コンテキスト生成部５１５は、収集した情報と生成ルールとに基づいてコンテキストを生成する。

生成されたコンテキストは、コンテキスト生成部５１５から判定部５１７に返される（Ｓ１６１５）。

コンテキストを受けると、判定部５１７は、利用可否判定処理を行う（Ｓ１６１７）。具体的には、判定部５１７は、コンテキストと判定ルールに基づいて、当該ＡＰＩの利用可否を判定する。そして、判定部５１７は、検出部（ＡＰＩ監視型）５１３ｂに判定結果を返す（Ｓ１６１９）。

図１７に、判定結果が成功である場合のシーケンスの例を示す。検出部（ＡＰＩ監視型）５１３ｂが成功の判定結果（Ｓ１７０１）を受けた場合には、検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ４３１を呼び出す（Ｓ１７０３）。検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ４３１から戻り値を受けると（Ｓ１７０５）、Ｗｅｂブラウザ４０５にその戻り値を渡す（Ｓ１７０７）。

図１８に、判定結果が失敗である場合のシーケンスの例を示す。検出部（ＡＰＩ監視型）５１３ｂが失敗の判定結果（Ｓ１８０１）を受けた場合には、検出部（ＡＰＩ監視型）５１３ｂは、Ｗｅｂブラウザ４０５にＡＰＩ利用不可の通知を渡す（Ｓ１８０３）。以上でシーケンスについての説明を終える。

続いて、処理の詳細について説明する。まず、検出部（ＡＰＩ監視型）５１３ｂの処理について説明する。図１９に、検出処理（ＡＰＩ監視型）フローの例を示す。検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ呼び出しをフックする（Ｓ１９０１）。図１６のＳ１６０１に示したステップに相当する。このとき、検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩの種別も特定する。

検出部（ＡＰＩ監視型）５１３ｂは、判定部５１７に判定リクエストを渡す（Ｓ１９０３）。このとき、判定リクエストに当該ＡＰＩの種別を含める。図１６のＳ１６０３に示したステップに相当する。

検出部（ＡＰＩ監視型）５１３ｂは、判定部５１７から判定結果を受ける（Ｓ１９０５）。図１６のＳ１６１９に示したステップに相当する。

そして、検出部（エンジン監視型）５１３ａは、判定結果が成功であるか、あるいは失敗であるかを判定する（Ｓ１９０７）。判定結果が成功であると判定した場合には、検出部（ＡＰＩ監視型）５１３ｂは、種別に応じてＡＰＩ４３１を呼び出す（Ｓ１９０９）。図１７のＳ１７０３に示したステップに相当する。

そして、検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ４３１から戻り値を受ける（Ｓ１９１１）。図１７のＳ１７０５に示したステップに相当する。

検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ戻り値をＷｅｂブラウザ４０５に返す（Ｓ１９１３）。図１７のＳ１７０７に示したステップに相当する。

Ｓ１９０７において判定結果が失敗であると判定した場合には、検出部（ＡＰＩ監視型）５１３ｂは、ＡＰＩ利用不可の通知を渡す（Ｓ１９１５）。図１８のＳ１８０３に示したステップに相当する。以上で、検出部（ＡＰＩ監視型）５１３ｂの処理についての説明を終える。

抽出部（プロキシ型）５０７ａと検出部（ＡＰＩ監視型）５１３ｂとを組み合わせる形態としてもよい。また、抽出部（ＡＰＩ監視型）５０７ｂと検出部（エンジン監視型）５１３ａとを組み合わせる形態としてもよい。

本実施の形態によれば、ＡＰＩ呼び出しをフックするので、Ｗｅｂブラウザ４０５に依存しない。更に、プロセス単位で通信を監視することができる。

［実施の形態３］
上述の実施の形態では、Ｗｅｂブラウザを有する利用者端末１００内でＡＰＩ４３１の利用を制限する処理を行う例について説明したが、本実施の形態では、Ｗｅｂブラウザを有する利用者端末１００とは別に設けた中継装置２００においてＡＰＩの利用を制限する例について説明する。

図２０に、実施の形態３に係る機能制限システムの構成例を示す。中継装置２００は、インターネットに接続する機能を有している。そして、中継装置２００は、Ｗｅｂアプリケーションサーバ３０１ａ乃至ｃ、利用者端末１００及び社内サーバ３０５とインターネットを介して通信する。尚、中継装置２００と利用者端末１００との間は、近距離無線通信や無線ＬＡＮなどの他の通信媒体によって接続されるようにしてもよい。

中継装置２００は、利用者端末１００とＷｅｂアプリケーションサーバ３０１ａ乃至ｃとの間の通信を中継する。また、中継装置２００は、利用者端末１００にＡＰＩの機能を提供する。そして、利用者端末１００にＡＰＩの機能を提供する前に、コンテキストを生成し、ＡＰＩの利用可否判定を行い、利用可と判定されたＡＰＩの機能を提供するように動作する。

図２１に、中継装置２００のモジュール構成例を示す。中継装置２００は、オペレーティングシステム（ＯＳ）２１０１、制限部２１０７、格納部２１０９、記憶部２１１１、送信部２１１３、受信部２１１５、表示部２１１７及び受付部２１１９を有している。

オペレーティングシステム２１０１は、ＡＰＩ群を備えるフレームワーク２１０３を有している。この例で、ＡＰＩ群には、ＧＰＳ機能に係るＡＰＩ２１３１ａ、署名機能に係るＡＰＩ２１３１ｂ、通信機能に係るＡＰＩ２１３１ｃ、復号機能に係るＡＰＩ２１３１ｄ及び時計機能に係るＡＰＩ２１３１ｆが含まれている。但し、他の機能に係るＡＰＩを設けるようにしてもよい。

図２２を用いて、格納部２１０９と制限部２１０７と記憶部２１１１との詳細について説明する。格納部２１０９は、この例では生成ルールテーブル、判定ルールテーブル及び検証データを格納する。

制限部２１０７は、生成ルール設定部２２０１、判定ルール設定部２２０３、検証データ登録部２２０５、抽出部（プロキシ型）２２０７ａ、検証部２２０９、Ｗｅｂアプリケーション登録部２２１１、コンテキスト生成部２２１５、判定部２２１７及び中継部２２１９を有している。

生成ルール設定部２２０１は、上述した生成ルールテーブルを格納部２１０９に格納させる。生成ルール設定部２２０１は、例えば、表示部２１１７に生成ルールの入力画面を表示させ、生成ルール入力画面に対する入力の操作を受付部２１１９で受け付けることによって、利用者に生成ルールを設定させる。あるいは、生成ルール設定部２２０１は、インターネットを介して、生成ルールテーブルを配信する装置（例えば、社内サーバ３０５）から生成ルールテーブルをダウンロードするようにしてもよい。利用者は、例えば準備段階で生成ルール設定部２２０１を起動し、生成ルールテーブルを用意する。

判定ルール設定部２２０３は、上述した判定ルールを格納部２１０９に格納させる。判定ルール設定部２２０３は、例えば、表示部２１１７に判定ルールの入力画面を表示させ、判定ルール入力画面に対する入力の操作を受付部２１１９で受け付けることによって、利用者に判定ルールを設定させる。あるいは、判定ルール設定部２２０３は、インターネットを介して、判定ルールテーブルを配信する装置（例えば、社内サーバ３０５）から判定ルールテーブルをダウンロードするようにしてもよい。利用者は、例えば準備段階で判定ルール設定部２２０３を起動し、判定ルールテーブルを用意する。

検証データ登録部２２０５は、検証データを所定の機関（例えば認証局）から取得し、格納部２１０９に格納させる。利用者は、例えば準備段階で検証データ登録部２２０５を起動し、検証データを用意する。

抽出部（プロキシ型）２２０７ａは、通信状況を監視し、通信に係る情報（接続先ネットワークのＵＲＬやＷｅｂアプリケーションを提供するサービスのＵＲＬなど）を抽出する。また、抽出部（プロキシ型）２２０７ａは、接続先のネットワークのＵＲＬを記憶部２１１１に記憶させる。

検証部２２０９は、Ｗｅｂアプリケーションサーバ３０１からダウンロードされるＷｅｂアプリケーションを検証する。例えば、ＷｅｂアプリケーションがＨＴＭＬ５ファイル形式である場合、検証部２２０９は、ダウンロードされるＨＴＭＬ５ファイルに相当するＨＴＴＰレスポンスの署名を検証する。検証部２２０９は、Ｗｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーション登録部２２１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部２１１１に記憶させる。

コンテキスト生成部２２１５は、コンテキストを生成する。判定部２２１７は、コンテキストに基づき、ＡＰＩの利用可否の判定を行う。

中継部２２１９は、利用者端末１００からのＡＰＩ利用を中継する。

記憶部２１１１は、例えば、ネットワークアドレスとＷｅｂアプリケーションリストとを記憶する。ネットワークアドレスは、接続先ネットワークのＵＲＬである。Ｗｅｂアプリケーションリストは、利用者端末１００で動作しているＷｅｂアプリケーションを提供したサービスのＵＲＬのリストである。動作を終えたＷｅｂアプリケーションについても、当該ＵＲＬが残されるようにしてもよい。

図２３に、実施の形態３に係る利用者端末のモジュール構成例を示す。利用者端末１００は、検出部（エンジン監視型）２３０１ａを有している。検出部（エンジン監視型）２３０１ａは、スクリプトエンジン４５１を監視する。

図２４に、実施の形態３に係るシーケンスの例を示す。利用者端末１００のＷｅｂブラウザ４０５から送出されるＨＴＴＰリクエストは、利用者端末１００のＷｅｂブラウザ４０５におけるプロキシの設定に従って、中継装置２００の抽出部（プロキシ型）２２０７ａに送られる（Ｓ２４０１）。このＨＴＴＰリクエストは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬへのアクセス要求に相当する。そして、中継装置２００の抽出部（プロキシ型）２２０７ａは、ＨＴＴＰリクエストをＷｅｂアプリケーションサーバ３０１に転送する（Ｓ２４０３）。

ＨＴＴＰリクエストに対するＨＴＴＰレスポンスは、Ｗｅｂアプリケーションサーバ３０１から中継装置２００の抽出部（プロキシ型）２２０７ａへ返される（Ｓ２４０５）。ＨＴＴＰレスポンスは、例えばＨＴＭＬ５ファイルに相当する。

監視していたＨＴＴＰリクエストとＨＴＴＰレスポンスとに基づいて、中継装置２００の抽出部（プロキシ型）２２０７ａは、ネットワークアドレスを抽出する処理を行う（Ｓ２４０７）。具体的には、中継装置２００の抽出部（プロキシ型）２２０７ａは、接続先ネットワークのＵＲＬを特定する。このとき、接続先ネットワークのＵＲＬは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬと一致する。抽出した接続先ネットワークのＵＲＬは、前述の通り記憶部２１１１に記憶される。この例では、Ｗｅｂアプリケーションサーバ３０１へのアクセスの例を示したが、他の装置にアクセスする場合にも、中継装置２００の抽出部（プロキシ型）２２０７ａは、ネットワークアドレスを抽出するようにしてもよい。

中継装置２００の抽出部（プロキシ型）２２０７ａは、中継装置２００の検証部２２０９に、Ｗｅｂアプリケーションサーバ３０１のＵＲＬとＨＴＴＰレスポンスとを渡す（Ｓ２４０９）。ＵＲＬとＨＴＴＰレスポンスと受けると、中継装置２００の検証部２２０９は検証処理を行う（Ｓ２４１１）。具体的には、中継装置２００の検証部２２０９は、ＨＴＴＰレスポンスに付されている署名データを検証する。署名データの検証に成功した場合には、Ｗｅｂアプリケーションは真正であると判断される。署名データの検証に失敗した場合には、Ｗｅｂアプリケーションは不正であると判断される。

また、中継装置２００の検証部２２０９は、ＳＳＬ通信の開始時にＷｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーションサーバ３０１の認証に成功した場合には、Ｗｅｂアプリケーションサーバ３０１は真正であり、Ｗｅｂアプリケーションサーバ３０１の認証に失敗した場合には、Ｗｅｂアプリケーションサーバ３０１は不正であると判断される。

中継装置２００の検証部２２０９は、中継装置２００の抽出部（プロキシ型）２２０７ａへ検証結果を返す（Ｓ２４１３）。検証結果が失敗である場合には、中継装置２００の抽出部（プロキシ型）２２０７ａは処理を中断する。

検証結果が成功である場合には、中継装置２００の抽出部（プロキシ型）２２０７ａは、中継装置２００のＷｅｂアプリケーション登録部２２１１にＷｅｂアプリケーションサーバ３０１のＵＲＬを渡す（Ｓ２４１５）。Ｗｅｂアプリケーションサーバ３０１のＵＲＬを受けると、中継装置２００のＷｅｂアプリケーション登録部２２１１は、Ｗｅｂアプリケーション登録処理を行う（Ｓ２４１７）。具体的には、中継装置２００のＷｅｂアプリケーション登録部２２１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部２１１１に記憶されているＷｅｂアプリケーションリストに加える。

そして、中継装置２００の抽出部（プロキシ型）２２０７ａは、利用者端末１００のＷｅｂブラウザ４０５へＨＴＴＰレスポンスを渡す（Ｓ２４１９）。

図２５に、続きのシーケンスの例を示す。利用者端末１００の検出部（エンジン監視型）２３０１ａは、利用者端末１００のＷｅｂブラウザ４０５から受けたスクリプトに前述のＡＰＩ群のうちのいずれかのＡＰＩの機能に関する記述が含まれている場合に、中継装置２００の中継部２２１９に当該ＡＰＩの利用を求める。そのため、利用者端末１００の検出部（エンジン監視型）２３０１ａは、インターネットを介して中継装置２００の中継部２２１９にＡＰＩ利用リクエストを送る（Ｓ２５０１）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

中継装置２００の中継部２２１９は、中継装置２００の判定部２２１７に判定リクエスト（ＡＰＩ種別を含む。）を渡す（Ｓ２５０３）。

判定リクエストを受けると、中継装置２００の判定部２２１７は、中継装置２００のコンテキスト生成部２２１５にコンテキストを生成するリクエストを渡す（Ｓ２５０５）。

コンテキストを生成するリクエストを受けると、中継装置２００のコンテキスト生成部２２１５は、コンテキスト生成処理を行う（Ｓ２５０７）。中継装置２００のコンテキスト生成部２２１５は、ネットワークアドレスの情報を用いる場合に、記憶部２１１１からネットワークアドレスを読み出す。また、中継装置２００のコンテキスト生成部２２１５は、動作しているＷｅｂアプリケーションの情報を用いる場合に、記憶部２１１１からＷｅｂアプリケーションリストを読み出す。更に、中継装置２００のコンテキスト生成部２２１５は、ＡＰＩから取得する情報（例えば、位置情報や時間情報）を用いる場合に、中継装置２００のＡＰＩ２１３１を呼び出し（Ｓ２５０９）、中継装置２００のＡＰＩ２１３１から戻り値を得る（Ｓ２５１３）。そして、中継装置２００のコンテキスト生成部２２１５は、収集した情報と生成ルールとに基づいてコンテキストを生成する。

生成されたコンテキストは、中継装置２００のコンテキスト生成部２２１５から中継装置２００の判定部２２１７に返される（Ｓ２５１５）。

コンテキストを受けると、中継装置２００の判定部２２１７は、利用可否判定処理を行う（Ｓ２５１７）。具体的には、中継装置２００の判定部２２１７は、コンテキストと判定ルールとに基づいて、当該ＡＰＩの利用可否を判定する。そして、中継装置２００の判定部２２１７は、中継装置２００の中継部２２１９に判定結果を返す（Ｓ２５１９）。

図２６に、判定結果が成功である場合のシーケンスの例を示す。中継装置２００の中継部２２１９が成功の判定結果（Ｓ２６０１）を受けた場合には、中継装置２００の中継部２２１９は、中継装置２００における当該機能に係るＡＰＩ２１３１を呼び出す（Ｓ２６０３）。そして、中継装置２００のＡＰＩ２１３１は、中継装置２００の中継部２２１９にＡＰＩ戻り値を返す（Ｓ２６０５）。そして、中継装置２００の中継部２２１９は、インターネットを介して利用者端末１００の検出部（エンジン監視型）２３０１ａにＡＰＩ利用結果を送る（Ｓ２６０７）。ＡＰＩ利用結果は、ＡＰＩ戻り値を含んでいる。利用者端末１００側は、ＡＰＩ戻り値を用いて処理を続行する。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

図２７に、判定結果が失敗である場合のシーケンスの例を示す。中継装置２００の中継部２２１９が失敗の判定結果（Ｓ２７０１）を受けた場合には、中継装置２００の中継部２２１９は、インターネットを介して利用者端末１００の検出部（エンジン監視型）２３０１ａにＡＰＩ利用不可の通知を送る（Ｓ２７０３）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

本実施の形態によれば、プログラムを実行する装置とは別の装置の状況に応じて、プログラムによる特定機能の利用を制限できる。

［実施の形態４］
利用者端末１００で監視するＡＰＩの呼び出しに基づいて、利用者端末１００と中継装置２００とが連携する形態について説明する。

図２８に、実施の形態４に係る格納部２１０９と制限部２１０７と記憶部２１１１の構成例を示す。図２２の抽出部（プロキシ型）２２０７ａに代えて、抽出部（ＡＰＩ監視型）２２０７ｂを有している。

図２９に、実施の形態４に係る利用者端末１００のモジュール構成例を示す。利用者端末１００は、図２３に示した検出部（エンジン監視型）２３０１ａに代えて、検出部（ＡＰＩ監視型）２３０１ｂを有している。更に、利用者端末１００は、転送部２９０１を有している。

図３０に、実施の形態４に係るシーケンスの例を示す。この例では、ソケットを用いた通信を想定する。この図では、ソケットを用いた通信のシーケンスの一部を示している。例えば、利用者端末１００のＷｅｂブラウザ４０５からのソケットオープンをフックした利用者端末１００の転送部２９０１は、インターネットを介してソケットオープンを中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂに送る（Ｓ３００１）。中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、ソケットオープンを中継装置２００における通信機能に係るＡＰＩ２１３１ｃに渡す（Ｓ３００３）。データ送信の場合も、利用者端末１００の転送部２９０１と中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂとを介して送られる（Ｓ３００５，Ｓ３００７）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

そして、中継装置２００における通信機能に係るＡＰＩ２１３１ｃからＷｅｂアプリケーションサーバ３０１へＨＴＴＰリクエストが送出される（Ｓ３００９）。Ｗｅｂアプリケーションサーバ３０１から返されたＨＴＴＰレスポンスは、中継装置２００における通信機能に係るＡＰＩ２１３１ｃから中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂに渡される（Ｓ３０１１、Ｓ３０１３）。

ＨＴＴＰレスポンスに相当するデータを受信すると、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、ネットワークアドレスを抽出する処理を行う（Ｓ３０１５）。具体的には、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、接続先ネットワークのＵＲＬを特定する。このとき、接続先ネットワークのＵＲＬは、Ｗｅｂアプリケーションサーバ３０１のＵＲＬと一致する。抽出した接続先ネットワークのＵＲＬは、前述の通り記憶部２１１１に記憶される。この例では、Ｗｅｂアプリケーションサーバ３０１へのアクセスの例を示したが、他の装置にアクセスする場合にも、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、ネットワークアドレスを抽出するようにしてもよい。

中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、中継装置２００の検証部２２０９に、Ｗｅｂアプリケーションサーバ３０１のＵＲＬとＨＴＴＰレスポンスとを渡す（Ｓ３０１７）。ＵＲＬとＨＴＴＰレスポンスとを受けると、中継装置２００の検証部２２０９は検証処理を行う（Ｓ３０１９）。具体的には、中継装置２００の検証部２２０９は、ＨＴＴＰレスポンスに付されている署名データを検証する。署名データの検証に成功した場合には、Ｗｅｂアプリケーションは真正であると判断される。署名データの検証に失敗した場合には、Ｗｅｂアプリケーションは不正であると判断される。

また、中継装置２００の検証部２２０９は、ＳＳＬ通信の開始時にＷｅｂアプリケーションサーバ３０１を認証するようにしてもよい。Ｗｅｂアプリケーションサーバ３０１の認証に成功した場合には、Ｗｅｂアプリケーションサーバ３０１は真正であり、Ｗｅｂアプリケーションサーバ３０１の認証に失敗した場合には、Ｗｅｂアプリケーションサーバ３０１は不正であると判断される。

中継装置２００の検証部２２０９は、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂへ検証結果を返す（Ｓ３０２１）。検証結果が失敗である場合には、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは処理を中断する。

検証結果が成功である場合には、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、中継装置２００のＷｅｂアプリケーション登録部２２１１にＷｅｂアプリケーションサーバ３０１のＵＲＬを渡す（Ｓ３０２３）。Ｗｅｂアプリケーションサーバ３０１のＵＲＬを受けると、中継装置２００のＷｅｂアプリケーション登録部２２１１は、Ｗｅｂアプリケーション登録処理を行う（Ｓ３０２５）。具体的には、中継装置２００のＷｅｂアプリケーション登録部２２１１は、Ｗｅｂアプリケーションサーバ３０１のＵＲＬを記憶部２１１１に記憶されているＷｅｂアプリケーションリストに加える。

そして、中継装置２００の抽出部（ＡＰＩ監視型）２２０７ｂは、インターネットを介して利用者端末１００の転送部２９０１へＨＴＴＰレスポンスに相当するデータを送信する（Ｓ３０２７）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

図３１に、続きのシーケンスの例を示す。利用者端末１００のＷｅｂブラウザ４０５からのＡＰＩ呼び出しをフックした利用者端末１００の検出部（ＡＰＩ監視型）２３０１ｂは、インターネットを介して中継装置２００の中継部２２１９にＡＰＩ利用のリクエストを送る（Ｓ３１０１）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。

中継装置２００の中継部２２１９は、中継装置２００の判定部２２１７に当該ＡＰＩについての利用可否の判定を求める。そのため、中継装置２００の中継部２２１９は、中継装置２００の判定部２２１７に判定リクエスト（ＡＰＩ種別を含む。）を渡す（Ｓ３１０３）。

判定リクエストを受けると、中継装置２００の判定部２２１７は、中継装置２００のコンテキスト生成部２２１５にコンテキストを生成するリクエストを渡す（Ｓ３１０５）。

コンテキストを生成するリクエストを受けると、中継装置２００のコンテキスト生成部２２１５は、コンテキスト生成処理を行う（Ｓ３１０７）。中継装置２００のコンテキスト生成部２２１５は、ネットワークアドレスの情報を用いる場合に、記憶部２１１１からネットワークアドレスを読み出す。中継装置２００のコンテキスト生成部２２１５は、動作しているＷｅｂアプリケーションの情報を用いる場合に、記憶部２１１１からＷｅｂアプリケーションリストを読み出す。中継装置２００のコンテキスト生成部２２１５は、ＡＰＩから取得する情報（例えば、位置情報や時間情報）を用いる場合に、中継装置２００のＡＰＩ２１３１を呼び出し（Ｓ３１０９）、ＡＰＩ戻り値を得る（Ｓ３１１３）。そして、中継装置２００のコンテキスト生成部２２１５は、収集した情報と生成ルールとに基づいてコンテキストを生成する。

生成されたコンテキストは、中継装置２００のコンテキスト生成部２２１５から中継装置２００の判定部２２１７に返される（Ｓ３１１５）。

コンテキストを受けると、中継装置２００の判定部２２１７は、利用可否判定処理を行う（Ｓ３１１７）。具体的には、中継装置２００の判定部２２１７は、コンテキストと判定ルールに基づいて、当該ＡＰＩの利用可否を判定する。そして、中継装置２００の判定部２２１７は、中継装置２００の中継部２２１９に判定結果を返す（Ｓ３１１９）。

図３２に、判定結果が成功である場合のシーケンスの例を示す。中継装置２００の中継部２２１９が成功の判定結果（Ｓ３２０１）を受けた場合には、中継装置２００の中継部２２１９は、中継装置２００のＡＰＩ２１３１を呼び出す（Ｓ３２０３）。中継装置２００の中継部２２１９は、中継装置２００のＡＰＩ２１３１から戻り値を受けると（Ｓ３２０５）、インターネットを介して利用者端末１００の検出部（ＡＰＩ監視型）２３０１ｂにＡＰＩ利用結果を送る（Ｓ３２０７）。ＡＰＩ利用結果には、ＡＰＩ戻り値が含まれる。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。利用者端末１００側は、ＡＰＩ戻り値を用いて処理を続行する。

図３３に、判定結果が失敗である場合のシーケンスの例を示す。中継装置２００の中継部２２１９が失敗の判定結果（Ｓ３３０１）を受けた場合には、中継装置２００の中継部２２１９は、インターネットを介して利用者端末１００の検出部（ＡＰＩ監視型）２３０１ｂにＡＰＩ利用不可の通知を送る（Ｓ３３０３）。このとき、インターネットに代えて、近距離無線通信や無線ＬＡＮなどの他の通信媒体が用いられるようにしてもよい。以上でシーケンスについての説明を終える。

本実施の形態によれば、プログラムを実行する装置とは別の装置の状況に応じて、プログラムによる特定機能の利用を制限できる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上述の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

利用者端末１００と中継装置２００とは、例えば携帯型情報処理装置である。図３４に、携帯型情報処理装置のハードウエア構成例を示す。携帯型情報処理装置は、ＲＡＭ（Random Access Memory）３４０３、スピーカ３４０５、ＬＣＤ（Liquid Crystal Display：液晶ディスプレイ）３４０７、タッチパネル３４０９、マイク３４１１、ＮＡＮＤ（Not AND）メモリ３４１３、通信ＣＰＵ（Central Processing Unit）３４１５、アプリＣＰＵ３４１７、近距離通信デバイス３４１９、ＧＰＳセンサー３４２１、無線ＬＡＮ（Local Area Network）デバイス３４２３、ＤＳＰ（Digital Signal Processor）３４２５、ＩＳＰ（Image Signal Processor）３４２７、カメラ３４２９、バス３４３１、サブプロセッサ３４３３、地磁気センサー３４３５、ジャイロセンサー３４３７及び加速度センサー３４３９を有している。そのうち、ＲＡＭ３４０３、スピーカ３４０５、ＬＣＤ３４０７、タッチパネル３４０９、マイク３４１１、ＮＡＮＤメモリ３４１３、通信ＣＰＵ３４１５、アプリＣＰＵ３４１７、近距離通信デバイス３４１９、ＧＰＳセンサー３４２１、無線ＬＡＮデバイス３４２３、ＤＳＰ３４２５、ＩＳＰ３４２７及びカメラ３４２９は、バス３４３１を介して接続されている。ＬＣＤ３４０７は、表示装置の例である。

ＲＡＭ３４０３は、例えばプログラムやデータを記憶する。スピーカ３４０５は、音声を出力する。ＬＣＤ３４０７は、画像や画面を表示する。タッチパネル３４０９は、接触状態と接触位置などを検出する。マイク３４１１は、音声を入力する。ＮＡＮＤメモリ３４１３は、不揮発性記憶素子のフラッシュメモリである。このＮＡＮＤメモリ３４１３は、例えばプログラムやデータを記憶する。通信ＣＰＵ３４１５は、通信処理に係る演算処理を行う。アプリＣＰＵ３４１７は、アプリケーションソフトを実行する演算装置である。近距離通信デバイス３４１９は、近距離通信を制御するデバイスである。ＧＰＳセンサー３４２１は、位置を測定する装置である。無線ＬＡＮデバイス３４２３は、無線ＬＡＮの通信を制御するデバイスである。ＤＳＰ３４２５は、デジタル信号処理を行うプロセッサである。ＩＳＰ３４２７は、画像処理を行うプロセッサである。カメラ３４２９は、撮影する装置である。また、アプリＣＰＵ３４１７は、サブプロセッサ３４３３と接続している。サブプロセッサ３４３３は、地磁気センサー３４３５、ジャイロセンサー３４３７、及び加速度センサー３４３９に接続している。サブプロセッサ３４３３は、地磁気センサー３４３５、ジャイロセンサー３４３７、及び加速度センサー３４３９を制御する。

この例では、アプリＣＰＵ３４１７は、サブプロセッサ３４３３を介して地磁気センサー３４３５、ジャイロセンサー３４３７、及び加速度センサー３４３９の計測結果を取得するが、アプリＣＰＵ３４１７は、直接に地磁気センサー３４３５、ジャイロセンサー３４３７、及び加速度センサー３４３９の計測結果を取得するようにしてもよい。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る情報処理装置は、プログラムの実行中に、特定機能に係る呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する生成部と、コンテキストに基づいて、呼び出しの許否を判定する判定部とを有する。

このようにすれば、プログラムによる特定機能の利用を、自動的に制限できる。

また、上記判定部は、更に、プログラム又はプログラムを提供するサービスに対応するルールに従って、呼び出しの許否を判定するようにしてもよい。

このようにすれば、プログラム又はプログラムを提供するサービスに応じて、プログラムによる特定機能の利用を制限できる。

また、上記自装置の状況は、情報処理装置におけるネットワークとの接続状況であってもよい。

このようにすれば、ネットワークとの接続状況に応じて、プログラムによる特定機能の利用を制限できる。

また、上記自装置の状況は、情報処理装置における他のプログラムの動作状況であってもよい。

このようにすれば、他のプログラムの動作状況に応じて、プログラムによる特定機能の利用を制限できる。

本実施の形態に係るシステムは、プログラムの実行中に、特定機能に係る呼び出しの発生を検出する検出部を有する第１の情報処理装置と、呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する生成部と、コンテキストに基づいて、呼び出しの許否を判定する判定部とを有する第２の情報処理装置とを含む。

このようにすれば、プログラムを実行する装置とは別の装置の状況に応じて、プログラムによる特定機能の利用を制限できる。

なお、上で述べた処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
プログラムの実行中に、特定機能に係る呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する生成部と、
前記コンテキストに基づいて、前記呼び出しの許否を判定する判定部と
を有する情報処理装置。

（付記２）
前記判定部は、更に、前記プログラム又は前記プログラムを提供するサービスに対応するルールに従って、前記呼び出しの許否を判定する
付記１記載の情報処理装置。

（付記３）
前記自装置の状況は、前記情報処理装置におけるネットワークとの接続状況である
付記１又は２記載の情報処理装置。

（付記４）
前記自装置の状況は、前記情報処理装置における他のプログラムの動作状況である
付記１乃至３のいずれか１つ記載の情報処理装置。

（付記５）
プログラムの実行中に、特定機能に係る呼び出しの発生を検出する検出部
を有する第１の情報処理装置と、
前記呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する生成部と、
前記コンテキストに基づいて、前記呼び出しの許否を判定する判定部と
を有する第２の情報処理装置と
を含むシステム。

（付記６）
プログラムの実行中に、特定機能に係る呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する処理と、
前記コンテキストに基づいて、前記呼び出しの許否を判定する処理と
を含む情報処理方法。

（付記７）
プログラムの実行中に、特定機能に係る呼び出しの発生を検出すると、自装置の状況に係るコンテキストを生成する処理と、
前記コンテキストに基づいて、前記呼び出しの許否を判定する処理と
をコンピュータに実行させるためのプログラム。

１００ 利用者端末 ２００ 中継装置
３０１ Ｗｅｂアプリケーションサーバ ３０３ ルータ
３０５ 社内サーバ ４０１ オペレーティングシステム
４０３ フレームワーク ４０５ Ｗｅｂブラウザ
４０７ 制限部 ４０９ 格納部
４１１ 記憶部 ４１３ 送信部
４１５ 受信部 ４１７ 表示部
４１９ 受付部 ４３１ ＡＰＩ
４３１ａ ＧＰＳ機能に係るＡＰＩ ４３１ｂ 署名機能に係るＡＰＩ
４３１ｃ 通信機能に係るＡＰＩ ４３１ｄ 復号機能に係るＡＰＩ
４３１ｅ アドレス帳機能に係るＡＰＩ ４３１ｆ 時計機能に係るＡＰＩ
４５１ スクリプトエンジン ４５３ プラグイン
５０１ 生成ルール設定部 ５０３ 判定ルール設定部
５０５ 検証データ登録部 ５０７ 抽出部
５０７ａ 抽出部（プロキシ型） ５０７ｂ 抽出部（ＡＰＩ監視型）
５０９ 検証部 ５１１ Ｗｅｂアプリケーション登録部
５１３ 検出部 ５１３ａ 検出部（エンジン監視型）
５１３ｂ 検出部（ＡＰＩ監視型） ５１５ コンテキスト生成部
５１７ 判定部 ２１０１ オペレーティングシステム
２１０３ フレームワーク ２１０７ 制限部
２１０９ 格納部 ２１１１ 記憶部
２１１３ 送信部 ２１１５ 受信部
２１１７ 表示部 ２１１９ 受付部
２１３１ ＡＰＩ ２１３１ａ ＧＰＳ機能に係るＡＰＩ
２１３１ｂ 署名機能に係るＡＰＩ ２１３１ｃ 通信機能に係るＡＰＩ
２１３１ｄ 復号機能に係るＡＰＩ ２１３１ｆ 時計機能に係るＡＰＩ
２２０１ 生成ルール設定部 ２２０３ 判定ルール設定部
２２０５ 検証データ登録部 ２２０７ 抽出部
２２０７ａ 抽出部（プロキシ型） ２２０７ｂ 抽出部（ＡＰＩ監視型）
２２０９ 検証部 ２２１１ Ｗｅｂアプリケーション登録部
２２１５ コンテキスト生成部 ２２１７ 判定部
２２１９ 中継部 ２３０１ａ 検出部（エンジン監視型）
２３０１ｂ 検出部（ＡＰＩ監視型） ２９０１ 転送部

Claims (1)

1. 第１の情報処理装置と、前記第１の情報処理装置とＷｅｂサーバとのデータ通信を中継する携帯型の第２の情報処理装置とを含み、
   前記第１の情報処理装置は、
   前記第２の情報処理装置を介して第１Ｗｅｂサーバから受信した第１プログラムの実行中に、特定機能に係る呼び出しの発生を検出する検出部
   を有し、
   前記第２の情報処理装置は、
   前記呼び出しの発生を検出すると、第２Ｗｅｂサーバから受信した第２プログラムの動作状況に係るコンテキストを生成する生成部と、
   前記コンテキストに基づいて、前記呼び出しの許否を判定する判定部と、
   前記呼び出しを許容すると判定した場合に、前記第２の情報処理装置における前記特定機能を呼び出す中継部
   を有するシステム。

Images