JP2008084117A - リクエスト送信制御プログラム，装置，および方法 - Google Patents

Abstract

【課題】 ユーザに脅威を与えうる強制リクエスト送信を制限するクライアント装置を提供する。
【解決手段】 ウィンドウ選択部２１３は，リクエスト送信があったときに，パーティションテーブル２０１をもとにリクエストを扱うウィンドウを選択し，ウィンドウ作成部２１７は，該当するウィンドウがなければパーティショニング設定テーブル２０３をもとにウィンドウを作成する。リクエスト検査部２１１は，リクエスト送信のアクセス先のウィンドウのパーティションが，リクエストを要求したパーティションに属さないアクセス先から得たレスポンスである場合に，そのリクエスト送信を拒否，またはユーザに通知する。または，リクエスト編集部２１９は，そのリクエスト送信の内容を変更して送信する。
【選択図】 図３

Description

本発明は，ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のブラウザ（Ｗｅｂブラウザ）の処理中に，アクセス先となるサイトのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）や期間によってページ群を区分けし，区分外からの要求によるリクエストの送信を制限する機能に関する。

近年，Ｗｅｂの技術にもとづくクライアント・サーバ・アプリケーション，すなわちＷｅｂアプリケーションが広く利用されている。これは，ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルによりネットワーク上で通信を行うアプリケーションであって，ユーザに提示される画面内容（ページ）は主にＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述される。

かつてのＷｅｂは，クライアントからみて，単純に発信された情報を取得するのが主であった。しかし，最近では掲示板やウェブログ（ブログ）といった情報を掲載する処理や，ネットワークに接続された機器の管理，商品やサービスの購入といった商取引など，多くのアプリケーションがＷｅｂ技術で実現されており，社会にも浸透している。

サーバはＷｅｂサイトとも呼ばれ，クライアントにはＷｅｂブラウザが主に用いられる。代表的なＷｅｂブラウザとして，Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒやＭｏｚｉｌｌａ ＦｏｕｎｄａｔｉｏｎのＦｉｒｅｆｏｘなどがある。

高度なＷｅｂアプリケーションの多くは，特定のユーザのみに情報を提供したり操作を許可したりすることが求められる。このため，ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）あるいはＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）による保護を行うＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ ＳＳＬ）プロトコルや，ＨＴＴＰ認証といったセキュリティ機能が用意されている。

しかし，ＨＴＴＰプロトコルはステートレスであり，プロトコル自体はリクエストとレスポンスの複数組の間の関連付けを行う機能を持たないため，クッキー（Ｃｏｏｋｉｅ）と呼ばれる機構が設けられている。クッキーは，サーバが指定したデータをＷｅｂブラウザが暗黙的に保持しておき，リクエストのたびにその値を付けて送信するという技術である。これにより，Ｗｅｂサーバは同じＷｅｂブラウザとやり取りしたリクエストやレスポンスの組を識別することができる。

一方で，複雑な処理を実現し，またユーザに高度な外観や機能を提供するために，Ｗｅｂブラウザには，ブラウザ自身の振舞いをＷｅｂサーバ側で用意される指定によって制御できる機能が設けられている。

その一つであるクライアント側スクリプトは，ＨＴＭＬページ内またはページから参照されるファイル内に記述できる簡易なプログラム言語であり，Ｗｅｂブラウザの振舞いをある程度制御することができる。クライアント側スクリプトの代表格として，ＪａｖａＳｃｒｉｐｔがあり，他にその亜種や類似のものとして，ＥＣＭＡＳｃｒｉｐｔ，ＪＳｃｒｉｐｔ，ＶＢＳｃｒｉｐｔなどがある。ここでは，それら全てを代表してＪａｖａＳｃｒｉｐｔと呼称する。

また，ＪａｖａＳｃｒｉｐｔを使用しないＨＴＴＰとＨＴＭＬだけでも，ＨＴＭＬページ内への画像やその他のオブジェクトの埋め込み，ＨＴＴＰによるリダイレクト，ＨＴＭＬのＭＥＴＡタグによる自動更新などの機能を備えている。これらも，Ｗｅｂブラウザの振舞いをある程度制御することができる。

このようなＷｅｂブラウザを制御する機能は，Ｗｅｂアプリケーション提供者にとって都合が良い。一方で，Ｗｅｂアプリケーションのセキュリティ機能をかいくぐってセキュリティ侵害を起こそうとする攻撃者にとっても好都合である。つまり，攻撃者は，自身に都合のよいＨＴＭＬページを任意のサイトに用意し，ユーザにそのページを開かせることによって，Ｗｅｂブラウザを操作して攻撃を行うことが可能となる。このような攻撃に対処するため，Ｗｅｂブラウザには，Ｓａｍｅ Ｏｒｉｇｉｎ Ｐｏｌｉｃｙ（ＳＯＰ）やゾーン分けといった保護機構が設けられるようになった。

保護機構の１つであるＳＯＰは，ＪａｖａＳｃｒｉｐｔの機能を制約するものである。これにより，ＪａｖａＳｃｒｉｐｔは，自身が関連付けられたページと取得元のサーバ（これをｏｒｉｇｉｎと呼ぶ）が同じであるページのオブジェクトツリーしか参照や操作することができなくなる。このような制約によって，異なるサーバから得たＨＴＴＰレスポンスの含む情報を互いに相手側のＪａｖａＳｃｒｉｐｔから守ることができる。なお，ＳＯＰは，ＪａｖａＳｃｒｉｐｔ機能を提供するほぼ全てのＷｅｂブラウザに用意されている。

また，別の保護機構であるゾーン分けは，Ｗｅｂブラウザにおいて，ユーザの指示に応じてＷｅｂサーバを異なるゾーンに分類し，ゾーンごとにＪａｖａＳｃｒｉｐｔなどの全機能や一部機能を制限するというものである。Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒでは，「セキュリティゾーン」という名前で提供されており，「インターネット」，「イントラネット」，「信頼済みサイト」，「制限付きサイト」，および「マイコンピュータ」ゾーンの複数のゾーンに分類できる。

また，Ｆｉｒｅｆｏｘ（少なくとも現行の１．５版まで）には，明示的なゾーン分けの設定はないが，「サイトポリシー」と呼ばれるゾーン分け機能がすでに用意され，「Ｐｏｌｉｃｙ Ｍａｎａｇｅｒ Ｅｘｔｅｎｓｉｏｎ」という拡張機能を追加することによって設定が可能になっている。この拡張機能によって，最小１サイト単位で任意のゾーンを作ることができる。いずれも，ＪａｖａＳｃｒｉｐｔなどの機能を制限するように設定できるという点が同じである。

しかし，前記のような保護機構を備えていても，Ｗｅｂブラウザの保護は充分でない。それは，攻撃者は，リクエストを異なるサイトへ送信するよう仕向けることができるからである。攻撃者があるサイトに設けたＨＴＭＬページによって，Ｗｅｂブラウザに対して別のサイトへリクエストを送信するよう指示できるということは，具体的には次のようなことを意味する。

まず，リクエストに付随するクエリやフォームのパラメータの値は，攻撃者が自由に指定できる（ただし，明示的に指定する必要があるため，攻撃者がその値を知っている必要がある）。次に，リクエストに付随するクッキーについては，攻撃者は指定することも知ることもできないが，Ｗｅｂブラウザが記憶している値が自動的に送信される。つまり，当該ユーザのみが知るクッキーを攻撃者の指示でブラウザが送信してしまう。結果として，攻撃者は，ユーザのみが知るクッキーを知り得ることになる。

このような強制的リクエスト送信により，様々な脅威が考えられるが，もっとも典型的なのがクロスサイトリクエスト偽造（ｃｒｏｓｓ−ｓｉｔｅ ｒｅｑｕｅｓｔ ｆｏｒｇｅｒｙ； ＣＳＲＦ）と呼ばれる攻撃の脅威である。ＣＳＲＦでは，Ｗｅｂブラウザが，攻撃者の指示によりアプリケーション上の重要な処理を求めるリクエストを送信してしまう。重要な処理とは，例えばメッセージの書き込み／削除，商品購入やサービスの申し込みなどである。ＣＳＲＦによって，ユーザ本人の意思と無関係にこれらの重要な処理が要求されてしまう危険がある。特にクッキーによってユーザを認識している場合には，深刻な被害をもたらしうる。

ＳＯＰは，異なるサイトから得たレスポンスの参照を禁止するだけであり，リクエストを異なるサイトへ送信すること自体を禁止できない。また，ゾーン分けは，ＪａｖａＳｃｒｉｐｔなどのブラウザ制御機能の一部または全部を制限するため，適切に設定すれば，ユーザが望まないリクエストの送信を防ぐことができる。しかし，今日のＷｅｂ技術適用の実情において，大多数のサイトに対してブラウザ制御機能を制限することは利便性を損なうため，非現実的である。

さらに，ユーザ不注意や攻撃者による巧みな誘導によっても，ユーザが意図しないリクエストが送信されるおそれがある。つまり，例えば，ハイパーリンクを辿ること，フォームを送信することなどのユーザの操作によって発生するリクエストも，ユーザがそのリクエストの及ぼす影響を充分に理解して行われない限り，ユーザが害を被ることになるからである。

このような脅威的な結果を生じうるリクエスト送信を，まとめて「強制リクエスト送信」と呼ぶ。「強制リクエスト送信」に対して以下の対策技術が存在する。

（１）従来技術１：ブラウザの諸機能
従来のＷｅｂブラウザの一部には，リクエストの送信も制限する機能が存在する。第一に，ＨＴＴＰＳのサイト（ＳＳＬもしくはＴＬＳにより保護されたサイト）は特別に扱われ，異なるＨＴＴＰＳサイト間やＨＴＴＰＳと非ＨＴＴＰＳのサイト間をまたがるリクエストの送信を拒否したり警告したりする機能が多くのブラウザに用意されている。これにより，重要なサイトがＨＴＴＰＳのみで提供されている場合には，強制リクエスト送信の脅威は緩和されているといえる。

また，Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒには，フォームの送信がサーバによって別のサーバへリダイレクトされたときに警告する機能もある。

（２）従来技術２：Ｆｉｒｅｆｏｘの拡張機能のＮｏＧＥＴ機能
ＦｉｒｅｆｏｘにＮｏＧＥＴと呼ばれる拡張機能を追加すると，ハイパーリンクを辿る際にＧＥＴメソッドのリクエストからクエリ・パラメータを削除する機能を持たせることができる。これは，部分的に強制リクエスト送信の脅威を緩和する。

（３）従来技術３：Ｍｉｃｒｏｓｏｆｔ社のアクセス制御技術
Ｗｅｂブラウザに限定された技術ではないが，ＯＳ上で稼動するプログラム一般を対象としたアクセス制御技術として，特許文献１および特許文献２の技術がある。特許文献１は，プログラムの実行単位であるプロセスごとにアクセス制御を行い，特定のプロセスが特定のサイトと通信することを禁止する技術である。また，特許文献２は，プログラムのインストール単位で同様のアクセス制御を行う技術である。特許文献１は起動されるプロセスごと，特許文献２はインストールされたプログラムごとに，適切なアクセス制御の設定を行うことによって，強制リクエスト送信を防止することができる。
特表２００２−５１７８５２号公報（ＵＳ０９／０９７，２１８） 特開２００４−３１０７７４号公報（ＵＳ１０／４０５，９７２）

しかし，このような従来技術は，強制リクエスト送信の問題を部分的にしか解決することができない。

従来技術１のブラウザの諸機能として，一部にリクエストの送信を制限する機能が備えられている。しかし，現実に実装される処理機能では，全ての越境リクエストを制限することができず不完全である。例えば，Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒでは，フォームの送信がサーバによって別のサーバへリダイレクトされたときに警告する機能を備えるが，これは強制リクエスト送信の脅威のごく一部を防ぐに過ぎない。

また，従来技術２のＦｉｒｅｆｏｘの拡張機能であるＮｏＧＥＴでは，ＧＥＴメソッドのリクエストからクエリ・パラメータを削除する場合しか対象にならないため，攻撃者は容易にこれを回避することができる。すなわち，ＧＥＴ以外のリクエストによる脅威や，クエリ・パラメータによらない脅威は緩和されない。

また，従来技術３のアクセス制御技術のうち，特許文献１の技術は起動されるプロセスごと，または特許文献２はインストールされたプログラムごとに，適切なアクセス制御の設定を行うため，Ｗｅｂブラウザ特有の振舞いに連動したきめ細かな制御を行うことができない。

特許文献１および２では，事前に，ＯＳレベルでプロセスを起動する操作を行う時やブラウザのインストール時に保護の開始を決定しなければならないため，例えば，特定のサイトへのリンクを辿る，特定のレスポンスを受け取る，といったイベントに呼応して強制リクエスト送信からの保護を始めることはできない。

また，ＨＴＭＬページのデータやクッキー，認証情報といった情報資源の分離に関しても，特許文献１では，プロセスごとに割り当てられる短期記憶領域に格納される情報は分離されるが，ファイルやレジストリといった長期記憶領域に格納される情報（不揮発性のクッキー，キャッシュなどの情報）は分離されずに共有されてしまう。また，特許文献２では，短期記憶領域および長期記憶領域のどちらの情報も分離されるが，それは本質的に複数のＷｅｂブラウザを用意するのと同じ手間が必要である。

このように，Ｗｅｂアプリケーションには強制リクエスト送信の脅威が存在する。しかし，従来の対策技術では対処が不充分であり，脅威を一部しか回避あるいは緩和できない，現実の利用において著しい不便を強いられる，といった問題がある。

本発明の目的は，ユーザに脅威を与えるおそれがある強制リクエスト送信を制限することができるクライアント装置を提供することである。

本発明は，アクセス先へのリクエスト送信を制御するプログラム，装置および方法であって，アクセス先，すなわちサーバあるいはその下位の資源を，所定の条件によって１つ以上のパーティションに区分し，任意のパーティションについて，そのパーティションに属さないアクセス先から得たＨＴＴＰレスポンスおよびそのボディコンテントによりそのパーティションに属するアクセス先へのリクエストの送信が指示されたとき，このリクエストを拒否する，ユーザに通知する，ユーザに判断を促す，リクエストに含まれる情報の一部を変更するなどの処理の１つ以上を実行する機能を備えることを特徴とする。

「パーティション」とは，所定の条件にもとづいて隔離されたアクセス先の区分のことをいい，アクセス先を区分に隔離することを「パーティショニング」という。パーティショニングは，ＨＴＴＰＳ，ＨＴＴＰ認証，フォーム内のパスワードフィールドの有無，Ｃｏｏｋｉｅヘッダの送信，Ｓｅｔ−Ｃｏｏｋｉｅヘッダの受信，Ｓｅｔ−Ｃｏｏｋｉｅヘッダの特別な属性の有無などに連動して行われる。

これによって，アクセス先の区分の境界を越えるリクエストの送信を制限することができる。

また，本発明は，前記のクライアント装置において，アクセス先に関連付けられた情報（クッキー，認証情報など）を対応するパーティションごとに隔離して保持する機能を備える。これにより，アクセス先ごとに，ページデータ，クッキー，認証情報などがパーティションごとに隔離されるため，異なるパーティション間で相互のアクセスを制限することができる。

さらに，本発明は，対応するパーティションに関連付けられた情報のリクエスト送信が指示されたときに，当該情報を含まないようにリクエストを編集して送信する機能を備えることを特徴とする。これにより，ユーザが害を被る可能性がある情報を排除したリクエスト送信を行うことができる。

本発明は以下のように動作する。

典型的にはＷｅｂブラウザとして実現される本発明のクライアント装置は，アクセス先を所定の条件によって１つ以上のパーティションに区分する処理（パーティショニング）を行う。パーティショニングの条件は，アクセス先ＵＲＬ（プロトコル名，ホスト名，ポート番号，パスからなる情報）の全部または一部の一致によるのが基本であるが，日時などによる時間的な期限，特定のクッキーの存在や認証情報の存在も条件に含めてもよい。

そして，あるパーティションに属するアクセス先へリクエスト送信が要求された場合に，その要求指示元が当該パーティションに属さないアクセス先から得たレスポンスであるならば，そのリクエストの送信を制限する。制限として，具体的には，単にリクエスト送信を拒否してもよい。または，ユーザに情報を示してユーザの判断を仰いだり，リクエストの一部を変更してから送信したりしてもよい。

さらに，クッキーや認証情報といったアクセス先に関連付けて使用される情報を上記のパーティションごとに保持する。そして，上記のパーティションを越えるリクエスト送信が要求された場合に，当該パーティションに関連付けられた情報を含まないようにリクエストを編集し，編集したリクエストを送信する。

また，パーティショニングの条件を事前に設定しておく手間を省くため，重要な処理を行うＷｅｂサイトの特徴的な傾向を見いだし，動的に条件を決定してパーティションを作成する。例えば，サーバからセッションクッキーが発行されたときに，それを契機として，そのクッキーの有効範囲（アクセス先および期限）と一致する条件を持ったパーティションを作成する。

または，同様に，ＷｅｂサーバからＢａｓｉｃ認証やＤｉｇｅｓｔ認証といったＨＴＴＰ認証が要求された場合に，それを契機として，その認証の範囲（レルムと呼ばれる）と一致する条件を持ったパーティションを作成する。

または，認証目的として多用されるパスワードフィールドを含むレスポンスが得られた場合に，パスワードフィールドがユーザに使用されて，パスワードフィールドを含むフォームが送信されるときなどに，該当するレスポンスを得たアクセス先あるいは送信しようとしているリクエストのアクセス先に応じた条件を持ったパーティションを作成する。

パーティションにもとづいてリクエスト送信の制約，パーティショニングの条件の設定は，煩雑であったり困難であったりするため，上記の処理によって，利便性をより高めることができる。

本発明のクライアント装置は，コンピュータにインストールされ実行されるソフトウェアプログラムによって実現することができる。そのプログラムは，コンピュータが読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスクなどの適当な記録媒体に格納することができ，これらの記録媒体に記録して提供され，または，通信インタフェースを介して種々の通信網を利用した送受信により提供される。

