JP2021009492A - クライアント装置及びサーバ装置及びそれらの制御方法及びプログラム、並びに、リモートブラウザシステム - Google Patents

Abstract

【課題】パスワードなどの所定の種類の情報をウェブサーバに送信する必要がある場合、リモートブラウザサーバを経由することなく、ウェブサーバに送信してウェブの閲覧を継続できるようにするクライアント装置、サーバ装置及びそれらの制御方法、プログラム、リモートブラウザシステムを提供する。【解決手段】リモートブラウザクライアントとして機能するクライアント装置３０１は、予め設定された種類の情報の入力を促す状態になったことをリモートブラウザサーバとして機能するサーバ装置３０２から受信した場合、それに対してユーザより入力した情報を保存し、サーバ装置がアクセスしているウェブサーバへのリクエスト送信が必要であることを示す通知及びそのリクエストのパラメータを受け取り、パラメータと保存された情報とを組み合わせて新たなリクエストを生成し、ウェブサーバに送信し、そのレスポンスを受け取り、レスポンスをサーバ装置に転送する。【選択図】図５

Description

本発明は、ウェブページの閲覧技術に関するものである。

近年、多くのネットワークサービスがウェブアプリケーションとして公開されるようになっている。以前は、ウェブアプリケーションの利用にはＰＣ上のウェブブラウザを使うのが一般的だったが、最近ではＰＣ以外の機器から直接使うという要望が高まっており、例えば多くのスマートフォンはウェブブラウザ（以下ブラウザ）の機能を有している。

しかし、ウェブブラウザの機能は非常に多く、汎用性の高いブラウザはＣＰＵやメモリなどの計算機資源への要求が高い。そのため、デジタルカメラやプリンタなどといった計算機資源の乏しい機器にブラウザを搭載するのは困難である。そのため、小型機器でブラウザを動作させる場合は機能の制限されたブラウザが使われることが多い。しかし、そのようなブラウザは、ウェブ標準仕様を完全には満たさないため、ウェブページがうまく表示されない、あるいはウェブアプリケーションを正しく動作させることができないなどの問題が起きる。

低リソース機器でウェブページを閲覧するもう一つの方法として、ブラウザの機能の基本部分を別の機器で行う方法がある。つまり、計算リソースの少ないクライアントでブラウザを動作させるのではなく、ネットワーク上に接続された別の機器（以下リモートブラウザサーバと呼ぶ）でブラウザを実行させてウェブページを描画し、その描画結果の画像を受けとって表示するよう構成するものである。このようにすれば、少ない計算リソースしか有さないクライアントであっても、本来のウェブページを表示できる。また、クライアントの入力情報（キーボード、マウス、タッチパネルなどの入力イベント）をリモートブラウザサーバに送信し、そこで動くブラウザに渡せば、ブラウザの操作も可能になり、あたかもクライアント上でブラウザが動いているように見せることができる。

しかし、パスワード入力を伴うウェブサイトを利用する場合、この方法にはセキュリティ上のリスクがある。ウェブサイトがパスワード入力を要求する場合、ユーザはクライアント機器の入力装置を使ってパスワードを入力することになる。入力装置がキーボードであれば、ユーザはそのウェブサイトのパスワードをキーボードで入力する。そのキー入力情報はクラウドブラウザに送られ、そこで動くブラウザに入力される。つまり、ウェブサイトのパスワードがそのままクラウドブラウザに渡されることになる。あるシステムのパスワードを、無関係な別のサービスにそのまま送るというのは、セキュリティ上好ましくないのは明らかである。

このような、ブラウザエンジンが動作する装置と入力・表示を行う装置を分離して動作するシステムにおいて機密情報も渡されてしまうという問題に対して、機密情報をマスクするという方式がある（特許文献１）。

特許第４９２３０５３号公報

しかしながら、上記従来技術はサーバ側にとっての機密情報をクライアントに送らないようにするために描画結果からマスクするものであり、クライアント側（つまりクライアントを操作するユーザ）の機密情報に対する技術ではない。従来技術と同様に、クライアントからサーバに送られる機密情報を変更してしまうと、サーバはその変更された機密情報を使って処理を続けることになる。つまり先の例においては、ウェブサーバに対してユーザが入力したものではないパスワードを送ることになり、想定した動作ではなくなってしまうという問題がある。

本発明はかかる問題に鑑み成されたものであり、パスワードなどの所定の種類の情報をウェブサーバに送信する必要がある場合であっても、リモートブラウザクライアントからリモートブラウザサーバにその情報を送ることなくウェブの閲覧を継続する技術を提供しようとするものである。

