JP2009134489A - 文書データの表示を制御する装置及び方法 - Google Patents

Abstract

【課題】ある言語で記述された文書データをあるクライアントで表示する際に、その文書データに対応する別の言語で記述された文書データを別のクライアントで表示する。
【解決手段】エージェント２０において、ブラウザ管理部２１は、例えば日本語のページのＵＲＬを受信し、これを例えば英語のページのＵＲＬに変換する指示を生成する。また、ＵＲＬ生成部２３は、この指示に応じ、パターンルール記憶部２４に記憶されたパターンルールに基づいて、英語のページのＵＲＬを含むＵＲＬ候補リストを生成する。更に、要求／応答管理部２５は、日本語のページを取得すると共に、ＵＲＬ候補リストに含まれるＵＲＬの妥当性を検証し、妥当と判断されたＵＲＬに基づいて英語のページを取得する。そして最後に、ブラウザ管理部２１が、日本語のページを第１のクライアントに送信すると共に英語のページを第２のクライアントに送信する。
【選択図】図３

Description

本発明は、文書データを表示するために用いられる装置及び方法に関する。特に、本発明は、文書データの表示を制御する装置及び方法に関する。

従来より、Ｗｅｂブラウザにより表示されるコンテンツを同期させる技術が知られている（例えば、特許文献１、２参照）。
特許文献１では、複数のコンピュータ端末間でコンテンツの同期を行い表示する同期プログラムが、コンピュータ端末でコンテンツ表示要求を受けたとき、要求されたコンテンツが記憶されていなければ、そのコンピュータ端末以外のコンピュータ端末からコンテンツを受信して表示している。
また、特許文献２では、基準サイトの中から基準ページを特定し、基準ページの単語集合情報と、比較サイト中のＷｅｂページである各比較ページの単語集合情報との比較に基づいて、各比較ページの中から基準ページに類似する類似ページを特定し、類似ページを基準ページと同一画面に表示している。

国際公開第２００４／０７０６１６号パンフレット 特開２００５−２０２７６６号公報

ところで、昨今のグローバリゼーション化に伴い、このようなコンテンツの同期を異なる言語間で行いたいという要求がある。例えば、Ｗｅｂブラウザを用いて日本語のＷｅｂページを閲覧する際に、同じＷｅｂページを英語でも確認したい、といった要求である。
しかしながら、従来、ある言語で記述されたコンテンツと、そのコンテンツに対応する別の言語で記述されたコンテンツとを同期させる手法は存在しなかった。従って、日本語で閲覧していたＷｅｂページと同じＷｅｂページの英語版を閲覧する場合、次のような操作を行うしかなかった。即ち、まず、日本語のＷｅｂページを閲覧する作業の終了後、言語を英語に切り替えて同様の作業を行い、同じＷｅｂページの英語版コンテンツを見つける。そして、再び日本語を閲覧する場合は、言語を日本語に戻してアクセスし直す、といった操作である。また、日本語のＷｅｂページを遷移させる操作を行ったら、英語のＷｅｂページも同じ操作を行って遷移させなければならない。この際、実装の異なる複数のブラウザを用いれば、それぞれのブラウザに対して別々の言語設定を行うことができるので、言語設定を切り替える必要はなくなるが、それでも、遷移する操作をそれぞれのブラウザに対して行う必要がある。一度のことであればそれほど大きな作業ではないが、この作業を反復する必要がある場合には、大きな手間となっていた。
尚、同様の問題点は、Ｗｅｂページやコンテンツを表示する場合に限らず、一般の文書データを表示する場合においても指摘できる。

一方、特許文献１の技術は、全く同じコンテンツを異なるコンピュータ端末のＷｅｂブラウザで同期させるものであり、ある言語で記述されたコンテンツと、そのコンテンツに対応する別の言語で記述されたコンテンツとを同期させるものではない。
また、特許文献２の技術は、言語の異なる複数ページの比較閲覧を行うものであるが、これらの複数ページは、あくまで類似ページであって、ある言語である内容について記述されたページと別の言語で同じ内容について記述されたページといった関係にあるものではない。

本発明の目的は、ある言語で記述された文書データをあるクライアントで表示するのに同期して、その文書データに対応する別の言語で記述された文書データを別のクライアントで表示することにある。

かかる目的のもと、本発明は、文書データの表示を制御する装置であって、第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付ける受付部と、受付部により受け付けた第１の識別情報に基づいて、第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得する取得部と、取得部により取得された第２の識別情報に基づいて、第２の言語で記述された文書データを表示するための第２のクライアントが第２の文書データを表示するように制御する制御部とを備えた、装置を提供する。

ここで、取得部は、受付部により受け付けた第１の識別情報に含まれる第１の言語に関係する文字列を第２の言語に関係する文字列に置換する処理を行うことにより、第２の識別情報を取得する、ものであってよい。
また、取得部は、受付部により受け付けた第１の識別情報に対して置換する処理を行うことにより第２の識別情報の複数の候補を生成し、その複数の候補のうち、第２の文書データを取得するために使用可能な候補を第２の識別情報として取得する、ものであってよい。
更に、取得部は、複数の候補の各々に基づくアクセスを順次試みることにより、第２の文書データを取得するために使用可能な候補を特定する、ものであってよい。
更にまた、取得部は、受付部により受け付けた第１の識別情報を構成する各要素に対して置換する処理を行い、置換する処理が行われた後の各要素を組み合わせることにより、第２の識別情報を取得する、ものであってよい。
また、この装置は、第１のクライアントの識別子と第２のクライアントの識別子との対応情報を記憶する記憶部を更に備え、受付部は、第１のクライアントからその識別子を受け付け、制御部は、受付部により受け付けた第１のクライアントの識別子を用いて記憶部に記憶された対応情報を検索することにより得られた第２のクライアントの識別子に基づいて、第２のクライアントを特定する、ものであってよい。
更に、取得部は、第２の識別情報に基づいて第２の文書データを取得し、第２の文書データが取得されたことを示す特定情報を記憶部に記憶し、制御部は、第２のクライアントから第２の文書データの表示要求があった際に、記憶部に特定情報が記憶されていれば、第２のクライアントが第２の文書データを表示するように制御する、ものであってよい。
また、第１の識別情報は、第１の文書データの所在を示すＵＲＬ（Uniform Resource Locator）を含む、ものであってよい。
更に、第１の識別情報は、第１のクライアントが表示する文書データの言語を指定するために第１のクライアントに設定された言語指定情報を含み、取得部は、言語指定情報を第２の言語を指定するように書き換えることにより、第２の識別情報を取得する、ものであってよい。
更にまた、受付部は、第１のクライアントから第１の識別情報を受け付けたことに応じて第２のクライアントに所定の文書データが表示された後に、第２のクライアントから第２の識別情報を受け付け、取得部は、第１の識別情報に基づいて第２の識別情報を取得する際に用いる情報を、受付部が受け付けた第２の識別情報に基づいて更新する、ものであってよい。

また、本発明は、文書データの表示を制御する方法であって、第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付けるステップと、受け付けた第１の識別情報に基づいて、第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得するステップと、取得された第２の識別情報に基づいて、第２の言語で記述された文書データを表示するための第２のクライアントが第２の文書データを表示するように制御するステップとを含む、方法も提供する。

更に、本発明は、文書データの表示を制御する装置としてコンピュータを機能させるプログラムであって、コンピュータを、第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付ける受付部と、受付部により受け付けた第１の識別情報に基づいて、第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得する取得部と、取得部により取得された第２の識別情報に基づいて、第２の言語で記述された文書データを表示するための第２のクライアントが第２の文書データを表示するように制御する制御部として機能させる、プログラムも提供する。

