JP4256218B2 - 通信システム、通信装置、プログラム並びに通信方法 - Google Patents
通信システム、通信装置、プログラム並びに通信方法 Download PDFInfo
- Publication number
- JP4256218B2 JP4256218B2 JP2003203791A JP2003203791A JP4256218B2 JP 4256218 B2 JP4256218 B2 JP 4256218B2 JP 2003203791 A JP2003203791 A JP 2003203791A JP 2003203791 A JP2003203791 A JP 2003203791A JP 4256218 B2 JP4256218 B2 JP 4256218B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- version
- client
- communication
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、データ又はプログラムなどの各種コンテンツをネットワーク経由で通信する通信システム、通信装置、プログラム並びに通信方法に関する。
【０００２】
【従来の技術】
ソフトウェアの一部の修正（書き換え、変換、変更なども含む）に用いられるプログラム又はデータをパッチという。パッチは、例えばセキュリティソフトウェアなど、様々なソフトウェアの修正に用いられる。
【０００３】
一般的に、パッチの配信は、サーバ／クライアント方式（以下、「Ｓ／Ｃ方式」という）によって行われる。サーバは、パッチを保持し、ソフトウェアの修正を行うクライアントに対してパッチを配信する。
【０００４】
一般的なＳ／Ｃ方式によるパッチの配信では、利用者は、クライアントを操作してサーバに接続し、自己の保持するソフトウェアをバージョンアップさせることが可能か確認し、バージョンアップを行う場合に、サーバに対してパッチを要求する。
【０００５】
Ｓ／Ｃ方式による他のパッチの配信方法として、クライアントがサーバのアップデート情報を自動確認し、クライアントがこの確認結果に応じてパッチを自動的にサーバからダウンロードする方法がある。
【０００６】
【特許文献１】
特開２００３−０１８２１３号公報
【０００７】
【発明が解決しようとする課題】
従来のＳ／Ｃ方式による配信では、クライアントの数が増加するとサーバの負荷が過大となる。したがって、サーバを運営するサービス提供者（サーバ管理者を含む）は、サーバの処理能力を増加させる必要があり、管理労力及びコストが高くなる。
【０００８】
また、利用者は、サーバに負荷が集中した場合、迅速にサーバに接続してサービスを受けることが困難となる。
【０００９】
宅配便などでサービス提供者から利用者にパッチを記録したＣＤ−ＲＯＭ（Compact Disk - Read Only Memory）を送付する場合、送付料金がかかる。また、パッチのＣＤ−ＲＯＭへの記録、利用者によるクライアントへのパッチの読み込みなどの作業が必要であり、サービス提供者及び利用者の双方の作業労力が大きくなる。
【００１０】
本発明は、以上のような実情に鑑みてなされたもので、コンテンツを提供する側に過負荷がかかることを防止しつつ、コンテンツを確実かつ迅速に提供するための通信システム、通信装置、プログラム並びに通信方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明を実現するにあたって講じた具体的手段について以下に説明する。
【００１２】
第１の発明は、サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムである。サーバは、配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、マルチキャスト配信におけるマルチキャストグループを指定するマルチキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を取得する手段と、配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を用いて、配信要求で指定されたコンテンツ識別情報の示すコンテンツのマルチキャスト配信を実行する配信手段とを具備する。マルチキャストグループに属するクライアントは、マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、マルチキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、クライアントに保持されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する。
【００１３】
第２の発明は、サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムである、サーバは、配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、エニーキャスト配信におけるエニーキャストグループを指定するエニーキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を取得する手段と、配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を用いて、エニーキャストリクエストを送信する手段と、エニーキャストリプライを受信する手段と、エニーキャストリプライの受信順序に基づいて、配信要求で指定されたコンテンツ識別情報の示すコンテンツの送信先を決定する送信先決定手段と、送信先決定手段によって決定された送信先に、配信要求で指定されたコンテンツ識別情報の示すコンテンツを送信する手段とを具備する。エニーキャストグループに属するクライアントは、エニーキャスト配信におけるエニーキャストリクエストを受信する手段と、エニーキャストリクエストの送信元にエニーキャストリプライを返す手段と、エニーキャストリクエストの送信元からコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、エニーキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、クライアントに保持されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する。
【００１４】
第３の発明は、マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、同一のマルチキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、記録手段に記録されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する通信装置である。
【００１５】
第４の発明は、エニーキャスト配信におけるエニーキャストリクエストを受信する手段と、エニーキャストリクエストの送信元にエニーキャストリプライを返す手段と、エニーキャストリクエストの送信元からコンテンツを受信する受信手段と、受信した前記コンテンツを記録する記録手段と、同一のエニーキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、記録手段に記録されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、記録手段に記憶されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する通信装置である。
【００１８】
上記各発明の各手段は、コンピュータにプログラムを読み込んで実現可能である。このプログラムは、記録媒体に記録してコンピュータに適用してもよい。
【００１９】
また、上記各発明によってコンテンツの通信方法が実行される。
【００２０】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態について説明する。なお、以下においては、コンテンツをサーバからクライアントに提供する場合を例に説明する。
【００２１】
ここで、コンテンツには、マルチメディアコンテンツ、プログラム、ドキュメントデータ、ポリシーデータ、パッチ、設定データ、ログ情報などが含まれる。
【００２２】
本実施の形態では、コンテンツがパッチの場合を例に説明する。しかしながら、サーバからクライアントに配信されるコンテンツは、パッチのみに限定されず、例えばクライアントの設定データ、ポリシーデータなど、様々なプログラム又はデータであってもよい。
【００２３】
以下の各図において同一の要素については同一の符号を付してその説明を省略し、異なる部分についてのみ詳しく説明する。
【００２４】
（第１の実施の形態）
本実施の形態においては、ネットワーク上において、サーバからクライアントにマルチキャスト配信を用いてパッチが送信され、その後パッチを受信したクライアントから受信していないクライアントにピア・ツー・ピア（以下、「P2P」という）通信を用いてパッチが送信され、クライアント間でパッチの共有化が図られる。
【００２５】
マルチキャスト配信では、サーバからネットワークに送信されたコンテンツはネットワーク内のルータによって必要に応じてコピーされ、複数のクライアントに受信される。
【００２６】
図１は、本実施の形態に係る通信システムの構成例を示す図である。
【００２７】
通信システム１では、サーバ（送信側通信装置）２とクライアント（受信側通信装置）３１〜３ｎとがネットワーク４経由で接続される。
【００２８】
ネットワーク４は、サーバ２とクライアント３１〜３ｎとを接続する通信網である。ネットワーク４としては、例えばインターネット、電話回線網、無線ＬＡＮ（Local Area Network）等など、コンテンツが送受信され各種機器が接続される各種の通信媒体が用いられる。
【００２９】
通信システム１では、まず、パッチ５がサーバ２からクライアント３１〜３ｎにマルチキャスト配信を用いて送信される。次に、通信システム１では、パッチ５を受信したクライアントからパッチ５を未受信のクライアントに対して、パッチ５がP2P通信を用いて送信される。
【００３０】
この図１では、クライアント３１〜３ｎのうち、クライアント３１，３３〜３５は、パッチ５をサーバ２から受信している。そして、それぞれパッチ５を受信したクライアント３１，３４，３５からパッチ５を未受信のクライアント３２，３ｎ，３６に、パッチ５が送信されている。
【００３１】
クライアント３１〜３ｎ間でパッチ５が送受信される場合、パッチ５を受信したクライアントは、通信先を決定する通信先決定サーバ４４にアクセスし、通信先決定サーバ４４から通知された同一のマルチキャストグループに属する他のクライアントとの間でP2P通信を行う。
【００３２】
図２は、本実施の形態に係る通信システム１のサーバ２の具体的構成例を示すブロック図である。
【００３３】
サーバ２は、マルチキャスト配信を用いて、クライアント３１〜３ｎにネットワーク４経由でパッチ５を送信する。
【００３４】
サーバ２は、記録媒体６に記録されているプログラム６ａを読み込み、実行することにより、要求処理部７、配信済み確認部８、グループ管理部９、配信部１０としての機能を実現する。サーバ２は、記録部１１を具備する。なお、本実施の形態では、記録部１１はサーバ２に内蔵されているが、例えばサーバ２に外付けの記録装置であってもよい。また、サーバ２はネットワーク４経由で記録部１１をアクセスするとしてもよい。
【００３５】
記録部１１は、ソフトウェア情報１１ａ、配信情報１１ｂ、グループ情報１１ｃ、パッチ情報１１ｄを記録する。
【００３６】
ソフトウェア情報１１ａは、図３に示すように、サーバ２が配信を行うパッチのパッチ識別情報とこのパッチに基づいて修正されるソフトウェアのソフトウェア識別情報とを対応付けた情報である。
【００３７】
本実施の形態では、パッチ識別情報には、パッチの名称とバージョン情報とが含まれているとする。図３の例では、パッチ識別情報１４とソフトウェア識別情報１５とが対応付けされている。
【００３８】
配信情報１１ｂは、図４に示すように、サーバ２から配信されたパッチのパッチ識別情報を含む。すなわち、この配信情報１１ｂに登録されているパッチ識別情報の示すパッチは、送信済みを意味する。図４の例では、パッチ識別情報１６，１７で示されるパッチが配信済みであることが表されている。
【００３９】
グループ情報１１ｃは、図５に示すように、サーバ２が配信を行うパッチによって修正されるソフトウェアのソフトウェア識別情報と、このソフトウェアを具備するクライアントの属するマルチキャストグループを示すマルチキャストアドレス情報とを対応付けた情報である。
【００４０】
例えば、図５のグループ情報１１ｃは、ウイルス駆除ソフトウェアは、クライアント３１〜３ｎのうちマルチキャストアドレス情報「3ffe:2001::2」で表されるマルチキャストグループに属するクライアントに具備されていることを表している。
【００４１】
なお、本実施の形態において、コンテンツに対して固有のマルチキャストアドレス情報を対応付けなくてもよい場合がある。
【００４２】
例えば、複数のコンテンツに共通のアドレス情報を対応付けておき、この共通のアドレス情報から各コンテンツを識別可能な仕組みを上位層に実装する、そして、この仕組みを用いて共通のアドレス情報から各コンテンツの識別を行うとしてもよい。
【００４３】
より具体的には、複数のコンテンツに同一のマルチキャストアドレス情報を対応付け、トランスポート層において、複数のコンテンツをポート番号によって識別するとしてもよい。
【００４４】
コンピュータネットワークでは、ＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）のポート番号でアプリケーションを判別することが可能である。また、コンピュータネットワークでは、ＴＣＰ又はＵＤＰのポート番号で続けて送られてくるデータをグルーピングすることが可能である。
【００４５】
固有のアドレス情報を用いて各コンテンツの識別を行うと、コンテンツの増加に応じてアドレス情報も増加し、アドレス情報が不足する場合がある。しかしながら、上記のように、上位層において共通のアドレス情報から各コンテンツを識別可能とすることにより、複数のコンテンツ間でアドレス情報を共有させることが可能になり、アドレス情報の不足を防止できる。
【００４６】
パッチ情報１１ｄは、図６に示すように、サーバ２が配信を行うパッチとこのパッチを識別するためのパッチ識別情報とを対応付けた情報である。
【００４７】
例えば、図６の例では、サーバ２はパッチ１２を配信し、このパッチ１２のパッチ識別情報１４は「ウイルス駆除.0102513」である旨が表されている。また、サーバ２はパッチ６９を配信し、このパッチ６９のパッチ識別情報は「地図データ.0301234」である旨が表されている。
【００４８】
本実施の形態においては、パッチ識別情報とマルチキャストアドレス情報とが、ソフトウェア識別情報を経由して間接的に対応付けされている。
【００４９】
要求処理部７は、要求発行元から配信要求１３を受け付け、この配信要求１３で指定されたパッチ識別情報１４を認識する。要求発行元としては、例えばサービス提供者、他のシステム、サーバ２内の他の要素などがある。
【００５０】
要求処理部７は、記録部１１に記録されているソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されているか判断する。
【００５１】
パッチ識別情報１４がソフトウェア情報１１ａに登録されていない場合、要求処理部７は、配信要求１３で指定されたパッチ識別情報１４の示すパッチはこのサーバ２が配信を行うパッチではないと判断し、エラーを配信要求１３の発行元に返す。
【００５２】
一方、パッチ識別情報１４がソフトウェア情報１１ａに登録されている場合、要求処理部７は、ソフトウェア情報１１ａでパッチ識別情報１４と対応付けられているソフトウェア識別情報１５を取得する。そして、要求処理部７は、パッチ識別情報１４とソフトウェア識別情報１５とを配信済み確認部８に提供する。
【００５３】
配信済み確認部８は、要求処理部７からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部１１に記録されている配信情報１１ｂを参照し、パッチ識別情報１４より新しい又は同じバージョン情報のパッチ識別情報が配信情報１１ｂに登録されているか否か判断する。
【００５４】
例えば、配信済み確認部８は、パッチ識別情報１４に含まれているパッチ名と同じパッチ名を含み、パッチ識別情報１４に含まれているバージョン情報より新しい又は同じバージョン情報を含むパッチ識別情報が配信情報１１ｂに登録されているか判断する。例えば、バージョン情報の新旧は、バージョン情報の大小関係によって判断する。
【００５５】
パッチ識別情報１４より新しいバージョン情報又は同じバージョン情報のパッチ識別情報が配信情報１１ｂに登録されている場合、配信済み確認部８は、配信要求で指定されたパッチ識別情報の示すパッチが配信済みである判断し、エラーを配信要求１３の発行元に返す。
【００５６】
一方、配信要求で指定されたパッチ識別情報１４に含まれているバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報よりも新しい場合、配信済み確認部８は、パッチ識別情報１４の示すパッチは未送信であると判断し、パッチ識別情報１４とソフトウェア識別情報１５とをグループ管理部９に提供するとともに、パッチ識別情報１４を配信情報１１ｂに登録する。
【００５７】
グループ管理部９は、配信済み確認部８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部１１に登録されているグループ情報１１ｃを参照し、ソフトウェア識別情報１５と対応するマルチキャストアドレス情報１８を取得する。この取得したマルチキャストアドレス情報１８はマルチキャスト配信先を表す。
【００５８】
そして、グループ管理部９は、パッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を配信部１０に提供する。
【００５９】
配信部１０は、ネットワーク４に各種コンテンツを配信するための命令を発行するとともに、ネットワーク４から各種コンテンツを受信するための命令を発行する。
【００６０】
また、配信部１０は、グループ管理部９からパッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８とを受け付けた場合、記録部１１に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【００６１】
そして、配信部１０は、マルチキャストアドレス情報１８を付して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツをネットワーク４に対してマルチキャスト配信を用いて送信する。
【００６２】
図７及び図８は、本実施の形態に係るサーバ２の動作（マルチキャスト配信段階）の一例を示すフローチャートである。
【００６３】
ステップＳ１において、要求処理部７は、配信要求１３を受け付ける。配信要求１３の発行は、サービス提供者によるコマンドラインからの入力によって行われてもよい。また、配信要求１３の発行は、サービス提供者がグラフィカルユーザーインターフェースを用いて行うとしてもよい。また、サーバ２によって配信要求を発行するコマンドが所定時間経過毎に実行され、要求処理部７は、この発行された配信要求１３を受け付けるとしてもよい。
【００６４】
例えば、配信要求１３として「% multicast -t 3000 ウイルス駆除.0102513」が発行される。この配信要求１３において「multicast」は命令名であり、「-t 3000」は3000秒後に配信を行う指示を表し、「ウイルス駆除」は配信されるパッチの名前を表す。「.」以下の「0102513」はパッチのバージョン情報を表す。すなわち、この「ウイルス駆除.0102513」は、配信要求１３で指定されたパッチ識別情報１４である。
【００６５】
ステップＳ２において、要求処理部７は、配信要求１３に基づいて、オプション解析と送信対象のパッチを示すパッチ識別情報１４の認識とを実行する。
【００６６】
ステップＳ３において、要求処理部７は、ソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４に対応するソフトウェア識別情報が登録されているか判断する。登録の有無に基づいて、配信要求１３で指定されたパッチ識別情報１４の示すパッチがこのサーバ２による配信対象のパッチか否か判断される。
【００６７】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されていない場合、ステップＳ４において、要求処理部７は、配信要求元にエラーを返し、処理を終了する。
【００６８】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されている場合、ステップＳ５において、パッチ識別情報１４に対応するソフトウェア識別情報１５を取得し、パッチ識別情報１４とソフトウェア識別情報１５とを配信済み確認部８に提供する。
【００６９】
ステップＳ６において、配信済み確認部８は、要求処理部７からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、配信情報１１ｂを参照し、配信要求１３で指定されたパッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報より新しいか判断する。パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報よりも新しい場合、未配信と判断される。一方、パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報と同一又は古い場合、配信済みと判断される。
【００７０】
パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報と同一又は古い場合、ステップＳ７において、配信済み確認部８は、配信要求元にエラーを返し、処理を終了する。
【００７１】
一方、パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報より新しい場合、ステップＳ８において、配信済み確認部８は、パッチ識別情報１４とソフトウェア識別情報１５とをグループ管理部９に提供する。
【００７２】
また、ステップＳ９において、配信済み確認部８は、パッチ識別情報１４を配信情報１１ｂに登録する。
【００７３】
ステップＳ１０において、グループ管理部９は、配信済み確認部８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、グループ情報１１ｃを参照し、ソフトウェア識別情報１５に対応するマルチキャストアドレス情報１８を取得する。ソフトウェア識別情報１５に対応するマルチキャストアドレス情報１８は、マルチキャスト配信先となる。マルチキャストグループとしてローカルサイト内のみを対象とする場合には、224.0.0.1から224.0.0.255までのアドレスがマルチキャストアドレス情報で指定される必要があり、インターネット全体をマルチキャストグループとする場合には224.0.1.0から238.255.255.255までのアドレスがマルチキャストアドレス情報で指定される必要がある。
【００７４】
ステップＳ１１において、グループ管理部９は、パッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を配信部１０に提供する。
【００７５】
ステップＳ１２において、配信部１０は、グループ管理部９からパッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を受け付けると、パッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【００７６】
ステップＳ１３において、配信部１０は、パッチ１２とパッチ識別情報１４及びソフトウェア識別情報１５について、マルチキャストアドレス情報１８の示すマルチキャストグループに対するマルチキャスト配信を実行する。なお、配信部１０は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５以外のコンテンツについて、マルチキャストアドレス情報１８の示すマルチキャストグループに対するマルチキャスト配信を実行してもよい。
【００７７】
なお、上記ステップＳ９は、上記ステップＳ６の後であればいずれの時点で実行してもよい。
【００７８】
図９は、本実施の形態に係るクライアント３１の具体的構成例を示すブロック図である。なお、他のクライアント３２〜３ｎの構成例についても同様である。
【００７９】
クライアント３１は、サーバ２からネットワーク４経由でパッチ５、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信し、他のクライアント３２〜３ｎのいずれかとの間でコンテンツの送信又は受信を行う。なお、本実施の形態では、クライアント３１とクライアント３２とが同一のマルチキャストグループに属する場合について説明する。
【００８０】
クライアント３１は、記録媒体１９に記録されているプログラム１９ａを読み込み、実行することにより、マルチキャスト受信部２０、受信確認部２１、バージョン管理部２２、パッチ処理部２３、通信先取得部２４、通信許可部２５、認証部２６、バージョン比較部２７、コンテンツ通信部２８、P2P通信部４１としての機能を実現する。クライアント３１は、記録部２９を具備する。なお、本実施の形態では、記録部２９はクライアント３１に内蔵されているが、例えばクライアント３１に外付けの記録装置であってもよい。また、クライアント３１はネットワーク４経由で記録部２９をアクセスするとしてもよい。
【００８１】
記録部２９は、バージョン管理情報２９ａ、パッチ情報２９ｂ、ソフトウェア管理情報２９ｃ、通信許可情報２９ｄ、グループ管理情報２９ｅを記録する。
【００８２】
バージョン管理情報２９ａは、図１０に示すように、クライアント３１に保持されているソフトウェアのソフトウェア識別情報と、クライアント３１に受信されそのソフトウェアの修正処理に用いられたパッチのパッチ識別情報とを対応付けた情報である。図１０の例では、ソフトウェア識別情報１５とパッチ識別情報１６とが対応付けされている。
【００８３】
パッチ情報２９ｂは、クライアント３１に保持されているパッチとパッチ識別情報とを関係付けた情報であり、例えば上記図６と同様の形式で情報が記録される。
【００８４】
ソフトウェア管理情報２９ｃは、図１１に示すように、クライアント３１に保持されているソフトウェアとソフトウェア識別情報とを関係付けた情報である。この図１１の例では、ソフトウェア識別情報１５とソフトウェア４０とが対応付けされている。
【００８５】
通信許可情報２９ｄは、クライアント３１が他のクライアントとの間でP2P通信を行った場合に、当該クライアント３１がどのクライアントと通信を行い、どのようなコンテンツを送受信したかを表すログなどを含む情報である。
【００８６】
本実施の形態では、通信許可情報２９ｄは、クライアント間通信の通信先として決定された通信先クライアントの識別情報と通信開始時間と通信終了時間を含むとする。この通信許可情報２９ｄを参照することにより、クライアント３１が他のクライアント３２〜３ｎとの間で通信中か否かを判断可能である。
【００８７】
グループ管理情報２９ｅは、図１２に示すように、クライアント３１に保持されているソフトウェア識別情報と、このソフトウェア識別情報の示すソフトウェアに関するパッチを送信するサーバのアドレス情報と、このソフトウェア識別情報の示すソフトウェアから定まるクライアント３１の属するマルチキャストグループのグループ識別情報とを関係付けた情報である。
【００８８】
この図１２では、ソフトウェア識別情報１５とサーバアドレス情報４２とグループ識別情報４３とが対応付けされている。
【００８９】
マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、マルチキャスト配信においてクライアント３１の属するマルチキャストグループを示すグループ識別情報４３とこのマルチキャスト配信を行うサーバ２のアドレス情報４２とを取得する。
【００９０】
マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、グループ識別情報４３の示すマルチキャストグループに属するために、サーバアドレス情報４２の示すサーバ２にIGMP Joinメッセージを送信する。
【００９１】
クライアント３１からサーバ２までの途中経路にあるネットワーク４上のルータ（図示せず）は、IGMP Joinメッセージを理解する。そして、ルータは、IGMP Joinメッセージを受信したポートに接続されているネットワークが、このルータ内に保持されておりマルチキャストグループを登録するテーブルに登録されていなければ、そのIGMP Joinメッセージを受信したポートに接続されているネットワークの情報をテーブル内に登録する。
【００９２】
これにより，サーバ２とクライアント３１との間でマルチキャスト配信を実行するための通信経路が確保される。
【００９３】
サーバ２からマルチキャストグループに対して送信されたコンテンツは、この処理によって確保された経路を通る。ルータは、受信したコンテンツをコピーして各登録ポートから送信する。これにより、同一のマルチキャストグループに属するクライアントに向けて、コンテンツのマルチキャスト配信が実行される。なお、マルチキャスト配信ではＵＤＰ（User Datagram Protocol）により通信が行われる。
【００９４】
マルチキャスト受信部２０は、サーバ２からマルチキャスト配信を用いて送信されたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信し、受信確認部２１に提供する。
【００９５】
受信確認部２１は、マルチキャスト受信部２０から受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５の完全性を判断する。
【００９６】
パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５が不完全の場合、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄する。
【００９７】
一方、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５が完全な場合、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５をバージョン管理部２２に提供する。
【００９８】
バージョン管理部２２は、受信確認部２１からパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を受け付けた場合、記録部２９に記録されているバージョン管理情報２９ａを参照する。
【００９９】
バージョン管理部２２は、サーバ２から受信したパッチ識別情報１４に含まれているパッチ名と同じパッチ名を含み、パッチ識別情報１４に含まれているバージョン情報より新しい又は同じバージョン情報を含むパッチ識別情報がバージョン管理情報２９ａに登録されているか判断する。すなわち、バージョン管理部２２は、サーバ２から受信したパッチ１２より新しい又は同じバージョンのパッチを受信済みか否か判断する。
【０１００】
パッチ識別情報１４より新しいバージョン情報又は同じバージョン情報のパッチ識別情報がバージョン管理情報２９ａに登録されている場合、バージョン管理部２２は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄する。
【０１０１】
一方、パッチ識別情報１４に含まれているバージョン情報がバージョン管理情報２９ａに登録されているパッチ識別情報のバージョン情報よりも新しい場合、バージョン管理部２２は、パッチ識別情報１４の示すパッチ１２は未受信であると判断し、パッチ識別情報１４とソフトウェア識別情報１５とを対応付けてバージョン管理情報２９ａに登録し、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部２３に提供する。
【０１０２】
パッチ処理部２３は、バージョン管理部２２又はコンテンツ通信部２８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、パッチ情報２９ｂからパッチ識別情報１４に対応する最新バージョンのパッチ１２を取得し、ソフトウェア管理情報２９ｃからソフトウェア識別情報１５に対応するソフトウェア４０を取得し、パッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理部２９ｃに登録する。
【０１０３】
通信先決定サーバ４４は、各クライアント３１〜３ｎの起動時に、各クライアント３１〜３ｎの登録を行う。
【０１０４】
通信先決定サーバ４４は、各クライアント３１〜３ｎの保持するソフトウェアを示すソフトウェア識別情報を各クライアント３１〜３ｎから取得する。
【０１０５】
通信先決定サーバ４４は、各クライアント３１〜３ｎの中から共通のソフトウェアを保持するクライアントの中からP2P通信を行うクライアントを決定し、P2P通信を行うと決定された各クライアントに対して通信先を提供する。なお、本実施の形態では、通信を行うクライアントとしてとしてクライアント３１が決定され、このクライアント３１の通信先としてクライアント３２が決定された場合について説明する。
【０１０６】
また、通信先決定サーバ４４は、登録したクライアントから一定期間経過してもアクセスがない場合、このクライアントは停止しているものと判断し、登録を解除する。
【０１０７】
クライアント３１のP2P通信部４１は、他のクライアント３２〜３ｎとの間においてP2P通信を行い、各種コンテンツを送受信する。
【０１０８】
通信先取得部２４は、クライアント３１が起動した場合に、通信先決定サーバ４４への登録を行う。
【０１０９】
また、通信先取得部２４は、記録部２９に記録されているソフトウェア管理情報２９ｃを参照し、一定期間経過する度に、クライアント３１に保持されているソフトウェアのソフトウェア識別情報を通信先決定サーバ４４に提供する。
【０１１０】
通信先取得部２４は、通信先決定サーバ４４から通信先のクライアント３２の指定を受け付けた場合、通信先のクライアント３２の指定を通信許可部２５に提供する。
【０１１１】
通信許可部２５は、通信先取得部２４から通信先のクライアント３２の指定を受け付けた場合、P2P通信部４１経由で通信先のクライアント３２にアクセスし、通信先のクライアント３２が他のクライアント３３〜３ｎと通信中か否か判断する。
【０１１２】
通信先のクライアント３２が他のクライアントと通信中でない場合、通信許可部２５は、通信先のクライアント３２の指定を認証部２６に提供する。通信先のクライアント３２が通信中の場合には、処理を終了する。なお、通信先のクライアント３２が通信中の場合には、処理を待ち状態としてもよい。
【０１１３】
認証部２６は、通信許可部２５から通信先のクライアント３２の指定を受け付けた場合、P2P通信部４１経由で通信先のクライアント３２にアクセスし、相互認証を行う。
【０１１４】
認証が正当に行われた場合、認証部２６は、通信開始時間を記録部２９の通信許可情報２９ｄに登録するとともに、通信先のクライアント３２の指定をバージョン比較部２７に提供する。認証が正当に行われなかった場合、処理を中止する。
【０１１５】
バージョン比較部２７は、認証部２６から通信先のクライアント３２の指定を受け付けた場合、記録部２９に記録されているバージョン管理情報２９ａを参照するとともに、P2P通信部４１経由で通信先のクライアント３２にアクセスしてクライアント３２のバージョン管理情報２９ａを取得する。これにより、比較対象の２つのバージョン管理情報２９ａが取得される。
【０１１６】
そして、バージョン比較部２７は、クライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを比較し、比較結果と通信先のクライアント３２の指定とをコンテンツ通信部２８に提供する。
【０１１７】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも新しい場合、コンテンツ通信部２８は、保持するパッチ１２とパッチ識別情報１４とソフトウェア識別情報１５とをP2P通信部４１経由で通信先のクライアント３２に提供する。
【０１１８】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも古い場合、コンテンツ通信部２８は、P2P通信部４１経由で通信先のクライアント３２から通信先のクライアント３２の保持するパッチとパッチ識別情報とソフトウェア識別情報とを受け付ける。そして、コンテンツ通信部２８は、通信先のクライアント３２から受け付けたパッチとパッチ識別情報とソフトウェア識別情報とに基づいてバージョン管理情報２９ａ、パッチ情報２９ｂへの登録を行い、通信先のクライアント３２から受け付けたパッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部２３に提供する。
【０１１９】
また、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１２０】
図１３は、本実施の形態に係るクライアント３１がサーバ２からマルチキャスト配信されたコンテンツを受信した場合の処理の一例を示すフローチャートである。
【０１２１】
ステップＴ１において、マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、マルチキャスト配信においてクライアント３１の属するマルチキャストグループを示すグループ識別情報４３とこのマルチキャストグループに対してマルチキャスト配信を実行するサーバ２のアドレス情報４２とを認識する。
【０１２２】
ステップＴ２において、マルチキャスト受信部２０は、グループ識別情報４３の示すマルチキャストグループに属するために、アドレス情報４２の示すサーバ２にIGMP Joinメッセージを送信する。
【０１２３】
ステップＴ３において、マルチキャスト受信部２０は、サーバ２からマルチキャスト配信を用いて送信されたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信する。
【０１２４】
ステップＴ４において、受信確認部２１は、マルチキャスト受信部２０から受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５の完全性を判断する。
【０１２５】
受信確認部２１による判断結果が不完全を示す場合、ステップＴ５において、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄し、処理を終了する。
【０１２６】
一方、受信確認部２１による判断結果が完全を示す場合、ステップＴ６において、バージョン管理部２２は、記録部２９に記録されているバージョン管理情報２９ａを参照する。
【０１２７】
ステップＴ７において、バージョン管理部２２は、サーバ２から受信したパッチ１２のバージョンが新しいか判断する。
【０１２８】
サーバ２から受信したパッチ１２のバージョンが新しくない場合、ステップＴ８において、バージョン管理部２２は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄し、処理を終了する。
【０１２９】
一方、サーバ２から受信したパッチ１２のバージョンが新しい場合、ステップＴ９において、バージョン管理部２２は、パッチ識別情報１４とソフトウェア識別情報１５とを対応付けてバージョン管理情報２９ａに登録するとともに、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録する。
【０１３０】
ステップＴ１０において、パッチ処理部２３は、最新バージョンのパッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０１３１】
図１４及び図１５は、本実施の形態に係るクライアント３１と他のクライアント３２によってP2P通信によりコンテンツを送受信する処理の一例を示すフローチャートである。
【０１３２】
ステップＵ１において、通信先取得部２４は、クライアント３１が起動した場合に、通信先決定サーバ４４への登録を行う。
【０１３３】
ステップＵ２において、通信先取得部２４は、一定時間経過したか判断する。
【０１３４】
ステップＵ３において、通信先取得部２４は、一定時間経過した場合、通信先決定サーバ４４にアクセスし、例えばソフトウェア管理情報２９ｃなどの記録部２９の情報を提供する。一定時間経過前の場合、待ち状態となる。
【０１３５】
ステップＵ４において、通信先取得部２４は、通信先決定サーバ４４から通信先のクライアント３２の指定を受け付ける。
【０１３６】
ステップＵ５において、通信許可部２５は、P2P通信部４１経由で通信先のクライアント３２にアクセスし、通信先のクライアント３２が他のクライアント３３〜３ｎと通信中か否か判断する。
【０１３７】
通信先のクライアント３２が通信中の場合、通信許可部２５は、処理を終了するか待ち状態とする。
【０１３８】
通信先のクライアント３２が通信中でない場合、ステップＵ６において、認証部２６は、P2P通信部４１経由で通信先のクライアント３２にアクセスし、相互認証を行う。
【０１３９】
認証が正当に行われなかった場合、認証部２６は、処理を中止する。
【０１４０】
認証が正当に行われた場合、ステップＵ７において、認証部２６は、通信開始時間を記録部２９の通信許可情報２９ｄに登録する。
【０１４１】
ステップＵ８において、バージョン比較部２７は、記録部２９に記録されているバージョン管理情報２９ａを参照するとともに、P2P通信部４１経由で通信先のクライアント３２にアクセスし、比較対象となるクライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを取得する。
【０１４２】
ステップＵ９において、バージョン比較部２７は、クライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを比較する。
【０１４３】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも新しい場合、ステップＵ１０において、コンテンツ通信部２８は、パッチ１２とパッチ識別情報１４とソフトウェア識別情報１５とをP2P通信部４１経由で通信先のクライアント３２に提供する。
【０１４４】
ステップＵ１１において、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１４５】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも古い場合、ステップＵ１２において、コンテンツ通信部２８は、通信先のクライアント３２の保持するパッチとパッチ識別情報とソフトウェア識別情報とをP2P通信部４１経由で通信先のクライアント３２から受け付け、記録部２９に記録する。
【０１４６】
ステップＵ１３において、パッチ処理部２３は、最新バージョンのパッチを用いてソフトウェアを修正し、修正前のソフトウェアに代えて修正後のソフトウェアをソフトウェア管理情報２９ｃに登録する。
【０１４７】
ステップＵ１４において、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１４８】
なお、ステップＵ１３，１４は、逆の順序で実行してもよく、並列に実行してもよい。
【０１４９】
図１６は、通信システム１の連携動作の一例を示すシーケンス図である。この図１６では、クライアント間のP2P通信の通信先を決定する場合に、通信先決定サーバ４４が利用される。
【０１５０】
また、この図１６では、サーバ２からクライアント３１，３２に対してパッチ等のコンテンツが送信され、その後クライアント３１からクライアント３２に対してパッチ等のコンテンツが送信される場合を例として示している。
【０１５１】
通信システム１によるコンテンツの送信は、マルチキャスト配信を用いた送信が行われるマルチキャスト配信段階と、クライアント間でP2P通信を用いた送信が行われるクライアント間通信段階とからなる。
【０１５２】
まず、上記図１６におけるマルチキャスト配信段階について説明する。
【０１５３】
サーバ２の要求処理部７は、配信要求１３に対するオプション解析と配信対象のパッチを示すパッチ識別情報１４の認識とを実行する。
【０１５４】
また、要求処理部７は、ソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２が自サーバ２の配信対象かを確認する。
【０１５５】
配信要求１３で指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されておらず、自サーバ２による配信対象でない場合、要求処理部７は、配信要求１３に対してエラーを返し、処理を終了する。
【０１５６】
配信済み確認部８は、配信情報１１ｂを参照し、配信要求１３で指定されたパッチ識別情報１４が登録されているか判断する。
【０１５７】
配信情報１１ｂにパッチ識別情報１４が登録されている場合、配信済み確認部８は、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２は配信済みであると判断し、配信要求元にエラーを返し、処理を終了する。
【０１５８】
一方、配信情報１１ｂにパッチ識別情報１４が登録されていない場合、配信済み確認部８は、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２は未配信であると判断し、グループ管理部９に処理を移す。
【０１５９】
グループ管理部９は、グループ情報１１ｃを参照し、配信対象のパッチ１２によって修正されるソフトウェアを保持するクライアント３１，３２の属するマルチキャストグループを示すマルチキャストアドレス情報１８を取得する。
【０１６０】
配信部１０は、パッチ情報１１ｄを参照し、配信要求１３で指定されたパッチ識別情報１４に対応するパッチ１２を取得する。
【０１６１】
そして、配信部１０は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを、マルチキャストアドレス情報１８の示すマルチキャストグループに属するクライアント３１，３２に対して、マルチキャスト配信を用いて送信する。
【０１６２】
上記のようなマルチキャスト配信の実行前において、クライアント３１、３２のマルチキャスト受信部２０は、マルチキャスト配信に対応するための前処理を実行する。
【０１６３】
マルチキャスト配信の実行後、クライアント３１，３２のマルチキャスト受信部２０は、サーバ２から送信されたコンテンツを受信する。
【０１６４】
クライアント３１，３２の受信確認部２１は、受信したコンテンツの完全性を確認する。
【０１６５】
この図１６の例では、サーバ２からクライアント３１に受信されたコンテンツは完全であったが、サーバ２からクライアント３２に受信されたコンテンツは不完全であったとする。
【０１６６】
クライアント３１のバージョン管理部２２は、バージョン管理情報２９ａを参照し、受信したコンテンツのバージョンとバージョン管理情報２９ａに登録されているバージョンとを比較し、受信したコンテンツが新バージョンか判断する。
【０１６７】
クライアント３１のバージョン管理部２２は、受信したコンテンツが新バージョンでない場合、処理をマルチキャスト配信の待ち受け状態に戻す。
【０１６８】
バージョン管理部２２は、受信したコンテンツが新バージョンの場合、受信したコンテンツを記録部２９に登録する。
【０１６９】
パッチ処理部２３は、受信したコンテンツに基づいて、ソフトウェアの修正を行う。
【０１７０】
一方、クライアント３２の受信確認部２１は、受信したコンテンツが不完全の場合には、受信したコンテンツを破棄する。
【０１７１】
次に、上記図１６におけるクライアント間通信段階について説明する。
【０１７２】
クライアント通信段階において、各クライアント３１，３２は、同一のマルチキャストグループに属する他のクライアントとの間でコンテンツを共有し、更新する。
【０１７３】
クライアント３１，３２間で共有されるコンテンツはサーバ２から各クライアント３１，３２にマルチキャスト配信を用いて送信されたコンテンツである。
【０１７４】
上記図１６において、クライアント３２では、サーバ２から受信したコンテンツが完全でないため、破棄されている。したがって、同じマルチキャストグループに属するクライアント３１，３２の中に、新バージョンのコンテンツを保持しているクライアント３１と保持していないクライアント３２とが混在している。
【０１７５】
クライアント間通信段階では、マルチキャスト配信により受信したコンテンツを保持するクライアント３１と保持しないクライアント３２との間でコンテンツが送受信される。
【０１７６】
クライアント３１，３２の通信先取得部２４は、起動した段階で通信先決定サーバ４４にアクセスする。
【０１７７】
通信先決定サーバ４４は、クライアント３１，３２からのアクセスに応じてクライアント３１，３２の登録を行う。
【０１７８】
その後、クライアント３１，３２の通信先取得部２４は、一定時間経過する毎に、通信先決定サーバ４４にアクセスして通信先のクライアントの指定（通信先情報）を要求し、通信先のクライアントの指定を取得する。
【０１７９】
通信先決定サーバ４４は、一定時間経過後においても通信先のクライアントの指定を要求しないクライアントについては停止していると判断し、登録されている情報を消去する。
【０１８０】
ここで、この図１６では、通信先決定サーバ４４は、クライアント３１からクライアント３２にコンテンツを提供することを決定したとする。クライアント３１の通信先取得部２４は、通信先決定サーバ４４に接続し、通信先のクライアント３２の指定を取得する。
【０１８１】
クライアント３１は、取得した通信先のクライアント３２の指定に基づいて、通信先のクライアント３２への接続を要求する。
【０１８２】
クライアント３１からクライアント３２への接続は、例えば次の処理にしたがって行われる。
【０１８３】
まず、クライアント３１の通信許可部２５は、P2P通信部４１を用いて、通信先のクライアント３２に接続要求を送信する。
【０１８４】
接続要求を受信した通信先のクライアント３２の通信許可部２５は、接続要求を受け付け、クライアント３２の記録部２９に記録されている通信許可情報２９ｄを参照し、通信先のクライアント３２が他のクライアント間で通信を行っていないか確認する。
【０１８５】
通信先のクライアント３２が通信を行っている場合、通信先のクライアント３２の通信許可部２５は、P2P通信部４１を用いて、接続拒否メッセージをクライアント３１に返す。
【０１８６】
通信先のクライアント３２が通信を行っていない場合、クライアント３１の認証部２６は、P2P通信部４１を用いて、通信先のクライアント３２の認証部２６と連携して相互に認証を行い、正当な通信相手であるか確認する。
【０１８７】
各クライアント３１，３２の認証部２６は、例えばグループ署名を用いて各クライアント３１，３２の属するグループを確認する。クライアント３１の認証部２６は、通信先のクライアント３２の所属するグループについても確認を行う。
【０１８８】
認証が正しく行われた場合、通信先のクライアント３２の認証部２６は、P2P通信部４１を用いて、通信先のクライアント３２の通信許可情報２９ｄに、クライアント３１の情報と通信開始時間を登録し、クライアント３１に接続確立の応答メッセージを送信する。
【０１８９】
クライアント３１の認証部２６は、応答メッセージを受け付けた場合に、通信先のクライアント３２の情報と通信開始時間をクライアント３１の通信許可情報２９ｄに登録する。
【０１９０】
接続が確立した場合、クライアント３１のバージョン比較部２７は、P2P通信部４１を用いて、通信先のクライアント３２のバージョン比較部２７と連携し、クライアント３１，３２に保持されているパッチのバージョン情報を確認する。
【０１９１】
例えば、クライアント３１のバージョン比較部２７は、クライアント３１のバージョン管理情報２９ａを通信先のクライアント３２のバージョン比較部２７に提供する。
【０１９２】
通信先のクライアント３２のバージョン比較部２７は、受け付けたクライアント３１のバージョン管理情報２９ａを、通信先のクライアント３２のバージョン管理情報２９ａと比較する。
【０１９３】
クライアント３１のバージョンの方が通信先のクライアント３２のバージョンより新しい場合、通信先のクライアント３２のバージョン比較部２７は、受信希望メッセージをクライアント３１に送信する。
【０１９４】
クライアント３１のバージョンの方が通信先のクライアント３２のバージョンより古い場合、通信先のクライアント３２のバージョン比較部２７は、送信希望メッセージをクライアント３１に送信する。
【０１９５】
バージョンが同じ場合には、通信先のクライアント３２のバージョン比較部２７は、同じバージョンである旨のメッセージをクライアント３１に送信する。
【０１９６】
通信先のクライアント３２からクライアント３１が受信希望メッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、記録部２９に記録されているパッチ、パッチ識別情報、ソフトウェア識別情報等のコンテンツを取得し、P2P通信部４１を用いて通信先のクライアント３２に送信し、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９７】
通信先のクライアント３２からクライアント３１が送信希望メッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、通信先のクライアント３２のコンテンツ通信部２８から提供されたコンテンツをクライアント３１の記録部２９に記録し、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９８】
通信先のクライアント３２からクライアント３１が同じバージョンである旨のメッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９９】
上記クライアント３１，３２間で実行されるP2P通信では、TCP通信が利用されるため、データの完全性は保証される。
【０２００】
以上説明した本実施の形態に係る通信システム１では、まずマルチキャスト配信を用いてサーバ２からクライアント３１〜３ｎにコンテンツが送信される。
【０２０１】
これにより、サーバ２から送信される総データ量を削減でき，サービス提供者のサーバ能力増強に関する労力とコストを抑制できる。
【０２０２】
また、本実施の形態では、マルチキャスト配信を用いたサーバからクライアントへのコンテンツの送信において、全てのクライアントにコンテンツが正常に受信されなかった場合に、コンテンツを正常に受信したクライアントからコンテンツを正常に受信しなかったクライアントへコンテンツが送信され、コンテンツの配信が補完される。
【０２０３】
これにより、各クライアントは、確実にかつ迅速にコンテンツを取得できる。
【０２０４】
（第２の実施の形態）
本実施の形態では、上記第１の実施の形態の変形例について説明する。上記第１の実施の形態では、マルチキャスト配信を用いてサーバからクライアントにコンテンツが送信され、その後マルチキャスト配信を補完するためにクライアント間でP2P通信が行われる。
【０２０５】
しかしながら、本実施の形態では、マルチキャスト配信の代わりにエニーキャスト配信が用いられる。
【０２０６】
本実施の形態では、エニーキャスト配信を用いてサーバからコンテンツが提供されるクライアントが決定され、サーバからこの決定されたクライアントにコンテンツが提供される。そして、決定されたクライアントから他のクライアントにコンテンツが分配される。
【０２０７】
なお、本実施の形態では、クライアント間でのコンテンツの送受信には、上記第１の実施の形態と同様の手法にP2P通信が用いられるとする。
【０２０８】
エニーキャスト配信は、IPv6（Internet Protocol Version 6）で実装された機能である。エニーキャスト配信は、指定されたＤＮＳ（Domain Name System）サーバの中から最も負荷の軽いものを選び出すなどの用途に使用される。
【０２０９】
エニーキャスト配信では、サーバは、エニーキャストグループに属する複数のクライアントに対してエニーキャストリクエストを送信し、このエニーキャストリクエストの応答であるエニーキャストリプライを各クライアントから受信する。
【０２１０】
そして、サーバは、エニーキャストリプライに基づいて各クライアントの負荷レベルを認識する。
【０２１１】
図１７は、本実施の形態に係る通信システムによるエニーキャスト配信の状態の一例を示す図である。
【０２１２】
通信システム４５では、サーバ４６とクライアント４７１〜４７ｎと通信先決定サーバ４４がサブネットワーク４８経由で接続される。サブネットワーク４８に接続されるクライアント４７１〜４７ｎは、共通のネットワークアドレスによって表される。
【０２１３】
通信システム４５では、まず、サーバ４６からクライアント４７１〜４７ｎにエニーキャスト配信によってエニーキャストリクエストが送信される。次に、エニーキャストリクエストを受信したクライアント４７１〜４７ｎからサーバ４６にエニーキャストリプライが返信される。
【０２１４】
次に、サーバ４６において各クライアント４７１〜４７ｎから受信したエニーキャストリプライに基づいて負荷の軽いクライアントが決定される。この図１７の例では、クライアント４７１〜４７ｎのうちクライアント４７１の負荷が最も軽い場合を示している。
【０２１５】
そして、サーバ４６からこの決定されたクライアント４７１にパッチ５等を含むコンテンツが送信される。サーバ４６からクライアント４７１にコンテンツが送信される場合、このコンテンツに署名が付されるとしてもよい。
【０２１６】
なお、本実施の形態においては、クライアント４７１〜４７ｎの全てがエニーキャスト配信の対象であるエニーキャストグループに属するとして説明を行う。
【０２１７】
サブネットワーク４８は、同一のネットワークアドレス又はブロードキャストアドレスで表され、ルータ又はスイッチによって分断されていない通信網であり、無線・有線を問わない。このサブネットワーク４８を経由して、エニーキャストリクエスト、エニーキャストリプライ、コンテンツが送受信される。
【０２１８】
図１８は、本実施の形態に係る通信システム４５によるクライアント間通信の状態の一例を示す図である。
【０２１９】
サーバ４６からコンテンツを受信したクライアント４７１から他のクライアント４７２〜４７ｎにP2P通信を用いてコンテンツが送信される。このクライアント４７１〜４７ｎ間でのコンテンツの送受信は、上記第１の実施の形態の場合と同様の手法が適用でき、本実施の形態においては説明を省略する。
【０２２０】
図１９は、本実施の形態に係る通信システム４５のサーバ４６の具体的構成例を示すブロック図である。
【０２２１】
サーバ４６は、記録媒体４９に記録されているプログラム４９ａを読み込み、実行することにより、要求処理部５０、アドレス取得部５１、リクエスト送信部５２、リプライ受信部５３、配信先決定部５４、配信部５５としての機能を実現する。サーバ４６は、記録部５６を具備する。なお、本実施の形態では、記録部５６はサーバ４６に内蔵されているが、例えばサーバ４６に外付けの記録装置であってもよい。また、サーバ４６はサブネットワーク４８経由で記録部５６をアクセスするとしてもよい。
【０２２２】
記録部５６は、ソフトウェア情報１１ａ、アドレス管理情報５６ａ、リプライ管理情報５６ｂ、配信情報５６ｃ、パッチ情報１１ｄを記録する。
【０２２３】
記録部５６に記録されているソフトウェア情報１１ａとパッチ情報１１ｄは、上記第１の実施の形態の場合と同様であるため、説明を省略する。
【０２２４】
アドレス管理情報５６ａは、図２０に示すように、サーバ４６から配信されるパッチによって修正が行われるソフトウェアのソフトウェア識別情報と、このソフトウェアを保持するクライアントの属するエニーキャストグループを示すエニーキャストアドレス情報とを対応付けた情報である。例えば、このアドレス管理情報５６ａでは、「ウイルス駆除ソフトウェア」という内容のソフトウェア識別情報１５に、「3ffe: 2001::2」という内容のエニーキャストアドレス情報５７が対応付けされている。図２０のアドレス管理情報５６ａは、ソフトウェア識別情報１５で表されるウイルス駆除ソフトウェアは、エニーキャストアドレス情報５７で表されるエニーキャストグループに属するクライアントに具備されていることを表している。
【０２２５】
なお、本実施の形態においても、上記第１の実施の形態と同様の理由により、コンテンツに対して固有のエニーキャストアドレス情報を対応付けなくてもよい場合がある。
【０２２６】
リプライ管理情報５６ｂは、図２１に示すように、リプライ受信部５３によってクライアント４７１〜４７ｎから受信されたエニーキャストリプライ５８１〜５８ｎを、受信順序を認識可能な状態で保持する情報である。
【０２２７】
この図２１のリプライ管理情報５６ｂでは、クライアント４７１〜４７ｎの順序で、エニーキャストリプライ５８１〜５８ｎが受信された場合を示している。
【０２２８】
エニーキャストリプライ５８１〜５８ｎには、送信元のクライアント４７１〜４７ｎのアドレス情報５９１〜５９ｎが含まれる。
【０２２９】
配信情報５６ｃは、図２２に示すように、パッチ識別情報と、このパッチ識別情報の示すパッチを送信した送信先クライアントのアドレス情報とを対応付けた情報である。この図２２の例では、「ウイルス駆除.0102513」という内容のパッチ識別情報１４に、「3ffe: 2001::30」という内容のアドレス情報６０が対応付けされている。
【０２３０】
本実施の形態においては、パッチ識別情報とエニーキャストアドレス情報とが、ソフトウェア識別情報を経由して間接的に対応付けされている。
【０２３１】
要求処理部５０は、要求発行元から配信要求６１を受け付け、この配信要求６１によって指定されたパッチ識別情報１４を認識する。
【０２３２】
また、要求処理部５０は、記録部５６に記録されているソフトウェア情報１１ａを参照し、配信要求６１によって指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されているか判断する。
【０２３３】
パッチ識別情報１４がソフトウェア情報１１ａに登録されていない場合、要求処理部５０は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチではないと判断し、エラーを配信要求６１の発行元に返す。
【０２３４】
一方、パッチ識別情報１４がソフトウェア情報１１ａに登録されている場合、要求処理部５０は、ソフトウェア情報１１ａからパッチ識別情報１４に対応するソフトウェア識別情報１５を取得する。そして、要求処理部５０は、パッチ識別情報１４とソフトウェア識別情報１５とをアドレス取得部５１に提供する。
【０２３５】
アドレス取得部５１は、要求処理部５０からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部５６に記録されているアドレス管理情報５６ａを参照する。
【０２３６】
また、アドレス取得部５１は、要求処理部５０から受け付けたソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されているか判断する。
【０２３７】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されていない場合、アドレス取得部５１は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチではないと判断し、エラーを配信要求６１の発行元に返す。
【０２３８】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されている場合、アドレス取得部５１は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチであると判断し、ソフトウェア識別情報１５に対応するエニーキャストアドレス情報５７を取得する。
【０２３９】
そして、アドレス取得部５１は、パッチ識別情報１４とソフトウェア識別情報１５とエニーキャストアドレス情報５７をリクエスト送信部５２に提供する。
【０２４０】
リクエスト送信部５２は、パッチ識別情報１４とソフトウェア識別情報１５とエニーキャストアドレス情報５７とをアドレス取得部５１から受け付けると、エニーキャストアドレス情報５７に基づいてエニーキャストアドレス配信におけるエニーキャストリクエストを送信する。このサーバ４６のリクエスト送信部５２から送信されるエニーキャストリクエストには、サーバ４６を示すアドレス情報が含まれている。
【０２４１】
リプライ受信部５３は、エニーキャストリクエストを受信した各クライアント４７１〜４７ｎからエニーキャストリプライ５８１〜５８ｎを受信する。
【０２４２】
そして、リプライ受信部５３は、エニーキャストリプライ５８１〜５８ｎを受信順序に応じてリプライ管理情報５６ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とを配信先決定部５４に提供する。
【０２４３】
配信先決定部５４は、パッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、リプライ管理情報５６ｂを参照する。
【０２４４】
配信先決定部５４は、リプライ管理情報５６ｂに登録されているエニーキャストリプライ５８１〜５８ｎのうち最先に受信したエニーキャストリプライ５８１を取得し、この再選に受信したエニーキャストリプライ５８１に含まれているアドレス情報５９１を取得する。
【０２４５】
そして、配信先決定部５４は、記録部５６に記録されている配信情報５６ｃを参照し、パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されているか判断する。
【０２４６】
パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されていない場合、配信先決定部５４は、取得したアドレス情報５９１の示すクライアントを配信先と決定し、アドレス情報５９１とパッチ識別情報１４とソフトウェア識別情報１５とを配信部５５に提供する。すなわち、パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されていない場合には、このパッチ識別情報１４の示すパッチはアドレス情報５９１の示すクライアント４７１に未送信であると判断される。
【０２４７】
一方、パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されている場合、配信先決定部５４は、このパッチ識別情報１４の示すパッチはアドレス情報５９１の示すクライアント４７１に送信済みであると判断する。すると、配信先決定部５４は、リプライ管理情報５６ｂを参照し、先に取得したエニーキャストリプライ５８１の次に受信したエニーキャストリプライ５８２を取得し、この新たに取得したエニーキャストリプライ５８２について上記のエニーキャストリプライ５８１に対する処理と同様の処理を実行する。これにより、パッチ識別情報１４の示すパッチを未送信のクライアントの中から、最先にエニーキャストリプライを返したクライアントが配信先として決定される。
【０２４８】
なお、本実施の形態では、配信先決定部５４は、アドレス情報５９１の示すクライアント４７１を配信先として決定したとする。
【０２４９】
配信部５５は、配信先決定部５４からパッチ識別情報１４とソフトウェア識別情報１５とアドレス情報５９１とを受け付けた場合、まず、アドレス情報５９１の示すクライアント４７１とのバージョンの比較を行うために、クライアント４７１に対して、パッチ識別情報１４を送信する。
【０２５０】
クライアント４７１は、サーバ４６から受信したパッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含み、このクライアント４７１に登録されているパッチ識別情報を検索する。
【０２５１】
そして、クライアント４７１は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報に含まれているバージョン情報とを比較する。
【０２５２】
受信したパッチ識別情報１４に含まれているバージョン情報の方が新しい場合、クライアント４７１は、コンテンツ送信要求をサーバ４７に返す。
【０２５３】
受信したパッチ識別情報１４に含まれているバージョン情報の方が新しくない場合、クライアント４７１は、中止要求をサーバ４７に返す。
【０２５４】
配信部５５は、配信先決定部５４によって決定されたアドレス情報５９１の示すクライアント４７１から中止要求を受信した場合、処理を終了する。
【０２５５】
一方、配信部５５は、クライアント４７１からコンテンツ送信要求を受信した場合、記録部５６に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【０２５６】
配信部１０は、決定されたアドレス情報５９１の示すクライアント４７１に対して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを送信する。
【０２５７】
そして、配信部１０は、送信されたパッチ１２を示すパッチ識別情報１４と決定されたアドレス情報５９１とを対応付けて配信情報５６ｃに登録する。
【０２５８】
図２３及び図２４は、本実施の形態に係るサーバ４６の動作の一例を示すフローチャートである。
【０２５９】
ステップＶ１において、要求処理部５０は、配信要求６１を受け付ける。
【０２６０】
例えば、配信要求６１として「% anycastsend -t now ウイルス駆除.0102513」が発行される。この配信要求６１において「anycastsend」は命令名であり、「-t now」は要求発行時に配信を行う指示を表し、「ウイルス駆除」は配信されるパッチの名前を表す。「.」以下の「0102513」はパッチのバージョン情報を表す。すなわち、この「ウイルス駆除.0102513」は、配信要求６１によって指定されたパッチ識別情報１４である。
【０２６１】
ステップＶ２において、要求処理部５０は、配信要求６１に基づいて、オプション解析と配信対象のパッチ識別情報１４の認識とを実行する。
【０２６２】
ステップＶ３において、要求処理部５０は、ソフトウェア情報１１ａを参照し、パッチ識別情報１４に対応するソフトウェア識別情報が登録されているか判断する。
【０２６３】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されていない場合、ステップＶ４において、要求処理部５０は、配信要求元にエラーを返し、処理を終了する。
【０２６４】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されている場合、ステップＶ５において、要求処理部５０は、パッチ識別情報１４に対応するソフトウェア識別情報１５を取得し、パッチ識別情報１４とソフトウェア識別情報１５とをアドレス取得部５１に提供する。
【０２６５】
ステップＶ６において、アドレス取得部５１は、アドレス管理情報５６ａを参照する。
【０２６６】
ステップＶ７において、アドレス取得部５１は、要求処理部５０から受け付けたソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されているか判断する。
【０２６７】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されていない場合、ステップＶ８において、アドレス取得部５１は、エラーを配信要求６１の発行元に返す。
【０２６８】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されている場合、ステップＶ９において、アドレス取得部５１は、ソフトウェア識別情報１５に対応するエニーキャストアドレス情報５７を取得する。
【０２６９】
ステップＶ１０において、リクエスト送信部５２は、エニーキャストアドレス情報５７に基づいてエニーキャストアドレス配信におけるエニーキャストリクエストを送信する。
【０２７０】
ステップＶ１１において、リプライ受信部５３は、エニーキャストリクエストを受信した各クライアント４７１〜４７ｎからエニーキャストリプライ５８１〜５８ｎを受信する。
【０２７１】
ステップＶ１２において、リプライ受信部５３は、エニーキャストリプライ５８１〜５８ｎを受信順序に応じてリプライ管理情報５６ｂに登録する。
【０２７２】
ステップＶ１３において、配信先決定部５４は、リプライ管理情報５６ｂに登録されているエニーキャストリプライ５８１〜５８ｎのうち最先に受信したエニーキャストリプライ５８１を取得し、最先に受信したエニーキャストリプライ５８１に含まれているアドレス情報５９１を取得する。
【０２７３】
ステップＶ１４において、配信先決定部５４は、記録部５６に記録されている配信情報５６ｃを参照し、配信要求６１で指定されたパッチ識別情報１４と取得したアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されているか、すなわちアドレス情報５９１の示すクライアント４７１にパッチ識別情報１４の示すパッチを配信済みか判断する。
【０２７４】
パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されていない、すなわち未配信の場合、ステップＶ１５において、配信先決定部５４は、取得したアドレス情報５９１の示すクライアントを配信先と決定する。
【０２７５】
パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されている場合、ステップＶ１６において、配信先決定部５４は、リプライ管理情報５６ｂを参照し、現在扱っているエニーキャストリプライの次に受信したエニーキャストリプライを取得し、この次のエニーキャストリプライに含まれているアドレス情報を取得する。そして、上記ステップＶ１４の処理を繰り返す。
【０２７６】
なお、本実施の形態では、アドレス情報５９１の示すクライアント４７１が配信先として決定されたとする。
【０２７７】
ステップＶ１７において、配信部５５は、クライアント４７１側でバージョンの比較を行うために、決定されたアドレス情報５９１の示すクライアント４７１に対して、パッチ識別情報１４を送信する。
【０２７８】
ステップＶ１８において、配信部５５は、決定されたアドレス情報５９１の示すクライアント４７１からコンテンツ送信要求又は中止要求を受信する。
【０２７９】
クライアント４７１から中止要求を受信した場合、配信部５５は、処理を終了する。
【０２８０】
一方、クライアント４７１からコンテンツ送信要求を受信した場合、ステップＶ１９において、配信部５５は、記録部５６に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【０２８１】
ステップＶ２０において、配信部５５は、決定されたアドレス情報５９１の示すクライアントに対して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを送信する。
【０２８２】
ステップＶ２１において、配信部５５は、送信されたパッチ１２を示すパッチ識別情報１４と決定されたアドレス情報５９１とを対応付けて配信情報５６ｃに登録する。
【０２８３】
なお、ステップＶ２１は、ステップＶ１８においてコンテンツ送信要求を受信した後であれば、いずれの時点で実行されてもよい。
【０２８４】
図２５は、本実施の形態に係るクライアント４７１の具体的構成例を示すブロック図である。なお、他のクライアント４７２〜４７ｎの構成例についても同様である。
【０２８５】
クライアント４７１は、記録媒体６２に記録されているプログラム６２ａを読み込み、実行することにより、リクエスト受信部６３、リプライ送信部６４、バージョン管理部６５、コンテンツ受信部６６、パッチ処理部６７、通信先取得部２４、通信許可部２５、認証部２６、バージョン比較部２７、コンテンツ通信部２８、P2P通信部４１としての機能を実現する。クライアント４７１は、記録部６８を具備する。なお、本実施の形態では、記録部６８はクライアント４７１に内蔵されているが、例えばクライアント４７１に外付けの記録装置であってもよい。また、クライアント４７１はサブネットワーク４８経由で記録部６８をアクセスするとしてもよい。
【０２８６】
記録部６８は、バージョン管理情報６８ａ、パッチ情報２９ｂ、ソフトウェア管理情報２９ｃ、通信許可情報２９ｄを記録する。
【０２８７】
バージョン管理情報２９ａには、図２６に示すように、クライアント４７１に受信されこのクライアント４７１に保持されているソフトウェアの修正処理に用いられたパッチのパッチ識別情報が登録されている。
【０２８８】
図２６の例では、「ウイルス駆除.0100001」という内容のパッチ識別情報１６が登録されている。
【０２８９】
リクエスト受信部６３は、サーバ４６からエニーキャストリクエストを受信すると、この受信したエニーキャストリクエストをリプライ送信部６４に提供する。
【０２９０】
リプライ送信部６４は、リクエスト受信部６３からエニーキャストリクエストを受け付けると、エニーキャストリクエストに含まれているサーバ４６のアドレス情報を取得する。
【０２９１】
そして、リプライ送信部６４は、取得したサーバ４６のアドレス情報に基づいて、このクライアント４７１のアドレス情報を含むエニーキャストリプライをサーバ４６に送信する。
【０２９２】
バージョン管理部６５は、サーバ４６からパッチ識別情報１４を受信すると、バージョン管理情報６８ａを参照する。
【０２９３】
バージョン管理部６５は、バージョン管理情報６８ａの中から、受信したパッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含むパッチ識別情報１６を検索する。
【０２９４】
そして、バージョン管理部６５は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報１６に含まれているバージョン情報とを比較する。
【０２９５】
バージョン管理部６５は、受信したバージョン情報の方が検索したバージョン情報よりも新しい場合、コンテンツ送信要求をサーバ４６に返す。
【０２９６】
一方、バージョン管理部６５は、受信したバージョン情報が検索したバージョン情報よりも新しくない場合、中止要求をサーバ４６に返す。
【０２９７】
コンテンツ受信部６６は、サーバ４６に対してコンテンツ送信要求を返した場合に、サーバ４６からパッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを受信する。
【０２９８】
そして、コンテンツ受信部６６は、パッチ識別情報１４をバージョン管理情報６８ａに登録し、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部６７に提供する。
【０２９９】
パッチ処理部６７は、コンテンツ受信部６６又はコンテンツ通信部２８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、パッチ情報２９ｂからパッチ識別情報１４に対応する最新バージョンのパッチ１２を取得し、ソフトウェア管理情報２９ｃからソフトウェア識別情報１５に対応するソフトウェア４０を取得し、パッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０３００】
図２７及び図２８は、本実施の形態に係るクライアント４７１がサーバ４６からコンテンツを受信する処理の一例を示すフローチャートである。
【０３０１】
ステップＷ１において、リクエスト受信部６３は、サーバ４６から送信されたエニーキャストリクエストを受信する。
【０３０２】
ステップＷ２において、リプライ送信部６４は、エニーキャストリクエストに含まれているサーバ４６のアドレス情報を取得する。
【０３０３】
ステップＷ３において、リプライ送信部６４は、取得したサーバ４６のアドレス情報に基づいて、このクライアント４７１のアドレス情報５９１を含むエニーキャストリプライ５８１をサーバ４６に送信する。
【０３０４】
ステップＷ４において、バージョン管理部６５は、サーバ４６からパッチ識別情報１４を受信する。
【０３０５】
ステップＷ５において、バージョン管理部６５は、バージョン管理情報６８ａを参照する。
【０３０６】
ステップＷ６において、バージョン管理部６５は、バージョン管理情報６８ａの中から、パッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含むパッチ識別情報１６を検索する。
【０３０７】
ステップＷ７において、バージョン管理部６５は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報１６に含まれているバージョン情報とを比較する。
【０３０８】
受信したバージョン情報の方が検索したバージョン情報よりも新しい場合、ステップＷ８において、バージョン管理部６５は、コンテンツ送信要求をサーバ４６に返す。
【０３０９】
一方、受信したバージョン情報が検索したバージョン情報よりも新しくない場合、ステップＷ９において、バージョン管理部６５は、中止要求をサーバ４６に返す。この場合、処理は終了となる。
【０３１０】
サーバ４６に対してコンテンツ送信要求を返した場合、ステップＷ１０において、コンテンツ受信部６６は、サーバ４６からパッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを受信する。
【０３１１】
ステップＷ１１において、コンテンツ受信部６６は、パッチ識別情報１４をバージョン管理情報６８ａに登録するとともに、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録する。
【０３１２】
ステップＷ１２において、パッチ処理部６７は、最新バージョンのパッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０３１３】
以下に、本実施の形態に係る通信システム４５の連携動作について説明する。
【０３１４】
図２９は、通信システム４５の連携動作の一例を示すシーケンス図である。
【０３１５】
サーバ４６は、クライアント４７１〜４７ｎに対してエニーキャストリクエストを送信する。
【０３１６】
各クライアント４７１〜４７ｎは、サーバ４７からのエニーキャストリクエストを受信すると、エニーキャストリプライ５８１〜５８ｎをサーバ４７に返す。
【０３１７】
サーバ４７は、先に受信したエニーキャストリプライの優先度を高くしてコンテンツを送信するクライアントを決定する。この図２９では、クライアント４７１が決定されたとする。
【０３１８】
サーバ４７は、決定されたクライアント４７１に、配信要求６１で指定されたパッチ識別情報１４（バージョン情報が送信されればよい）を送信する。
【０３１９】
クライアント４７１は、受信したバージョン情報と自己の保持するバージョン情報とを比較する。
【０３２０】
クライアント４７１は、比較の結果が新バージョンを表す場合、コンテンツ送信要求をサーバ４６に送信する。
【０３２１】
サーバ３６は、クライアント４７１からコンテンツ送信要求を受信した場合、配信要求６１で指定されたコンテンツをクライアント４７１に送信する。
【０３２２】
クライアント４７１は、同一のエニーキャストグループに属する他のクライアント４７２〜４７ｎにコンテンツを送信する。
【０３２３】
以上説明した本実施の形態に係る通信システム４５では、エニーキャストを用いてサーバ４６から特定のクライアント４７１にコンテンツが配信され、配信されたコンテンツが特定のクライアント４７１から他のクライアント４７２〜４７ｎに拡散される。
【０３２４】
これにより、サーバ４６の負荷を軽減するとともにクライアント４７１〜４７ｎにコンテンツを確実にかつ迅速に受信できる。
【０３２５】
（第３の実施の形態）
本実施の形態では、上記各実施の形態の変形例について説明する。
【０３２６】
例えば、上記第２の実施の形態のエニーキャスト配信に代えて、Xcastを用いて多数のネットワークに対して配信を実行するとしてもよい。
【０３２７】
Xcastとは、小グループ用のマルチキャスト配信である。このXcastでは、ネットワーク内に流されるパケットのヘッダに宛先を示すアドレス情報が複数記述され、ルータを通過する段階において各アドレス情報に対する経路が分岐する場合に、パケットがコピーされ配信される。
【０３２８】
Xcastで記載されるアドレス情報に多数のネットワークのエニーキャストアドレスを記載すれば、複数のサブネットワークにエニーキャストリクエストを送信することができ、上述したエニーキャスト通信と同様の手法により、各種コンテンツの配信を行うことができる。
【０３２９】
なお、上記各実施の形態において、通信システム１，４５の各構成要素は、プログラムにより実現される部分がハードウェアによって実現されるとしてもよい。
【０３３０】
上記各実施の形態におけるクライアントは、例えば家庭で使用される電化製品などであってもよい。これにより、ネットワーク経由で通信可能な電化製品の制御プログラムを迅速かつ正確かつ容易に修正できる。
【０３３１】
上記各実施の形態において、記録部１１，２９，４６，６８には、例えばストレージデバイス，メモリデバイス等が利用できる。
【０３３２】
また、上記各実施の形態に係る通信システム１，４５において、各構成要素は同様の動作を実現可能であれば配置を変更させてもよく、また各構成要素を自由に組み合わせてもよく、各構成要素を自由に分割してもよく、いくつかの構成要素を削除してもよい。
【０３３３】
例えば、記録部１１，２９，４６，６８は、複数の記録部に分割してもよい。すなわち、上記各実施の形態については、上記の構成そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
【０３３４】
【発明の効果】
以上詳記したように本発明においては、送信側の通信装置から複数の受信側の通信装置へのコンテンツの配信を迅速かつ正確に行うことができ、送信側の通信装置の負荷が軽減される。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態に係る通信システムの構成例を示す図。
【図２】 同実施の形態に係る通信システムのサーバの具体的構成例を示すブロック図。
【図３】 同実施の形態に係るソフトウェア情報の一例を示す図。
【図４】 同実施の形態に係る配信情報の一例を示す図。
【図５】 同実施の形態に係るグループ情報の一例を示す図。
【図６】 同実施の形態に係るパッチ情報の一例を示す図。
【図７】 同実施の形態に係るサーバの動作の前半の一例を示すフローチャート。
【図８】 同実施の形態に係るサーバの動作の後半の一例を示すフローチャート。
【図９】 同実施の形態に係るクライアントの具体的構成例を示すブロック図。
【図１０】 同実施の形態に係るバージョン管理情報の一例を示す図。
【図１１】 同実施の形態に係るソフトウェア管理情報の一例を示す図。
【図１２】 同実施の形態に係るグループ管理情報の一例を示す図。
【図１３】 同実施の形態に係るクライアントがサーバからマルチキャスト配信されたコンテンツを受信した後の処理の一例を示すフローチャート。
【図１４】 同実施の形態に係るクライアント間でP2P通信によりコンテンツを送受信する処理の前半の一例を示すフローチャート。
【図１５】 同実施の形態に係るクライアント間でP2P通信によりコンテンツを送受信する処理の後半の一例を示すフローチャート。
【図１６】 同実施の形態に係る通信システムの連携動作の一例を示すシーケンス図。
【図１７】 本発明の第２の実施の形態に係る通信システムによるエニーキャスト配信の状態の一例を示す図。
【図１８】 同実施の形態に係る通信システムによるクライアント間通信の状態の一例を示す図。
【図１９】 同実施の形態に係る通信システムのサーバの具体的構成例を示すブロック図。
【図２０】 同実施の形態に係るアドレス管理情報の一例を示す図。
【図２１】 同実施の形態に係るリプライ管理情報の一例を示す図。
【図２２】 同実施の形態に係る配信情報の一例を示す図。
【図２３】 同実施の形態に係るサーバの動作の前半の一例を示すフローチャート。
【図２４】 同実施の形態に係るサーバの動作の後半の一例を示すフローチャート
【図２５】 同実施の形態に係るクライアントの具体的構成例を示すブロック図。
【図２６】 同実施の形態に係るバージョン管理情報の一例を示す図。
【図２７】 同実施の形態に係るクライアントがサーバからコンテンツを受信する処理の前半の一例を示すフローチャート。
【図２８】 同実施の形態に係るクライアントがサーバからコンテンツを受信する処理の後半の一例を示すフローチャート。
【図２９】 同実施の形態に係る通信システムの連携動作の一例を示すシーケンス図。
【符号の説明】
１，４５…通信システム、２，４６…サーバ、３１〜３ｎ，４７１〜４７ｎ…クライアント、４…ネットワーク、５，１２ａ，１２ｂ…パッチ、６，１９，４９，６２…記録媒体、６ａ，１９ａ，４９ａ，６２ａ…プログラム、１３，６１…配信要求、１４…パッチ識別情報、１５…ソフトウェア識別情報、７，５０…要求処理部、８…配信済み確認部、９…グループ管理部、１０，５５…配信部、１１，２９，５６，６８…記録部、１１ａ…ソフトウェア情報、１１ｂ，５６ｃ…配信情報、１１ｃ…グループ情報、１１ｄ，２９ｂ…パッチ情報、２０…マルチキャスト受信部、２１…受信確認部、２２，６５…バージョン管理部、２３，６７…パッチ処理部、２４…通信先取得部、２５…通信先許可部、２６…認証部、２７…バージョン比較部、２８…コンテンツ通信部、２９ａ…バージョン管理部、２９ｃ…ソフトウェア管理情報、２９ｄ…通信許可情報、２９ｅ…グループ管理情報、４１…P2P通信部、４８…サブネットワーク、５１…アドレス取得部、５２…リクエスト送信部、５３…リプライ受信部、５４…配信先決定部、５６ａ…アドレス管理情報、５６ｂ…リプライ管理情報、６３…リクエスト受信部、６４…リプライ送信部、６６…コンテンツ受信部、６８ａ…バージョン管理情報
【発明の属する技術分野】
本発明は、データ又はプログラムなどの各種コンテンツをネットワーク経由で通信する通信システム、通信装置、プログラム並びに通信方法に関する。
【０００２】
【従来の技術】
ソフトウェアの一部の修正（書き換え、変換、変更なども含む）に用いられるプログラム又はデータをパッチという。パッチは、例えばセキュリティソフトウェアなど、様々なソフトウェアの修正に用いられる。
【０００３】
一般的に、パッチの配信は、サーバ／クライアント方式（以下、「Ｓ／Ｃ方式」という）によって行われる。サーバは、パッチを保持し、ソフトウェアの修正を行うクライアントに対してパッチを配信する。
【０００４】
一般的なＳ／Ｃ方式によるパッチの配信では、利用者は、クライアントを操作してサーバに接続し、自己の保持するソフトウェアをバージョンアップさせることが可能か確認し、バージョンアップを行う場合に、サーバに対してパッチを要求する。
【０００５】
Ｓ／Ｃ方式による他のパッチの配信方法として、クライアントがサーバのアップデート情報を自動確認し、クライアントがこの確認結果に応じてパッチを自動的にサーバからダウンロードする方法がある。
【０００６】
【特許文献１】
特開２００３−０１８２１３号公報
【０００７】
【発明が解決しようとする課題】
従来のＳ／Ｃ方式による配信では、クライアントの数が増加するとサーバの負荷が過大となる。したがって、サーバを運営するサービス提供者（サーバ管理者を含む）は、サーバの処理能力を増加させる必要があり、管理労力及びコストが高くなる。
【０００８】
また、利用者は、サーバに負荷が集中した場合、迅速にサーバに接続してサービスを受けることが困難となる。
【０００９】
宅配便などでサービス提供者から利用者にパッチを記録したＣＤ−ＲＯＭ（Compact Disk - Read Only Memory）を送付する場合、送付料金がかかる。また、パッチのＣＤ−ＲＯＭへの記録、利用者によるクライアントへのパッチの読み込みなどの作業が必要であり、サービス提供者及び利用者の双方の作業労力が大きくなる。
【００１０】
本発明は、以上のような実情に鑑みてなされたもので、コンテンツを提供する側に過負荷がかかることを防止しつつ、コンテンツを確実かつ迅速に提供するための通信システム、通信装置、プログラム並びに通信方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明を実現するにあたって講じた具体的手段について以下に説明する。
【００１２】
第１の発明は、サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムである。サーバは、配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、マルチキャスト配信におけるマルチキャストグループを指定するマルチキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を取得する手段と、配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を用いて、配信要求で指定されたコンテンツ識別情報の示すコンテンツのマルチキャスト配信を実行する配信手段とを具備する。マルチキャストグループに属するクライアントは、マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、マルチキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、クライアントに保持されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する。
【００１３】
第２の発明は、サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムである、サーバは、配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、エニーキャスト配信におけるエニーキャストグループを指定するエニーキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を取得する手段と、配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を用いて、エニーキャストリクエストを送信する手段と、エニーキャストリプライを受信する手段と、エニーキャストリプライの受信順序に基づいて、配信要求で指定されたコンテンツ識別情報の示すコンテンツの送信先を決定する送信先決定手段と、送信先決定手段によって決定された送信先に、配信要求で指定されたコンテンツ識別情報の示すコンテンツを送信する手段とを具備する。エニーキャストグループに属するクライアントは、エニーキャスト配信におけるエニーキャストリクエストを受信する手段と、エニーキャストリクエストの送信元にエニーキャストリプライを返す手段と、エニーキャストリクエストの送信元からコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、エニーキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、クライアントに保持されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、クライアントに保持されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する。
【００１４】
第３の発明は、マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段と、受信したコンテンツを記録する記録手段と、同一のマルチキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、記録手段に記録されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する通信装置である。
【００１５】
第４の発明は、エニーキャスト配信におけるエニーキャストリクエストを受信する手段と、エニーキャストリクエストの送信元にエニーキャストリプライを返す手段と、エニーキャストリクエストの送信元からコンテンツを受信する受信手段と、受信した前記コンテンツを記録する記録手段と、同一のエニーキャストグループに属する他のクライアントに保持されているコンテンツのバージョン情報と、記録手段に記録されているコンテンツのバージョン情報とを比較するバージョン比較手段と、バージョン比較手段による比較の結果に基づき、記録手段に記録されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも新しい場合に、他のクライアントに対してコンテンツの新バージョンをＰ２Ｐ通信で送信し、記録手段に記憶されているコンテンツのバージョンが他のクライアントに保持されているコンテンツのバージョンよりも古い場合に、他のクライアントからコンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段とを具備する通信装置である。
【００１８】
上記各発明の各手段は、コンピュータにプログラムを読み込んで実現可能である。このプログラムは、記録媒体に記録してコンピュータに適用してもよい。
【００１９】
また、上記各発明によってコンテンツの通信方法が実行される。
【００２０】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態について説明する。なお、以下においては、コンテンツをサーバからクライアントに提供する場合を例に説明する。
【００２１】
ここで、コンテンツには、マルチメディアコンテンツ、プログラム、ドキュメントデータ、ポリシーデータ、パッチ、設定データ、ログ情報などが含まれる。
【００２２】
本実施の形態では、コンテンツがパッチの場合を例に説明する。しかしながら、サーバからクライアントに配信されるコンテンツは、パッチのみに限定されず、例えばクライアントの設定データ、ポリシーデータなど、様々なプログラム又はデータであってもよい。
【００２３】
以下の各図において同一の要素については同一の符号を付してその説明を省略し、異なる部分についてのみ詳しく説明する。
【００２４】
（第１の実施の形態）
本実施の形態においては、ネットワーク上において、サーバからクライアントにマルチキャスト配信を用いてパッチが送信され、その後パッチを受信したクライアントから受信していないクライアントにピア・ツー・ピア（以下、「P2P」という）通信を用いてパッチが送信され、クライアント間でパッチの共有化が図られる。
【００２５】
マルチキャスト配信では、サーバからネットワークに送信されたコンテンツはネットワーク内のルータによって必要に応じてコピーされ、複数のクライアントに受信される。
【００２６】
図１は、本実施の形態に係る通信システムの構成例を示す図である。
【００２７】
通信システム１では、サーバ（送信側通信装置）２とクライアント（受信側通信装置）３１〜３ｎとがネットワーク４経由で接続される。
【００２８】
ネットワーク４は、サーバ２とクライアント３１〜３ｎとを接続する通信網である。ネットワーク４としては、例えばインターネット、電話回線網、無線ＬＡＮ（Local Area Network）等など、コンテンツが送受信され各種機器が接続される各種の通信媒体が用いられる。
【００２９】
通信システム１では、まず、パッチ５がサーバ２からクライアント３１〜３ｎにマルチキャスト配信を用いて送信される。次に、通信システム１では、パッチ５を受信したクライアントからパッチ５を未受信のクライアントに対して、パッチ５がP2P通信を用いて送信される。
【００３０】
この図１では、クライアント３１〜３ｎのうち、クライアント３１，３３〜３５は、パッチ５をサーバ２から受信している。そして、それぞれパッチ５を受信したクライアント３１，３４，３５からパッチ５を未受信のクライアント３２，３ｎ，３６に、パッチ５が送信されている。
【００３１】
クライアント３１〜３ｎ間でパッチ５が送受信される場合、パッチ５を受信したクライアントは、通信先を決定する通信先決定サーバ４４にアクセスし、通信先決定サーバ４４から通知された同一のマルチキャストグループに属する他のクライアントとの間でP2P通信を行う。
【００３２】
図２は、本実施の形態に係る通信システム１のサーバ２の具体的構成例を示すブロック図である。
【００３３】
サーバ２は、マルチキャスト配信を用いて、クライアント３１〜３ｎにネットワーク４経由でパッチ５を送信する。
【００３４】
サーバ２は、記録媒体６に記録されているプログラム６ａを読み込み、実行することにより、要求処理部７、配信済み確認部８、グループ管理部９、配信部１０としての機能を実現する。サーバ２は、記録部１１を具備する。なお、本実施の形態では、記録部１１はサーバ２に内蔵されているが、例えばサーバ２に外付けの記録装置であってもよい。また、サーバ２はネットワーク４経由で記録部１１をアクセスするとしてもよい。
【００３５】
記録部１１は、ソフトウェア情報１１ａ、配信情報１１ｂ、グループ情報１１ｃ、パッチ情報１１ｄを記録する。
【００３６】
ソフトウェア情報１１ａは、図３に示すように、サーバ２が配信を行うパッチのパッチ識別情報とこのパッチに基づいて修正されるソフトウェアのソフトウェア識別情報とを対応付けた情報である。
【００３７】
本実施の形態では、パッチ識別情報には、パッチの名称とバージョン情報とが含まれているとする。図３の例では、パッチ識別情報１４とソフトウェア識別情報１５とが対応付けされている。
【００３８】
配信情報１１ｂは、図４に示すように、サーバ２から配信されたパッチのパッチ識別情報を含む。すなわち、この配信情報１１ｂに登録されているパッチ識別情報の示すパッチは、送信済みを意味する。図４の例では、パッチ識別情報１６，１７で示されるパッチが配信済みであることが表されている。
【００３９】
グループ情報１１ｃは、図５に示すように、サーバ２が配信を行うパッチによって修正されるソフトウェアのソフトウェア識別情報と、このソフトウェアを具備するクライアントの属するマルチキャストグループを示すマルチキャストアドレス情報とを対応付けた情報である。
【００４０】
例えば、図５のグループ情報１１ｃは、ウイルス駆除ソフトウェアは、クライアント３１〜３ｎのうちマルチキャストアドレス情報「3ffe:2001::2」で表されるマルチキャストグループに属するクライアントに具備されていることを表している。
【００４１】
なお、本実施の形態において、コンテンツに対して固有のマルチキャストアドレス情報を対応付けなくてもよい場合がある。
【００４２】
例えば、複数のコンテンツに共通のアドレス情報を対応付けておき、この共通のアドレス情報から各コンテンツを識別可能な仕組みを上位層に実装する、そして、この仕組みを用いて共通のアドレス情報から各コンテンツの識別を行うとしてもよい。
【００４３】
より具体的には、複数のコンテンツに同一のマルチキャストアドレス情報を対応付け、トランスポート層において、複数のコンテンツをポート番号によって識別するとしてもよい。
【００４４】
コンピュータネットワークでは、ＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）のポート番号でアプリケーションを判別することが可能である。また、コンピュータネットワークでは、ＴＣＰ又はＵＤＰのポート番号で続けて送られてくるデータをグルーピングすることが可能である。
【００４５】
固有のアドレス情報を用いて各コンテンツの識別を行うと、コンテンツの増加に応じてアドレス情報も増加し、アドレス情報が不足する場合がある。しかしながら、上記のように、上位層において共通のアドレス情報から各コンテンツを識別可能とすることにより、複数のコンテンツ間でアドレス情報を共有させることが可能になり、アドレス情報の不足を防止できる。
【００４６】
パッチ情報１１ｄは、図６に示すように、サーバ２が配信を行うパッチとこのパッチを識別するためのパッチ識別情報とを対応付けた情報である。
【００４７】
例えば、図６の例では、サーバ２はパッチ１２を配信し、このパッチ１２のパッチ識別情報１４は「ウイルス駆除.0102513」である旨が表されている。また、サーバ２はパッチ６９を配信し、このパッチ６９のパッチ識別情報は「地図データ.0301234」である旨が表されている。
【００４８】
本実施の形態においては、パッチ識別情報とマルチキャストアドレス情報とが、ソフトウェア識別情報を経由して間接的に対応付けされている。
【００４９】
要求処理部７は、要求発行元から配信要求１３を受け付け、この配信要求１３で指定されたパッチ識別情報１４を認識する。要求発行元としては、例えばサービス提供者、他のシステム、サーバ２内の他の要素などがある。
【００５０】
要求処理部７は、記録部１１に記録されているソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されているか判断する。
【００５１】
パッチ識別情報１４がソフトウェア情報１１ａに登録されていない場合、要求処理部７は、配信要求１３で指定されたパッチ識別情報１４の示すパッチはこのサーバ２が配信を行うパッチではないと判断し、エラーを配信要求１３の発行元に返す。
【００５２】
一方、パッチ識別情報１４がソフトウェア情報１１ａに登録されている場合、要求処理部７は、ソフトウェア情報１１ａでパッチ識別情報１４と対応付けられているソフトウェア識別情報１５を取得する。そして、要求処理部７は、パッチ識別情報１４とソフトウェア識別情報１５とを配信済み確認部８に提供する。
【００５３】
配信済み確認部８は、要求処理部７からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部１１に記録されている配信情報１１ｂを参照し、パッチ識別情報１４より新しい又は同じバージョン情報のパッチ識別情報が配信情報１１ｂに登録されているか否か判断する。
【００５４】
例えば、配信済み確認部８は、パッチ識別情報１４に含まれているパッチ名と同じパッチ名を含み、パッチ識別情報１４に含まれているバージョン情報より新しい又は同じバージョン情報を含むパッチ識別情報が配信情報１１ｂに登録されているか判断する。例えば、バージョン情報の新旧は、バージョン情報の大小関係によって判断する。
【００５５】
パッチ識別情報１４より新しいバージョン情報又は同じバージョン情報のパッチ識別情報が配信情報１１ｂに登録されている場合、配信済み確認部８は、配信要求で指定されたパッチ識別情報の示すパッチが配信済みである判断し、エラーを配信要求１３の発行元に返す。
【００５６】
一方、配信要求で指定されたパッチ識別情報１４に含まれているバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報よりも新しい場合、配信済み確認部８は、パッチ識別情報１４の示すパッチは未送信であると判断し、パッチ識別情報１４とソフトウェア識別情報１５とをグループ管理部９に提供するとともに、パッチ識別情報１４を配信情報１１ｂに登録する。
【００５７】
グループ管理部９は、配信済み確認部８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部１１に登録されているグループ情報１１ｃを参照し、ソフトウェア識別情報１５と対応するマルチキャストアドレス情報１８を取得する。この取得したマルチキャストアドレス情報１８はマルチキャスト配信先を表す。
【００５８】
そして、グループ管理部９は、パッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を配信部１０に提供する。
【００５９】
配信部１０は、ネットワーク４に各種コンテンツを配信するための命令を発行するとともに、ネットワーク４から各種コンテンツを受信するための命令を発行する。
【００６０】
また、配信部１０は、グループ管理部９からパッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８とを受け付けた場合、記録部１１に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【００６１】
そして、配信部１０は、マルチキャストアドレス情報１８を付して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツをネットワーク４に対してマルチキャスト配信を用いて送信する。
【００６２】
図７及び図８は、本実施の形態に係るサーバ２の動作（マルチキャスト配信段階）の一例を示すフローチャートである。
【００６３】
ステップＳ１において、要求処理部７は、配信要求１３を受け付ける。配信要求１３の発行は、サービス提供者によるコマンドラインからの入力によって行われてもよい。また、配信要求１３の発行は、サービス提供者がグラフィカルユーザーインターフェースを用いて行うとしてもよい。また、サーバ２によって配信要求を発行するコマンドが所定時間経過毎に実行され、要求処理部７は、この発行された配信要求１３を受け付けるとしてもよい。
【００６４】
例えば、配信要求１３として「% multicast -t 3000 ウイルス駆除.0102513」が発行される。この配信要求１３において「multicast」は命令名であり、「-t 3000」は3000秒後に配信を行う指示を表し、「ウイルス駆除」は配信されるパッチの名前を表す。「.」以下の「0102513」はパッチのバージョン情報を表す。すなわち、この「ウイルス駆除.0102513」は、配信要求１３で指定されたパッチ識別情報１４である。
【００６５】
ステップＳ２において、要求処理部７は、配信要求１３に基づいて、オプション解析と送信対象のパッチを示すパッチ識別情報１４の認識とを実行する。
【００６６】
ステップＳ３において、要求処理部７は、ソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４に対応するソフトウェア識別情報が登録されているか判断する。登録の有無に基づいて、配信要求１３で指定されたパッチ識別情報１４の示すパッチがこのサーバ２による配信対象のパッチか否か判断される。
【００６７】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されていない場合、ステップＳ４において、要求処理部７は、配信要求元にエラーを返し、処理を終了する。
【００６８】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されている場合、ステップＳ５において、パッチ識別情報１４に対応するソフトウェア識別情報１５を取得し、パッチ識別情報１４とソフトウェア識別情報１５とを配信済み確認部８に提供する。
【００６９】
ステップＳ６において、配信済み確認部８は、要求処理部７からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、配信情報１１ｂを参照し、配信要求１３で指定されたパッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報より新しいか判断する。パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報よりも新しい場合、未配信と判断される。一方、パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報と同一又は古い場合、配信済みと判断される。
【００７０】
パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報と同一又は古い場合、ステップＳ７において、配信済み確認部８は、配信要求元にエラーを返し、処理を終了する。
【００７１】
一方、パッチ識別情報１４の示すバージョン情報が配信情報１１ｂに登録されているパッチ識別情報の示すバージョン情報より新しい場合、ステップＳ８において、配信済み確認部８は、パッチ識別情報１４とソフトウェア識別情報１５とをグループ管理部９に提供する。
【００７２】
また、ステップＳ９において、配信済み確認部８は、パッチ識別情報１４を配信情報１１ｂに登録する。
【００７３】
ステップＳ１０において、グループ管理部９は、配信済み確認部８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、グループ情報１１ｃを参照し、ソフトウェア識別情報１５に対応するマルチキャストアドレス情報１８を取得する。ソフトウェア識別情報１５に対応するマルチキャストアドレス情報１８は、マルチキャスト配信先となる。マルチキャストグループとしてローカルサイト内のみを対象とする場合には、224.0.0.1から224.0.0.255までのアドレスがマルチキャストアドレス情報で指定される必要があり、インターネット全体をマルチキャストグループとする場合には224.0.1.0から238.255.255.255までのアドレスがマルチキャストアドレス情報で指定される必要がある。
【００７４】
ステップＳ１１において、グループ管理部９は、パッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を配信部１０に提供する。
【００７５】
ステップＳ１２において、配信部１０は、グループ管理部９からパッチ識別情報１４とソフトウェア識別情報１５とマルチキャストアドレス情報１８を受け付けると、パッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【００７６】
ステップＳ１３において、配信部１０は、パッチ１２とパッチ識別情報１４及びソフトウェア識別情報１５について、マルチキャストアドレス情報１８の示すマルチキャストグループに対するマルチキャスト配信を実行する。なお、配信部１０は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５以外のコンテンツについて、マルチキャストアドレス情報１８の示すマルチキャストグループに対するマルチキャスト配信を実行してもよい。
【００７７】
なお、上記ステップＳ９は、上記ステップＳ６の後であればいずれの時点で実行してもよい。
【００７８】
図９は、本実施の形態に係るクライアント３１の具体的構成例を示すブロック図である。なお、他のクライアント３２〜３ｎの構成例についても同様である。
【００７９】
クライアント３１は、サーバ２からネットワーク４経由でパッチ５、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信し、他のクライアント３２〜３ｎのいずれかとの間でコンテンツの送信又は受信を行う。なお、本実施の形態では、クライアント３１とクライアント３２とが同一のマルチキャストグループに属する場合について説明する。
【００８０】
クライアント３１は、記録媒体１９に記録されているプログラム１９ａを読み込み、実行することにより、マルチキャスト受信部２０、受信確認部２１、バージョン管理部２２、パッチ処理部２３、通信先取得部２４、通信許可部２５、認証部２６、バージョン比較部２７、コンテンツ通信部２８、P2P通信部４１としての機能を実現する。クライアント３１は、記録部２９を具備する。なお、本実施の形態では、記録部２９はクライアント３１に内蔵されているが、例えばクライアント３１に外付けの記録装置であってもよい。また、クライアント３１はネットワーク４経由で記録部２９をアクセスするとしてもよい。
【００８１】
記録部２９は、バージョン管理情報２９ａ、パッチ情報２９ｂ、ソフトウェア管理情報２９ｃ、通信許可情報２９ｄ、グループ管理情報２９ｅを記録する。
【００８２】
バージョン管理情報２９ａは、図１０に示すように、クライアント３１に保持されているソフトウェアのソフトウェア識別情報と、クライアント３１に受信されそのソフトウェアの修正処理に用いられたパッチのパッチ識別情報とを対応付けた情報である。図１０の例では、ソフトウェア識別情報１５とパッチ識別情報１６とが対応付けされている。
【００８３】
パッチ情報２９ｂは、クライアント３１に保持されているパッチとパッチ識別情報とを関係付けた情報であり、例えば上記図６と同様の形式で情報が記録される。
【００８４】
ソフトウェア管理情報２９ｃは、図１１に示すように、クライアント３１に保持されているソフトウェアとソフトウェア識別情報とを関係付けた情報である。この図１１の例では、ソフトウェア識別情報１５とソフトウェア４０とが対応付けされている。
【００８５】
通信許可情報２９ｄは、クライアント３１が他のクライアントとの間でP2P通信を行った場合に、当該クライアント３１がどのクライアントと通信を行い、どのようなコンテンツを送受信したかを表すログなどを含む情報である。
【００８６】
本実施の形態では、通信許可情報２９ｄは、クライアント間通信の通信先として決定された通信先クライアントの識別情報と通信開始時間と通信終了時間を含むとする。この通信許可情報２９ｄを参照することにより、クライアント３１が他のクライアント３２〜３ｎとの間で通信中か否かを判断可能である。
【００８７】
グループ管理情報２９ｅは、図１２に示すように、クライアント３１に保持されているソフトウェア識別情報と、このソフトウェア識別情報の示すソフトウェアに関するパッチを送信するサーバのアドレス情報と、このソフトウェア識別情報の示すソフトウェアから定まるクライアント３１の属するマルチキャストグループのグループ識別情報とを関係付けた情報である。
【００８８】
この図１２では、ソフトウェア識別情報１５とサーバアドレス情報４２とグループ識別情報４３とが対応付けされている。
【００８９】
マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、マルチキャスト配信においてクライアント３１の属するマルチキャストグループを示すグループ識別情報４３とこのマルチキャスト配信を行うサーバ２のアドレス情報４２とを取得する。
【００９０】
マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、グループ識別情報４３の示すマルチキャストグループに属するために、サーバアドレス情報４２の示すサーバ２にIGMP Joinメッセージを送信する。
【００９１】
クライアント３１からサーバ２までの途中経路にあるネットワーク４上のルータ（図示せず）は、IGMP Joinメッセージを理解する。そして、ルータは、IGMP Joinメッセージを受信したポートに接続されているネットワークが、このルータ内に保持されておりマルチキャストグループを登録するテーブルに登録されていなければ、そのIGMP Joinメッセージを受信したポートに接続されているネットワークの情報をテーブル内に登録する。
【００９２】
これにより，サーバ２とクライアント３１との間でマルチキャスト配信を実行するための通信経路が確保される。
【００９３】
サーバ２からマルチキャストグループに対して送信されたコンテンツは、この処理によって確保された経路を通る。ルータは、受信したコンテンツをコピーして各登録ポートから送信する。これにより、同一のマルチキャストグループに属するクライアントに向けて、コンテンツのマルチキャスト配信が実行される。なお、マルチキャスト配信ではＵＤＰ（User Datagram Protocol）により通信が行われる。
【００９４】
マルチキャスト受信部２０は、サーバ２からマルチキャスト配信を用いて送信されたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信し、受信確認部２１に提供する。
【００９５】
受信確認部２１は、マルチキャスト受信部２０から受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５の完全性を判断する。
【００９６】
パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５が不完全の場合、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄する。
【００９７】
一方、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５が完全な場合、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５をバージョン管理部２２に提供する。
【００９８】
バージョン管理部２２は、受信確認部２１からパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を受け付けた場合、記録部２９に記録されているバージョン管理情報２９ａを参照する。
【００９９】
バージョン管理部２２は、サーバ２から受信したパッチ識別情報１４に含まれているパッチ名と同じパッチ名を含み、パッチ識別情報１４に含まれているバージョン情報より新しい又は同じバージョン情報を含むパッチ識別情報がバージョン管理情報２９ａに登録されているか判断する。すなわち、バージョン管理部２２は、サーバ２から受信したパッチ１２より新しい又は同じバージョンのパッチを受信済みか否か判断する。
【０１００】
パッチ識別情報１４より新しいバージョン情報又は同じバージョン情報のパッチ識別情報がバージョン管理情報２９ａに登録されている場合、バージョン管理部２２は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄する。
【０１０１】
一方、パッチ識別情報１４に含まれているバージョン情報がバージョン管理情報２９ａに登録されているパッチ識別情報のバージョン情報よりも新しい場合、バージョン管理部２２は、パッチ識別情報１４の示すパッチ１２は未受信であると判断し、パッチ識別情報１４とソフトウェア識別情報１５とを対応付けてバージョン管理情報２９ａに登録し、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部２３に提供する。
【０１０２】
パッチ処理部２３は、バージョン管理部２２又はコンテンツ通信部２８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、パッチ情報２９ｂからパッチ識別情報１４に対応する最新バージョンのパッチ１２を取得し、ソフトウェア管理情報２９ｃからソフトウェア識別情報１５に対応するソフトウェア４０を取得し、パッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理部２９ｃに登録する。
【０１０３】
通信先決定サーバ４４は、各クライアント３１〜３ｎの起動時に、各クライアント３１〜３ｎの登録を行う。
【０１０４】
通信先決定サーバ４４は、各クライアント３１〜３ｎの保持するソフトウェアを示すソフトウェア識別情報を各クライアント３１〜３ｎから取得する。
【０１０５】
通信先決定サーバ４４は、各クライアント３１〜３ｎの中から共通のソフトウェアを保持するクライアントの中からP2P通信を行うクライアントを決定し、P2P通信を行うと決定された各クライアントに対して通信先を提供する。なお、本実施の形態では、通信を行うクライアントとしてとしてクライアント３１が決定され、このクライアント３１の通信先としてクライアント３２が決定された場合について説明する。
【０１０６】
また、通信先決定サーバ４４は、登録したクライアントから一定期間経過してもアクセスがない場合、このクライアントは停止しているものと判断し、登録を解除する。
【０１０７】
クライアント３１のP2P通信部４１は、他のクライアント３２〜３ｎとの間においてP2P通信を行い、各種コンテンツを送受信する。
【０１０８】
通信先取得部２４は、クライアント３１が起動した場合に、通信先決定サーバ４４への登録を行う。
【０１０９】
また、通信先取得部２４は、記録部２９に記録されているソフトウェア管理情報２９ｃを参照し、一定期間経過する度に、クライアント３１に保持されているソフトウェアのソフトウェア識別情報を通信先決定サーバ４４に提供する。
【０１１０】
通信先取得部２４は、通信先決定サーバ４４から通信先のクライアント３２の指定を受け付けた場合、通信先のクライアント３２の指定を通信許可部２５に提供する。
【０１１１】
通信許可部２５は、通信先取得部２４から通信先のクライアント３２の指定を受け付けた場合、P2P通信部４１経由で通信先のクライアント３２にアクセスし、通信先のクライアント３２が他のクライアント３３〜３ｎと通信中か否か判断する。
【０１１２】
通信先のクライアント３２が他のクライアントと通信中でない場合、通信許可部２５は、通信先のクライアント３２の指定を認証部２６に提供する。通信先のクライアント３２が通信中の場合には、処理を終了する。なお、通信先のクライアント３２が通信中の場合には、処理を待ち状態としてもよい。
【０１１３】
認証部２６は、通信許可部２５から通信先のクライアント３２の指定を受け付けた場合、P2P通信部４１経由で通信先のクライアント３２にアクセスし、相互認証を行う。
【０１１４】
認証が正当に行われた場合、認証部２６は、通信開始時間を記録部２９の通信許可情報２９ｄに登録するとともに、通信先のクライアント３２の指定をバージョン比較部２７に提供する。認証が正当に行われなかった場合、処理を中止する。
【０１１５】
バージョン比較部２７は、認証部２６から通信先のクライアント３２の指定を受け付けた場合、記録部２９に記録されているバージョン管理情報２９ａを参照するとともに、P2P通信部４１経由で通信先のクライアント３２にアクセスしてクライアント３２のバージョン管理情報２９ａを取得する。これにより、比較対象の２つのバージョン管理情報２９ａが取得される。
【０１１６】
そして、バージョン比較部２７は、クライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを比較し、比較結果と通信先のクライアント３２の指定とをコンテンツ通信部２８に提供する。
【０１１７】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも新しい場合、コンテンツ通信部２８は、保持するパッチ１２とパッチ識別情報１４とソフトウェア識別情報１５とをP2P通信部４１経由で通信先のクライアント３２に提供する。
【０１１８】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも古い場合、コンテンツ通信部２８は、P2P通信部４１経由で通信先のクライアント３２から通信先のクライアント３２の保持するパッチとパッチ識別情報とソフトウェア識別情報とを受け付ける。そして、コンテンツ通信部２８は、通信先のクライアント３２から受け付けたパッチとパッチ識別情報とソフトウェア識別情報とに基づいてバージョン管理情報２９ａ、パッチ情報２９ｂへの登録を行い、通信先のクライアント３２から受け付けたパッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部２３に提供する。
【０１１９】
また、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１２０】
図１３は、本実施の形態に係るクライアント３１がサーバ２からマルチキャスト配信されたコンテンツを受信した場合の処理の一例を示すフローチャートである。
【０１２１】
ステップＴ１において、マルチキャスト受信部２０は、記録部２９に記録されているグループ管理情報２９ｅを参照し、マルチキャスト配信においてクライアント３１の属するマルチキャストグループを示すグループ識別情報４３とこのマルチキャストグループに対してマルチキャスト配信を実行するサーバ２のアドレス情報４２とを認識する。
【０１２２】
ステップＴ２において、マルチキャスト受信部２０は、グループ識別情報４３の示すマルチキャストグループに属するために、アドレス情報４２の示すサーバ２にIGMP Joinメッセージを送信する。
【０１２３】
ステップＴ３において、マルチキャスト受信部２０は、サーバ２からマルチキャスト配信を用いて送信されたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを受信する。
【０１２４】
ステップＴ４において、受信確認部２１は、マルチキャスト受信部２０から受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５の完全性を判断する。
【０１２５】
受信確認部２１による判断結果が不完全を示す場合、ステップＴ５において、受信確認部２１は、受け付けたパッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄し、処理を終了する。
【０１２６】
一方、受信確認部２１による判断結果が完全を示す場合、ステップＴ６において、バージョン管理部２２は、記録部２９に記録されているバージョン管理情報２９ａを参照する。
【０１２７】
ステップＴ７において、バージョン管理部２２は、サーバ２から受信したパッチ１２のバージョンが新しいか判断する。
【０１２８】
サーバ２から受信したパッチ１２のバージョンが新しくない場合、ステップＴ８において、バージョン管理部２２は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５を破棄し、処理を終了する。
【０１２９】
一方、サーバ２から受信したパッチ１２のバージョンが新しい場合、ステップＴ９において、バージョン管理部２２は、パッチ識別情報１４とソフトウェア識別情報１５とを対応付けてバージョン管理情報２９ａに登録するとともに、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録する。
【０１３０】
ステップＴ１０において、パッチ処理部２３は、最新バージョンのパッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０１３１】
図１４及び図１５は、本実施の形態に係るクライアント３１と他のクライアント３２によってP2P通信によりコンテンツを送受信する処理の一例を示すフローチャートである。
【０１３２】
ステップＵ１において、通信先取得部２４は、クライアント３１が起動した場合に、通信先決定サーバ４４への登録を行う。
【０１３３】
ステップＵ２において、通信先取得部２４は、一定時間経過したか判断する。
【０１３４】
ステップＵ３において、通信先取得部２４は、一定時間経過した場合、通信先決定サーバ４４にアクセスし、例えばソフトウェア管理情報２９ｃなどの記録部２９の情報を提供する。一定時間経過前の場合、待ち状態となる。
【０１３５】
ステップＵ４において、通信先取得部２４は、通信先決定サーバ４４から通信先のクライアント３２の指定を受け付ける。
【０１３６】
ステップＵ５において、通信許可部２５は、P2P通信部４１経由で通信先のクライアント３２にアクセスし、通信先のクライアント３２が他のクライアント３３〜３ｎと通信中か否か判断する。
【０１３７】
通信先のクライアント３２が通信中の場合、通信許可部２５は、処理を終了するか待ち状態とする。
【０１３８】
通信先のクライアント３２が通信中でない場合、ステップＵ６において、認証部２６は、P2P通信部４１経由で通信先のクライアント３２にアクセスし、相互認証を行う。
【０１３９】
認証が正当に行われなかった場合、認証部２６は、処理を中止する。
【０１４０】
認証が正当に行われた場合、ステップＵ７において、認証部２６は、通信開始時間を記録部２９の通信許可情報２９ｄに登録する。
【０１４１】
ステップＵ８において、バージョン比較部２７は、記録部２９に記録されているバージョン管理情報２９ａを参照するとともに、P2P通信部４１経由で通信先のクライアント３２にアクセスし、比較対象となるクライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを取得する。
【０１４２】
ステップＵ９において、バージョン比較部２７は、クライアント３１のバージョン管理情報２９ａと通信先のクライアント３２のバージョン管理情報２９ａとを比較する。
【０１４３】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも新しい場合、ステップＵ１０において、コンテンツ通信部２８は、パッチ１２とパッチ識別情報１４とソフトウェア識別情報１５とをP2P通信部４１経由で通信先のクライアント３２に提供する。
【０１４４】
ステップＵ１１において、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１４５】
クライアント３１の保持するパッチ１２の方が通信先のクライアント３２の保持するパッチよりも古い場合、ステップＵ１２において、コンテンツ通信部２８は、通信先のクライアント３２の保持するパッチとパッチ識別情報とソフトウェア識別情報とをP2P通信部４１経由で通信先のクライアント３２から受け付け、記録部２９に記録する。
【０１４６】
ステップＵ１３において、パッチ処理部２３は、最新バージョンのパッチを用いてソフトウェアを修正し、修正前のソフトウェアに代えて修正後のソフトウェアをソフトウェア管理情報２９ｃに登録する。
【０１４７】
ステップＵ１４において、コンテンツ通信部２８は、記録部２９に記録されている通信許可情報２９ｄに通信終了時間を登録する。
【０１４８】
なお、ステップＵ１３，１４は、逆の順序で実行してもよく、並列に実行してもよい。
【０１４９】
図１６は、通信システム１の連携動作の一例を示すシーケンス図である。この図１６では、クライアント間のP2P通信の通信先を決定する場合に、通信先決定サーバ４４が利用される。
【０１５０】
また、この図１６では、サーバ２からクライアント３１，３２に対してパッチ等のコンテンツが送信され、その後クライアント３１からクライアント３２に対してパッチ等のコンテンツが送信される場合を例として示している。
【０１５１】
通信システム１によるコンテンツの送信は、マルチキャスト配信を用いた送信が行われるマルチキャスト配信段階と、クライアント間でP2P通信を用いた送信が行われるクライアント間通信段階とからなる。
【０１５２】
まず、上記図１６におけるマルチキャスト配信段階について説明する。
【０１５３】
サーバ２の要求処理部７は、配信要求１３に対するオプション解析と配信対象のパッチを示すパッチ識別情報１４の認識とを実行する。
【０１５４】
また、要求処理部７は、ソフトウェア情報１１ａを参照し、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２が自サーバ２の配信対象かを確認する。
【０１５５】
配信要求１３で指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されておらず、自サーバ２による配信対象でない場合、要求処理部７は、配信要求１３に対してエラーを返し、処理を終了する。
【０１５６】
配信済み確認部８は、配信情報１１ｂを参照し、配信要求１３で指定されたパッチ識別情報１４が登録されているか判断する。
【０１５７】
配信情報１１ｂにパッチ識別情報１４が登録されている場合、配信済み確認部８は、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２は配信済みであると判断し、配信要求元にエラーを返し、処理を終了する。
【０１５８】
一方、配信情報１１ｂにパッチ識別情報１４が登録されていない場合、配信済み確認部８は、配信要求１３で指定されたパッチ識別情報１４の示すパッチ１２は未配信であると判断し、グループ管理部９に処理を移す。
【０１５９】
グループ管理部９は、グループ情報１１ｃを参照し、配信対象のパッチ１２によって修正されるソフトウェアを保持するクライアント３１，３２の属するマルチキャストグループを示すマルチキャストアドレス情報１８を取得する。
【０１６０】
配信部１０は、パッチ情報１１ｄを参照し、配信要求１３で指定されたパッチ識別情報１４に対応するパッチ１２を取得する。
【０１６１】
そして、配信部１０は、パッチ１２、パッチ識別情報１４、ソフトウェア識別情報１５等のコンテンツを、マルチキャストアドレス情報１８の示すマルチキャストグループに属するクライアント３１，３２に対して、マルチキャスト配信を用いて送信する。
【０１６２】
上記のようなマルチキャスト配信の実行前において、クライアント３１、３２のマルチキャスト受信部２０は、マルチキャスト配信に対応するための前処理を実行する。
【０１６３】
マルチキャスト配信の実行後、クライアント３１，３２のマルチキャスト受信部２０は、サーバ２から送信されたコンテンツを受信する。
【０１６４】
クライアント３１，３２の受信確認部２１は、受信したコンテンツの完全性を確認する。
【０１６５】
この図１６の例では、サーバ２からクライアント３１に受信されたコンテンツは完全であったが、サーバ２からクライアント３２に受信されたコンテンツは不完全であったとする。
【０１６６】
クライアント３１のバージョン管理部２２は、バージョン管理情報２９ａを参照し、受信したコンテンツのバージョンとバージョン管理情報２９ａに登録されているバージョンとを比較し、受信したコンテンツが新バージョンか判断する。
【０１６７】
クライアント３１のバージョン管理部２２は、受信したコンテンツが新バージョンでない場合、処理をマルチキャスト配信の待ち受け状態に戻す。
【０１６８】
バージョン管理部２２は、受信したコンテンツが新バージョンの場合、受信したコンテンツを記録部２９に登録する。
【０１６９】
パッチ処理部２３は、受信したコンテンツに基づいて、ソフトウェアの修正を行う。
【０１７０】
一方、クライアント３２の受信確認部２１は、受信したコンテンツが不完全の場合には、受信したコンテンツを破棄する。
【０１７１】
次に、上記図１６におけるクライアント間通信段階について説明する。
【０１７２】
クライアント通信段階において、各クライアント３１，３２は、同一のマルチキャストグループに属する他のクライアントとの間でコンテンツを共有し、更新する。
【０１７３】
クライアント３１，３２間で共有されるコンテンツはサーバ２から各クライアント３１，３２にマルチキャスト配信を用いて送信されたコンテンツである。
【０１７４】
上記図１６において、クライアント３２では、サーバ２から受信したコンテンツが完全でないため、破棄されている。したがって、同じマルチキャストグループに属するクライアント３１，３２の中に、新バージョンのコンテンツを保持しているクライアント３１と保持していないクライアント３２とが混在している。
【０１７５】
クライアント間通信段階では、マルチキャスト配信により受信したコンテンツを保持するクライアント３１と保持しないクライアント３２との間でコンテンツが送受信される。
【０１７６】
クライアント３１，３２の通信先取得部２４は、起動した段階で通信先決定サーバ４４にアクセスする。
【０１７７】
通信先決定サーバ４４は、クライアント３１，３２からのアクセスに応じてクライアント３１，３２の登録を行う。
【０１７８】
その後、クライアント３１，３２の通信先取得部２４は、一定時間経過する毎に、通信先決定サーバ４４にアクセスして通信先のクライアントの指定（通信先情報）を要求し、通信先のクライアントの指定を取得する。
【０１７９】
通信先決定サーバ４４は、一定時間経過後においても通信先のクライアントの指定を要求しないクライアントについては停止していると判断し、登録されている情報を消去する。
【０１８０】
ここで、この図１６では、通信先決定サーバ４４は、クライアント３１からクライアント３２にコンテンツを提供することを決定したとする。クライアント３１の通信先取得部２４は、通信先決定サーバ４４に接続し、通信先のクライアント３２の指定を取得する。
【０１８１】
クライアント３１は、取得した通信先のクライアント３２の指定に基づいて、通信先のクライアント３２への接続を要求する。
【０１８２】
クライアント３１からクライアント３２への接続は、例えば次の処理にしたがって行われる。
【０１８３】
まず、クライアント３１の通信許可部２５は、P2P通信部４１を用いて、通信先のクライアント３２に接続要求を送信する。
【０１８４】
接続要求を受信した通信先のクライアント３２の通信許可部２５は、接続要求を受け付け、クライアント３２の記録部２９に記録されている通信許可情報２９ｄを参照し、通信先のクライアント３２が他のクライアント間で通信を行っていないか確認する。
【０１８５】
通信先のクライアント３２が通信を行っている場合、通信先のクライアント３２の通信許可部２５は、P2P通信部４１を用いて、接続拒否メッセージをクライアント３１に返す。
【０１８６】
通信先のクライアント３２が通信を行っていない場合、クライアント３１の認証部２６は、P2P通信部４１を用いて、通信先のクライアント３２の認証部２６と連携して相互に認証を行い、正当な通信相手であるか確認する。
【０１８７】
各クライアント３１，３２の認証部２６は、例えばグループ署名を用いて各クライアント３１，３２の属するグループを確認する。クライアント３１の認証部２６は、通信先のクライアント３２の所属するグループについても確認を行う。
【０１８８】
認証が正しく行われた場合、通信先のクライアント３２の認証部２６は、P2P通信部４１を用いて、通信先のクライアント３２の通信許可情報２９ｄに、クライアント３１の情報と通信開始時間を登録し、クライアント３１に接続確立の応答メッセージを送信する。
【０１８９】
クライアント３１の認証部２６は、応答メッセージを受け付けた場合に、通信先のクライアント３２の情報と通信開始時間をクライアント３１の通信許可情報２９ｄに登録する。
【０１９０】
接続が確立した場合、クライアント３１のバージョン比較部２７は、P2P通信部４１を用いて、通信先のクライアント３２のバージョン比較部２７と連携し、クライアント３１，３２に保持されているパッチのバージョン情報を確認する。
【０１９１】
例えば、クライアント３１のバージョン比較部２７は、クライアント３１のバージョン管理情報２９ａを通信先のクライアント３２のバージョン比較部２７に提供する。
【０１９２】
通信先のクライアント３２のバージョン比較部２７は、受け付けたクライアント３１のバージョン管理情報２９ａを、通信先のクライアント３２のバージョン管理情報２９ａと比較する。
【０１９３】
クライアント３１のバージョンの方が通信先のクライアント３２のバージョンより新しい場合、通信先のクライアント３２のバージョン比較部２７は、受信希望メッセージをクライアント３１に送信する。
【０１９４】
クライアント３１のバージョンの方が通信先のクライアント３２のバージョンより古い場合、通信先のクライアント３２のバージョン比較部２７は、送信希望メッセージをクライアント３１に送信する。
【０１９５】
バージョンが同じ場合には、通信先のクライアント３２のバージョン比較部２７は、同じバージョンである旨のメッセージをクライアント３１に送信する。
【０１９６】
通信先のクライアント３２からクライアント３１が受信希望メッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、記録部２９に記録されているパッチ、パッチ識別情報、ソフトウェア識別情報等のコンテンツを取得し、P2P通信部４１を用いて通信先のクライアント３２に送信し、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９７】
通信先のクライアント３２からクライアント３１が送信希望メッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、通信先のクライアント３２のコンテンツ通信部２８から提供されたコンテンツをクライアント３１の記録部２９に記録し、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９８】
通信先のクライアント３２からクライアント３１が同じバージョンである旨のメッセージを受信した場合、クライアント３１のコンテンツ通信部２８は、P2P通信を終了し、通信許可情報２９ｄに通信終了時間を登録する。
【０１９９】
上記クライアント３１，３２間で実行されるP2P通信では、TCP通信が利用されるため、データの完全性は保証される。
【０２００】
以上説明した本実施の形態に係る通信システム１では、まずマルチキャスト配信を用いてサーバ２からクライアント３１〜３ｎにコンテンツが送信される。
【０２０１】
これにより、サーバ２から送信される総データ量を削減でき，サービス提供者のサーバ能力増強に関する労力とコストを抑制できる。
【０２０２】
また、本実施の形態では、マルチキャスト配信を用いたサーバからクライアントへのコンテンツの送信において、全てのクライアントにコンテンツが正常に受信されなかった場合に、コンテンツを正常に受信したクライアントからコンテンツを正常に受信しなかったクライアントへコンテンツが送信され、コンテンツの配信が補完される。
【０２０３】
これにより、各クライアントは、確実にかつ迅速にコンテンツを取得できる。
【０２０４】
（第２の実施の形態）
本実施の形態では、上記第１の実施の形態の変形例について説明する。上記第１の実施の形態では、マルチキャスト配信を用いてサーバからクライアントにコンテンツが送信され、その後マルチキャスト配信を補完するためにクライアント間でP2P通信が行われる。
【０２０５】
しかしながら、本実施の形態では、マルチキャスト配信の代わりにエニーキャスト配信が用いられる。
【０２０６】
本実施の形態では、エニーキャスト配信を用いてサーバからコンテンツが提供されるクライアントが決定され、サーバからこの決定されたクライアントにコンテンツが提供される。そして、決定されたクライアントから他のクライアントにコンテンツが分配される。
【０２０７】
なお、本実施の形態では、クライアント間でのコンテンツの送受信には、上記第１の実施の形態と同様の手法にP2P通信が用いられるとする。
【０２０８】
エニーキャスト配信は、IPv6（Internet Protocol Version 6）で実装された機能である。エニーキャスト配信は、指定されたＤＮＳ（Domain Name System）サーバの中から最も負荷の軽いものを選び出すなどの用途に使用される。
【０２０９】
エニーキャスト配信では、サーバは、エニーキャストグループに属する複数のクライアントに対してエニーキャストリクエストを送信し、このエニーキャストリクエストの応答であるエニーキャストリプライを各クライアントから受信する。
【０２１０】
そして、サーバは、エニーキャストリプライに基づいて各クライアントの負荷レベルを認識する。
【０２１１】
図１７は、本実施の形態に係る通信システムによるエニーキャスト配信の状態の一例を示す図である。
【０２１２】
通信システム４５では、サーバ４６とクライアント４７１〜４７ｎと通信先決定サーバ４４がサブネットワーク４８経由で接続される。サブネットワーク４８に接続されるクライアント４７１〜４７ｎは、共通のネットワークアドレスによって表される。
【０２１３】
通信システム４５では、まず、サーバ４６からクライアント４７１〜４７ｎにエニーキャスト配信によってエニーキャストリクエストが送信される。次に、エニーキャストリクエストを受信したクライアント４７１〜４７ｎからサーバ４６にエニーキャストリプライが返信される。
【０２１４】
次に、サーバ４６において各クライアント４７１〜４７ｎから受信したエニーキャストリプライに基づいて負荷の軽いクライアントが決定される。この図１７の例では、クライアント４７１〜４７ｎのうちクライアント４７１の負荷が最も軽い場合を示している。
【０２１５】
そして、サーバ４６からこの決定されたクライアント４７１にパッチ５等を含むコンテンツが送信される。サーバ４６からクライアント４７１にコンテンツが送信される場合、このコンテンツに署名が付されるとしてもよい。
【０２１６】
なお、本実施の形態においては、クライアント４７１〜４７ｎの全てがエニーキャスト配信の対象であるエニーキャストグループに属するとして説明を行う。
【０２１７】
サブネットワーク４８は、同一のネットワークアドレス又はブロードキャストアドレスで表され、ルータ又はスイッチによって分断されていない通信網であり、無線・有線を問わない。このサブネットワーク４８を経由して、エニーキャストリクエスト、エニーキャストリプライ、コンテンツが送受信される。
【０２１８】
図１８は、本実施の形態に係る通信システム４５によるクライアント間通信の状態の一例を示す図である。
【０２１９】
サーバ４６からコンテンツを受信したクライアント４７１から他のクライアント４７２〜４７ｎにP2P通信を用いてコンテンツが送信される。このクライアント４７１〜４７ｎ間でのコンテンツの送受信は、上記第１の実施の形態の場合と同様の手法が適用でき、本実施の形態においては説明を省略する。
【０２２０】
図１９は、本実施の形態に係る通信システム４５のサーバ４６の具体的構成例を示すブロック図である。
【０２２１】
サーバ４６は、記録媒体４９に記録されているプログラム４９ａを読み込み、実行することにより、要求処理部５０、アドレス取得部５１、リクエスト送信部５２、リプライ受信部５３、配信先決定部５４、配信部５５としての機能を実現する。サーバ４６は、記録部５６を具備する。なお、本実施の形態では、記録部５６はサーバ４６に内蔵されているが、例えばサーバ４６に外付けの記録装置であってもよい。また、サーバ４６はサブネットワーク４８経由で記録部５６をアクセスするとしてもよい。
【０２２２】
記録部５６は、ソフトウェア情報１１ａ、アドレス管理情報５６ａ、リプライ管理情報５６ｂ、配信情報５６ｃ、パッチ情報１１ｄを記録する。
【０２２３】
記録部５６に記録されているソフトウェア情報１１ａとパッチ情報１１ｄは、上記第１の実施の形態の場合と同様であるため、説明を省略する。
【０２２４】
アドレス管理情報５６ａは、図２０に示すように、サーバ４６から配信されるパッチによって修正が行われるソフトウェアのソフトウェア識別情報と、このソフトウェアを保持するクライアントの属するエニーキャストグループを示すエニーキャストアドレス情報とを対応付けた情報である。例えば、このアドレス管理情報５６ａでは、「ウイルス駆除ソフトウェア」という内容のソフトウェア識別情報１５に、「3ffe: 2001::2」という内容のエニーキャストアドレス情報５７が対応付けされている。図２０のアドレス管理情報５６ａは、ソフトウェア識別情報１５で表されるウイルス駆除ソフトウェアは、エニーキャストアドレス情報５７で表されるエニーキャストグループに属するクライアントに具備されていることを表している。
【０２２５】
なお、本実施の形態においても、上記第１の実施の形態と同様の理由により、コンテンツに対して固有のエニーキャストアドレス情報を対応付けなくてもよい場合がある。
【０２２６】
リプライ管理情報５６ｂは、図２１に示すように、リプライ受信部５３によってクライアント４７１〜４７ｎから受信されたエニーキャストリプライ５８１〜５８ｎを、受信順序を認識可能な状態で保持する情報である。
【０２２７】
この図２１のリプライ管理情報５６ｂでは、クライアント４７１〜４７ｎの順序で、エニーキャストリプライ５８１〜５８ｎが受信された場合を示している。
【０２２８】
エニーキャストリプライ５８１〜５８ｎには、送信元のクライアント４７１〜４７ｎのアドレス情報５９１〜５９ｎが含まれる。
【０２２９】
配信情報５６ｃは、図２２に示すように、パッチ識別情報と、このパッチ識別情報の示すパッチを送信した送信先クライアントのアドレス情報とを対応付けた情報である。この図２２の例では、「ウイルス駆除.0102513」という内容のパッチ識別情報１４に、「3ffe: 2001::30」という内容のアドレス情報６０が対応付けされている。
【０２３０】
本実施の形態においては、パッチ識別情報とエニーキャストアドレス情報とが、ソフトウェア識別情報を経由して間接的に対応付けされている。
【０２３１】
要求処理部５０は、要求発行元から配信要求６１を受け付け、この配信要求６１によって指定されたパッチ識別情報１４を認識する。
【０２３２】
また、要求処理部５０は、記録部５６に記録されているソフトウェア情報１１ａを参照し、配信要求６１によって指定されたパッチ識別情報１４がソフトウェア情報１１ａに登録されているか判断する。
【０２３３】
パッチ識別情報１４がソフトウェア情報１１ａに登録されていない場合、要求処理部５０は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチではないと判断し、エラーを配信要求６１の発行元に返す。
【０２３４】
一方、パッチ識別情報１４がソフトウェア情報１１ａに登録されている場合、要求処理部５０は、ソフトウェア情報１１ａからパッチ識別情報１４に対応するソフトウェア識別情報１５を取得する。そして、要求処理部５０は、パッチ識別情報１４とソフトウェア識別情報１５とをアドレス取得部５１に提供する。
【０２３５】
アドレス取得部５１は、要求処理部５０からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、記録部５６に記録されているアドレス管理情報５６ａを参照する。
【０２３６】
また、アドレス取得部５１は、要求処理部５０から受け付けたソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されているか判断する。
【０２３７】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されていない場合、アドレス取得部５１は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチではないと判断し、エラーを配信要求６１の発行元に返す。
【０２３８】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されている場合、アドレス取得部５１は、配信要求６１で指定されたパッチ識別情報１４の示すパッチはこのサーバ４６によって配信されるパッチであると判断し、ソフトウェア識別情報１５に対応するエニーキャストアドレス情報５７を取得する。
【０２３９】
そして、アドレス取得部５１は、パッチ識別情報１４とソフトウェア識別情報１５とエニーキャストアドレス情報５７をリクエスト送信部５２に提供する。
【０２４０】
リクエスト送信部５２は、パッチ識別情報１４とソフトウェア識別情報１５とエニーキャストアドレス情報５７とをアドレス取得部５１から受け付けると、エニーキャストアドレス情報５７に基づいてエニーキャストアドレス配信におけるエニーキャストリクエストを送信する。このサーバ４６のリクエスト送信部５２から送信されるエニーキャストリクエストには、サーバ４６を示すアドレス情報が含まれている。
【０２４１】
リプライ受信部５３は、エニーキャストリクエストを受信した各クライアント４７１〜４７ｎからエニーキャストリプライ５８１〜５８ｎを受信する。
【０２４２】
そして、リプライ受信部５３は、エニーキャストリプライ５８１〜５８ｎを受信順序に応じてリプライ管理情報５６ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とを配信先決定部５４に提供する。
【０２４３】
配信先決定部５４は、パッチ識別情報１４とソフトウェア識別情報１５とを受け付けると、リプライ管理情報５６ｂを参照する。
【０２４４】
配信先決定部５４は、リプライ管理情報５６ｂに登録されているエニーキャストリプライ５８１〜５８ｎのうち最先に受信したエニーキャストリプライ５８１を取得し、この再選に受信したエニーキャストリプライ５８１に含まれているアドレス情報５９１を取得する。
【０２４５】
そして、配信先決定部５４は、記録部５６に記録されている配信情報５６ｃを参照し、パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されているか判断する。
【０２４６】
パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されていない場合、配信先決定部５４は、取得したアドレス情報５９１の示すクライアントを配信先と決定し、アドレス情報５９１とパッチ識別情報１４とソフトウェア識別情報１５とを配信部５５に提供する。すなわち、パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されていない場合には、このパッチ識別情報１４の示すパッチはアドレス情報５９１の示すクライアント４７１に未送信であると判断される。
【０２４７】
一方、パッチ識別情報１４とアドレス情報５９１とを関係付けた情報が配信情報５６ｃに登録されている場合、配信先決定部５４は、このパッチ識別情報１４の示すパッチはアドレス情報５９１の示すクライアント４７１に送信済みであると判断する。すると、配信先決定部５４は、リプライ管理情報５６ｂを参照し、先に取得したエニーキャストリプライ５８１の次に受信したエニーキャストリプライ５８２を取得し、この新たに取得したエニーキャストリプライ５８２について上記のエニーキャストリプライ５８１に対する処理と同様の処理を実行する。これにより、パッチ識別情報１４の示すパッチを未送信のクライアントの中から、最先にエニーキャストリプライを返したクライアントが配信先として決定される。
【０２４８】
なお、本実施の形態では、配信先決定部５４は、アドレス情報５９１の示すクライアント４７１を配信先として決定したとする。
【０２４９】
配信部５５は、配信先決定部５４からパッチ識別情報１４とソフトウェア識別情報１５とアドレス情報５９１とを受け付けた場合、まず、アドレス情報５９１の示すクライアント４７１とのバージョンの比較を行うために、クライアント４７１に対して、パッチ識別情報１４を送信する。
【０２５０】
クライアント４７１は、サーバ４６から受信したパッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含み、このクライアント４７１に登録されているパッチ識別情報を検索する。
【０２５１】
そして、クライアント４７１は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報に含まれているバージョン情報とを比較する。
【０２５２】
受信したパッチ識別情報１４に含まれているバージョン情報の方が新しい場合、クライアント４７１は、コンテンツ送信要求をサーバ４７に返す。
【０２５３】
受信したパッチ識別情報１４に含まれているバージョン情報の方が新しくない場合、クライアント４７１は、中止要求をサーバ４７に返す。
【０２５４】
配信部５５は、配信先決定部５４によって決定されたアドレス情報５９１の示すクライアント４７１から中止要求を受信した場合、処理を終了する。
【０２５５】
一方、配信部５５は、クライアント４７１からコンテンツ送信要求を受信した場合、記録部５６に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【０２５６】
配信部１０は、決定されたアドレス情報５９１の示すクライアント４７１に対して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを送信する。
【０２５７】
そして、配信部１０は、送信されたパッチ１２を示すパッチ識別情報１４と決定されたアドレス情報５９１とを対応付けて配信情報５６ｃに登録する。
【０２５８】
図２３及び図２４は、本実施の形態に係るサーバ４６の動作の一例を示すフローチャートである。
【０２５９】
ステップＶ１において、要求処理部５０は、配信要求６１を受け付ける。
【０２６０】
例えば、配信要求６１として「% anycastsend -t now ウイルス駆除.0102513」が発行される。この配信要求６１において「anycastsend」は命令名であり、「-t now」は要求発行時に配信を行う指示を表し、「ウイルス駆除」は配信されるパッチの名前を表す。「.」以下の「0102513」はパッチのバージョン情報を表す。すなわち、この「ウイルス駆除.0102513」は、配信要求６１によって指定されたパッチ識別情報１４である。
【０２６１】
ステップＶ２において、要求処理部５０は、配信要求６１に基づいて、オプション解析と配信対象のパッチ識別情報１４の認識とを実行する。
【０２６２】
ステップＶ３において、要求処理部５０は、ソフトウェア情報１１ａを参照し、パッチ識別情報１４に対応するソフトウェア識別情報が登録されているか判断する。
【０２６３】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されていない場合、ステップＶ４において、要求処理部５０は、配信要求元にエラーを返し、処理を終了する。
【０２６４】
パッチ識別情報１４に対応するソフトウェア識別情報がソフトウェア情報１１ａに登録されている場合、ステップＶ５において、要求処理部５０は、パッチ識別情報１４に対応するソフトウェア識別情報１５を取得し、パッチ識別情報１４とソフトウェア識別情報１５とをアドレス取得部５１に提供する。
【０２６５】
ステップＶ６において、アドレス取得部５１は、アドレス管理情報５６ａを参照する。
【０２６６】
ステップＶ７において、アドレス取得部５１は、要求処理部５０から受け付けたソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されているか判断する。
【０２６７】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されていない場合、ステップＶ８において、アドレス取得部５１は、エラーを配信要求６１の発行元に返す。
【０２６８】
ソフトウェア識別情報１５に対応するエニーキャストアドレス情報がアドレス管理情報５６ａに登録されている場合、ステップＶ９において、アドレス取得部５１は、ソフトウェア識別情報１５に対応するエニーキャストアドレス情報５７を取得する。
【０２６９】
ステップＶ１０において、リクエスト送信部５２は、エニーキャストアドレス情報５７に基づいてエニーキャストアドレス配信におけるエニーキャストリクエストを送信する。
【０２７０】
ステップＶ１１において、リプライ受信部５３は、エニーキャストリクエストを受信した各クライアント４７１〜４７ｎからエニーキャストリプライ５８１〜５８ｎを受信する。
【０２７１】
ステップＶ１２において、リプライ受信部５３は、エニーキャストリプライ５８１〜５８ｎを受信順序に応じてリプライ管理情報５６ｂに登録する。
【０２７２】
ステップＶ１３において、配信先決定部５４は、リプライ管理情報５６ｂに登録されているエニーキャストリプライ５８１〜５８ｎのうち最先に受信したエニーキャストリプライ５８１を取得し、最先に受信したエニーキャストリプライ５８１に含まれているアドレス情報５９１を取得する。
【０２７３】
ステップＶ１４において、配信先決定部５４は、記録部５６に記録されている配信情報５６ｃを参照し、配信要求６１で指定されたパッチ識別情報１４と取得したアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されているか、すなわちアドレス情報５９１の示すクライアント４７１にパッチ識別情報１４の示すパッチを配信済みか判断する。
【０２７４】
パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されていない、すなわち未配信の場合、ステップＶ１５において、配信先決定部５４は、取得したアドレス情報５９１の示すクライアントを配信先と決定する。
【０２７５】
パッチ識別情報１４とアドレス情報５９１とを対応付けた情報が配信情報５６ｃに登録されている場合、ステップＶ１６において、配信先決定部５４は、リプライ管理情報５６ｂを参照し、現在扱っているエニーキャストリプライの次に受信したエニーキャストリプライを取得し、この次のエニーキャストリプライに含まれているアドレス情報を取得する。そして、上記ステップＶ１４の処理を繰り返す。
【０２７６】
なお、本実施の形態では、アドレス情報５９１の示すクライアント４７１が配信先として決定されたとする。
【０２７７】
ステップＶ１７において、配信部５５は、クライアント４７１側でバージョンの比較を行うために、決定されたアドレス情報５９１の示すクライアント４７１に対して、パッチ識別情報１４を送信する。
【０２７８】
ステップＶ１８において、配信部５５は、決定されたアドレス情報５９１の示すクライアント４７１からコンテンツ送信要求又は中止要求を受信する。
【０２７９】
クライアント４７１から中止要求を受信した場合、配信部５５は、処理を終了する。
【０２８０】
一方、クライアント４７１からコンテンツ送信要求を受信した場合、ステップＶ１９において、配信部５５は、記録部５６に登録されているパッチ情報１１ｄを参照し、パッチ識別情報１４に対応するパッチ１２を取得する。
【０２８１】
ステップＶ２０において、配信部５５は、決定されたアドレス情報５９１の示すクライアントに対して、パッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを送信する。
【０２８２】
ステップＶ２１において、配信部５５は、送信されたパッチ１２を示すパッチ識別情報１４と決定されたアドレス情報５９１とを対応付けて配信情報５６ｃに登録する。
【０２８３】
なお、ステップＶ２１は、ステップＶ１８においてコンテンツ送信要求を受信した後であれば、いずれの時点で実行されてもよい。
【０２８４】
図２５は、本実施の形態に係るクライアント４７１の具体的構成例を示すブロック図である。なお、他のクライアント４７２〜４７ｎの構成例についても同様である。
【０２８５】
クライアント４７１は、記録媒体６２に記録されているプログラム６２ａを読み込み、実行することにより、リクエスト受信部６３、リプライ送信部６４、バージョン管理部６５、コンテンツ受信部６６、パッチ処理部６７、通信先取得部２４、通信許可部２５、認証部２６、バージョン比較部２７、コンテンツ通信部２８、P2P通信部４１としての機能を実現する。クライアント４７１は、記録部６８を具備する。なお、本実施の形態では、記録部６８はクライアント４７１に内蔵されているが、例えばクライアント４７１に外付けの記録装置であってもよい。また、クライアント４７１はサブネットワーク４８経由で記録部６８をアクセスするとしてもよい。
【０２８６】
記録部６８は、バージョン管理情報６８ａ、パッチ情報２９ｂ、ソフトウェア管理情報２９ｃ、通信許可情報２９ｄを記録する。
【０２８７】
バージョン管理情報２９ａには、図２６に示すように、クライアント４７１に受信されこのクライアント４７１に保持されているソフトウェアの修正処理に用いられたパッチのパッチ識別情報が登録されている。
【０２８８】
図２６の例では、「ウイルス駆除.0100001」という内容のパッチ識別情報１６が登録されている。
【０２８９】
リクエスト受信部６３は、サーバ４６からエニーキャストリクエストを受信すると、この受信したエニーキャストリクエストをリプライ送信部６４に提供する。
【０２９０】
リプライ送信部６４は、リクエスト受信部６３からエニーキャストリクエストを受け付けると、エニーキャストリクエストに含まれているサーバ４６のアドレス情報を取得する。
【０２９１】
そして、リプライ送信部６４は、取得したサーバ４６のアドレス情報に基づいて、このクライアント４７１のアドレス情報を含むエニーキャストリプライをサーバ４６に送信する。
【０２９２】
バージョン管理部６５は、サーバ４６からパッチ識別情報１４を受信すると、バージョン管理情報６８ａを参照する。
【０２９３】
バージョン管理部６５は、バージョン管理情報６８ａの中から、受信したパッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含むパッチ識別情報１６を検索する。
【０２９４】
そして、バージョン管理部６５は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報１６に含まれているバージョン情報とを比較する。
【０２９５】
バージョン管理部６５は、受信したバージョン情報の方が検索したバージョン情報よりも新しい場合、コンテンツ送信要求をサーバ４６に返す。
【０２９６】
一方、バージョン管理部６５は、受信したバージョン情報が検索したバージョン情報よりも新しくない場合、中止要求をサーバ４６に返す。
【０２９７】
コンテンツ受信部６６は、サーバ４６に対してコンテンツ送信要求を返した場合に、サーバ４６からパッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを受信する。
【０２９８】
そして、コンテンツ受信部６６は、パッチ識別情報１４をバージョン管理情報６８ａに登録し、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録し、パッチ識別情報１４とソフトウェア識別情報１５とをパッチ処理部６７に提供する。
【０２９９】
パッチ処理部６７は、コンテンツ受信部６６又はコンテンツ通信部２８からパッチ識別情報１４とソフトウェア識別情報１５とを受け付けた場合、パッチ情報２９ｂからパッチ識別情報１４に対応する最新バージョンのパッチ１２を取得し、ソフトウェア管理情報２９ｃからソフトウェア識別情報１５に対応するソフトウェア４０を取得し、パッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０３００】
図２７及び図２８は、本実施の形態に係るクライアント４７１がサーバ４６からコンテンツを受信する処理の一例を示すフローチャートである。
【０３０１】
ステップＷ１において、リクエスト受信部６３は、サーバ４６から送信されたエニーキャストリクエストを受信する。
【０３０２】
ステップＷ２において、リプライ送信部６４は、エニーキャストリクエストに含まれているサーバ４６のアドレス情報を取得する。
【０３０３】
ステップＷ３において、リプライ送信部６４は、取得したサーバ４６のアドレス情報に基づいて、このクライアント４７１のアドレス情報５９１を含むエニーキャストリプライ５８１をサーバ４６に送信する。
【０３０４】
ステップＷ４において、バージョン管理部６５は、サーバ４６からパッチ識別情報１４を受信する。
【０３０５】
ステップＷ５において、バージョン管理部６５は、バージョン管理情報６８ａを参照する。
【０３０６】
ステップＷ６において、バージョン管理部６５は、バージョン管理情報６８ａの中から、パッチ識別情報１４に含まれているパッチ名と同一のパッチ名を含むパッチ識別情報１６を検索する。
【０３０７】
ステップＷ７において、バージョン管理部６５は、受信したパッチ識別情報１４に含まれているバージョン情報と検索されたパッチ識別情報１６に含まれているバージョン情報とを比較する。
【０３０８】
受信したバージョン情報の方が検索したバージョン情報よりも新しい場合、ステップＷ８において、バージョン管理部６５は、コンテンツ送信要求をサーバ４６に返す。
【０３０９】
一方、受信したバージョン情報が検索したバージョン情報よりも新しくない場合、ステップＷ９において、バージョン管理部６５は、中止要求をサーバ４６に返す。この場合、処理は終了となる。
【０３１０】
サーバ４６に対してコンテンツ送信要求を返した場合、ステップＷ１０において、コンテンツ受信部６６は、サーバ４６からパッチ識別情報１４、ソフトウェア識別情報１５、パッチ１２等のコンテンツを受信する。
【０３１１】
ステップＷ１１において、コンテンツ受信部６６は、パッチ識別情報１４をバージョン管理情報６８ａに登録するとともに、パッチ１２とパッチ識別情報１４とを対応付けてパッチ情報２９ｂに登録する。
【０３１２】
ステップＷ１２において、パッチ処理部６７は、最新バージョンのパッチ１２を用いてソフトウェア４０を修正し、修正前のソフトウェア４０に代えて修正後のソフトウェア４０をソフトウェア管理情報２９ｃに登録する。
【０３１３】
以下に、本実施の形態に係る通信システム４５の連携動作について説明する。
【０３１４】
図２９は、通信システム４５の連携動作の一例を示すシーケンス図である。
【０３１５】
サーバ４６は、クライアント４７１〜４７ｎに対してエニーキャストリクエストを送信する。
【０３１６】
各クライアント４７１〜４７ｎは、サーバ４７からのエニーキャストリクエストを受信すると、エニーキャストリプライ５８１〜５８ｎをサーバ４７に返す。
【０３１７】
サーバ４７は、先に受信したエニーキャストリプライの優先度を高くしてコンテンツを送信するクライアントを決定する。この図２９では、クライアント４７１が決定されたとする。
【０３１８】
サーバ４７は、決定されたクライアント４７１に、配信要求６１で指定されたパッチ識別情報１４（バージョン情報が送信されればよい）を送信する。
【０３１９】
クライアント４７１は、受信したバージョン情報と自己の保持するバージョン情報とを比較する。
【０３２０】
クライアント４７１は、比較の結果が新バージョンを表す場合、コンテンツ送信要求をサーバ４６に送信する。
【０３２１】
サーバ３６は、クライアント４７１からコンテンツ送信要求を受信した場合、配信要求６１で指定されたコンテンツをクライアント４７１に送信する。
【０３２２】
クライアント４７１は、同一のエニーキャストグループに属する他のクライアント４７２〜４７ｎにコンテンツを送信する。
【０３２３】
以上説明した本実施の形態に係る通信システム４５では、エニーキャストを用いてサーバ４６から特定のクライアント４７１にコンテンツが配信され、配信されたコンテンツが特定のクライアント４７１から他のクライアント４７２〜４７ｎに拡散される。
【０３２４】
これにより、サーバ４６の負荷を軽減するとともにクライアント４７１〜４７ｎにコンテンツを確実にかつ迅速に受信できる。
【０３２５】
（第３の実施の形態）
本実施の形態では、上記各実施の形態の変形例について説明する。
【０３２６】
例えば、上記第２の実施の形態のエニーキャスト配信に代えて、Xcastを用いて多数のネットワークに対して配信を実行するとしてもよい。
【０３２７】
Xcastとは、小グループ用のマルチキャスト配信である。このXcastでは、ネットワーク内に流されるパケットのヘッダに宛先を示すアドレス情報が複数記述され、ルータを通過する段階において各アドレス情報に対する経路が分岐する場合に、パケットがコピーされ配信される。
【０３２８】
Xcastで記載されるアドレス情報に多数のネットワークのエニーキャストアドレスを記載すれば、複数のサブネットワークにエニーキャストリクエストを送信することができ、上述したエニーキャスト通信と同様の手法により、各種コンテンツの配信を行うことができる。
【０３２９】
なお、上記各実施の形態において、通信システム１，４５の各構成要素は、プログラムにより実現される部分がハードウェアによって実現されるとしてもよい。
【０３３０】
上記各実施の形態におけるクライアントは、例えば家庭で使用される電化製品などであってもよい。これにより、ネットワーク経由で通信可能な電化製品の制御プログラムを迅速かつ正確かつ容易に修正できる。
【０３３１】
上記各実施の形態において、記録部１１，２９，４６，６８には、例えばストレージデバイス，メモリデバイス等が利用できる。
【０３３２】
また、上記各実施の形態に係る通信システム１，４５において、各構成要素は同様の動作を実現可能であれば配置を変更させてもよく、また各構成要素を自由に組み合わせてもよく、各構成要素を自由に分割してもよく、いくつかの構成要素を削除してもよい。
【０３３３】
例えば、記録部１１，２９，４６，６８は、複数の記録部に分割してもよい。すなわち、上記各実施の形態については、上記の構成そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
【０３３４】
【発明の効果】
以上詳記したように本発明においては、送信側の通信装置から複数の受信側の通信装置へのコンテンツの配信を迅速かつ正確に行うことができ、送信側の通信装置の負荷が軽減される。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態に係る通信システムの構成例を示す図。
【図２】 同実施の形態に係る通信システムのサーバの具体的構成例を示すブロック図。
【図３】 同実施の形態に係るソフトウェア情報の一例を示す図。
【図４】 同実施の形態に係る配信情報の一例を示す図。
【図５】 同実施の形態に係るグループ情報の一例を示す図。
【図６】 同実施の形態に係るパッチ情報の一例を示す図。
【図７】 同実施の形態に係るサーバの動作の前半の一例を示すフローチャート。
【図８】 同実施の形態に係るサーバの動作の後半の一例を示すフローチャート。
【図９】 同実施の形態に係るクライアントの具体的構成例を示すブロック図。
【図１０】 同実施の形態に係るバージョン管理情報の一例を示す図。
【図１１】 同実施の形態に係るソフトウェア管理情報の一例を示す図。
【図１２】 同実施の形態に係るグループ管理情報の一例を示す図。
【図１３】 同実施の形態に係るクライアントがサーバからマルチキャスト配信されたコンテンツを受信した後の処理の一例を示すフローチャート。
【図１４】 同実施の形態に係るクライアント間でP2P通信によりコンテンツを送受信する処理の前半の一例を示すフローチャート。
【図１５】 同実施の形態に係るクライアント間でP2P通信によりコンテンツを送受信する処理の後半の一例を示すフローチャート。
【図１６】 同実施の形態に係る通信システムの連携動作の一例を示すシーケンス図。
【図１７】 本発明の第２の実施の形態に係る通信システムによるエニーキャスト配信の状態の一例を示す図。
【図１８】 同実施の形態に係る通信システムによるクライアント間通信の状態の一例を示す図。
【図１９】 同実施の形態に係る通信システムのサーバの具体的構成例を示すブロック図。
【図２０】 同実施の形態に係るアドレス管理情報の一例を示す図。
【図２１】 同実施の形態に係るリプライ管理情報の一例を示す図。
【図２２】 同実施の形態に係る配信情報の一例を示す図。
【図２３】 同実施の形態に係るサーバの動作の前半の一例を示すフローチャート。
【図２４】 同実施の形態に係るサーバの動作の後半の一例を示すフローチャート
【図２５】 同実施の形態に係るクライアントの具体的構成例を示すブロック図。
【図２６】 同実施の形態に係るバージョン管理情報の一例を示す図。
【図２７】 同実施の形態に係るクライアントがサーバからコンテンツを受信する処理の前半の一例を示すフローチャート。
【図２８】 同実施の形態に係るクライアントがサーバからコンテンツを受信する処理の後半の一例を示すフローチャート。
【図２９】 同実施の形態に係る通信システムの連携動作の一例を示すシーケンス図。
【符号の説明】
１，４５…通信システム、２，４６…サーバ、３１〜３ｎ，４７１〜４７ｎ…クライアント、４…ネットワーク、５，１２ａ，１２ｂ…パッチ、６，１９，４９，６２…記録媒体、６ａ，１９ａ，４９ａ，６２ａ…プログラム、１３，６１…配信要求、１４…パッチ識別情報、１５…ソフトウェア識別情報、７，５０…要求処理部、８…配信済み確認部、９…グループ管理部、１０，５５…配信部、１１，２９，５６，６８…記録部、１１ａ…ソフトウェア情報、１１ｂ，５６ｃ…配信情報、１１ｃ…グループ情報、１１ｄ，２９ｂ…パッチ情報、２０…マルチキャスト受信部、２１…受信確認部、２２，６５…バージョン管理部、２３，６７…パッチ処理部、２４…通信先取得部、２５…通信先許可部、２６…認証部、２７…バージョン比較部、２８…コンテンツ通信部、２９ａ…バージョン管理部、２９ｃ…ソフトウェア管理情報、２９ｄ…通信許可情報、２９ｅ…グループ管理情報、４１…P2P通信部、４８…サブネットワーク、５１…アドレス取得部、５２…リクエスト送信部、５３…リプライ受信部、５４…配信先決定部、５６ａ…アドレス管理情報、５６ｂ…リプライ管理情報、６３…リクエスト受信部、６４…リプライ送信部、６６…コンテンツ受信部、６８ａ…バージョン管理情報
Claims (13)
- サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムにおいて、
前記サーバは、
前記配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、
マルチキャスト配信におけるマルチキャストグループを指定するマルチキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、前記配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を取得する手段と、
前記配信要求で指定されたコンテンツ識別情報に対応するマルチキャストアドレス情報を用いて、前記配信要求で指定されたコンテンツ識別情報の示すコンテンツのマルチキャスト配信を実行する配信手段と
を具備し、
前記マルチキャストグループに属するクライアントは、
前記マルチキャスト配信を用いて配信された前記コンテンツを受信する受信手段と、
受信した前記コンテンツを記録する記録手段と、
前記マルチキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記クライアントに保持されている前記コンテンツのバージョン情報とを比較するバージョン比較手段と、
前記バージョン比較手段による比較の結果に基づき、前記クライアントに保持されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記クライアントに保持されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段と
を具備する
ことを特徴とする通信システム。 - 請求項１記載の通信システムにおいて、
前記配信要求で指定されたコンテンツ識別情報は、前記配信対象のコンテンツのバージョン情報を含み、
前記サーバは、前記配信要求で指定されたコンテンツ識別情報のバージョン情報と前記配信手段によって配信済みの前記コンテンツを示すコンテンツ識別情報のバージョン情報を比較する手段をさらに具備し、
前記配信手段は、前記配信要求で指定されたコンテンツ識別情報に含まれているバージョン情報が、前記配信手段によって配信済みの前記コンテンツを示すコンテンツ識別情報のバージョン情報よりも新しい場合、マルチキャスト配信を実行する
ことを特徴とする通信システム。 - 請求項１又は請求項２記載の通信システムにおいて、
前記複数のクライアントの保持するコンテンツを示すコンテンツ識別情報を前記複数のクライアントから取得し、前記複数のクライアントの中の共通のコンテンツを保持するクライアントの中から、前記Ｐ２Ｐ通信を行う前記クライアントと前記他のクライアントとを決定し、前記クライアントと前記他のクライアントに通信先を通知する通信先決定サーバをさらに具備することを特徴とする通信システム。 - 請求項１乃至請求項３のいずれか１項に記載の通信システムにおいて、
前記受信手段によって受信された前記コンテンツの完全性を確認し、完全性が確保されていなければ前記受信手段によって受信された前記コンテンツを破棄する手段をさらに具備する通信システム。 - サーバから複数のクライアントに配信対象のコンテンツを送信する通信システムにおいて、
前記サーバは、
前記配信対象のコンテンツを示すコンテンツ識別情報を指定する配信要求を受け付ける受付手段と、
エニーキャスト配信におけるエニーキャストグループを指定するエニーキャストアドレス情報とコンテンツ識別情報とを対応付けた情報に基づいて、前記配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を取得する手段と、
前記配信要求で指定されたコンテンツ識別情報に対応するエニーキャストアドレス情報を用いて、エニーキャストリクエストを送信する手段と、
エニーキャストリプライを受信する手段と、
前記エニーキャストリプライの受信順序に基づいて、前記配信要求で指定されたコンテンツ識別情報の示すコンテンツの送信先を決定する送信先決定手段と、
前記送信先決定手段によって決定された送信先に、前記配信要求で指定されたコンテンツ識別情報の示すコンテンツを送信する手段と
を具備し、
前記エニーキャストグループに属するクライアントは、
前記エニーキャスト配信における前記エニーキャストリクエストを受信する手段と、
前記エニーキャストリクエストの送信元に前記エニーキャストリプライを返す手段と、
前記エニーキャストリクエストの送信元から前記コンテンツを受信する受信手段と、
受信した前記コンテンツを記録する記録手段と、
前記エニーキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記クライアントに保持されている前記コンテンツのバージョン情報とを比較するバージョン比較手段と、
前記バージョン比較手段による比較の結果に基づき、前記クライアントに保持されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記クライアントに保持されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段と
を具備する
ことを特徴とする通信システム。 - 請求項５記載の通信システムにおいて、
前記送信先決定手段は、前記配信要求で指定されたコンテンツ識別情報の示すコンテンツを未だ送信してなく先に受信したエニーキャストリプライの送信元を、前記配信要求で指定されたコンテンツ識別情報の示すコンテンツの送信先として決定することを特徴とする通信システム。 - 請求項５又は請求項６記載の通信システムにおいて、
前記クライアントは、前記エニーキャストリクエストの送信元から前記コンテンツのバージョン情報を受信して新バージョンか否か判断し、新バージョンと判断された場合に前記エニーキャストリクエストの送信元にコンテンツ送信要求を返す手段をさらに具備し、
前記受信手段は、新バージョンと判断された前記コンテンツを受信する
ことを特徴とする通信システム。 - マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段と、
受信した前記コンテンツを記録する記録手段と、
同一のマルチキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較するバージョン比較手段と、
前記バージョン比較手段による比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段と
を具備する通信装置。 - エニーキャスト配信におけるエニーキャストリクエストを受信する手段と、
前記エニーキャストリクエストの送信元にエニーキャストリプライを返す手段と、
前記エニーキャストリクエストの送信元からコンテンツを受信する受信手段と、
受信した前記コンテンツを記録する記録手段と、
同一のエニーキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較するバージョン比較手段と、
前記バージョン比較手段による比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記憶されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段と
を具備する通信装置。 - コンピュータを、
マルチキャスト配信を用いて配信されたコンテンツを受信する受信手段、
受信した前記コンテンツを記録手段に記録する手段、
同一のマルチキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較するバージョン比較手段、
前記バージョン比較手段による比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段
として機能させるためのプログラム。 - コンピュータを、
エニーキャスト配信におけるエニーキャストリクエストを受信する手段、
前記エニーキャストリクエストの送信元にエニーキャストリプライを返す手段、
前記エニーキャストリクエストの送信元からコンテンツを受信する受信手段、
受信した前記コンテンツを記録手段に記録する手段、
同一のエニーキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較するバージョン比較手段、
前記バージョン比較手段による比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信するＰ２Ｐ通信手段
として機能させるためのプログラム。 - 通信装置が、マルチキャスト配信を用いて配信されたコンテンツを受信し、
前記通信装置が、受信した前記コンテンツを記録手段に記録し、
前記通信装置が、同一のマルチキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較し、
前記比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信する
ことを特徴とする通信方法。 - 通信装置が、エニーキャスト配信におけるエニーキャストリクエストを受信し、
前記通信装置が、前記エニーキャストリクエストの送信元にエニーキャストリプライを返し、
前記通信装置が、前記エニーキャストリクエストの送信元からコンテンツを受信し、
前記通信装置が、受信した前記コンテンツを記録手段に記録し、
前記通信装置が、同一のエニーキャストグループに属する他のクライアントに保持されている前記コンテンツのバージョン情報と、前記記録手段に記録されている前記コンテンツのバージョン情報とを比較し、
前記通信装置が、前記比較の結果に基づき、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも新しい場合に、前記他のクライアントに対して前記コンテンツの新バージョンをＰ２Ｐ通信で送信し、前記記録手段に記録されている前記コンテンツのバージョンが前記他のクライアントに保持されている前記コンテンツのバージョンよりも古い場合に、前記他のクライアントから前記コンテンツの新バージョンをＰ２Ｐ通信で受信する
ことを特徴とする通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003203791A JP4256218B2 (ja) | 2003-07-30 | 2003-07-30 | 通信システム、通信装置、プログラム並びに通信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003203791A JP4256218B2 (ja) | 2003-07-30 | 2003-07-30 | 通信システム、通信装置、プログラム並びに通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005051351A JP2005051351A (ja) | 2005-02-24 |
| JP4256218B2 true JP4256218B2 (ja) | 2009-04-22 |
Family
ID=34263017
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003203791A Expired - Fee Related JP4256218B2 (ja) | 2003-07-30 | 2003-07-30 | 通信システム、通信装置、プログラム並びに通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4256218B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4774814B2 (ja) * | 2005-06-06 | 2011-09-14 | 日本電気株式会社 | サーバアクセス制御システム、サーバアクセス制御方法およびサーバアクセス制御プログラム |
| JP4747733B2 (ja) | 2005-08-22 | 2011-08-17 | ブラザー工業株式会社 | ノード装置、共用情報更新処理プログラム、共用情報更新方法、及び情報共有システム |
| US8291093B2 (en) * | 2005-12-08 | 2012-10-16 | Microsoft Corporation | Peer-to-peer remediation |
| RU2454011C2 (ru) | 2006-07-24 | 2012-06-20 | Эл Джи Электроникс Инк. | Двухточечные радиоканалы для службы радиовещания |
| CN102037678B (zh) * | 2008-05-20 | 2013-09-25 | 汤姆森许可贸易公司 | 分发在多个接收机处可用的内容的映射图的系统和方法 |
| EP2294795B1 (en) * | 2008-07-02 | 2013-12-11 | Thomson Licensing | Device and method for disseminating content data between peers in a p2p mode, by using a bipartite peer overlay |
| JP2010054100A (ja) * | 2008-08-27 | 2010-03-11 | Sharp Corp | 蒸気供給装置及び加熱調理器 |
| JP2010206736A (ja) * | 2009-03-05 | 2010-09-16 | Nec Corp | ネットワークシステム、その通信方法、ルータ、およびプログラム |
-
2003
- 2003-07-30 JP JP2003203791A patent/JP4256218B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005051351A (ja) | 2005-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6363081B1 (en) | System and method for sharing a network port among multiple applications | |
| JP4965574B2 (ja) | 複数のプロセスにおけるポートの共有 | |
| JP2020162146A (ja) | 仮想ネットワークにおける分散型フロー状態ｐ２ｐ設定のためのシステムおよび方法 | |
| JP4664143B2 (ja) | パケット転送装置、通信網及びパケット転送方法 | |
| US20030018914A1 (en) | Stateful packet forwarding in a firewall cluster | |
| CN101272627B (zh) | 实现漫游的网络接入控制方法及设备 | |
| US20120215747A1 (en) | Data uploading method, data downloading method, and data system | |
| US20060143699A1 (en) | Firewall device | |
| CN106878483A (zh) | 一种ip地址分配方法及装置 | |
| US11856065B2 (en) | Data transmission for service integration between a virtual private cloud and an intranet | |
| EP2922246B1 (en) | Method and data center network for cross-service zone communication | |
| RU2344473C2 (ru) | Сетевая система, прокси-сервер, способ управления сеансом | |
| US20190089648A1 (en) | Resource subscription method, resource subscription apparatus, and resource subscription system | |
| CN112367666B (zh) | 一种5G核心网中pNF通过NRF认证cNF的方法、装置及系统 | |
| CN113824685B (zh) | 一种基于Android VpnService实现的移动端定向流量代理系统与方法 | |
| JP4256218B2 (ja) | 通信システム、通信装置、プログラム並びに通信方法 | |
| CN113852483B (zh) | 网络切片连接管理方法、终端及计算机可读存储介质 | |
| JP4494279B2 (ja) | マルチキャスト制御方法、マルチキャスト制御装置、及びコンテンツ属性情報管理装置、並びにプログラム | |
| Stapp | DHCPv6 Bulk Leasequery | |
| US7689648B2 (en) | Dynamic peer network extension bridge | |
| JP2003179647A (ja) | パケット転送装置およびパケット転送方法 | |
| US10849179B1 (en) | Mobile network tool | |
| US8996656B2 (en) | File transfer method in converged IP messaging system | |
| JP4554420B2 (ja) | ゲートウェイ装置及びそのプログラム | |
| CN112073403A (zh) | 一种ap隔离状态配网方法、终端及可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060721 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080703 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080805 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081006 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090127 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090129 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120206 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120206 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130206 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |