JP2018005344A - 機能拡張システム、機能拡張方法および機能拡張プログラム - Google Patents

Abstract

【課題】ユーザインタフェース機能を簡易に拡張できる。【解決手段】プロキシサーバ１０は、Ｗｅｂサーバ３０から端末２０上で動作するＷｅｂブラウザ２１に至るまでの経路上で、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、ルールを解釈して実行するコードとをメッセージに追加する。そして、端末２０は、追加されたコードをＷｅｂブラウザ２１上で実行して、ルールファイルを解釈し、該ルールファイルに基づいて、Ｗｅｂブラウザ２１によって表示される画面上のユーザインタフェース機能を拡張する。【選択図】図１

Description

本発明は、機能拡張システム、機能拡張方法および機能拡張プログラムに関する。

従来、Ｗｅｂシステムなどの業務システム一般において、当初想定していた操作フローが開発時と異なってきたり、新たなフローが必要となったりする場合、業務システムのユーザインタフェース（以下、適宜ＵＩと記載）を作り直すなどの方法で、追加や変化に対応するのは一般的な方法である。

例えば、業務システムにおいて、新たなサービスの追加やサービス内容の変更、運用プロセスの変更などにより、業務システムのＵＩが最適なものではなくなり、業務が効率的に行えなくなる、操作のミスが増えるなど、業務上の問題点が生じてくる。具体的な例として、業務システム上のある入力フォームには所定のコード値の集合からオペレータが一つ選んで記入することを期待されているが、実際には入力にあたって制限がないので、所定のコード値の集合に無い値を入れてしまうなどのミスが起こりうる。

別の例では、新たなサービスメニューが追加されたが業務システムの改修がまだ行われていない場合、自由記述の備考欄に所定のルールに従って新しいサービスメニューに関する情報を入力する、という業務ルールが新たに設定されることがありうるが、この場合あくまでも自由記述の備考欄を使っているために、オペレータが期待される情報を入力しない、といったことが起こりうる。このような場合、業務システムの改修を行うことで対処することが一般的である。

例えば、Ｗｅｂ ＡＰＩを持つＷｅｂシステムを連携させて、新たなＷｅｂシステムを構成する技術も存在する。Ｗｅｂ ＡＰＩを公開しているＷｅｂシステムを１つ以上使って、ＡＰＩ呼び出しを使ってＷｅｂシステムを作り上げることが可能である。ここでは既存のＷｅｂシステム自体には手をいれておらず、利用しているだけである。

業務システムＵＩのクライアントサイド拡張技術は、対象のシステムを作り変えずに、業務システムＵＩをクライアント端末側で機能拡張するアイデアが述べられている（非特許文献１参照）。対象ＵＩ要素に、予め設定された表示ルールに基づいて新たな拡張ＵＩ要素をオーバーレイ表示し、オペレータに拡張ＵＩ要素に対して入力を行わせる。拡張ＵＩ要素への入力内容と予め設定された入力ルールの整合性を判定し、整合する場合には元のＵＩ要素に自動入力する。

また、Greasemonkeyは、Firefoxブラウザのアドオンであり、Greasemonkeyの提供するＡＰＩとJavaScript（登録商標）を活用してユーザが用意したJavaScriptコードの実行を可能とする（非特許文献２参照）。特権モードで動作するGreasemonkeyのＡＰＩによって、通常のブラウザアドオンでは許可されていない任意のリモートサイトへのアクセスなどが可能となっている。このため、Greasemonkeyのコミュニティサイト上のユーザスクリプトに、ユーザ認証情報の取得などを行うマルウェアが一定数含まれていたと確認されている。このように、Greasemonkeyは、本質的にマルウェアに対して脆弱である。

また、Stickletは、Greasemonkeyの脆弱性という欠点を解消するために、独自のDomain Specific Language（ＤＳＬ）を導入して記述を制限している（非特許文献３参照）。独自のＤＳＬ以外ではユーザスクリプトを記述することができなくなっている。Greasemonekyと同様にFirefoxのアドオンとして実装されている。なお、Stickletは非常に限定された記述のみが可能となるＤＳＬの導入により、ある程度汎用的な業務用途で用いることは難しい。

足立 洋之ら、"業務システムＵＩのクライアントサイド拡張によるユーザ操作支援"、電子情報通信学会 総合大会、2016年3月 "Greasemonkey :: Add-ons for Firefox"2010.[平成28年5月24日検索]、インターネット＜https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/＞ Oscar Diaz, Cristobal Arellano, and Maider Azanza. "A Language for End-User Web Augmentation: Caring for Producers and Consumers Alike". ACM Trans. Web, Vol7, No2, Article 9 (May 2013), 51 pages.

上記した従来の技術では、ユーザインタフェース機能を簡易に拡張することができないという課題があった。つまり、アプリケーションシステムの作り変えや開発を行ってユーザインタフェース機能の拡張を行う場合には、テストを含めた開発コストや期間が掛かる。また、パッケージソフトウェアなどソースコードが公開されていない場合は、そもそも開発を行ってシステム（パッケージソフトウェア）を作り変えることが難しいという問題がある。

また、例えば、Ｗｅｂ ＡＰＩを持つＷｅｂシステムを連携させてユーザインタフェース機能の拡張を行う場合に、元となる既存のシステムがＷｅｂ ＡＰＩなど利用可能なＡＰＩを公開していない場合には、新たなＷｅｂシステムを構成するために手間やコストが掛かるという問題がある。

上述した課題を解決し、目的を達成するために、本発明の機能拡張システムは、ブラウザを動作させる端末と、該端末と通信を行うサーバとを有する機能拡張システムであって、前記サーバから前記ブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加部と、前記追加部によって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行部とを備えることを特徴とする。

また、本発明の機能拡張方法は、ブラウザを動作させる端末と、該端末と通信を行うサーバとを有する機能拡張システムによって実行される機能拡張方法であって、前記サーバから前記ブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加工程と、前記追加工程によって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行工程とを含んだことを特徴とする。

また、本発明の機能拡張プログラムは、端末と通信を行うサーバから前記端末上で動作するブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加ステップと、前記追加ステップによって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行ステップとをコンピュータに実行させることを特徴とする。

本発明によれば、ユーザインタフェース機能を簡易に拡張できるという効果を奏する。

