情報配信装置及び情報配信方法
【課題】 ネットワークを介して複数のクライアントに対して情報配信を実行する情報配信装置及びその方法において，前記複数のクライアント間で受けるサービスの質になるべく不平等が生じないよう情報配信すること。
【解決手段】 満足度算出手段１０７は，各クライアントからの要求履歴と各クライアントへの情報配信履歴とに基づいて満足度を算出する。
また，情報配信能力判別手段１０３は，要求リソースの合計とサービスリソースとを比較して，情報配信装置１０の情報配信能力を判別する。
通信仕様決定手段１０５は，前記情報配信能力判別手段１０３による判別結果に応じて，通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１，若しくは，通信仕様案変更手段１０４によって前記満足度に応じて作成された通信仕様案Ｐ２のいずれかに基づいて，情報配信時の通信仕様を決定する。
【解決手段】 満足度算出手段１０７は，各クライアントからの要求履歴と各クライアントへの情報配信履歴とに基づいて満足度を算出する。
また，情報配信能力判別手段１０３は，要求リソースの合計とサービスリソースとを比較して，情報配信装置１０の情報配信能力を判別する。
通信仕様決定手段１０５は，前記情報配信能力判別手段１０３による判別結果に応じて，通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１，若しくは，通信仕様案変更手段１０４によって前記満足度に応じて作成された通信仕様案Ｐ２のいずれかに基づいて，情報配信時の通信仕様を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ネットワークを介して複数のクライアントに対して情報配信を実行する情報配信装置及びその方法に関し，特に，前記複数のクライアント間でできるだけ公平な情報配信を行うための情報配信装置及びその方法に関する。
【背景技術】
【０００２】
近年，情報配信装置からインターネット等のネットワークを介して複数のクライアントに対して，画像データ，音楽データ等，各種情報の配信を行う，コンテンツ配信等と呼ばれる情報配信サービスが盛んになっている。
従来の情報配信サービスでは，例えば，インターネット回線を通じて，クライアントからの情報配信に関する要求を受けたＷｅｂサーバ（情報配信装置の一例）が，この要求に応じた情報を配信するが，この場合に，クライアントの要求をＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ／先入れ先出し）で処理し，先に要求を送信してきたクライアント端末に対して先に情報を配信する技術が一般的であった。
また，クライアントを階級分けし，情報配信を要求してきたクライアントの階級に応じて情報を配信する順番，速度等を決定するサービスも知られている。
さらに，クライアントからのリクエストを募集して，コンテンツの人気度を算出し，このコンテンツの人気度に応じてコンテンツ配信を実行すると共に，クライアントからのリクエストに応じて課金を行うサービスも知られている（例えば，特許文献１参照）。
【特許文献１】特開２０００−１５６８５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで，このような情報配信サービスでは，クライアントが情報配信を受ける際にクライアント間で受けるサービスの質に差異が生じることがしばしばである。ここでのサービスの質とは，クライアント側の観点で，要求通りの情報をいかに短い時間で入手できるかによって主に決まり，同じ時間であればより大量のデータが配信された方が質の高いサービスで，同じ量のデータであればより短時間で配信された方が質の高いサービスということになる。
前記ＦＩＦＯによる処理を行う従来技術では，クライアントがリクエストを出したタイミングに前記Ｗｅｂサーバへのアクセスが多い状態であれば情報配信が遅くなり，逆に前記Ｗｅｂサーバへのアクセスが少ない状態であれば情報配信が早くなる，というように，クライアント間で受けるサービスの質に不平等が生じる。
また，前記クライアントを階級分けする従来技術では，同階級においては，やはりＦＩＦＯによる処理が行われ，同階級のクライアント間で受けるサービスの質には，同様の不平等が生じる。
さらに，前記特許文献１に記載のコンテンツの人気度に応じてコンテンツを配信する従来技術では，人気のないコンテンツを選択したクライアントは，要求するコンテンツをなかなか得ることができないというおそれがあり，人気のあるコンテンツを選択したクライアントとの間で受けるサービスの質に不平等が生じる。
本発明は，前記事情に鑑みてなされたものであり，その目的とするところは，ネットワークを介して複数のクライアントに対して情報配信を実行する情報配信装置及びその方法において，前記複数のクライアント間で受けるサービスの質になるべく不平等が生じないよう情報配信する情報配信装置及びその方法を提供することにある。
【課題を解決するための手段】
【０００４】
前記課題を解決するために，本発明は，ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定するに際して，各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とを用いることを要旨とする情報配信装置として構成されている。
このような構成によれば，クライアントごとの満足度と各クライアントに通信する時の情報配信能力とに応じて情報配信時の通信仕様が決定され，このように決定された通信仕様に基づいて，クライアントへの情報配信がなされるため，満足度の低いクライアントには良好な通信仕様で情報配信されることになり，クライアント間で受けるサービスの質に差異が小さくなる。
【０００５】
前記クライアント各々から要求を受けた際に，要求通りに情報配信を行うことを目的とする通信仕様案を一度作成しておき，複数のクライアントの要求通りに配信できないのであれば，通信仕様案を変更し，変更後の通信仕様案に基づいて通信仕様を決定する構成としても良い。
通信仕様案を情報配信装置の配信能力に応じて適宜変更することによって，情報配信装置の配信能力の範囲内で，なるべく複数のクライアントからの要求に近い情報配信を実現することができる。
【０００６】
前記通信仕様案の変更に当たっては，満足度の高いクライアントを特定し，この特定されたクライアントに対応する通信仕様を低下させる構成とすることが考えられる。これによって，前記複数のクライアント間での満足度の均等化を図ることができる。
【０００７】
クライアントからの要求を受け付ける際に発信する許可信号を発信している間を１サイクルとし，この１サイクル間に受信した要求を，ＦＩＦＯではなく，前記のように満足度と自己の情報配信能力とに応じて処理する構成とすることもできる。
また，許可信号を発信する時間帯を決定するタイマを設けることにより，クライアントにとって使用しやすいシステムとすることができる。
【０００８】
前記クライアントからの要求から配信を要求する情報のデータ量を検知する構成とすることもできる。また，前記クライアントからの要求が，配信を要求する情報の希望配信完了時間に関する情報を含むもの，あるいは前記クライアント各々の端末仕様に関する情報を含むものであっても良い。
【０００９】
あるいは，本発明は，前記情報配信装置により行われる情報配信方法として捉えたものであっても良い。
【発明を実施するための最良の形態】
【００１０】
以下，添付図面を参照して，本発明の実施の形態及び実施例につき説明し，本発明の理解に供する。尚，以下の実施の形態及び実施例は本発明を具体化した一例であって，本発明の技術的範囲を限定する性格のものではない。
ここに，図１は，本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の機能を示す機能ブロック図，図２は，前記情報配信サーバ１０の制御部の通信仕様案作成手段１０１によって実行される要求リソースの割り当ての手順の一例を示すフローチャート，図３は，前記通信仕様案作成手段１０１によって実行されるデータ形式に関する案の作成手順の一例を示すフローチャート，図４は，前記情報配信サーバ１０の制御部によって実行される情報配信処理手順の一例を示すフローチャート，図５は，前記情報配信サーバ１０からの情報配信１回ごとのクライアントの満足度ＣＳを表すグラフ，図６は，前記情報配信サーバ１０の制御部の通信仕様案変更手段１０４によって実行される通信仕様案の変更手順の一例を示すフローチャート，図７は，前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の標準偏差値の推移を，従来技術の場合と比較したグラフ，図８は，前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，従来技術の場合と比較したグラフである。
【００１１】
はじめに，図１のブロック図に基づいて，本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の機能について説明する。
図１に示されるように，前記情報配信サーバ１０は複数のクライアント端末２１ないし２５と，インターネット回線のようなネットワークＮを介して接続され，情報配信システムＳの一部を構成している。
上記情報配信サーバ１０は，ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を，各クライアントからの要求履歴（後述）と，各クライアントへの情報配信履歴（後述）とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とに基づいて決定する。
そのため情報配信サーバ１０は，上記要求履歴を算出するための各クライアント端末２１ないし２５からの情報配信に関する要求信号を受信する要求受信部１１０と，各クライアントへの情報配信履歴と上記要求履歴とから各クライアントの満足度を算定する満足度算出手段１０７と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力を判別する情報配信能力判別手段１０３と，上記満足度算出手段１０７により算出される満足度と，上記情報配信能力判別手段１０３により判断される情報配信能力とから情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定する通信仕様決定手段１０５と，クライアントに配信するためのデータを保管する配信用データ保管部１５０と，クライアント端末２１ないし２５への情報配信を実行する配信部１６０とを備え，これら各要素が相互に接続されて構成されている。
また，情報配信サーバ１０は，これら以外に，各クライアントに関する情報を，それぞれのクライアントに対応する記憶領域に保管するクライアント情報保管部１２０と，前記要求受信部１１０で受信された要求信号に基づいて通信仕様の案を作成する通信仕様案作成手段１０１，データＩＤ参照手段１０２，通信仕様案変更手段１０４，配信用データ加工手段１０６，タイマ１３０，メモリ１４０などを有しているが，これらの詳細については後記する。尚，これら通信仕様案作成手段１０１，データＩＤ参照手段１０２，情報配信能力判別手段１０３，通信仕様案変更手段１０４，通信仕様決定手段１０５，配信用データ加工手段１０６，満足度算出手段１０７などの各手段は，図示しないプログラムメモリに格納された制御プログラムに基づいて，ＣＰＵ等からなる情報配信サーバ１０の制御部により実行される機能を果たすための手段であり，それぞれの作用については，以下に順次説明する。
また，これら各手段は，それぞれ独立した回路によって構成されていても良く，このような場合であっても本発明の範囲内である。
また，以下の説明に登場する，通信仕様とは，各クライアントに対する情報配信時のサーバ・クライアント間における通信の仕様であって，いずれのクライアントにいずれのデータを送信するか，各クライアントにどれだけのリソースを割り当てるか，配信するデータの形式をいずれの形式にするか等によって決まる仕様である。
また，リソースとは，通信帯域，通信回線数等，情報配信サーバ１０が情報配信を行なう際に各クライアントに対して割り当てる通信用の資源のことであり，割り当てられるリソースが大きければ大きいほど，同じ時間で配信することができるデータ量は大きくなり，同じ量のデータを配信するのに要する時間が短くなる。
各クライアントが要求する条件通りに情報配信を行う際に，各クライアントに割り当てることが必要となるリソースを，以下では「要求リソース」と称する。また，情報配信サーバ１０が１回の情報配信を行なう際に割り当てることができるリソースには上限があり，この上限を，以下では「サービスリソース」と称する。さらに，情報配信サーバ１０から各クライアントへの情報配信時に，配信部１６０が各クライアントに割り当てるリソースのことを，以下では「配信リソース」と称する。
【００１２】
前記通信仕様は，上述のように，各クライアントの満足度と情報配信サーバ１０の情報配信能力とに応じて決定されるものであるが，具体的には通信仕様案作成手段１０１によって通信仕様の案が先に作成され，この案を前記満足度等に応じて変更することによって情報配信時の通信仕様が決定される。通信仕様の案は，いずれのクライアントにいずれのデータを送信するかという案，各クライアントにどれだけのリソースを割り当てるかという案，配信するデータの形式をいずれの形式にするかという案等を含むものであり，前記通信仕様案作成手段１０１が，クライアントからの要求信号に含まれる情報に応じて作成する。要求受信部１１０が受信する前記クライアントからの要求信号には，少なくとも送信元クライアントのＩＤ，要求するデータのＩＤが含まれており，また，他にも，例えば，希望配信完了時間，クライアント端末仕様に関する情報等が含まれていても良い。通信仕様の案を作成する手法は，例えば以下のようなものである。
上記いずれのクライアントにいずれのデータを送信するかという案については，要求信号に含まれる前記クライアントＩＤと，要求データＩＤとに基づいて作成する。
また，上記各クライアントにどれだけのリソースを割り当てるかという案については，配信する情報のデータ容量と目標とする配信完了時間とに基づいて作成する。通信仕様案作成手段１０１は前記案の作成に当たり，各クライアントに対して前記要求リソースが割り当てるが，この要求リソースの割り当ての手順の一例を，図２のフローチャートを用いて説明する。図２中のＳ１０１，Ｓ１０２等の番号は，手順（ステップ）の番号を示す。
はじめに，クライアントからの要求信号に含まれる要求データＩＤに基づいて，要求データＩＤ参照手段１０２が配信用データ保管部１５０にアクセスすることで，クライアントが配信を要望するデータの容量を検知する（ステップＳ１０１／データ容量検知手段の処理の一例）。
次に，クライアントからの要求信号に希望配信完了時間に関する情報が含まれているか否かを検出し，含まれている場合（ステップＳ１０２においてＹＥＳ），この希望配信完了時間を目標とする配信完了時間として設定する（ステップＳ１０３）。一方，クライアントからの要求信号に希望配信完了時間に関する情報が含まれていない場合（ステップＳ１０２においてＮＯ），通常配信完了時間を算出し（ステップＳ１０４），この通常配信完了時間を目標とする配信完了時間に設定する（ステップＳ１０５）。
ここで，通常配信完了時間とは，各クライアントに対する過去の情報配信時に，所定単位当たりのデータ量の配信完了に要した時間の平均値を求め，この平均値に要求データＩＤに対応するデータの容量を乗じることによって算出される時間である。例えば，クライアント端末２１に対して過去に情報を配信した際に，１Ｍビット当たりの配信完了に平均１．０秒要したとすれば，要求データＩＤに対応するデータの容量が１０Ｍビットである場合，クライアント端末２１への通常配信完了時間は１０．０秒ということになる。尚，クライアントが初めて情報配信を受ける場合のように，過去の情報配信の実績が蓄積されていない場合には，例えば，他のクライアントの通常配信完了時間を流用しても良い。この場合，通信回線の仕様（光ファイバ回線か，ＡＤＳＬ回線か，ＩＳＤＮ回線か等），通信端末の仕様（ＣＰＵの仕様，メモリ容量等）等が，最も似ているクライアントの通常配信完了時間を流用することが望ましい。
通信仕様案作成手段１０１は，前記ステップＳ１０１において検出された容量を有するデータを，前記ステップＳ１０３若しくはＳ１０５において設定された前記目標とする配信完了時間内に送信するために必要となるリソース（要求リソース）を，それぞれのクライアントに対して割り当てる（ステップＳ１０６）。
配信するデータの形式をいずれの形式にするかという案については，要求信号に含まれる前記要求データＩＤ，クライアントＩＤと，クライアント端末仕様に関する情報に基づいて作成される。
この要求データ形式に関する案作成の手順の一例を，図３のフローチャートを用いて説明する。はじめに，データＩＤ参照手段１０２が，クライアントからの要求信号に含まれる前記要求データＩＤに基づいて，配信用データ保管部１５０にアクセスし，クライアントが配信を要望するデータが配信用データ保管部１５０にどのようなデータ形式で保管されているかを検出する（ステップＳ２０１）。ここで，前記クライアントからの要求信号に端末仕様に関する情報が含まれている場合（ステップＳ２０２においてＹＥＳ），検出されたデータ形式がクライアントの端末で再生可能か否かについて判断がなされる（ステップＳ２０３）。この判断は，例えば，クライアント端末にインストールされているソフトウェアによって，ステップＳ２０１において検出されたデータ形式のデータを再生できるかどうか等に基づいてなされる。再生可能と判断される場合（ステップＳ２０３においてＹＥＳ），配信用データ保管部１５０に保管されているデータの形式をそのまま形式案として採用する（ステップＳ２０４）。一方，再生不可能と判断される場合（ステップＳ２０３においてＮＯ）であって，データ形式をクライアント端末において再生可能となるよう変更できる場合（ステップＳ２０５においてＹＥＳ）には，再生可能となるよう変更したデータ形式を形式案として採用する（ステップＳ２０６）。データ形式をクライアント端末にて再生可能となるよう変更できない場合（ステップＳ２０５においてＮＯ），通信仕様案作成手段１０１は，配信部１６０を通じて要求元クライアントにその旨を伝える（ステップＳ２０７）と共に，当該クライアントからの要求信号を破棄する（ステップＳ２０８）。
前記ステップＳ２０５における変更可能かどうかについての判断は，例えば，データ形式を変更できるか否かを納めたデータテーブルを参照することで行い得る。
クライアントからの要求信号に端末仕様に関する情報が含まれていない場合（ステップＳ２０２においてＮＯ），クライアント情報保管部１２０に当該クライアントの端末仕様に関する情報が保管されているかを確認し，保管されている場合（ステップＳ２０９においてＹＥＳ），このクライアント情報保管部１２０に保管されている端末仕様の情報に基づいて，前記ステップＳ２０３以下の処理がなされる。一方，クライアント情報保管部１２０に保管されていない場合（ステップＳ２０９においてＮＯ），配信用データ保管部１５０に保管されているデータの形式をそのまま形式案として採用する（ステップＳ２０４）。
以上のようにして，通信仕様案作成手段１０１は，要求信号を送信してきた各クライアントに対応する通信仕様案をそれぞれ作成するが，通信仕様案作成手段１０１によって作成される通信仕様案のことを，以下では通信仕様案Ｐ１と称する。
【００１３】
次に，図１のブロック図を参照しつつ，図４のフローチャートを用いて，前記情報配信サーバ１０の制御部によって実行される，情報配信処理の手順の一例を説明する。
この実施形態は，ネットワークを介して接続された複数のクライアントからの要求に応じて，情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定するに際して，前記従来技術のようにＦＩＦＯで処理を行うのではなく，各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とを用いる情報配信装置として構成されている。
従って，この実施形態に係る情報配信装置においては，あるクライアントから情報配信の要求があった場合に，当該クライアントに対する通信仕様を即座に決定して情報配信を行う前記ＦＩＦＯによる処理とは異なり，例えば，所定の時間ｔを１サイクルとして，同じサイクル内に送信されてきた複数のクライアントからの要求信号を受信した時点で，後述するように情報配信サーバ１０の情報配信能力と満足度とに応じて通信仕様（例えばクライアントに割り当てるリソース）を決定し，この通信仕様に基づいて情報配信を実行するという手順で処理を行う。このように所定の時間ｔを１サイクルとする役割を担うのがタイマ１３０であり，ステップＳ３０１においては，まずタイマ１３０による計測が開始される。
次に，相手クライアント端末２１ないし２５からの配信要求があるか否かを判断することになる。すなわちステップＳ３０２において，要求受信部１１０がクライアント端末２１ないし２５からの要求信号を受信すると，受信された要求信号は制御部の通信仕様案作成手段１０１に送信される。
通信仕様案作成手段１０１は，複数のクライアント端末２１ないし２５からの要求をすべて満たすことを目標とする各クライアントに対応する通信仕様の案である前記通信仕様案Ｐ１を作成する（ステップＳ３０３）。通信仕様案作成手段１０１が通信仕様案Ｐ１を作成する手順については，上に示した通りである（図２，図３参照）。
【００１４】
通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１は，クライアント情報保管部１２０のカウンタ１２１に送られる。カウンタ１２１は，前記通信仕様案Ｐ１が送られてくる度に，いずれのクライアントに対応する通信仕様案Ｐ１であるかを識別し，クライアントごとに通信仕様案Ｐ１が送られてきた回数（即ち，各クライアントからの要求回数）をカウントする（ステップＳ３０４）。続いて，クライアント情報保管部１２０に，前記通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１を，前記カウンタ１２１によってカウントされた前記要求回数と共に保管する（ステップＳ３０５）。このように要求回数とともに保管された通信仕様案Ｐ１は，各クライアントからの要求の履歴であり，前記要求履歴データの一例である。
一方，前記通信仕様案Ｐ１は，メモリ１４０にも送られ，ここに一旦格納される（ステップＳ３０６）。
情報配信サーバ１０の制御部は，所定の時間ｔが経過するまで（ステップＳ３０７においてＮＯ）は，前記ステップＳ３０２ないしＳ３０６の処理を繰り返し，複数のクライアントからの要求を受け付け，それぞれに対応する通信仕様案を作成し，それぞれの前記要求履歴データをクライアント情報保管部１２０に保管する。
時間ｔが経過すると（ステップＳ３０７においてＹＥＳ），メモリ１４０に格納された前記複数のクライアントに対応する複数の通信仕様案は情報配信能力判別手段１０３に送られる。
情報配信能力判別手段１０３は，前記通信仕様案Ｐ１において各クライアントに割り当てられた要求リソースを合計し（ステップＳ３０８），この合計値と前記サービスリソースとを比較することによって，情報配信可能か否かに関する情報配信サーバ１０自身の情報配信能力を判別する。
サービスリソース≧要求リソースの合計
の関係が成り立つとき，情報配信能力判別手段１０３は，「配信可能」と判別する。一方，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，情報配信能力判別手段１０３は，「配信不能」と判別する。
【００１５】
サービスリソース≧要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信可能」と判別する場合（ステップＳ３０９においてＹＥＳ），前記通信仕様案Ｐ１は，そのまま通信仕様決定手段１０５に送られ，通信仕様決定手段１０５は，送られてきた通信仕様案Ｐ１に基づいて情報配信時の通信仕様Ｐを決定する（ステップＳ３１０）。
一方，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信不能」と判別する場合（ステップＳ３０９においてＮＯ），前記通信仕様案Ｐ１は，通信仕様案変更手段１０４に送られる。通信仕様案変更手段１０４は，クライアントごとの満足度に応じて前記通信仕様案Ｐ１に変更を施すことにより新たな通信仕様案Ｐ２を作成するが，この通信仕様案変更手段１０４による処理の手順については後述する。
通信仕様案変更手段によって作成された新たな通信仕様案Ｐ２は，通信仕様決定手段１０５に送られ，通信仕様決定手段１０５は，送られてきた通信仕様案Ｐ２に基づいて情報配信時の通信仕様Ｐを決定する（ステップＳ３１０）。
【００１６】
前記通信仕様決定手段によって決定された通信仕様Ｐは，配信用データ加工手段１０６及び配信部１６０に送られる。配信用データ加工手段１０６は，前記通信仕様Ｐを受けると，前記通信仕様Ｐに基づいて，クライアントに配信すべきデータを配信用データ保管部１５０から読み出すと共に，配信用データに加工を施す必要がある場合（ステップＳ３１１においてＹＥＳ）は，配信用データに加工を施す（ステップＳ３１２）。ここで，加工とは，配信用データ保管部１５０に保管された配信用データの形式変更，間引き，後部削除等をいう。
配信用データの形式変更とは，クライアントからの要求信号に含まれるクライアント端末仕様に関する情報に基づいて，配信先のクライアント端末において再生可能となるようデータの形式を変更することをいい，前記図３に示される手順によって作成された形式案に従ってなされる。
また，データの間引きとは，例えば，画像データの解像度を落とす等によってデータの容量を小さくすることをいい，データの後部削除とは，例えば，電子メールメッセージを古いほうから順に所定数削除したり，文書データを文書の後部を途中から所定量削除したりすることをいう。
配信するデータを間引いたり，後部削除することが許されるか否かの情報は，クライアントからの要求信号に含ませておく。例えば，クライアントが無線通信のホットスポットを通過している際に情報配信を受けるような場合であって，前記希望配信完了時間の厳守が求められるような場合，当該クライアントが，後述する通信仕様案変更手段１０４によって譲歩クライアントに特定され，割り当てられるリソースが前記要求リソースより低下した場合であっても，配信データの間引きや後部削除がなされることで，前記希望配信完了時間内に情報配信を行うことが可能となる。
一方，配信用データに加工を施す必要がない場合（ステップＳ３１０においてＮＯ），配信用データ加工手段１０６は，配信用データに加工を施さない。
必要に応じて加工が施された前記配信用データは，配信部１６０に送られ，配信部１６０は，前記通信仕様決定手段１０５から送られてきた通信仕様Ｐに基づいて，各クライアントにリソース（配信リソース）を割り当てて情報配信を実行する（ステップＳ３１３）。
また，配信部１６０によってクライアントごとに割り当てられた前記配信リソースに関する情報は，クライアント情報保管部１２０のカウンタ１２２に送られる。カウンタ１２２は，前記配信リソースに関する情報が送られてくる度に，いずれのクライアントに対応する配信リソースに関する情報であるかを識別し，クライアントごとに配信リソースに関する情報が送られてきた回数（即ち，各クライアントに対する情報配信回数）をカウントする（ステップＳ３１４）。クライアント情報保管部１２０は，前記配信リソースに関する情報を前記カウンタ１２２によってカウントされた前記情報配信回数とともに保管する（ステップＳ３１５）。このように情報配信回数と共に保管された配信リソースに関する情報は，各クライアントに対する情報配信の履歴であり，前記情報配信履歴データの一例である。
【００１７】
クライアント情報保管部１２０に保管された前記要求履歴データと前記情報配信履歴データは，満足度算出手段１０７によって読み出され，満足度算出手段１０７は，これらデータに基づいて満足度を算出する（ステップＳ３１６）。
ここで，あるクライアントからのｍ回目の要求時の要求リソースをＲＲ（ｍ），当該クライアントへのｍ回目の情報配信時の配信リソースをＴＲ（ｍ）とする。前記説明から明らかなように，ＲＲ（ｍ）は前記要求履歴データに，ＴＲ（ｍ）は前記配信履歴データに，それぞれ含まれるデータである。
満足度算出手段１０７で算出される満足度としては，情報配信サーバ１０からの情報配信１回ごとの満足度ＣＳと，クライアントごとの満足度ＣＳを過去の実績から累計した累積満足度ＡＣＳとが定義される。
ｍ回目の情報配信を受けた際の，情報配信１回ごとの満足度ＣＳ（ｍ）は，例えば，次式のような評価関数によって算出される。
ＣＳ（ｍ）＝１／（１＋α×ｅｘｐ（−λｘ））…（１）
但し，ｘ＝ＴＲ（ｍ）／ＲＲ（ｍ）
（１）式においては，クライアントの特性に応じてパラメータ値α，λを変更することによって，図３のｂ点の位置をシフトさせたり，グラフの傾きを変えたりすることができる。具体的には，例えば，完全なコンテンツが欲しい場合には，ｂ→１に，また，コンテンツの一部でもよいから早急に欲しいような場合はｂ→０のようにｂ点をシフトさせることが出来る。
図５は，前記（１）式をグラフ化したものである。図５に示されるように，ｘが１に近づく，即ち，要求リソースと配信リソースとの差異が小さくなるにつれて，満足度ＣＳが高くなり，要求リソースと配信リソースが等しい（ｘ＝１）場合，即ちクライアントからの要求通りに情報配信できるよう，配信リソースが割り当てられた場合に，満足度ＣＳは最大値１となる。逆にｘが小さくなるにつれて満足度も低下するが，ｘが所定の点ｂを下回ると急激に満足度が低下することが理解できる。
尚，このような点ｂ，及びｘの低下に伴う満足度の低下傾向（即ち，グラフの傾き）は，クライアントごとに傾向が異なるものであるため，各クライアントに対して顧客満足度調査を実施して調査結果をフィードバックする等により，クライアントごとに適切なパラメータ値α，λを設定することが望ましい。
一方，クライアントがｎ回情報配信を受けた場合の累積満足度ＡＣＳ（ｎ）は，例えば，次式のような評価関数によって算出される。
ＡＣＳ（ｎ）＝β×ＣＳ（ｎ）＋（１−β）×ＡＣＳ（ｎ−１）…（２）
ここで，βは０＜β＜１で定められるパラメータ値であり，βが大きいほど，新しい満足度ＣＳが累積満足度ＡＣＳに強く反映される。一般には，新しい満足度ＣＳの方がクライアントの満足度意識に影響を及ぼすと考えられるため，β≧０．５に定めることが適しているといえるが，やはり，クライアントごとに傾向が異なるものであるため，各クライアントに対して顧客満足度調査を実施して調査結果をフィードバックする等により，クライアントごとに適切なパラメータ値βを設定することが望ましい。
満足度算出手段１０７によって算出された前記１回ごとの満足度ＣＳ並びに累積満足度ＡＣＳはクライアント情報保管部１２０に送られ，クライアントごとに保管される（ステップＳ３１７）。
【００１８】
続いて，図６のフローチャートを用いて，前記通信仕様案変更手段１０４による通信仕様案の変更の手順の一例を説明する。尚，図６に示される処理手順は，前記図４のステップＳ３０９において，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信不能」と判別した場合の処理の手順の一例である。
通信仕様案変更手段１０４は，情報配信能力判別手段１０３から送られてきた通信仕様案Ｐ１に含まれるクライアントＩＤに基づいて，情報配信を要求したすべてのクライアント満足度データを，クライアント情報保管部１２０から読み出す（ステップＳ４０１）。ここで，読み出される満足度データは，あるクライアントへの今回の情報配信がｎ回目の配信であるとすると，当該クライアントに対する前回情報配信完了時後の累積満足度ＡＣＳ（ｎ−１）である。尚，情報配信を要求したクライアント中に，初めて情報配信を受けるクライアントが含まれている場合のように，上記すべてのクライアントの満足度データがクライアント情報保管部に保管されていない場合（ステップＳ４０２においてＮＯ），満足度データを有していないクライアントには仮満足度を付与する（ステップＳ４０３）。仮満足度は，例えば，情報配信を過去に受けたことがある全てのクライアントの累積満足度の平均値，現サイクルにおいて情報配信を要求した全てのクライアントの累積満足度の平均値，或いは，前記（１）式においてｘ＝ｂとなる場合の満足度ｃ等に定めても良い。
次に，前記ステップＳ４０１において読み出された満足度，或いは前記ステップＳ４０３において与えられた仮満足度が最も高いクライアントを譲歩クライアントとして特定する（ステップＳ４０４／クライアント特定手段の処理の一例）と共に，譲歩クライアントに割り当てるリソースを，前記要求リソースより低下させる（ステップＳ４０５）。このとき，前記譲歩クライアントとして特定されたクライアントの満足度が急減に低下することを防止するため，前記（１）式においてｘ＝ｂとなるようにリソースを低下させることが望ましい。
このように譲歩クライアントとして特定されたクライアントに割り当てるリソースを低下させることによって，リソースの再割当を行うと，再割当後のリソースを合計して（ステップＳ４０６），合計値を算出する。
ステップＳ４０６によって算出された合計値は，前記サービスリソースと比較され，
サービスリソース≧再割当後のリソースの合計
の関係が成り立つまで（ステップＳ４０７においてＮＯ），ステップＳ４０４ないしステップＳ４０６の処理を繰り返す。
前記関係が成り立つと（ステップＳ４０７においてＹＥＳ），通信仕様案変更手段１０４は，各クライアントに割り当てるリソースを再割当後のリソースに変更することによって，新たな通信仕様案Ｐ２を作成し（ステップＳ４０８），これを通信仕様決定手段１０５に送る。
これ以降の処理は，上述した図４のステップＳ３１０以下の処理と同様である。
尚，ステップＳ４０４における譲歩クライアントの特定の際に，累積満足度の同じクライアントが複数存在する場合には，譲歩クライアント特定手段１０５は，要求の順番に応じて譲歩クライアントとして特定しても良い。例えば，同じ満足度を有するクライアントのうち，一番遅い順番で要求信号を送信してきたクライアントから順に譲歩クライアントとして特定する。
すべてのクライアントが譲歩クライアントとして特定され，リソースがｘ＝ｂとなるように低下された後に，前記ステップＳ４０７においてＹＥＳの関係とならない場合，通信仕様案変更手段１０４は，例えば，
ａ＝（低下後のリソースの合計 − サービスリソース）／ クライアント数
で求めた値ａを，各クライアントに割り当てられたリソースから均等に差し引く，或いは，それぞれのクライアントの要求データ容量の大きさの全体の要求データ容量の大きさに対する比率ｒを，ａに乗じて得られる値ｒ×ａを各クライアントに割り当てられたリソースから差し引く等の手法も考えられる。
【００１９】
以上のような構成によれば，情報配信サーバ１０から全てのクライアントの要求に応えて情報配信ができない場合，累積満足度の高いクライアントから順に，割り当てるリソースを低下させることによって対応するため，クライアント間の累積満足度の均等化，即ち，クライアント間で受けるサービスの質の均等化を図ることができる。
また，この場合におけるリソースの低下は，前記（１）式においてｘ＝ｂとなるようになされるため，各顧客の累積満足度はｃ以上に保たれ，全クライアントの平均満足度も向上する。
図７は，本発明の実施形態に係る情報配信サーバ１０からの配信を受けたクライアントの累積満足度の標準偏差値の推移を，前記ＦＩＦＯによる処理を行う従来技術の場合と比較したものであり，線（１）が前者，線（２）が後者を示す。サービス回数が増えるにつれていずれも標準偏差は低くなるが，サービス回数が１００回を超える付近で，線（２）は０．０１付近，線（１）は０．００５付近に収束することが分かる。このように，本実施形態に係る情報配信サーバ１０からの情報配信を受けた顧客の累積満足度のばらつきはサービス回数が増えるにつれて低くなり，公平なサービスの提供が実現されていることが理解できる。
図８は，本発明の実施形態に係る情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，前記ＦＩＦＯによる処理を行う従来技術の場合と比較したものであり，線（３）が前者，線（４）が後者を示す。前者では，サービス回数が増えるにつれて平均累積満足度が向上し，サービス回数が約１００回を超えてからは，０．８以上の高い水準で安定する。一方，後者では０．２から０．４程度の低い水準で推移することが理解できる。
これは，本発明の実施形態に係る情報配信サーバ１０による情報配信サービスを受けたクライアントが，譲歩クライアントとして特定されたクライアントであってもｘ＝ｂとなるようにリソースの再割当がなされるからである。即ち，図３に示されるよう，たとえ譲歩クライアントであってもサービス１回ごとの満足度ＡＣはｃであり，一方，譲歩クライアント以外のクライアントのサービス１回ごとの満足度ＡＣは１であり，繰り返しサービスを受ける結果，各クライアントの累積満足度がｃ以上１以下の高い水準に保たれるためである。
【実施例】
【００２０】
前記実施の形態では，クライアントの満足度ＣＳ及び累積満足度ＡＣＳが情報配信サーバ１０の制御部（満足度算出手段１０７）によって算出され，情報配信サーバ１０のクライアント情報保管部１２０に保管されているが，これらは，各端末において算出及び／若しくは保管されても良い。このような構成によれば，情報配信サーバ１０側の負担を減らすことができる。
クライアント端末に満足度ＣＳ及び累積満足度ＡＣＳが保管される実施例においては，各クライアントが要求信号を送信する際に，満足度ＣＳ，累積満足度ＡＣＳに関する情報を含ませる等によって，情報配信サーバ１０に対して自己の満足度ＣＳ，累積満足度ＡＣＳを知らせる。
【００２１】
前記複数のクライアントからの要求を受け付ける際に，前記複数のクライアントに対して前記要求を許可する許可信号を発信する許可信号発信手段を更に備えた構成とすることも考えられる。
前記実施の形態では，所定の時間ｔを１サイクルとして要求の受付を行っているが，許可信号を発信している間を１サイクルとすることができる。例えば，あるサイクルで受信した要求に対応する情報配信がすべて完了した時点で許可信号を発信し，次のサイクルにおける要求受信を開始する構成とすれば，情報配信サーバ１０が有する全てのリソースを１回の情報配信の際に割り当てることができるため，前記サービスリソースの向上を図ることができる。
或いは，この許可信号を発信する時間帯を制御するタイマ手段を更に具備する構成としておいても良い。タイマ手段によって定期的に前記許可信号を発信する構成としておけば，所定の決まった時間に情報配信に関する要求の受信がなされるため，クライアントにとって使用しやすいシステムになる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の概略構成を示すブロック図。
【図２】前記情報配信サーバ１０の制御部の通信仕様案作成手段１０１によって実行される要求リソースの割り当ての手順の一例を示すフローチャート。
【図３】前記通信仕様案作成手段１０１によって実行されるデータ形式に関する案の作成手順の一例を示すフローチャート。
【図４】前記情報配信サーバ１０の制御部によって実行される情報配信処理手順の一例を示すフローチャート。
【図５】前記情報配信サーバ１０からの情報配信１回ごとのクライアントの満足度ＣＳを表すグラフ。
【図６】前記情報配信サーバ１０の制御部の通信仕様案変更手段１０４によって実行される通信仕様案の変更手順の一例を示すフローチャート。
【図７】前記情報配信サーバ１０からの情報配信を受けたクライアントの累積満足度の標準偏差値の推移を，従来技術の場合と比較して示すグラフ。
【図８】前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，従来技術の場合と比較して示すグラフ。
【符号の説明】
【００２３】
１０・・・情報配信サーバ（情報配信装置の一例）
２１〜２５・・・クライアント端末
１０１・・・通信仕様案作成手段
１０２・・・データＩＤ参照手段
１０３・・・情報配信能力判別手段
１０４・・・通信仕様案変更手段
１０５・・・通信仕様決定手段
１０６・・・配信用データ加工手段
１０７・・・満足度算出手段
１１０・・・要求受信部
１２０・・・クライアント情報保管部
１２１，１２２・・・カウンタ
１３０・・・タイマ
１４０・・・メモリ
１５０・・・配信用データ保管部
１６０・・・配信部
【技術分野】
【０００１】
本発明は，ネットワークを介して複数のクライアントに対して情報配信を実行する情報配信装置及びその方法に関し，特に，前記複数のクライアント間でできるだけ公平な情報配信を行うための情報配信装置及びその方法に関する。
【背景技術】
【０００２】
近年，情報配信装置からインターネット等のネットワークを介して複数のクライアントに対して，画像データ，音楽データ等，各種情報の配信を行う，コンテンツ配信等と呼ばれる情報配信サービスが盛んになっている。
従来の情報配信サービスでは，例えば，インターネット回線を通じて，クライアントからの情報配信に関する要求を受けたＷｅｂサーバ（情報配信装置の一例）が，この要求に応じた情報を配信するが，この場合に，クライアントの要求をＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ／先入れ先出し）で処理し，先に要求を送信してきたクライアント端末に対して先に情報を配信する技術が一般的であった。
また，クライアントを階級分けし，情報配信を要求してきたクライアントの階級に応じて情報を配信する順番，速度等を決定するサービスも知られている。
さらに，クライアントからのリクエストを募集して，コンテンツの人気度を算出し，このコンテンツの人気度に応じてコンテンツ配信を実行すると共に，クライアントからのリクエストに応じて課金を行うサービスも知られている（例えば，特許文献１参照）。
【特許文献１】特開２０００−１５６８５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで，このような情報配信サービスでは，クライアントが情報配信を受ける際にクライアント間で受けるサービスの質に差異が生じることがしばしばである。ここでのサービスの質とは，クライアント側の観点で，要求通りの情報をいかに短い時間で入手できるかによって主に決まり，同じ時間であればより大量のデータが配信された方が質の高いサービスで，同じ量のデータであればより短時間で配信された方が質の高いサービスということになる。
前記ＦＩＦＯによる処理を行う従来技術では，クライアントがリクエストを出したタイミングに前記Ｗｅｂサーバへのアクセスが多い状態であれば情報配信が遅くなり，逆に前記Ｗｅｂサーバへのアクセスが少ない状態であれば情報配信が早くなる，というように，クライアント間で受けるサービスの質に不平等が生じる。
また，前記クライアントを階級分けする従来技術では，同階級においては，やはりＦＩＦＯによる処理が行われ，同階級のクライアント間で受けるサービスの質には，同様の不平等が生じる。
さらに，前記特許文献１に記載のコンテンツの人気度に応じてコンテンツを配信する従来技術では，人気のないコンテンツを選択したクライアントは，要求するコンテンツをなかなか得ることができないというおそれがあり，人気のあるコンテンツを選択したクライアントとの間で受けるサービスの質に不平等が生じる。
本発明は，前記事情に鑑みてなされたものであり，その目的とするところは，ネットワークを介して複数のクライアントに対して情報配信を実行する情報配信装置及びその方法において，前記複数のクライアント間で受けるサービスの質になるべく不平等が生じないよう情報配信する情報配信装置及びその方法を提供することにある。
【課題を解決するための手段】
【０００４】
前記課題を解決するために，本発明は，ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定するに際して，各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とを用いることを要旨とする情報配信装置として構成されている。
このような構成によれば，クライアントごとの満足度と各クライアントに通信する時の情報配信能力とに応じて情報配信時の通信仕様が決定され，このように決定された通信仕様に基づいて，クライアントへの情報配信がなされるため，満足度の低いクライアントには良好な通信仕様で情報配信されることになり，クライアント間で受けるサービスの質に差異が小さくなる。
【０００５】
前記クライアント各々から要求を受けた際に，要求通りに情報配信を行うことを目的とする通信仕様案を一度作成しておき，複数のクライアントの要求通りに配信できないのであれば，通信仕様案を変更し，変更後の通信仕様案に基づいて通信仕様を決定する構成としても良い。
通信仕様案を情報配信装置の配信能力に応じて適宜変更することによって，情報配信装置の配信能力の範囲内で，なるべく複数のクライアントからの要求に近い情報配信を実現することができる。
【０００６】
前記通信仕様案の変更に当たっては，満足度の高いクライアントを特定し，この特定されたクライアントに対応する通信仕様を低下させる構成とすることが考えられる。これによって，前記複数のクライアント間での満足度の均等化を図ることができる。
【０００７】
クライアントからの要求を受け付ける際に発信する許可信号を発信している間を１サイクルとし，この１サイクル間に受信した要求を，ＦＩＦＯではなく，前記のように満足度と自己の情報配信能力とに応じて処理する構成とすることもできる。
また，許可信号を発信する時間帯を決定するタイマを設けることにより，クライアントにとって使用しやすいシステムとすることができる。
【０００８】
前記クライアントからの要求から配信を要求する情報のデータ量を検知する構成とすることもできる。また，前記クライアントからの要求が，配信を要求する情報の希望配信完了時間に関する情報を含むもの，あるいは前記クライアント各々の端末仕様に関する情報を含むものであっても良い。
【０００９】
あるいは，本発明は，前記情報配信装置により行われる情報配信方法として捉えたものであっても良い。
【発明を実施するための最良の形態】
【００１０】
以下，添付図面を参照して，本発明の実施の形態及び実施例につき説明し，本発明の理解に供する。尚，以下の実施の形態及び実施例は本発明を具体化した一例であって，本発明の技術的範囲を限定する性格のものではない。
ここに，図１は，本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の機能を示す機能ブロック図，図２は，前記情報配信サーバ１０の制御部の通信仕様案作成手段１０１によって実行される要求リソースの割り当ての手順の一例を示すフローチャート，図３は，前記通信仕様案作成手段１０１によって実行されるデータ形式に関する案の作成手順の一例を示すフローチャート，図４は，前記情報配信サーバ１０の制御部によって実行される情報配信処理手順の一例を示すフローチャート，図５は，前記情報配信サーバ１０からの情報配信１回ごとのクライアントの満足度ＣＳを表すグラフ，図６は，前記情報配信サーバ１０の制御部の通信仕様案変更手段１０４によって実行される通信仕様案の変更手順の一例を示すフローチャート，図７は，前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の標準偏差値の推移を，従来技術の場合と比較したグラフ，図８は，前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，従来技術の場合と比較したグラフである。
【００１１】
はじめに，図１のブロック図に基づいて，本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の機能について説明する。
図１に示されるように，前記情報配信サーバ１０は複数のクライアント端末２１ないし２５と，インターネット回線のようなネットワークＮを介して接続され，情報配信システムＳの一部を構成している。
上記情報配信サーバ１０は，ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を，各クライアントからの要求履歴（後述）と，各クライアントへの情報配信履歴（後述）とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とに基づいて決定する。
そのため情報配信サーバ１０は，上記要求履歴を算出するための各クライアント端末２１ないし２５からの情報配信に関する要求信号を受信する要求受信部１１０と，各クライアントへの情報配信履歴と上記要求履歴とから各クライアントの満足度を算定する満足度算出手段１０７と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力を判別する情報配信能力判別手段１０３と，上記満足度算出手段１０７により算出される満足度と，上記情報配信能力判別手段１０３により判断される情報配信能力とから情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定する通信仕様決定手段１０５と，クライアントに配信するためのデータを保管する配信用データ保管部１５０と，クライアント端末２１ないし２５への情報配信を実行する配信部１６０とを備え，これら各要素が相互に接続されて構成されている。
また，情報配信サーバ１０は，これら以外に，各クライアントに関する情報を，それぞれのクライアントに対応する記憶領域に保管するクライアント情報保管部１２０と，前記要求受信部１１０で受信された要求信号に基づいて通信仕様の案を作成する通信仕様案作成手段１０１，データＩＤ参照手段１０２，通信仕様案変更手段１０４，配信用データ加工手段１０６，タイマ１３０，メモリ１４０などを有しているが，これらの詳細については後記する。尚，これら通信仕様案作成手段１０１，データＩＤ参照手段１０２，情報配信能力判別手段１０３，通信仕様案変更手段１０４，通信仕様決定手段１０５，配信用データ加工手段１０６，満足度算出手段１０７などの各手段は，図示しないプログラムメモリに格納された制御プログラムに基づいて，ＣＰＵ等からなる情報配信サーバ１０の制御部により実行される機能を果たすための手段であり，それぞれの作用については，以下に順次説明する。
また，これら各手段は，それぞれ独立した回路によって構成されていても良く，このような場合であっても本発明の範囲内である。
また，以下の説明に登場する，通信仕様とは，各クライアントに対する情報配信時のサーバ・クライアント間における通信の仕様であって，いずれのクライアントにいずれのデータを送信するか，各クライアントにどれだけのリソースを割り当てるか，配信するデータの形式をいずれの形式にするか等によって決まる仕様である。
また，リソースとは，通信帯域，通信回線数等，情報配信サーバ１０が情報配信を行なう際に各クライアントに対して割り当てる通信用の資源のことであり，割り当てられるリソースが大きければ大きいほど，同じ時間で配信することができるデータ量は大きくなり，同じ量のデータを配信するのに要する時間が短くなる。
各クライアントが要求する条件通りに情報配信を行う際に，各クライアントに割り当てることが必要となるリソースを，以下では「要求リソース」と称する。また，情報配信サーバ１０が１回の情報配信を行なう際に割り当てることができるリソースには上限があり，この上限を，以下では「サービスリソース」と称する。さらに，情報配信サーバ１０から各クライアントへの情報配信時に，配信部１６０が各クライアントに割り当てるリソースのことを，以下では「配信リソース」と称する。
【００１２】
前記通信仕様は，上述のように，各クライアントの満足度と情報配信サーバ１０の情報配信能力とに応じて決定されるものであるが，具体的には通信仕様案作成手段１０１によって通信仕様の案が先に作成され，この案を前記満足度等に応じて変更することによって情報配信時の通信仕様が決定される。通信仕様の案は，いずれのクライアントにいずれのデータを送信するかという案，各クライアントにどれだけのリソースを割り当てるかという案，配信するデータの形式をいずれの形式にするかという案等を含むものであり，前記通信仕様案作成手段１０１が，クライアントからの要求信号に含まれる情報に応じて作成する。要求受信部１１０が受信する前記クライアントからの要求信号には，少なくとも送信元クライアントのＩＤ，要求するデータのＩＤが含まれており，また，他にも，例えば，希望配信完了時間，クライアント端末仕様に関する情報等が含まれていても良い。通信仕様の案を作成する手法は，例えば以下のようなものである。
上記いずれのクライアントにいずれのデータを送信するかという案については，要求信号に含まれる前記クライアントＩＤと，要求データＩＤとに基づいて作成する。
また，上記各クライアントにどれだけのリソースを割り当てるかという案については，配信する情報のデータ容量と目標とする配信完了時間とに基づいて作成する。通信仕様案作成手段１０１は前記案の作成に当たり，各クライアントに対して前記要求リソースが割り当てるが，この要求リソースの割り当ての手順の一例を，図２のフローチャートを用いて説明する。図２中のＳ１０１，Ｓ１０２等の番号は，手順（ステップ）の番号を示す。
はじめに，クライアントからの要求信号に含まれる要求データＩＤに基づいて，要求データＩＤ参照手段１０２が配信用データ保管部１５０にアクセスすることで，クライアントが配信を要望するデータの容量を検知する（ステップＳ１０１／データ容量検知手段の処理の一例）。
次に，クライアントからの要求信号に希望配信完了時間に関する情報が含まれているか否かを検出し，含まれている場合（ステップＳ１０２においてＹＥＳ），この希望配信完了時間を目標とする配信完了時間として設定する（ステップＳ１０３）。一方，クライアントからの要求信号に希望配信完了時間に関する情報が含まれていない場合（ステップＳ１０２においてＮＯ），通常配信完了時間を算出し（ステップＳ１０４），この通常配信完了時間を目標とする配信完了時間に設定する（ステップＳ１０５）。
ここで，通常配信完了時間とは，各クライアントに対する過去の情報配信時に，所定単位当たりのデータ量の配信完了に要した時間の平均値を求め，この平均値に要求データＩＤに対応するデータの容量を乗じることによって算出される時間である。例えば，クライアント端末２１に対して過去に情報を配信した際に，１Ｍビット当たりの配信完了に平均１．０秒要したとすれば，要求データＩＤに対応するデータの容量が１０Ｍビットである場合，クライアント端末２１への通常配信完了時間は１０．０秒ということになる。尚，クライアントが初めて情報配信を受ける場合のように，過去の情報配信の実績が蓄積されていない場合には，例えば，他のクライアントの通常配信完了時間を流用しても良い。この場合，通信回線の仕様（光ファイバ回線か，ＡＤＳＬ回線か，ＩＳＤＮ回線か等），通信端末の仕様（ＣＰＵの仕様，メモリ容量等）等が，最も似ているクライアントの通常配信完了時間を流用することが望ましい。
通信仕様案作成手段１０１は，前記ステップＳ１０１において検出された容量を有するデータを，前記ステップＳ１０３若しくはＳ１０５において設定された前記目標とする配信完了時間内に送信するために必要となるリソース（要求リソース）を，それぞれのクライアントに対して割り当てる（ステップＳ１０６）。
配信するデータの形式をいずれの形式にするかという案については，要求信号に含まれる前記要求データＩＤ，クライアントＩＤと，クライアント端末仕様に関する情報に基づいて作成される。
この要求データ形式に関する案作成の手順の一例を，図３のフローチャートを用いて説明する。はじめに，データＩＤ参照手段１０２が，クライアントからの要求信号に含まれる前記要求データＩＤに基づいて，配信用データ保管部１５０にアクセスし，クライアントが配信を要望するデータが配信用データ保管部１５０にどのようなデータ形式で保管されているかを検出する（ステップＳ２０１）。ここで，前記クライアントからの要求信号に端末仕様に関する情報が含まれている場合（ステップＳ２０２においてＹＥＳ），検出されたデータ形式がクライアントの端末で再生可能か否かについて判断がなされる（ステップＳ２０３）。この判断は，例えば，クライアント端末にインストールされているソフトウェアによって，ステップＳ２０１において検出されたデータ形式のデータを再生できるかどうか等に基づいてなされる。再生可能と判断される場合（ステップＳ２０３においてＹＥＳ），配信用データ保管部１５０に保管されているデータの形式をそのまま形式案として採用する（ステップＳ２０４）。一方，再生不可能と判断される場合（ステップＳ２０３においてＮＯ）であって，データ形式をクライアント端末において再生可能となるよう変更できる場合（ステップＳ２０５においてＹＥＳ）には，再生可能となるよう変更したデータ形式を形式案として採用する（ステップＳ２０６）。データ形式をクライアント端末にて再生可能となるよう変更できない場合（ステップＳ２０５においてＮＯ），通信仕様案作成手段１０１は，配信部１６０を通じて要求元クライアントにその旨を伝える（ステップＳ２０７）と共に，当該クライアントからの要求信号を破棄する（ステップＳ２０８）。
前記ステップＳ２０５における変更可能かどうかについての判断は，例えば，データ形式を変更できるか否かを納めたデータテーブルを参照することで行い得る。
クライアントからの要求信号に端末仕様に関する情報が含まれていない場合（ステップＳ２０２においてＮＯ），クライアント情報保管部１２０に当該クライアントの端末仕様に関する情報が保管されているかを確認し，保管されている場合（ステップＳ２０９においてＹＥＳ），このクライアント情報保管部１２０に保管されている端末仕様の情報に基づいて，前記ステップＳ２０３以下の処理がなされる。一方，クライアント情報保管部１２０に保管されていない場合（ステップＳ２０９においてＮＯ），配信用データ保管部１５０に保管されているデータの形式をそのまま形式案として採用する（ステップＳ２０４）。
以上のようにして，通信仕様案作成手段１０１は，要求信号を送信してきた各クライアントに対応する通信仕様案をそれぞれ作成するが，通信仕様案作成手段１０１によって作成される通信仕様案のことを，以下では通信仕様案Ｐ１と称する。
【００１３】
次に，図１のブロック図を参照しつつ，図４のフローチャートを用いて，前記情報配信サーバ１０の制御部によって実行される，情報配信処理の手順の一例を説明する。
この実施形態は，ネットワークを介して接続された複数のクライアントからの要求に応じて，情報を配信する場合に必要な各クライアントへの情報配信時の通信仕様を決定するに際して，前記従来技術のようにＦＩＦＯで処理を行うのではなく，各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて算出される各クライアントの満足度と，前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力とを用いる情報配信装置として構成されている。
従って，この実施形態に係る情報配信装置においては，あるクライアントから情報配信の要求があった場合に，当該クライアントに対する通信仕様を即座に決定して情報配信を行う前記ＦＩＦＯによる処理とは異なり，例えば，所定の時間ｔを１サイクルとして，同じサイクル内に送信されてきた複数のクライアントからの要求信号を受信した時点で，後述するように情報配信サーバ１０の情報配信能力と満足度とに応じて通信仕様（例えばクライアントに割り当てるリソース）を決定し，この通信仕様に基づいて情報配信を実行するという手順で処理を行う。このように所定の時間ｔを１サイクルとする役割を担うのがタイマ１３０であり，ステップＳ３０１においては，まずタイマ１３０による計測が開始される。
次に，相手クライアント端末２１ないし２５からの配信要求があるか否かを判断することになる。すなわちステップＳ３０２において，要求受信部１１０がクライアント端末２１ないし２５からの要求信号を受信すると，受信された要求信号は制御部の通信仕様案作成手段１０１に送信される。
通信仕様案作成手段１０１は，複数のクライアント端末２１ないし２５からの要求をすべて満たすことを目標とする各クライアントに対応する通信仕様の案である前記通信仕様案Ｐ１を作成する（ステップＳ３０３）。通信仕様案作成手段１０１が通信仕様案Ｐ１を作成する手順については，上に示した通りである（図２，図３参照）。
【００１４】
通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１は，クライアント情報保管部１２０のカウンタ１２１に送られる。カウンタ１２１は，前記通信仕様案Ｐ１が送られてくる度に，いずれのクライアントに対応する通信仕様案Ｐ１であるかを識別し，クライアントごとに通信仕様案Ｐ１が送られてきた回数（即ち，各クライアントからの要求回数）をカウントする（ステップＳ３０４）。続いて，クライアント情報保管部１２０に，前記通信仕様案作成手段１０１によって作成された通信仕様案Ｐ１を，前記カウンタ１２１によってカウントされた前記要求回数と共に保管する（ステップＳ３０５）。このように要求回数とともに保管された通信仕様案Ｐ１は，各クライアントからの要求の履歴であり，前記要求履歴データの一例である。
一方，前記通信仕様案Ｐ１は，メモリ１４０にも送られ，ここに一旦格納される（ステップＳ３０６）。
情報配信サーバ１０の制御部は，所定の時間ｔが経過するまで（ステップＳ３０７においてＮＯ）は，前記ステップＳ３０２ないしＳ３０６の処理を繰り返し，複数のクライアントからの要求を受け付け，それぞれに対応する通信仕様案を作成し，それぞれの前記要求履歴データをクライアント情報保管部１２０に保管する。
時間ｔが経過すると（ステップＳ３０７においてＹＥＳ），メモリ１４０に格納された前記複数のクライアントに対応する複数の通信仕様案は情報配信能力判別手段１０３に送られる。
情報配信能力判別手段１０３は，前記通信仕様案Ｐ１において各クライアントに割り当てられた要求リソースを合計し（ステップＳ３０８），この合計値と前記サービスリソースとを比較することによって，情報配信可能か否かに関する情報配信サーバ１０自身の情報配信能力を判別する。
サービスリソース≧要求リソースの合計
の関係が成り立つとき，情報配信能力判別手段１０３は，「配信可能」と判別する。一方，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，情報配信能力判別手段１０３は，「配信不能」と判別する。
【００１５】
サービスリソース≧要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信可能」と判別する場合（ステップＳ３０９においてＹＥＳ），前記通信仕様案Ｐ１は，そのまま通信仕様決定手段１０５に送られ，通信仕様決定手段１０５は，送られてきた通信仕様案Ｐ１に基づいて情報配信時の通信仕様Ｐを決定する（ステップＳ３１０）。
一方，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信不能」と判別する場合（ステップＳ３０９においてＮＯ），前記通信仕様案Ｐ１は，通信仕様案変更手段１０４に送られる。通信仕様案変更手段１０４は，クライアントごとの満足度に応じて前記通信仕様案Ｐ１に変更を施すことにより新たな通信仕様案Ｐ２を作成するが，この通信仕様案変更手段１０４による処理の手順については後述する。
通信仕様案変更手段によって作成された新たな通信仕様案Ｐ２は，通信仕様決定手段１０５に送られ，通信仕様決定手段１０５は，送られてきた通信仕様案Ｐ２に基づいて情報配信時の通信仕様Ｐを決定する（ステップＳ３１０）。
【００１６】
前記通信仕様決定手段によって決定された通信仕様Ｐは，配信用データ加工手段１０６及び配信部１６０に送られる。配信用データ加工手段１０６は，前記通信仕様Ｐを受けると，前記通信仕様Ｐに基づいて，クライアントに配信すべきデータを配信用データ保管部１５０から読み出すと共に，配信用データに加工を施す必要がある場合（ステップＳ３１１においてＹＥＳ）は，配信用データに加工を施す（ステップＳ３１２）。ここで，加工とは，配信用データ保管部１５０に保管された配信用データの形式変更，間引き，後部削除等をいう。
配信用データの形式変更とは，クライアントからの要求信号に含まれるクライアント端末仕様に関する情報に基づいて，配信先のクライアント端末において再生可能となるようデータの形式を変更することをいい，前記図３に示される手順によって作成された形式案に従ってなされる。
また，データの間引きとは，例えば，画像データの解像度を落とす等によってデータの容量を小さくすることをいい，データの後部削除とは，例えば，電子メールメッセージを古いほうから順に所定数削除したり，文書データを文書の後部を途中から所定量削除したりすることをいう。
配信するデータを間引いたり，後部削除することが許されるか否かの情報は，クライアントからの要求信号に含ませておく。例えば，クライアントが無線通信のホットスポットを通過している際に情報配信を受けるような場合であって，前記希望配信完了時間の厳守が求められるような場合，当該クライアントが，後述する通信仕様案変更手段１０４によって譲歩クライアントに特定され，割り当てられるリソースが前記要求リソースより低下した場合であっても，配信データの間引きや後部削除がなされることで，前記希望配信完了時間内に情報配信を行うことが可能となる。
一方，配信用データに加工を施す必要がない場合（ステップＳ３１０においてＮＯ），配信用データ加工手段１０６は，配信用データに加工を施さない。
必要に応じて加工が施された前記配信用データは，配信部１６０に送られ，配信部１６０は，前記通信仕様決定手段１０５から送られてきた通信仕様Ｐに基づいて，各クライアントにリソース（配信リソース）を割り当てて情報配信を実行する（ステップＳ３１３）。
また，配信部１６０によってクライアントごとに割り当てられた前記配信リソースに関する情報は，クライアント情報保管部１２０のカウンタ１２２に送られる。カウンタ１２２は，前記配信リソースに関する情報が送られてくる度に，いずれのクライアントに対応する配信リソースに関する情報であるかを識別し，クライアントごとに配信リソースに関する情報が送られてきた回数（即ち，各クライアントに対する情報配信回数）をカウントする（ステップＳ３１４）。クライアント情報保管部１２０は，前記配信リソースに関する情報を前記カウンタ１２２によってカウントされた前記情報配信回数とともに保管する（ステップＳ３１５）。このように情報配信回数と共に保管された配信リソースに関する情報は，各クライアントに対する情報配信の履歴であり，前記情報配信履歴データの一例である。
【００１７】
クライアント情報保管部１２０に保管された前記要求履歴データと前記情報配信履歴データは，満足度算出手段１０７によって読み出され，満足度算出手段１０７は，これらデータに基づいて満足度を算出する（ステップＳ３１６）。
ここで，あるクライアントからのｍ回目の要求時の要求リソースをＲＲ（ｍ），当該クライアントへのｍ回目の情報配信時の配信リソースをＴＲ（ｍ）とする。前記説明から明らかなように，ＲＲ（ｍ）は前記要求履歴データに，ＴＲ（ｍ）は前記配信履歴データに，それぞれ含まれるデータである。
満足度算出手段１０７で算出される満足度としては，情報配信サーバ１０からの情報配信１回ごとの満足度ＣＳと，クライアントごとの満足度ＣＳを過去の実績から累計した累積満足度ＡＣＳとが定義される。
ｍ回目の情報配信を受けた際の，情報配信１回ごとの満足度ＣＳ（ｍ）は，例えば，次式のような評価関数によって算出される。
ＣＳ（ｍ）＝１／（１＋α×ｅｘｐ（−λｘ））…（１）
但し，ｘ＝ＴＲ（ｍ）／ＲＲ（ｍ）
（１）式においては，クライアントの特性に応じてパラメータ値α，λを変更することによって，図３のｂ点の位置をシフトさせたり，グラフの傾きを変えたりすることができる。具体的には，例えば，完全なコンテンツが欲しい場合には，ｂ→１に，また，コンテンツの一部でもよいから早急に欲しいような場合はｂ→０のようにｂ点をシフトさせることが出来る。
図５は，前記（１）式をグラフ化したものである。図５に示されるように，ｘが１に近づく，即ち，要求リソースと配信リソースとの差異が小さくなるにつれて，満足度ＣＳが高くなり，要求リソースと配信リソースが等しい（ｘ＝１）場合，即ちクライアントからの要求通りに情報配信できるよう，配信リソースが割り当てられた場合に，満足度ＣＳは最大値１となる。逆にｘが小さくなるにつれて満足度も低下するが，ｘが所定の点ｂを下回ると急激に満足度が低下することが理解できる。
尚，このような点ｂ，及びｘの低下に伴う満足度の低下傾向（即ち，グラフの傾き）は，クライアントごとに傾向が異なるものであるため，各クライアントに対して顧客満足度調査を実施して調査結果をフィードバックする等により，クライアントごとに適切なパラメータ値α，λを設定することが望ましい。
一方，クライアントがｎ回情報配信を受けた場合の累積満足度ＡＣＳ（ｎ）は，例えば，次式のような評価関数によって算出される。
ＡＣＳ（ｎ）＝β×ＣＳ（ｎ）＋（１−β）×ＡＣＳ（ｎ−１）…（２）
ここで，βは０＜β＜１で定められるパラメータ値であり，βが大きいほど，新しい満足度ＣＳが累積満足度ＡＣＳに強く反映される。一般には，新しい満足度ＣＳの方がクライアントの満足度意識に影響を及ぼすと考えられるため，β≧０．５に定めることが適しているといえるが，やはり，クライアントごとに傾向が異なるものであるため，各クライアントに対して顧客満足度調査を実施して調査結果をフィードバックする等により，クライアントごとに適切なパラメータ値βを設定することが望ましい。
満足度算出手段１０７によって算出された前記１回ごとの満足度ＣＳ並びに累積満足度ＡＣＳはクライアント情報保管部１２０に送られ，クライアントごとに保管される（ステップＳ３１７）。
【００１８】
続いて，図６のフローチャートを用いて，前記通信仕様案変更手段１０４による通信仕様案の変更の手順の一例を説明する。尚，図６に示される処理手順は，前記図４のステップＳ３０９において，
サービスリソース＜要求リソースの合計
の関係が成り立つとき，即ち，情報配信能力判別手段１０３が「配信不能」と判別した場合の処理の手順の一例である。
通信仕様案変更手段１０４は，情報配信能力判別手段１０３から送られてきた通信仕様案Ｐ１に含まれるクライアントＩＤに基づいて，情報配信を要求したすべてのクライアント満足度データを，クライアント情報保管部１２０から読み出す（ステップＳ４０１）。ここで，読み出される満足度データは，あるクライアントへの今回の情報配信がｎ回目の配信であるとすると，当該クライアントに対する前回情報配信完了時後の累積満足度ＡＣＳ（ｎ−１）である。尚，情報配信を要求したクライアント中に，初めて情報配信を受けるクライアントが含まれている場合のように，上記すべてのクライアントの満足度データがクライアント情報保管部に保管されていない場合（ステップＳ４０２においてＮＯ），満足度データを有していないクライアントには仮満足度を付与する（ステップＳ４０３）。仮満足度は，例えば，情報配信を過去に受けたことがある全てのクライアントの累積満足度の平均値，現サイクルにおいて情報配信を要求した全てのクライアントの累積満足度の平均値，或いは，前記（１）式においてｘ＝ｂとなる場合の満足度ｃ等に定めても良い。
次に，前記ステップＳ４０１において読み出された満足度，或いは前記ステップＳ４０３において与えられた仮満足度が最も高いクライアントを譲歩クライアントとして特定する（ステップＳ４０４／クライアント特定手段の処理の一例）と共に，譲歩クライアントに割り当てるリソースを，前記要求リソースより低下させる（ステップＳ４０５）。このとき，前記譲歩クライアントとして特定されたクライアントの満足度が急減に低下することを防止するため，前記（１）式においてｘ＝ｂとなるようにリソースを低下させることが望ましい。
このように譲歩クライアントとして特定されたクライアントに割り当てるリソースを低下させることによって，リソースの再割当を行うと，再割当後のリソースを合計して（ステップＳ４０６），合計値を算出する。
ステップＳ４０６によって算出された合計値は，前記サービスリソースと比較され，
サービスリソース≧再割当後のリソースの合計
の関係が成り立つまで（ステップＳ４０７においてＮＯ），ステップＳ４０４ないしステップＳ４０６の処理を繰り返す。
前記関係が成り立つと（ステップＳ４０７においてＹＥＳ），通信仕様案変更手段１０４は，各クライアントに割り当てるリソースを再割当後のリソースに変更することによって，新たな通信仕様案Ｐ２を作成し（ステップＳ４０８），これを通信仕様決定手段１０５に送る。
これ以降の処理は，上述した図４のステップＳ３１０以下の処理と同様である。
尚，ステップＳ４０４における譲歩クライアントの特定の際に，累積満足度の同じクライアントが複数存在する場合には，譲歩クライアント特定手段１０５は，要求の順番に応じて譲歩クライアントとして特定しても良い。例えば，同じ満足度を有するクライアントのうち，一番遅い順番で要求信号を送信してきたクライアントから順に譲歩クライアントとして特定する。
すべてのクライアントが譲歩クライアントとして特定され，リソースがｘ＝ｂとなるように低下された後に，前記ステップＳ４０７においてＹＥＳの関係とならない場合，通信仕様案変更手段１０４は，例えば，
ａ＝（低下後のリソースの合計 − サービスリソース）／ クライアント数
で求めた値ａを，各クライアントに割り当てられたリソースから均等に差し引く，或いは，それぞれのクライアントの要求データ容量の大きさの全体の要求データ容量の大きさに対する比率ｒを，ａに乗じて得られる値ｒ×ａを各クライアントに割り当てられたリソースから差し引く等の手法も考えられる。
【００１９】
以上のような構成によれば，情報配信サーバ１０から全てのクライアントの要求に応えて情報配信ができない場合，累積満足度の高いクライアントから順に，割り当てるリソースを低下させることによって対応するため，クライアント間の累積満足度の均等化，即ち，クライアント間で受けるサービスの質の均等化を図ることができる。
また，この場合におけるリソースの低下は，前記（１）式においてｘ＝ｂとなるようになされるため，各顧客の累積満足度はｃ以上に保たれ，全クライアントの平均満足度も向上する。
図７は，本発明の実施形態に係る情報配信サーバ１０からの配信を受けたクライアントの累積満足度の標準偏差値の推移を，前記ＦＩＦＯによる処理を行う従来技術の場合と比較したものであり，線（１）が前者，線（２）が後者を示す。サービス回数が増えるにつれていずれも標準偏差は低くなるが，サービス回数が１００回を超える付近で，線（２）は０．０１付近，線（１）は０．００５付近に収束することが分かる。このように，本実施形態に係る情報配信サーバ１０からの情報配信を受けた顧客の累積満足度のばらつきはサービス回数が増えるにつれて低くなり，公平なサービスの提供が実現されていることが理解できる。
図８は，本発明の実施形態に係る情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，前記ＦＩＦＯによる処理を行う従来技術の場合と比較したものであり，線（３）が前者，線（４）が後者を示す。前者では，サービス回数が増えるにつれて平均累積満足度が向上し，サービス回数が約１００回を超えてからは，０．８以上の高い水準で安定する。一方，後者では０．２から０．４程度の低い水準で推移することが理解できる。
これは，本発明の実施形態に係る情報配信サーバ１０による情報配信サービスを受けたクライアントが，譲歩クライアントとして特定されたクライアントであってもｘ＝ｂとなるようにリソースの再割当がなされるからである。即ち，図３に示されるよう，たとえ譲歩クライアントであってもサービス１回ごとの満足度ＡＣはｃであり，一方，譲歩クライアント以外のクライアントのサービス１回ごとの満足度ＡＣは１であり，繰り返しサービスを受ける結果，各クライアントの累積満足度がｃ以上１以下の高い水準に保たれるためである。
【実施例】
【００２０】
前記実施の形態では，クライアントの満足度ＣＳ及び累積満足度ＡＣＳが情報配信サーバ１０の制御部（満足度算出手段１０７）によって算出され，情報配信サーバ１０のクライアント情報保管部１２０に保管されているが，これらは，各端末において算出及び／若しくは保管されても良い。このような構成によれば，情報配信サーバ１０側の負担を減らすことができる。
クライアント端末に満足度ＣＳ及び累積満足度ＡＣＳが保管される実施例においては，各クライアントが要求信号を送信する際に，満足度ＣＳ，累積満足度ＡＣＳに関する情報を含ませる等によって，情報配信サーバ１０に対して自己の満足度ＣＳ，累積満足度ＡＣＳを知らせる。
【００２１】
前記複数のクライアントからの要求を受け付ける際に，前記複数のクライアントに対して前記要求を許可する許可信号を発信する許可信号発信手段を更に備えた構成とすることも考えられる。
前記実施の形態では，所定の時間ｔを１サイクルとして要求の受付を行っているが，許可信号を発信している間を１サイクルとすることができる。例えば，あるサイクルで受信した要求に対応する情報配信がすべて完了した時点で許可信号を発信し，次のサイクルにおける要求受信を開始する構成とすれば，情報配信サーバ１０が有する全てのリソースを１回の情報配信の際に割り当てることができるため，前記サービスリソースの向上を図ることができる。
或いは，この許可信号を発信する時間帯を制御するタイマ手段を更に具備する構成としておいても良い。タイマ手段によって定期的に前記許可信号を発信する構成としておけば，所定の決まった時間に情報配信に関する要求の受信がなされるため，クライアントにとって使用しやすいシステムになる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態に係る情報配信装置の一例である情報配信サーバ１０の概略構成を示すブロック図。
【図２】前記情報配信サーバ１０の制御部の通信仕様案作成手段１０１によって実行される要求リソースの割り当ての手順の一例を示すフローチャート。
【図３】前記通信仕様案作成手段１０１によって実行されるデータ形式に関する案の作成手順の一例を示すフローチャート。
【図４】前記情報配信サーバ１０の制御部によって実行される情報配信処理手順の一例を示すフローチャート。
【図５】前記情報配信サーバ１０からの情報配信１回ごとのクライアントの満足度ＣＳを表すグラフ。
【図６】前記情報配信サーバ１０の制御部の通信仕様案変更手段１０４によって実行される通信仕様案の変更手順の一例を示すフローチャート。
【図７】前記情報配信サーバ１０からの情報配信を受けたクライアントの累積満足度の標準偏差値の推移を，従来技術の場合と比較して示すグラフ。
【図８】前記情報配信サーバ１０からの配信を受けたクライアントの累積満足度の平均値の推移を，従来技術の場合と比較して示すグラフ。
【符号の説明】
【００２３】
１０・・・情報配信サーバ（情報配信装置の一例）
２１〜２５・・・クライアント端末
１０１・・・通信仕様案作成手段
１０２・・・データＩＤ参照手段
１０３・・・情報配信能力判別手段
１０４・・・通信仕様案変更手段
１０５・・・通信仕様決定手段
１０６・・・配信用データ加工手段
１０７・・・満足度算出手段
１１０・・・要求受信部
１２０・・・クライアント情報保管部
１２１，１２２・・・カウンタ
１３０・・・タイマ
１４０・・・メモリ
１５０・・・配信用データ保管部
１６０・・・配信部
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する情報配信装置であって，
各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて，各クライアントの満足度を算出する満足度算出手段と，
前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力を判別する情報配信能力判別手段と，
前記情報配信能力判別手段による判別結果と，前記満足度算出手段によって算出された各クライアントの満足度とに応じて，各クライアントへの情報配信時の通信仕様を決定する通信仕様決定手段と，
前記通信仕様決定手段によって決定された前記通信仕様に基づいて前記複数のクライアント各々に対して情報配信を実行する情報配信実行手段と，
を具備してなることを特徴とする情報配信装置。
【請求項２】
前記複数のクライアント各々からの要求に応じて情報配信を行うことを目的とする各クライアントに対応する通信仕様の案である通信仕様案を作成する通信仕様案作成手段と，
前記情報配信能力判別手段によって前記複数のクライアントからの要求に応じた情報の配信が不可能であると判別される場合に，前記通信仕様案作成手段によって作成された通信仕様案を変更する通信仕様案変更手段と，
を更に備え，
前記通信仕様決定手段が，前記通信仕様案変更手段によって変更された前記通信仕様案に基づいて，各クライアントへの情報配信時の通信仕様を決定するものである請求項１に記載の情報配信装置。
【請求項３】
前記満足度算出手段によって算出される満足度に基づいて要求通りの情報配信を行わないクライアントを特定するクライアント特定手段を更に備え，
前記通信仕様案変更手段が，
前記通信仕様案作成手段によって作成された前記通信仕様案の，前記クライアント特定手段によって特定されたクライアントに対応する通信仕様を低下させることによって前記通信仕様案を変更するものである請求項２に記載の情報配信装置。
【請求項４】
前記複数のクライアントからの要求を受け付ける際に，前記複数のクライアントに対して許可信号を発信する許可信号発信手段を更に具備してなる請求項１〜３のいずれかに記載の情報配信装置。
【請求項５】
前記許可信号発信手段によって許可信号を発信する時間帯を決定するタイマ手段を更に具備してなる請求項４に記載の情報配信装置。
【請求項６】
前記クライアントからの要求に応じて，配信が要求された情報のデータ容量を検知するデータ容量検知手段を更に具備してなる請求項１〜５のいずれかに記載の情報配信装置。
【請求項７】
前記クライアントからの要求が，配信を要求する情報の希望配信完了時間に関する情報を含むものである請求項１〜６のいずれかに記載の情報配信装置。
【請求項８】
前記クライアントからの要求が，前記クライアント各々の端末仕様に関する情報を含むものである請求項１〜７のいずれかに記載の情報配信装置。
【請求項９】
ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する情報配信方法であって，
各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて，各クライアントの満足度を算出する満足度算出工程と，
前記複数のクライアントからの要求に応じた情報の配信が可能か否か，自己の情報配信能力を判別する情報配信能力判別工程と，
前記情報配信能力判別工程による判別結果と，前記満足度算出工程により算出された各クライアントの満足度とに応じて，各クライアントへの情報配信時の通信仕様を決定する通信仕様決定工程と，
前記通信仕様決定工程により決定された前記通信仕様に基づいて前記複数のクライアント各々に対して情報配信を実行する情報配信実行工程と，
を有してなることを特徴とする情報配信方法。
【請求項１】
ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する情報配信装置であって，
各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて，各クライアントの満足度を算出する満足度算出手段と，
前記複数のクライアントからの要求に応じた情報の配信が可能か否かに関する自己の情報配信能力を判別する情報配信能力判別手段と，
前記情報配信能力判別手段による判別結果と，前記満足度算出手段によって算出された各クライアントの満足度とに応じて，各クライアントへの情報配信時の通信仕様を決定する通信仕様決定手段と，
前記通信仕様決定手段によって決定された前記通信仕様に基づいて前記複数のクライアント各々に対して情報配信を実行する情報配信実行手段と，
を具備してなることを特徴とする情報配信装置。
【請求項２】
前記複数のクライアント各々からの要求に応じて情報配信を行うことを目的とする各クライアントに対応する通信仕様の案である通信仕様案を作成する通信仕様案作成手段と，
前記情報配信能力判別手段によって前記複数のクライアントからの要求に応じた情報の配信が不可能であると判別される場合に，前記通信仕様案作成手段によって作成された通信仕様案を変更する通信仕様案変更手段と，
を更に備え，
前記通信仕様決定手段が，前記通信仕様案変更手段によって変更された前記通信仕様案に基づいて，各クライアントへの情報配信時の通信仕様を決定するものである請求項１に記載の情報配信装置。
【請求項３】
前記満足度算出手段によって算出される満足度に基づいて要求通りの情報配信を行わないクライアントを特定するクライアント特定手段を更に備え，
前記通信仕様案変更手段が，
前記通信仕様案作成手段によって作成された前記通信仕様案の，前記クライアント特定手段によって特定されたクライアントに対応する通信仕様を低下させることによって前記通信仕様案を変更するものである請求項２に記載の情報配信装置。
【請求項４】
前記複数のクライアントからの要求を受け付ける際に，前記複数のクライアントに対して許可信号を発信する許可信号発信手段を更に具備してなる請求項１〜３のいずれかに記載の情報配信装置。
【請求項５】
前記許可信号発信手段によって許可信号を発信する時間帯を決定するタイマ手段を更に具備してなる請求項４に記載の情報配信装置。
【請求項６】
前記クライアントからの要求に応じて，配信が要求された情報のデータ容量を検知するデータ容量検知手段を更に具備してなる請求項１〜５のいずれかに記載の情報配信装置。
【請求項７】
前記クライアントからの要求が，配信を要求する情報の希望配信完了時間に関する情報を含むものである請求項１〜６のいずれかに記載の情報配信装置。
【請求項８】
前記クライアントからの要求が，前記クライアント各々の端末仕様に関する情報を含むものである請求項１〜７のいずれかに記載の情報配信装置。
【請求項９】
ネットワークを介して接続された複数のクライアントからの要求に応じて情報を配信する情報配信方法であって，
各クライアントからの要求履歴と，各クライアントへの情報配信履歴とに基づいて，各クライアントの満足度を算出する満足度算出工程と，
前記複数のクライアントからの要求に応じた情報の配信が可能か否か，自己の情報配信能力を判別する情報配信能力判別工程と，
前記情報配信能力判別工程による判別結果と，前記満足度算出工程により算出された各クライアントの満足度とに応じて，各クライアントへの情報配信時の通信仕様を決定する通信仕様決定工程と，
前記通信仕様決定工程により決定された前記通信仕様に基づいて前記複数のクライアント各々に対して情報配信を実行する情報配信実行工程と，
を有してなることを特徴とする情報配信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−１０７００５（Ｐ２００６−１０７００５Ａ）
【公開日】平成１８年４月２０日（２００６．４．２０）
【国際特許分類】
【出願番号】特願２００４−２９１０８１（Ｐ２００４−２９１０８１）
【出願日】平成１６年１０月４日（２００４．１０．４）
【出願人】（０００００１１９９）株式会社神戸製鋼所 (5,860)
【Ｆターム（参考）】
【公開日】平成１８年４月２０日（２００６．４．２０）
【国際特許分類】
【出願日】平成１６年１０月４日（２００４．１０．４）
【出願人】（０００００１１９９）株式会社神戸製鋼所 (5,860)
【Ｆターム（参考）】
[ Back to top ]