本発明によれば、ある言語で記述された文書データをあるクライアントで表示するのに同期して、その文書データに対応する別の言語で記述された文書データを別のクライアントで表示することができる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、「実施の形態」という）について詳細に説明する。尚、本実施の形態では、ＨＴＴＰプロトコルを用いてＷｅｂページを表示する場合を前提に説明するが、これはあくまで例示であって、本発明を特定のプロトコルや特定の表示対象に限定するものではない。即ち、本実施の形態は、如何なる文書データを如何なるプロトコルを用いて表示する場合にも適用可能である。

まず、本実施の形態におけるコンピュータシステムについて説明する。
図１は、本実施の形態におけるコンピュータシステムの構成及び動作を示している。
図示するように、このコンピュータシステムは、主ブラウザ１１と、従ブラウザ１２と、エージェント２０と、Ｗｅｂサーバ３０とを含んでいる。

このうち、主ブラウザ１１は、Ｗｅｂブラウザを起動することで生成されるプロセスにより生成されるインスタンスであり、ユーザがある言語のＷｅｂページ（以下、単に「ページ」という）の表示や遷移のために操作するウィンドウ（以下、「主ブラウザウィンドウ」という）を表示する。
また、従ブラウザ１２は、Ｗｅｂブラウザを起動することで生成されるプロセスにより生成される主ブラウザ１１とは異なるインスタンスであり、主ブラウザウィンドウに表示されたページと同期させる別の言語のページを閲覧するためのウィンドウ（以下、「従ブラウザウィンドウ」という）を表示する。ここで、従ブラウザ１２は、１つしか図示していないが、複数存在していてもよい。

尚、主ブラウザ１１及び従ブラウザ１２は、同じコンピュータ端末で動作するものでも、異なるコンピュータ端末で動作するものでもよい。また、ここでは、同期させる２つのページを、別々のブラウザウィンドウに表示するようにしたが、これに限られるものではない。即ち、１つのブラウザウィンドウ内の複数の領域（例えば、タブ）に表示するようにしてもよい。このように、本実施の形態において、同期させるページは、異なるコンピュータ端末や、異なるブラウザウィンドウや、同じブラウザウィンドウ内の異なる領域に表示され得る。この場合、コンピュータ端末、ブラウザウィンドウ、ブラウザウィンドウ内の領域は、クライアントの一例であるということができる。

エージェント２０は、複数のブラウザ（ここでは、主ブラウザ１１及び従ブラウザ１２）を管理し、Ｗｅｂサーバ３０に対して必要なページを要求する。尚、エージェント２０は、主ブラウザ１１及び従ブラウザ１２の少なくとも何れか一方が動作するコンピュータ端末で動作するものでもよいし、このようなコンピュータ端末とは別のコンピュータで動作するものでもよい。
Ｗｅｂサーバ３０は、同じ内容について複数の言語で記述されたページを格納する１台のサーバであってもよいし、言語ごとにそれぞれ専用のサーバにページが格納される構成でもよい。本実施の形態では、物理的な構成の台数に関わらず、Ｗｅｂサーバ３０は論理的に１台で表現する。

このような構成を有するコンピュータシステムにおいて、本実施の形態は、次のような動作を行う。尚、ここでは、主ブラウザ１１が日本語のページを表示し、従ブラウザ１２が英語のページを表示するものとする。
まず、ユーザが、主ブラウザウィンドウを操作して、あるページの表示を要求すると、主ブラウザ１１は、エージェント２０に対してそのページを要求する（１）。これにより、エージェント２０は、Ｗｅｂサーバ３０に対して、日本語のページを要求する（２ａ）と共に、英語のページを要求する（２ｂ）。その結果、Ｗｅｂサーバ３０は、この要求に対する応答として、日本語のページを返す（３ａ）と共に、英語のページを返す（３ｂ）。すると、エージェント２０は、日本語のページは主ブラウザ１１に返信し（４ａ）、英語のページは従ブラウザ１２に返信する（４ｂ）。これにより、主ブラウザウィンドウには日本語のページが、従ブラウザウィンドウには英語のページが表示され、ページ間で同期がとられることになる。

ここで、図１の主ブラウザ１１又は従ブラウザ１２が表示するブラウザウィンドウについて説明する。
図２は、ブラウザウィンドウの表示イメージの例を示した図である。
まず、ブラウザウィンドウの上辺部には、通常のウィンドウでも見られるメニューバー１０１が表示される。
また、その下には、通常のブラウザウィンドウでも見られるように、ＵＲＬ（Uniform Resource Locator）を入力するためのアドレスバー１０２が表示される。本実施の形態では、このアドレスバー１０２のＵＲＬ入力欄に対し、エージェント２０のＵＲＬが入力されることになる。

更に、その下には、エージェント２０に対して情報を受け渡すためのカスタムツールバー１０３が表示される。そして、このカスタムツールバー１０３は、ＵＲＬ入力ボックス１０４と、送信ボタン１０５と、制御取得チェックボックス１０６と、言語選択リストボックス１０７とを含む。

このうち、ＵＲＬ入力ボックス１０４は、主ブラウザウィンドウにおいては、同期させたいページのＵＲＬの入力欄として機能する。また、従ブラウザウィンドウにおいては、正しくないページが表示された場合に、正しいページのＵＲＬの入力欄として機能する。
送信ボタン１０５は、ＵＲＬ入力ボックス１０４に入力されたＵＲＬをエージェント２０に伝えるために押下されるボタンである。
制御取得チェックボックス１０６は、ページの遷移を制御する権限を取得するためチェックされるボックスである。即ち、この制御取得チェックボックス１０６にチェックがなされたブラウザウィンドウを表示するブラウザは、図１の主ブラウザ１１となり、この制御取得チェックボックス１０６にチェックがなされていないブラウザウィンドウを表示するブラウザは、図１の従ブラウザ１２となる。
言語選択リストボックス１０７は、このブラウザウィンドウに表示するページの言語を指定するために用いるリストボックスである。例えば、図示するように、言語選択リストから英語を選択した場合、このブラウザウィンドウには、英語のページが表示される。

更にまた、その下には、エージェント２０から取得したコンテンツを表示するためのコンテンツ表示領域１０８が設けられている。

次に、図１のエージェント２０の機能構成について説明する。
図３は、エージェント２０の機能構成例を示したブロック図である。
図示するように、エージェント２０は、ブラウザ管理部２１と、ブラウザ情報記憶部２２と、ＵＲＬ生成部２３と、パターンルール記憶部２４と、要求／応答管理部２５とを備えている。

ブラウザ管理部２１は、複数のブラウザを例えばクッキーで識別する。そして、ブラウザごとにどの言語のページを表示するかを管理する。ここでは、主ブラウザ１１（図１参照）が日本語のページを表示し、従ブラウザ１２（図１参照）が英語のページを表示するものとする。この場合、ブラウザ管理部２１は、まず、主ブラウザ１１（図１参照）から、日本語のページを示すＵＲＬをページの表示要求として受け付ける。即ち、本実施の形態では、第１のクライアントで表示する文書データの識別情報の一例として、ＵＲＬを用いており、その識別情報を受け付ける受付部の一例として、ブラウザ管理部２１を設けている。そして、日本語のページを示すＵＲＬを英語のページを示すＵＲＬに変換するＵＲＬ変換指示をＵＲＬ生成部２３に伝える。或いは、図示しないが、従ブラウザ１２（図１参照）から正しいＵＲＬが通知された場合に、それをＵＲＬ生成部２３に伝えることもある。一方、要求／応答管理部２５から日本語のページと英語のページとを受け取ると、日本語のページは主ブラウザ１１へ、英語のページは従ブラウザ１２へ送信する。即ち、本実施の形態では、第２のクライアントが文書データを表示するように制御する制御部の一例として、ブラウザ管理部２１を設けている。