本発明によれば，所定の条件によって区分けされたパーティション境界をまたがるリクエストは，その送信前に制限され，事前設定やユーザの判断に従って，送信が拒否されたり，別のパーティション内で送信されたりする。これにより，パーティション外からパーティション内へのリクエスト要求，例えば，「信頼性のないサイト」からの要求にもとづいて「信頼性のあるサイト」への重要なリクエスト送信を防止することができる。

また，信用しているサイトに対して使用しているクッキーやＨＴＴＰ認証情報が使われないため，より安全にリクエストを送信することができる。

さらに，事前にパーティショニングの設定をしていない場合でも，重要なサイトへのアクセスの予兆，すなわち，あるＨＴＴＰＳサイトへのアクセス開始，ある種のクッキーの送受信，ＨＴＴＰ認証情報の送信，パスワードフィールドの値の送信といった事象があったときに，自動的または半自動的にパーティショニングを行うことで，利便性をより高めることができる。

本発明の一実施形態を，従来の一般的なＷｅｂブラウザと同様の，汎用的なコンピュータとオペレーティングシステム（ＯＳ）上で動作するアプリケーションプログラムとして説明する。

図１に，本発明が実施されるコンピュータの構成例を示す。

図１のコンピュータ１０は，演算装置１１，揮発性の記憶域である物理メモリ１２，不揮発性の記憶域であるディスク１３，キーボード，マウス，ビデオディスプレイなどの入出力装置１４，ネットワークＮとの入出力装置１５などを備えるものとする。コンピュータ１０上ではオペレーティングシステム（ＯＳ）と各種アプリケーションプログラムが動作する。ＯＳは，前記の各種装置の機能を，プロセスの実行制御（スケジューリング），ヒープなどの短期記憶，ファイルやレジストリなどの長期記憶，ＴＣＰ／ＩＰによる通信機能，ウィンドウシステムにもとづくグラフィカルユーザインタフェース（ＧＵＩ）などに対するシステムコールやＡＰＩの形でアプリケーションプログラムに提供する。なお，本発明の実施形態は，上記に構成に限定されるものではなく，グラフィカルでないユーザインタフェースを持つコンピュータやブラウザ専用の簡易端末装置などとして実現されても構わない。

図２に，Ｗｅｂブラウザの一般的な機能の構成および主なデータを示す。

Ｗｅｂブラウザ１００の主要な機能は，ＨＴＴＰ／ＨＴＴＰＳ通信機能１００ａ，ＨＴＭＬ文書解析・管理機能１００ｂ，レンダリング機能１００ｃ，ＧＵＩ制御機能１００ｄであり，これらの機能が，ＯＳの提供する通信ＡＰＩ１５０やＧＵＩ ＡＰＩ１４０と連携し，ＨＴＴＰプロトコルによるサーバとの通信とその主な内容物であるＨＴＭＬ文書の解釈・管理・画面表示，およびユーザとの対話的操作を実現する。多くの場合，Ｗｅｂブラウザ１００は，ウィンドウやタブと呼ばれる領域（以下，単にウィンドウと呼ぶ）を用いて，同時に複数のＷｅｂページを表示することができる。さらに，一般的に，ＨＴＴＰ認証機能１００ｅ，キャッシュ機能１００ｆ，スクリプト制御機能１００ｇ，クッキー管理機能１００ｈなども備えている。

ヒープメモリなどの短期記憶域１２０には，Ｗｅｂブラウザ１００が動作している間だけ保持されるデータが保存される。このような短期記憶域１２０のデータ（短期記憶データ）には，ＨＴＭＬ文書の解釈結果であるＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）データ，ユーザが入力したユーザＩＤとパスワード（または，入力されたデータからの生成物）を保持するＨＴＴＰ認証データ，サーバから受け取ったクッキーの情報を保持する揮発性クッキーデータが含まれる。

ファイルやレジストリなどの長期記憶域１３０には，Ｗｅｂブラウザ１００が動作を中止しても保持され続けるデータが保存される。このような長期記憶域１３０のデータ（長期記憶データ）には，キャッシュデータや不揮発性クッキーデータが含まれる。

図３に，本発明のＷｅｂブラウザ２００の機能ブロック構成とデータとを示す。ただし，図３の構成では，図２に示すＷｅｂブラウザ１００と同じ機能は略記されている。

Ｗｅｂブラウザ２００は，パーティションテーブル２０１，パーティショニング設定テーブル２０３，ウィンドウテーブル２０５，パーティショニング管理部２１０を備える。

パーティションテーブル２０１およびパーティショニング設定テーブル２０３は，長期記憶域２３０に備えられる。ウィンドウテーブル２０５は，短期記憶域２２０に備えられる。

パーティショニング管理部２１０は，リクエスト検査部２１１，ウィンドウ選択部２１３，パーティション作成部２１５，ウィンドウ作成部２１７を備える。

なお，前述した本発明のリクエスト判定手段は，リクエスト検査部２１１によって実施される。パーティショニング手段は，ウィンドウ選択部２１３，パーティション作成部２１５，およびウィンドウ作成部２１７によって実施される。リクエスト編集手段は，リクエスト編集部２１９によって実現される。

Ｗｅｂブラウザ２００は，図２に示す一般的なＷｅｂブラウザ１００の機能やデータ構造を基準として同等の処理機能を有するが，以下の特徴を持つ点が従来のものと異なる。
（ａ）複数のパーティションを持つこと。
（ｂ）ウィンドウごとに，１つのパーティションが対応付けられること。
（ｃ）パーティションごとに，短期記憶データ（ＤＯＭデータ，認証情報，揮発性クッキーなど）と長期記憶データ（不揮発性クッキー，キャッシュなど）が管理されること。
（ｄ）各ウィンドウ内で行われる処理は，そのウィンドウに対応するパーティションに割り当てられた短期記憶データおよび長期記憶データを用いて行われること。
（ｅ）リクエスト送信イベント発生時に，イベント発生元のウィンドウに応じたパーティション境界検査が行われ，パーティション間を越境しようとするリクエストは制限されること。

Ｗｅｂブラウザ２００のパーティションテーブル２０１によって上記特徴（ａ）が，ウィンドウテーブル２０５によって上記特徴（ｂ）が，パーティションＰ０，Ｐ１，…，ごとに区分けして管理された短期記憶域２２０および長期記憶域２３０によって上記特徴（ｃ）が，パーティショニング管理部２１０によって上記特徴（ｄ）および（ｅ）が，それぞれ実現されている。

次に，本発明のＷｅｂブラウザ２００のデータ定義について説明する。

本実施の形態において，「パーティション」は，何らかの条件にもとづくＷｅｂページの区分である。パーティションの区分の条件は，基本的に，そのＷｅｂページを取得するためのリクエストが持つ特徴に関して定義される。

Ｐは，ある時点で，Ｗｅｂブラウザ２００上に存在する全てのパーティションｐの集合である。

Ｐ＝｛ｐ１，ｐ２，…，ｐｎ｝
ここで，ｐ１，ｐ２，…，ｐｎは，各パーティションを一意に識別するパーティション識別子である。ｎは，その時点で存在するパーティション数である。ｎ＝０でもよく，その場合にＰは空集合である。

Ｐ′は，Ｐに特別なパーティション識別子ｐ０を加えた集合である。

Ｐ′＝｛ｐ０｝∪Ｐ
ｐ０は，どのパーティションにも含まれないことを意味する。Ｐ′は，常にＰに追従して変化する集合である。例えば，集合Ｐに要素ｐが加われば，集合Ｐ′にも自動的にｐが加わったものとみなす。

Ｗは，ある時点で，Ｗｅｂブラウザ２００上に存在する全てのウィンドウｗの集合である。

Ｗ＝｛ｗ１，ｗ２，…，ｗｍ｝
ここで，ｗ１，ｗ２，…，ｗｍは，各ウィンドウを一意に識別するウィンドウ識別子である。ｍは，その時点でのウィンドウ数である。初期状態などではｍ＝０でもよく，その場合にＷは空集合である。

Ｗ′は，Ｗに特別なウィンドウ識別子ｗ０を加えた集合である。

Ｗ′＝｛ｗ０｝∪Ｗ
ｗ０は，どのウィンドウにも属さないことを意味する。例えば，ＯＳや他のアプリケーションなど，Ｗｅｂブラウザ２００のウィンドウではないところからリクエスト送信が要求された場合などに用いられる。Ｗ′は，常にＷに追従して変化する集合である。例えば，集合Ｗに要素ｗが加われば，集合Ｗ′にも自動的にｗが加わったものとみなす。

各ウィンドウｗは，必ず１つのパーティション識別子ｐと対応付けられる。すなわち，写像ｆ：Ｗ→Ｐ′が存在するものとする。

さらに，これをＷ０も扱えるように拡張した写像ｆ′：Ｗ′→Ｐ′が定義される。ただし，常に，ｆ′（ｗ０）＝ｐ０であり，これは，どのウィンドウでもない場合は，どのパーティションにも属さないと扱うことを意味する。

任意のｐ∈Ｐ′には，パーティションｐに所属するための条件ｃｏｎｄ（ｐ）が定義されている。また，新たなパーティションを作り出すための作成条件ｎｅｗｃｏｎｄも定義されている。

なお，ウィンドウの集合Ｗは，Ｗｅｂブラウザ２００の従来の機能によって当然に保持されるべきものであるので，保持されなくてもよい。

次に，Ｗｅｂブラウザ２００の構成要素を説明する。