この課題を解決するため、例えば本発明のクライアント装置は以下の構成を備える。すなわち、
ネットワーク上のサーバ装置にて動作するブラウザエンジンの描画結果の画像を受け取って表示し、ユーザによる操作に応じた入力情報を前記サーバ装置に送信することで、ウェブページを閲覧・操作するリモートブラウザクライアントとして機能するクライアント装置であって、
所定の種類の情報の入力を促す状態になったこと前記サーバ装置から受信した場合、それに対してユーザより入力した情報をサーバ装置に送ることなく、保持する保持手段と、
前記サーバ装置がアクセスしているウェブサーバへのリクエスト送信が必要であることを示す通知、及び、そのリクエストのパラメータを受け取る受信手段と、
前記受信手段によって受信したパラメータと、前記保持手段によって保存された情報とを組み合わせて新たなリクエストを生成する作成手段と、
前記作成手段によって作成された新たなリクエストを、ウェブサーバに送信し、そのレスポンスを受け取るウェブ通信手段と、
前記ウェブ通信手段によって得られたレスポンスを前記サーバ装置に転送する転送手段とを有する。

本発明によれば、パスワードなどの所定の種類の情報をウェブサーバに送信する必要がある場合であっても、リモートブラウザクライアントからリモートブラウザサーバにその情報を送ることなくウェブの閲覧を継続できる。

リモートブラウザクライアント装置のハードウェア構成図。 リモートブラウザサーバ装置のハードウェア構成図。 リモートブラウザシステムのネットワーク構成図。 リモートブラウザシステムの表示部の表示画面の例を示す図。 リモートブラウザシステムのソフトウェア構成図。 パスワード入力フォームを持つウェブページのＨＴＭＬの記述例を示す図。 パスワード入力を行う場合の画面遷移図。 リモートブラウザサーバのパスワード入力メッセージ送信処理のフローチャート。 リモートブラウザクライアントのパスワード入力・保存処理のフローチャート。 パスワード入力フォームを持つフォームを送信する際のパラメータの例を示す図。 リモートブラウザサーバのリクエストチェック・転送処理のフローチャート。 リモートブラウザクライアントのリクエスト送信処理のフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

図１は、本実施形態であるリモートブラウザシステムのクライアント（以下ＲＢクライアント）のハードウェア構成図を示す。図２は、実施形態におけるリモートブラウザシステムのサーバ（以下、ＲＢサーバと呼ぶ）のハードウェア構成図を示す。

ＲＢクライアントは、装置の各処理部を繋ぐバス１００と、装置全体を制御するＣＰＵ（Central Processing Unit）１０１、変更を必要としないプログラムやパラメータ格納するＲＯＭ（Read Only Memory）１０２、外部記憶部などから供給されるプログラムデータを一時記憶するＲＡＭ（Random Access Memory）１０３を有する。また、ＲＢクライアントは、本装置に固定して設置されたハードディスク、着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ Ｄｉｓｃ（ＣＤ）などの光ディスク、磁気カードなどを含む外部記憶１０４、ネットワーク上の他の機器とデータの送受信を行うネットワークインターフェース１０５、画像や文字などを表示する液晶ディスプレイなどの表示部１０６、及び、ユーザが操作を行うためのキーボード、マウス、タッチパネルなどの操作部１０７を有する。

ここで、ネットワークインタフェース１０５は、有線、無線を問わない。また、タッチパネルは表示部１０６の表示面上に設けられるものであり、ユーザは画面を見ながら指でタッチすることで、表示されたメニューに対する選択等が行える。

図２のＲＢサーバにおける参照符号２００乃至２０５は、機能的には図１の参照符号１００乃至１０５と同じである。ただし、ＲＢサーバは、ウェブ標準仕様を満たすに十分な計算リソースを有するのに対し、ＲＢクライアントはＲＢサーバで生成したウエブページの画像を受信し表示する程度の計算リソースしか有さない。

リモートブラウザシステムのネットワーク構成を図３に示す。ＲＢクライアント３０１（図１）、ＲＢサーバ３０２（図２）、及び、ウェブサーバ３０３はネットワーク３０４で接続され、相互に通信可能になっている。なお、ウェブサーバ３０３は一般的なウェブサーバであれば良く、その構成や処理の詳細については記載しない。

上記構成にいて、ＲＢサーバ３０２が、ＲＢクライアント３０１からの要求に従って、ウェブサーバ３０３にアクセスして、受信したウェブ記述ファイル（ｈｔｍｌファイル）を解釈しウェブページの表示用の「画像」を生成する。そしてＲＢサーバ３０２は、生成した「画像」をＲＢクライアント３０１に送信する。ＲＢクライアント３０１は、ウェブ記述ファイルの解釈、実行すること無しに、ＲＢサーバ３０２から受信した「画像」を表示部１０６に表示するという単純な処理を行うことになる。以下、図４、図５を参照して、リモートブラウザシステムの動作をより詳しく説明する。

図４はＲＢクライアント３０１の表示部１０６に表示される画面の例である。画面上部にアドレスバー４０１、戻るボタン４０２、進むボタン４０３が入りされる。また、４０４はウェブページの表示領域である。ユーザはこの画面に対して操作部１０７を操作することになる。

図５はリモートブラウザシステムのソフトウェアモジュール構成と主なデータの流れを示す図である。参照符号“５ａ”で始まる処理はＲＢクライアント３０１におけるＣＰＵ１０１の処理を示す。また、参照符号“５ｂ”で始まる処理はＲＢサーバ３０２のＣＰＵ２０１の処理を示す。そして、ＲＢクライアント３０１、Ｒｂサーバ３０２、及び、ウェブサーバ３０３間を結ぶ線は、それぞれの装置が接続しているネットワーク３０４を介したネットワーク通信を示している。

ユーザがＲＢクライアント３０１の画面を見ながら、操作部１０７を介して何らかの操作を行うと、入力イベント送信部５ａ０２はその操作の種類に応じたメッセージを、ネットワークインタフェース１０５を介してＲＢサーバ３０２のメッセージ処理部５ｂ０２に送信する。具体的な操作は、アドレスバーへの入力、戻るボタン押下、進むボタン押下、表示領域への入力の４種類に分けられる。アドレスバー４０１にＵＲＬがされた場合、入力イベント処理部５ａ０２は、そのＵＲＬをロードすることを命令するＬｏａｄＵＲＬメッセージを送信する。また、戻るボタン４０２が押されたときは、ブラウザの表示履歴を使って１つ前のページに戻ることを命令するＧｏＢａｃｋメッセージを送信する。同様に、進むボタンが押されたときは履歴を１つ進むＧｏＦｏｒｗａｒｄメッセージを送信する。

また、表示領域への入力はさらにマウスイベントメッセージとキーボードイベントメッセージがある。表示領域内でマウスカーソルが移動された／ボタンが押された／ボタンが離されたときはそれぞれＭｏｕｓｅＭｏｖｅ、ＭｏｕｓｅＤｏｗｎ、ＭｏｕｓｅＵｐメッセージを送り、マウスの座標値や押されたボタンの種類を通知する。キーボードのキーが押された／離されたときはＫｅｙＰｒｅｓｓ、ＫｅｙＲｅｌｅａｓｅメッセージを送る。

ＲＢサーバ３０１のメッセージ処理部５ｂ０２は、受け取ったメッセージをブラウザエンジン５ｂ０３に渡す。ブラウザエンジンはウェブサーバからウェブページのデータ（ＨＴＭＬ、ＣＳＳ、ＪａｖａＳｃｒｉｐｔ、画像ファイルなど）を取得してページを描画するものである。一般的なウェブブラウザアプリケーションとは異なり、他のソフトウェアモジュールから操作するためのＡＰＩ（Application Programming Interface）を提供する。ブラウザエンジンには例えばＷｅｂＫｉｔＧＴＫ＋ Ｔｅａｍが提供するＷｅｂＫｉｔＧＴＫ（http://webkitgtk.org）や、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）に含まれるＣＨｔｍｌＶｉｅｗなどがある。ブラウザエンジンはＬｏａｄＵＲＬやＧｏＢａｃｋなど、リモートブラウザクライアントから送られるメッセージと同等のＡＰＩを持ち、メッセージ処理部５ｂ０２は単に対応するＡＰＩを呼び出すことでブラウザエンジンを制御できる。

ブラウザエンジン５ｂ０３はウェブサーバとの通信やページの描画を行うが、より正確には、実際の通信・描画処理は別のモジュールが行う。ネットワーク通信が必要な場合、ブラウザエンジン５ｂ０３はＨＴＴＰ（またはＨＴＴＰＳ）リクエストのパラメータ（送信先ＵＲＬやリクエストヘッダの情報など）をＨＴＴＰクライアント５ｂ０６に渡し、実際の通信はＨＴＴＰクライアントが行う。描画処理については、２Ｄグラフィックスライブラリ５ｂ０４が直線、ベジェ曲線、文字といった２Ｄグラフィックスプリミティブのレンダリング機能を提供し、ブラウザエンジンは２Ｄグラフィックスライブラリに対する描画命令を発行する。

また、ブラウザエンジン５ｂ０３は特定の状況が発生もしくはその状況を検出したときに、それを他のソフトウェアモジュールに通知する仕組みを持つ。例えば、ウェブページの遷移などによりページがロードされたとき、表示しているページの特定の要素がフォーカスされたとき、ネットワークリクエストが発生したときなどである。ＷｅｂＫｉｔＧＴＫでは、ＷｅｂＫｉｔＷｅｂＶｉｅｗのｌｏａｄ−ｃｈａｎｇｅｄシグナルでページのロード状態が変化したことの通知を受けることができる。また、フォーカスを監視したい要素に対してｗｅｂｋｉｔ＿ｄｏｍ＿ｅｖｅｎｔ＿ｔａｒｇｅｔ＿ａｄｄ＿ｅｖｅｎｔ＿ｌｉｓｔｅｎｅｒ関数を使うことで通知を受けることができる。ネットワークリクエストの発生についてはＷｅｂＫｉｔＷｅｂＰａｇｅのｓｅｎｄ−ｒｅｑｕｅｓｔシグナルによって、そのリクエストの情報をコールバック関数で受け取ることができる。さらに、そのコールバック関数の戻り値によって、そのリクエストを実際に送るかどうかを制御することが可能である。フォームチェック部５ｂ０１とリクエスト転送部５ｂ０７は、これらの機能を利用して特定の要素へのフォーカスと、ネットワークリクエストを監視する。これら処理については後述する。