図１は、第１の実施形態の機能拡張システムの構成例を示すブロック図である。 図２は、第１の実施形態に係る機能拡張システムにおけるユーザインタフェース機能拡張処理の概要を説明する図である。 図３は、ＵＩ拡張前とＵＩ拡張後のＷｅｂサイトの画面例を示す図である。 図４は、第１の実施形態に係る機能拡張システムの処理を具体的に説明する図である。 図５は、ルールファイルの記述例を示す図である。 図６は、拡張処理の適用前後のＷｅｂブラウザによる表示結果を示す図である。 図７は、対象Ｗｅｂサイトのソースコード（ＨＴＭＬ）のうち、関連する部分を示す図である。 図８は、ＪＳＯＮ形式で記述したルールファイルの例を示す図である。 図９は、ルールファイルから参照され、Ｗｅｂブラウザにて解釈実行されるJavaScriptコードの例を示す図である。 図１０は、ＵＩ拡張関連コードが注入された後のメッセージ例を示す図である。 図１１は、ＵＩ拡張関連コードが注入された後でかつＷｅｂブラウザによって解釈実行された後のメッセージ例を示す図である。 図１２は、第１の実施形態に係る機能拡張システムにおけるルール解釈実行処理の流れの一例を示すフローチャートである。 図１３は、第１の実施形態に係る機能拡張システムにおける対象アプリケーション変化検知処理の流れの一例を示すフローチャートである。 図１４は、プロキシサーバを端末上で動作させる場合の機能拡張システムの処理の概要を説明する図である。 図１５は、Ｗｅｂサーバとプロキシサーバが同じサーバで稼働している場合の機能拡張システムの処理の概要を説明する図である。 図１６は、第２の実施形態に係る機能拡張システムにおけるユーザインタフェース機能拡張処理の概要を説明する図である。 図１７は、ＳＳＬを含む機能拡張システムの構成例を示すブロック図である。 図１８は、機能拡張プログラムを実行するコンピュータを示す図である。

以下に、本願に係る機能拡張システム、機能拡張方法および機能拡張プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態により本願に係る機能拡張システム、機能拡張方法および機能拡張プログラムが限定されるものではない。

（第１の実施形態）
図１は、第１の実施形態に係る機能拡張システムの構成の一例を示す図である。第１の実施形態に係る機能拡張システムは、プロキシサーバ１０、端末２０およびＷｅｂサーバ３０を有する。なお、図１に示す構成は一例にすぎず、具体的な構成や各装置の数は特に限定されない。

プロキシサーバ１０は、ユーザ端末２０からＷｅｂサーバ３０へのＷｅｂアクセスを中継するサーバである。プロキシサーバ１０は、Ｗｅｂサーバ３０から端末２０上で動作するＷｅｂブラウザ２１に至るまでの経路上で、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、ルールを解釈して実行するコードとをメッセージに追加する。なお、ここでプロキシサーバ１０とは、フォワード型のものであってもよいし、リバース型であってもよい。また、ルールファイルそのものをメッセージに追加せずにルールファイルの参照のみを追加してもよく、ルールファイルの実体が外部にあってもよい。

端末２０は、例えばパーソナルコンピュータ、スマートフォン等の情報処理装置である。端末２０は、ユーザの操作を受け付け、ＯＳ２２上で動作するＷｅｂブラウザ２１を介してＷｅｂサーバ３０と通信を行い、Ｗｅｂサイト等を閲覧可能に表示する。また、端末２０は、ユーザによる入力操作を受け付ける入力デバイス２３とＷｅｂサイト等の画面を表示するディスプレイ２４とを有する。

Ｗｅｂサーバ３０は、例えばＷｅｂサイトを運営するサーバ装置であって、端末２０からプロキシサーバ１０を経由してアクセスを受け付け、受け付けたアクセスに応じてメッセージをプロキシサーバ１０を介して端末２０に返信する。

ここで、図２を用いて、第１の実施形態に係る機能拡張システムにおけるユーザインタフェース機能拡張処理の概要を説明する。図２は、第１の実施形態に係る機能拡張システムにおけるユーザインタフェース機能拡張処理の概要を説明する図である。図２に示すように、プロキシサーバ１０は追加部１１を有し、端末２０は実行部２５を有する。

プロキシサーバ１０の追加部１１は、Ｗｅｂサーバ３０から端末２０上で動作するＷｅｂブラウザ２１に至るまでの経路上で、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、ルールを解釈して実行するコードとをメッセージに追加する。具体的には、追加部１１は、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを受信すると、ユーザインタフェースを拡張するルールが規定されたルールファイルとルールを解釈して実行するコードを含むＵＩ拡張関連コードとをメッセージに注入し、端末２０に転送する。また、追加部１１は、アプリケーションの変化を検知するコードと、アプリケーションの変化に応じてルールを解釈して実行するコードとをさらにメッセージに追加する。

そして、端末２０の実行部２５は、追加部１１によって追加されたコードをＷｅｂブラウザ２１上で実行して、ルールファイルを解釈し、該ルールファイルに基づいて、Ｗｅｂブラウザ２１によって表示される画面上のユーザインタフェース機能を拡張する。また、実行部２５は、追加部１１によって追加された各コードをＷｅｂブラウザ２１上で実行し、アプリケーションの変化を検知した場合には、該変化に応じてルールファイルを再度解釈して、ユーザインタフェース機能を拡張する。また、実行部２５は、監視すべきイベントを指定するホワイトリストと監視すべきでないイベントを指定するブラックリストを参照し、監視すべきイベントを指定するリストに記載されたイベントによりアプリケーションの変化を検知した場合に該変化に応じてルールファイルを再度解釈して、ユーザインタフェース機能を拡張するようにしてもよい。

つまり、プロキシサーバ１０は、Ｗｅｂブラウザ２１においてプロキシサーバを利用すると設定している場合やリバース型プロキシを設置している場合、Ｗｅｂサーバ３０から端末２０に向かうＨＴＴＰレスポンスがプロキシサーバ１０を通ることを利用して、プロキシサーバ１０においてレスポンスの本文を書き換えてから、端末２０に転送する。プロキシサーバ１０は、拡張ルールを参照して動作するようなコード（例えば、ＨＴＭＬ、JavaScript等）をＨＴＴＰレスポンス本文に埋め込む。端末２０のＷｅｂブラウザ２１は、レスポンスに埋め込まれたコードを実行すると、コードはルールを解釈してＵＩ拡張を行う。