ブラウザ情報記憶部２２は、複数のブラウザについて、ブラウザＩＤと、ａｃｃｅｐｔ−ｌａｎｇｕａｇｅと、ＵＲＬと、完了フラグとを対応付けて記憶する。
ここで、ブラウザＩＤは、ブラウザを一意に識別する識別情報であり、クライアントの識別子の一例である。図では、主ブラウザ１１のブラウザＩＤを「００１」、従ブラウザ１２のブラウザＩＤを「００２」としている。また、ブラウザＩＤ「００１」に続く「＊」により、何れのブラウザが主ブラウザであるかも記憶している。このように、本実施の形態では、エージェント２０がブラウザの主従関係を管理しており、これにより、ブラウザ間の同期をＵＲＬリクエストを介して実現することを可能にしている。
尚、本実施の形態では、ブラウザの主従関係のグループは１つとしているが、ブラウザの主従関係のグループは複数あってもよい。その場合は、主ブラウザを「＊」で識別するのではなく、ブラウザ情報記憶部２２に主ブラウザＩＤ欄を追加するとよい。そして、主ブラウザＩＤをキーとしてグループを検索するとよい。例えば、主ブラウザＩＤ「００１」に対する従ブラウザＩＤが「００２」、「００３」であり、主ブラウザＩＤ「００４」に対する従ブラウザＩＤが「００５」、「００６」、「００７」であるとする。この場合、ブラウザＩＤ「００１」、「００２」、「００３」、「００４」、「００５」、「００６」、「００７」に対し、それぞれ、主ブラウザＩＤ「００１」、「００１」、「００１」、「００４」、「００４」、「００４」、「００４」が記憶される。そして、主ブラウザＩＤ「００１」をキーとして、ブラウザＩＤ「００１」、「００２」、「００３」からなるグループが特定され、主ブラウザＩＤ「００４」をキーとして、ブラウザＩＤ「００４」、「００５」、「００６」、「００７」からなるグループが特定されることになる。

また、ａｃｃｅｐｔ−ｌａｎｇｕａｇｅは、ブラウザにおける言語設定とは関係なく、ブラウザウィンドウでどの言語のページが必要なのかを示す情報である。即ち、ブラウザにおける言語設定は、ブラウザからエージェント２０へのＨＴＴＰリクエストのヘッダに含まれる言語指定情報の一例としてのａｃｃｅｐｔ−ｌａｎｇｕａｇｅに書き込まれているが、これは、ブラウザ情報記憶部２２に記憶されたａｃｃｅｐｔ−ｌａｎｇｕａｇｅの値により上書きされる。
尚、ブラウザＩＤ及びａｃｃｅｐｔ−ｌａｎｇｕａｇｅは、ブラウザの登録時に設定される。

一方、ＵＲＬは、後述するＵＲＬ生成部２３及び要求／応答管理部２５の処理結果に応じて設定されるものであり、各ブラウザが表示すべきことが判明したページのＵＲＬである。実際には、ＵＲＬの文字列が格納されることになるが、ここでは便宜上、日本語のページのＵＲＬを「ｒｅｓ−ｊａ」で表し、英語のページのＵＲＬを「ｒｅｓ−ｅｎ」で表している。
また、完了フラグは、上記ＵＲＬ欄に格納されたＵＲＬに基づくページの取得が完了したかどうかを示すフラグである。この完了フラグには、ページの取得が完了していれば「Ｙ」が設定され、ページの取得が完了していなければ「Ｎ」が設定されるものとする。図では、「完了フラグ」を単に「完了」と示している。
尚、本実施の形態では、ブラウザＩＤの対応情報又は後述する特定情報を記憶する記憶部の一例として、ブラウザ情報記憶部２２を設けている。

ＵＲＬ生成部２３は、ブラウザ管理部２１から渡されたＵＲＬ変換指示に従い、従ブラウザ１２が表示するページのＵＲＬの候補をリスト化したＵＲＬ候補リストを生成する。その際、ＵＲＬ生成部２３は、後述するパターンルールを用いるが、ブラウザ管理部２１から正しいＵＲＬが通知された場合は、パターンルールを更新することもある。そして、ＵＲＬ生成部２３は、ＵＲＬ候補リストを生成した場合、そのリストを要求／応答管理部２５に受け渡す。本実施の形態では、第２のクライアントで表示する文書データの識別情報を取得する取得部の一例として、ＵＲＬ生成部２３を設けている。
パターンルール記憶部２４は、ＵＲＬ生成部２３にてＵＲＬ候補リストを生成する際に用いるパターンルールを記憶する。
要求／応答管理部２５は、ＵＲＬ生成部２３からＵＲＬ候補リストを受け取り、そのリストに含まれる各ＵＲＬの妥当性を検証する。そして、妥当であると判断されたＵＲＬに基づいて、Ｗｅｂサーバ３０（図１参照）からページを取得する。本実施の形態では、第２のクライアントで表示する文書データを取得する取得部の一例として、要求／応答管理部２５を設けている。

次に、エージェント２０の動作について説明する。尚、本実施の形態では、次のことを前提とする。まず、対象とする言語（英語、日本語等）のページが、アクセスしたいサイトに存在することを、ユーザが予め知っているということである。また、ユーザは、アクセスしたいサイトのページの構造を知らないものとする。更に、他の言語のページの取得に失敗した場合、ユーザは、正しいＵＲＬを何らかの方法で特定して知らせることができるものとする。

まず、エージェント２０に各ブラウザを登録する際の動作を説明する。
図４は、このときの動作の流れを示したものである。
図示するように、主ブラウザ１１は、エージェント２０に登録要求を送信する（０−１）。その際、図２に示した制御取得チェックボックス１０６にチェックし、制御取得をオンに設定する。即ち、制御取得をオンに設定して登録要求を行ったブラウザが、ページを同期させる際にユーザの操作を受け付ける主ブラウザ１１となる。また、図において、主ブラウザ１１は、日本語のページを表示すべきこともエージェント２０に送信している。一方、従ブラウザ１２も、エージェント２０に登録要求を送信する（０−２）。その際、図２に示した制御取得チェックボックス１０６にチェックせず、制御取得はオフに設定する。即ち、制御取得をオフに設定して登録要求を行ったブラウザは、ページを同期して表示する従ブラウザ１２となる。また、図において、従ブラウザ１２は、英語のページを表示すべきこともエージェント２０に送信している。

これにより、エージェント２０では、ブラウザ管理部２１が、各ブラウザに一意のブラウザＩＤを付与する。そして、ブラウザ情報記憶部２２に対し、各ブラウザのブラウザＩＤと、各ブラウザで表示するページの言語との対応を登録する。ここでは、主ブラウザ１１にブラウザＩＤ「００１」を付与し、従ブラウザ１２にブラウザＩＤ「００２」を付与している。従って、ブラウザＩＤ「００１」と日本語を表す「ｊａ」との対応、及び、ブラウザＩＤ「００２」と英語を表す「ｅｎ」との対応を登録している。尚、「＊」は、上述したように、そのブラウザが主ブラウザであることを示している。
その後、エージェント２０では、ブラウザ管理部２１が、ブラウザＩＤ「００１」を主ブラウザ１１に送信する（０−３）と共に、ブラウザＩＤ「００２」を従ブラウザ１２に送信する（０−４）。
尚、本実施の形態では、エージェント２０へのブラウザ登録要求を送信する際に、制御取得のオン・オフの情報を含めることにより主・従ブラウザを決定した。しかし、これに限らず、後述の表示するページを要求する際に、制御取得の情報を含めることにより主・従ブラウザを再度決定し、既存の主従関係を更新することもできる。このように、ページ要求を行うごとに、主ブラウザの役割を入れ替えるといった実施の形態も考えられる。