パーティションテーブル２０１は，パーティションの集合Ｐと条件ｃｏｎｄ（ｐ）とを示す情報を記憶する記憶部である。

図４に，パーティションテーブル２０１の例を示す。パーティションテーブル２０１は，各パーティションを１つの列とし，各列に，パーティション識別子，有効期限，条件，短期記憶域内格納位置，長期記憶域内格納位置を保持する。

パーティション識別子は，各パーティションを一意に識別できる値であれば，どのような値でもよい。

有効期限は，そのパーティションの有効期限である。日時を具体的に指定する値，”ｖｏｌａｔｉｌｅ（揮発性；Ｗｅｂブラウザ２００が処理を終了するまでの間だけ有効）”，”ｎ／ａ（ｎｏｔ ａｐｐｌｉｃａｂｌｅ；期限なし）”のいずれかの値をとる。

短期記憶域内格納位置は，そのパーティションに対応する短期記憶域２２０内のデータ（揮発性クッキーなど）の位置を指定するものである。図４に示すように，短期記憶域内格納位置は，例えば，ある特定のメモリアドレスからのオフセット（差分値）の１６進数を用いて表わされる。

長期記憶域内格納位置は，このパーティションに対応する長期記憶域２３０内のデータ（不揮発性クッキーなど）の位置を指定するものである。例えば，図５に示すようなディスクのファイルシステムにおいて，所定の基準ディレクトリ下にパーティション別のサブディレクトリを設けて長期記憶データを記憶する場合に，図４に示すように，長期記憶域内格納位置は，ある特定のディレクトリパスからの相対パスを用いて表される。

パーティションテーブル２０１の条件の項目は，条件ｃｏｎｄ（ｐ）を指定するものである。図４では，条件として，基本的な条件であるＵＲＬに対する条件と，補足的な条件である連動クッキーの条件および連動ＨＴＴＰ認証の条件が保持される。

ＵＲＬに対する条件は，プロトコル名，ホスト名，ポート番号，パスの４項目からなる。項目それぞれが，ＵＲＬの対応する部分と照合される。条件の各項目において，以下のような値が設定される。なお，特殊な値”＊”はその項目に該当する部分は，どのような値でも条件を満たすとみなすワイルドカードを意味する。

プロトコル名：”ｈｔｔｐ”，”ｈｔｔｐｓ”，または”＊”，
ホスト名：完全限定ホスト名またはその一部をワイルドカード”＊”で置き換えたもの，または”＊”，
ポート番号：０から６５５３５までの範囲の整数，”＊”，または特殊な値”ｄｅｆａｕｌｔ（ＵＲＬにポート番号指定が存在してはならないという条件を意味する）”，
パス：”／”で始まる絶対パス名，またはその一部をワイルドカード”＊”で置き換えたもの，または”＊”。

パーティションテーブル２０１の連動クッキーの項目は，後述するクッキー連動機能によるパーティション作成処理で使用するクッキーを指定するものである。この項目には，”ｎ／ａ（この条件は使用しないことを意味する）”，または，以下に述べる具体的なクッキーの条件が記憶される。

クッキーの条件は，クッキー名と，その後ろに０個以上のオプションのセミコロンで区切られたリストが記載される。

＜クッキー名＞［；＜オプション＞［；＜オプション＞［．．．］］］
クッキー名は，任意のクッキーの名前である。オプションは，
＜オプション名＞＝＜オプション値＞
の形をとる。有効なオプション名として，以下のようなものがある。

ｄｏｍａｉｎ：クッキーの適用ドメインがあればその値をとる，
ｐｏｒｔ：クッキーの適用ポート番号があればその値をとる，
ｐａｔｈ：クッキーの適用パスがあればその値をとる，
ｓｅｃｕｒｅ：クッキーにセキュア指定があれば指定し，”ｔｒｕｅ”を値とする。

連動クッキーの項目の値は，たとえば以下の値をとる。

ＪＳＥＳＳＩＯＮＩＤ，
ＡＳＰＳＥＳＳＩＯＮＩＤ；ｓｅｃｕｒｅ＝ｔｒｕｅ，
ＰＨＰＳＥＳＳＩＤ；ｄｏｍａｉｎ＝ｓｈｏｐ．ｅｘａｍｐｌｅ．ｊｐ；ｐａｔｈ＝／ｂｏｏｋｓｔｏｒｅ／
この項目の条件は，リクエストが該当するクッキーを送信しようとしているときに満たされるものとする。

パーティションテーブル２０１の連動ＨＴＴＰ認証の項目は，後述するＨＴＴＰ認証連動機能によるパーティション作成処理で使用するＨＴＴＰ認証の仕様が指定される。この項目には，”ｎ／ａ（この条件を使用しないことを意味する）”，または，以下のセミコロン区切りのリストが設定される。

”ＨＴＴＰ認証の種類（”ｂａｓｉｃ”または”ｄｉｇｅｓｔ”）；認証領域名（レルム名）（引用符で囲まれた任意の文字列）；ユーザ名（任意の文字列）；認証領域パス（”／”で始まる絶対パス，省略可）”
認証領域パスを省略した場合には，ＵＲＬ条件のパス項目と同じとみなされる。この項目の値は，たとえば以下のようなリストになる。

ｂａｓｉｃ；“Ａｕｔｈｏｒｉｚｅｄ ｕｓｅｒｓ ｏｎｌｙ”；ｙａｍａｄａ
ｄｉｇｅｓｔ；“Ｈｏｍｅ ｄｉｒｅｃｔｏｒｙ”；ｓｕｚｕｋｉ；／ｈｏｍｅ／ｓｕｚｕｋｉ／
この項目の条件は，リクエストが該当するＨＴＴＰ認証子を送信しようとしているときに満たされるものとする。

なお，パーティションテーブル２０１に関して，パーティショニング管理部２１０は，Ｗｅｂブラウザ２００の起動時に毎回チェックを行い，以下のいずれかに当てはまるパーティションの列を削除する。

・有効期限が，”ｖｏｌａｔｉｌｅ”であるか，または，具体的に指定された日時が現在時刻より古い，
・連動クッキーの項目に具体的なクッキーの条件が設定されていて，該当するクッキーがＷｅｂブラウザ２００に記憶されていないか，または有効期限切れである。

パーティショニング設定テーブル２０３は，作成条件ｎｅｗｃｏｎｄを示す情報を記憶する記憶部である。

図６に，パーティショニング設定テーブル２０３の例を示す。パーティショニング設定テーブル２０３には，パーティション作成部２１５が備える４つの機能をそれぞれ有効にするかどうかの設定が格納される。

４つの機能とは，ＨＴＴＰＳ連動機能，クッキー連動機能，ＨＴＴＰ認証連動機能，パスワードフィールド連動機能である。これらの機能に対応する項目は，「有効」または「無効」のいずれかの値をとる。さらに，それぞれの機能の実行に際して必要または有用な副次的な設定情報も含まれてよい。本実施例では，副次的な設定情報として，クッキー連動機能に関連したクッキー名パターンが設定される。

図６に示すパーティショニング設定テーブル２０３では，クッキー名パターンの項目は，以下のような正規表現で指定される。

”＾（ＪＳＥＳＳＩＯＮＩＤ｜ＡＳＰＳＥＳＳＩＯＮＩＤ｜ＰＨＰＳＥＳＳＩＤ｜ＣＧＩＳＥＳＳＩＤ）＄”
この指定は，クッキーの名前が括弧内の縦棒記号（”｜”）で区切られた４つの指定のいずれかに完全に一致する場合を意味する。

他の指定方法としては，例えば，
”（？ｉ）ｓｅｓｓ（ｉｏｎ）？ｉｄ＄”
が挙げられる。この指定は，クッキー名が，”ｓｅｓｓｉｄ”または”ｓｅｓｓｉｏｎｉｄ”で終わることを意味する。なお，”（？ｉ）”は，大文字・小文字の違いを無視する（ｃａｓｅ−ｉｎｓｅｎｓｉｔｉｖｅ）オプションを有効にすることを正規表現の中で指定するものである。

このようなパーティショニング設定テーブル２０３の設定データのもと，作成条件ｎｅｗｃｏｎｄが満たされるのは，パーティション作成部２１５のいずれかの連動機能が有効であって，かつ，その機能ごとの条件にリクエストが該当する場合である。

ウィンドウテーブル２０５は，ウィンドウの集合Ｗと写像ｆ，すなわち各ウィンドウｗとパーティションｐとの対応関係を示す情報を記憶する記憶部である。

図７に，ウィンドウテーブル２０５の例を示す。ウィンドウテーブル２０５は，各列が各ウィンドウに対応する。列はウィンドウ識別子とパーティション識別子からなる。

ウィンドウ識別子は，各ウィンドウを一意に識別できる値である。一般的には，システムが提供する値（ウィンドウハンドルなど）を用いることができる。

パーティション識別子は，パーティションテーブルに記載されたパーティション識別子のいずれかである。

図８に示すように，Ｗｅｂブラウザ２００で複数のウィンドウｗ１〜ｗ４，…，が表示されているとする。このときに，パーティションテーブル２０１の設定にもとづいて，ウィンドウｗ１，ｗ２は，アクセス先が一般的なサイトであり，パーティションｐ１，ｐ２のいずれかの条件も満たさない。そこで，パーティションｐ０と特定され，ウィンドウテーブル２０５の該当する列に，”ｐ０”が設定される。