２Ｄグラフィックスライブラリ５ｂ０４が描画した結果である画像は画像転送部５ｂ０５に渡される。画像転送部５ｂ０５は、その画像をＲＢクライアント３０１の画像受信処理部５ａ０３に送信する。画像受信処理部５ａ０３は、受け取った画像を表示部１０６の画面中のウェブページ表示領域４０４内に表示する。このようにして、ＲＢサーバ３０２側で動作するブラウザエンジンの描画結果の画像をＲＢクライアントの表示部１０６で表示することができる。

次に、パスワードなどの機密情報が入力される場合の動作について説明する。例として、図６に示すＨＴＭＬによるログインページを用いる。このＨＴＭＬには、行６０１から始まるｆｏｒｍ要素がある。そして、このｆｏｒｍ要素の中には、ユーザ名入力用のテキスト入力フォームを示す行６０２と、パスワード入力フォームを示す行６０３、そしてこれらの情報をウェブサーバに送信するための送信ボタンを定義する行６０４が含まれている。なお、本実施形態の技術とは関係のない他の要素については、ここでの説明・表示を省略する。

上記のＨＴＭＬを表示すると、図７（ａ）のようになる（ここで、ユーザ名は入力した状態）。図示の参照符号７ａ０１〜７ａ０３はそれぞれ図６の行６０２〜６０４に対応する。

前述のとおり、ＲＢクライアント３０１側でユーザが何らかの操作を行うと、その操作に対応するメッセージがＲＢサーバ３０２に送られ、ブラウザエンジン５ｂ０３に渡される。メッセージがマウス・キーボードの入力メッセージの場合、ページ内でフォーカスされる要素が変化することがある。例えば、テキスト入力フォーム上にマウスを移動し、そこでクリックした場合、そのテキスト入力フォームがフォーカスされる。

ユーザがマウス・キーボードを操作すると、ページ中のフォーカスされた要素が変化することがあるが、フォームフォーカスチェック部５ｂ０１は、パスワード入力フォームにフォーカスされた場合に通知を受けるよう構成されている。

これは、以下のようにして実現できる。まず、ブラウザエンジン５ｂ０３が提供するロード状態変化通知機能を使い、ページがロードされたときに通知を受けるようにしておく。そして、ページロードの通知を受けたとき、そのページに含まれるパスワード入力フォームに対し、フォーカス通知機能をセットしておく。パスワード入力フォームはｔｙｐｅ属性が”ｐａｓｓｗｏｒｄ”であるｉｎｐｕｔ要素であることから判別できる。このようにしておけば、ブラウザエンジン５ｂ０３は、パスワード入力フォームがフォーカスされたとき、フォームフォーカスチェック部５ｂ０１にそれを通知できる。

パスワード入力フォームへのフォーカスが通知されたときのフォームフォーカスチェック部５ｂ０１の動作を図８に示す。

まず、フォームフォーカスチェック部５ｂ０１は、そのページ内におけるそのフォームの一意な識別子を生成する（Ｓ８０１）。もしｉｎｐｕｔ要素にｉｄ属性があればその値を利用できる。ない場合は、ランダムな文字列を生成し、そのｉｎｐｕｔ要素にｉｄ属性として追加することで代用できる。図６の行６０３のｉｎｐｕｔ要素はｉｄ属性があるため、その値である”ｐｗ１”がフォーム識別子となる。次にフォームフォーカスチェック部５ｂ０１は、生成されたフォーム識別子を付けてＲＢクライアント３０１にパスワード入力メッセージを送る（Ｓ８０２）。そのレスポンスとして文字列を受け取り（Ｓ８０３）、それをパスワード入力フォームに入力する（Ｓ８０４）。なお、ＲＢクライアント３０１側の動作については後述するが、この文字列は、ユーザが入力した正しいパスワードではない文字列である。そして、フォームフォーカスチェック部５ｂ０１は、その文字列とフォーム識別子の組み合わせを外部記憶部２０４に保存する（Ｓ８０４）。

Ｓ８０２で送られたパスワード入力メッセージは、ＲＢクライアント３０１のパスワード入力処理部５ａ０１が受信し、ユーザはパスワード入力を行うことになる。この処理の詳細を図９に示す。

まず、パスワード入力処理部５ａ０１は、パスワード入力ウィンドウを生成し、表示部１０６に表示し、ユーザにパスワードの入力を促す（Ｓ９０１）。図７（ｂ）の参照符号７ｂ０１が、このときの表示部１０６に表示されるパスワード入力を促すウィンドウである。このウィンドウ７ｂ０１は、ＲＢクライアント３０１で作成したウィンドウであり、ブラウザエンジンが作成したものではないことに注意されたい。ここにはパスワード入力フォーム７ｂ０２があり、ユーザはここにパスワードを入力する。ここではパスワードとして”ＭｙＰａｓｓｗｏｒｄ１”が入力されたとする。パスワード入力処理部５ａ０１は、このパスワードと送られたフォーム識別子を保持する（Ｓ９０２）。具体的には、パスワード入力処理部５ａ０１は、パスワードと送られたフォーム識別子を、外部記憶装置１０４に保存する。なお保存方法は単純なテキストファイルにすることや、リレーショナルデータベースを使うこともできる。また、外部記憶装置１０４ではなくＲＡＭ上にすることも可能である。

なお、このパスワード入力画面は一般的なウェブブラウザにはない機能であるため、ユーザの混乱を招く可能性がある。そのため、パスワード入力処理部５ａ０１は、参照符号７ｂ０３のように、一般的なウェブブラウザとは異なる処理を行っていることをユーザに通知するメッセージを含むウインドウ７ｂ０１を生成することが望ましい。

パスワードを保存後、パスワード入力処理部５ａ０１は、ダミー情報をＲＢサーバ３０１に送る（Ｓ９０３）。このとき送信するダミー情報は、入力されたパスワードと同じ文字数のダミー文字列とする。これはＳ８０４でブラウザエンジンに入力される。

ダミー文字列を入力する第一の理由は、ユーザにとって違和感のない見た目を提供することである。通常、ユーザがパスワード入力フォームに入力すると、そのフォーム内にパスワードを構成する文字の代替シンボル（例えば点）として表示される。もし、Ｓ８０４の処理を行わないと、フォーム内が空のままとなり、ユーザを混乱させる恐れがある。

ダミー文字列を入力する第二の理由は、ＪａｖａＳｃｒｉｐｔによるチェックを通過させるためである。ウェブサイトによっては、ＪａｖａＳｃｒｉｐｔを使って、入力されたパスワードをブラウザ側でチェックする構成になっており、パスワードが空の場合などにエラーメッセージを出すようになっている。そのため、空ではない何らかの文字列を入れておかないとその後の動作が妨げられてしまう。

ダミー文字列は本当のパスワードとは無関係のものであれば良く、ランダムな文字列でも良い。第一の理由のためには、文字列の長さは本当のパスワードと同じ長さであることが望ましい。そうすれば、図７（ｃ）のように１１個の点が表示され、本当のパスワードを入れた場合と同じ見た目になる。また、第二の理由への対応として、使われる文字の種類（大文字・小文字・数字・記号など）を合わせるのが良い。ＪａｖａＳｃｒｉｐｔがパスワードをチェックする場合、文字の種類の規則（大文字・小文字・数字を少なくとも１つ以上含むこと、など）をチェックすることが多いためである。従って、“ＭｙＰａｓｓｗｏｒｄ１”に対して生成されるダミー文字列は、例えば”ＦｌＵｚｏｖｍｅｔｖ５”となる。このダミー文字列がＲＢサーバ３０２に返される。なお、この段階では、ＲＢサーバ３０２に渡されたのはダミー文字列のみであり、本当のパスワードは送られていないことに注意されたい。

ユーザ名とパスワードの入力後、ユーザは画面上のＳｕｂｍｉｔボタンを押す、つまりＳｕｂｍｉｔボタンのある位置でマウスをクリックする。この場合もその入力イベントはＭｏｕｓｅＤｏｗｎ、ＭｏｕｓｅＵｐメッセージとしてブラウザエンジン５ｂ０３に渡される。Ｓｕｂｍｉｔボタンが押されたときの処理は、そのＳｕｂｍｉｔボタンを含むｆｏｒｍ要素の指定に従う。ａｃｔｉｏｎ属性によって送信先ＵＲＬが指定され、ｍｅｔｈｏｄ属性によってＨＴＴＰメソッドが指定される。この例では行６０１のｆｏｒｍ要素であるため、フォームの内容がｐｒｏｃ−ｌｏｇｉｎ．ｃｇｉにＰＯＳＴメソッドによって送信される。より具体的には、ブラウザエンジン５ｂ０３は、図１０に示すパラメータを生成し、それをＨＴＴＰクライアント５ｂ０６に渡すことでウェブサーバに送る。

ただし前述したとおり、ブラウザエンジンが生成するネットワークリクエストは、実際にＨＴＴＰクライアント５ｂ０６に渡される前に、コールバック関数としてリクエスト転送部５ｂ０７に渡される。このコールバック関数は引数としてそのリクエストのパラメータ、つまり図１０の情報を持つ。また、戻り値はブール型である、ＦＡＬＳＥを返すと字際のウェブサーバへのリクエスト送信が行われ、ＴＲＵＥを返すとそのリクエストはキャンセルされ、ウェブサーバには送られなくなる。