次に、主ブラウザ１１がエージェント２０にページを要求してから、主ブラウザ１１及び従ブラウザ１２がページを表示するまでの動作を説明する。
図５〜９は、このときの動作の流れを示したものである。
まず、図５を参照して、主ブラウザ１１がエージェント２０にページを要求するときの動作を説明する。
図示するように、主ブラウザ１１は、表示したいページのＵＲＬをエージェント２０に送信する（１−１）。その際、主ブラウザ１１のブラウザＩＤも、例えばクッキー等を用いて、主ブラウザ１１からエージェント２０へと渡される。図では、ＵＲＬ「http://www.foo.com/ja」と、ブラウザＩＤ「００１」とが受け渡されている。

すると、エージェント２０では、ブラウザ管理部２１が、ブラウザ情報記憶部２２において、主ブラウザ１１から受け取ったブラウザＩＤに対し、受け取ったＵＲＬを記憶する。また、ブラウザ情報記憶部２２を参照し、主ブラウザ１１が表示する言語が日本語であり、従ブラウザ１２が表示する言語が英語であることを認識する。そして、主ブラウザ１１から渡されたＵＲＬを日本語のページを示すものから英語のページを示すものに変換するＵＲＬ変換指示をＵＲＬ生成部２３に伝える（１−２）。尚、ここでは、主ブラウザ１１は既定であるとしているが、前述のページ要求ごとに主ブラウザの役割を入れ替える実施の形態では、従ブラウザ１２が制御取得をオンにしてページ要求を行い、ブラウザ管理部２１がページ要求を受け付けた段階で、主ブラウザ１１と従ブラウザ１２の役割を変更することになる。

一方で、従ブラウザ１２は、短い時間間隔、例えば、１秒ごとに更新チェック要求をエージェント２０に送信する（１−３）。その際、従ブラウザ１２のブラウザＩＤも、例えばクッキー等を用いて、従ブラウザ１２からエージェント２０へと渡される。
すると、エージェント２０では、ブラウザ管理部２１が、ブラウザ情報記憶部２２を参照し、従ブラウザ１２から受け取ったブラウザＩＤに対する完了フラグが「Ｙ」に設定されているかどうかを判定する。ところが、この時点でエージェント２０はまだ英語のページを取得しておらず、ブラウザＩＤ「００２」に対する完了フラグは「Ｎ」に設定されている。従って、ブラウザ管理部２１は、従ブラウザ１２に対して、ページを送信しない。

次に、図６を参照して、エージェント２０がＵＲＬ候補リストを生成するときの動作を説明する。
エージェント２０では、前述したように、ブラウザ管理部２１からＵＲＬ生成部２３へ、ＵＲＬを日本語対応のものから英語対応のものに変換するＵＲＬ変換指示が送られている。
これにより、ＵＲＬ生成部２３は、パターンルール記憶部２４に記憶されたパターンルールを参照し、ＵＲＬ候補リストを生成する（２−１）。例えば、図の例のように、日本語を英語に変換する場合であれば、どこに出現する「ｊａ」を「ｅｎ」に変換するか、どのパターンルールを優先的に適用するか等を考慮して、ＵＲＬを生成する。そして、ＵＲＬ生成部２３は、生成したＵＲＬ候補リストを要求／応答管理部２５に受け渡す（２−２）。

また、図７を参照して、ＵＲＬ候補リストに含まれる各ＵＲＬの妥当性を検証するときの動作を説明する。
エージェント２０では、図示するように、要求／応答管理部２５が、ＵＲＬ候補リストに含まれる各ＵＲＬに基づいて、Ｗｅｂサーバ３０に対し、ＨＥＡＤリクエストを送信する（２−３）。ここで、ＨＥＡＤリクエストとは、ＨＴＴＰリクエストのうちＨＥＡＤメソッドによるリクエストである。尚、この場合、ＵＲＬ候補リストに含まれるＵＲＬは、上に記載された方が優先度が高いものとし、上に記載されたものからＨＥＡＤリクエストを送信するものとする。また、ＵＲＬ候補リストに含まれるＵＲＬのうち、「en.foo.com」及び「www.foo.co.jp/en」は存在しておらず、「www.foo.com/en」は存在しているものとする。まず、「en.foo.com」に対してＨＥＡＤリクエストを送信するが、これに対しては「Ｕｎｋｎｏｗｎ Ｈｏｓｔ」とのステータスが返されるので、妥当なＵＲＬではないことが分かる。次に、「www.foo.co.jp/en」に対してＨＥＡＤリクエストを送信するが、これに対しては「４０４ Ｎｏｔ Ｆｏｕｎｄ」とのステータスが返されるので、これも妥当なＵＲＬではないことが分かる。最後に、「www.foo.com/en」に対してＨＥＡＤリクエストを送信すると、これに対して「２００ ＯＫ」とのステータスが返されるので、妥当なＵＲＬであることが分かる。
そして、要求／応答管理部２５は、ブラウザ情報記憶部２２において、従ブラウザ１２のブラウザＩＤ「００２」に対し、ここで妥当と判断されたＵＲＬ「www.foo.com/en」を記憶する（２−４）。

更に、図８を参照して、オリジナルのＵＲＬと妥当なＵＲＬからレスポンスを取得するときの動作を説明する。
エージェント２０では、図示するように、要求／応答管理部２５が、ブラウザ情報記憶部２２において各ブラウザのブラウザＩＤに対して登録されたＵＲＬを取り出す。ここでは、ブラウザＩＤ「００１」に対するＵＲＬ（オリジナルのＵＲＬ）として、「www.foo.com/ja」を取り出し、ブラウザＩＤ「００２」に対するＵＲＬ（妥当なＵＲＬ）として、「www.foo.com/en」を取り出している。そして、要求／応答管理部２５は、これらのＵＲＬに基づいて、Ｗｅｂサーバ３０からページを取得する（３−１）。この場合、両方とも正しいＵＲＬであるので、「２００ ＯＫ」とのステータスが返され、ページが取得される。その後、要求／応答管理部２５は、取得したページをブラウザ管理部２１に受け渡す（３−２）。また、取得したページがブラウザ管理部２１に受け渡されると、要求／応答管理部２５は、ブラウザ情報記憶部２２において、ブラウザＩＤ「００１」に対する完了フラグ、及び、ブラウザＩＤ「００２」に対する完了フラグを「Ｙ」に設定する。

更にまた、図９を参照して、主ブラウザ１１及び従ブラウザ１２にレスポンスを返すときの動作を説明する。
エージェント２０では、図示するように、ブラウザ管理部２１が、日本語のページを主ブラウザ１１に送信する（４−１）。尚、主ブラウザ１１からブラウザ管理部２１への破線は、図５に示したページの取得要求を示している。一方、ブラウザ管理部２１は、英語のページを従ブラウザ１２に送信する（４−２）。尚、従ブラウザ１２からブラウザ管理部２１への破線は、図５に示した更新チェック要求を示している。図５では、ブラウザ情報記憶部２２においてブラウザＩＤ「００２」に対する完了フラグが「Ｎ」に設定されていたので、ページは送信されなかったが、ここでは、図６から図８までの処理を経ることによりブラウザＩＤ「００２」に対する完了フラグが「Ｙ」に設定されているので、更新チェック要求に応じてページが送信される。

通常、ブラウザは、ユーザ操作がない限り、リクエストを発行しない。そして、リクエストを発行しないと、送信先が特定できないので、情報も表示されない。そこで、本実施の形態では、従ブラウザ１２が、更新チェック要求をエージェント２０に対して定期的に行うことで、ページが表示されるようにした。また、その際、従ブラウザ１２は、本来必要となるリクエストを更新チェックリクエストでエミュレートしてエージェント２０に発行するようにした。これにより、複数の従ブラウザ１２が存在した場合に、複数のレスポンスを各ブラウザに返せるようになっている。

尚、ここでは、従ブラウザ１２が表示すべきページが取得されているかどうかを示す方法として、ページの取得が完了したかどうかを完了フラグで示す方法を採用したが、この方法には限らない。即ち、従ブラウザ１２が表示すべきページが取得されたことを示す特定情報を記憶しておくことができるものであれば、如何なる方法を採用してもよい。
また、ここでは、主ブラウザ１１及び従ブラウザ１２に対してページを送信したが、必ずしもページを送信しなくてもよい。例えば、エージェント２０から各ブラウザへはページのＵＲＬのみを送信し、ページの取得は、エージェント２０を介さずに行うような構成も考えられる。

ところで、以上のような動作により、従ブラウザ１２は、所望の言語のページを表示することになるが、図６で生成し、図７で妥当と判断したＵＲＬが誤っている場合もないわけではない。このような場合、エージェント２０は、ユーザからの正しいＵＲＬの入力により、パターンルールを更新する。以下、このときの動作について説明する。
図１０〜１３は、このときの動作の流れを示したものである。
まず、図１０を参照して、従ブラウザ１２が正しいＵＲＬをエージェント２０に通知するときの動作を説明する。
図示するように、従ブラウザ１２は、正しいＵＲＬを、エージェント２０に通知する（５−１）。その際、従ブラウザ１２のブラウザＩＤも、例えばクッキー等を用いて、従ブラウザ１２からエージェント２０へと渡される。図では、正しいＵＲＬ「www.en.foo.com」が、ブラウザＩＤ「００２」と共に受け渡されている。すると、エージェント２０では、ブラウザ管理部２１が、渡されたＵＲＬを受け付ける。

次に、図１１を参照して、エージェント２０がパターンルールを更新するときの動作を説明する。
エージェント２０では、図示するように、ブラウザ管理部２１が、図９で従ブラウザ１２に送信したＵＲＬを従ブラウザ１２から受信した正しいＵＲＬに訂正するＵＲＬ訂正指示をＵＲＬ生成部２３に伝える（５−２）。具体的には、従ブラウザ１２から取得した正しいＵＲＬである「www.en.foo.com」を伝えている。これにより、ＵＲＬ生成部２３は、パターンルールを更新する（５−３）。尚、ここでのパターンルールの更新は、ここでブラウザ管理部２１から伝えられたＵＲＬを図５で主ブラウザ１１から受信したＵＲＬに直接対応付けることにより行ってもよいし、ここでブラウザ管理部２１から伝えられたＵＲＬに基づいてパターンルールの適用順位を調整することにより行ってもよい。このようにしてパターンルールの更新が終了すると、ＵＲＬ生成部２３は、正しいＵＲＬを要求／応答管理部２５に通知する（５−４）。尚、このとき、要求／応答管理部２５は、ブラウザ情報記憶部２２において、従ブラウザ１２のブラウザＩＤ「００２」に対し、通知されたＵＲＬを記憶する。

また、図１２を参照して、訂正後のＵＲＬからレスポンスを取得するときの動作を説明する。
エージェント２０では、図示するように、要求／応答管理部２５が、ブラウザ情報記憶部２２において従ブラウザ１２に対して登録されたＵＲＬを取り出す。ここでは、ブラウザＩＤ「００２」に対するＵＲＬとして、「www.en.foo.com」を取り出している。そして、要求／応答管理部２５は、このＵＲＬに基づいて、Ｗｅｂサーバ３０からページを取得する（５−５）。この場合、これは妥当なＵＲＬであるので、「２００ ＯＫ」とのステータスが返され、ページが取得される。その後、要求／応答管理部２５は、取得したページをブラウザ管理部２１に受け渡す（５−６）。

更に、図１３を参照して、従ブラウザ１２にレスポンスを返すときの動作を説明する。
エージェント２０では、図示するように、ブラウザ管理部２１が、指示されたＵＲＬに基づく正しいページを従ブラウザ１２に送信する（５−７）。尚、従ブラウザ１２からブラウザ管理部２１への破線は、図５に示した更新チェック要求を示している。これにより、ブラウザ管理部２１から従ブラウザ１２へ、正しいＵＲＬである「www.en.foo.com」のページが送信され、従ブラウザ１２がこのページを表示する。
尚、ここでも、エージェント２０から従ブラウザ１２へはページのＵＲＬのみを送信し、ページの取得は、エージェント２０を介さずに行うような構成も考えられる。

ここで、以上述べた動作をフローチャートに基づいて説明する。
図１４は、エージェント２０の動作例を示したフローチャートである。尚、このフローチャートは、主ブラウザ１１からの１回の要求に応じた処理について示したものであり、通常は、この処理が主ブラウザ１１からの要求に応じて繰り返されることになる。

動作が開始すると、まず、ブラウザ管理部２１が、主ブラウザ１１からページの表示要求を受け付ける（ステップ２０１）。このとき、ページの表示要求には、上述したように、ページのＵＲＬが含まれている。また、このとき、ブラウザ管理部２１は、ブラウザ情報記憶部２２を参照して、従ブラウザ１２が表示するページの言語を特定し、ＵＲＬをこの特定された言語を表すものに変換するＵＲＬ変換指示を生成してＵＲＬ生成部２３に送る。
すると、ＵＲＬ生成部２３は、パターンルール記憶部２４に記憶されたパターンルールを用いて、従ブラウザ１２が表示するページのＵＲＬの候補からなるＵＲＬ候補リストを生成し、要求／応答管理部２５に受け渡す（ステップ２０２）。

これにより、要求／応答管理部２５は、受け渡されたＵＲＬ候補リストに含まれるＵＲＬ候補の妥当性を検証する。即ち、まず、ＵＲＬ候補リストに含まれるＵＲＬ候補で未処理のものを格納したバッファが空になったかどうかを判定する（ステップ２０３）。
ここで、バッファが空になっていないと判定されれば、次のＵＲＬ候補をバッファから取り出す（ステップ２０４）。次に、この取り出したＵＲＬ候補に基づいて、Ｗｅｂサーバ３０にＨＥＡＤリクエストを送信する（ステップ２０５）。これに対して、Ｗｅｂサーバ３０から「２００ ＯＫ」とのレスポンス、つまり、正常なレスポンスが返って来たかどうかを判定する（ステップ２０６）。そして、正常なレスポンスが返って来ていなければ、ステップ２０３に戻り、再びバッファが空かどうかを判定する。また、正常なレスポンスが返って来れば、ステップ２０４で取り出したＵＲＬに基づいて、Ｗｅｂサーバ３０にＧＥＴリクエスト又はＰＯＳＴリクエストを送信する（ステップ２０７）。これにより、Ｗｅｂサーバ３０から返されたレスポンスは、ブラウザ管理部２１に渡される。
一方、ステップ２０３でバッファが空になったと判定されれば、ステップ２０８に進む。この場合は、全てのＵＲＬ候補について正常な応答が返されなかったことになるので、その旨の情報がブラウザ管理部２１に渡される。