ウィンドウｗ３は，プロトコル名が“ｈｔｔｐｓ”，アクセス先のホスト名が“ｂａｎｋ．ｅｘａｍｐｌｅ．ｃｏｍ”であり，パーティションｐ１の条件を満たす。そこで，ウィンドウテーブル２０５の該当する列に”ｐ１”が設定される。また，ウィンドウｗ４は，アクセス先のホスト名が“ｓｈｏｐ．ｅｘａｍｐｌｅ．ｊｐ”，パス名が“／ｂｏｏｋｓｔｏｒｅ／＊”であり，パーティションｐ２の条件を満たす。同様に，ウィンドウテーブル２０５の該当する列に”ｐ２”が設定される。

なお，パーティションテーブル２０１，ウィンドウテーブル２０５のデータは，パーティショニング管理部２１０の処理結果に応じて適宜変更される。

次に，本発明の動作原理を説明する。

Ｗｅｂブラウザ２００は，各ウィンドウｗ∈Ｗに対して，ウィンドウｗに対応するパーティションｐ＝ｆ（ｗ）に割り当てられた短期記憶域２２０のデータおよび長期記憶域２３０のデータを使用し，リクエストの送信，レスポンスの解釈や保持，スクリプトの動作などを行う。よって，他のパーティションのデータは使用されない。例えば，異なるパーティションに割り当てられた短期記憶域２２０または長期記憶域２３０内に，あるサーバへ送るべきクッキーが格納されていても，Ｗｅｂブラウザ２００は，そのクッキーを送信せず，ウィンドウｗ自身に割り当てられたパーティション内のクッキーだけを送信する。また，クッキーがなければ送信しない。

パーティショニング管理部２１０は，リクエスト検査部２１１，ウィンドウ選択部２１３，パーティション作成部２１５，ウィンドウ作成部２１７，およびリクエスト編集部２１９を備える。

パーティショニング管理部２１０は，あるウィンドウ内で，例えば，リンクがクリックされる，フォームの送信ボタンが押される，埋め込みオブジェクトやＪａｖａＳｃｒｉｐｔによりリクエスト送信が求められるなどのリクエスト送信イベントが発生すると，そのリクエスト送信前にパーティション境界検査処理を行う。

ここで，送信が求められたリクエストをｒ，イベント発生元のウィンドウをｗｓ∈Ｗ′とする。

図９に，リクエスト検査処理のフローチャートを示す。リクエスト検査部２１１は，ｃｈｅｃｋ＿ｒｅｑｕｅｓｔアルゴリズムによって，以下の処理を行う。

リクエスト検査部２１１は，まず，ウィンドウｗからリクエストｒを送信するイベントが発生すると，ウィンドウ選択処理（後述）を行って，リクエストｒを扱うべきウィンドウｗｄを決定する（ステップＳ１）。

ウィンドウｗｄの値が特殊な値（ｎｕｌｌ）であるかを検査する（ステップＳ２）。ウィンドウｗｄが特殊な値（ｎｕｌｌ）であれば（ステップＳ２のＹＥＳ），リクエストｒは送信すべきではないので，処理を終了する。ウィンドウｗｄが特殊な値（ｎｕｌｌ）でなければ（ステップＳ２のＮＯ），Ｗｅｂブラウザ２００は，ウィンドウｗｄでリクエストｒを送信し，その後も，ウィンドウｗｄに対応するパーティションｐ＝ｆ（ｗｄ）に割り当てられた短期記憶データおよび長期記憶データを使用して，リクエストｒの送信，レスポンスの解釈や保持，スクリプトの動作などを行う（ステップＳ３）。

図１０および図１１に，ウィンドウ選択処理のフローチャートを示す。ウィンドウ選択部２１３は，ｓｅｌｅｃｔ＿ｗｉｎｄｏｗアルゴリズムによって，以下の処理を行う。

ウィンドウ選択部２１３は，まず，元ウィンドウｗｓのパーティションｐｓ←ｆ′（ｗｓ）を求める（ステップＳ１００）。次に，リクエストｒが条件ｃｏｎｄ（ｐｓ）を満たすかを検査する（ステップＳ１０１）。リクエストｒが条件ｃｏｎｄ（ｐｓ）を満たす場合に（ステップＳ１０１のＹＥＳ），元ウィンドウｗｓと同じパーティションに所属するので，ウィンドウｗｓ内でリクエストｒを扱ってよい。したがってｗにｗｓを代入し（ステップＳ１０２），ｗを出力し（ステップＳ１０３），処理を終了する。

リクエストｒが条件ｃｏｎｄ（ｐｓ）を満たさない場合に（ステップＳ１０１のＮＯ），各パーティションｐ∈Ｐについて，リクエストｒが条件ｃｏｎｄ（ｐ）を満たすかを検査し，リクエストｒが条件ｃｏｎｄ（ｐ）を満たすようなｐを探す（ステップＳ１０４）。ただしｐ＝ｐｓの場合は，すでに検査しているので省略してよい。条件ｃｏｎｄ（ｐ）が満たされるｐがなければ，ｐ０をｐに代入する。なお，該当するｐが複数存在する可能性もあるが，何らかの手法で１つのｐを選択する。例えば，優先順位を決めておくなどして，あらかじめ条件が重ならないようにしておくのが望ましい。

ここで，リクエストｒが条件ｃｏｎｄ（ｐｓ）を満たさない場合とは，リクエストｒによって，元のパーティションｐｓと異なるパーティションｐに属するアクセス先へアクセスしようとしていることを意味する。ウィンドウ選択部２１３は，何らかの手法によって，次の選択肢のいずれかを選択する（ステップＳ１０５）。

選択肢（Ａ）：リクエストｒを拒否する，
選択肢（Ｂ）：リクエストｒをパーティションｐに受け入れる，
選択肢（Ｃ）：リクエストｒをパーティションｐ０に受け入れる（ｐ≠ｐ０のときのみ選択可），
選択肢（Ｄ）：リクエストｒを新たなパーティションに受け入れる（ｐ＝ｐ０かつｒがｎｅｗｃｏｎｄを満たすときのみ選択可）。

選択方法としては，事前に設定された条件に従って選択肢を決定する，例えば，ユーザに選択肢を表示し，入力された選択肢に決定するなどの処理を行う。

選択肢（Ａ）が選択された場合には（ステップＳ１０６の（Ａ）），ｗに特殊な値（ｎｕｌｌ）を代入し（ステップＳ１０７），ｗを出力し（ステップＳ１０３），処理を終了する。これによって，リクエストｒが破棄されることになる。

選択肢（Ｂ）が選択された場合には（ステップＳ１０６の（Ｂ）），受け入れ先パーティションをｐとして，ｆ′（ｗ）＝ｐを満たすようなウィンドウｗ∈Ｗが存在するかを調べる（ステップＳ１０８）。ｐを満たすようなｗ∈Ｗが存在するならば（ステップＳ１０９のＹＥＳ），ｗを出力して（ステップＳ１０３），処理を終了する。一方，ｐを満たすようなｗ∈Ｗが存在しないならば（ステップＳ１０９のＮＯ），ウィンドウ作成処理によって，選択されたパーティションｐに対応する新たなウィンドウｗを作成し（ステップＳ１１０），ｗを出力して（ステップＳ１０３），処理を終了する。これによって，リクエストｒは，パーティションｐで扱われることになる。

選択肢（Ｃ）が選択された場合には（ステップＳ１０６の（Ｃ）），ｐ０をｐに代入してから（ステップＳ１１１），ステップＳ１０８以降の処理を行う。これにより，リクエストｒは，パーティションｐ０で扱われることになる。

選択肢（Ｄ）が選択された場合には（ステップＳ１０６の（Ｄ）），まずパーティション作成処理によって，新たなパーティションｐを作成する（ステップＳ１１２）。次に，ウィンドウ作成処理によって，作成されたパーティションｐに対応する新たなウィンドウｗを作成し（ステップＳ１１０），ｗを出力し（ステップＳ１０３），処理を終了する。これによって，リクエストｒは，新たなパーティションｐで扱われることになる。

図１２に，パーティション作成処理のフローチャートを示す。パーティション作成部２１５は，ｃｒｅａｔｅ＿ｐａｒｔｉｔｉｏｎアルゴリズムによってリクエストｒに対応する新たなパーティションを作成する。ただし，事前条件として，リクエストｒは作成条件ｎｅｗｃｏｎｄを満たす必要がある。

パーティション作成部２１５は，所定の方法により，リクエストｒが所属する新たなパーティションｐを作成し（ステップＳ１２０），作成したパーティションｐをパーティションの集合Ｐに加え（ステップＳ１２１），ｐを出力する（ステップＳ１２２）。

具体的には，リクエストｒを含むことができるような条件を持ったパーティションｐｎをパーティションテーブル２０１に追加し，対応するデータの記憶領域を，短期記憶域２２０と長期記憶域２３０に用意する。パーティションテーブル２０１の具体的な条件の設定方法は，リクエストｒ，および作成条件ｎｅｗｃｏｎｄ，すなわちパーティショニング設定テーブル２０３に設定されている条件に依存する。