このネットワーク送信前通知を受け取ったときのリクエスト転送部５ｂ０７の処理を図１１に示すフローチャートを参照して説明する。

まず、Ｓ１１０１にて、リクエスト転送部５ｂ０７は、Ｓ８０５において保存されたダミー文字列がリクエストパラメータ中にあるかどうかを調べる。ない場合、つまりこのリクエストがパスワードに関する情報を含まない場合は、リクエスト転送部５ｂ０７は処理をＳ１１０２に進め、ブラウザエンジン５ｂ０３にＦＡＬＳＥを返して終了する。ＦＡＬＳＥを返すということは、このリクエストはそのままＨＴＴＰクライアント５ｂ０６に渡されてウェブサーバに３０３に送られ、ブラウザエンジン５ｂ０３はそのレスポンスを得ることになる。

もしダミー文字列と同じものがある場合、リクエスト転送部５ｂ０７は、Ｓ１１０３にて、リクエストパラメータ中のダミー文字列をプレースホルダで置き換える。プレースホルダは、後でその箇所を変更する目印となるもので、ここでは“＃｛ｐｌａｃｅｈｏｌｅｒ 識別子｝”、という形式とする。つまり、パラメータＰＯＳＴ Ｄａｔａ２の値は“ｐａｓｓｗｏｒｄ１＝＃｛ｐｌａｃｅｈｏｌｄｅｒ ｐｗ１｝”となる。次に、リクエスト転送部５ｂ０７は、このパラメータリストとともに、リクエスト代理処理メッセージをＲＢクライアント３０１に送信し（Ｓ１１０４）、ＲＢクライアント３０１からそのレスポンスを受け取る（Ｓ１１０５）。そして、リクエスト転送部５ｂ０７は、そのレスポンスをブラウザエンジン５ｂ０３に渡す（Ｓ１１０６）。このレスポンスの内容については後述するが、これはＨＴＭＬなどを含むＨＴＴＰレスポンスであり、渡されたブラウザエンジン５ｂ０３は、図１０のリクエストに対するレスポンスとして処理を続行できる。最後に、リクエスト転送部５ｂ０７は、保存したダミー文字列と識別子を削除した後（Ｓ１１０７）、ブラウザエンジン５ｂ０７に対してＴＲＵＥを返し、リクエストが直接ウェブサーバ３０３に送られるのを防ぐ（Ｓ１１０８）。この結果、ブラウザエンジン５ｂ０３が送ろうとするＨＴＴＰリクエストパラメータ中にパスワード情報がある場合、そのリクエストに対するレスポンスはＲＢクライアント３０１から受け取り、そうでなければ直接ウェブサーバから取得することになる。なお、Ｓ１１０７でダミー文字列と識別子を削除するのは、別のページにパスワード入力フォームがあった場合の誤動作を防ぐためである。

リクエスト代理処理メッセージは、ＲＢクライアント３０１のＨＴＴＰ代理処理部５ａ０４が受信して処理する。この処理の詳細を図１２のフローチャートにしたがって説明する。

まず、ＨＴＴＰ代理処理部５ａ０４は、パラメータリスト中のプレースホルダを探し、そこにある識別子を得る（Ｓ１２０１）。この例では、”ｐｗ１”である。次に、ＨＴＴＰ代理処理部５ａ０４は、その識別子に対応するパスワードをパスワードリストから探す（Ｓ１２０２）。パスワードリストはＳ９０２の処理で作られているものである。実施形態の場合、ＨＴＴＰ代理処理部５ａ０４は、識別子”ｐｗ１”に対応するパスワード”ｍｙｐａｓｓｗｏｒｄ１”を得ることになる。

次に、ＨＴＴＰ代理処理部５ａ０４は、パラメータリスト中のプレースホルダをそのパスワードで置き換える（Ｓ１２０３）。これにより、本来送られるべきリクエストを構築することができる。得られたパラメータリストを基に、ＨＴＴＰ代理処理部５ａ０４は、ウェブ通信部として機能するＨＴＴＰクライアント通知５ａ０５を使ってウェブサーバ３０３にリクエストを送り、レスポンスを受信する（Ｓ１２０４）。最後に、ＨＴＴＰ代理処理部５ａ０４は、受信したレスポンスをＲＢサーバ３０２に送信して終了する（Ｓ１２０５）。このレスポンスは、ＨＴＴＰヘッダ及びボディをすべて含む。Ｓ１２０４でウェブサーバに送られたリクエストは、ＲＢサーバ３０２のブラウザエンジン５ｂ０３が生成したパラメータを基に、パスワード部分のみユーザが入力した正しいパスワードとなったものである。従って、このリクエストは、リモートブラウザシステムではない通常のブラウザを使用した場合と同一の内容になり、ウェブサーバは正しく処理することができる。また、ウェブサーバのレスポンスを、ヘッダも含めてすべてＲＢサーバ３０２に転送してブラウザエンジンに渡すため、ブラウザエンジンもリモートブラウザシステムでない場合と全く同じ振る舞いになる。これにより、以降のページの閲覧・操作時は問題なく行うことができる。