そして、ブラウザ管理部２１は、この渡された情報を主ブラウザ１１及び従ブラウザ１２に返す（ステップ２０８）。尚、このとき、全てのＵＲＬ候補について正常な応答が返されなかった旨の情報も従ブラウザ１２に送信される。また、Ｗｅｂサーバ３０から返された正常なレスポンスを従ブラウザ１２に送信したとしても、そのレスポンスに誤りがある可能性はある。本実施の形態では、このような場合に、先にも述べた通り、正しいＵＲＬをフィードバックすることを可能としている。
そこで、ブラウザ管理部２１は、フィードバック要求があるかどうかを判定し（ステップ２０９）、フィードバック要求がない場合は、そのまま処理を終了する。一方、フィードバック要求がある場合、従ブラウザ１２から正しいＵＲＬを受け付ける（ステップ２１０）。そして、ブラウザ管理部２１は、ＵＲＬ訂正指示をＵＲＬ生成部２３に伝え、ＵＲＬ生成部２３が、パターンルールを更新する（ステップ２１１）。尚、この更新されたパターンルールは、ステップ２０２で再び使用されることになる。
ところで、ステップ２０９におけるフィードバック要求の有無の判定は、リクエストを送ってきたブラウザが従ブラウザ１２であるかどうかによって行う。即ち、従ブラウザ１２からリクエストが送信された場合のみフィードバック要求があったと判定する。ここで、前述のページ要求ごとに主ブラウザの役割を入れ替える実施の形態では、制御取得がオフであるブラウザからのリクエストをフィードバック要求と判定する。

次に、図１４のフローチャートのステップ２０２でＵＲＬ候補リストを生成する際の詳細な動作について説明する。本実施の形態において、このＵＲＬ候補リストの生成は、前半及び後半の２段階の処理からなる。前半の処理は、ＵＲＬの要素ごとに言語情報を変換する処理である。一方、後半の処理は、ＵＲＬの要素ごとに変換した結果を組み合わせて最終的なＵＲＬ候補リストを生成する処理である。そこで、本実施の形態では、２種類のパターンルールを用いる。即ち、前半の処理で用いられる変換ルールと、後半の処理で用いられる組み合わせルールである。尚、このようにＵＲＬ候補リストの生成を前半及び後半に分けたのは、各ＵＲＬ要素に含まれる言語情報が相互依存しない場合があることを考慮したものである。

以下、これらの処理を順に説明する。
図１５は、ＵＲＬ候補リストの生成における前半部分の動作例を示したフローチャートである。
まず、ＵＲＬ生成部２３は、ブラウザ管理部２１からＵＲＬ変換指示を受け付ける（ステップ２２１）。ここで、ＵＲＬ変換指示には、主ブラウザ１１から渡されたＵＲＬ（以下、「元ＵＲＬ」という）と、どの言語からどの言語へ変換すべきかを示す言語変換情報とが含まれる。このうち、元ＵＲＬは、ドメイン（ホスト名）、パス、パラメータ（クエリーストリング）からなる文字列（一般にＵＲＬとして認識されている文字列）を含む。但し、本実施の形態では、これに加え、ＨＴＴＰヘッダ内のａｃｃｅｐｔ−ｌａｎｇｕａｇｅや、ＰＯＳＴメソッドでＷｅｂサーバ３０に送信されるフォームデータ（以下、「ＰＯＳＴデータ」という）や、クッキーの情報もＵＲＬに含めて考える。

次に、ＵＲＬ生成部２３は、ステップ２２１で受け付けた元ＵＲＬに含まれるａｃｃｅｐｔ−ｌａｎｇｕａｇｅに設定された言語を、同じくステップ２２１で受け付けた言語変換情報に従って変更する（ステップ２２２）。通常、言語設定は個々のブラウザウィンドウに対して行うことができない。つまり、複数のブラウザウィンドウを開いた状態で１つのブラウザウィンドウ上で言語を切り替えた場合、他のブラウザウィンドウの言語設定も変更されてしまう。そこで、本実施の形態では、ブラウザが発行したリクエスト中のブラウザにおける言語設定に基づいて設定されたａｃｃｅｐｔ−ｌａｎｇｕａｇｅの値を、エージェント２０が上書きして変更している。

また、ＵＲＬ生成部２３は、ステップ２２１で取得したＵＲＬを、ドメイン、パス、パラメータ、ＰＯＳＴデータ、クッキー等の要素（以下、「ＵＲＬ要素」という）に分離する（ステップ２２３）。そして、分離した各ＵＲＬ要素に対して、以下の処理を実行する。

即ち、まず、全種類のＵＲＬ要素について、処理を行ったかどうかを判定する（ステップ２２４）。
ここで、全種類のＵＲＬ要素について処理を行っていると判定されれば、処理を終了する。
一方、全種類のＵＲＬ要素について処理を行っていないと判定されれば、１種類のＵＲＬ要素（例えば、ドメイン）に着目し、ステップ２２１で受け付けたＵＲＬのこのＵＲＬ要素の部分をそのままＵＲＬ要素候補リストに登録する（ステップ２２５）。尚、以下の説明では、このようにそのまま登録した候補を“ａｓ ｉｓ”候補と呼ぶ。“ａｓ ｉｓ”候補は、それ自体では、言語情報の変換を行ったことにはならないが、言語情報の変換を行った他のＵＲＬ要素と組み合わせることにより、従ブラウザ１２が表示するページのＵＲＬ候補を構成することになる。
次に、ＵＲＬ生成部２３は、ステップ２２１で受け付けたＵＲＬのこのＵＲＬ要素の部分が言語情報を含むかどうかを判定する（ステップ２２６）。

その結果、このＵＲＬ要素の部分が言語情報を含んでいなければ、ステップ２２４に戻り、次のＵＲＬ要素について同様の処理を行う。
一方、このＵＲＬ要素の部分が言語情報を含んでいれば、変換ルールの数だけ、以下の処理を繰り返す。
即ち、まず、全ての変換ルールを適用して変換を行ったかどうかを判定する（ステップ２２７）。そして、全ての変換ルールを適用して変換を行っていれば、ステップ２２４に戻り、次の種類のＵＲＬ要素（例えば、パス）について同様の処理を行う。また、全ての変換ルールを適用して変換を行っていなければ、ＵＲＬ要素の部分に含まれる言語情報を、ここで着目している変換ルールに従って変換する（ステップ２２８）。そして、言語情報を変換した後のＵＲＬ要素をＵＲＬ要素候補としてＵＲＬ要素候補リストに登録する（ステップ２２９）。そして、ステップ２２７に戻り、全ての変換ルールが適用されるまで処理を繰り返す。

ここで、この動作を具体例を用いて説明する。
まず、この例で用いる変換ルールについて説明する。
図１６は、パターンルール記憶部２４に記憶された変換ルールの例である。
この変換ルールは、ＵＲＬ要素内のどの文字列を変換するかを優先順位と共に記憶したものである。本実施の形態では、ある言語のページのＵＲＬを別の言語のページのＵＲＬに変換するために、ＵＲＬ中に現れる言語情報として、言語名、言語コード、国名、国コードに着目している。そして、この言語情報の何れを変換したものをＵＲＬ候補とするかを定義している。図中、「ＹＥＳ」は、対応する言語情報を変換することを表しており、「ＮＯ」は、対応する言語情報を変換しないことを表している。

ところで、この例では、言語名、言語コード、国名、国コードの何れを置換したＵＲＬ要素の優先順位を高くすべきかを、次のような考え方に基づいて決定している。即ち、文字列が短くなりがちな場合、間違った置換がなされる可能性が高いので、文字列が長くなる傾向にあるものほど優先的に置換するという考え方である。例えば、国名と言語名とを比較すると、国名よりも言語名の方が長いことが多い。従って、図１６において、優先順位は、言語名、言語コード、国名、国コードの順としている。但し、これとは逆のケースもあるので、国ごとに言語名と国名のリストを作成し、言語名と国名のうちの長い方の優先順位を高くしてもよい。

