JP2011034290A - 中継装置、中継方法、および中継プログラム - Google Patents

Abstract

【課題】ネットワーク内で中継するリクエストから欠落しているリクエスト元のアクセス状態を識別するための状態データを補完してリクエスト先に転送すること
【解決手段】中継サーバ１０２は、リクエスト先からレスポンス２０３を受信して、そのレスポンス２０３の中からクッキー２０４を抽出し、リクエスト先と関連付けてクッキーＤＢ１２０に登録する。これ以降において、中継サーバ１０２は、リクエスト元からリクエスト２０７を受信し、そのリクエスト先に対応するクッキー２０４を、クッキーＤＢ１２０の中から検索する。そして、中継サーバ１０２は、検索されたクッキー２０４をリクエスト２０７に付加してリクエスト先に送信する。
【選択図】図２

Description

本発明は、ネットワークを介して通信を中継する中継装置、中継方法、および中継プログラムに関する。

近年、Ｗｅｂ技術の発展にともない各種のＷｅｂサービスが提供されるようになっている。また、新しいＷｅｂの使い方として、従来のように自サイトのＷｅｂページを提供するだけでなく、他サイトの情報を加工して表示したり、他サイトが提供する画面を部品として組み込むような使い方が注目を集めている。

具体的には、たとえば、他サイトの内容を翻訳してユーザに提供する翻訳サイトや、既存のＷｅｂシステムにマッシュアップ機能を追加するサーバなどがある。このような新しいＷｅｂの使い方を実現する上で重要になるのが、ユーザのブラウザからのアクセスを中継し目的サーバ（たとえば、Ｗｅｂサーバ）にアクセスする中継サーバの技術である。

翻訳サイトの場合、クライアント端末が中継サーバ経由で目的サーバにアクセスすると、中継サーバが目的サーバから取得したコンテンツに翻訳処理などの加工を行なってクライアント端末に送信する。その結果、ユーザは、通常と同様にＷｅｂページを閲覧するだけで翻訳された内容を見ることができる。

また、中継サーバは、目的によって使い分けたり、インターネット上に置かれることが多い。このため、クライアント端末のブラウザで設定するプロキシサーバではなく、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プロキシと呼ばれる方式をとることが一般的である。

ＣＧＩプロキシを使って目的サーバにアクセスするには、中継サーバのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に目的サーバのＵＲＬを結合したＵＲＬを使って中継サーバにアクセスする。たとえば、ユーザが目的サーバのＵＲＬを引数として中継サーバにアクセスすると、中継サーバがホスト名の文字列を解釈して目的サーバのＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）に変換し、目的サーバにアクセスする。

一方で、中継サーバの技術を用いる場合、Ｗｅｂサイトがユーザを識別するためなどに使用するクッキーの扱いには注意が必要となる。クッキーとは、目的サーバがレスポンスの一部としてクライアント端末に送る文字列である。クライアント端末が目的サーバにリクエストを送信する際に、その目的サーバから以前に送られてきたクッキーがあれば、それをリクエストに付加して送信する。

その結果、目的サーバは、リクエストに付加されたクッキーを使って以前にアクセスのあったクライアント端末かどうかを識別することができる。この仕組みを利用することで、以前の閲覧状態の続きを表示させるといったサービスが提供できるため、多くのサイトで使用されている。

中継サーバの技術を用いる場合、当然このクッキーも中継する必要がある。ところが、クッキーには目的サーバのドメイン、パスの情報が含まれている。そのため、クライアント端末から見た場合、アクセス先は中継サーバとなり、それとは異なるドメインのクッキーが送られてきても正しく扱えないという問題が発生する。

そこで、中継サーバ経由でもクッキーを扱えるようにする技術が開発されている（たとえば、下記特許文献１参照。）。具体的には、たとえば、中継サーバにおいて目的サーバのドメイン、パスをクッキー名に追加する書き換えを行なって元の情報を保持する技術がある。さらに、Ｗｅｂページ内にＪａｖａＳｃｒｉｐｔ（登録商標）を挿入し、ＪａｖａＳｃｒｉｐｔ内からクッキーの参照・更新を行なう際の処理を上書きして、クッキーが書き換えられていても元と同じ動作をするようにする技術がある（たとえば、下記特許文献２参照。）。

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

しかしながら、中継サーバを用いてクッキーを中継する場合、クライアント端末のブラウザ側から見ると、中継されるすべてのクッキーが中継サーバから送信されていることになる。一方、ブラウザ側では、１サーバに対するクッキーは５０個程度しか保持できないという保持制限がある。

そのため、中継サーバ経由で閲覧しているすべての目的サーバのクッキーの合計が５０個を超えると、たとえば、ブラウザ内で最も使われていないクッキーから順に削除されてしまう。したがって、上述した従来技術では、ユーザが中継サーバ経由で多くのサイトを閲覧すると、ブラウザの保持制限によりクッキーが削除され、ユーザを識別するためのクッキーの機能が使えなくなる場合があるという問題がある。

図４９は、従来技術の問題点を示す説明図である。図４９において、クライアント端末４９０１は、中継サーバ４９０２を介して各目的サーバ４９０３〜４９０５にアクセスする。ここで、クライアント端末４９０１における１サーバに対するクッキーの保持制限を５０個とする。

クライアント端末４９０１のブラウザ側から見ると、各目的サーバ４９０３〜４９０５で使用するすべてのクッキー（各２０個）が中継サーバ４９０２から送信されていることになる。すなわち、中継サーバ４９０２において、各目的サーバ４９０３〜４９０５で使用するすべてのクッキーのドメインＡ〜Ｃを、中継サーバ４９０２のドメインＤに書き換えている。

このため、クライアント端末４９０１のブラウザ側から見ると、中継サーバ４９０２から送信されるクッキー数が６０個となり制限数を超えてしまう。その結果、クライアント端末４９０１において、クッキーＤＢ（データベース）４９１０から１０個のクッキーが削除され、ユーザを識別するためのクッキーの機能が使えなくなる場合がある。

なお、１サーバに対して保持可能なクッキー数を増やすことも考えられる。しかしながら、クッキーの保持制限は、ブラウザ側に予め組み込まれている制約である。そのため、ユーザが任意に制限数を増やすなどの設計変更を行なうことが難しいという問題がある。

本発明は、上述した従来技術による問題点を解消するため、ネットワーク内で中継するリクエストから欠落しているリクエスト元のアクセス状態を識別するための状態データを補完してリクエスト先に転送することができる中継装置、中継方法、および中継プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本開示技術は、リクエスト先からレスポンスを受信し、そのレスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、リクエスト先と関連付けてデータベースに登録する。そして、本開示技術は、リクエスト元からリクエストを受信し、そのリクエスト先に対応する状態データをデータベース内の状態データ群の中から検索し、検索された状態データをリクエストに付加してリクエスト先に送信することを特徴とする。

本中継装置、中継方法、および中継プログラムによれば、ネットワーク内で中継するリクエストから欠落しているリクエスト元のアクセス状態を識別するための状態データを補完してリクエスト先に転送することができるという効果を奏する。

ネットワークシステムのシステム構成の一例を示す説明図である。 本中継手法の一実施例を示す説明図である。 ＵＲＬの変換処理手順の一例を示すフローチャートである。 ＵＲＬの復元処理手順の一例を示すフローチャートである。 中継サーバのハードウェア構成を示すブロック図である。 クッキーＤＢの記憶内容の一例を示す説明図である。 中継サーバの機能的構成を示すブロック図である。 リクエストの一例を示す説明図である。 端末対応テーブルの記憶内容の一例を示す説明図である。 レスポンスの一例を示す説明図である。 ＵＲＬの復元例を示す説明図である。 クッキーの変換例を示す説明図である。 クッキーの復元例を示す説明図である。 復元後のクッキーの付加例を示す説明図である。 識別用クッキーの付加例を示す説明図である。 欠落しているクッキーの補完例を示す説明図である。 ＪａｖａＳｃｒｉｐｔコードの置換例を示す説明図である。 ＪａｖａＳｃｒｉｐｔコードの挿入例を示す説明図である。 リクエストの加工例を示す説明図（その１）である。 リクエストの加工例を示す説明図（その２）である。 リクエストヘッダの加工例を示す説明図である。 レスポンスの加工例を示す説明図（その１）である。 レスポンスの加工例を示す説明図（その２）である。 レスポンスヘッダの加工例を示す説明図である。 レスポンスボディの加工例を示す説明図である。 中継サーバの要求中継処理手順の一例を示すフローチャートである。 セッション管理処理の具体的処理手順を示すフローチャートである。 クッキー復元処理の具体的処理手順を示すフローチャートである。 クッキー補完処理の具体的処理手順を示すフローチャートである。 中継サーバの応答中継処理手順の一例を示すフローチャートである。 識別用クッキー付加処理の具体的処理手順の一例を示すフローチャートである。 クッキー変換処理の具体的処理手順の一例を示すフローチャートである。 クライアント端末のクッキー参照処理手順の一例を示すフローチャートである。 ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅの値を参照して得られる文字列の一例を示す説明図である。 元クッキーリストの記憶内容の一例を示す説明図である。 クライアント端末のクッキー更新処理手順の一例を示すフローチャート（その１）である。 コード例を示す説明図である。 クッキー設定文字列の一例を示す説明図である。 更新履歴の具体例を示す説明図である。 クッキー復元部７０３が備える機能的構成を示すブロック図である。 中継サーバの更新履歴リストの記憶内容の一例を示す説明図である。 中継サーバの更新履歴処理手順の一例を示すフローチャートである。 クライアント端末のクッキー更新処理手順の一例を示すフローチャート（その２）である。 更新履歴追加処理の具体的処理手順の一例を示すフローチャートである。 クッキー値の具体例を示す説明図である。 クライアント端末の更新履歴リストの記憶内容の一例を示す説明図である。 エントリが追加された更新履歴リストの記憶内容の一例を示す説明図である。 文字列の一例を示す説明図である。 従来技術の問題点を示す説明図である。

以下に添付図面を参照して、この発明にかかる中継装置、中継方法、および中継プログラムの好適な実施の形態を詳細に説明する。なお、本明細書において、中継装置は中継サーバである。また、リクエスト元のアクセス状態を識別するための状態データを「クッキー」と表記する。

（実施の形態１）
まず、実施の形態１にかかるネットワークシステムのシステム構成について説明する。図１は、ネットワークシステムのシステム構成の一例を示す説明図である。ネットワークシステム１００では、クライアント端末１０１と、中継サーバ１０２と、目的サーバ１０３〜１０５と、がインターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワーク１５０を介して相互に通信可能に接続されている。

クライアント端末１０１は、クッキーＤＢ（データベース）１１０を備え、各目的サーバ１０３〜１０５から提供される情報（たとえば、Ｗｅｂページ）を閲覧するためのブラウザを有する。クッキーＤＢ１１０は、レスポンスに付加されているクッキーを保持する記憶装置である。ただし、クッキーＤＢ１１０には、１サーバに対して予め定められた数（たとえば、５０個）を限度としてクッキーが保持される。

中継サーバ１０２は、クッキーＤＢ１２０を備え、クライアント端末１０１と各目的サーバ１０３〜１０５との通信を中継する機能を有する。具体的には、たとえば、中継サーバ１０２は、クライアント端末／目的サーバ間のデータを、中継サーバ１０２経由でアクセス可能な形式に変換して中継する。なお、クッキーＤＢ１２０の記憶内容については図６を用いて後述する。

目的サーバ１０３〜１０５は、サービス提供用のサーバであり、たとえば、クライアント端末１０１のブラウザからの要求に応じてＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書や画像などの情報を提供するＷｅｂサーバである。

ネットワークシステム１００では、ユーザはクライアント端末１０１から中継サーバ１０２を介して各目的サーバ１０３〜１０５にアクセスする。そして、ネットワークシステム１００では、他のサービス（システム）と連携可能に設計されていない各目的サーバ１０３〜１０５の入出力を、中継サーバ１０２で加工して連携可能な入出力に置き換えることにより、サービス間連携を実現する。

また、ネットワークシステム１００では、クライアント端末１０１が、中継サーバ１０２経由で各目的サーバ１０３〜１０５にアクセスする。このため、ユーザには、各目的サーバ１０３〜１０５のＵＲＬではなく、特殊な加工を施したＵＲＬを指定させることになる。

（本中継手法の一実施例）
つぎに、本中継手法の一実施例について説明する。図２は、本中継手法の一実施例を示す説明図である。ここでは、クライアント端末１０１が中継サーバ１０２を介して目的サーバ１０３にアクセスする場合を例に挙げて、本中継手法の一実施例を説明する。

（１）クライアント端末１０１が、目的サーバ１０３に対するリクエスト２０１を中継サーバ１０２に送信する。ここで、リクエスト先のＵＲＬは、中継サーバ１０２経由で目的サーバ１０３にアクセス可能な形式に変換されている。なお、ＵＲＬの変換方法については図３を用いて後述する。

（２）中継サーバ１０２が、クライアント端末１０１からリクエスト２０１を受信し、リクエスト先のＵＲＬを目的サーバ１０３に送信可能な形式に復元するとともに、リクエスト２０１を加工する。なお、ＵＲＬの復元方法については図４を用いて後述する。また、リクエストの加工方法については図１９〜図２１を用いて後述する。

（３）中継サーバ１０２が、復元後のＵＲＬを用いて、リクエスト２０２（加工後）を目的サーバ１０３に送信する。

（４）目的サーバ１０３が、中継サーバ１０２からリクエスト２０２を受信し、リクエスト２０２に対するレスポンス２０３を中継サーバ１０２に送信する。ここで、レスポンス２０３には、リクエスト元のユーザ（ブラウザ）を識別するためのクッキー２０４が付加されている。

（５）中継サーバ１０２が、目的サーバ１０３からレスポンス２０３を受信し、レスポンス２０３に含まれているクッキー２０４を抽出してクッキーＤＢ１２０に登録する。

（６）中継サーバ１０２が、クッキー２０４を、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換するとともに、レスポンス２０３を加工する。なお、クッキーの変換方法については図１２を用いて後述する。また、レスポンスの加工方法については図２２〜図２５を用いて後述する。

（７）中継サーバ１０２が、変換後のクッキー２０５が付加されたレスポンス２０６（加工後）をクライアント端末１０１に送信する。