以上のようにして、パスワードを送信する必要があるウェブサイトを、ＲＢサーバ３０２にパスワードを送ることなく閲覧することが可能になる。

なお、上述したＲＢサーバ３０２のブラウザエンジン５ｂ０３は、ｈｔｍｌファイルの行６０３に記述の文字列“ｐａｓｓｗｏｒｄ”の有無から機密文書であるか否かの判定を行ったが、要は機密を必要とする所定の種類の情報の入力があるか否かが判定できれば良い。例えば、パスワード以外としては、金融機関の口座番号等、様々である。それ故、かかる判定処理として、機械学習された学習済みモデルを代わりに用いて処理しても良い。その場合には、例えば、その処理部への入力データと出力データとの組合せを学習データとして複数個準備し、それらから機械学習によって知識を獲得し、獲得した知識に基づいて入力データに対する出力データを結果として出力する学習済みモデルを生成する。学習済みモデルは、例えばニューラルネットワークモデルで構成可能である。そして、その学習済みモデルは、前記処理部と同等の処理をするためのプログラムとして、ＣＰＵあるいはＧＰＵなどと協働で動作することにより、前記処理部の処理を行う。なお、上記学習済みモデルは、必要に応じて一定の処理後に更新しても良い。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００、２００…バス、１０１、２０１…ＣＰＵ、１０２、２０２…ＲＯＭ、１０３、２０３…ＲＡＭ、１０４、２０４…外部記憶装置、１０５、２０５…ネットワークインタフェース、１０６…表示部、１０７…操作部

Claims (10)

1. ネットワーク上のサーバ装置にて動作するブラウザエンジンの描画結果の画像を受け取って表示し、ユーザによる操作に応じた入力情報を前記サーバ装置に送信することで、ウェブページを閲覧・操作するリモートブラウザクライアントとして機能するクライアント装置であって、
   所定の種類の情報の入力を促す状態になったこと前記サーバ装置から受信した場合、それに対してユーザより入力した情報をサーバ装置に送ることなく、保持する保持手段と、
   前記サーバ装置がアクセスしているウェブサーバへのリクエスト送信が必要であることを示す通知、及び、そのリクエストのパラメータを受け取る受信手段と、
   前記受信手段によって受信したパラメータと、前記保持手段によって保存された情報とを組み合わせて新たなリクエストを生成する作成手段と、
   前記作成手段によって作成された新たなリクエストを、ウェブサーバに送信し、そのレスポンスを受け取るウェブ通信手段と、
   前記ウェブ通信手段によって得られたレスポンスを前記サーバ装置に転送する転送手段と、
   を有することを特徴とするクライアント装置。
2. 前記保持手段は、ユーザから入力された情報に代わる、ダミー情報を生成し、前記サーバ装置に送信する手段を含む
   ことを特徴とする請求項１に記載のクライアント装置。
3. 前記保持手段は、ユーザによる入力が前記サーバ装置には送信されないことを示すメッセージを表示しつつ、ユーザに対して入力を促すことを特徴とする請求項１又は２に記載のクライアント装置。
4. 前記所定の種類の情報は、パスワードを含む機密に係る情報であることを特徴とする請求項１乃至３のいずれか１項に記載のクライアント装置。
5. ウェブサーバにアクセスし、ブラウザエンジンによる描画結果の画像をクライアント装置に送信すると共に、当該クライアント装置から入力情報を受け取り、その入力情報を使ってブラウザエンジンを操作することで、クライアント装置に対してウェブページの閲覧に係る操作を可能にするリモートブラウザサーバとして機能するサーバ装置であって、
   ウェブサーバから受信したウェブページに、所定の種類の情報の入力を促す入力フォームの記述がある場合、その入力フォームが前記クライアント装置にてフォーカスされたことを検出する検出手段と、
   該検出手段により前記所定の種類の情報の入力フォームがフォーカスされた場合、所定の入力を行うように前記クライアント装置に通知する通知手段と、
   ブラウザエンジンからウェブサーバに送られるネットワークリクエストのパラメータ中に、前記入力フォームに入力された情報が含まれるかを判定する判定手段と、
   該判定手段によって、ネットワークリクエストのパラメータ中に前記入力フォームに入力された情報が含まれると判定された場合、そのリクエストをウェブサーバに送ることなく、そのパラメータを前記クライアント装置に送る送信手段と、
   前記送信手段で送信したリクエストに対するレスポンスを、前記クライアント装置から受け取り、そのレスポンスを使ってブラウザエンジンを動作させる受信手段と、
   を有することを特徴とするサーバ装置。