図１３に，ウィンドウ作成処理のフローチャートを示す。ウィンドウ作成部２１７は，ｃｒｅａｔｅ＿ｗｉｎｄｏｗアルゴリズムによって，パーティションｐと，新たなウィンドウｗとの対応関係を作成する。

ウィンドウ作成部２１７は，Ｗｅｂブラウザ２００によって，既存の処理方法で新たなウィンドウｗが作成されると（ステップＳ１３０），作成されたウィンドウｗをウィンドウの集合Ｗに加える（ステップＳ１３１）。さらに，ウィンドウｗと，指定されたパーティションｐとを対応付けるため，ｆ（Ｗ）＝Ｐとなるように写像ｆを変更し（ステップＳ１３２），ｗを出力する（ステップＳ１３３）。具体的には，ウィンドウテーブル２０５に新たな列を追加して，ｗとｐとを設定する。

次に，パーティション作成処理を，より詳細に説明する。

パーティション作成部２１５は，ＨＴＴＰＳ連動機能，クッキー連動機能，ＨＴＴＰ認証連動機能，パスワードフィールド連動機能を備え，個々の機能によって，以下のようにパーティション作成処理を行う。

なお，新たなパーティション識別子は他のパーティション識別子と一致しないように適当に決められ，長期記憶域内格納位置は，パーティション識別子にもとづく相対パス名，短期記憶域内格納位置は，新たに利用できるメモリ領域へのオフセットが適当に決められるものとする。

また，実際にパーティションを作成する前に，どのようなパーティション作成処理が行われるかについての情報をユーザに提示し，パーティション作成処理実行の可否，リクエスト送信の拒否などの判断を促すようにしてもよい。

（１）ＨＴＴＰＳ連動機能によるパーティション作成処理
パーティション作成部２１５は，リクエストｒのＵＲＬのプロトコル名が”ｈｔｔｐｓ”であった場合のみ，ＨＴＴＰＳ連動機能を適用してパーティションを新たに作成する。

以下に，作成されるパーティションの内容を示す。これは，ＨＴＴＰＳプロトコルのサイトへリクエストしようとした場合に，そのサイトへのリクエストを包括するパーティションが作成されることを意味する。

有効期限：”ｖｏｌａｔｉｌｅ”，
ＵＲＬプロトコル条件：”ｈｔｔｐｓ”，
ＵＲＬホスト名条件：リクエストｒの宛先ホスト名と同じ，
ＵＲＬポート番号条件：リクエストｒの宛先ポート番号指定と同じ，なければ”ｄｅｆａｕｌｔ”，
ＵＲＬパス条件：”＊”，またはリクエストｒのリクエストＵＲＩのパスからプレフィクス部を自動的に複製して適用（ユーザの判断や事前設定に応じてどちらを使うか決める），
連動クッキー条件：”ｎ／ａ”，
連動ＨＴＴＰ認証条件：”ｎ／ａ”。

（２）クッキー連動機能によるパーティション作成処理
パーティション作成部２１５は，リクエストｒに付随して送信されようとしているいずれかのクッキーの名前がパーティショニング設定テーブル２０３のクッキー名パターンに一致するときに，クッキー連動機能を適用してパーティションを新たに作成する。図６に示すパーティショニング設定テーブル２０３の例に即していえば，例えば，”ＪＳＥＳＳＩＯＮＩＤ”という名前のクッキーが送られるようなリクエストｒに対して適用される。

以下に，作成されるパーティションの内容を示す。これは，指定された名前のクッキーを付けてリクエストしようとした場合に，そのクッキーが送信されうるリクエストを包括するパーティションが作成されることを意味する。

有効期限：該当するクッキーの有効期限と同じ，なければ”ｖｏｌａｔｉｌｅ”，
ＵＲＬプロトコル条件：該当するクッキーにｓｅｃｕｒｅ属性があれば”ｈｔｔｐｓ”，なければ”＊”，
ＵＲＬホスト名条件：該当するクッキーの適用ドメインと同じ，なければリクエストｒの宛先ホスト名と同じ，
ＵＲＬポート番号条件：該当するクッキーの適用ポート番号と同じ，なければリクエストｒの宛先ポート番号指定と同じ，それもなければ”ｄｅｆａｕｌｔ”，
ＵＲＬパス条件：該当するクッキーの適用パスと同じ，なければ”＊”，
連動クッキー条件：該当するクッキーの名前，適用ドメイン，適用ポート番号，適用パス，ｓｅｃｕｒｅ属性の有無から作成したセミコロン区切りのリスト，
連動ＨＴＴＰ認証条件：”ｎ／ａ”。

（３）ＨＴＴＰ認証連動機能によるパーティション作成処理
パーティション作成部２１５は，リクエストｒにＡｕｔｈｏｒｉｚａｔｉｏｎ ＨＴＴＰヘッダーフィールドが存在するときに，ＨＴＴＰ認証連動機能を適用してパーティションを作成する。

以下に，作成されるパーティションの内容を示す。これは，ＨＴＴＰ認証の認証情報を付随してリクエストを送信しようとしたら，その認証領域（レルム）の種類・範囲，およびユーザＩＤに対応するパーティションが作成されることを意味する。

有効期限：”ｖｏｌａｔｉｌｅ”，
ＵＲＬプロトコル条件：リクエストｒのプロトコル名と同じ，
ＵＲＬホスト名条件：リクエストｒの宛先ホスト名と同じ，
ＵＲＬポート番号条件：リクエストｒの宛先ポート番号と同じ，なければ”ｄｅｆａｕｌｔ”，
ＵＲＬパス条件：送信しようとしているＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに対応するＨＴＴＰ認証領域（レルム）のパスと同じ，
連動クッキー条件：”ｎ／ａ”，
連動ＨＴＴＰ認証条件：対応するＨＴＴＰ認証領域（レルム）および認証情報から得た，ＨＴＴＰ認証の種類（”ｂａｓｉｃ”または”ｄｉｇｅｓｔ”），レルム名，認証情報のユーザＩＤ，レルムのパス名からなるセミコロン区切りのリスト。

（４）パスワードフィールド連動機能によるパーティション作成処理
パーティション作成部２１５は，リクエストｒにＨＴＭＬのフォームのパスワードフィールドに由来する（クエリまたはフォームの）パラメータが含まれているときに，ＨＴＴＰ認証連動機能を適用してパーティションを新たに作成する。パスワードフィールドとは，ｔｙｐｅ属性の値が”ｐａｓｓｗｏｒｄ”であるＩＮＰＵＴタグによって作られるフィールド（入力項目）である。

以下に，作成されるパーティションの内容を示す。これは，パスワードフィールドの値（多くの場合，認証のためのパスワード）を含めてリクエストを送信しようとしたら，そのサイトへのリクエストを包括するパーティションが作成されることを意味する。

有効期限：”ｖｏｌａｔｉｌｅ”，
ＵＲＬプロトコル条件：リクエストｒのプロトコル名と同じ，または”＊”（ユーザの判断や事前設定に応じてどちらを使うか決める），
ＵＲＬホスト名条件：リクエストｒの宛先ホスト名と同じ，
ＵＲＬポート番号条件：リクエストｒの宛先ポート番号と同じ，なければ”ｄｅｆａｕｌｔ”，
ＵＲＬパス条件：”＊”，またはリクエストｒのリクエストＵＲＩのパスからプレフィクス部を自動的に複製して適用（ユーザの判断や事前設定に応じてどちらを使うか決める），
連動クッキー条件：”ｎ／ａ”，
連動ＨＴＴＰ認証条件：”ｎ／ａ”。

（５）クッキー受け取り連動によるパーティション作成処理
以上の（１）〜（４）はリクエスト送信時に新たなパーティションを作成する方法であるが，パーティショニング管理部２１０は，別のタイミングでパーティションを作成することもできる。

クッキー受け取り連動によるパーティション作成処理は，図６のパーティショニング設定テーブル２０３のクッキー連動パーティショニングが有効で，かつ，レスポンスがＳｅｔ−ＣｏｏｋｉｅまたはＳｅｔ−Ｃｏｏｋｉｅ２のヘッダを持ち，さらにそのヘッダで指定されたクッキーの名前が，クッキー名パターンに一致するときのみ行われる。

パーティション作成部２１５は，特定のレスポンスを受け取ったときに，作成条件ｎｅｗｃｏｎｄを判断して，作成が必要であれば，ｃｒｅａｔｅ＿ｐａｒｔｉｔｉｏｎアルゴリズムにもとづいて新たにパーティションを作成し，パーティションテーブル２０１中でレスポンスを扱う方法を記述する。作成されるパーティションの情報は，リクエスト送信時のクッキー連動機能によるパーティション作成処理の場合と同じである。

ウィンドウ作成部２１７は，ｃｒｅａｔｅ＿ｗｉｎｄｏｗアルゴリズムによって，新たなパーティションと，Ｗｅｂブラウザ２００で作成されたウィンドウとを対応付ける情報を作成する。

これにより，サーバからクッキーが発行されたときに，パーティションによる隔離が可能になる。

（６）クッキー受け取りおよびサーバ指定属性の利用によるパーティション作成処理
前記（５）のパーティション作成処理において，さらに，サーバ側で重要な処理の開始を意味するセッションクッキーの発行が明示されていれば，より確実にパーティション作成処理を行うことができる。