ここで、図３を用いて、ＵＩ拡張の実施イメージを説明する。図３は、ＵＩ拡張前とＵＩ拡張後のＷｅｂサイトの画面例を示す図である。図３に示すように、ＵＩ拡張される前のＷｅｂサイトでは１行の入力フィールドであったものが、ＵＩ拡張後はリスト形式の入力ＵＩ要素となっており、同様にテキストエリアであったところが、ラジオボタンとカレンダーから日付を選択するＵＩ要素とボタンに、機能拡張されている。また、アノテーションメッセージも追加されている。これにより、期待される入力値を決まった値の範囲内に制限することができており、またユーザ操作を支援するためのアノテーションも追加できている。これらの拡張されたＵＩに対する入力値は元のＵＩ要素に必要に応じて変換を施して転記すればよい。その際、拡張したＵＩを表示し続けてもよいし、非表示にして元のＵＩを表示してもよい。これらの処理はルール中にJavaScriptなどブラウザが解釈実行できるプログラミング言語を使えば記載可能である。

また、他にも例えば、ある特定の値が入力されたらそれに応じてメッセージ（例えば、警告メッセージ）を表示させたり、画面上に表示された特定の値に応じて処理を変化させたり、入力値を他の箇所に転記させたり、入力値をあるルールに従って変換してから転記したり、表示値に応じた自動操作など、JavaScriptを使ってブラウザ上で実施可能なことは原理的に全て可能である。その他、ある条件（表示値がある値を含むなど）が満たされた時に、予め決められた一連の処理を順次実行するような自動操作も可能であるし、特定の操作が難しい画面において、操作方法を支援する所定の動画像を表示再生させたりすることも可能である。また、ユーザ操作等のイベントを検知して、所定の処理を実行するなどのイベント駆動型の処理内容も指定できる。いずれにおいても、元となるＷｅｂサーバ３０には何も手を入れていないし、端末２０側に特別なアプリケーションを導入することも必要なく、Ｗｅｂブラウザ２１が動きさえすれば、ＯＳ等の環境も問わない。

このように、Ｗｅｂブラウザ２１で解釈実行できるプログラミング言語（例えば、JavaScript等）で記載した任意のコードを中に含む拡張ルール、及び拡張ルールを解釈実行するＵＩ拡張関連コード、もしくはこれらへの参照をメッセージに追加するのみで、Ｗｅｂサーバ３０と端末２０のＷｅｂブラウザ２１を結ぶ経路途中で、ユーザインタフェース機能を拡張する。具体的には、経路途中に設置したプロキシサーバ１０（フォワード型、リバース型問わず）において、Ｗｅｂサーバ３０から端末２０のＷｅｂブラウザ２１に対して返却されたレスポンスメッセージ（ＨＴＭＬ、JavaScript、ＣＳＳ等）を書き換えることで、ＵＩ機能の拡張を実現する。これにより、開発コスト及び期間を小さく抑えたまま、軽量・迅速な形で、ＵＩ周辺に特化した形のＷｅｂシステムの簡易な拡張が可能となる。さらに、既存のＷｅｂシステムのＵＩが前提となるため、ＵＩ拡張したとしても既存Ｗｅｂシステムの枠組みから大きく外れないため、従来のＷｅｂシステムのインタフェースになれたユーザにとってもとっつきやすいインタフェースとなっていることが期待できる。また、プロキシサーバ１０がＵＩ拡張関連コードを注入することで、Internet Explorerや、その他タブレットやスマートフォンのような端末２０上のＷｅｂブラウザ２１をサポートする。

また、拡張ルール内の拡張ロジック部分の記述力に関しては、Stickletのような記述力不足に陥らないようにするために、任意のJavaScriptコードを許可する。一方で、拡張ルール内のJavaScriptコードに関してはサンドボックス技術を活用して、例えば、予め設定されていないドメインに対するアクセスは不許可とするなど、ユーザもしくは管理者がプロキシサー１０バやアドオンに指定したポリシー（例えば、アクセスできる外部アクセスのリスト）に応じたセキュリティを担保することで、脆弱性の問題を回避する。これにより、入力値のバリデーションや自由記述の制限（リスト化など）、入力値に応じた拡張内容の変化など、様々な拡張機能を実装できる。

ここで、図４を用いて、第１の実施形態に係る機能拡張システムの処理を具体的に説明する。図４は、第１の実施形態に係る機能拡張システムの処理を具体的に説明する図である。図４に示すように、プロキシサーバ１０は、Ｗｅｂサーバ３０から端末２０に向かって送られるメッセージを取得し、ルール解釈実行部、変更検知部、ＵＩ拡張再表示部で構成されるＵＩ拡張関連コード、ルールファイルもしくはこれらへの参照をメッセージに注入し、Ｗｅｂブラウザ２１に転送する。なお、ルール解釈実行部、変更検知部、ＵＩ拡張再表示部とは、メッセージに注入されるコードである。

なお、ルールファイルは必ずしも一緒に注入する必要はなく、ルール解釈実行部から外部のファイルを参照する形でもよい。また、全てのレスポンスメッセージに対して、毎回ルール解釈実行部等を注入することは必須ではなく、例えば、プロキシサーバ１０は、ルールファイルを解釈して、各ルールで規定したＵＲＬとマッチした場合に限りＵＩ拡張関連コードをメッセージに注入するようにしてもよい。

Ｗｅｂブラウザ２１は、Ｗｅｂサーバ３０から元々送信されたメッセージと注入された記述をあわせて一体的に解釈実行することで、ルールに指定されたＵＩ拡張が実施されることになる。ＵＩ拡張関連コードは、ＵＩ拡張関連コードを実装した言語（例えば、JavaScript）のインタプリタによって、Ｗｅｂブラウザ２１で解釈実行される。

また、図４に示すように、ＵＩ拡張関連コードは、プロキシサーバ１０でデータとして保持、または外部サーバでデータとして保持されるＵＩ拡張関連コードへの参照をデータとして保持され、メッセージに注入されるものであって、Ｗｅｂブラウザ２１に渡されてＷｅｂブラウザ２１で動作されるものである。また、図４においてＷｅｂブラウザ２１での注入メッセージの解釈実行イメージとして示されているように、Ｗｅｂブラウザ２１で動作する際は、ルール解釈実行部がルールファイルを取得し、取得したルールファイルをもとにルールを順次解釈実行する。また、変更検知部が対象Ｗｅｂサイトなどの変更（ＤＯＭ（Document Object Model）変化、リサイズ等）を検知すると、その変更内容をＵＩ拡張再表示部に通知する。そして、ＵＩ拡張再表示部は、ルール解釈実行部に必要なルールの再適用を依頼する。