6. 前記所定の種類の情報は、パスワードを含む機密に係る情報であることを特徴とする請求項５に記載のサーバ装置。
7. ブラウザエンジンを有し、当該ブラウザエンジンによる描画結果の画像をクライアント装置に送信することでリモートブラウザサーバとして機能するサーバ装置と、当該サーバ装置から受信した画像を表示すると共にユーザからの操作を前記サーバ装置に通知することでリモートブラウザクライアントとして機能するクライアント装置とを有するリモートブラウザシステムであって、
   前記クライアント装置は、
   所定の種類の情報の入力を促す状態になったこと前記サーバ装置から受信した場合、それに対してユーザより入力した情報をサーバ装置に送ることなく、保持する保持手段と、
   前記サーバ装置がアクセスしているウェブサーバへのリクエスト送信が必要であることを示す通知、及び、そのリクエストのパラメータを受け取る受信手段と、
   前記受信手段によって受信したパラメータと、前記保持手段によって保存された情報とを組み合わせて新たなリクエストを生成する作成手段と、
   前記作成手段によって作成された新たなリクエストを、ウェブサーバに送信し、そのレスポンスを受け取るウェブ通信手段と、
   前記ウェブ通信手段によって得られたレスポンスを前記サーバ装置に転送する転送手段とを有し、
   前記サーバ装置は、
   ウェブサーバから受信したウェブページに、所定の種類の情報の入力を促す入力フォームの記述がある場合、その入力フォームが前記クライアント装置にてフォーカスされたことを検出する検出手段と、
   該検出手段により前記所定の種類の情報の入力フォームがフォーカスされた場合、所定の入力を行うように前記クライアント装置の前記保持手段に向けて通知する通知手段と、
   ブラウザエンジンからウェブサーバに送られるネットワークリクエストのパラメータ中に、前記入力フォームに入力された情報が含まれるかを判定する判定手段と、
   該判定手段によって、ネットワークリクエストのパラメータ中に前記入力フォームに入力された情報が含まれると判定された場合、そのリクエストをウェブサーバに送ることなく、そのパラメータを前記クライアント装置の前記受信手段に送る送信手段と、
   前記送信手段で送信したリクエストに対するレスポンスを、前記クライアント装置の前記転送手段から受け取り、そのレスポンスを使ってブラウザエンジンを動作させる受信手段とを有する
   ことを特徴とするリモートブラウザシステム。
8. ネットワーク上のサーバ装置にて動作するブラウザエンジンの描画結果の画像を受け取って表示し、ユーザによる操作に応じた入力情報を前記サーバ装置に送信することで、ウェブページを閲覧・操作するリモートブラウザクライアントとして機能するクライアント装置の制御方法であって、
   所定の種類の情報の入力を促す状態になったこと前記サーバ装置から受信した場合、それに対してユーザより入力した情報をサーバ装置に送ることなく、保持する保持工程と、
   前記サーバ装置がアクセスしているウェブサーバへのリクエスト送信が必要であることを示す通知、及び、そのリクエストのパラメータを受け取る受信工程と、
   前記受信工程によって受信したパラメータと、前記保持工程によって保存された情報とを組み合わせて新たなリクエストを生成する作成工程と、
   前記作成工程によって作成された新たなリクエストを、ウェブサーバに送信し、そのレスポンスを受け取るウェブ通信工程と、
   前記ウェブ通信工程によって得られたレスポンスを前記サーバ装置に転送する転送工程と、
   を有することを特徴とするクライアント装置の制御方法。
9. ウェブサーバにアクセスし、ブラウザエンジンによる描画結果の画像をクライアント装置に送信すると共に、当該クライアント装置から入力情報を受け取り、その入力情報を使ってブラウザエンジンを操作することで、クライアント装置に対してウェブページの閲覧に係る操作を可能にするリモートブラウザサーバとして機能するサーバ装置の制御方法であって、
   ウェブサーバから受信したウェブページに、所定の種類の情報の入力を促す入力フォームの記述がある場合、その入力フォームが前記クライアント装置にてフォーカスされたことを検出する検出工程と、
   該検出工程により前記所定の種類の情報の入力フォームがフォーカスされた場合、所定の入力を行うように前記クライアント装置に通知する通知工程と、
   ブラウザエンジンからウェブサーバに送られるネットワークリクエストのパラメータ中に、前記入力フォームに入力された情報が含まれるかを判定する判定工程と、
   該判定工程によって、ネットワークリクエストのパラメータ中に前記入力フォームに入力された情報が含まれると判定された場合、そのリクエストをウェブサーバに送ることなく、そのパラメータを前記クライアント装置に送る送信工程と、
   前記送信工程で送信したリクエストに対するレスポンスを、前記クライアント装置から受け取り、そのレスポンスを使ってブラウザエンジンを動作させる受信工程と、
   を有することを特徴とするサーバ装置の制御方法。
10. コンピュータが読み込み実行することで、前記コンピュータに、請求項８又は９に記載の方法の各工程を実行させるためのプログラム。

Images