（８）クライアント端末１０１が、中継サーバ１０２からレスポンス２０６を受信し、レスポンス２０６に付加されているクッキー２０５をクッキーＤＢ１１０に登録する。

ここで、クライアント端末１０１では、中継サーバ１０２から取得したクッキーの合計が１サーバに対する保持制限を超えて、クッキーＤＢ１１０からクッキー２０５が削除されたとする。

（９）クライアント端末１０１が、目的サーバ１０３に対するリクエスト２０７を中継サーバ１０２に送信する。ただし、クッキーＤＢ１１０からクッキー２０５が削除されているため、本来付加すべきクッキー２０５がリクエスト２０７から欠落している。

（１０）中継サーバ１０２が、クライアント端末１０１からリクエスト２０７を受信し、上記（２）と同様に、リクエスト先のＵＲＬを復元するとともにリクエスト２０７を加工する。

（１１）中継サーバ１０２が、リクエスト２０８（加工後）から欠落しているクッキー２０４をクッキーＤＢ１２０の中から検索する。

（１２）中継サーバ１０２が、検索されたクッキー２０４をリクエスト２０８に付加して目的サーバ１０３に送信する。

このように、本中継手法によれば、中継サーバ１０２において、リクエスト２０７から欠落しているクッキー２０５（２０４）を補完して目的サーバ１０３に転送することができる。これにより、クライアント端末１０１のブラウザ側のクッキーの保持制限による問題を回避して、目的サーバ１０３側での処理を正常に行なえるようになる。

（ＵＲＬの変換方法）
ここで、中継サーバ１０２経由で各目的サーバ１０３〜１０５にアクセス可能な形式にリクエスト先のＵＲＬを変換する変換方法について説明する。図３は、ＵＲＬの変換処理手順の一例を示すフローチャートである。なお、ここでは一例として、ＵＲＬを変換する実行主体を中継サーバ１０２とする。

中継サーバ１０２により、変換対象のＵＲＬからプロトコル、ＦＱＤＮおよびポート番号の文字列を抽出する（ステップＳ３０１）。ただし、ポート番号については省略されている場合を除く。なお、ＵＲＬは予め定められたフォーマットで記述されている。そのため、中継サーバ１０２は、そのフォーマットにしたがってＵＲＬを読み込むことで、プロトコル、ＦＱＤＮおよびポート番号の文字列を認識できる。

中継サーバ１０２により、ＦＱＤＮ文字列にハイフンが含まれているか否かを判断する（ステップＳ３０２）。ここで、ハイフンが含まれている場合（ステップＳ３０２：Ｙｅｓ）、そのハイフンを、ハイフン２つに置換する（ステップＳ３０３）。一方、ハイフンが含まれていない場合（ステップＳ３０２：Ｎｏ）、ステップＳ３０４に移行する。

中継サーバ１０２により、ＦＱＤＮ文字列（ハイフン置換後）のドットをハイフンに置換する（ステップＳ３０４）。中継サーバ１０２により、ステップＳ３０１において抽出されたプロトコル文字列（ｈｔｔｐ、ｈｔｔｐｓなど）を、ＦＱＤＮ文字列（ドット置換後）の前にハイフンで連結する（ステップＳ３０５）。

中継サーバ１０２により、ステップＳ３０１においてポート番号文字列が抽出されたか否かを判断する（ステップＳ３０６）。ここで、ポート番号文字列が抽出されている場合（ステップＳ３０６：Ｙｅｓ）、ステップＳ３０５において生成された文字列の後ろにハイフン２つで連結する（ステップＳ３０７）。一方、ポート番号文字列が未抽出の場合（ステップＳ３０６：Ｎｏ）、ステップＳ３０８に移行する。

中継サーバ１０２により、ステップＳ３０５またはステップＳ３０７において生成された文字列をホスト名として、中継サーバ１０２のドメインに付加する形で、ＵＲＬを生成する（ステップＳ３０８）。

これにより、各目的サーバ１０３〜１０５のＵＲＬを、クライアント端末１０１が中継サーバ１０２を介して各目的サーバ１０３〜１０５にアクセス可能なＵＲＬに変換することができる。なお、ＵＲＬの変換方法として、上述した変換方法のほか、ＣＧＩパラメタを使用した方式やパスを使用した方式などを用いることにしてもよい。

（ＵＲＬの復元方法）
つぎに、図３に示した変換方法により変換されたＵＲＬを、元のＵＲＬに復元する復元方法の一例について説明する。図４は、ＵＲＬの復元処理手順の一例を示すフローチャートである。

中継サーバ１０２により、復元対象のＵＲＬのホスト名文字列（ＦＱＤＮの一番左側の要素）を抽出する（ステップＳ４０１）。中継サーバ１０２により、抽出された文字列（先頭がｈｔｔｐ−またはｈｔｔｐｓ−で始まる文字列）の先頭文字列をプロトコル文字列として抽出する（ステップＳ４０２）。

中継サーバ１０２により、ステップＳ４０１において抽出された文字列の末尾がハイフン２つに続く数字列となっているか否かを判断する（ステップＳ４０３）。ここで、末尾が数字列となっている場合（ステップＳ４０３：Ｙｅｓ）、その数字列をポート番号文字列として抽出する（ステップＳ４０４）。一方、末尾が数字列となっていない場合（ステップＳ４０３：Ｎｏ）、ポート番号文字列の抽出を省略する。

中継サーバ１０２により、ステップＳ４０１において抽出された文字列から、ステップＳ４０２およびステップＳ４０３の解釈に用いた先頭および末尾の文字列を削除する（ステップＳ４０５）。中継サーバ１０２により、削除後の文字列のハイフンをすべてドットに置換してＦＱＤＮ文字列を生成する（ステップＳ４０６）。

中継サーバ１０２により、ステップＳ４０６において生成された文字列に２つ連続するドットがあるか否かを判断する（ステップＳ４０７）。ここで、ドットが２つ連続する場合（ステップＳ４０７：Ｙｅｓ）、その２つのドットを１つのハイフンに置換してＦＱＤＮ文字列を生成する（ステップＳ４０８）。一方、２つ連続するドットがない場合（ステップＳ４０７：Ｎｏ）、ステップＳ４０９に移行する。

中継サーバ１０２により、ステップＳ４０２において抽出されたプロトコル文字列、ステップＳ４０６またはステップＳ４０８において生成されたＦＱＤＮ文字列、およびステップＳ４０４において抽出されたポート番号文字列を用いて、ＵＲＬを生成する（ステップＳ４０９）。

これにより、図３に示した変換方法により変換されたＵＲＬを、中継サーバ１０２が各目的サーバ１０３〜１０５に送信可能な形式に復元することができる。

（中継サーバのハードウェア構成）
つぎに、中継サーバ１０２のハードウェア構成について説明する。図５は、中継サーバのハードウェア構成を示すブロック図である。図５において、中継サーバ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０３と、磁気ディスクドライブ５０４と、磁気ディスク５０５と、光ディスクドライブ５０６と、光ディスク５０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）５０８と、操作パネル５０９と、を備えている。また、各構成部はバス５００によってそれぞれ接続されている。

ここで、ＣＰＵ５０１は、中継サーバ１０２の全体の制御を司る。ＲＯＭ５０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。磁気ディスクドライブ５０４は、ＣＰＵ５０１の制御にしたがって磁気ディスク５０５に対するデータのリード／ライトを制御する。磁気ディスク５０５は、磁気ディスクドライブ５０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ５０６は、ＣＰＵ５０１の制御にしたがって光ディスク５０７に対するデータのリード／ライトを制御する。光ディスク５０７は、光ディスクドライブ５０６の制御で書き込まれたデータを記憶したり、光ディスク５０７に記憶されたデータをコンピュータに読み取らせたりする。

インターフェース（以下、「Ｉ／Ｆ」と略する。）５０８は、通信回線を通じてＬＡＮ、ＷＡＮ、インターネットなどのネットワーク１５０に接続され、このネットワーク１５０を介して他の装置に接続される。そして、Ｉ／Ｆ５０８は、ネットワーク１５０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ５０８には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

操作パネル５０９は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。なお、ここでは中継サーバ１０２のハードウェア構成について説明したが、クライアント端末１０１および目的サーバ１０３〜１０５についても同様のハードウェア構成により実現できる。

（クッキーＤＢの記憶内容）
つぎに、中継サーバ１０２が備えるクッキーＤＢ１２０の記憶内容について説明する。図６は、クッキーＤＢの記憶内容の一例を示す説明図である。図６において、クッキーＤＢ１２０は、クライアントＩＤ、セッションＩＤ、ドメイン名、パス名、クッキー名、クッキー値、有効期限およびセキュアフラグのフィールドを有する。各フィールドに情報を設定することで、クッキー情報６００−１〜６００−６がレコードとして記憶されている。

ここで、クライアントＩＤとは、ユーザ（ブラウザ）の識別子であり、たとえば、後述する端末識別用のクッキーの値である。セッションＩＤとは、セッションの識別子であり、たとえば、後述するセッション識別用のクッキーの値である。ドメイン名とは、リクエスト先のドメイン名である。パス名とは、リクエスト先のパス名である。なお、ドメイン名はネットワーク１５０上でのコンピュータの住所（名前）を示し、パス名はリクエスト対象となるデータの格納場所を示す。

クッキー名とは、クッキーの名前である。クッキー値とは、クッキーの値である。有効期限とは、クッキーの有効期限である。セキュアフラグとは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）通信時に指定するフラグである。ここでは、ＳＳＬ通信にのみクッキーを送信する場合に有効が設定され、ＳＳＬ通信でなくても送信する場合に無効が設定される。

（中継サーバの機能的構成）
つぎに、中継サーバ１０２の機能的構成について説明する。図７は、中継サーバの機能的構成を示すブロック図である。図７において、中継サーバ１０２は、要求受信部７０１と、要求解釈部７０２と、クッキー復元部７０３と、第１付加部７０４と、判定部７０５と、検索部７０６と、セッション管理部７０７と、要求送信制御部７０８と、要求送信部７０９と、応答受信部７１０と、抽出部７１１と、登録部７１２と、応答解釈部７１３と、クッキー変換部７１４と、第２付加部７１５と、コード置換部７１６と、応答変換部７１７と、応答送信制御部７１８と、応答送信部７１９と、を含む構成である。

この制御部となる機能（要求受信部７０１〜応答送信部７１９）は、具体的には、たとえば、図５に示したＲＯＭ５０２、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０８により、その機能を実現する。なお、以降の説明において、特に指定する場合を除いて、目的サーバ１０３〜１０５を単に「目的サーバ１０３」と表記する。

要求受信部７０１は、クライアント端末１０１からリクエストを受信する機能を有する。ここで、リクエストとは、たとえば、目的サーバ１０３のＷｅｂサイトにＷｅｂページを要求するためのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエスト（図８参照）である。

リクエストの宛先は、たとえば、上述した変換方法（図３参照）により、中継サーバ１０２を経由してクライアント端末１０１から目的サーバ１０３にアクセス可能な形式に変換されている。なお、受信されたリクエストは、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。

図８は、リクエストの一例を示す説明図である。ここで、リクエストは、予め定められたフォーマットにしたがって記述されている。図８において、リクエスト８００は、リクエスト行８１０とリクエストヘッダ８２０とリクエストボディ８３０を有する。リクエスト行８１０には、メソッド、パス名、バージョンなどが記述される。リクエストヘッダ８２０には、ブラウザ側でサポートするデータのタイプ、データ圧縮の方法、ブラウザの種類、クッキーなどが記述される。リクエストボディ８３０には、Ｗｅｂページの入力欄などに記入したテキストなどが記述される。

ここで、リクエストヘッダ８２０には、クッキー８２１〜８２４が記述されている。クッキー８２１は、クッキー名『＿ｃｌｉｅｎｔ＿ｉｄ』、クッキー値『ａｂ２３４５６ｄ』の端末識別用のクッキーである。クッキー８２２は、クッキー名『＿ｓｅｓｓｉｏｎ』、クッキー値『ｔｒｕｅ』のセッション識別用のクッキーである。なお、端末識別用およびセッション識別用のクッキーについての詳細な説明は後述する。また、クッキー８２３，８２４は、あるＷｅｂサイトで使用するクッキーであり、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換されている。

図７の説明に戻り、要求解釈部７０２は、受信されたリクエストの宛先を復元する機能を有する。ここで、リクエストの宛先は、リクエスト先のＵＲＬであり、クライアント端末１０１が中継サーバ１０２経由で目的サーバ１０３にアクセス可能な形式に変換されている。

具体的には、たとえば、要求解釈部７０２が、図４に示した復元方法により、リクエストの宛先を、目的サーバ１０３に送信可能な形式に復元する。復元された復元結果は、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。なお、ＵＲＬの復元例については図１１を用いて後述する。

また、要求解釈部７０２は、リクエストを加工する機能を有する。ここで、リクエストは、クライアント端末１０１が中継サーバ１０２を経由して目的サーバ１０３にアクセス可能な形式に変換されている。そこで、要求解釈部７０２が、目的サーバ１０３が認識可能な形式にリクエストを加工する。加工された加工結果は、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。なお、リクエストの加工例については図１９〜図２１を用いて後述する。

クッキー復元部７０３は、リクエストに含まれているクッキーを復元する機能を有する。ここで、リクエストに含まれているクッキーは、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換されている。このため、クッキー復元部７０３が、目的サーバ１０３が認識可能な形式にクッキーを復元する。なお、クッキーの復元例については図１３を用いて後述する。

第１付加部７０４は、復元されたクッキーをリクエストに付加する機能を有する。具体的には、たとえば、第１付加部７０４が、リクエストヘッダに含まれている復元前のクッキーを、復元後のクッキーに置き換える。また、第１付加部７０４は、後述する判定部７０５の判定結果に基づいて、復元後のクッキーを付加することにしてもよい。

判定部７０５は、復元されたクッキーのドメイン名が、リクエスト先のＵＲＬに含まれるドメイン名と一致、または、上位のドメイン名となっているか否かを判定する機能を有する。ここで、リクエスト先のＵＲＬに含まれるドメイン名を『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』とする。この場合、このドメイン名の上位のドメイン名は『ｅｘａｍｐｌｅ．ｃｏｍ』または『．ｃｏｍ』となる。ただし『．ｃｏｍ』はトップレベルドメインであるため不可である。

また、判定部７０５は、復元されたクッキーのパス名が、リクエスト先のＵＲＬに含まれるパス名と先頭一致するか否かを判定する機能を有する。ここで、リクエスト先のＵＲＬに含まれるパス名を『／ａａａ／ｂｂｂ／ｉｎｄｅｘ．ｈｔｍｌ』とする。この場合、『／』や『／ａａａ／ｂ』などと先頭一致する。

また、判定部７０５は、復元されたクッキーのセキュアフラグが有効、かつ、リクエストのプロトコルが暗号化用か否かを判定する機能を有する。具体的には、たとえば、判定部７０５が、復元されたクッキーにセキュアフラグ（Ｓ）が付加され、かつ、リクエスト先のＵＲＬに含まれるプロトコルがｈｔｔｐｓか否かを判定する。なお、判定された判定結果は、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。

また、上記第１付加部７０４は、判定結果が下記（Ａ）〜（Ｃ）の全てを満たす場合に、復元後のクッキーをリクエストに付加することにしてもよい。

（Ａ）復元後のクッキーのドメイン名がリクエスト先のドメイン名と一致または上位
（Ｂ）復元後のクッキーのパス名がリクエスト先のパス名と先頭一致
（Ｃ）復元後のクッキーのセキュアフラグが有効ならばリクエストのプロトコルが暗号化用

上記クッキー復元部７０３、第１付加部７０４、判定部７０５によれば、リクエスト先で有効となるクッキーを目的サーバ１０３が認識可能な形式に復元してリクエストに付加することができる。

検索部７０６は、リクエストの宛先に対応するクッキーをクッキーＤＢ１２０の中から検索する機能を有する。具体的には、たとえば、検索部７０６が、クッキーＤＢ１２０に登録されているクッキー群のうち、下記（Ｄ）かつ（Ｅ）のクッキーを検索することにしてもよい。

（Ｄ）ドメイン名がリクエスト先のＵＲＬに含まれるドメイン名と一致または上位となっているクッキー
（Ｅ）パス名がリクエスト先のＵＲＬに含まれるパス名と先頭一致となっているクッキー

また、検索部７０６は、リクエストが暗号化用のプロトコルではない場合、クッキーＤＢ１２０内のクッキー群のうちセキュアフラグが有効のクッキーを検索対象から除外してもよい。なお、検索された検索結果は、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。

また、第１付加部７０４は、検索されたクッキーをリクエストに付加する機能を有する。具体的には、たとえば、第１付加部７０４が、検索されたクッキーがリクエストから欠落している場合に、そのクッキーをリクエストヘッダに付加する。すなわち、検索されたクッキーを付加することで、たとえば、クライアント端末１０１のブラウザの保持制限によりクッキーＤＢ１１０から削除されたクッキーを補完する。なお、クッキーの補完例については図１６を用いて後述する。

セッション管理部７０７は、クライアント端末１０１とのセッションを管理する機能を有する。具体的には、たとえば、セッション管理部７０７が、図９に示す端末対応テーブル９００を用いて、クライアント端末１０１とのセッションを管理することにしてもよい。ここで、端末対応テーブル９００の記憶内容について説明する。

図９は、端末対応テーブルの記憶内容の一例を示す説明図である。図９において、端末対応テーブル９００は、セッションＩＤおよび端末識別クッキーのフィールドを有し、セッションごとの端末情報９００−１〜９００−３をレコードとして記憶している。ここで、セッションＩＤとは、セッションの識別子である。端末識別クッキーとは、端末識別用のクッキーの値（クライアントＩＤ）である。

セッション管理部７０７は、端末対応テーブル９００を用いてセッションを管理することで、どのユーザ（ブラウザ）からアクセスを受け付けたのかを把握する。なお、セッション管理処理の具体的な処理内容については図２７のフローチャートを用いて後述する。

要求送信部７０９は、リクエストを目的サーバ１０３に転送する機能を有する。具体的には、たとえば、要求送信制御部７０８が、要求送信部７０９を制御して、復元後のＵＲＬを用いて、復元後のクッキーが付加された加工後のリクエストを送信する。また、要求送信制御部７０８が、要求送信部７０９を制御して、復元後のＵＲＬを用いて、検索されたクッキーが付加された加工後のリクエストを送信する。

応答受信部７１０は、目的サーバ１０３からレスポンスを受信する機能を有する。ここで、レスポンスとは、たとえば、要求されたＷｅｂページのＨＴＭＬデータを含むＨＴＴＰレスポンス（図１０参照）である。レスポンスには、リクエスト元のアクセス状態を識別するためのクッキーが含まれている場合がある。なお、受信されたレスポンスは、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。

図１０は、レスポンスの一例を示す説明図である。ここで、レスポンスは、予め定められたフォーマットにしたがって記述されている。図１０において、レスポンス１０００は、ステータス行１０１０と、レスポンスヘッダ１０２０と、レスポンスボディ１０３０とを有する。ステータス行１０１０には、バージョン、ステータス・コード、説明文などが記述される。

レスポンスヘッダ１０２０には、目的サーバ１０３の種類、実際に返信するデータのタイプ、データの圧縮方法、クッキーなどが記述される。レスポンスボディ１０３０には、要求されたＷｅｂページのＨＴＭＬデータなどが記述される。ここで、レスポンスヘッダ１０２０は、クッキー１０２１（Ｓｅｔ−Ｃｏｏｋｉｅ：から始まる１行の文字列）が記述されている。

抽出部７１１は、受信されたレスポンスの中からクッキーを抽出する機能を有する。具体的には、たとえば、抽出部７１１が、レスポンス１０００のレスポンスヘッダ１０２０の中から、Ｓｅｔ−Ｃｏｏｋｉｅ：から始まる１行の文字列をクッキー１０２１として抽出する。なお、抽出された抽出結果は、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶される。

登録部７１２は、抽出されたクッキーを、リクエストの宛先と関連付けてクッキーＤＢ１２０に登録する機能を有する。具体的には、たとえば、登録部７１２が、クッキーのドメイン名が現在のドメイン名と一致または上位のドメイン名となっているか否かを判断する。ここで、ドメイン名が一致または上位の場合、登録部７１２が、クッキーのパス名が現在のパス名と先頭一致となっているか否かを判断する。そして、パス名が先頭一致の場合、登録部７１２が、クッキーに含まれるクッキー名、クッキー値、ドメイン名、パス名、有効期限およびセキュアフラグの設定状態を、クライアントＩＤおよびセッションＩＤと関連付けてクッキーＤＢ１２０に登録する。

応答解釈部７１３は、受信されたレスポンスを加工する機能を有する。具体的には、たとえば、応答解釈部７１３が、クライアント端末１０１が中継サーバ１０２からのものと認識可能な形式にレスポンスを加工する。なお、レスポンスの加工例については図２２〜図２５を用いて後述する。

クッキー変換部７１４は、レスポンスに含まれているクッキーを変換する機能を有する。具体的には、たとえば、クッキー変換部７１４が、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式にクッキーを変換する。なお、クッキーの変換例については図１２を用いて後述する。

第２付加部７１５は、変換されたクッキーをレスポンスに付加する機能を有する。具体的には、たとえば、第２付加部７１５が、レスポンスヘッダに含まれている変換前のクッキーを、変換後のクッキーに置き換える。

また、第２付加部７１５は、リクエストの宛先に対応するクッキーをレスポンスに付加する機能を有する。ここで、リクエストの宛先に対応するクッキーは、上記検索部７０６によって検索されるクッキーである。具体的には、たとえば、第２付加部７１５が、検索されたクッキーがレスポンスから欠落している場合に、そのクッキーをリクエストヘッダに付加する。

すなわち、リクエストに補完されたクッキーが、目的サーバ１０３側でレスポンスに付与されなかった場合に、そのクッキーを再度補完する。このように、以前に受け取ったクッキーもレスポンスに付加してクライアント端末１０１に送信することで、クッキーの保持制限により削除されたクッキーをブラウザから読めなくなることを防ぐことができる。

また、第２付加部７１５は、端末識別用およびセッション識別用のクッキーをレスポンスに付加する機能を有する。端末識別用およびセッション識別用のクッキーのドメイン名は、レスポンスに含まれるクッキー、すなわち、変換されたクッキーのドメイン名とは異なるものを用いる。これにより、ブラウザの保持制限によって端末識別用およびセッション識別用のクッキーが削除されることを防止できる。

また、セッション識別用のクッキーは、有効期限のないクッキー（いわゆるセッションクッキー）とする。これにより、ブラウザが新しいセッションを開始した際に、以前のセッション識別用のクッキーを使うことがないようにする。なお、端末識別用およびセッション識別用のクッキーの付加例については図１５を用いて後述する。

応答送信部７１９は、レスポンスをクライアント端末１０１に送信する機能を有する。具体的には、たとえば、応答送信制御部７１８が、応答送信部７１９を制御して、変換後のクッキーが付加された加工後のレスポンスをクライアント端末１０１に転送する。

コード置換部７１６は、レスポンスボディに格納されているＨＴＭＬ形式のドキュメントのうち、クッキー値を参照・更新するためのコードを書き換える機能を有する。また、コード置換部７１６は、ドキュメント中の特定箇所に、ＳｅｔＣｏｏｋｉｅ関数、ＧｅｔＣｏｏｋｉｅ関数の定義を行なうＪａｖａＳｃｒｉｐｔコードを挿入する機能を有する。ＪａｖａＳｃｒｉｐｔコードの置換例、挿入例については図１７および図１８を用いて後述する。

応答変換部７１７では、レスポンス（応答内容）に対して変更を行なう機能を有する。ただし、この変更は、翻訳サイトやマッシュアップ機能追加装置などの従来技術と同じであり、それぞれの用途によって異なる変更処理が行なわれるため、動作の例と説明は省略する。

（ＵＲＬの復元例）
ここで、ＵＲＬの復元例について説明する。図１１は、ＵＲＬの復元例を示す説明図である。ここでは、図８に示したリクエスト８００の宛先であるＵＲＬの復元例について説明する。図１１において、ＵＲＬ１１１０は、クライアント端末１０１から要求されたＵＲＬである。

（１）要求解釈部７０２が、復元対象のＵＲＬ１１１０の中からホスト名文字列（ＦＱＤＮの一番左側の要素）を抽出する。ここでは、「ｈｔｔｐ：／／ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ．ｒ．ｐｒｏｘｙ．ｃｏｍ／ｍｙｐａｔｈ」から「ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ」が抽出される。

（２）要求解釈部７０２が、上記（１）で抽出された文字列の先頭文字列をプロトコル文字列とする。ここでは、「ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ」の先頭文字列「ｈｔｔｐ−」がプロトコル文字列となり、プロトコルがｈｔｔｐであると解釈される。

（３）要求解釈部７０２が、上記（１）で抽出された文字列から、上記（２）で解釈に用いた先頭の文字列を削除する。ここでは、「ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ」から「ｈｔｔｐ−」が削除される。

（４）要求解釈部７０２が、上記（３）で残った文字列のハイフンをすべてドットに置換してＦＱＤＮ文字列を生成する。ここでは、「ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ」からＦＱＤＮ文字列「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」が生成される。

（５）要求解釈部７０２が、上記（２）のプロトコル文字列および上記（４）で生成されたＦＱＤＮ文字列を用いて、ＵＲＬ１１２０を生成する。ここでは、ＵＲＬ１１２０「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍｙｐａｔｈ」が生成される。

これにより、クライアント端末１０１が中継サーバ１０２経由で目的サーバ１０３にアクセス可能な形式で変換されたＵＲＬ１１１０を、中継サーバ１０２が目的サーバ１０３に送信可能な形式に復元することができる。

（クッキーの変換例）
つぎに、クッキーの変換例について説明する。図１２は、クッキーの変換例を示す説明図である。ここでは、図１０に示したレスポンス１０００のクッキー１０２１の変換例について説明する。なお、ここでは中継サーバ１０２のドメイン名を『ｒ．ｐｒｏｘｙ．ｃｏｍ』とする。

（１）クッキー変換部７１４が、『；』を区切り文字として、元のドメイン名、元のパス名、元のクッキー名を連結して変換後のクッキー名とする。
元のドメイン名『．ｅｘａｍｐｌｅ．ｃｏｍ』、元のパス名『／ｍｙｐａｔｈ』、元のクッキー名『ｆｏｏ』
→．ｅｘａｍｐｌｅ．ｃｏｍ；／ｍｙｐａｔｈ；ｆｏｏ

（２）クッキー変換部７１４が、クッキー名として使用できない文字を（％＋１６進表記の文字）の形式でエスケープする。ここでは、『；』が『％３Ｂ』に置き換えられ、『／』が『％２Ｆ』に置き換えられる。
．ｅｘａｍｐｌｅ．ｃｏｍ；／ｍｙｐａｔｈ；ｆｏｏ
→．ｅｘａｍｐｌｅ．ｃｏｍ％３Ｂ％２Ｆｍｙｐａｔｈ％３Ｂｆｏｏ

（３）クッキー変換部７１４が、元の有効期限文字列内の区切り文字を『−』で置換して、変換後のクッキー値とする。ここでは、有効期限をＧＭＴ（Ｇｒｅｅｎｗｉｃｈ Ｍｅａｎ Ｔｉｍｅ）形式で記述する。
Ｆｒｉ， ２５−Ｍａｒ−２０１１ ０２：１４：３０ ＧＭＴ
→Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴ

（４）クッキー変換部７１４が、元のクッキーのセキュアフラグが有効であれば『Ｓ』を、無効であれば『ｓ』を、変換後のクッキー値の最後に追加する。ここでは、元のクッキーのセキュアフラグは無効である。
Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴ
→Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴｓ

（５）クッキー変換部７１４が、変換後のクッキー値に元のクッキー値を追加する。ここで、元のクッキー値は『ｂａｒ』である。
Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴｓ
→Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴｓｂａｒ

（６）クッキー変換部７１４が、変換後のドメイン名を中継サーバ１０２のドメイン名『．ｒ．ｐｒｏｘｙ．ｃｏｍ』とし、パス名を『／』としてクッキー１２００を生成する。すなわち、クライアント端末１０１が中継サーバ１０２のドメイン名に属するクッキーと認識できるように変換する。なお、ここではドメインを明示的に指定するときには先頭にドットをつける。一方、明示的に指定しないときはリクエストＵＲＩのドメインと同じものが指定されていると解釈する。ただし、先頭のドットはつけない。
→ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ％３Ｂ％２Ｆｍｙｐａｔｈ％３Ｂｆｏｏ＝Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴｓｂａｒ；ｐａｔｈ＝／；ｄｏｍａｉｎ＝．ｒ．ｐｒｏｘｙ．ｃｏｍ；ｅｘｐｉｒｅｓ＝Ｆｒｉ， ２５−Ｍａｒ−２０１１ ０２：１４：３０ ＧＭＴ

これにより、目的サーバ１０３からのレスポンス１０００に付加されているクッキー１０２１を、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換することができる。

（クッキーの復元例）
つぎに、クッキーの復元例について説明する。図１３は、クッキーの復元例を示す説明図である。ここでは、図８に示したリクエスト８００のクッキー８２３，８２４の復元例について説明する。

（１）クッキー復元部７０３が、復元対象となるクッキー８２３，８２４のクッキー名１３０１，１３０２のＵＲＬエンコーディング（％＋１６進表記の文字）を復元する。ここでは、『％３Ｂ』が『；』に置き換えられ、『％２Ｆ』が『／』に置き換えられる。
・クッキー８２３
ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ％３Ｂ％２Ｆｍｙｐａｔｈ％３Ｂｆｏｏ
→ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ；／ｍｙｐａｔｈ；ｆｏｏ
・クッキー８２４
ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍ％３Ｂ％２Ｆ％３Ｂｋｅｙ
→ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍ；／；ｋｅｙ

（２）クッキー復元部７０３が、『；』を区切り文字として、クッキー名１３０１，１３０２を『ドメイン名』、『パス名』、『元のクッキー名』に分解する。
・クッキー８２３
ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ；／ｍｙｐａｔｈ；ｆｏｏ
→ドメイン名『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』、パス名『／ｍｙｐａｔｈ』、元のクッキー名『ｆｏｏ』
・クッキー８２４
ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍ；／；ｋｅｙ
→ドメイン名『ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍ』、パス名『／』、元のクッキー名『ｋｅｙ』

（３）クッキー復元部７０３が、クッキー値１３０３，１３０４のＵＲＬエンコーディング（％＋１６進表記の文字）を復元する。ここでは、クッキー値１３０３，１３０４ともに、％＋１６進表記の文字が含まれていないため処理を省略する。

（４）クッキー復元部７０３が、クッキー値１３０３，１３０４を『有効期限文字列』、『セキュアフラグ』、『元のクッキー値』に分解する。
・クッキー８２３
Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴｓｂａｒ
→有効期限文字列『Ｆｒｉ−２５−Ｍａｒ−２０１１−０２−１４−３０−ＧＭＴ』、セキュアフラグ『ｓ』、元のクッキー値『ｂａｒ』
・クッキー８２４
Ｓａｔ−２９−Ａｐｒ−２０１１−０４−３０−１８−ＧＭＴｓ１２３４
→有効期限文字列『Ｓａｔ−２９−Ａｐｒ−２０１１−０４−３０−１８−ＧＭＴ』、セキュアフラグ『ｓ』、元のクッキー値『１２３４』

（５）クッキー復元部７０３が、クッキー８２３の元のクッキー名『ｆｏｏ』と元のクッキー値『ｂａｒ』を用いて、復元後のクッキー１３１０を生成する。また、クッキー復元部７０３が、クッキー８２４の元のクッキー名『ｋｅｙ』と元のクッキー値『１２３４；』を用いて、復元後のクッキー１３２０を生成する。

これにより、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式で変換されているクッキー８２３，８２４を、目的サーバ１０３が認識可能な形式に復元することができる。

（復元後のクッキーの付加例）
つぎに、復元後のクッキーの付加例について説明する。図１４は、復元後のクッキーの付加例を示す説明図である。ここでは、図１３に示した復元後のクッキー１３１０，１３２０の付加例について説明する。

（１）判定部７０５が、復元後のクッキー１３１０，１３２０のドメイン名が、リクエスト先のドメイン名と一致または上位のドメイン名となっているか否かを判定する。ここで、リクエスト先のドメイン名（復元後のＵＲＬに含まれるドメイン名）は『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』である。また、クッキー１３１０のドメイン名は『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』であり、クッキー１３２０のドメイン名は『ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍ』である。
・クッキー１３１０→ドメイン名一致
・クッキー１３２０→ドメイン名不一致

（２）第１付加部７０４が、上記（１）でドメイン名が一致または上位と判定されたクッキー１３１０をリクエスト８００に付加する。一方、上記（１）でドメイン名が不一致と判定されたクッキー１３２０は付加対象から除外される。これにより、リクエスト先に対して不要なクッキーをリクエストから排除することができる。

（識別用クッキーの付加例）
つぎに、端末識別用のクッキーおよびセッション識別用のクッキーの付加例について説明する。図１５は、識別用クッキーの付加例を示す説明図である。ここでは、図１０に示したレスポンス１０００に端末識別用のクッキーおよびセッション識別用のクッキーを付加する場合について説明する。

（１）第２付加部７１５が、クッキー名『＿ｃｌｉｅｎｔ＿ｉｄ』のクッキー１５１０をレスポンス１０００に付加する。ただし、クッキー１５１０のクッキー値は現在のセッションの端末識別用のクッキー値とし、有効期限は規定値（たとえば、現在から１年後など）とする。また、ドメイン名は中継サーバ１０２のドメイン名と異なる『．ｐｒｏｘｙ．ｃｏｍ』とし、パス名は『／』とし、セキュアフラグは無効とする。これにより、以降において、端末識別用のクッキーを用いて、ユーザを識別することができる。

（２）第２付加部７１５が、クッキー名『＿ｓｅｓｓｉｏｎ』のクッキー１５２０をレスポンス１０００に付加する。ただし、クッキー１５２０のクッキー値は『ｔｒｕｅ』とし、有効期限はなしとする。また、ドメイン名は中継サーバ１０２のドメイン名と異なる『．ｐｒｏｘｙ．ｃｏｍ』とし、パス名は『／』とし、セキュアフラグは無効とする。これにより、以降において、セッション識別用のクッキーを用いて、セッションを識別することができる。

（欠落しているクッキーの補完例）
つぎに、欠落しているクッキーの補完例について説明する。図１６は、欠落しているクッキーの補完例を示す説明図である。図１６において、リクエスト８００のリクエストヘッダ８２０には復元後のクッキー１３１０が記述されている。ここで、リクエスト先のＵＲＬのドメイン名は『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』、パス名は『／ｍｙｐａｔｈ』である。また、リクエスト８００のプロトコルは暗号化用ではない。

（１）検索部７０６が、ドメイン名がリクエスト先のドメイン名と一致または上位でかつパス名がリクエスト先のパス名と先頭一致のクッキーをクッキーＤＢ１２０の中から検索する。ここでは、クッキー『ｆｏｏ＝ｂａｒ』（クッキー情報６００−１）とクッキー『ｃｌｉｅｎｔ＝ｉｅ』（クッキー情報６００−２）が検索される。

（２）第１付加部７０４が、検索されたクッキーがリクエスト８００に付加されているか否かを判断する。ここで、リクエスト８００に、クッキー『ｆｏｏ＝ｂａｒ』（クッキー１３１０）は付加されているが、クッキー『ｃｌｉｅｎｔ＝ｉｅ』は付加されていない。

（３）第１付加部７０４が、クッキー『ｃｌｉｅｎｔ＝ｉｅ』（クッキー１６１０）をリクエスト８００のリクエストヘッダ８２０に付加する。これにより、クライアント端末１０１のブラウザ側のクッキーの保持制限により欠落しているクッキーを補完することができる。

（コードの置換例）
つぎに、上記コード置換部７１６によるコードの置換例について説明する。図１７は、ＪａｖａＳｃｒｉｐｔコードの置換例を示す説明図である。コード置換部７１６は、ＨＴＭＬ形式のドキュメントかＪａｖａＳｃｒｉｐｔ形式の内容に対して、ＪａｖａＳｃｒｉｐｔコードによってクッキー値を参照・更新している部分の書き換えを行なう。ＪａｖａＳｃｒｉｐｔコード中では、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ１７１０という変数がクッキーを表わしており、これの参照・更新がクッキー値の読取・書換処理となっている。

したがって、ＪａｖａＳｃｒｉｐｔコード中で、”ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ＝更新値”（符号１７２０）というパターンに合致する文を、”ＳｅｔＣｏｏｋｉｅ（更新値）”（符号１７３０）という関数の呼び出しに置換する。そのあと”ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ”（符号１７１０）という変数を使用している箇所を”ＧｅｔＣｏｏｋｉｅ（）”（符号１７４０）という関数の呼び出しに置換する。

（コードの挿入例）
つぎに、上記コード置換部７１６によるコードの挿入例について説明する。図１８は、ＪａｖａＳｃｒｉｐｔコードの挿入例を示す説明図である。コード置換部７１６は、ＨＴＭＬ形式のドキュメント中の特定箇所（＜ｈｅａｄ＞タグの直後など）に、ＳｅｔＣｏｏｋｉｅ関数、ＧｅｔＣｏｏｋｉｅ関数の定義を行なうＪａｖａＳｃｒｉｐｔコード１８００を挿入する。なお、ＧｅｔＣｏｏｋｉｅ関数やＳｅｔＣｏｏｋｉｅ関数の定義は一か所だけでよい。ここでは、置換対象となるＨＴＭＬ形式およびＪａｖａＳｃｒｉｐｔ形式のうち、関数の挿入を「ＨＴＭＬ形式のドキュメント中」に限定して説明する。また、ＪａｖａＳｃｒｉｐｔコードは、コードテーブル（不図示）に格納されている。なお、コードテーブルとは、ＳｅｔＣｏｏｋｉｅ関数、ＧｅｔＣｏｏｋｉｅ関数の定義を行なうＪａｖａＳｃｒｉｐｔコード（たとえば、ＪａｖａＳｃｒｉｐｔコード１８００）を保持するテーブルである。コードテーブルは、たとえば、ＲＡＭ５０３、磁気ディスク５０５、光ディスク５０７などの記憶装置に記憶されている。

ＧｅｔＣｏｏｋｉｅ関数は、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅへの参照を行なっていた箇所から呼び出され、変換された形式のクッキーを解釈して、変換前の形式で参照できるようにする。ＳｅｔＣｏｏｋｉｅ関数は、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅへの更新を行なっていた箇所から呼び出され、変換前の形式での更新値を解釈して、変換後のクッキー名、クッキー値で更新を行なうようにする。

なお、ＪａｖａＳｃｒｉｐｔコードからクッキーの削除を行なう場合は、有効期限を過去の値にしてｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅの更新を行なうことになっているため、クッキーの削除用の処理は更新用の処理と同じである。

（リクエストの加工例）
つぎに、上記要求解釈部７０２によるリクエストの加工例について説明する。図１９および図２０は、リクエストの加工例を示す説明図である。また、図２１は、リクエストヘッダの加工例を示す説明図である。図１９に示す例では、リクエスト１９００に含まれる情報のうち、メソッド、パス、およびリクエストボディは加工しない。一方、リクエストヘッダは図２０に示すように加工される。

図２０において、リクエストヘッダに含まれる情報のうち、ＨｏｓｔおよびＲｅｆｅｒｅｒは図４に示したＵＲＬの復元方法により加工され、Ａｃｃｅｐｔ、Ｉｆ−Ｍｏｄｉｆｉｅｄ−ＳｉｎｃｅおよびＵｓｅｒ−Ａｇｅｎｔは加工されない。具体的には、たとえば、図２１に示すように、リクエストヘッダ２１１０は、加工されてリクエストヘッダ２１２０に変換される。

（レスポンスの加工例）
つぎに、上記応答解釈部７１３によるレスポンスの加工例について説明する。図２２および図２３は、レスポンスの加工例を示す説明図である。また、図２４は、レスポンスヘッダの加工例を示す説明図である。また、図２５は、レスポンスボディの加工例を示す説明図である。

図２２に示す例では、レスポンス２２００に含まれる情報のうち、ステータス行は加工されない。レスポンスボディは、ＭＩＭＥタイプを示すＣｏｎｔｅｎｔ−Ｔｙｐｅがｔｅｘｔ／＊の場合は、ボディ全体に対して、図３に示した変換方法により加工される。さらに、Ｃｏｎｔｅｎｔ−Ｔｙｐｅがｔｅｘｔ／ｈｔｍｌの場合は、ＳＣＲＩＰＴタグが挿入される。ただし、Ｆｒａｍｅｓｅｔタグが発見されたときは、ＳＣＲＩＰＴタグの挿入は行なわれない。

レスポンスヘッダは、図２３に示すように加工される。具体的には、レスポンスヘッダに含まれる情報のうち、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ、Ｃｏｎｔｅｎｔ−ＤｉｓｐｏｓｉｔｉｏｎおよびＥｘｐｉｒｅｓは加工されない。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈは、加工後のレスポンスボディの長さに変更され、Ｔｒａｎｓｆｅｒ−ＥｎｃｏｄｉｎｇとＣｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇはエンコーディング方式に合わせて設定し直す。Ｓｅｔ−Ｃｏｏｋｉｅは、図１２に示したような変換方法により加工される。

Ｌｏｃａｔｉｏｎは、図３に示した変換方法により加工され、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅは、シングルサインオンを行なう場合を除いて加工されない。より具体的には、たとえば、図２４に示すように、レスポンスヘッダ２４１０は、加工されてレスポンスヘッダ２４２０に変換される。また、図２５に示すように、レスポンスボディ２５１０は、加工されてレスポンスボディ２５２０に変換される。

この場合、図２４に示すレスポンスヘッダ２４１０のＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈは、６１１０から６４３２に変換され、図２５に示すレスポンスボディ２５２０には、ＳＣＲＩＰＴタグが挿入されている。このレスポンス２２００を受信したクライアント端末１０１のブラウザは、ＳＣＲＩＰＴタグにより指定されたスクリプトを使用して中継サーバ１０２によって機能を付加することもできる。