（ＵＩ拡張関連コードについて）
ルールファイルには、ＵＩ拡張を行う条件（発火条件）、対象ＵＩ要素および操作内容が記載されている。例えば、発火条件はＵＲＬが「http://xxx.yyy/zzz/.*」という正規表現とマッチすること、対象ＵＩ要素は「input[name=検索ボタン]」というＷ３ＣのＣＳＳのＳｅｌｅｃｔｏｒ記法により表されるＨＴＭＬ内のＵＩ要素、操作内容は<input type="submit" name="Search button" value="Search"...>で表されるＵＩ要素を対象ＵＩ要素と同じサイズで同じ位置に重ねて表示する、拡張後のＵＩ要素に対する入力内容を元のＵＩ要素に転記する、新たなＵＩ要素は追加せずに元のＵＩ要素に直接バリデーション機能を追加する、などといった内容である。同じサイズ、同じ位置で対象ＵＩ要素の上に重ねて表示する方法は、ＣＳＳを使いposition: absolute及びz-indexを対象ＵＩ要素よりも大きな値に設定することで、実現可能であり、JavaScript等を用いることで容易に実現可能である。また、対象ＵＩ要素に依存しない拡張内容であれば、対象ＵＩ要素を指定せずに、操作内容を記述することも可能である。

また、発火条件や対象ＵＩ要素の指定を、画像情報を使って記述する形態も可能である。例えば、発火条件として、ファイルのパスによって指定される画像が画面上に存在すること、また対象ＵＩ要素の指定も同様で、ファイルのパスによって指定された画像が存在すればその画像を指定、などといった形でピクセルデータを使った指定も同じ枠組みで実現可能である。また、ルールファイル自身の編集方法については、特に限定されるものではなく、ルール形式に応じてテキストエディタで記載してもよいし、専用のエディタを用意してもよい。

また、ルールファイルは、ルール解釈実行部に添付させておいてもよいし、端末２０のローカルファイルシステムに持たせてもよいし、外部の独立したＷｅｂサーバが提供する形でもよいし、Ｗｅｂサーバにルール取得や更新のためのＷｅｂ ＡＰＩを付加して他システムとの連携を促進して、更なるルール共有や活用をはかることもできる。

ここで、図５を用いて、ルールファイルの記述例（ＪＳＯＮ形式）について説明する。図５は、ルールファイルの記述例を示す図である。図５に例示するように、ＵＩ拡張を行う条件を指定する発火条件は、ｕｒｌ欄に指定したＵＲＬと現在のＵＲＬがマッチするかどうか、またprecondition欄に記載したJavaScriptによる式の真偽値をチェックしている。対象ＵＩ要素は、selectorによって指定しており、ここではＣＳＳのselectorの記法を用いている。そして、発火条件が真であり、かつ対象ＵＩ要素が存在する場合、操作内容の一つとして、ｕｉで表されるＵＩ要素を対象ＵＩと同じサイズ同じ位置で、対象ＵＩの上に重ねて表示する。追加の操作内容は、ｂｉｎｄまたはｂｉｎｄｅｘｔで示され、JavaScriptで記載する例となっている。ｂｉｎｄｅｘｔは外部のJavaScriptファイルを参照し、fの値として指定されたｆｕｎｃｔｉｏｎを実施する指定の例である。

ｕｒｌ要素は例えば一つ上の階層に記述し、１つのＵＲＬに対して複数のルールが対応する場合に、１つのＵＲＬを何度も記述しないような方法も可能である。またｂｉｎｄやｂｉｎｄｅｘｔによる操作内容をどういうルール内で指定する拡張ＵＩ要素やｓｅｌｅｃｔｏｒで指定する対象ＵＩ要素に対するものだけに限定する形態も可能であるし、逆に全ルールに共通の操作内容として、前述のｕｒｌ要素と同様に一つ上の階層に記述し、各ルールで共用する形態も可能である。

ルール解釈実行部は、ルールファイルとあわせて、プロキシサーバ１０によってＷｅｂサーバ３０からブラウザ本体に渡されるレスポンスメッセージに注入される。ルール解釈実行部への参照のみを注入する形も同様である。レスポンスメッセージは、端末２０ではＷｅｂブラウザ２１に渡されて解釈実行され、Ｗｅｂブラウザ２１上に表示される。ルール解釈実行部はＷｅｂブラウザ２１が解釈実行できる言語で実装している前提であり、例えば、JavaScriptが例として挙げられる。JavaScriptなどによって実装されたルール解釈実行部はブラウザ本体内のJavaScriptインタプリタによって解釈実行され、既にレスポンスメッセージのＨＴＭＬ等からＷｅｂブラウザ２１が構成してあるＤＯＭに対して働きかけ、ルールに従って追記や書き換え等を行う。

変更検知部は、対象アプリケーションの変化を検知したらＵＩ拡張再表示部に通知する。このときＵＩ拡張再表示部は既に端末２０側のＷｅｂブラウザ２１で動作している。通知されたＵＩ拡張再表示部はルールを再度解釈実行するなどの処理を行う。この機能部は、ある時点でＵＩ拡張のルールを適用し、ＵＩ機能を拡張したとしても、ウィンドウのリサイズやアプリケーション画面の切り替え等のイベントにより、適用済みのルールが適切ではなくなることがあるため、そのような事態に対応するためのものである。Ｗｅｂアプリケーションの例では、ページのリサイズやスクロール等のイベントを取得したり、MutationObserver（例えば、MutationObserver−Web APIs | MDN 「https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver」参照）という枠組みを用いてＤＯＭの変更イベントを取得することで実現可能である。ルール解釈実行部と一緒に端末２０へのレスポンスメッセージに変更検知部本体もしくは参照を注入する形が一つの実施形態である。

また、Ｗｅｂページの作り方によっては頻繁にイベントが発生するケースもある。例えば、マウスの位置を検知・追跡し、その現在位置にあわせて、画像要素を変化させるなどといったＷｅｂページでは、ページの変化イベントが発生しすぎてしまい、ルール適用の回数及び頻度が膨大となり、ルール適用処理の負担が重たくなってしまうことがありうる。このようなケースに対しては、監視すべきイベントを指定するホワイトリスト、また監視すべきでないイベントを個別に指定するブラックリストを導入することで、ルールの再適用処理の回数を大幅に減らすことが可能である。具体的には、変更検知部にてホワイトリストとブラックリストをチェックするようにすればよい。

ＵＩ拡張再表示部は、ＵＩ拡張の再適用をＷｅｂブラウザ２１側で行うためのものである。基本的には現在閲覧しているＵＲＬにマッチしたルール集合のみを対象に、ルール解釈実行部を使い、ルールの再適用を行えばよい。