また、言語名、言語コード、国名、国コードを組み合わせて置換したＵＲＬ要素のうち、どの組合せの優先度を高くすべきかについては、幾つかの考え方がある。
１つは、Ｘ個の言語情報を置換したＵＲＬ要素は、（Ｘ−１）個の言語情報を置換したＵＲＬ要素よりも、優先順位を高くするという考え方である。
図１６（ａ）は、この考え方に基づいて用意された変換ルールである。優先順位が「１」に対して、「ＹＥＳ」が４つ、優先順位が「２」〜「５」に対して、「ＹＥＳ」が３つ、優先順位が「６」〜「１１」に対して、「ＹＥＳ」が２つ、優先順位が「１２」〜「１５」に対して、「ＹＥＳ」が１つとなっている。

またもう１つは、優先順位が高い言語情報を置換したＵＲＬ要素の方が、優先順位が高くなるようにするという考え方である。
図１６（ｂ）は、この考え方に基づいて用意された変換ルールである。優先順位「１」〜「８」に対して、言語名が「ＹＥＳ」となっており、優先順位「９」〜「１２」に対して、言語名は「ＮＯ」で言語コードが「ＹＥＳ」となっており、優先順位「１３」、「１４」に対して、言語名、言語コードは「ＮＯ」で国名が「ＹＥＳ」となっており、優先順位「１５」に対して、国コードのみが「ＹＥＳ」となっている。

次に、図１６（ａ）の変換ルールを用いた実際のＵＲＬの変換について説明する。
例えば、ステップ２２１で取得した元ＵＲＬが「http://ja.foobar.com/ja_JP/document/release_note_japanese.html」であるとする。
この場合、ステップ２２３で、元ＵＲＬから、ドメイン要素「ja.foobar.com」と、パス要素「ja_JP/document/release_note_japanese.html」とが抽出される。
そして、このＵＲＬを日本語対応のものからフランス語対応のものに変換することを考える。

まず、ドメイン要素の変換について考える。
この場合、ドメイン要素に含まれる言語情報は、言語コードのみであるので、（ａ）の表の優先順位１３の変換ルールのみを適用すればよい。
図１７（ａ）にこの変換規則を適用して生成されたドメイン要素の候補（ドメイン候補）を示す。この場合、言語コード「ｊａ」を「ｆｒ」に変換し、ドメイン候補「fr.foobar.com」を生成している。尚、優先順位“ａｓ ｉｓ”は、ステップ２２５でそのまま登録されたドメイン候補を示している。

次に、パス要素の変換について考える。
この場合、パス要素には、言語名「japanese」、言語コード「ja」、国コード「JP」が言語情報として含まれている。そこで、国名を変換するための変換ルール以外を順に適用する。具体的には、優先順位３、６、８、１０、１２、１３、１５の変換ルールを順に適用して、パス要素の候補（パス候補）を生成する。優先順位３の変換ルールを適用すると、言語名、言語コード、国コードの全てが変換される。つまり、言語名「japanese」が「french」に変換され、言語コード「ja」が「fr」に変換され、国コード「JP」が「FR」に変換され、図１７（ｂ）における優先順位１のパス候補が生成される。以下、同様に変換ルールを適用し、図１７（ｂ）における優先順位２〜７のパス候補が生成される。尚、ここでも、優先順位“ａｓ ｉｓ”は、ステップ２２５でそのまま登録されたパス候補を示している。

また、図１８は、ＵＲＬ候補リストの生成における後半部分の動作例を示したフローチャートである。
まず、ＵＲＬ生成部２３は、ＵＲＬ要素候補、例えば、ドメイン要素の候補、パス要素の候補、パラメータ要素の候補等を読み込む（ステップ２４１）。
一方、ＵＲＬ生成部２３は、これらのＵＲＬ要素の候補を組み合わせるための組み合わせルールをパターンルール記憶部２４から読み込む（ステップ２４２）。
そして、ステップ２４１で読み込んだ各ＵＲＬ要素の候補に対し、ステップ２４２で読み込んだ組み合わせルールを適用することにより、最終的なＵＲＬ候補リストを生成する（ステップ２４３）。
また、図１５のステップ２２２でａｃｃｅｐｔ−ｌａｎｇｕａｇｅを変更されたリクエストを追加し、その結果を全てのＵＲＬ候補とする（ステップ２４４）。

ここで、この動作を具体例を用いて説明する。
まず、この例で用いる組み合わせルールについて説明する。
図１９−１（ａ）は、パターンルール記憶部２４に記憶された組み合わせルールの例である。
この組み合わせルールは、どのＵＲＬ要素を優先的に組み合わせてＵＲＬを生成するかを示す規則である。ここでは、ＵＲＬ要素として、ドメイン要素、パス要素、パラメータ要素を想定している。図中、「ＹＥＳ」は、対応するＵＲＬ要素について変換結果を組み合わせることを表しており、「ＮＯ」は、対応するＵＲＬ要素については変換結果を組み合わせないことを表している。

また、図１９−２（ｂ）は、この組み合わせルールを模式的に示したものである。
まず、ｋ通りのドメイン要素の各候補、ｍ通りのパス要素の各候補、ｎ通りのパラメータ要素の各候補の全ての組合せを順に列挙する。即ち、ＵＲＬ候補１１１、ＵＲＬ候補１１２、・・・、ＵＲＬ候補ｋｍｎを作成する。図１９−１（ｂ）の例では、ドメイン、パス、パラメータの順で優先度が高い前提にして組合せを列挙している。その後、図１９−１（ａ）の表の優先順位に従い、同じ順位のＵＲＬ候補をグループ化する。即ち、ＵＲＬ候補１１１は優先順位１、ＵＲＬ候補１１ｎは優先順位２のグループにそれぞれ入る。同一グループ内の順位は、列挙したときの順番を保持する。即ちＵＲＬ候補の添え字とした数字が小さいほど優先順位が高いので、同じ優先順位グループ１のＵＲＬ候補１１１とＵＲＬ候補１２１は、ＵＲＬ候補１１１の方が優先度が高くなる。

次に、図１９−１（ａ）の組み合わせルールを用いた実際のＵＲＬの生成について説明する。
ここでは、ステップ２４１において、図１７（ａ）に示したドメイン要素の候補及び同図（ｂ）に示したパス要素の候補が読み込まれたものとする。
この例では、パラメータは存在しないので、図１９−１（ａ）の優先順位２、５、６の順に、組み合わせルールを適用する。

図２０は、このようにして生成されたＵＲＬ候補リストである。
図１９−１（ａ）の組み合わせルールの優先順位２を適用することにより、図２０のＵＲＬ候補リストの優先順位１〜７が生成されている。
また、図１９−１（ａ）の組み合わせルールの優先順位５を適用することにより、図２０のＵＲＬ候補リストの優先順位８が生成されている。
更に、図１９−１（ａ）の組み合わせルールの優先順位６を適用することにより、図２０のＵＲＬ候補リストの優先順位９〜１５が生成されている。

以上説明したように、本実施の形態では、ブラウザに主従関係を導入し、エージェント２０が主ブラウザ１１及び従ブラウザ１２を管理するようにした。そして、ブラウザウィンドウに施された言語設定をエージェント２０が加工して生成したＵＲＬリクエストをＷｅｂサーバ３０に発行することにより、元の言語設定とは独立して言語設定が施された複数のブラウザウィンドウに対して、同じ内容の異なる言語のページを同期しながら表示するようにした。これにより、例えば、日本語のページを開くと、自動的に対応する英語のページが開かれる、また、日本語のページが遷移したら、自動的に対応する英語のページも遷移する、といったブラウザウィンドウ上の動作が可能となる。