そこで，前記のサーバからのレスポンスのＳｅｔ−ＣｏｏｋｉｅまたはＳｅｔ−Ｃｏｏｋｉｅ２ヘッダの判断方法に加えて，さらに，同クッキーにｓｅｓｓｉｏｎ＝ｔｒｕｅなる属性が指定されていたときのみ，クッキー受け取りおよびサーバ指定属性の利用によるパーティション作成処理を行う。

次に，リクエスト編集処理を説明する。

パーティショニング管理部２１０のリクエスト編集部２１９は，リクエストの送信前に，そのリクエストの内容を任意に変更することができる。リクエスト内容の変更は，事前に決められた規則に則って自動的に行ってもよいし，または，ユーザの対話的操作にる編集を行うようにしてもよい。

図１４に，ユーザの対話的操作のための画面の例を示す。パーティショニング管理部２１０は，あるパーティションにおいて，外部からそのパーティションのアクセス先へのリクエスト送信要求があった場合に，画面３００を表示して，パーティションを越境するリクエスト送信の存在をユーザに通知し，所定の処理を選択させる。例えば，画面３００内に設けられた（Ｒ）ボタン選択操作で，そのリクエスト送信を拒否するか，または，同（Ｘ）ボタン選択操作で，そのパーティション外（例えばパーティションｐ０）でリクエストを送信するか，または，同（Ｉ）ボタン選択操作でパーティション内へリクエストの情報をインポートするかを選択させる。

さらに，画面３００内に，オプション項目として「送信しない」のチェック欄を設ける。ユーザが画面３００のこのチェック欄にマークを付けたときは，送信するリクエストの内容から，チェックマークが付けられた情報を削除し，内容を編集したリクエストが送信されるようにする。

パーティション境界検査処理によって，リクエスト送信の許否や，受け入れパーティションの選択を行っているが，さらに，リクエスト編集処理によって，ユーザが害を被ることにつながりそうなリクエストのパラメータが削除または変更されるので，より安全なリクエストのみを送信してアクセスを試してみることが可能になる。

図１５および図１６を用いて，本発明の作用を説明する。

図１５に示すように，Ｗｅｂブラウザ２００が，あるＷｅｂページｘをウィンドウ４００（パーティションｐ０）に表示しているとする。

ウィンドウ４００でユーザがＷｅｂページをブラウジング中に，入力またはブックマークによってユーザが別のＵＲＬ（銀行）を指定する。別のＵＲＬ指定によってリクエスト送信が要求されると，パーティション境界検査処理が行われる。リクエスト要求されたリクエストのプロトコル名が“ＨＴＴＰＳ”であれば，このリクエスト送信をもとに別のウィンドウ４１０が生成される。さらに，ＨＴＴＰＳ連動のパーティション作成処理によって，パーティションｐ１が生成されて，ウィンドウ４１０が隔離される。

これによって，ＵＲＬ（銀行）のＷｅｂページ（銀行ページ）は新たなウィンドウ４１０に表示され，以降のリクエストはアクセス先が同じである限り，ウィンドウ４１０で扱われる。

また，図１６に示すように，隔離されたウィンドウ４１０で扱われる短期記憶データ（ページデータ，オブジェクト，揮発性クッキー，認証情報など）と長期記憶データ（キャッシュ，不揮発性クッキー，履歴など）は，それぞれ短期記憶域２２０，長期記憶域２３０に領域が確保されて隔離される。

Ｗｅｂ２００で，ウィンドウ４００とウィンドウ４１０とが表示されている間に，ウィンドウ４００のアクセス先を要求元としたリクエストであって，ウィンドウ４１０のアクセス先（銀行）へのものが要求されたとする。パーティション境界検査処理によって，このリクエスト送信がパーティションを越境するものであると判断されるので，Ｗｅｂブラウザ２００は，自動的にリクエスト送信を拒否したり，ユーザに通知して送信の可否を確認したりして，ユーザが望まないリクエスト送信を制御することができる。

また，ウィンドウ４１０に対応するパーティションｐ１の情報も，外部のウィンドウ，例えばウィンドウ４００で扱われる処理から隔離される。

続いて，ウィンドウ４００でＷｅｂページをブラウジング中に，ユーザがコミュニティサイトへログインするとする。ログインのリクエスト送信によって，パーティション境界検査処理が行われ，別のウィンドウ４２０が生成される。ログイン後にＳｅｔ−Ｃｏｏｋｉｅを持つレスポンスを受信すると，クッキー受け取り連動のパーティション作成処理によって，パーティションｐ２が生成され，ウィンドウ４２０が隔離される。

これによって，Ｗｅｂページ（コミュニティサイト）は新たなウィンドウ４２０に表示され，以降のリクエストはアクセス先が同じである限り，ウィンドウ４２０で扱われる。

コミュニティサイトは，ユーザが再訪問するようなサイトであり，ウィンドウ４２０が閉じられた後も，ウィンドウ４２０に対応するパーティションｐ２は有効な設定として保持され，パーティションｐ２に対応する長期記憶域２３０内にクッキーなどの情報が隔離されて保存される。

ウィンドウ４２０が閉じられた後に，ウィンドウ４００のアクセス先を要求元としたリクエストであって，ウィンドウ４２０のアクセス先（コミュニティサイト）へのものが要求されたとする。パーティション境界検査処理によって，このリクエスト送信がパーティションを越境するものであると判断され，Ｗｅｂブラウザ２００は，自動的にリクエスト送信を拒否したり，ユーザに通知して送信の可否を確認したりして，ユーザが望まないリクエスト送信を制御する。

後日，ユーザがコミュニティサイトを再訪しログインすると，ウィンドウ４３０が作成され，パーティションｐ２が対応付けられ，同様に隔離される。ウィンドウ４３０は，パーティションｐ２として隔離された情報を従来通り使用することができる。

なお，本実施の形態において，パーティショニング管理部２１０は，事前にパーティションテーブル２０１に適切な情報が設定されていれば，パーティションテーブル２０１およびウィンドウテーブル２０５のみを用いたパーティション境界検査処理において，リクエストｒを検査してパーティションを決定することができる。この場合には，パーティショニング設定テーブル２０３が使用されず，作成条件ｎｅｗｃｏｎｄが指定されていないことになるので，新たなパーティションは作成されない。

パーティショニング設定テーブル２０３を備えて作成条件ｎｅｗｃｏｎｄを設定することによって，ユーザが事前にパーティションテーブル２０１に情報を設定することなく，適当なタイミングで自動的にパーティションが作成されるため，より利便性が高くなる。

以上，本発明をその実施の形態により説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。

本発明の形態および実施例の特徴を列記すると以下のとおりである。

（付記１） 通信プロトコル処理においてリクエスト送信を制御するために，コンピュータを，
リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段と，
リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング手段と，
前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定手段と，
前記越境リクエストの送信を拒否するリクエスト送信制御手段とを備える制御装置
として機能させるためのリクエスト送信制御プログラム。

（付記２） 前記コンピュータを，
前記リクエスト送信制御手段は，前記越境リクエストの送信をユーザに通知し，送信許可が指示された場合に，当該越境リクエストを送信する制御装置
として機能させるための前記付記１に記載のリクエスト送信制御プログラム。

（付記３） 前記コンピュータを，
前記越境リクエストに含まれる情報の一部を変更するリクエスト編集手段を備え，
前記リクエスト送信制御手段は，前記編集された越境リクエストを送信する制御装置
として機能させるための前記付記１または前記付記２のいずれか一項に記載のリクエスト送信制御プログラム。

（付記４） 前記コンピュータを，
アクセス先に関連付けて使用される情報を，当該アクセス先が所属するパーティションに割り当てられた領域に隔離して保持するデータ記憶手段を備え，
前記リクエスト送信制御手段は，前記アクセス先に対するリクエスト送信を行う場合に，当該アクセス先が所属するパーティションの領域に隔離された情報を使用する制御装置
として機能させるための前記付記１ないし前記付記３のいずれか一項に記載のリクエスト送信制御プログラム。

（付記５） 前記コンピュータを，
アクセス先を区分するパーティショニングを実行する条件が設定されたパーティショニング設定情報を記憶するパーティショニング設定情報記憶手段と，
前記パーティショニング手段は，前記パーティショニング設定情報にもとづいて，リクエスト送信のアクセス先を区分し，当該アクセス先が前記パーティション情報に該当しない場合に前記アクセス先に対応する新たなパーティションを作成し，前記作成されたパーティションの所属条件を前記パーティション情報に追加する制御装置
として機能させるための前記付記１ないし前記付記４のいずれか一項に記載のリクエスト送信制御プログラム。

（付記６） 前記コンピュータを，
前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からセッションクッキーが発行された場合に，当該発行を契機として，当該セッションクッキーの有効範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する制御装置
として機能させるための前記付記５に記載のリクエスト送信制御プログラム。

（付記７） 前記コンピュータを，
前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先から認証が要求された場合に，当該認証の要求を契機として，当該認証の範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する制御装置
として機能させるための前記付記５に記載のリクエスト送信制御プログラム。