（具体的な事例に基づいた機能拡張処理の説明）
以下では、プロキシサーバ１０で、どのように機能拡張処理が実現されるか、図６から図１１で示される例を用いて具体的に説明する。図６は、拡張処理の適用前後のＷｅｂブラウザによる表示結果を示す図である。図７は、対象Ｗｅｂサイトのソースコード（ＨＴＭＬ）のうち、関連する部分を示す図である。図８は、ＪＳＯＮ形式で記述したルールファイルの例を示す図である。図９は、ルールファイルから参照され、Ｗｅｂブラウザにて解釈実行されるJavaScriptコードの例を示す図である。図１０は、ＵＩ拡張関連コードが注入された後のメッセージ例を示す図である。図１１は、ＵＩ拡張関連コードが注入された後でかつＷｅｂブラウザによって解釈実行された後のメッセージ例を示す図である。

図６の例では、この例で実施する拡張処理の適用前後のＷｅｂブラウザ２１による表示結果を示している。元々は、１行のテキストが入力可能なフォームが２つ並んでいたが（お客様氏名と申込種別の入力フォーム）、その双方の入力フォームの上に拡張ＵＩフォームを重ねて表示している。申込種別の入力フォームは自由記述のフォームであったものが、ドロップダウンリストから選択する形式のフォームとなっている。お客様氏名のフォームは見た目には変化は見えないが、後述するように全角文字しか受け付けないような入力値に対するバリデーション処理が追加されている。これらの拡張はプロキシサーバ１０を経由した場合に効果としてあらわれる。フォワード型プロキシを利用する場合には、Ｗｅｂブラウザ２１のプロキシサーバの設定に、ＵＩ拡張関連コードを注入するプロキシサーバ１０を指定すればよい。

図７は、図６で示す対象Ｗｅｂサイトのソースコード（ＨＴＭＬ）のうち、関連する部分を示したものである。お客様氏名と申込種別の入力フォームがｉｎｐｕｔタグ（type=text）で表現されていることがわかる。ＵＩ拡張処理を行わない場合は、Ｗｅｂサーバ３０からは図７で示すＨＴＭＬを含むコードがメッセージとしてプロキシサーバ１０を経由して端末２０上のＷｅｂブラウザ２１に届き、Ｗｅｂブラウザ２１によって解釈実行され（この場合はＨＴＭＬとして解釈実行され）、画面上に表示されることとなる。

図８は、ＪＳＯＮ形式で記述したルールファイル例である。ここでは、上述した図５のルール例と若干形式が異なっており、１つのｕｒｌ要素（ここでは、「http://localhost/example.html」）に対して、ｒｕｌｅ要素で表されるルールのリスト（ここでは２ルール）、ｂｉｎｄｅｘｔ要素で表される機能拡張のスクリプトを記載している。ｂｉｎｄｅｘｔ要素では、図９で示すJavaScriptコードを参照しており、ルールが読み込まれた際にＷｅｂブラウザ２１中のJavaScriptインタプリタによって解釈実行される。図８の１つ目のルールでは、selector要素の値”input#name”で示される対象Ｗｅｂページ中のＵＩ要素（お客様氏名）の位置にあわせて、ルール中のＵＩ要素の値で示されるｉｎｐｕｔタグ（１行の文字列を入力するフォーム）を配置する。配置と重なり順序（ｉｎｐｕｔタグがより上位に表示）はルールではなくルール解釈実行部の一部としてメッセージに注入されるＣＳＳの中で表現される。図８の２つ目のルールは、ｓｅｌｅｃｔｏｒ要素の値”input#type”で示される対象Ｗｅｂページ中のＵＩ要素（申込種別）の位置にあわせて、ルール中のＵＩ要素の値ｓｅｌｅｃｔタグで表されるドロップダウンリストのＵＩ要素を表示する。

図９の例は、図８のルールファイルがＷｅｂブラウザ２１上でルール解釈実行部によって解釈実行されるときに、あわせて解釈実行されるJavaScriptコードである。この例ではｂｉｎｄｅｘｔ要素により、外部サーバにホストされているスクリプトとしたが、ルールファイル中に直接記述するｂｉｎｄ要素を使っても同じ効果を得ることができる。この例では、お客様氏名の入力フォームを拡張したフォームについてのイベント処理を記載している。ルールファイルのｕｉ要素によって表示された新たなＵＩ要素（拡張入力フォーム）からフォーカスが外れた時（ｂｌｕｒ関数）に拡張入力フォームへの入力値をチェックして全角文字でなければ、アラートを表示するようにしている。全角文字が入力された場合は元の入力フォームに入力値を転記して、拡張入力フォームを非表示とする、といった処理が記載されている。２つ目の申込種別に関する処理では、ドロップダウンリストで選択された値を元の入力フォームにやはり転記してから、拡張入力フォーム（ドロップダウンリスト）を非表示としている。

図１０の例は、プロキシサーバ１０によって、JavaScript（Ｗｅｂブラウザ２１で解釈実行可能な言語であれば他でもよい）で実装されたＵＩ拡張関連コード、すなわちルール解釈実行部、ＵＩ拡張再表示部、変更検知部、もしくはこれらのＵＩ拡張関連コードへの参照、及びＪＳＯＮ等によって記述されたルールファイル本体もしくはルールファイルへの参照が注入された後のメッセージ例の抜粋である。この段階ではまだＷｅｂブラウザ２１によってＵＩ拡張関連コード及びルールファイルは解釈実行されていない。プロキシサーバ１０によって、ルール解釈実行部、変更検知部、ＵＩ拡張再表示部のJavaScriptコードが＜ｓｃｒｉｐｔ＞タグを使って挿入されている。このメッセージが、Ｗｅｂブラウザ２１によって解釈実行される。

図１１の例は、図１０のメッセージがＷｅｂブラウザ２１によって解釈実行された後のメッセージ抜粋を示している。ＵＩ拡張関連コードの解釈実行により、ルールファイルが解釈実行され、図に示すようなお客様氏名の入力フォームを拡張したｉｎｐｕｔタグ、申込種別の入力フォームを拡張したｄｉｖタグ（内部はｓｅｌｅｃｔとｏｐｔｉｏｎタグ）が新たに挿入されていることがわかる。これらが実際には図６の下部に示すように、Ｗｅｂブラウザ２１上では新たな入力フォームとして表示される。また図９で示したJavaScriptによるイベント処理などに関わる拡張コードは、ｓｃｒｉｐｔタグによって挿入されている。これがＷｅｂブラウザ２１によって実行されることで、フォーカスが外れたイベントに対する処理が実現される。