ユーザは、目的サーバ１０３と挿入したいスクリプトの組をユーザ情報として、予め中継サーバ１０２に登録しておくこともできる。この場合、セッション管理部７０７は、ユーザ情報を参照してユーザを特定し、応答変換部７１７は、その指定に応じたスクリプトをレスポンスボディに挿入することになる。

（中継サーバの各種処理手順）
＜要求中継処理手順＞
つぎに、中継サーバ１０２の各種処理手順について説明する。図２６は、中継サーバの要求中継処理手順の一例を示すフローチャートである。図２６のフローチャートにおいて、まず、要求受信部７０１により、クライアント端末１０１からリクエストを受信したか否かを判断する（ステップＳ２６０１）。

ここで、リクエストを受信するのを待って（ステップＳ２６０１：Ｎｏ）、受信した場合（ステップＳ２６０１：Ｙｅｓ）、セッション管理部７０７により、セッション管理処理を実行する（ステップＳ２６０２）。このあと、要求解釈部７０２により、受信されたリクエストのＵＲＬを復元し（ステップＳ２６０３）、リクエストを加工する（ステップＳ２６０４）。

つぎに、クッキー復元部７０３により、リクエストに含まれているクッキーを復元するクッキー復元処理を実行し（ステップＳ２６０５）、リクエストから欠落しているクッキーを補完するクッキー補完処理を実行する（ステップＳ２６０６）。このあと、要求送信制御部７０８により、要求送信部７０９を制御して、リクエストを目的サーバ１０３に転送して（ステップＳ２６０７）、本フローチャートによる一連の処理を終了する。

これにより、クライアント端末１０１からのリクエストを目的サーバ１０３に中継することができる。このとき、リクエストから欠落しているクッキーを補完して目的サーバ１０３に転送することができる。

＜セッション管理処理手順＞
つぎに、図２６に示したステップＳ２６０２のセッション管理処理の具体的な処理手順について説明する。図２７は、セッション管理処理の具体的処理手順を示すフローチャートである。図２７のフローチャートにおいて、まず、セッション管理部７０７により、リクエストのリクエストヘッダに端末識別用のクッキーがあるか否かを判断する（ステップＳ２７０１）。

ここで、端末識別用のクッキーがある場合（ステップＳ２７０１：Ｙｅｓ）、セッション管理部７０７により、その端末識別用のクッキーのクッキー値が端末対応テーブル９００にあるか否かを判断する（ステップＳ２７０２）。なお、端末識別用のクッキーのクッキー値とは、端末対応テーブル９００の端末識別クッキーのフィールドに設定されている情報である。

ここで、端末対応テーブル９００にクッキー値がある場合（ステップＳ２７０２：Ｙｅｓ）、セッション管理部７０７により、リクエストヘッダにセッション識別用のクッキーがあるか否かを判断する（ステップＳ２７０３）。

ここで、セッション識別用のクッキーがある場合（ステップＳ２７０３：Ｙｅｓ）、セッション管理部７０７により、端末対応テーブル９００内の該当エントリを現在のセッションとして（ステップＳ２７０４）、図２６に示したステップＳ２６０３に移行する。

一方、セッション識別用のクッキーがない場合（ステップＳ２７０３：Ｎｏ）、セッション管理部７０７により、クッキーＤＢ１２０から端末識別用のクッキーが一致するエントリを検索して（ステップＳ２７０５）、そのエントリからセッション識別用のクッキーを削除する（ステップＳ２７０６）。なお、端末識別用のクッキーとはクッキーＤＢ１２０のクライアントＩＤのフィールドに設定されている情報であり、セッション識別用のクッキーとはセッションＩＤのフィールドに設定されている情報である。すなわち、セッション識別用のクッキーがない場合は、新しいセッションを開始するために、以前のセッションＩＤを破棄する。そして、セッション管理部７０７により、端末対応テーブル９００内の該当エントリを現在のセッションとして（ステップＳ２７０４）、図２６に示したステップＳ２６０３に移行する。

また、ステップＳ２７０１において、端末識別用のクッキーがない場合（ステップＳ２７０１：Ｎｏ）、セッション管理部７０７により、端末識別用のクッキー値を生成する（ステップＳ２７０７）。同様に、ステップＳ２７０２において、端末対応テーブル９００にクッキー値がない場合（ステップＳ２７０２：Ｎｏ）、セッション管理部７０７により、端末識別用のクッキー値を生成する（ステップＳ２７０７）。そして、生成されたクッキー値を端末対応テーブル９００に設定することで新たなエントリを登録する（ステップＳ２７０８）。つぎに、そのエントリを現在のセッションとして（ステップＳ２７０４）、図２６に示したステップＳ２６０３に移行する。

これにより、端末対応テーブル９００を用いて、クライアント端末１０１とのセッションを管理することができるようになる。

＜クッキー復元処理手順＞
つぎに、図２６に示したステップＳ２６０５のクッキー復元処理の具体的な処理手順について説明する。図２８は、クッキー復元処理の具体的処理手順を示すフローチャートである。

図２８のフローチャートにおいて、まず、クッキー復元部７０３により、リクエストの中からクッキーを抽出して（ステップＳ２８０１）、クッキー名のＵＲＬエンコーディングを復元する（ステップＳ２８０２）。そして、クッキー復元部７０３により、『；』を区切り文字として、クッキー名を『ドメイン名』、『パス名』、『元のクッキー名』に分解する（ステップＳ２８０３）。

つぎに、クッキー復元部７０３により、リクエストに含まれているクッキー値のＵＲＬエンコーディングを復元する（ステップＳ２８０４）。そして、クッキー復元部７０３により、クッキー値を『有効期限文字列』、『セキュアフラグ』、『元のクッキー値』に分解する（ステップＳ２８０５）。

このあと、クッキー復元部７０３により、『元のクッキー名』および『元のクッキー値』を用いて、復元後のクッキーを生成する（ステップＳ２８０６）。そして、クッキー復元部７０３により、『元のクッキー名』に対応するエントリをクッキーＤＢ１２０の中から検索する（ステップＳ２８０７）。

ここで、エントリが検索された場合（ステップＳ２８０８：Ｙｅｓ）、クッキー復元部７０３により、『元のクッキー値』と『有効期限文字列』を用いて、エントリのクッキー値と有効期限を更新する（ステップＳ２８０９）。

一方、エントリが非検索の場合（ステップＳ２８０８：Ｎｏ）、『ドメイン名』、『パス名』、『元のクッキー名』、『有効期限文字列』、『セキュアフラグ』、『元のクッキー値』を用いて、新規エントリをクッキーＤＢ１２０に登録する（ステップＳ２８１０）。なお、新規エントリのクライアントＩＤおよびセッションＩＤは、新たに生成されることになる。

このあと、判定部７０５により、復元後のクッキーのドメイン名が、リクエストのドメイン名と一致または上位のドメイン名となっているか否かを判定する（ステップＳ２８１１）。ここで、一致または上位の場合（ステップＳ２８１１：Ｙｅｓ）、判定部７０５により、復元後のクッキーのパス名が、リクエストのパス名と先頭一致のパス名となっているか否かを判定する（ステップＳ２８１２）。

ここで、一致または上位の場合（ステップＳ２８１２：Ｙｅｓ）、判定部７０５により、復元後のクッキーのセキュアフラグが有効かつリクエストのプロトコルがｈｔｔｐｓではないかを判定する（ステップＳ２８１３）。

ここで、セキュアフラグが無効、または、セキュアフラグが有効かつプロトコルがｈｔｔｐｓの場合（ステップＳ２８１３：Ｎｏ）、第１付加部７０４により、リクエストヘッダに復元後のクッキーを付加する（ステップＳ２８１４）。そして、クッキー復元部７０３により、リクエストの中から抽出されていない未抽出のクッキーがあるか否かを判断する（ステップＳ２８１５）。

ここで、未抽出のクッキーがある場合（ステップＳ２８１５：Ｙｅｓ）、ステップＳ２８０１に戻る。一方、未抽出のクッキーがない場合（ステップＳ２８１５：Ｎｏ）、図２６に示したステップＳ２６０６に移行する。また、ステップＳ２８１１において、ドメイン名が一致または上位ではない場合（ステップＳ２８１１：Ｎｏ）、ステップＳ２８１５に移行する。

また、ステップＳ２８１２において、パス名が先頭一致ではない場合（ステップＳ２８１２：Ｎｏ）、ステップＳ２８１５に移行する。また、ステップＳ２８１３において、セキュアフラグが有効かつプロトコルがｈｔｔｐｓではない場合（ステップＳ２８１３：Ｙｅｓ）、ステップＳ２８１５に移行する。

これにより、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式で変換されているクッキーを、目的サーバ１０３が認識可能な形式に復元することができる。

＜クッキー補完処理＞
つぎに、図２６に示したステップＳ２６０６のクッキー補完処理の具体的な処理手順について説明する。図２９は、クッキー補完処理の具体的処理手順を示すフローチャートである。

図２９のフローチャートにおいて、まず、検索部７０６により、クッキーＤＢ１２０の中から、クライアントＩＤが、リクエストの端末識別用のクッキー値と一致するエントリがあるか否かを判断する（ステップＳ２９０１）。ここで、エントリがある場合（ステップＳ２９０１：Ｙｅｓ）、検索部７０６により、クッキーＤＢ１２０の中からクライアントＩＤが一致するエントリを選択する（ステップＳ２９０２）。

このあと、検索部７０６により、選択されたエントリの有効期限が切れているか否かを判断する（ステップＳ２９０３）。ここで、有効期限が切れている場合（ステップＳ２９０３：Ｙｅｓ）、クッキーＤＢ１２０の中から選択されたエントリを削除して（ステップＳ２９０４）、ステップＳ２９０１に戻る。

一方、有効期限が切れていない場合（ステップＳ２９０３：Ｎｏ）、検索部７０６により、選択されたエントリのドメイン名が、リクエストのドメイン名と一致または上位のドメイン名となっているか否かを判断する（ステップＳ２９０５）。

ここで、一致または上位の場合（ステップＳ２９０５：Ｙｅｓ）、検索部７０６により、選択されたエントリのパス名が、リクエストのパス名と先頭一致となるパス名となっているか否かを判断する（ステップＳ２９０６）。

ここで、先頭一致の場合（ステップＳ２９０６：Ｙｅｓ）、検索部７０６により、エントリのセキュアフラグが有効かつリクエストのプロトコルがｈｔｔｐｓではないかを判断する（ステップＳ２９０７）。

ここで、セキュアフラグが無効、または、セキュアフラグが有効かつプロトコルがｈｔｔｐｓの場合（ステップＳ２９０７：Ｎｏ）、第１付加部７０４により、リクエストヘッダに選択されたエントリのクッキーを付加して（ステップＳ２９０８）、ステップＳ２９０１に戻る。

また、ステップＳ２９０５において、ドメイン名が一致または上位ではない場合（ステップＳ２９０５：Ｎｏ）、ステップＳ２９０１に戻る。また、ステップＳ２９０６において、パス名が先頭一致ではない場合（ステップＳ２９０６：Ｎｏ）、ステップＳ２９０１に戻る。また、ステップＳ２９０７において、セキュアフラグが有効かつプロトコルがｈｔｔｐｓではない場合（ステップＳ２９０７：Ｙｅｓ）、ステップＳ２９０１に戻る。

これにより、クライアント端末１０１のブラウザ側のクッキーの保持制限により欠落しているクッキーを補完することができる。

＜応答中継処理手順＞
つぎに、中継サーバ１０２の応答中継処理手順について説明する。図３０は、中継サーバの応答中継処理手順の一例を示すフローチャートである。図３０のフローチャートにおいて、まず、応答受信部７１０により、目的サーバ１０３からレスポンスを受信したか否かを判断する（ステップＳ３００１）。

ここで、レスポンスを受信するのを待って（ステップＳ３００１：Ｎｏ）、受信した場合（ステップＳ３００１：Ｙｅｓ）、第２付加部７１５により、識別用クッキーをレスポンスに付加する識別用クッキー付加処理を実行する（ステップＳ３００２）。つぎに、レスポンスから欠落しているクッキーを補完するクッキー補完処理を実行する（ステップＳ３００３）。

そして、クッキー変換部７１４により、レスポンスに含まれているクッキーを変換するクッキー変換処理を実行する（ステップＳ３００４）。このあと、応答解釈部７１３により、レスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅ：行を解釈して応答内容がＨＴＭＬ形式またはＪａｖａＳｃｒｉｐｔ形式のドキュメントか否かを判断する（ステップＳ３００５）。

ここで、応答内容がＨＴＭＬ形式またはＪａｖａＳｃｒｉｐｔ形式のドキュメントではない場合（ステップＳ３００５：Ｎｏ）、ステップＳ３００８に移行する。一方、応答内容がＨＴＭＬ形式またはＪａｖａＳｃｒｉｐｔ形式のドキュメントの場合（ステップＳ３００５：Ｙｅｓ）、コード置換部７１６により、レスポンスボディに格納されているドキュメントのうち、クッキー値を参照・更新するためのコードを書き換える（ステップＳ３００６）。

そして、応答変換部７１７により、レスポンス（応答内容）に対する変更処理を実行する（ステップＳ３００７）。最後に、応答送信制御部７１８により、応答送信部７１９を制御して、レスポンスをクライアント端末１０１に転送して（ステップＳ３００８）、本フローチャートによる一連の処理を終了する。なお、ステップＳ３００３のクッキー補完処理については、図２９に示したクッキー補完処理と同様のため（補完先がリクエストからレスポンスとなる）、ここでは詳細な説明を省略する。

これにより、目的サーバ１０３からのレスポンスをクライアント端末１０１が中継サーバ１０２からのものと認識可能な形式に変換して中継することができる。

＜識別用クッキー付加処理＞
つぎに、図３０に示したステップＳ３００２の識別用クッキー付加処理の具体的な処理手順について説明する。図３１は、識別用クッキー付加処理の具体的処理手順の一例を示すフローチャートである。

図３１のフローチャートにおいて、まず、第２付加部７１５により、端末対応テーブル９００から現在のセッションの端末識別クッキーを抽出する（ステップＳ３１０１）。そして、第２付加部７１５により、クッキー名『＿ｃｌｉｅｎｔ＿ｉｄ』のクッキーをレスポンスに付加する（ステップＳ３１０２）。

ただし、クッキー値は現在のセッションの端末識別クッキーとし、有効期限は規定値とし、ドメイン名は中継サーバ１０２のドメイン名と異なる『．ｐｒｏｘｙ．ｃｏｍ』とし、パス名は『／』とし、セキュアフラグは無効とする。

このあと、第２付加部７１５により、クッキー名『＿ｓｅｓｓｉｏｎ』のクッキーをレスポンスに付加して（ステップＳ３１０３）、図３０に示したステップＳ３００３に移行する。ただし、クッキー値は『ｔｒｕｅ』とし、有効期限はなしとし、ドメイン名は中継サーバ１０２のドメイン名と異なる『．ｐｒｏｘｙ．ｃｏｍ』とし、パス名は『／』とし、セキュアフラグは無効とする。

＜クッキー変換処理手順＞
つぎに、図３０に示したステップＳ３００３のクッキー変換処理の具体的な処理手順について説明する。図３２は、クッキー変換処理の具体的処理手順の一例を示すフローチャートである。

図３２のフローチャートにおいて、まず、クッキー変換部７１４により、『；』を区切り文字として、元のドメイン名、元のパス名、元のクッキー名を連結して変換後のクッキー名とする（ステップＳ３２０１）。そして、クッキー変換部７１４により、クッキー名として使用不可の文字をエスケープする（ステップＳ３２０２）。

このあと、クッキー変換部７１４により、元のクッキーに有効期限があるか否かを判断する（ステップＳ３２０３）。ここで、有効期限がある場合（ステップＳ３２０３：Ｙｅｓ）、クッキー変換部７１４により、元の有効期限文字列の区切り文字を『−』で置換して変換後のクッキー値とする（ステップＳ３２０４）。

一方、有効期限がない場合（ステップＳ３２０３：Ｎｏ）、クッキー変換部７１４により、変換後のクッキー値を１つのハイフンとする（ステップＳ３２０５）。つぎに、クッキー変換部７１４により、元のクッキーにセキュアフラグがあれば『Ｓ』を、なければ『ｓ』を変換後のクッキー値の最後に追加する（ステップＳ３２０６）。

そして、クッキー変換部７１４により、変換後のクッキー値に元のクッキー値を追加して（ステップＳ３２０７）、変換後のドメイン名を『．ｒ．ｐｒｏｘｙ．ｃｏｍ』、パス名を『／』として（ステップＳ３２０８）、図３０に示したステップＳ３００４に移行する。

これにより、目的サーバ１０３からのレスポンスに付加されているクッキーを、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換することができる。

（クライアント端末のクッキー参照・更新処理手順）
つぎに、クライアント端末１０１のクッキー参照処理手順について説明する。図３３は、クライアント端末のクッキー参照処理手順の一例を示すフローチャートである。

図３３のフローチャートにおいて、まず、クライアント端末１０１により、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ変数から、現在のドキュメントのプロトコル、ドメイン名、パス名を取得する（ステップＳ３３０１）。

具体的には、たとえば、現在のページを『ｈｔｔｐ：／／ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ．ｒ．ｐｒｏｘｙ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』とする。この場合、ステップＳ３３０１では、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ変数を参照すると、『ｈｔｔｐ：／／ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ．ｒ．ｐｒｏｘｙ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』が得られる。そして、クライアント端末１０１が、この値を解釈して、目的サーバ１０３のＵＲＬは『ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』であるとする。

図３３のフローチャートの説明に戻り、つぎに、クライアント端末１０１により、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅの値を、『；』を区切り文字として分解して元クッキーリストを作成する（ステップＳ３３０２）。

具体的には、たとえば、クライアント端末１０１が、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅの値を参照すると、図３４に示すような文字列３４００が得られる。図３４は、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅの値を参照して得られる文字列の一例を示す説明図である。そして、クライアント端末１０１が、文字列３４００を『；』を区切り文字として分割し、各要素を解釈して、図３５に示すような元クッキーリストを作成する。

図３５は、元クッキーリストの記憶内容の一例を示す説明図である。図３５において、元クッキーリスト３５００は、ドメイン名、パス名、クッキー名、有効期限、セキュアフラグ、クッキー値のフィールドを有する。各フィールドに情報を設定することで、元クッキーがレコードとして記憶されている。

図３３のフローチャートの説明に戻り、つぎに、クライアント端末１０１により、結果文字列を空にする（ステップＳ３３０３）。そして、クライアント端末１０１により、元クッキーリストが空か否かを判断する（ステップＳ３３０４）。

ここで、元クッキーリストが空でない場合（ステップＳ３３０４：Ｎｏ）、クライアント端末１０１により、元クッキーリストの先頭要素を処理対象クッキーとして元クッキーリストから削除する（ステップＳ３３０５）。

そして、クライアント端末１０１により、処理対象クッキーのクッキー名とクッキー値から実クッキーのクッキー名、クッキー値、有効期限、ドメイン名、パス名セキュアフラグを復元する（ステップＳ３３０６）。このあと、クライアント端末１０１により、有効期限が切れているか否かを判断する（ステップＳ３３０７）。

ここで、有効期限が切れている場合（ステップＳ３３０７：Ｙｅｓ）、ステップＳ３３０４に戻る。一方、有効期限が切れていない場合（ステップＳ３３０７：Ｎｏ）、クライアント端末１０１により、ドメイン名が現在のドメイン名と一致または上位のドメイン名となっているか否かを判断する（ステップＳ３３０８）。

ここで、ドメイン名が一致または上位ではない場合（ステップＳ３３０８：Ｎｏ）、ステップＳ３３０４に戻る。一方、ドメイン名が一致または上位の場合（ステップＳ３３０８：Ｙｅｓ）、クライアント端末１０１により、パス名が現在のパス名と先頭一致になっているか否かを判断する（ステップＳ３３０９）。

ここで、パス名が先頭一致ではない場合（ステップＳ３３０９：Ｎｏ）、ステップＳ３３０４に戻る。一方、パス名が先頭一致の場合（ステップＳ３３０９：Ｙｅｓ）、クライアント端末１０１により、セキュアフラグが有効かつ現在のプロトコルがｈｔｔｐｓではないかを判断する（ステップＳ３３１０）。

ここで、セキュアフラグが有効かつ現在のプロトコルがｈｔｔｐｓではない場合（ステップＳ３３１０：Ｙｅｓ）、ステップＳ３３０４に戻る。一方、セキュアフラグが無効、または、セキュアフラグが有効かつ現在のプロトコルがｈｔｔｐｓの場合（ステップＳ３３１０：Ｎｏ）、クライアント端末１０１により、クッキー名、クッキー値からクッキー文字列を生成し結果文字列に追加して（ステップＳ３３１１）、ステップＳ３３０４に戻る。

そして、ステップＳ３３０４において、元クッキーリストが空の場合は（ステップＳ３３０４：Ｙｅｓ）、クライアント端末１０１により、結果文字列を返り値として（ステップＳ３３１２）、本フローチャートによる一連の処理を終了する。

すなわち、元クッキーリストの各エントリに対して、ステップ３３０７〜ステップＳ３３１０の判定を実行し、追加すべきエントリであれば結果文字列へ追加する。図３５に示した元クッキーリスト３５００の例では、ステップＳ３３０７の有効期限のチェックでは、３番目のエントリが除外され、ステップＳ３３０８のドメイン名のチェックでは４番目のエントリが除外される。

また、ステップＳ３３０９のパス名のチェックでは、２番目のエントリは目的サーバ１０３のＵＲＬとは一致していないが、先頭一致のパスになっているため除外されず、この例では除外されるエントリはない。ステップＳ３３１０の判定では、この例の対象プロトコルはｈｔｔｐなので除外されるエントリはない。結果として、１番目と２番目のエントリが残り、下記に示すような結果文字列として設定される。

ａｌｐｈａ＝ａｌｅｐｈ；ｂｅｔａ＝ｂｅｔｈ

つぎに、クライアント端末１０１のクッキー更新処理手順について説明する。図３６は、クライアント端末のクッキー更新処理手順の一例を示すフローチャート（その１）である。図３６のフローチャートにおいて、まず、クライアント端末１０１により、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ変数から、現在のドキュメントのプロトコル、ドメイン名、パス名を取得する（ステップＳ３６０１）。

具体的には、たとえば、現在のページを『ｈｔｔｐ：／／ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ．ｒ．ｐｒｏｘｙ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』とする。この場合、ステップＳ３６０１では、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ変数を参照すると、『ｈｔｔｐ：／／ｈｔｔｐ−ｗｗｗ−ｅｘａｍｐｌｅ−ｃｏｍ．ｒ．ｐｒｏｘｙ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』が得られる。そして、クライアント端末１０１が、この値を解釈して、目的サーバ１０３のＵＲＬは『ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｎ／ｅｘａｍｐｌｅ／ｐａｔｈ．ｈｔｍｌ』であるとする。

図３６のフローチャートの説明に戻り、つぎに、クライアント端末１０１により、引数（ａｒｇ）からクッキー名、クッキー値、ドメイン名、パス名、セキュアフラグ、有効期限を取得する（ステップＳ３６０２）。

ここで、ステップＳ３６０２においてＳｅｔＣｏｏｋｉｅ（）を呼び出している部分のコード例３７００を図３７に示す。図３７は、コード例を示す説明図である。クライアント端末１０１が、引数をクッキーの書式にしたがって解釈し、ドメイン名は『ｅｘａｍｐｌｅ．ｃｏｍ』、パス名は『／』、クッキー名は『ａｌｐｈａ』、クッキー値は『ａｌｅｐｈ』とする。また、セキュアフラグは『無効』、有効期限は『Ｔｕｅ， ０１−Ｊａｎ−２９９９ １５：００：００ ＧＭＴ』とする。

図３６のフローチャートの説明に戻り、つぎに、クライアント端末１０１により、ドメイン名が現在のドメイン名と一致または上位のドメイン名となっているか否かを判断する（ステップＳ３６０３）。ここで、ドメイン名が一致または上位ではない場合（ステップＳ３６０３：Ｎｏ）、本フローチャートによる一連の処理を終了する。

一方、ドメイン名が一致または上位の場合（ステップＳ３６０３：Ｙｅｓ）、クライアント端末１０１により、パス名が現在のパス名と先頭一致のパス名となっているか否かを判断する（ステップＳ３６０４）。ここで、パス名が先頭一致ではない場合（ステップＳ３６０４：Ｎｏ）、本フローチャートによる一連の処理を終了する。

一方、パス名が先頭一致の場合（ステップＳ３６０４：Ｙｅｓ）、クライアント端末１０１により、ドメイン名、パス名、クッキー名から変換後のクッキー名を生成する（ステップＳ３６０５）。そして、クライアント端末１０１により、有効期限、セキュアフラグ、クッキー値から変換後のクッキー値を生成する（ステップＳ３６０６）。

このあと、クライアント端末１０１により、ドメイン名を『．ｒ．ｐｒｏｘｙ．ｃｏｍ』、パス名を『／』、有効期限を引数から取得した有効期限とする（ステップＳ３６０７）。最後に、クライアント端末１０１により、クッキー設定文字列を生成し、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅに代入して（ステップＳ３６０８）、本フローチャートによる一連の処理を終了する。

すなわち、ステップＳ３６０３，３６０４では、ステップＳ３６０２で解釈された値と現在のドメイン名、パス名のチェックを行なう。この例では、ドメインが上位になっておりパスが先頭一致となっているため有効とみなされる。そして、引数から解釈した情報を用いて、ステップＳ３６０５で変換後のクッキー名を、ステップＳ３６０６で変換後のクッキー値を生成する。さらに、ステップＳ３６０７でドメイン名、パス名、有効期限を生成し、これらの値からステップＳ３６０８で図３８に示すようなクッキー設定文字列３８００を生成する。図３８は、クッキー設定文字列の一例を示す説明図である。

以上説明したように、本開示技術では、レスポンスの中からクッキーを抽出して、リクエスト先と関連付けてクッキーＤＢ１２０に登録する。そして、本開示技術では、リクエストを受信すると、リクエスト先に対応するクッキーをクッキーＤＢ１２０内のクッキー群の中から検索してリクエストに付加する。

これにより、中継サーバ１０２において、ブラウザ側のクッキーの保持制限などによりリクエストから欠落しているクッキーを補完して、目的サーバ１０３に転送することができる。その結果、クライアント端末１０１のブラウザ側のクッキーの保持制限による問題を回避して、目的サーバ１０３側での処理を正常に行なえるようになる。

また、本開示技術では、レスポンスの中から抽出されたクッキーを、クライアント端末１０１が中継サーバ１０２のドメインのものとして認識可能な形式に変換することにより、中継サーバ１０２経由でもクッキーを扱えるようになる。

また、本開示技術では、レスポンスに含まれるＨＴＭＬ形式のドキュメントのうち、クッキー値を参照・更新するためのコードを、変換後のクッキーを参照・更新するためのコードに書き換える。これにより、クライアント端末１０１のブラウザ側で、変換後のクッキーの中身にアクセスできるようになる。

また、本開示技術では、クッキーＤＢ１２０内のクッキー群のうち、リクエスト先のドメイン名と一致または該ドメイン名よりも上位のドメイン名と関連付けて登録されているクッキーを検索することにしてもよい。これにより、クッキーＤＢ１２０内のクッキー群の中からリクエスト先に対して有効なクッキーを絞り込んで、リクエストに補完することができる。

また、本開示技術では、さらに、検索されたクッキーのうち、リクエスト先のパス名と先頭一致するパス名に関連付けて登録されているクッキーを検索することにしてもよい。これにより、クッキーＤＢ１２０内のクッキー群の中からリクエスト先に対して有効なクッキーをリクエストに補完することができる。

また、本開示技術では、リクエストのプロトコルが暗号化用ではない場合、クッキーＤＢ１２０内のクッキー群のうち、セキュアフラグが有効のクッキーを検索対象から除外することにしてもよい。これにより、秘匿すべきクッキーが第３者に盗み見られたり、改ざんされることを防止することができる。

また、本開示技術では、クッキーＤＢ１２０内のクッキー群のうち、有効期限が切れているクッキーを検索対象から除外することにしてもよい。これにより、有効期限内のクッキーのみを検索対象とすることができる。