そして、このようなブラウザウィンドウ上の動作は、実際の応用場面では次のような効果をもたらすことになる。
第一に、ヘルプ等の技術情報の日本語翻訳と英語原文とを簡単に対比させながら読むことができる。
第二に、複数の言語で作成したウェブ情報の翻訳を検証する翻訳検証テストをブラウザ上で行う際に、これまで翻訳検証者が行っていた作業のうち、言語の切替が正常に動作するかの検証は、切り替わった後の正しい表示が何かを知っていれば、開発技術者自身が英語情報の上で操作することによって行うことができる。
第三に、国際化検証テストのような言語依存のテストを、オリジナルの英語のアプリケーションの動作と英語以外のアプリケーションの動作とを対比させながら行うことができる。
第四に、母国語が異なる受講生が受講するＥラーニングにおいて、講師の操作に応じ、各受講生の母国語でコンテンツを表示することができる。尚、これは、図１の主ブラウザ１１が講師のコンピュータ端末で動作し、複数の従ブラウザ１２が各受講生のコンピュータ端末で動作する場合の効果である。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図２１は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ(Central Processing Unit）９０ａと、Ｍ／Ｂ(マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図２１において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

本発明の実施の形態におけるコンピュータシステムの構成及び動作を示した図である。 本発明の実施の形態で表示するブラウザウィンドウのイメージを示した図である。 本発明の実施の形態におけるエージェントの機能構成例を示した図である。 本発明の実施の形態においてブラウザを登録する際の動作を示した図である。 本発明の実施の形態においてページを同期表示する際の動作を示した図である。 本発明の実施の形態においてページを同期表示する際の動作を示した図である。 本発明の実施の形態においてページを同期表示する際の動作を示した図である。 本発明の実施の形態においてページを同期表示する際の動作を示した図である。 本発明の実施の形態においてページを同期表示する際の動作を示した図である。 本発明の実施の形態において妥当と判断したＵＲＬが正しくなかった場合の動作を示した図である。 本発明の実施の形態において妥当と判断したＵＲＬが正しくなかった場合の動作を示した図である。 本発明の実施の形態において妥当と判断したＵＲＬが正しくなかった場合の動作を示した図である。 本発明の実施の形態において妥当と判断したＵＲＬが正しくなかった場合の動作を示した図である。 本発明の実施の形態におけるエージェントの動作例を示したフローチャートである。 本発明の実施の形態におけるＵＲＬ候補リストの生成の前半の動作例を示したフローチャートである。 本発明の実施の形態におけるＵＲＬ候補リストの生成の前半の動作で用いる変換ルールの例を示した図である。 本発明の実施の形態において生成されるＵＲＬ要素候補の具体例を示した図である。 本発明の実施の形態におけるＵＲＬ候補リストの生成の後半の動作例を示したフローチャートである。 本発明の実施の形態におけるＵＲＬ候補リストの生成の後半の動作で用いる組み合わせルールの例を示した図である。 本発明の実施の形態におけるＵＲＬ候補リストの生成の後半の動作で用いる組み合わせルールの例を示した図である。 本発明の実施の形態において生成されるＵＲＬ候補リストの具体例を示した図である。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

符号の説明

２０…エージェント、２１…ブラウザ管理部、２２…ブラウザ情報記憶部、２３…ＵＲＬ生成部、２４…パターンルール記憶部、２５…要求／応答管理部

Claims (12)

1. 文書データの表示を制御する装置であって、
   第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付ける受付部と、
   前記受付部により受け付けた前記第１の識別情報に基づいて、前記第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得する取得部と、
   前記取得部により取得された前記第２の識別情報に基づいて、前記第２の言語で記述された文書データを表示するための第２のクライアントが前記第２の文書データを表示するように制御する制御部と
   を備えた、装置。
2. 前記取得部は、前記受付部により受け付けた前記第１の識別情報に含まれる前記第１の言語に関係する文字列を前記第２の言語に関係する文字列に置換する処理を行うことにより、前記第２の識別情報を取得する、請求項１の装置。
3. 前記取得部は、前記受付部により受け付けた前記第１の識別情報に対して前記置換する処理を行うことにより前記第２の識別情報の複数の候補を生成し、当該複数の候補のうち、前記第２の文書データを取得するために使用可能な候補を前記第２の識別情報として取得する、請求項２の装置。
4. 前記取得部は、前記複数の候補の各々に基づくアクセスを順次試みることにより、前記第２の文書データを取得するために使用可能な候補を特定する、請求項３の装置。
5. 前記取得部は、前記受付部により受け付けた前記第１の識別情報を構成する各要素に対して前記置換する処理を行い、当該置換する処理が行われた後の当該各要素を組み合わせることにより、前記第２の識別情報を取得する、請求項２の装置。
6. 前記第１のクライアントの識別子と前記第２のクライアントの識別子との対応情報を記憶する記憶部を更に備え、
   前記受付部は、前記第１のクライアントから、当該第１のクライアントの識別子を受け付け、
   前記制御部は、前記受付部により受け付けた前記第１のクライアントの識別子を用いて前記記憶部に記憶された前記対応情報を検索することにより得られた前記第２のクライアントの識別子に基づいて、当該第２のクライアントを特定する、請求項１の装置。
7. 前記取得部は、前記第２の識別情報に基づいて前記第２の文書データを取得し、当該第２の文書データが取得されたことを示す特定情報を記憶部に記憶し、
   前記制御部は、前記第２のクライアントから前記第２の文書データの表示要求があった際に、前記記憶部に前記特定情報が記憶されていれば、当該第２のクライアントが当該第２の文書データを表示するように制御する、請求項１の装置。
8. 前記第１の識別情報は、前記第１の文書データの所在を示すＵＲＬ（Uniform Resource Locator）を含む、請求項１の装置。
9. 前記第１の識別情報は、前記第１のクライアントが表示する文書データの言語を指定するために当該第１のクライアントに設定された言語指定情報を含み、
   前記取得部は、前記言語指定情報を前記第２の言語を指定するように書き換えることにより、前記第２の識別情報を取得する、請求項１の装置。
10. 前記受付部は、前記第１のクライアントから前記第１の識別情報を受け付けたことに応じて前記第２のクライアントに所定の文書データが表示された後に、当該第２のクライアントから前記第２の識別情報を受け付け、
    前記取得部は、前記第１の識別情報に基づいて前記第２の識別情報を取得する際に用いる情報を、前記受付部が受け付けた前記第２の識別情報に基づいて更新する、請求項１の装置。
11. 文書データの表示を制御する方法であって、
    第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付けるステップと、
    受け付けた前記第１の識別情報に基づいて、前記第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得するステップと、
    取得された前記第２の識別情報に基づいて、前記第２の言語で記述された文書データを表示するための第２のクライアントが前記第２の文書データを表示するように制御するステップと
    を含む、方法。
12. 文書データの表示を制御する装置としてコンピュータを機能させるプログラムであって、
    前記コンピュータを、
    第１の言語で記述された文書データを表示するための第１のクライアントから、表示対象の第１の文書データの第１の識別情報を受け付ける受付部と、
    前記受付部により受け付けた前記第１の識別情報に基づいて、前記第１の文書データに対応し、かつ、第２の言語で記述された第２の文書データの第２の識別情報を取得する取得部と、
    前記取得部により取得された前記第２の識別情報に基づいて、前記第２の言語で記述された文書データを表示するための第２のクライアントが前記第２の文書データを表示するように制御する制御部と
    して機能させる、プログラム。

Images