また、プロキシサーバ１０がどのように図１０に示すようなＵＩ拡張関連コードを注入するかは、例えばＡｐａｃｈｅのｍｏｄ＿ｐｒｏｘｙモジュールを使いプロキシサーバ１０を実装し、ｍｏｄ＿ｅｘｔ＿ｆｉｌｔｅｒなどのモジュールを使うことで実現できる。ｍｏｄ＿ｅｘｔ＿ｆｉｌｔｅｒを使うと、プロキシサーバ１０のプロセスは、外部のプロセスにＷｅｂサーバ３０からのレスポンス本文を転送し、何らかの処理をした結果の出力を受け取ることができる。この枠組を利用することで、Ｗｅｂサーバ３０からのレスポンスメッセージを入力として、ＵＩ拡張関連コードをＢｏｄｙタグ末尾等に注入したメッセージを出力としたプログラムを任意の言語で実装することで、機能拡張処理を実現することができる。また、無条件に図１０で示すようなＵＩ拡張関連コードを挿入するのではなく、プロキシサーバ１０で動かす前述のメッセージ置換プログラムで、ルールファイルからＵＲＬをチェックしてから必要な場合だけＵＩ拡張関連コードを注入するような実装も可能である。

（ルール解釈実行処理及び対象アプリケーション変化検知処理の流れ）
図１２は、第１の実施形態に係る機能拡張システムにおけるルール解釈実行処理の流れの一例を示すフローチャートである。図１３は、第１の実施形態に係る機能拡張システムにおける対象アプリケーション変化検知処理の流れの一例を示すフローチャートである。

まず、図１２を用いて、機能拡張システムにおけるルール解釈実行処理の流れを説明する。図１２に示すように、端末２０の実行部２５は、プロキシサーバ１０からメッセージを受信すると、該メッセージに含まれるルールファイルを取得する（ステップＳ１０１）。そして、実行部２５は、次のルールが存在するかを判定し（ステップＳ１０２）、存在する場合には（ステップＳ１０２肯定）、次のルールを読み込み、解釈する（ステップＳ１０３）。そして、実行部２５は、解釈したルールを実行し（ステップＳ１０４）、ステップＳ１０２に戻る。ここでは、全てのルールが実行されるまでステップＳ１０２〜Ｓ１０４の処理を繰り返す。そして、ステップＳ１０２において、次のルールが存在しないと判定された場合には（ステップＳ１０２否定）、処理を終了する。

次に、図１３を用いて、対象アプリケーション変化検知処理の流れを説明する。図１３に示すように、端末２０の実行部２５は、対象アプリケーションを監視する（ステップＳ２０１）。そして、実行部２５は、対象アプリケーションに変化があると判定した場合には（ステップＳ２０２肯定）、図１２に示したルール解釈実行処理を実行し（ステップＳ２０３）、ステップＳ２０１に戻る。また、実行部２５は、対象アプリケーションに変化がないと判定した場合には（ステップＳ２０２否定）、そのままステップＳ２０１に戻る。

なお、上記の説明では、プロキシサーバ１０がＷｅｂサーバ３０や端末２０とは別のマシン上で動作している場合について説明したが、これに限定されるものではない。例えば、図１４に例示するように、端末２０上でプロキシサーバ１０を動作させてもよい。また、例えば、図１５に例示するように、Ｗｅｂサーバ３０とプロキシサーバ１０が同じサーバで稼働していてもよい。図１４は、プロキシサーバを端末上で動作させる場合の機能拡張システムの処理の概要を説明する図である。図１５は、Ｗｅｂサーバとプロキシサーバが同じサーバで稼働している場合の機能拡張システムの処理の概要を説明する図である。

なお、上述したように拡張ルールの解釈を行うコードを埋め込む方法以外に、プロキシサーバ１０で、ＵＩ拡張のプログラムを動作させ、拡張ルールを解釈して、必要な拡張のためのコード（ＨＴＭＬ、JavaScript等）をレスポンス本文に埋め込むことも可能である。この場合は解釈結果を埋め込む点が解釈を行うコードを埋め込む方法と異なる。ただし、解釈結果を埋め込むやり方では、プロキシ配下の端末台数が増えたり、拡張処理が複雑になっていくと、プロキシサーバ１０の負荷が高くなり、端末２０から見た時のレスポンスが悪化する可能性もある。この場合のルール解釈実行部（テキストの置換等が行える一般のプログラミング言語で実装）は、プロキシサーバ１０よりＷｅｂサーバ３０から届いたレスポンスメッセージを渡されるので、そのメッセージをルールに従って追記や置換等を行い、さらに変更検知部が通知できるようにするために、通知に応えてＵＩ拡張を再表示するのに必要なコード（ＵＩ拡張再表示部）もメッセージに埋め込み、プロキシサーバ１０に返却する。ＵＩ拡張再表示部は、例えば、ＨＴＭＬ内のＳｃｒｉｐｔタグなどに埋め込んでしまう形が一つの形態である。

また、Ｗｅｂブラウザ２１側で動作しているＵＩ拡張再表示部は通知を受けたら、ＵＩ拡張を再表示するなどの処理を行う。プロキシサーバ１０はルール解釈を行いメッセージの変換処理を行う際に、適用したルールのリストを得ているので、これらのルールとその処理部分のみをＵＩ拡張再表示部に埋め込むなどすることが一つの実現例である。

（第１の実施形態の効果）
第１の実施形態に係る機能拡張システムにおいて、プロキシサーバ１０は、Ｗｅｂサーバ３０から端末２０上で動作するＷｅｂブラウザ２１に至るまでの経路上で、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、ルールを解釈して実行するコードとをメッセージに追加する。そして、端末２０は、追加されたコードをＷｅｂブラウザ２１上で実行して、ルールファイルを解釈し、該ルールファイルに基づいて、Ｗｅｂブラウザ２１によって表示される画面上のユーザインタフェース機能を拡張する。このため、ユーザインタフェース機能を簡易に拡張することが可能である。

つまり、第１の実施形態に係る機能拡張システムによって、従来であれば、ＵＩに関わる部分において、対象のＷｅｂシステム自体を作り変えることによって得ていた効果と同等の効果を、対象システムの作り変え無しに得ることができる。また、プロキシサーバ１０を利用する形態においては端末２０への特殊なアプリケーションの導入無しに、簡易なルール記述により、ユーザインタフェース機能を簡易に拡張することができる。