なお、ブラウザ側のクッキーの保持制限による問題を回避するために、複数個のクッキーを一つにまとめることでクッキーの数を減らすことも考えられる。しかしながら、複数個のクッキーをまとめるとクッキー自体の文字数制限に抵触して、結果的にすべての情報をクッキーに埋め込むことができない場合があるという問題がある。さらに、複数のレスポンスの順序が入れ替わってしまう場合のコヒーレンシーの問題が発生してしまう。

また、クッキーの情報を中継サーバのＤＢに保存して、そのＤＢのＩＤ（代表ＩＤ）を新たなクッキー情報としてクライアント端末に送信することも考えられる。しかしながら、この手法では、ブラウザには、たとえば、ＪａｖａＳｃｒｉｐｔでクッキーを操作する機能が用意されるが、代表ＩＤを使うと、ブラウザからクッキーそのものの中身にアクセスできなくなるという問題がある。

これに対して、本開示技術によれば、クッキー自体の文字数制限に抵触することなく、また、レスポンスの順序が入れ替わることによるコヒーレンシーの問題を防止して、ブラウザ側のクッキーの保持制限による問題を回避することができる。さらに、代表ＩＤを使うことで発生するクッキー内のＪａｖａＳｃｒｉｐｔがクッキーにアクセス不能となる問題を抑止することができる。

（実施の形態２）
つぎに、本中継手法の実施の形態２について説明する。実施の形態１では、クライアント端末１０１のブラウザ側で、意図的にクッキーが削除された場合と、クッキーＤＢ１２０の保持制限によりクッキーが削除された場合との区別ができない。そのため、実施の形態１では、クッキーが意図的に削除されているにも関わらず、中継サーバ１０２でクッキーが補完され目的サーバ１０３に転送される場合がある。

そこで、実施の形態２では、クライアント端末１０１が、クッキーを削除（あるいは、書き換え）したことを表わす更新履歴をリクエストに含めて中継サーバ１０２に送信する。これにより、中継サーバ１０２側で、欠落しているクッキーが、クライアント端末１０１側で意図的に削除されたものかどうかを把握できるようにする。なお、実施の形態１で説明した箇所と同様の箇所については図示および説明を省略する。

（更新履歴の具体例）
ここで、リクエストに含まれるクライアント端末１０１側でクッキーを意図的に削除したことを表わす更新履歴について説明する。図３９は、更新履歴の具体例を示す説明図である。図３９において、リクエスト３９００には、クライアント端末１０１側でクッキーを意図的に削除したことを表わす更新履歴３９１０が含まれている。

具体的には、更新履歴３９１０は、クッキー名『＿ｍｏｄｌｏｇ』のクッキーとして表わされる。より具体的には、文字列３９１１は、シーケンス番号『１』、ドメイン名『ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ』、パス名『／』、クッキー名『ｉｄ』のクッキーが『Ｓａｔ， ２９−Ｍａｒ−２００９ ２０：０９：１３ ＧＭＴ』に削除されたことを表わす。また、文字列３９１２は、シーケンス番号『２』、ドメイン名『ｗｗｗ．ｅｘａｍｐｌｅ３．ｃｏｍ』、パス名『／ａｐｐ』、クッキー名『ｕｓｅｒ』のクッキーが『Ｓａｔ， ２９−Ｍａｒ−２００９ １８：３０：１０ ＧＭＴ』に削除されたことを表わす。

なお、文字列３９２０は、処理済シーケンス番号を表わす。具体的には、文字列３９２０は、前回のリクエストを送信するまでにシーケンス番号０までのクッキーは処理済みであることを表わしている。更新履歴３９１０は、クライアント端末１０１で生成されてリクエスト３９００に追加されることになる。なお、クライアント端末１０１での更新履歴追加処理については図４４を用いて後述する。

（クッキー復元部７０３の機能的構成）
つぎに、実施の形態２にかかる中継サーバ１０２のクッキー復元部７０３が備える機能的構成について説明する。図４０は、クッキー復元部７０３が備える機能的構成を示すブロック図である。図４０において、クッキー復元部７０３は、第１付加部７０４と、判定部７０５と、検索部７０６と、更新履歴抽出部４００１と、更新対象検索部４００２と、更新部４００３と、を含む構成である。

更新履歴抽出部４００１は、リクエストの中から、クライアント端末１０１側で行なわれたクッキーに対する更新処理に関する履歴データを抽出する機能を有する。具体的には、たとえば、更新履歴抽出部４００１が、リクエスト３９００の中から、クッキー名『＿ｍｏｄｌｏｇ』を手掛かりに更新履歴３９１０を抽出する。抽出された更新履歴は、たとえば、図４１に示す更新履歴リスト４１００に記憶される。

図４１は、中継サーバの更新履歴リストの記憶内容の一例を示す説明図である。図４１において、更新履歴リスト４１００は、シーケンス番号、ドメイン名、パス名、クッキー名、有効期限、セキュアフラグおよびクッキー値のフィールドを有する。各フィールドに情報を設定することで、更新履歴４１００−１，４１００−２がレコードとして記憶されている。

更新対象検索部４００２は、抽出された履歴データに基づいて、クッキーＤＢ１２０内のクッキー群の中から更新対象となるクッキーを検索する機能を有する。具体的には、たとえば、更新対象検索部４００２が、クッキーＤＢ１２０（図６参照）の中から、ドメイン名、パス名、クッキー名が更新履歴４１００−１，４１００−２と一致するクッキー情報を検索する。この例では、クッキーＤＢ１２０の中からクッキー情報６００−４が検索される。

更新部４００３は、履歴データに基づいて、検索された更新対象のクッキーを更新する機能を有する。具体的には、たとえば、更新部４００３が、更新履歴４１００−２に含まれている有効期限が切れている場合、更新対象となるクッキー情報６００−４をクッキーＤＢ１２０の中から削除する。また、更新部４００３は、更新履歴４１００−２に含まれている有効期限が切れていない場合、更新対象となるクッキー情報６００−４の内容を更新履歴４１００−２の内容に書き換える。なお、内容とは、たとえば、有効期限、セキュアフラグ、クッキー値である。

また、検索部７０６は、更新部４００３によって更新された更新後のクッキーＤＢ１２０内のクッキー群の中から、リクエストの宛先に対応するクッキーを検索する。すなわち、検索部７０６が、ブラウザ側で意図的に削除されたクッキーを排除したクッキーＤＢ１２０の中からリクエストの宛先に対応するクッキーを検索する。

（中継サーバの更新履歴処理手順）
つぎに、中継サーバ１０２の更新履歴処理手順について説明する。図４２は、中継サーバの更新履歴処理手順の一例を示すフローチャートである。図４２のフローチャートにおいて、まず、更新履歴抽出部４００１により、リクエストから更新履歴を抽出して、更新履歴リストを作成する（ステップＳ４２０１）。

このあと、更新対象検索部４００２により、リクエストから処理済シーケンス番号を取得して（ステップＳ４２０２）、更新履歴リストに更新履歴があるか否かを判断する（ステップＳ４２０３）。ここで、更新履歴がある場合（ステップＳ４２０３：Ｙｅｓ）、更新対象検索部４００２により、更新履歴リストから先頭の更新履歴を取り出して、更新履歴リストから削除する（ステップＳ４２０４）。

そして、先頭の更新履歴のシーケンス番号が処理済シーケンス番号よりも大きいか否かを判断する（ステップＳ４２０５）。ここで、処理済シーケンス番号以下の場合（ステップＳ４２０５：Ｎｏ）、ステップＳ４２０３に戻る。

一方、処理済シーケンス番号よりも大きい場合（ステップＳ４２０５：Ｙｅｓ）、更新対象検索部４００２により、先頭の更新履歴のドメイン名、パス名、クッキー名に一致するエントリをクッキーＤＢ１２０の中から検索する（ステップＳ４２０６）。ここで、エントリが非検索の場合（ステップＳ４２０７：Ｎｏ）、ステップＳ４２０３に戻る。

一方、エントリが検索された場合（ステップＳ４２０７：Ｙｅｓ）、更新部４００３により、先頭の更新履歴の有効期限は切れているか否かを判断する（ステップＳ４２０８）。ここで、有効期限切れの場合（ステップＳ４２０８：Ｙｅｓ）、更新部４００３により、クッキーＤＢ１２０の中から該当エントリを削除する（ステップＳ４２０９）。

一方、有効期限が切れていない場合（ステップＳ４２０８：Ｎｏ）、更新部４００３により、クッキーＤＢ１２０内の該当エントリの内容を、先頭の更新履歴の内容に書き換える（ステップＳ４２１０）。そして、更新部４００３により、処理済シーケンス番号をインクリメントして（ステップＳ４２１１）、ステップＳ４２０３に戻る。

また、ステップＳ４２０３において、更新履歴リストに更新履歴がない場合（ステップＳ４２０３：Ｎｏ）、本フローチャートによる一連の処理を終了する。

これにより、欠落しているクッキーが、クライアント端末１０１側で意図的に削除されたものかどうかを把握できるようになり、意図的に削除されたクッキーを補完してしまう不具合を回避することができる。

（クライアント端末のクッキー更新処理）
つぎに、クライアント端末１０１のクッキー更新処理手順について説明する。図４３は、クライアント端末のクッキー更新処理手順の一例を示すフローチャート（その２）である。

図４３のフローチャートにおいて、まず、クライアント端末１０１により、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ変数から、現在のドキュメントのプロトコル、ドメイン名、パス名を取得する（ステップＳ４３０１）。そして、クライアント端末１０１により、引数（ａｒｇ）からクッキー名、クッキー値、ドメイン名、パス名、セキュアフラグ、有効期限を取得する（ステップＳ４３０２）。

つぎに、クライアント端末１０１により、ドメイン名が現在のドメイン名と一致または上位のドメイン名となっているか否かを判断する（ステップＳ４３０３）。ここで、ドメイン名が一致または上位ではない場合（ステップＳ４３０３：Ｎｏ）、本フローチャートによる一連の処理を終了する。

一方、ドメイン名が一致または上位の場合（ステップＳ４３０３：Ｙｅｓ）、クライアント端末１０１により、パス名が現在のパス名と先頭一致となっているか否かを判断する（ステップＳ４３０４）。ここで、パス名が先頭一致ではない場合（ステップＳ４３０４：Ｎｏ）、本フローチャートによる一連の処理を終了する。

一方、パス名が先頭一致の場合（ステップＳ４３０４：Ｙｅｓ）、クライアント端末１０１により、ドメイン名、パス名、クッキー名から変換後のクッキー名を生成する（ステップＳ４３０５）。そして、クライアント端末１０１により、有効期限、セキュアフラグ、クッキー値から変換後のクッキー値を生成する（ステップＳ４３０６）。

このあと、クライアント端末１０１により、ドメイン名を『．ｒ．ｐｒｏｘｙ．ｃｏｍ』、パス名を『／』、有効期限を引数から取得した有効期限とする（ステップＳ４３０７）。そして、クライアント端末１０１により、クッキー設定文字列を生成し、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅに代入する（ステップＳ４３０８）。

最後に、クライアント端末１０１により、クッキー設定文字列を引数にして、更新履歴追加処理を実行して（ステップＳ４３０９）、本フローチャートによる一連の処理を終了する。

＜更新履歴追加処理手順＞
つぎに、図４３に示したステップＳ４３０９の更新履歴追加処理の具体的な処理手順について説明する。図４４は、更新履歴追加処理の具体的処理手順の一例を示すフローチャートである。

図４４のフローチャートにおいて、まず、クライアント端末１０１により、引数ａｒｇを解釈して今回更新したクッキーの情報を抽出する（ステップＳ４４０１）。ここでは、今回更新したクッキーの情報をクッキーの書式にしたがって解釈した結果、ドメイン名は『ｅｘａｍｐｌｅ．ｃｏｍ』、パス名は『／』とする。また、クッキー名は『ａｌｐｈａ』、クッキー値は『ａｌｅｐｈ』、セキュアフラグは『無効（Ｎｏ）』、有効期限は『Ｔｕｅ， ０１−Ｊａｎ−２９９９ １５：００：００ ＧＭＴ』とする。

そして、クライアント端末１０１により、クッキー名『＿ｍｏｄｌｏｇ』のクッキー値を取得する（ステップＳ４４０２）。具体的には、たとえば、クライアント端末１０１が、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ変数の値を参照し、クッキーの書式にしたがってクッキー名が『＿ｍｏｄｌｏｇ』のエントリを検索し、クッキー値（たとえば、クッキー値４５００）を取得する。図４５は、クッキー値の具体例を示す説明図である。

クライアント端末１０１により、クッキー値を解釈して更新履歴リストを作成する（ステップＳ４４０３）。具体的には、たとえば、クライアント端末１０１が、取得したクッキー値の１６進表記をデコードし、『；』を区切り文字として解釈して更新履歴リストを作成する。図４６は、クライアント端末の更新履歴リストの記憶内容の一例を示す説明図である。

図４６において、更新履歴リスト４６００は、シーケンス番号、ドメイン名、パス名、クッキー名、有効期限、セキュアフラグ、クッキー値のフィールドを有する。各フィールドに情報を設定することで、更新履歴４６００−１，４６００−２，４６００−３がレコードとして記憶されている。

そして、クライアント端末１０１により、クッキー名『＿ｍｏｄｌｏｇ』のクッキー値を取得して、処理済シーケンス番号を取得する（ステップＳ４４０４）。具体的には、たとえば、クライアント端末１０１が、ｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ変数の値を参照し、クッキーの書式にしたがってクッキー名が『＿ｍｏｄｌｏｇ』のエントリを検索し、処理済シーケンス番号を取得する。ここでは、この処理済シーケンス番号を０とする。

このあと、クライアント端末１０１により、更新履歴リストの中から処理済シーケンス番号以下のシーケンス番号の更新履歴を削除する（ステップＳ４４０５）。具体的には、たとえば、クライアント端末１０１が、更新履歴リスト４６００から、シーケンス番号が０以下のエントリを削除する。この例では、シーケンス番号が０のエントリ（更新履歴４６００−１）が削除される。

そして、クライアント端末１０１により、更新履歴リストの最後のエントリのシーケンス番号をインクリメントして今回のシーケンス番号とする（ステップＳ４４０６）。具体的には、たとえば、クライアント端末１０１が、今回のシーケンス番号を３とする。