（付記８） 前記コンピュータを，
前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からパスワードフィールドを含むレスポンスが得られた場合に，当該パスワードフィールドに値が入力されたデータを含むリクエストの送信を契機として，当該レスポンスを得たアクセス先または当該リクエストを送信しようとしているアクセス先のいずれかに応じた所属条件を持つパーティションを作成することを，条件として設定する制御装置
として機能させるための前記付記５に記載のリクエスト送信制御プログラム。

（付記９） 通信プロトコル処理においてリクエスト送信を制御する装置であって，
リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段と，
リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング手段と，
前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定手段と，
前記越境リクエストの送信を拒否するリクエスト送信制御手段とを備える
ことを特徴とするリクエスト送信制御装置。

（付記１０） 前記リクエスト送信制御手段は，前記越境リクエストの送信をユーザに通知し，送信許可が指示された場合に，当該越境リクエストを送信する
ことを特徴とする前記付記９に記載のリクエスト送信制御装置。

（付記１１） 前記越境リクエストに含まれる情報の一部を変更するリクエスト編集手段を備え，
前記リクエスト送信制御手段は，前記編集された越境リクエストを送信する
ことを特徴とする前記付記９または前記付記１０のいずれか一項に記載のリクエスト送信制御装置。

（付記１２） アクセス先に関連付けて使用される情報を，当該アクセス先が所属するパーティションに割り当てられた領域に隔離して保持するデータ記憶手段を備え，
前記リクエスト送信制御手段は，前記アクセス先に対するリクエスト送信を行う場合に，当該アクセス先が所属するパーティションの領域に隔離された情報を使用する
ことを特徴とする前記付記９ないし前記付記１１のいずれか一項に記載のリクエスト送信制御装置。

（付記１３） アクセス先を区分するパーティショニングを実行する条件が設定されたパーティショニング設定情報を記憶するパーティショニング設定情報記憶手段と，
前記パーティショニング手段は，前記パーティショニング設定情報にもとづいて，リクエスト送信のアクセス先を区分し，当該アクセス先が前記パーティション情報に該当しない場合に前記アクセス先に対応する新たなパーティションを作成し，前記作成されたパーティションの所属条件を前記パーティション情報に追加する
ことを特徴とする前記付記９ないし前記付記１２のいずれか一項に記載のリクエスト送信制御装置。

（付記１４） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からセッションクッキーが発行された場合に，当該発行を契機として，当該セッションクッキーの有効範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記１３に記載のリクエスト送信制御装置。

（付記１５） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先から認証が要求された場合に，当該認証の要求を契機として，当該認証の範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記１３に記載のリクエスト送信制御装置。

（付記１６） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からパスワードフィールドを含むレスポンスが得られた場合に，当該パスワードフィールドに値が入力されたデータを含むリクエストの送信を契機として，当該レスポンスを得たアクセス先または当該リクエストを送信しようとしているアクセス先のいずれかに応じた所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記１３に記載のリクエスト送信制御装置。

（付記１７） コンピュータが，通信プロトコル処理においてリクエスト送信を制御する方法であって，
リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段にアクセスするデータアクセス処理過程と，
リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング処理過程と，
前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定処理過程と，
前記越境リクエストの送信を拒否するリクエスト送信制御過程とを備える
ことを特徴とするリクエスト送信制御方法。

（付記１８） 前記リクエスト送信制御過程では，前記越境リクエストの送信をユーザに通知し，送信許可が指示された場合に，当該越境リクエストを送信する
ことを特徴とする前記付記１７に記載のリクエスト送信制御方法。

（付記１９） 前記越境リクエストに含まれる情報の一部を変更するリクエスト編集過程を備え，
前記リクエスト送信制御過程では，前記編集された越境リクエストを送信する
ことを特徴とする前記付記１７または前記付記１８のいずれか一項に記載のリクエスト送信制御方法。

（付記２０） アクセス先に関連付けて使用される情報を，当該アクセス先が所属するパーティションに割り当てられた領域に隔離して保持するデータ記憶手段にアクセスする第２のアクセス処理過程を備え，
前記リクエスト送信制御過程では，前記アクセス先に対するリクエスト送信を行う場合に，当該アクセス先が所属するパーティションの領域に隔離された情報を使用する
ことを特徴とする前記付記１７ないし前記付記１９のいずれか一項に記載のリクエスト送信制御方法。

（付記２１） アクセス先を区分するパーティショニングを実行する条件が設定されたパーティショニング設定情報を記憶するパーティショニング設定情報記憶手段にアクセスする第３のアクセス処理過程と，
前記パーティショニング処理過程では，前記パーティショニング設定情報にもとづいて，リクエスト送信のアクセス先を区分し，当該アクセス先が前記パーティション情報に該当しない場合に前記アクセス先に対応する新たなパーティションを作成し，前記作成されたパーティションの所属条件を前記パーティション情報に追加する
ことを特徴とする前記付記１７ないし前記付記２０のいずれか一項に記載のリクエスト送信制御方法。

（付記２２） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からセッションクッキーが発行された場合に，当該発行を契機として，当該セッションクッキーの有効範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記２１に記載のリクエスト送信制御方法。

（付記２３） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先から認証が要求された場合に，当該認証の要求を契機として，当該認証の範囲と一致する所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記２１に記載のリクエスト送信制御方法。

（付記２４） 前記パーティショニング設定情報は，実行されたリクエスト送信のアクセス先からパスワードフィールドを含むレスポンスが得られた場合に，当該パスワードフィールドに値が入力されたデータを含むリクエストの送信を契機として，当該レスポンスを得たアクセス先または当該リクエストを送信しようとしているアクセス先のいずれかに応じた所属条件を持つパーティションを作成することを，条件として設定する
ことを特徴とする前記付記２１に記載のリクエスト送信制御方法。

本発明が実施されるコンピュータの構成例を示す図である。 Ｗｅｂブラウザの一般的な機能の構成および主なデータを示す図である。 本発明のＷｅｂブラウザの機能ブロック構成とデータとを示す図である。 パーティションテーブルの例を示す図である。 ディスクのファイルシステムにおける長期記憶データの指定の例を示す図である。 パーティショニング設定テーブルの例を示す図である。 ウィンドウテーブルの例を示す図である。 Ｗｅｂブラウザで複数のウィンドウｗ１〜ｗ４，…，が表示されている場合の例を示す図である。 リクエスト検査処理のフローチャートである。 ウィンドウ選択処理のフローチャートである。 ウィンドウ選択処理のフローチャートである。 パーティション作成処理のフローチャートである。 ウィンドウ作成処理のフローチャートである。 ユーザの対話的操作のための画面の例を示す図である。 本発明の作用を説明するための図である。 本発明の作用を説明するための図である。

符号の説明

２００ Ｗｅｂブラウザ
２０１ パーティションテーブル
２０３ パーティショニング設定テーブル
２０５ ウィンドウテーブル
２１０ パーティショニング管理部
２１１ リクエスト検査部
２１３ ウィンドウ選択部
２１５ パーティション作成部
２１７ ウィンドウ作成部
２１９ リクエスト編集部
２２０ 短期記憶域
２３０ 長期記憶域

Claims (5)

1. 通信プロトコル処理においてリクエスト送信を制御するために，コンピュータを，
   リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段と，
   リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング手段と，
   前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定手段と，
   前記越境リクエストの送信を拒否するリクエスト送信制御手段とを備える制御装置
   として機能させるためのリクエスト送信制御プログラム。
2. 前記コンピュータを，
   前記リクエスト送信制御手段は，前記越境リクエストの送信をユーザに通知し，送信許可が指示された場合に，当該越境リクエストを送信する制御装置
   として機能させるための請求項１に記載のリクエスト送信制御プログラム。
3. 前記コンピュータを，
   前記越境リクエストに含まれる情報の一部を変更するリクエスト編集手段を備え，
   前記リクエスト送信制御手段は，前記編集された越境リクエストを送信する制御装置
   として機能させるための請求項１または請求項２のいずれか一項に記載のリクエスト送信制御プログラム。
4. 通信プロトコル処理においてリクエスト送信を制御する装置であって，
   リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段と，
   リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング手段と，
   前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定手段と，
   前記越境リクエストの送信を拒否するリクエスト送信制御手段とを備える
   ことを特徴とするリクエスト送信制御装置。
5. コンピュータが，通信プロトコル処理においてリクエスト送信を制御する方法であって，
   リクエスト送信のアクセス先を区分けする１つ以上のパーティションの所属条件として，当該パーティションに属するアクセス先の所在情報の全部または一部が設定されたパーティション情報を記憶するパーティション情報記憶手段にアクセスするデータアクセス処理過程と，
   リクエスト送信が指示された場合に，前記パーティション情報にもとづいて，当該リクエスト送信のアクセス先が所属するパーティションを特定するパーティショニング処理過程と，
   前記リクエスト送信の要求元を判定し，前記リクエスト送信が，当該リクエスト送信のアクセス先のパーティションに所属しないアクセス先から取得したレスポンスまたはボディコンテントによって要求されている場合に，当該リクエストを越境リクエストと判定するリクエスト判定処理過程と，
   前記越境リクエストの送信を拒否するリクエスト送信制御過程とを備える
   ことを特徴とするリクエスト送信制御方法。

Images