また、第１の実施形態に係る機能拡張システムによって、ＵＩ拡張ルール内に記述するＷｅｂブラウザ２１で解釈実行できるプログラミング言語による任意のコードによって機能拡張することができる一方で、サンドボックス技術の適用により悪意あるコード実行を防ぐことで、ルールの記述力とルール実行の安全性を高いレベルで確保できるようになる。

また、第１の実施形態に係る機能拡張システムにおいて、端末２０の環境に要求されるのは、Ｗｅｂブラウザ２１が動作することのみであり、その他動作しているＯＳは限定せず、端末２０に特殊なアプリケーションやアドオン等の導入を要求することもないため、汎用的なプラットフォーム上でＵＩ拡張の効果を享受することができる。これにより、Ｗｅｂブラウザ２１の動作する端末、例えばタブレット端末やスマートフォンなどでも、ＯＳを問わずＵＩ拡張を利用することができるようになる。

さらに、第１の実施形態に係る機能拡張システムでは、ＵＩ拡張ルールを複数人が作成していくことによって、システム上のどこに改善ポイントがあり、どう修正すべきなのかが見えてくるので、システム開発の要件定義をより効果的なものにすることができる。

（第２の実施形態）
上記の第１の実施形態では、プロキシサーバ１０がメッセージにＵＩ拡張関連コードを注入する場合を説明したが、これに限定されるものではなく、ブラウザアドオンがメッセージにＵＩ拡張関連コードを注入するようにしてもよい。そこで、以下では、第２の実施形態として、ブラウザアドオンがメッセージにＵＩ拡張関連コードを注入する場合を説明する。なお、第１の実施形態と同様の構成および処理の説明は省略する。

図１６に示すように、端末２０は、Ｗｅｂブラウザ２１と該Ｗｅｂブラウザ２１のブラウザアドオン４０を動作している。ブラウザアドオン４０は、Ｗｅｂサーバ３０から端末２０上で動作するＷｅｂブラウザ２１に至るまでの経路上で、Ｗｅｂサーバ３０から端末２０宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、ルールを解釈して実行するコードとをメッセージに追加する。

ここで、基本となる機能構成はプロキシサーバ１０を用いた第１の実施形態と同一である。ブラウザアドオン４０は、Ｗｅｂブラウザ２１がページをレンダリングして表示する前に、適宜ページを書き換えることができるので、ＵＩ拡張関連コードをメッセージに注入することができる。ブラウザアドオン４０を用いた場合は、Ｗｅｂブラウザ２１ごとに若干異なる実装方法が必要となるものの、基本となる方式は全て同一である。ルール解釈実行部をメッセージに埋め込む形となる。なお、ここでのＷｅｂブラウザ２１は、ＵＩ拡張関連コードを注入するブラウザアドオンを含まないものとする。

ブラウザアドオン４０を実装する場合は、各Ｗｅｂブラウザ２１のアドオンの実装方法に従って実装することになる。ＦｉｒｅｆｏｘやＣｈｒｏｍｅといったブラウザであれば、Ｗｅｂ ＥｘｔｅｎｓｉｏｎｓもしくはＥｘｔｅｎｓｉｏｎ ＡＰＩなどと呼ばれる形式を使って、ブラウザアドオンを実装することができる。Internet Explorerの場合は、Browser Helper Objectを用いてブラウザアドオンを実装する形となる。その他、例えば、Internet Explorerの場合などは、ブラウザアドオンのほかに、単独の独立したプログラムを構築して、そのプログラムからInternet Explorer内のページ構造ＤＯＭにアクセスするＡＰＩを使って、ページ構造を操作する形も取りうる。この場合は前述の独立したプログラムが追加部１１として機能していることになる。

ブラウザアドオン４０を用いる方式で、外部のＷｅｂサーバ３０にルールファイルを配置する場合は、Ｗｅｂブラウザ２１に通常実装されている同一生成元ポリシーによって、対象のＷｅｂサイトとドメイン等（生成元）が異なるために、取得することができない、という制約がある。これらは全て公表されている方法、このケースでは例えばルールファイルをホストするＷｅｂサーバでＣＯＲＳ（Cross Origin Resource Sharing）の設定を行うことによって回避可能である（例えば、HTTP access control (CORS) 「https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS」参照）。

ブラウザアドオン４０を活用する場合であっても、機能拡張処理については、プロキシサーバ１０を活用する場合と概ね同じである。ただし、プロキシサーバ１０がＵＩ拡張関連コードをＷｅｂサーバ３０からのメッセージに注入していた処理を、ブラウザアドオン４０として実装する必要がある点が異なる。

ＦｉｒｅｆｏｘやＣｈｒｏｍｅでサポートしているWeb Extensionsという形式を前提とすると、アドオンパッケージでは、Content ScriptとしてJavaScriptファイルを指定でき、このJavaScriptコードがアドオンのｍａｎｉｆｅｓｔファイルで正規表現によって指定されたＵＲＬを読み込む度ごとに実行されるので、Content ScriptとしてＵＩ拡張関連コードを前述の図１０と全く同じようにＢｏｄｙタグ末尾に注入すればよい。

注入した後、ＵＩ拡張関連コードがＷｅｂブラウザ２１で解釈実行されると、図１１と同様に、ルールファイルの解釈実行が行われて、ルールファイルの指定に応じて新たなＵＩ要素が追加され、イベント処理関連等の拡張JavaScriptコードが注入される。結果となるメッセージは図１１のプロキシサーバ１０を利用した形態と同一である。

ここで、注入するＵＩ拡張関連コードとルールファイルもしくはこれらへの参照はプロキシサーバ１０を用いた第１の実施形態のものと同一のものを使うことができる。そのため、プロキシサーバ１０を使っても、ブラウザアドオン４０を使っても、同一の効果をＷｅｂブラウザ２１上でユーザは得ることができる。

なお、多様な業務環境を想定して、端末２０へのソフトウェア導入無しで済ませたい環境と、端末２０へのソフトウェア導入による対応を望む環境、またそれらが混在した環境に対応するため、拡張ルールを解釈実行する機能部をブラウザアドオン４０とプロキシサーバ１０で共通化することで、同一ルールをブラウザアドオン４０、プロキシサーバ１０の双方で解釈実行し、同じ効果を奏することができる。

また、本実施形態を実現するにあたって、Greasemonkeyのようなブラウザアドオンをベースに拡張してもよいし、０からブラウザアドオン４０やプロキシサーバ１０として実装してもよい。上記の説明は、Greasemonkeyなどの既存のツールに依存しない前提で記載している。

（第３の実施形態）
さて、これまで本発明の実施形態について説明したが、本発明は上述した実施形態以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では第３の実施形態として本発明に含まれる他の第３の実施形態を説明する。