さらに、クライアント端末１０１により、更新履歴リストの中から今回更新したクッキーに対する以前の更新履歴を削除する（ステップＳ４４０７）。具体的には、たとえば、クライアント端末１０１が、今回更新したクッキーの更新履歴を更新履歴リスト４６００から探して削除する。この例ではシーケンス番号１のエントリ（更新履歴４６００−２）がドメイン名、パス名、クッキー名が一致しているので削除される。

そして、クライアント端末１０１により、今回のシーケンス番号を付した新しい更新履歴のエントリを作成して更新履歴リストの最後に追加する（ステップＳ４４０８）。具体的には、たとえば、クライアント端末１０１が、今回更新したクッキーの更新履歴のエントリを更新履歴リスト４６００に追加する。エントリが追加された例を図４７に示す。

図４７は、エントリが追加された更新履歴リストの記憶内容の一例を示す説明図である。図４７において、更新履歴リスト４６００には、更新履歴４６００−３，４７００−１がレコードとして記憶されている。ここでは、図４６に示した更新履歴リスト４６００から更新履歴４６００−１，４６００−２が削除され、更新履歴４７００−１が追加されている。

最後に、クライアント端末１０１により、更新履歴リストを文字列化し、クッキー名『＿ｍｏｄｌｏｇ』のクッキー値として設定して（ステップＳ４４０９）、本フローチャートによる一連の処理を終了する。

具体的には、たとえば、クライアント端末１０１が、更新履歴リスト４６００の情報を『；』を区切り文字として連結し、クッキー文字列中に使用不可な文字を１６進表記にエンコードして＿ｍｏｄｌｏｇの値とする。図４８は、文字列の一例を示す説明図である。図４８において、更新履歴リストを文字列化した文字列４８００が示されている。

以上説明したように、実施の形態２にかかる本開示技術では、リクエストの中からクッキーの更新履歴を抽出し、その更新履歴に基づいて、クッキーＤＢ１２０内のクッキー群の中から更新対象となるクッキーを検索する。そして、本開示技術では、更新履歴に基づいて、検索されたクッキーを更新し、更新後のクッキーＤＢ１２０内のクッキー群の中から、リクエスト先に対応する状態データを検索する。これにより、リクエストから欠落しているクッキー（または、変更されているクッキー）が、クライアント端末１０１側で意図的に削除（または、変更）されたものかを把握することができる。

また、本開示技術では、更新履歴に含まれている有効期限が切れている場合、更新対象となるクッキーをクッキーＤＢ１２０の中から削除することにしてもよい。これにより、クライアント端末１０１側で意図的に削除されたクッキーをリクエストに補完してしまうことを回避することができる。

また、本開示技術では、更新履歴に含まれている有効期限が切れていない場合、更新対象となるクッキーの内容を更新履歴の内容に書き換えることにしてもよい。これにより、クライアント端末１０１側で更新されたクッキーの内容を中継サーバ１０２のクッキーＤＢ１２０に反映することができる。

なお、本実施の形態で説明した中継方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本中継プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本中継プログラムは、インターネット等のネットワークを介して配布してもよい。

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

（付記１）ネットワーク内の通信を中継する中継装置において、
リクエストおよびレスポンスを受信する受信手段と、
前記受信手段によって受信されたリクエストおよびレスポンスを送信する送信手段と、
前記レスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、リクエスト先と関連付けてデータベースに登録する登録手段と、
前記リクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索手段と、
前記検索手段によって検索された状態データを前記リクエストに付加する付加手段と、
前記送信手段を制御して、前記付加手段によって前記状態データが付加されたリクエストを前記リクエスト先に送信する送信制御手段と、
を備えることを特徴とする中継装置。

（付記２）前記レスポンスの中から抽出された状態データを、前記リクエスト元が前記中継装置のドメインのものとして認識可能な形式に変換する変換手段と、
前記レスポンスに含まれるドキュメントのうち、前記状態データを参照・更新するためのコードを、前記リクエスト元が前記変換手段によって変換された変換後の状態データを解釈して変換前の状態データを参照・更新するためのコードに書き換える置換手段と、を備え、
前記付加手段は、前記変換手段によって変換された変換後の状態データを前記置換手段によって前記状態データを参照・更新するためのコードが書き換えられたレスポンスに付加し、
前記送信制御手段は、前記送信手段を制御して、前記付加手段によって変換後の状態データが付加されたレスポンスを前記リクエスト元に送信することを特徴とする付記１に記載の中継装置。

（付記３）前記登録手段は、前記状態データを前記リクエスト先のドメイン名と関連付けて前記データベースに登録し、
前記検索手段は、前記データベース内の状態データ群のうち、前記リクエストのリクエスト先のドメイン名と一致または当該ドメイン名よりも上位のドメイン名と関連付けて登録されている状態データを検索することを特徴とする付記１または２に記載の中継装置。

（付記４）前記登録手段は、前記状態データを前記リクエスト先のパス名と関連付けて前記データベースに登録し、
前記検索手段は、さらに、検索された状態データのうち、前記リクエストのリクエスト先のパス名と先頭一致するパス名に関連付けて登録されている状態データを検索することを特徴とする付記３に記載の中継装置。

（付記５）前記登録手段は、前記状態データを当該状態データの暗号化を指定するためのセキュアフラグの設定状態と関連付けて前記データベースに登録し、
前記検索手段は、前記リクエストのプロトコルが暗号化用ではない場合、前記データベース内の状態データ群のうち、前記セキュアフラグが有効の状態データを検索対象から除外することを特徴とする付記１〜４のいずれか一つに記載の中継装置。

（付記６）前記登録手段は、前記状態データを当該状態データの有効期限と関連付けて前記データベースに登録し、
前記検索手段は、前記データベース内の状態データ群のうち、前記有効期限が切れている状態データを検索対象から除外することを特徴とする付記１〜５のいずれか一つに記載の中継装置。

（付記７）前記リクエストの中から、前記リクエスト元で行なわれた前記状態データに対する更新処理に関する履歴データを抽出する更新履歴抽出手段と、
前記更新履歴抽出手段によって抽出された履歴データに基づいて、前記データベース内の状態データ群の中から更新対象となる状態データを検索する更新対象検索手段と、
前記履歴データに基づいて、前記検索手段によって検索された状態データを更新する更新手段と、を備え、
前記検索手段は、前記更新手段によって更新された更新後の前記データベース内の状態データ群の中から、前記リクエスト先に対応する状態データを検索することを特徴とする付記１〜６のいずれか一つに記載の中継装置。

（付記８）前記履歴データは、前記状態データの有効期限を含んでおり、
前記更新手段は、前記履歴データに含まれている有効期限が切れている場合、前記更新対象となる状態データを前記データベースの中から削除することを特徴とする付記７に記載の中継装置。

（付記９）前記更新手段は、前記履歴データに含まれている有効期限が切れていない場合、前記更新対象となる状態データの内容を前記履歴データの内容に書き換えることを特徴とする付記８に記載の中継装置。

（付記１０）前記受信手段によって受信されたリクエストに付加されており、前記リクエスト元が前記中継装置のドメインのものとして認識可能に変換された状態データを復元する復元手段を備え、
前記付加手段は、前記復元手段によって復元された復元後の状態データを前記リクエストに付加し、
前記送信制御手段は、前記送信手段を制御して、前記付加手段によって前記復元後の状態データが付加されたリクエストを前記リクエスト先に送信することを特徴とする付記１〜９のいずれか一つに記載の中継装置。

（付記１１）前記復元手段は、前記中継装置を経由してリクエスト元からリクエスト先にアクセス可能な形式に変換されたリクエストの宛先を復元し、
前記送信制御手段は、前記送信手段を制御して、前記復元手段によって復元された復元後の宛先を用いて、前記リクエストを送信することを特徴とする付記１０に記載の中継装置。

（付記１２）前記復元手段は、前記中継装置を経由してリクエスト元からリクエスト先にアクセス可能な形式に変換されたリクエストを復元し、
前記送信制御手段は、前記送信手段を制御して、前記復元手段によって復元された復元後のリクエストを送信することを特徴とする付記１０または１１に記載の中継装置。

（付記１３）ネットワーク内の通信を中継するコンピュータを、
リクエストおよびレスポンスを受信する受信手段、
前記受信手段によって受信されたリクエストおよびレスポンスを送信する送信手段、
前記レスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、リクエスト先と関連付けてデータベースに登録する登録手段、
前記リクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索手段、
前記検索手段によって検索された状態データを前記リクエストに付加する付加手段、
前記送信手段を制御して、前記付加手段によって前記状態データが付加されたリクエストを前記リクエスト先に送信する送信制御手段、
として機能させることを特徴とする中継プログラム。

（付記１４）ネットワーク内の通信を中継するコンピュータが、
リクエスト先からレスポンスを受信する応答受信工程と、
前記応答受信工程によって受信されたレスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、前記リクエスト先と関連付けてデータベースに登録する登録工程と、
前記リクエスト元からリクエストを受信する要求受信工程と、
前記要求受信工程によって受信されたリクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索工程と、
前記検索工程によって検索された状態データを前記リクエストに付加する付加工程と、
前記付加工程によって前記状態データが付加されたリクエストを前記リクエスト先に送信する要求送信工程と、
を実行することを特徴とする中継方法。

以上のように、本中継装置、中継方法、および中継プログラムは、Ｗｅｂシステムにおいてクライアント・サーバ間で情報を中継するプロキシサーバに有用であり、特に、翻訳やマッシュアップのための中継サーバに適している。

１００ ネットワークシステム
１０１ クライアント端末
１０２ 中継サーバ
１０３，１０４，１０５ 目的サーバ
１１０，１２０ クッキーＤＢ
７０１ 要求受信部
７０２ 要求解釈部
７０３ クッキー復元部
７０４ 第１付加部
７０５ 判定部
７０６ 検索部
７０７ セッション管理部
７０８ 要求送信制御部
７０９ 要求送信部
７１０ 応答受信部
７１１ 抽出部
７１２ 登録部
７１３ 応答解釈部
７１４ クッキー変換部
７１５ 第２付加部
７１６ コード置換部
７１７ 応答変換部
７１８ 応答送信制御部
７１９ 応答送信部
４００１ 更新履歴抽出部
４００２ 更新対象検索部
４００３ 更新部

Claims (7)

1. ネットワーク内の通信を中継する中継装置において、
   リクエストおよびレスポンスを受信する受信手段と、
   前記受信手段によって受信されたリクエストおよびレスポンスを送信する送信手段と、
   前記レスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、リクエスト先と関連付けてデータベースに登録する登録手段と、
   前記リクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索手段と、
   前記検索手段によって検索された状態データを前記リクエストに付加する付加手段と、
   前記送信手段を制御して、前記付加手段によって前記状態データが付加されたリクエストを前記リクエスト先に送信する送信制御手段と、
   を備えることを特徴とする中継装置。
2. 前記レスポンスの中から抽出された状態データを、前記リクエスト元が前記中継装置のドメインのものとして認識可能な形式に変換する変換手段と、
   前記レスポンスに含まれるドキュメントのうち、前記状態データを参照・更新するためのコードを、前記リクエスト元が前記変換手段によって変換された変換後の状態データを解釈して変換前の状態データを参照・更新するためのコードに書き換える置換手段と、を備え、
   前記付加手段は、前記変換手段によって変換された変換後の状態データを前記置換手段によって前記状態データを参照・更新するためのコードが書き換えられたレスポンスに付加し、
   前記送信制御手段は、前記送信手段を制御して、前記付加手段によって変換後の状態データが付加されたレスポンスを前記リクエスト元に送信することを特徴とする請求項１に記載の中継装置。
3. 前記登録手段は、前記状態データを前記リクエスト先のドメイン名と関連付けて前記データベースに登録し、
   前記検索手段は、前記データベース内の状態データ群のうち、前記リクエストのリクエスト先のドメイン名と一致または当該ドメイン名よりも上位のドメイン名と関連付けて登録されている状態データを検索することを特徴とする請求項１または２に記載の中継装置。
4. 前記登録手段は、前記状態データを前記リクエスト先のパス名と関連付けて前記データベースに登録し、
   前記検索手段は、さらに、検索された状態データのうち、前記リクエストのリクエスト先のパス名と先頭一致するパス名に関連付けて登録されている状態データを検索することを特徴とする請求項３に記載の中継装置。
5. 前記リクエストの中から、前記リクエスト元で行なわれた前記状態データに対する更新処理に関する履歴データを抽出する更新履歴抽出手段と、
   前記更新履歴抽出手段によって抽出された履歴データに基づいて、前記データベース内の状態データ群の中から更新対象となる状態データを検索する更新対象検索手段と、
   前記履歴データに基づいて、前記検索手段によって検索された状態データを更新する更新手段と、を備え、
   前記検索手段は、前記更新手段によって更新された更新後の前記データベース内の状態データ群の中から、前記リクエスト先に対応する状態データを検索することを特徴とする請求項１〜４のいずれか一つに記載の中継装置。
6. ネットワーク内の通信を中継するコンピュータを、
   リクエストおよびレスポンスを受信する受信手段、
   前記受信手段によって受信されたリクエストおよびレスポンスを送信する送信手段、
   前記レスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、リクエスト先と関連付けてデータベースに登録する登録手段、
   前記リクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索手段、
   前記検索手段によって検索された状態データを前記リクエストに付加する付加手段、
   前記送信手段を制御して、前記付加手段によって前記状態データが付加されたリクエストを前記リクエスト先に送信する送信制御手段、
   として機能させることを特徴とする中継プログラム。
7. ネットワーク内の通信を中継するコンピュータが、
   リクエスト先からレスポンスを受信する応答受信工程と、
   前記応答受信工程によって受信されたレスポンスの中からリクエスト元のアクセス状態を識別するための状態データを抽出して、前記リクエスト先と関連付けてデータベースに登録する登録工程と、
   前記リクエスト元からリクエストを受信する要求受信工程と、
   前記要求受信工程によって受信されたリクエストのリクエスト先に対応する状態データを、前記データベース内の状態データ群の中から検索する検索工程と、
   前記検索工程によって検索された状態データを前記リクエストに付加する付加工程と、
   前記付加工程によって前記状態データが付加されたリクエストを前記リクエスト先に送信する要求送信工程と、
   を実行することを特徴とする中継方法。

Images