(57)【特許請求の範囲】
【請求項１】
利用者からＷｅｂリクエストを出して、プロバイダを介してＷｅｂサーバからＷｅｂオブジェクトを受信するＷｅｂサービスを利用するためのＷｅｂ情報優先転送システムにおいて、
このシステムは、
利用者のサイトにおけるＬＡＮ側プロキシサーバと、
前記プロバイダのサイトにおけるＷＡＮ側プロキシサーバとを有し、
前記ＬＡＮ側プロキシサーバは、
Ｗｅｂリクエストを識別し、予め設定した条件によりサイト優先度を付加する手段と、
そのＷｅｂリクエストを、前記ＷＡＮ側プロキシサーバに送信する手段とを備え、
前記ＷＡＮ側プロキシサーバは、
Ｗｅｂリクエストに付加されたサイト優先度を取得する手段と、
取得したサイト優先度を、通信状況や設定に基づき最終優先度に変換する手段と、
前記ＷｅｂリクエストをＷｅｂサーバに中継し、Ｗｅｂサーバからその返答として送られてくるＷｅｂオブジョクトを受信する手段とを備え、
前記ＷＡＮ側プロキシサーバは、
前記Ｗｅｂリクエストから取得した優先度を最終優先度に変換し、また、それをＩＰパケットの優先制御パラメタに変換して、その返答となるＷｅｂオブジェクトのＩＰパケットに前記優先制御パラメタを付加して前記ＬＡＮ側プロキシサーバに中継するか、
または、前記Ｗｅｂリクエストから取得した優先度を最終優先度に変換し、また、その最終優先度に基づいて、その返答となるＷｅｂオブジェクトのＩＰパケットの優先制御をおこなうことを特徴とするＷｅｂ情報優先転送システム。
【請求項２】
さらに、このシステムは、
前記利用者のサイトに、利用者が利用する利用者計算機を有し、
その利用者計算機は、Ｗｅｂリクエストごとに個人優先度を設定できる手段を備え、
前記ＬＡＮ側プロキシサーバは、
さらに、利用者ごとのＷｅｂサービスの通信記録を集計する手段を備え、
前記ＬＡＮ側プロキシサーバにより設定されるサイト優先度は、
前記予め設定した条件に加えて、前記個人優先度と、前記利用者ごとのＷｅｂサービスの通信記録とに基づいて設定されることを特徴とする請求項１記載のＷｅｂ情報優先転送システム。
【請求項３】
前記Ｗｅｂサーバから受信するＷｅｂオブジェクトのトラフィック量、または、前記ＬＡＮ側プロキシサーバと前記ＷＡＮ側プロキシサーバの通信状況に応じて、
前記最終優先度からＩＰパケットの優先制御パラメタへの変換を、動的におこなうことを特徴とする請求項１記載のＷｅｂ情報優先転送システム。
【請求項４】
前記ＷＡＮ側プロキシサーバは、
さらに、利用者ごとのＷｅｂサービスの通信記録を集計する手段を備え、
利用者の利用した通信内容と、利用者の要求した優先度に基づき、利用者ごとに課金する手段を有することを特徴とする請求項１記載のＷｅｂ情報優先転送システム。
【発明の詳細な説明】
技術分野
本発明は、Ｗｅｂ情報優先転送システムに係り、ＴＣＰ／ＩＰを利用したＷｅｂサービスを提供する通信網で、Ｗｅｂサービスを受ける際に利用者、サイトの通信の優先度を設定可能にし、しかも、既存のインターネット網をそのまま利用できるようなＷｅｂ情報優先転送システムに関する。
背景技術
近年、Ｗｅｂを利用したサービスやアプリケーションの増加により、Ｗｅｂ情報の送受信が増大している。このようなＷｅｂに関する通信トラフィックが増加すると、ネットワークの回線容量が不足し、サービスのレスポンスが低下すると言う事態を生じる。また、一般にインターネットの通信は、Ｗｅｂ情報の重要度と関係なくできるだけ公平にトラフィックを配送しようとするので、重要なトラフィックとそうでないトラフィック共に一様に影響を受けることになる。そこで、重要度の高いネットワークサービスに対して、レスポンス時間を確保するため、トラフィックの重要度を識別した優先制御をおこなう必要がある。
これに対しＷｅｂを含めた従来のトラフィックの識別、優先制御方式には、主に次の四つの方式がある。
第一は、ＴＣＰ／ＵＤＰのポート番号をルータが識別し、ルータの配送で優先制御する方式である。この方式では、ルータが、ＩＰパケットのヘッダに含まれるポート番号、送信元ＩＰ、送信先ＩＰを用いてトラフィックを識別して優先制御する。一般的に、クライアントサーバ型のネットワークアプリケーションでは、特定のポート番号を利用して通信するので、この方式では、ルータが、アプリケーションの種類、クライアント、サーバを識別し優先制御できる。
第二は、ＩＰパケットのＴｙｐｅ  ｏｆ  ＳｅｒｖｉｃｅのＰｒｅｃｅｄｅｎｃｅフィールドでパケットを識別し、ルータが優先制御する方式である。この方式では、クライアントサーバ型のネットワークアプリケーションにおいて、クライアントとサーバが、通信する際にパケットのＴｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅに優先情報を付加し、アプリケーションがデータフローごとに優先度を指定できる。
第三は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用する方式である。この方式は、送信前に、経路を構成する機器に対して通信帯域の確保を要求するパケットを送信し、経路上の各機器の通信帯域を確保した後、通信する。この方式では、アプリケーションが、データフローごとに送信前に通信帯域を確保できるので、データフローごとにレスポンス時間を保証できる。
第四は、パケットシェイピングと呼ばれる方式である。これは、クライアントサーバ型のネットワークアプリケーションのデータフローを、クライアントとサーバ間の経路上において、ポート番号、送信元ＩＰ、送信先ＩＰで識別する。そして、データフローのリクエスト間隔、ネットワークウィンドウサイズを制御し、データフローごとに優先制御する。この方式では、パケットシェイパが、アプリケーションの種類、クライアント、サーバを識別し優先制御できる。
上記、第一、第二の優先制御方式は、Ｄｏｕｇｌａｓ  Ｃｏｍｅｒ著「ＴＣＰ／ＩＰネットワーク構築Ｖｏｌ１」に、第三の方式はＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）の２２０５に詳述されている。
上記従来技術の第一の方式のデータフローをポート番号で識別する方式では、アプリケーションの種類でしかデータフローを識別できない。
Ｗｅｂサービスは、一般に同一のポート番号を利用するので、Ｗｅｂリクエストごとに識別することができず、Ｗｅｂごとの優先制御や帯域保証をすることができない。
それゆえ、Ｗｅｂを利用した配信サービスやストリームサービス、Ｗｅｂ化した業務アプリケーションといった、トラフィック量、要求するレスポンス時間、優先度などの性質が異なるサービスへのＷｅｂリクエストが同一に扱われるので、重要なＷｅｂリクエストのトラフィックが圧迫され、レスポンスが低下するという問題点があった。
さらに、Ｗｅｂアプリケーションのトラフィック量は、クライアントからサーバへ向かう量よりも、サーバからクライアントへ向かう量の方が多いので、サーバからクライアントへ向かうトラフィックに対して優先制御する方が効果がある。しかし、Ｗｅｂアプリケーションは、不特定のサーバを利用するので、サーバまたは経路全体で制御が必要な優先制御方式は、実現が困難である。例えば、上記第三の方式では、経路の全て装置がＲＳＶＰのプロトコルを理解できる必要がある。
一般に、インタネット網で通信帯域が小さくなるのは、ＬＡＮなどの企業網から、公衆回線を介してプロバイダのインターネットにアクセスするところであり、これがインターネットを利用する際のボトルネックとなる。このボトルネックとなる通信経路の下り回線の優先制御をできれば効果的である。
また、上記第一ないし第四の全ての従来技術で、Ｗｅｂリクエストごとに優先制御や帯域保証をするという発想がないので、プロバイダ等のインターネット接続サービスや、企業等のサイト接続サービスでは、利用者のＷｅｂリクエストはすべて同一の優先度である。利用者が早いレスポンスでＷｅｂサービスを利用したい場合でも、他の利用者が回線の通信帯域を使い切っている場合には、遅いレスポンスでしかＷｅｂサービスを利用できない。さらに、Ｗｅｂサービスの利用量が多い利用者と、利用量が少ない利用者に対しても、同一課金で同一品質のサービスしか提供できないという一種の不公平が生じる。
本発明は、上記問題点を解決するためになされたもので、その目的は、利用者や企業などのサイトがインターネットを利用して、Ｗｅｂサービスを受けるに際し、品質や課金に応じて優先度をつけてサービスを受けることが可能であり、しかも、利用者の利用するクライアント、Ｗｅｂサーバ、経路など既存のインターネット網を利用可能なＷｅｂ情報優先転送システムを提供することにある。
発明の開示
Ｗｅｂ情報優先転送システムにおいて、利用者のサイトで個人優先度と、サイト優先度の二段階の優先度を設定できるようにする。利用者のサイトでは、ＬＡＮ側プロキシサーバにより設定できるサイト優先度が、リクエストを出すときの優先度である。プロバイダ側に置かれるＷＡＮ側プロキシサーバは、そのリクエストのサイト優先度を取りだし、通信状況や設定に応じて最終優先度に変換する。そして、Ｗｅｂリクエストに対して返答されるＷｅｂオブジェクトのＩＰパケットの優先制御パラメタに変換して、ＬＡＮ側プロキシサーバに中継するようにする。また、ＷＡＮ側プロキシサーバ内で最終優先度に基づき、優先制御をするようにしても良い。
プロバイダでの課金は、利用した通信内容と要求した優先度に基づいておこなうようにする。
発明を実施するための最良の形態
以下、第１図ないし第２８図を用いて本発明に係る各実施形態を説明する。
〔実施形態１〕
以下、第１図ないし第２４図を用いて本発明に係る第一の実施形態を説明する。
（Ｉ）システム概要
先ず、第１図を用いて本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明する。
第１図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
本発明は、利用者がＷｅｂサーバ１３０にアクセスするときに、その通信を制御するものである。特に、第１図にも示されているように、利用者がＷｅｂサーバ１３０にリクエストを出し、Ｗｅｂオブジェクトを受け取るときには、Ｗｅｂサーバ１３０から利用者の方向、いわゆる「下り」の方がトラフィックが大きくなる傾向があるので、そこの通信を制御することを主眼としている。
先ず、利用者１０４が自分の利用している利用者計算機１０３から、ブラウザを利用して、あるホームページを見たいときには、自分の属するサイトのＬＡＮ側プロキシサーバ１１０を対してＷｅｂリクエストを出す。ＬＡＮ側プロキシサーバ１１０は、公衆網に接続されているプロバイダ網のＷＡＮ側プロキシサーバ１２０にＷｅｂリクエストを出し、さらに、ＷＡＮ側プロキシサーバ１２０は、Ｗｅｂサーバ１２０にＷｅｂリクエストを伝えることになる。そして、下りは、この逆の方向に、Ｗｅｂサーバ１３０から、ＷＡＮ側プロキシサーバ１２０、ＬＡＮ側プロキシサーバ１１０を経由して、利用者計算機１０３にＷｅｂオブジェクトが伝えられることになる。
このとき、利用者１０４は、自分のＷｅｂリクエストに対して優先度を設定することができる。すなわち、重要で緊急を要するようなＷｅｂリクエストは、高い優先度を設定することになる。これが、個人優先度である。
また、利用者の属するサイトのサイト管理者１０５は、自分のサイトの管理上の観点と、個人優先度を考慮して、サイトでの通信制御の方針であるサイトポリシを予め定めておく。そして、このサイトポリシに基づき、サイト優先度を設定して、ＷＡＮ側プロキシサーバ１２０にＷｅｂリクエストをするのに際して、サイト優先度を送る。
ＷＡＮ側プロキシサーバ１２０は、Ｗｅｂサーバ１３０から送られたデータを転送するときに、そのサイト優先度に基づいて、通信パケットを優先転送したり、通信帯域を保証するなどの処理をする。
これが、本実施形態の基本的な仕組みである。
（ＩＩ）システム構成
次に、第２図を用いて本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム構成を説明する。
第２図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
本システムは、以下の三つの装置から構成される。すなわち、インターネット接続サービスを提供するプロバイダ１０２内のＷＡＮ側プロキシサーバ１２０と、サイト１０１内のＬＡＮ側プロキシサーバ１１０と、利用者１０４が利用する利用者計算機１０３がそれである。
サイト１０１内には、利用者計算機１０３、ＬＡＮ側プロキシサーバ１１０がある。利用者１０４は、実際にインターネットによりＷｅｂを利用する者である。一方、サイト１０４を管理する者として、サイト管理者１０５を想定している。
データとしては、利用者の個人情報を管理する個人情報管理表１０６が置かれている。
利用者計算機１０３は、利用者がＷｅｂ情報を見るときのブラウザ１５０を起動するようなパーソナルコンピュータを想定している。ＬＡＮ側プロキシサーバ１１０は、利用者計算機１０３とローカルエリアネットワークで接続されていて、外部のインターネット網と接続するサーバであり、利用者１０４からＷｅｂリクエストにサイト優先度を付加する役割を担っている。
利用者計算機１０３内には、ブラウザ１５０とソフトウェアプロキシ１４０の二つのアプリケーションが実行されている。
ブラウザ１５０は、Ｗｅｂサーバから送られてきたｃｏｏｋｉｅを保存するｃｏｏｋｉｅ管理表１５１を持ち、ソフトウェアプロキシ１４０に現在表示しているＷｅｂアプリケーションのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を通知する機能を持つ。ここで、ｃｏｏｋｉｅとは、Ｗｅｂサーバがユーザを識別するための情報であり、Ｗｅｂサーバは、このｃｏｏｋｉｅを用いてユーザを管理する。
ソフトウェアプロキシ１４０は、利用者計算機１０３内で実行されるソフトウェアであり、利用者の定める優先度の方針である個人ポリシにより個人優先度を設定して、ＷｅｂリクエストをＬＡＮ側プロキシサーバ１１０に中継する機能を有する。このソフトウェアプロキシ１４０は、個人ポリシ設定手段１４３、個人ポリシ管理表１４４、個人優先度決定手段１４１、中継処理手段１４２を持っている。個人ポリシ設定手段１４３は、利用者が個人ポリシを設定するためのインタフェースを提供し、その入力を個人ポリシ管理表１４４に反映して保管する。中継処理手段１４２は、ＷＡＮ側プロキシサーバ１２０とＬＡＮ側プロキシサーバを介し、１１０Ｗｅｂサーバ１３０から返送されてくるＷｅｂオブジェクトを受け取って中継する機能を有している。
なお、個人ポリシは、優先制御の対象にするＷｅｂページのＵＲＬと、それに対する個人優先度の対として表現されるものであり、詳細については後に説明することになる。
ＬＡＮ側プロキシサーバ１１０は、利用者計算機１０３からのＷｅｂリクエストを外部のインターネット網に中継するために置かれるサーバであり、Ｗｅｂリクエストに対して、サイト優先度を設定し付加する機能を有している。このＬＡＮ側プロキシサーバ１１０は、サイトポリシ管理表１１４、優先度決定手段１１１、転送先切替え手段１１２、中継処理手段１１３、利用統計管理表１１５、通信記録を格納する通信記録管理表１１６を持っている。
サイトポリシ管理表１１４には、サイト管理者１０５が決定したサイトポリシが格納されている。優先度決定手段１１１は、利用者のＷｅｂリクエストを解析しサイト優先度を決定する。
転送先切替え手段１１２は、優先度が定められているときに、ＷＡＮ側プロキシサーバ１２０にＷｅｂリクエストを送信する機能を有している。
中継処理手段１１３は、ＷＡＮ側プロキシサーバ１２０を介してＷｅｂサーバ１３０から送られてくるＷｅｂオブジェクトを受信して、次の利用者計算機１０３に中継する部分である。
また、利用統計管理表１１５には、利用者の通信の利用料が格納され、通信記録管理表１１６には、利用者の通信記録が格納されて管理できるようになっている。
一方、プロバイダ１０２内のサイトは、利用者から送られてくるＷｅｂリクエストをＷｅｂサーバ１３０に中継するためのＷＡＮ側プロキシサーバ１２０が置かれている。
ＬＡＮ側プロキシサーバ１１０から送られてくるＷｅｂリクエストには、サイト優先度が付加されているので、それに基づき、そのＷｅｂリクエストに対する応答として返送されるＷｅｂオブジェクトの通信の制御をおこなう。また、プロバイダ網には、ＷＡＮ側プロキシサーバ１２０を管理するために、プロバイダ管理者が置かれる。
ＷＡＮ側プロキシサーバ１２０は、中継処理手段１２１、要求解析手段１２２、トラフィック制御手段１２３、トラフィック量管理表１２６、ＩＰ優先度設定手段１２４、ＩＰ優先度マップ表１２５、フロー管理表１２８がある。
中継処理手段１２１は、サイト１０１からのＷｅｂリクエストをＷｅｂサーバに中継する部分である。
要求解析手段１２２は、サイト１０１からのＷｅｂリクエスト内に優先度情報が含まれるかを解析する。トラフィック制御手段１２３は、Ｗｅｂリクエストに付加されているサイト優先度の情報と現在のトラフィック量に基づいてＷｅｂオブジェクトのトラフィックを制御するように動作する。具体的には、Ｗｅｂリクエストに付加されてくるサイト優先度を、現実のトラフィック量に基づいて、最終的な優先度（以下、「最終優先度」と言う）を定める処理をおこなう。
トラフィック量管理表１２６は、Ｗｅｂオブジェクトの現在のトラフィックを管理するためのデータが格納されている。
プロバイダのサイトは、Ｗｅｂリクエストをフローと言う概念で管理し、各々にフロー番号が付されている。フロー管理表１２８は、各々のフローのトラフィックを制御するためのデータを格納するものである。
本実施形態の優先制御の仕組みは、サイト１０１で設定されてＷｅｂリクエストに付加された優先度を、そのリクエストの返答として送られくるＷｅｂオブジェクトのパケットのパラメタに反映させてトラフィックを制御しようといるものである。すなわち、サイト１０１で設定される個人優先度やサイト優先度や、それに基づいてトラフィック制御手段１２３により定められる最終優先度は、通信モデルで言う所のアプリケーション層で設定されるものであるが、その優先度をＩＰ層にあたるＴＣＰ／ＩＰのパケットのパラメタに反映させようとするものである。
ＩＰ優先度設定手段１２４は、Ｗｅｂリクエストのフローに対して、上記の仕組みに基づいてトラフィック制御手段１２３により定められる最終優先度を、対応するＷｅｂオブジェクトのパケットのパラメタ（以下、「優先制御パラメタ」と言う。）に反映させる部分である。
ＩＰ優先度マップ表１２５は、ＩＰ優先度設定手段１２４が最終優先度から優先制御パラメタに変換する際のルールを規定するためのデータが格納されている。
（ＩＩＩ）システムに用いられるデータ構造
次に、第５図ないし第１４図を用いて本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステムに用いられるデータ構造について説明する。
第５図は、個人ポリシ管理表１４４の例を示す模式図である。
第６図は、個人情報管理表１０６の例を示す模式図である。
第７図は、サイトポリシ管理表１１４の例を示す模式図である。
第８図は、利用統計管理表１１５の例を示す模式図である。
第９図は、トラフィック量管理表１２６の例を示す模式図である。
第１０図は、フロー管理表１２８の例を示す模式図である。
第１１図は、ＩＰ優先度マップ表１２５の例を示す模式図である。
第１２図は、優先度をＷｅｂリクエストへ付加するときに利用するｈｔｔｐリクエストヘッダの構造の例を示す模式図である。
第１３図は、本実施形態に係るＩＰパケットの例を示す模式図である。
第１４図は、通信記録表１１６の例を示す模式図である。
第５図に示される個人ポリシ管理表１４４は、個人ポリシを、対象となるＷｅｂリクエストの条件とそれに対する個人優先結果の対として表現する表である。
対象とするＷｅｂリクエストの条件として、リクエスト先ＵＲＬ６２０、対象オブジェクト６２１、指定範囲属性６２２、時刻６２３の項目を持ち、個人優先結果として個人優先度６２４、保証帯域６２５の項目を持っている。また、レコードの意味は、リクエスト先ＵＲＬ６２０、対象オブジェクト６２１、指定範囲属性６２２、時刻６２３が全て満たされたＷｅｂリクエストの個人優先度結果は、そのレコードの個人優先度６２４、保証帯域６２５とすると言う意味である。
リクエスト先ＵＲＬは、対象なるリクエストのＵＲＬを指定するフィールドである。この欄には、ＵＲＬを直接記述できる外、「全て」や「アクティブブラウザ」などのキーワードも指定できる。「全て」と記述した場合には、全てのＵＲＬが対象となり、「アクティブブラウザ」と記述した場合には、ウィンドウがアクティブになっているブラウザのＵＲＬが対象となる。対象オブジェクト種別６２１は、Ｗｅｂリクエストで対象となるオブジェクトの種別を指定するフィールドであり、例えば、図の様に、ファイル種別の拡張子や「全て」などのキーワードを指定する。指定範囲属性６２２は、指定したＵＲＬの範囲をさらに細かく設定するフィールドであり、図の様なキーワードを指定できるものとする。
個人優先度６２３は、図の例では、高いものから順に「優先」、「通常」、「低優先」の三種類指定できることにした。また、個人優先結果としては、保証帯域６２４のフィールドでも、その通信に係る保証帯域を記述することによっても指定できる。
第６図に示される個人情報管理表１０６は、システムが、個人を認証し管理するためのデータを記録する表であり、ユーザ名６３０、ユーザＩＤ６３１、パスワード６３２の項目を持つ。ユーザ名６３０は、通常の個人の名前である。ユーザＩＤ６３１は、システムが個人を識別するための一意的なキーである。パスワード６３２は、その個人の認証のために使われる。
第７図に示されるサイトポリシ管理表１１４は、サイト１０１でのサイトポリシを定めるルールを記述する表であり、対象となるＷｅｂリクエストの条件とそれに対するサイト優先結果の対として表現される。
対象となるＷｅｂリクエストの条件は、リクエスト先ＵＲＬ６４０、対象オブジェクト種別６４１、指定範囲属性６４２、ユーザＩＤ６４３、個人優先度６４４、利用量６４５、時刻６４６の項目であり、サイト優先結果としては、サイト優先度６４７、保証帯域６４８の項目である。このサイトポリシ管理表１１４も、全ての対象となるＷｅｂリクエストの条件を満たすＷｅｂリクエストに対して、サイト優先度結果を定めると言う意味である。また、特に注意するのは、個人優先度６４４が条件の中に含まれており、個人優先度がサイト優先度に反映される点である。
リクエスト先ＵＲＬ６４０、対象オブジェクト種別６４１、指定範囲属性６４２の意義は、第５図の個人ポリシ管理表のときと同様である。ユーザＩＤ６４３は、このポリシの対象とするユーザのＩＤであり、第６図の個人情報管理表１０６のユーザＩＤ６３１のフィールドで定義されたものである。個人優先度６４４は、個人ポリシ管理表１４４の個人優先度６２３のフィールドにより定義される優先度である。利用量６４５は、回線をどれだけ使っているかを表すトラフィック量である。時刻６４６は、このサイトポリシを適用する通信時刻を表す。
サイト優先度６４７は、以上の対象となるＷｅｂリクエストの条件を満たしたときに、定められるサイトの優先度であり、第７図の例では、４段階になっている。ここでは、数値が少ないものほど優先度が高いものとする。保証帯域６４８は、Ｗｅｂリクエストの条件を満たしたときに、サイトとして保証する帯域量である。
第８図に示される利用統計管理表１１５は、利用者の過去のＷｅｂサービス利用量を示す表であり、利用者毎に、これまでのサイトでの通信のトラフィック量の累積量が示される。利用統計管理表１１５は、ユーザＩＤ６５０、個人優先度の別のトラフィック量６５１、６５２、６５３を持っている。
第９図に示されるトラフィック管理表１２６は、ＷＡＮ側プロキシサーバ１２０においてトラフィック制御をする際に用いられる表であり、優先度ごとに現状のトラフィック量と割り当て可能な上限値を示すものである。優先度６６０は、ＷＡＮ側プロキシサーバ１２０でトラフィック制御に用いる最終優先度である。トラフィック量６６１は、現状その優先度で通信しているトラフィック量であり、マップ可能トラフィック量６６２は、その優先度で割り当てることのできるトラフィック量の上限値である。
第１０図に示されるフロー管理表１２８は、ＷＡＮ側プロキシサーバ１２０内のＷｅｂリクエストと、その返答として送られるＷｅｂオブジェクトを、フローとして管理する表である。Ｗｅｂリクエストと、その返答として送られるＷｅｂオブジェクトに関する通信は、ＷＡＮ側プロキシサーバ１２０内でフロー番号を付して管理される。
フロー管理表１２８は、フロー番号６７０、サイト優先度６７１、最終優先度６７２、トラフィック量６７３、保証帯域６７４の項目を持つ。フロー番号６７０は、Ｗｅｂリクエストと、その返答として送られるＷｅｂオブジェクトに関するデータフローに対して一意的に付される番号である。サイト優先度６７１は、ＬＡＮ側プロキシサーバ１１０でＷｅｂリクエストに付加されるサイト優先度である。最終優先度６７２は、ＷＡＮ側プロキシサーバ１２０内で、サイト優先度やその他の通信状況を参照して最終的に決定される最終優先度である。保証帯域６７４は、Ｗｅｂリクエストで要求された保証帯域である。
第１１図に示されるＩＰ優先度マップ表１２５は、最終優先度とＩＰ層での優先制御パラメータの対応規則を示す表である。最終優先度６８０は、ＷＡＮ側プロキシサーバ１２０内で決定されたフローの最終優先度であり、優先制御パラメタ６８１には、ＩＰパケットの優先度を示すＰｒｅｃｅｄｅｎｃｅ値が入る。
第１２図に示されるｈｔｔｐリクエストヘッダは、優先度をＷｅｂリクエストへ付加するときに利用されるｈｔｔｐリクエストヘッダの構造を示している。
装置間で優先度の伝達するために、ＲＦＣで規定されているｈｔｔｐ  Ｖｅｒ１．１と言う規格が定められている。それと比較し、ヘッダ拡張項目として、個人優先度６９０、サイト優先度６９１、保証帯域６９２の項目が追加されていて、個人ポリシで定めた個人優先度、サイト優先度で定めたサイト優先度は、このエリアに書き込まれる。
第１３図に示される本実施形態に係るＩＰパケットは、ＩＰ層で利用する優先制御パラメタの例がヘッダ部分に付加されている。具体的には、ＩＰ層でパケット単位の優先制御するために、ＩＰヘッダ内のＴｙｐｅ  ｏｆ  ｓｅｒｖｉｃｅのＰｒｅｃｅｄｅｎｃｅフィールド７００に優先度情報を付加されている。
第１４図に示されている通信記録表１１６は、ＷＡＮ側プロキシサーバ１２０内での通信の記録データを格納する表である。通信記録表１１６は、利用時刻７１０、クライアントＩＰアドレス７１１、利用ＵＲＬ７１２、利用サイズ７１３、優先度７１４、使用帯域７１５の項目を持っていて、それぞれの通信があるたびに記録され、プロバイダが利用者に課金するときに使われる。
（ＩＶ）システムの通信動作の詳細
次に、第２図、第３図ないし第４図、第１５図ないし第２３図を用いて本発明の第一の実施形態に係るＷｅｂ情報優先転送システムの通信動作の詳細について説明する。
第３図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムの通信シーケンス図である。
第４図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムの通信の流れの概略を示す図である。
第１５図は、ログイン画面を示す模式図である。
第１６図は、個人ポリシ設定画面を示す模式図である。
第１７図は、個人ポリシ設定の手順を示すフローチャートである。
第１８図は、ソフトウェアプロキシ１４０がＷｅｂリクエストの受け付けるときの手順を示すフローチャートである。
第１９図は、ＬＡＮ側プロキシサーバ１１０がＷｅｂリクエストを受け付けるときの手順を示すフローチャートである。
第２０図は、Ｗｅｂリクエストの転送先を決定する手順を示すフローチャートである。
第２１図は、ＷＡＮ側プロキシサーバ１２０がＷｅｂリクエストを受け付けるときの手順を示すフローチャートである。
第２２図は、トラフィック制御をする手順を示すフローチャートである。
第２３図は、優先制御パラメタを設定する手順を示すフローチャートである。
なお、本発明のＷｅｂ情報優先転送システムの通信の流れの大要は、第４図に示す通りなので、この図を押さえて各処理の流れを見ていけば理解しやすい。
（ＩＶ−１）ユーザ登録
先ず、利用者１０４が、優先制御付きでＷｅｂサービスを利用したい場合には、最初にサイト１０１内にある個人情報管理表１０６に、ユーザＩＤ、パスワードを利用者情報として登録する。個人情報管理表１０６には、第６図に示したように格納される。
（ＩＶ−２）個人ポリシの設定と個人ポリシの登録
次に、利用者１０４は、優先的に利用したいＷｅｂサービスのＵＲＬと優先度を個人ポリシとして、第６図の個人ポリシ設定画面５３０を用いて、ソフトウェアプロキシ１４０に登録する。
第６図に示されるように個人ポリシ設定画面５３０には、個人優先度を指定する優先ボタン５３１、通常ボタン５３２、低優先ボタン５３３がある。また、全リクエストボタン５３５、最前列ブラウザボタン５３６、指定ＵＲＬボタン５３７と、ＵＲＬを指定するためのＵＲＬ入力欄５３４、ＵＲＬ追加ボタン５３８、ＵＲＬ削除ボタン５３９によって、対象とするＷｅｂリクエストを指定することができる。
優先度の指定の仕方は、先ず、対象とするＷｅｂリクエストを指定し、その後に望みの優先度のボタンをクリックすることになる。
Ｗｅｂリクエストは、実際には、以下の三種類の方法で指定することができる。
一つ目は、全リクエストボタン５３５の選択して、以後のＷｅｂリクエストすべての優先度を設定する方法である。
二つ目は、アクティブブラウザボタン５３６の選択して、ウィンドウがアクティブになっているのブラウザが表示しているＷｅｂサービスを指定する方法である。
これは、マルチウィンドウを持つＯＳでは、ブラウザを複数立ち上げる場合がある。そのとき、最前列にあってアクティブになっているブラウザの表示しているＵＲＬに対して優先度を設定しようとするものである。
三つ目は、指定ＵＲＬボタン５３７の選択で、特定のＵＲＬに対して優先度を設定する方法である。優先したいＵＲＬの登録は、ＵＲＬ入力欄５３４にＵＲＬを入力後、ＵＲＬ追加ボタン５３８を押し登録できる。ＵＲＬの登録を抹消する場合には、ＵＲＬ入力欄５３４にＵＲＬを入力後、ＵＲＬ削除ボタン５３９を押すことで登録を抹消できる。
上記の方法で対象とするＷｅｂサービスのＵＲＬを指定した後、個人優先度を指定する。個人優先度は、優先ボタン５３１、通常ボタン５３２、低優先ボタン５３３により、それぞれ優先、通常、低優先に設定できる。個人優先度は、優先、通常、低優先の順に高くなっていて、優先度が高い場合には、優先度の低いＷｅｂリクエストのトラフィックよりも、レスポンスが低下されないことが保証されている。
上記の入力作業がおこなわれると、ソフトウェアプロキシ１４０の個人ポリシ設定手段１４３は、第１７図のフロチャートに基づき個人ポリシ管理表１４４に登録する。
先ず、ＵＲＬ、優先度が上記の方法で、利用者から入力される（Ｓ５４０）。
次に、ブラウザが表示しているＵＲＬの優先度を変更するか否かを判定し（Ｓ５４１）、必要なら場合には、指定方法がブラウザが表示しているページのＵＲＬを取得して（Ｓ５４２）、入力された個人ポリシを個人ポリシ管理表に登録する。個人ポリシ管理表１４４には、第５図のようなフォーマットで格納される。
（ＩＶ−３）ログイン
利用者１０４がＷｅｂサービスを利用する場合には、ログインによりユーザ認証を受けることが必要である。
実際に、利用者がＷｅｂサービスを要求すると、Ｗｅｂサーバ１３０へのＷｅｂリクエストは、個人ポリシ決定手段１４１を経由して、ＬＡＮ側プロキシサーバ１１０に送られる。この際、Ｗｅｂリクエストに、利用者を認証するｃｏｏｋｉｅが付加されていない場合には、ＬＡＮ側プロキシサーバ１１０は、利用者１０４にログイン画面を返送し、ログイン処理を要求する。
ユーザ認証に利用するログイン画面は、第６図に示されるような画面であり、Ｗｅｂページとして利用者１０４に提供され、利用者１０４はブラウザ１５０によりアクセスすることができる。ログイン画面５２０には、ユーザＩＤ入力欄５２１とパスワード入力欄５２２があり、ここに利用者１０４は、自分のユーザＩＤとパスワードを入力する。ブラウザ１５０は、入力されたユーザＩＤとパスワードをログイン要求としてＬＡＮ側プロキシサーバ１１０に送信する（第３図のＳＱ５０１）。
上記のログイン処理を終了した利用者１０４は、個人優先度付きでＷｅｂサービスを利用できることになる。
（ＩＶ−４）ソフトウェアプロキシ１４０のＷｅｂリクエストの受付け
次に、第１８図のフローチャートを追いながらソフトウェアプロキシ１４０のＷｅｂリクエストの受け付けるときの手順を説明する。
ブラウザ１５０からのＷｅｂリクエストは、ソフトウェアプロキシ１４０へ送られる（第３図のＳＱ５０３）。
ブラウザ１５０からのＷｅｂリクエストを受信し（Ｓ５５０）、次に、読み出すべき個人ポリシが、存在するか否かを判定する（Ｓ５５１）。
個人ポリシがある場合は、第５図に示される個人ポリシ管理表１４４から個人ポリシを一つ読み出して（Ｓ５５２）、読み出した個人ポリシのレコードと受信したＷｅｂリクエストの条件が一致するか否かを判定する（Ｓ５５３）。これを読み出すべき個人ポリシがなくなるまで繰り返す。
具体的には、先ず、個人ポリシ管理表１４４のＵＲＬ６２０と、ＷｅｂリクエストのＵＲＬが一致するか判定する。この際、指定範囲属性６２２が下位ディレクトリの場合には、ＵＲＬ６２０以下のディレクトリも一致するとし、「サイト内」と記述されたいる場合には、同一サイトも一致とする。次に、ＷｅｂリクエストのＷｅｂオブジェクトの種類と、対象オブジェクト種別６２１を比較する。
このように判定していき受信したＷｅｂリクエストの条件が、個人ポリシと一致した場合には、個人ポリシに登録されている個人優先度６２３をＷｅｂリクエストに付加する（Ｓ５５４）。具体的には、第１２図に示すｈｔｔｐリクエストヘッダの個人優先度６９０の項目に個人ポリシ管理表１４４の個人優先度６２３の値を書き込む。そして、最後に、Ｗｅｂリクエストを送信する（Ｓ５５５）。
なお、本実施形態では、個人ポリシを、個人ポリシ管理表１４４の−レコードとして表現したが他の方法で表現しても良い。
（ＩＶ−５）ＬＡＮ側プロキシサーバ１１０のＷｅｂリクエストの受付け
次に、第９図のフローチャートを追いながらＬＡＮ側プロキシサーバ１１０のＷｅｂリクエストの受付けるときの処理について説明する。
Ｗｅｂリクエストは、ソフトウェアプロキシ１４０からＬＡＮ側プロキシサーバ１１０に送信されてくる（第３図のＳＱ５０５）。
先ず、ＬＡＮ側プロキシサーバ１１０は、Ｗｅｂリクエストを受信し（Ｓ５６０）、ログイン要求かを判定する（Ｓ５６１）。
ログイン要求の場合には、個人情報管理表１０６を用いて、第３図のＳＱ５０１により送信されてくるユーザＩＤとパスワードを比較して、有効か否かを判定する。
有効の場合には、ｃｏｏｋｉｅ発行フェーズ５６２でｃｏｏｋｉｅを発行する（Ｓ５６２、第３図のＳＱ５０２）。
ログイン要求でない場合には、Ｗｅｂリクエストのｈｔｔｐヘッダに有効なｃｏｏｋｉｅが含まれるかを判定する（Ｓ５６３）。
ｃｏｏｋｉｅを含まない場合には、ログイン画面を利用者に送信して（Ｓ５６４）、利用者１０４にログインを促す。なお、ｃｏｏｋｉｅを発行後、一定時間リクエストがない場合には、利用を終了したと判断し、そのｃｏｏｋｉｅを破棄することにする。ここでは、個人認証については、ユーザＩＤ、パスワードとｃｏｏｋｉｅの併用する方式を取ったが、他の方式、例えば、特定の暗号アルゴリズムを用いる方法、指紋などによる方法などを利用しても良い。
Ｗｅｂリクエストのｈｔｔｐヘッダに有効なｃｏｏｋｉｅが含まれていて、個人の認証ができるときには、次に、個人認証チェックの後、認証された利用者１０４の利用量を第８図に示される利用統計管理表１１５から得る（Ｓ５６５）。
次に、読み出すべきサイトポリシの存在の有無を判定し（Ｓ５６６）、サイトポリシがある場合には、第７図に示されるサイトポリシ管理表１１４からサイトポリシを一つ読み出す（Ｓ５６７）。
続いて、受信したＷｅｂリクエストの条件と読み出したサイトポリシが一致するか否かを判定する（Ｓ５６８）。そして、この処理を全てのサイトポリシがなくなるまで繰り返す。
具体的には、ＷｅｂリクエストのＵＲＬ、Ｗｅｂオブジェクトの種類を第１８図のＳ５５３と同様の方法で比較する。次に、Ｗｅｂリクエストの利用者と個人優先度を、それぞれ、ユーザＩＤ６４３、個人優先度６４４と比較する。次に、利用者の利用量が、利用量６４５に記録された条件と一致するか判定する。例えば、ある利用者の利用量が、全体の利用量の平均を越えた場合にはサイト優先度を下げるなどのポリシを設定することができる。
なお、本実施形態では、サイトポリシを、サイトポリシ管理表１１４の−レコードとして表現したが他の方法で表現しても良い。
受信したＷｅｂリクエストの条件が、サイトポリシに一致した場合には、サイトポリシ管理表１１４に登録されているサイト優先度６４７をＷｅｂリクエストに付加する（Ｓ６４７）。具体的には、第１２図に示すｈｔｔｐリクエストヘッダのサイト優先度６９１の項目にサイトポリシ管理表１１４のサイト優先度６４７の値を書き込む。
そして、次の（ＩＶ−６）のフェーズで転送先を決めた後に、Ｗｅｂリクエストを外部のインターネット網に送信する（Ｓ５７０、第３図のＳＱ５０５）。
（ＩＶ−６）Ｗｅｂリクエストの転送先の決定
次に、第２０図のフローチャートを追いながらＬＡＮ側プロキシサーバ１１０で、Ｗｅｂリクエストの転送先を決定する手順について説明する。
サイト優先度が決定されたＷｅｂリクエストは、ＬＡＮ側プロキシサーバ１１０の転送先切替え手段１１２に送られてくる（Ｓ５８０）。
ここで受け付けられたＷｅｂリクエストは、サイト優先度の有無が判定され（Ｓ５８１）、サイト優先度が付加されている場合には、予め設定した適当なＷＡＮ側プロキシサーバ１２０に送信される（Ｓ５８２）。例えば、ＷＡＮ側プロキシサーバが複数用意されている場合には、Ｗｅｂリクエストで要求されたＵＲＬから適当なＷＡＮ側プロキシサーバを選択する。
サイト優先度が付加されていない場合には、ＷＡＮ側プロキシサーバ１２０には送られず、本発明の優先制御はおこなわれない。
（ＩＶ−７）ＷＡＮ側プロキシサーバ１２０のＷｅｂリクエストの受付け
上記のようにサイト優先度が付加されたＷｅｂリクエストは、ＷＡＮ側プロキシサーバ１２０に送信される。
次に、第２１図のフローチャートを追いながら、ＷＡＮ側プロキシサーバ１２０のＷｅｂリクエストの受け付けるときの手順について説明する。
ＷＡＮ側プロキシサーバ１２０に送信されたＷｅｂリクエストは、中継処理手段１２１を経由し、要求解析手段１２２に送信される。
最初に、要求解析手段１２２でＷｅｂリクエストを受付け（Ｓ５９０）、Ｗｅｂリクエストの中のｈｔｔｐヘッダにサイト優先度が定義されているか否かを判定し（Ｓ５９１）、付加されていれば、トラフィック制御手段１２３に通知する（Ｓ５９２）。
その後、Ｗｅｂリクエストで要求されている要求先のＷｅｂサーバ１３０に、Ｗｅｂリクエストを送信する（Ｓ５９３、第３図のＳＱ５０６）。
（ＩＶ−８）ＷＡＮ側プロキシサーバ１２０のトラフィック制御
ＷＡＮ側プロキシサーバ１２０から、Ｗｅｂサーバ１３０にＷｅｂリクエストが送信され、その返答としてＷｅｂオブジェクトを、ＷＡＮ側プロキシサーバ１２０のトラフィック制御手段１２３が受信する（第３図のＳＱ５０７）。
以下では、第２２図のフローチャートを追いながらＷＡＮ側プロキシサーバ１２０でのＷｅｂオブジェクトに対するトラフィック制御の手順について説明する。
先ず、トラフィック制御手段１２３は、Ｗｅｂサーバ１３０からのＷｅｂオブジェクトを受信する（Ｓ６００）。
そして、受信したパケットのトラフィック量を測定して、現在のＷＡＮ側プロキシサーバを通過するトラフィック量を、優先度ごとに、第９図に示したトラフィック量管理表１２６のトラフィック量６６１に記録する。
同様に、第１４図に示した通信記録表１２７に対して、Ｗｅｂリクエストを受信した時刻、要求されたＵＲＬ、Ｗｅｂオブジェクトのサイズ、優先度、受信に使用した帯域を、それぞれ利用時刻６８３、利用ＵＲＬ６８４、サイズ６８５、優先度６８６、利用帯域６８７に記録する。
次に、（ＩＶ−７）のフェーズで優先度があった場合には、要求解析手段１２２からそれが通知されているので、その優先度が通知されたか否かを判定する（Ｓ６０２）。
優先すべきトラフィックの場合には、トラフィック量管理表１２６から、ＷＡＮ側プロキシサーバ１２０を通過する優先度別のトラフィック量と割当て可能なトラフィック量を取得する。続いて、受信したＷｅｂオブジェクトのトラフィック量が、割当て可能なトラフィック量を越えるかを判定し（Ｓ６０３）、越える場合には、優先度を一つ下げ（Ｓ６０４）、最終優先度とする（Ｓ６０５）。
もし、トラフィック量が、割当て可能なトラフィック量を越えない場合には、指定されたサイト優先度を最終優先度とする（Ｓ６０５）。
その後、Ｗｅｂオブジェクトに最終優先度を付加して、ＩＰ優先度設定手段１２４へ送る（Ｓ６０６）。なお、トラフィック制御手段１２３は、第１０図に示したフロー管理表１２８によりトラフィックを管理している。
（ＩＶ−９）優先制御パラメタを設定
前の（ＩＶ−８）のフェーズでは、最終優先度が決定されたが、この最終優先度は、トラフィック制御手段がアプリケーション層で決定したものである。これをＩＰ層で認識する優先制御パラメタに変更して、パケットのレベルで優先制御をさせようにするというのが本発明の考え方である。
以下、この手順を第２３図のフローチャートを追いながら説明する。
最初に、ＩＰ優先度設定手段１２４は、トラフィック制御手段１２３からＷｅｂオブジェクトを受取る（Ｓ６１０）。
次に、そのＷｅｂオブジェクトに最終優先度が付加されているかをで判定する（Ｓ６１１）。そして、最終優先度が付加されている場合には、第１１図に示されたＩＰ優先度マップ表１２５から、その最終優先度に対応するＩＰ層での優先制御パラメタとしてＰｒｅｃｅｄｅｎｃｅの値を得る（Ｓ６１２）。次に、第１３図に示した送信するＩＰパケットのＴｙｐｅ  ｏｆ  ｓｅｒｖｉｃｅのＰｒｅｃｅｄｅｎｃｅフィールド７００に、最終優先度から変換したＰｒｅｃｅｄｅｎｃｅの値を付加し（Ｓ６１３）、ＩＰパケットをインターネット網に送信する（Ｓ６１４）。
（ＩＶ−１０）その後のパケットの流れ
第４図に示されるように、優先制御パラメタを設定されたＩＰパケットは、ルータに送られて、インターネット網に中継される。ＷＡＮ側プロキシサーバ１２０とＬＡＮ側プロキシサーバ１１０のインターネット網には、ルータ１３１ｂとルータ１３１ａが接続されていて、それらのルータは、優先制御パラメータにより、ＩＰパケットを優先処理して制御する機能を有している。
ＷＡＮ側プロキシサーバ１２０から送信されたＷｅｂオブジェクトは、ＬＡＮ側プロキシサーバ１１０の中継処理手段１１３が受信する。中継処理手段１１３では、受信したＷｅｂオブジェクトのトラフィック量を、利用統計管理表１１５と通信記録表１１６に記録し、利用者計算機１０３に送信する（第３図の５０８）。
ＬＡＮ側プロキシサーバ１１０から送信されたＷｅｂオブジェクトは、利用者計算機１０３のソフトウェアプロキシ１４０の中継処理手段１４２に送られる（第３図の５０９）。中継処理手段１４２は、トラフィックの要求時刻、利用者計算機のＩＰアドレス、要求ＵＲＬ、Ｗｅｂオブジェクトのサイズ、個人優先度、使用した帯域を通信記録表１１６に記録する。そして、中継処理手段１４２は、ブラウザ１５０に送信し（第３図の５０９）、最終的に利用者１０４に提供される。
（Ｖ）その他の通信制御方法
これまでの例では、ＩＰバケットのＴｙｐｅ  ｏｆ  ｓｅｒｖｉｃｅのＰｒｅｃｅｄｅｎｃｅを利用し、その優先制御パラメタを解釈できるようなルータによりパケットの優先制御をおこなうようにした。
この優先制御の外に他の優先制御方法を利用しても良い。また、ＷＡＮ側プロキシサーバ１２０が、優先制御をしつつ配送する方法も考えられる。例えば、ＷＡＮ側プロキシサーバ１２０が、優先度ごとにパケットをバッファリングして配送する方法が考えられる。
（ＶＩ）本発明のシステムの通信の特徴
上記のように、本発明は、アプリケーションで設定される通信の優先度を、ＩＰ層のパケットの各Ｐｒｅｃｅｄｅｎｃｅの値に変換するものである。本発明では、第９図に示されるように、優先度ごとにマップ可能なトラフィック量を持っている。したがって、優先度を各Ｐｒｅｃｅｄｅｎｃｅの値に変換すると、結果として、ＩＰ層の各Ｐｒｅｃｅｄｅｎｃｅの値ごとのパケットのトラフィック量が規定されることになり、そのトラフィック量を越えないよう優先度を制御することで、ルータ等のＩＰ層での中継装置において、優先度が高いパケットキューが溢れず、ＩＰ層でのパケット通信が支障なく動作することが期待できる。
また、帯域保証要求のＷｅｂリクエストに対しては、最優先のＰｒｅｃｅｄｅｎｃｅを帯域保証専用として割当て、マップ可能なトラフィック量を設定し、サイトポリシでそのトラフィック量だけ帯域保証要求付きのＷｅｂリクエストを受付けることで実現できる。このとき、マップ可能なトラフィック量を越える帯域保証要求のＷｅｂリクエストがあるときには、最終優先度を下げることにより対応することになる。
さらに、上記実施形態では取り上げなかったが利用者がＷｅｂリクエスト以外の通信をおこなう場合もある。そのような場合のｈｔｔｐ以外のアプリケーション（例えば、ＦＴＰ、メールなど）のトラフィックの制御は、利用する各中継装置の優先制御機能を利用し、例えば、ＴＣＰのポートなどを利用して、アプリケーションごとに帯域の設定をおこなう。
このように、第一の実施形態では、利用者やサイト管理者の優先制御ポリシに従い、利用者ごとの利用量や利用するＷｅｂページなどのアプリケーション層の情報を利用して、ＩＰ層でパケット単位での優先制御や帯域保証ができる。
さらに、ＷＡＮ側プロキシサーバ１２０を利用して、優先制御や帯域制御に対応していないＷｅｂサーバ１３０からのＷｅｂオブジェクトに対しても、ＷＡＮ側プロキシサーバ１２０が利用者から要求されたポリシでトラフィック制御し、Ｗｅｂオブジェクトに対して優先制御や帯域保証をおこなうことができる。
すなわち、ＷＡＮ側プロキシサーバ１２０は、本発明を実施するために、優先度を見て、それを優先制御パラメタに変換する機構をもっているが、Ｗｅｂオブジェクトを提供するＷｅｂサーバ１３０は、これまでのＷｅｂサーバとなんら変わることなく、通信のインターフェースも全く変わることがなく、Ｗｅｂサービスが提供できると言うことである。
（ＶＩＩ）本システムにより期待されるサービス
次に、第２４図を用いて本発明の第一の実施形態に係るＷｅｂ情報優先転送システムにより期待されるサービスについて説明する。
第２４図は、プロバイダ１０２が、利用者１０４に対して発行する請求書の一例を示す模式図である。
請求書７２０は、利用明細表７２１、請求内訳表７２２、請求額７２３の欄からなっている。
利用明細表７２１は、利用時刻７２４、利用ＵＲＬ７２５、サイズ７２６、優先度７２７、使用帯域７２８の項目を持ち、請求内訳表７２２は、優先度７２９、利用量７３０、利用帯域７３１、小計７３２を持っている。
すなわち、利用明細表７２１は、利用者が過去にどれだけサービスを提供されたかの記録であり、請求内訳表７２２は、それに基づいて料金を計算する根拠を示している。
さて、プロバイダが、サイトや利用者に対して提供できるサービスを第２３図によりサービスの内容を参照しつつ示すと以下の如くである。
一つ目は利用者が、動的に品質や価格を選択して利用できるＷｅｂサービスである。このサービスにより、利用者は、レスポンス時間が重要でない配信サービスは、利用できる帯域が少ないが、低価格に設定されたサービスとして利用できる。逆に、レスポンス時間が重要な場合には、価格が高くても他の利用者より優先してＷｅｂサービスを利用すれば良い。
具体的には、プロバイダは、例えば、第２４図の請求書７２０のように、利用者が要求した優先度ごとに追加や割引して課金する形態の契約を結べるようにする。請求書７２０では、利用明細表７２１に、利用した時刻、利用したＷｅｂサービスのＵＲＬ、受信したＷｅｂオブジェクトのサイズ、利用者が要求した優先度、要求に基づいてプロバイダが提供した帯域が、それぞれ利用時刻７２４、利用ＵＲＬ７２５、サイズ７２６、優先度７２７、利用帯域７２８に記載される。そして、利用明細７２２から、優先度ごとに、受信したＷｅｂオブジェクトのサイズの合計、提供した帯域の平均から課金額を算出し、それぞれ優先度７２９、利用量７３９、利用帯域７３１、小計７３２に記載し、請求内訳７２２を作成する。請求内訳表７２２の優先度ごとの課金額の小計７３２の合計を、最終的な課金額として請求額７２３に印刷する。
このように通信の優先度、すなわち、通信の質に応じたサービスをプロバイダが提供することができ、利用者の立場からすると、自分の受けたいサービスの内容にそった合理的な価格でサービスを受けることができる。
二つ目は、利用者が重要とするトラフィックの、契約した帯域に占める量をサイト管理者に通知するサービスである。このサービスにより、サイト管理者は、利用者が重要とするトラフィック量を把握することができるので、より利用者の要求に応じたネットワーク回線の増設計画を立案できる。
三つ目は、トラフィック量の急増からの、既存のＷｅｂサービスの保護である。このサービスにより、新規にＷｅｂアプリケーションを導入する場合など、Ｗｅｂアプリケーションのトラフィック量が急増する場合に、ＷｅｂアプリケーションをＵＲＬやＷｅｂオブジェクトの種類等で識別し、利用する帯域を設定することで、既存のＷｅｂサービスの品質を保護することができる。また逆に、特定の帯域を必要とするＷｅｂアプリケーションを、既存のＷｅｂサービスのトラフィックから保護し導入できる。
四つ目は、Ｗｅｂサービスの種類ごとのバランス制御である。このサービスにより、Ｗｅｂを利用したストリーム配信や、配信サービスなどを、特定のＵＲＬやＷｅｂオブジェクトの種別によって識別することで、サイト管理者がサイト全体でＷｅｂサービスの種類ごとに利用量のバランスを制御でき、段階的な導入や、過剰な利用の制限ができる。
五つ目は、サイト内の利用者に対する、利用量に基づいた均一なＷｅｂサービスである。従来、Ｗｅｂリクエストは、その利用量に依存せず平等に処理されてきた。したがって、Ｗｅｂサービスの質をレスポンス時間とすると、多くリクエストした利用者が、他の利用者と同質のサービスを多く利用できる上、ネットワーク回線を圧迫するので、全体的なサービスの質を低下させる。
そこで、本発明では、Ｗｅｂサービスの質を、利用量とＷｅｂのレスポンス時間の二面から捉えている。これにより、利用したＷｅｂトラフィック量に応じ、利用量が多い利用者よりも、利用量が少ない利用者のＷｅｂリクエストを優先することができるので、利用者全員が、利用量に基づいた均一な質のＷｅｂサービスを利用できる。さらに、利用者にトラフィック量を意識させることで、必要性が低いＷｅｂの利用を自粛することが期待できる。
六つ目は、契約した帯域の空き帯域を利用するサービスである。Ｗｅｂのレスポンスの向上のために先読み技術がある。しかし、この技術はトラフィック量が一般的なＷｅｂサービスよりも多く、ネットワーク回線を圧迫しＷｅｂサービスのレスポンスを低下させるので、Ｗｅｂサービス中は同一のネットワーク回線を利用にくかった。そこで、このサービスにより、Ｗｅｂサービス中でも、先読み技術を優先度を下げることで、Ｗｅｂサービスのレスポンスを低下させることなく利用できる。また、Ｗｅｂ情報のミラーリングや、Ｗｅｂの情報検索サービスなども、同様の問題を持つので、本サービスの適応が期待できる。
〔実施形態２〕
以下、第２５図ないし第２６図を用いて本発明に係る第二の実施形態を説明する。
第２５図は、本発明の第二の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
第２６図は、本発明の第二の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
本実施形態のＷｅｂ情報優先転送システムの通信モデルでは、第２５図に示されているように利用者１０４が個人優先度を設定せず、サイト管理者１０５がサイト優先度のみを設定する。その他の機能や各機能の動作は、第一の実施形態と同様である。
構成的には、第２６図に示されているように利用者計算機１０３の中にソフトウェアプロキシを中継せず、ブラウザ１５０がＬＡＮ側プロキシサーバ１１０に直接アクセスするようになる。
この第二の実施形態の構成によれば、利用者が優先度を指定できないが、利用者計算機１０３にソフトウェアプロキシ１４０をインストールせずに済み、ＬＡＮ側プロキシサーバ１１０だけでサービスできるので、導入や管理の手間を削減することができる。
〔実施形態３〕
以下、第２７図ないし第２８図を用いて本発明に係る第三の実施形態を説明する。
第２７図は、本発明の第三の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
第２８図は、本発明の第三の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
本実施形態のＷｅｂ情報優先転送システムの通信モデルでは、第２７図に示されているようにサイト優先度は設定されず、利用者１０４が個人優先度のみを設定して、ＷＡＮ側プロキシサーバ１２０にＷｅｂリクエストを送る。その他の機能や各機能の動作は、第一の実施形態と同様である。
構成的には、第２８図に示されているようにサイト優先度を設定していたＬＡＮ側プロキシサーバ１１０が必要なくなり、利用者計算機１０３が直接、インタネット網のＷＡＮ側プロキシサーバ１２０にアクセスするようになる。
このように、第三の実施形態では、プロバイダ１０２がサイト１０１ではなく、直接利用者１０４に対して、利用者の優先度に基づき優先制御や帯域確保のサービスを提供できる。本実施形態では、サイトと言う概念は存在せず、個人や家庭でインターネットを利用する者向けの通信モデルであると言うことができる。
産業上の利用可能性
以上のように本発明のＷｅｂ情報優先転送システムは、既存のインターネット網で、プロバイダを介してＷｅｂサーバからＷｅｂ情報の提供を受けるときに、利用負担に応じたサービスを受けるのに好適な通信システムを提供できる。
【図面の簡単な説明】
第１図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
第２図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
第３図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムの通信シーケンス図である。
第４図は、本発明の第一の実施形態に係るＷｅｂ情報優先転送システムの通信の流れの概略を示す図である。
第５図は、個人ポリシ管理表１４４の例を示す模式図である。
第６図は、個人情報管理表１０６の例を示す模式図である。
第７図は、サイトポリシ管理表１１４の例を示す模式図である。
第８図は、利用統計管理表１１５の例を示す模式図である。
第９図は、トラフィック量管理表１２６の例を示す模式図である。
第１０図は、フロー管理表１２８の例を示す模式図である。
第１１図は、ＩＰ優先度マップ表１２５の例を示す模式図である。
第１２図は、優先度をＷｅｂリクエストへ付加するときに利用するｈｔｔｐリクエストヘッダの構造の例を示す模式図である。
第１３図は、本実施形態に係るＩＰパケットの例を示す模式図である。
第１４図は、通信記録表１１６の例を示す模式図である。
第１５図は、ログイン画面を示す模式図である。
第１６図は、個人ポリシ設定画面を示す模式図である。
第１７図は、個人ポリシ設定の手順を示すフローチャートである。
第１８図は、ソフトウェアプロキシ１４０がＷｅｂリクエストの受け付けるときの手順を示すフローチャートである。
第１９図は、ＬＡＮ側プロキシサーバ１１０がＷｅｂリクエストを受け付けるときの手順を示すフローチャートである。
第２０図は、Ｗｅｂリクエストの転送先を決定する手順を示すフローチャートである。
第２１図は、ＷＡＮ側プロキシサーバ１２０がＷｅｂリクエストを受け付けるときの手順を示すフローチャートである。
第２２図は、トラフィック制御をする手順を示すフローチャートである。
第２３図は、優先制御パラメタを設定する手順を示すフローチャートである。
第２４図は、プロバイダ１０２が、利用者１０４に対して発行する請求書の一例を示す模式図である。
第２５図は、本発明の第二の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
第２６図は、本発明の第二の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
第２７図は、本発明の第三の実施形態に係るＷｅｂ情報優先転送システムのシステム概要を説明するための図である。
第２８図は、本発明の第三の実施形態に係るＷｅｂ情報優先転送システムのシステム構成図である。
【図１】
0003857228.tif 000002
【図２】
0003857228.tif 000003
【図３】
0003857228.tif 000004
【図４】
0003857228.tif 000005
【図５】
0003857228.tif 000006
【図６】
0003857228.tif 000007
【図７】
0003857228.tif 000008
【図８】
0003857228.tif 000009
【図９】
0003857228.tif 000010
【図１０】
0003857228.tif 000011
【図１１】
0003857228.tif 000012
【図１２】
0003857228.tif 000013
【図１３】
0003857228.tif 000014
【図１４】
0003857228.tif 000015
【図１５】
0003857228.tif 000016
【図１６】
0003857228.tif 000017
【図１７】
0003857228.tif 000018
【図１８】
0003857228.tif 000019
【図１９】
0003857228.tif 000020
【図２０】
0003857228.tif 000021
【図２１】
0003857228.tif 000022
【図２２】
0003857228.tif 000023
【図２３】
0003857228.tif 000024
【図２４】
0003857228.tif 000025
【図２５】
0003857228.tif 000026
【図２６】
0003857228.tif 000027
【図２７】
0003857228.tif 000028
【図２８】
0003857228.tif 000029