（安全性）
端末２０の実行部２５は、予め決められたファイル以外の情報を、予め決められた外部サイト以外へＷｅｂブラウザ２１が送信することを中止するようにしてもよい。例えば、ポリシーに応じた、Ｗｅｂブラウザ２１上で動作する言語（ここではJavaScriptを例にとる）によって書かれたコードのセキュリティ担保について、最も簡単だが限定的な実現方法は、Ｗｅｂサーバ３０からのレスポンスがＷｅｂブラウザ２１のレンダリングエンジンに渡される前に捕捉し、チェックして書き換える手法である。例えば、ブラウザアドオン４０やプロキシサーバ１０において、外部に送信したりＷｅｂブラウザ２１上に表示したりしてよいファイルやデータの属するファイルのリストを予め正規表現などで指定しておき、またアクセスしてよい外部サイトのドメインを正規表現などで予め指定しておき、外部への送信や表示時にこれらのリストをチェックすることで、ユーザスクリプトによる悪意ある情報流出を防ぐ方法が考えられる。

具体的には、外部への送信に関して、JavaScriptの場合であれば、XMLHttpRequestなどの外部にアクセスする関数で渡されるデータやアクセス先をチェックしたり、JSONPといわれる手法で利用されるｓｃｒｉｐｔタグのｓｒｃを事前にチェックし、予め登録されていないドメインに対するものであれば不許可とする、書き換えて無効化するなどの方法で実現可能である。実行時に読み込まれるスクリプトに関しても、ルール解釈実行部で予め読み込まれるスクリプトを取得し、前述のチェックを行うことは可能である。

また、外部への情報送信だけに限定せず、より汎用的なリスクに適用できる手法としては、Ｃａｊａ（例えば、Caja: Google Developers、「https://developers.google.com/caja/」参照）などの手法を活用して、危険性のあるコード部分は無効化する、といった手法も選択可能であるし、Ｃａｊａなどをそのまま利用することも可能である。Ｃａｊａを使う場合は、ＵＲＩ Ｐｏｌｉｃｙを指定することで、外向きのアクセスをドメインとポートを指定して許可もしくは不許可とすることが可能であるし、その他のリスクへの対応も可能である。

（プロキシサーバを活用した形態におけるＳＳＬ（Secure Sockets Layer）対応）
プロキシサーバ１０を活用した形態において、ＳＳＬにより途中の通信内容が暗号化されているケースでは、適用に工夫が必要である。このような場合には、図１７に例示するように例えば、リバース型のプロキシサーバ１０を配置し、その手前もしくはプロキシサーバ１０内部にＳＳＬ終端機能を有するＳＳＬ終端装置（例えば、ロードバランサーなど）５０を配置し、ＳＳＬ終端機能でＳＳＬを一旦終端させることで、回避可能である。この場合、ＳＳＬ終端機能とＷｅｂサーバ３０間の通信は暗号化がなされないことから、必要に応じて内側のネットワークは閉域網を利用するなど、エンドツーエンドの通信の安全性を担保する。もしくは、プロキシサーバ１０もしくはＳＳＬ終端装置５０を起点に、Ｗｅｂサーバ３０との間をＨＴＴＰＳ通信とする、といった手法も可能である。

（システム構成等）
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（プログラム）
また、上記実施形態において説明した機能拡張システムが実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態に係る機能拡張システムにおける各装置（プロキシサーバ１０や端末２０）が実行する処理をコンピュータが実行可能な言語で記述した機能拡張プログラムを作成することもできる。この場合、コンピュータが機能拡張プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる機能拡張プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された機能拡張プログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。

図１８は、機能拡張プログラムを実行するコンピュータ１０００を示す図である。図１８に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図１８に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１８に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、図１８に例示するように、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、図１８に例示するように、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、図１８に例示するように、例えばディスプレイ１１３０に接続される。

ここで、図１８に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の機能拡張プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０９０に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。

なお、機能拡張プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、機能拡張プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

上記の実施形態やその変形は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１０ プロキシサーバ
１１ 追加部
２０ 端末
２１ Ｗｅｂブラウザ
２２ ＯＳ
２３ 入力デバイス
２４ ディスプレイ
３０ Ｗｅｂサーバ
４０ ブラウザアドオン
５０ ＳＳＬ終端装置

Claims (6)

1. ブラウザを動作させる端末と、該端末と通信を行うサーバとを有する機能拡張システムであって、
   前記サーバから前記ブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加部と、
   前記追加部によって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行部と
   を備えることを特徴とする機能拡張システム。
2. 前記追加部は、アプリケーションの変化を検知するコードと、前記アプリケーションの変化に応じて前記ルールを解釈して実行するコードとをさらに前記メッセージに追加し、
   前記実行部は、前記追加部によって追加された各コードを前記ブラウザ上で実行し、アプリケーションの変化を検知した場合には、該変化に応じて前記ルールファイルを再度解釈して、前記ユーザインタフェース機能を拡張することを特徴とする請求項１に記載の機能拡張システム。
3. 前記実行部は、監視すべきイベントを指定するリストと監視すべきでないイベントを指定するリストを参照し、監視すべきイベントを指定するリストに記載されたイベントによりアプリケーションの変化を検知した場合に該変化に応じて前記ルールファイルを再度解釈して、前記ユーザインタフェース機能を拡張することを特徴とする請求項２に記載の機能拡張システム。
4. 前記実行部は、予め決められたファイル以外の情報を、予め決められた外部サイト以外へ前記ブラウザが送信することを中止することを特徴とする請求項１に記載の機能拡張システム。
5. ブラウザを動作させる端末と、該端末と通信を行うサーバとを有する機能拡張システムによって実行される機能拡張方法であって、
   前記サーバから前記ブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加工程と、
   前記追加工程によって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行工程と
   を含んだことを特徴とする機能拡張方法。
6. 端末と通信を行うサーバから前記端末上で動作するブラウザに至るまでの経路上で、前記サーバから前記端末宛てに送信されたメッセージを取得し、ユーザインタフェースを拡張するルールが規定されたルールファイルと、前記ルールを解釈して実行するコードとを前記メッセージに追加する追加ステップと、
   前記追加ステップによって追加されたコードを前記ブラウザ上で実行して、前記ルールファイルを解釈し、該ルールファイルに基づいて、前記ブラウザによって表示される画面上のユーザインタフェース機能を拡張する実行ステップと
   をコンピュータに実行させることを特徴とする機能拡張プログラム。

Images