JP5208549B2 - 通信装置、システム、送信方法及びプログラム - Google Patents

通信装置、システム、送信方法及びプログラム Download PDF

Info

Publication number
JP5208549B2
JP5208549B2 JP2008078239A JP2008078239A JP5208549B2 JP 5208549 B2 JP5208549 B2 JP 5208549B2 JP 2008078239 A JP2008078239 A JP 2008078239A JP 2008078239 A JP2008078239 A JP 2008078239A JP 5208549 B2 JP5208549 B2 JP 5208549B2
Authority
JP
Japan
Prior art keywords
piece
encrypted
pieces
index
priority
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
Application number
JP2008078239A
Other languages
English (en)
Other versions
JP2009232393A (ja
Inventor
健太郎 梅澤
竜一 小池
英樹 松本
達之 松下
拓 加藤
春彦 外山
英昭 佐藤
達 上林
聡 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2008078239A priority Critical patent/JP5208549B2/ja
Priority to US12/333,704 priority patent/US8175267B2/en
Priority to CN2009101279783A priority patent/CN101547201B/zh
Publication of JP2009232393A publication Critical patent/JP2009232393A/ja
Application granted granted Critical
Publication of JP5208549B2 publication Critical patent/JP5208549B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1076Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078Resource delivery mechanisms
    • H04L67/108Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Description

本発明は、暗号鍵を用いて暗号化された暗号化コンテンツを、他の通信装置に送信する通信装置、システム、送信方法及びプログラムに関する。
一般に、コンテンツを配信するシステムには、「単一サーバ型」と「分散サーバ型」とがある。単一サーバ型のシステムでは、例えば、1つのコンテンツサーバと、ライセンスサーバと、クライアントとがネットワークを介して接続され、コンテンツサーバからコンテンツが各クライアントに配信される。配信されるコンテンツは暗号化されており、この暗号化に係る鍵情報をライセンスサーバが有している。コンテンツサーバでは、コンテンツはE( KT )[ C ]として保持される。ただし、KTはタイトル鍵と呼ばれる鍵であり、Cは平文のコンテンツである。E( KT )[ C ]はCがKTで暗号化されていることを示す。鍵情報にはKTが含まれている。クライアントBは、鍵情報をライセンスサーバから取得し、当該鍵情報を、当該クライアント(クライアントBとする)固有の鍵KBを用いて暗号化し、これをコンテンツサーバから受信したコンテンツE( KT )[ C ]と関連づけて保持する。そして、クライアントBは、鍵KBを用いて鍵情報を復号して、タイトル鍵KTを取り出し、当該タイトル鍵KTを用いてE( KT )[ C ]を復号することにより、コンテンツを利用することができる。
このような構成において、クライアントBは、コンテンツサーバからコンテンツE( KT )[ C ]をダウンロードする際、認証及び鍵交換を互いに行う。この結果、クライアントBは、一時鍵KtmpBを共有する。コンテンツサーバは、一時鍵KtmpBを用いてコンテンツE( KT )[ C ]を暗号化し、コンテンツE( KtmpB )[ E( KT )[ C ]をクライアントBに送信する。クライアントBは、上述の認証及び鍵交換によってコンテンツサーバと共有している一時鍵KtmpBを用いてコンテンツE( KtmpB )[ E( KT )[ C ]]を復号して、E( KT )[ C ]を取り出す。このような構成においては、ネットワークの経路上で、暗号化されたコンテンツE( KtmpB )[ E( KT )[ C ] ]が不正に読み取られたとしても、不正に読み取られたものは一時鍵KtmpBがなければ復号することができない。即ち、クライアント毎に異なる一時鍵を用いてコンテンツを暗号化することにより、同一のコンテンツをクライアント毎に個別化し、これにより、コンテンツの不正使用を抑制することができる。例えば、クライアントAに対する一時鍵KtmpAとクライアントBに対する一時鍵KtmpBとを異ならせることにより、クライアントAに配信されるコンテンツE( KtmpA )[ E( KT )[ C ] ]と、クライアントBに配信されるコンテンツE( KtmpB )[ E( KT )[ C ] ]とは異なる個別のデータとなる。このように同一のコンテンツを暗号鍵の相違により個別化することにより、コンテンツの不正使用を抑制することができる。
しかし、単一サーバ型のシステムでは、クライアントとコンテンツサーバとの1対1での通信となるため、多くのクライアントがコンテンツサーバからコンテンツの配信を受けようとすると、配信効率が悪くなるという問題がある。
一方、分散サーバ型のシステムには、例えば、P2PによるBitTorrentというコンテンツ配信システムがある(例えば、非特許文献1参照)。このようなシステムにおいては、コンテンツ毎に異なるトラッカと、シーダと、リーチャとがP2Pで各々接続される。また、配信されるコンテンツは、複数のピースに分割されている。シーダは、コンテンツの配信(アップロード)を目的として、コンテンツを構成するピースを配信するノードである。リーチャは、コンテンツの受信(ダウンロード)を目的として、コンテンツを構成する各ピースの受信とコンテンツを構成するピースの配信とを行うノードである。即ち、リーチャはコンテンツを構成するピースをある程度取得するとシーダになる場合がある。このように、シーダには、コンテンツを構成する全部のピース又は一部のピースを受信したリーチャがシーダへ変化したものと、システム側で(予め又は配信の途中に)用意される(最初からシーダである)ものとがある。後者を初期シーダと呼ぶ。初期シーダは、あるひとつのコンテンツを構成し得る全てのピース又は一部のピースを保持している。以降、特に断りのない限り、シーダとはシーダ又は初期シーダを意味するものとし、ノードとはリーチャ、シーダ、又は初期シーダを意味するものとする。トラッカは、各ノードに関するノード情報を保持しており、リーチャからアクセスがあった場合、ノード情報をリーチャに提供する。
このような構成において、あるリーチャがコンテンツの配信を受ける場合、まず、Torrent Fileと呼ばれる情報を取得する。Torrent Fileは、例えば、コンテンツプロバイダ又はユーザにコンテンツを販売するサービスを運用するサーバ(販売サーバと呼ぶ)から、他ノード又は販売サーバへ与えられ、さらに他ノード又は販売サーバからリーチャへ与えられる。この他に、例えばCD−ROMなどの記録媒体に記録されたTorrent Fileをオフラインでリーチャへ配布される場合もある。Torrent Fileには、コンテンツに関するトラッカ情報と、当該コンテンツのファイル情報とが格納されている。トラッカ情報はトラッカの接続先を含んでいる。ファイル情報は、例えば、コンテンツを構成する各ピースのハッシュ情報を含んでいる。ハッシュ情報は、ピースの完全性を確認するために用いられる。即ち、ハッシュ情報は、リーチャがダウンロードしたピースのハッシュを計算し、当該ピースのハッシュ値と照合して、受信したピースが改竄されていないことを確認するのに用いられる。
リーチャは、このようなTorrent Fileを取得すると、トラッカ情報に基づいてトラッカに接続する。トラッカは、リーチャに上述のノード情報を送信する。ノード情報は単数または複数のノードの接続先のリストを含んでいる。リーチャはノード情報に基づいて、複数のノードに接続する。各ノードが配信するピースは、ノード毎に異なっている場合が多い。リーチャは、複数のノードから異なるピースを受信することができるので、コンテンツの高速な受信が可能である。
このように、P2Pによるコンテンツ配信システムでは、コンテンツは複数のノードに分散して保持されている。従って、このようなシステムにおいては、コンテンツの配信を受けるノードが多くても、P2Pにより複数の他のノードからコンテンツの配信を受けることができるため、単一サーバ型のシステムに比べて配信効率が良い。
Bittorrent Protocol Specification v1.0
尚、このように、複数のノードからコンテンツを配信し得るコンテンツ配信システムにおいても、コンテンツの不正使用を抑制するためには、配信するコンテンツを暗号化によって保護することが望ましい。しかし、このようなコンテンツ配信システムでは、単一サーバ型のシステムとは異なり、各リーチャがシーダから受信する同一のコンテンツは、暗号化された状態であっても同一でなければならず、リーチャ毎に個別に暗号化したコンテンツを配信することは難しかった。このため、暗号化されたコンテンツを復号するための鍵が1つ曝露されてしまうと、ネットワーク上に多数存在するコンテンツが全て復号可能になってしまうという恐れがあった。
とくに、複数のリーチャ同士が、サーバ等を介さずに、暗号化したピースを交換する状況では、各リーチャがコンテンツを取得する行為を制御することが難しいため、上記の鍵の暴露の影響は深刻であった。
本発明は、上記に鑑みてなされたものであって、コンテンツ配信システムにおいて配信されるコンテンツの一部であるピースを、リーチャ同士が共有するような場合であっても、鍵が暴露された際の影響を軽減することが可能な通信装置、システム、送信方法及びプログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段と、前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御手段と、暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定手段と、送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定手段と、送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、前記送信手段によって送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新手段と、前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新手段とを備えることを特徴とする。
また、本発明は、通信システムであって、コンテンツの一部である複数のピースの送受信を行う第1通信装置及び第2通信装置がネットワークを介して接続され、第1通信装置及び第2通信装置は各々、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段と、前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御手段と、暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定手段と、送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定手段と、送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、前記送信手段によって送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新手段と、前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新手段と、前記暗号化ピースを他の通信装置から受信するピース受信手段と、受信された前記暗号化ピースを前記第1記憶手段に記憶させるピース記憶制御手段とを備え、前記第1通信装置の備える前記送信手段が、送信対象として決定された前記暗号化ピースを前記第2通信装置に送信し、前記第2通信装置の備える前記ピース受信手段が、前記第1通信装置の備える前記送信手段から送信された前記暗号化ピースを受信することを特徴とする。
また、本発明は、コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段とを備える通信装置において実現される送信方法であって、前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御ステップと、暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定ステップと、送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定ステップと、送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、前記送信ステップで送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新ステップと、前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新ステップとを含むことを特徴とする。
また、本発明は、コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段とを備える通信装置の有するコンピュータに実行させるための送信プログラムであって、前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御ステップと、暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、前記ピース要求が受信された場合、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定ステップと、送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定ステップと、送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、前記送信ステップで送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新ステップと、前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新ステップとを含むことを特徴とする。
本発明によれば、コンテンツ配信システムにおいて配信されるコンテンツの一部である複数のピースを、リーチャ同士が共有するような場合であっても、鍵が暴露された際の影響を軽減することが可能になる。
以下に添付図面を参照して、この発明にかかる通信装置、システム、送信方法及びプログラムの最良な実施の形態を詳細に説明する。
[第1の実施の形態]
(1)構成
<コンテンツ配信システムの構成>
図1は、本実施の形態にかかるコンテンツ配信システムの構成を示すブロック図である。本実施の形態にかかるコンテンツ配信システムにおいては、リーチャ50A〜50Bと、トラッカ51と、シーダ52A〜52Cと、販売サーバ54とが各々P2PネットワークNTを介して接続されている。リーチャ50A〜50Bと、鍵サーバ53とは各々、図示しないインターネットなどのネットワークを介して接続される。ここでノードとは、リーチャ50A〜50Bと、シーダ52A〜52Cとである。シーダ52A〜52Cは、複数のピースに分割されたコンテンツについて、各ピースが各々異なる暗号鍵で暗号化された各暗号化ピースを保持している。尚、以降、このような暗号化ピースから構成されるコンテンツを暗号化コンテンツという。このような暗号化コンテンツの詳細については後述する。シーダ52A〜52Cのうち、シーダ52Aは、上述した初期シーダとして機能する。シーダ52Aは、一つのコンテンツを構成する各ピースについて、同一のピースに対して複数の暗号鍵を用いて各々暗号化されて生成された暗号化ピースの全てを保持している。トラッカ51は、各ノードにアクセスするためのノード情報を保持している。鍵サーバ53は、各暗号化ピースを復号するための復号鍵を保持している。販売サーバ54は、Torrent Fileを保持している。
リーチャ50Aは、販売サーバ54からTorrent Fileを受信し、当該Torrent Fileに基づいて、トラッカ51にアクセスしてノード情報を取得し、ノード情報に基づいて、シーダ52A〜52Cやリーチャ50Bの少なくとも1つにアクセスして各暗号化ピースを受信して、各ピースに各々対応する全ての暗号化ピースを取得し、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を鍵サーバ53から受信する。リーチャ50Bについても同様である。尚、以降、リーチャ50A〜50Bを各々区別する必要がない場合、単にリーチャ50と記載する。シーダ52A〜52Cを各々区別する必要がない場合も、単にシーダ52と記載する。
ここで、コンテンツの構成について説明する。コンテンツとは、種々のデジタルデータ、例えばMPEG2やMPEG4等の動画データや音声データの他、テキストデータや静止画データ等を指し、また、これらのデジタルデータが暗号化されているものもコンテンツと呼ぶ。例えば、HD DVD Prepared Video ContentをAACS(Advanced Access Content System)仕様に従って暗号化したものもコンテンツである。ここでは、コンテンツ全体をCと表すものとする。Cは平文であっても暗号化されていても構わない。図2は、コンテンツが複数のピースに分割された状態を模式的に示す図である。例えば、コンテンツCは、ある1つのコンテンツをN(N>1)個のピースC1〜CNに分割される。各ピースC1,C2,・・・CNのデータ長は全て同一であっても良いし、そうでなくても良い。これらのN個の各ピースC1〜CNについては、各々異なる暗号鍵で暗号化される。このとき、N個のうちa個のピースについては、同一のピースに対して、各々異なるm(m>1)個の暗号鍵で暗号化される。残りの(N-a)個のピースについては、同一のピースに対して1つの暗号鍵(第1暗号鍵)で暗号化される。即ち、a個の各ピースについては、同一のピースがm個の異なる暗号鍵で各々暗号化されてm個の異なるピース(暗号化ピース)が生成される。(N-a)個の各ピースについては、各々1つの暗号鍵で暗号化して、1つのピースに対して1つの暗号化ピースが生成される。図3は、各暗号化ピースを模式的に示す図である。このa個の各ピースに各々対応して、m個の暗号化ピースの中から各々1つ選択される暗号化ピースの組み合わせを異ならせることにより、N個の暗号化ピースから構成される暗号化コンテンツ全体を個別化することができる。
次に、リーチャ50と、トラッカ51と、シーダ52と、鍵サーバ53との各装置のハードウェア構成について説明する。各装置は各々、装置全体を制御するCPU(Central Processing Unit)等の制御装置と、各種データや各種プログラムを記憶するROM(Read Only Memory)やRAM(Random Access Memory)等の記憶装置と、各種データや各種プログラムを記憶するHDD(Hard Disk Drive)やCD(Compact Disk)ドライブ装置等の外部記憶装置と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、各装置には各々、情報を表示する表示装置と、ユーザの指示入力を受け付けるキーボードやマウス等の入力装置と、外部装置の通信を制御する通信I/F(interface)とが有線又は無線により接続される。
<シーダ52の構成>
ここで、シーダ52の構成について詳細に説明する。シーダ52は、コンテンツCを構成する複数のピースC1〜CNが各々暗号化された各暗号化ピースを、各ピースC1〜CNを各々復号するための各復号鍵のインデックス(添え字)と対応付けて記憶している。尚、各復号鍵は、各暗号鍵と同一であっても良いし、各暗号鍵と異なるものであっても良い。いずれにしろ、各ピースC1〜CNは各々暗号鍵で暗号化されているため、これらの各暗号化ピースを復号するための復号鍵のそれぞれについて、各復号鍵のインデックスを用いて、各暗号化ピースを特定することができる。このような各暗号化ピースは例えば外部記憶装置に記憶される。
以下簡単のため、暗号鍵と復号鍵が同一の場合で説明する。復号鍵のインデックスを、( i, j )で表し、復号鍵を、K ( i, j )で表すとすると、各暗号化ピースは、例えば、以下のように表される。
E( K( i, j) )[ Cj ]
(ただし、i, jは整数、1≦i≦m、1≦j≦N(m>1)、相異なるインデックス( i, j)、( i’, j’) (( i, j)≠( i’, j’))についてK( i, j)= K( i’, j’)であってもよい。)
このような各暗号化ピースから構成される暗号化コンテンツは、例えば、以下のように表される。
{ E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]}
(ただし、1≦i1, …, iN≦m)
このような暗号化コンテンツにおける各暗号化ピースのシーケンスは、各暗号化ピースのインデックスの組み合わせにより表され、例えば以下のように表される。ここでは、各ピースC1〜CNに各々対応するインデックスが左から順に配列されて表されている。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
従って、シーダ52が各暗号化ピースとインデックスとを対応付けて記憶するものは、例えば、以下のように表される。
{ ( E( K( i1, 1) )[ C1 ], ( i1, 1 ) ), ( E( K( i2, 2) )[ C2 ], ( i2, 2 ) ), …,( E( K( iN, N )[ CN ], ( iN, N ) ) )}
(ただし、1≦i1, …, iN≦m)
尚、以降、各ピースC1〜CNを区別するためのインデックスjについては、ピースインデックスと表記し、復号鍵の数に応じてバリエーションが生じるインデックスiについては、バリエーションインデックスと表記し、これらの組(i,j)を単にインデックスと表記する。また、ピースインデックスjに対応するピースについて、相異なる2つ以上の暗号鍵で各々暗号化された暗号化ピースが存在する場合これらの集合を暗号化ピース列jと適宜表記する。
初期シーダであるシーダ52Aは、コンテンツを構成する各ピースに各々対応する各暗号化ピースについて、同一のピースに対して複数の暗号鍵により各々暗号化されて生成された暗号化ピースの全てを記憶している。図4は、シーダ52Aが記憶している各暗号化ピースを例示する図である。同図においては、N個のうちa個(1<a<N)のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化されていることが示されている。同図においては、同一のピースの暗号化に用いられる暗号鍵の個数は、ピース毎に異なっている。ピースC1に対する暗号鍵の個数はm個であり、ピースC3に対する暗号鍵の個数は2個である。但し、本実施の形態においては、同一のピースの暗号化に用いられる暗号鍵の個数はピース毎に同じであっても良い。ピース処理装置では、このように、N個のうちa個(1<a<N)のピースについて、同一のピースに対して複数の異なる暗号鍵で各々暗号化することにより、例えば、重要度の高いほど暗号鍵の数を増やすようにすることができる。
尚、本実施の形態においては、これに限らず、例えば、図5に示されるように、「a=N」の場合、即ち、N個全てのピースについて、同一のピースに対してm個の異なる暗号鍵で各々暗号化されていても良い。このような構成によれば、暗号化ピースのシーケンスのバリエーションを多くすることができる。また、図6に示されるように、「a=1」の場合、即ち、N個のうち1個のピースのみ、m個の異なる暗号鍵で暗号化されていても良い。このような構成によれば、配信効率を向上させることができる。
尚、初期シーダであるシーダ52A以外のシーダ52B,52Cは、暗号化ピース列jに属する暗号化ピースとして存在するものの全てを必ずしも保持しているとは限らない。シーダ52B,52Cが、ある時点で、暗号化ピース列jに属する暗号化ピースとして存在する一部の暗号化ピースしか保持していない場合、当該一部の暗号化ピースを処理対象として各種処理を行う。但し、ここでは、少なくとも1つの暗号化ピース列jについては、異なる2つ以上の暗号鍵で各々暗号化された暗号化ピースをシーダ52は保持しているものとする。なお、シーダ52Aを含むシーダ52(送信側)や、暗号化ピースを送信する送信側となった場合のリーチャ50との間、即ち、送信側間では、少なくともピースインデックスは共有されているものとする。また、後述するように、暗号化ピースを受信する受信側からバリエーションインデックスの指定がなされる場合には、バリエーションインデックスも送信側間では共有されているものとする。これは、同一のTorrent Fileを共有するなどしていたりすれば実現可能である。このようなシーダ52B,52Cは、他のシータ52やリーチャ50から暗号化ピースを受信することにより、暗号化ピース列jに属する暗号化ピースとして存在するものの全てを保持可能である。
次に、シーダ52のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図7は、シーダ52の機能的構成を例示する図である。シーダ52は、ピース情報送信部520と、ピース要求受信部521と、優先ピースインデックス選定部522と、ピースインデックス決定部523と、バリエーションインデックス決定部524と、送信状況テーブル更新部525と、ピース送信部526とを有する。また、シーダ52は、図示しない送信状況テーブルを有する。送信状況テーブルとは、例えば外部記憶装置に記憶されるデータテーブルである。
ピース情報送信部520は、リーチャ50からのアクセスにより、当該シーダ52が記憶している暗号化ピースのピースインデックスを示すピース情報をリーチャ50に送信する。図8は、ピース情報のデータ構成を例示する図である。同図においては、ピースインデックスのみが示されており、ピースC19,C29,C100,C101に対応する暗号化ピースをシーダ52が有することが示されている。このような構成によれば、シーダ52は自身の保持する暗号化ピース(i,j)のバリエーションインデックスiをリーチャ50に隠すことができる。このような構成においてもリーチャ50は、Torrent Fileの情報や暗号化ピースの受信時にヘッダ情報として記載されたバリエーションインデックスの値iを参照することにより、自身が取得した暗号化ピースのシーケンスを判断することは可能である。しかし、シーダ52は、ピースインデックスjのみならず、ピースインデックスjとバリエーションインデックスiとの組(i,j)を示すピース情報をリーチャ50に送信するようにしても良い。
ピース要求受信部521は、上述のピース情報に基づいて暗号化ピースを要求するリーチャ50からのピース要求を受信する。
送信状況テーブル更新部525は、シーダ52が記憶している暗号化ピースのそれぞれについて、それが送信された後にその送信回数を計数し、送信回数を各暗号化ピースと対応付けて送信状況テーブルに記録する。図9は、送信状況テーブルのデータ構成を例示する図である。同図に示される送信状況テーブルにおいては、コンテンツを構成する全てのピースのピースインデックスと、当該ピースインデックスに対して存在する全てのバリエーションインデックスとが示されており、このうち、シーダ52が記憶している暗号化ピースのインデックス(i,j)に対応して送信回数が各々記録される。また、送信状況テーブルにおいては、各ピースインデックスに対して、優先ピースインデックスフラグが対応付けられている。優先ピースインデックスフラグとは、以下に説明する優先ピースインデックス選定部522が優先ピースインデックスとして選定したピースインデックスを特定するものであり、優先ピース情報に相当する。優先ピースインデックスフラグには、初期値として‘0’が設定されている。これが‘1’に設定されたピースインデックスは、優先ピースインデックスとして選定されたことを示す。また、暗号化ピースが送信された後優先ピースインデックスの初期化条件が成立した場合に、送信状況テーブル更新部525が、全てのピースインデックスに対する優先ピースインデックスフラグの値を‘0’に設定することにより優先ピースインデックスを初期化する。即ち、優先ピースインデックスの初期化条件が成立した場合、送信状況テーブル更新部525は、優先ピースインデックスフラグによって優先ピースインデックスが特定されない初期状態にする。優先ピースインデックスの初期化条件とは、優先ピースインデックスとして選定されたピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未だ送信していない、即ち、送信回数が0回である暗号化ピース(未送信暗号化ピース)が存在しなくなったことである。ここで、送信回数が0回であることはこれまでの送信履歴が0回ということではなく、前回の配信からある一定程度の時間が経過していたり、配信側のポリシーによって0回に設定されて配信が開始したりすることを意味している。例えばP2PネットワークNTで流通が確認されないなどの判断に基づいて設定すればよい。
優先ピースインデックス選定部522は、上述の送信状況テーブルを参照して、シーダ52が記憶している暗号化ピースのうち未送信暗号化ピースの個数、即ち、送信回数が‘0’の暗号化ピースの個数を暗号化ピース列毎に計数し、未送信暗号化ピースの個数が最も多い暗号化ピース列のピースインデックスjを優先ピースインデックスとして選定する。即ち、優先ピースインデックスとして選定されたピースインデックスjの暗号化ピース列に含まれる複数の暗号化ピースが優先ピースとして選定される。優先ピースとは、ピースが異なる暗号鍵で暗号化された複数の暗号化ピースのうち、優先的に配信されるピースのことである。そして、優先ピースインデックス選定部522は、送信状況テーブルにおいて、優先ピースインデックスとして選定したピースインデックスに対応する優先ピースインデックスフラグを‘1’に設定する。尚、優先ピースインデックスの個数は、複数であっても良く、この場合、優先ピースインデックス選定部522は、未送信の暗号化ピースの個数が多い順に優先ピースインデックスを選定する。
ピースインデックス決定部523は、ピース要求受信部521がピース要求を受信した場合、送信状況テーブルの優先ピースインデックスフラグを参照して、優先ピースインデックスとして選定されたピースインデックスjが存在するか否かを判断し、当該判断結果が肯定的である場合に、送信候補とする暗号化ピースのピースインデックスjを決定する。バリエーションインデックス決定部524は、ピースインデックス決定部523が決定したピースインデックスjに対応する暗号化ピース列に属し自身が保持している暗号化ピースのバリエーションインデックスの中から、送信対象とする暗号化ピースのバリエーションインデックスiを決定する。この結果、ピースインデックスj及びバリエーションiとの組からなるインデックス(i,j)が決定され、当該インデックス(i,j)に対応する暗号化ピースが送信対象として決定されることになる。
ピース送信部526は、ピースインデックス決定部523が決定したピースインデックスjと、バリエーションインデックス決定部524が決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースをリーチャ50に送信する。
<リーチャ50の構成>
次に、上述したハードウェア構成において、リーチャ50のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図10は、リーチャ50の機能的構成を例示する図である。リーチャ50は、コンテンツ取得部500と、鍵束要求部501と、鍵束取得部502と、コンテンツ復号部503とを有する。これら各部の実体は、CPUのプログラム実行時にRAMなどの記憶装置上に生成されるものである。
コンテンツ取得部500は、P2PネットワークNTを介して、暗号化コンテンツを構成する各暗号化ピースをシーダ52の少なくとも1つから受信する。具体的には、コンテンツ取得部500は、まず、販売サーバ54からTorrent Fileを受信する。Torrent Fileは、トラッカ51に接続するためのトラッカ接続先情報を含むトラッカ情報と、暗号化コンテンツを構成する各暗号化ピースとしてどのようなものがあるかを示すファイル情報とを含んでいる。図11は、Torrent Fileを例示する図である。同図においては、ファイル情報として、各暗号化ピースを特定するための情報として、各暗号化ピースに対応するインデックスが各々示されている。
コンテンツ取得部500は、Torrent Fileに基づいて、P2PネットワークNTを介してトラッカ51にアクセスして、P2PネットワークNTに接続されているノード(シーダ52、他のリーチャ50)にアクセスするためのノード情報を当該トラッカ51から受信する。ノード情報の詳細については後述する。そして、コンテンツ取得部500は、ノード情報に基づいて、ノードの少なくとも1つにアクセスして、当該ノードが記憶している自身の保持する暗号化ピースのシーケンスを示すピース情報を取得する。そして、コンテンツ取得部500は、ピース情報に基づいて、暗号化コンテンツを構成する各暗号化ピースをノードの少なくとも1つから受信し、暗号化コンテンツを構成する全ての暗号化ピース(ピースシーケンス)を取得する。例えば、図3に示した各暗号化ピースのうち、網掛けされた全ての暗号化ピースをピースシーケンスとしてコンテンツ取得部500は取得する。
鍵束要求部501は、ピースシーケンスを復号するための鍵束を要求する要求メッセージを鍵サーバ53へ送信する。鍵束とは、ピースシーケンスの各暗号化ピースを各々復号するための各復号鍵を、各暗号化ピースのシーケンスに合わせて含むものである。尚、鍵束及び復号鍵の詳細については後述する。要求メッセージは、この鍵束に含ませる各復号鍵のシーケンスを指定する情報として、ピースシーケンスにおける各暗号化ピースのインデックスの組み合わせ(シーケンス)を示すインデックス情報を含む。このようなシーケンスは、例えば、以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
鍵束取得部502は、要求メッセージに応じて鍵サーバ53から送信された鍵束を受信する。コンテンツ復号部503は、コンテンツ取得部500が取得した各暗号化ピースを、鍵束取得部502が取得した鍵束に含まれ各暗号化ピースに各々対応する復号鍵を用いて各々復号して、復号した各ピースから構成されるコンテンツを取得する。
尚、リーチャ50は、上述したように、シーダとして機能する場合もあるが、その機能的構成については、シーダ52の構成において説明したため、ここでは、その説明を省略する。但し、ここでは、リーチャ50は、シーダとして機能する場合、各ピースC1〜CNのうち少なくとも2つのピースに対応する暗号化ピースを保持しており、更に、そのうち少なくとも1つのピースについては異なる2つ以上の暗号鍵で各々暗号化された暗号化ピースを保持しているものとする。
<鍵サーバ53の構成>
次に、鍵サーバ53のCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図12は、鍵サーバ53の機能的構成を例示する図である。鍵サーバ53は、制御部530と、パケット処理部531と、ネットワークインターフェース部532と、認証・鍵交換処理部533と、鍵記憶部534と、シーケンス情報記憶部536と、シーケンス情報照合部535と、鍵供給部537とを有する。制御部530と、シーケンス情報照合部535と、ネットワークインターフェース部532と、パケット処理部531と、認証・鍵交換処理部533と、鍵供給部537との実体は、CPUのプログラム実行時にRAMなどの記憶装置上に生成されるものである。鍵記憶部534は、例えば、外部記憶装置に記憶されるものである。
制御部530は、鍵サーバ53全体を制御し、シーケンス情報照合部535から鍵供給部537への指示を仲介したりする。パケット処理部531は、リーチャ50などの外部装置に送信する各種データをパケット化してネットワークインターフェース部532に受け渡したり、ネットワークインターフェース部532から受け渡されたパケットを基にデータを取得したりする。ネットワークインターフェース部532は、外部装置との通信を制御し、パケット処理部531から受け渡されたパケット化されたデータを送信したり、外部装置から受信したパケットをパケット処理部531に受け渡したりする。
認証・鍵交換処理部533は、ネットワークインターフェース部532を介して、リーチャ50と相互認証を行い、認証後、インデックス情報をリーチャ50から受信する。
鍵記憶部534は、例えば、HDDなどの外部記憶装置において構成され、各暗号化ピースを各々復号するための各復号鍵を各々記憶する。各復号鍵は、上述したように、例えばK ( i, j )として表される。
シーケンス情報記憶部536は、例えばHDDなどの外部記憶装置において構成され、リーチャ50に過去に送信した全ての鍵束に各々対応するシーケンスを示すシーケンス情報を記憶する。鍵束に各々対応するシーケンスは、上述したインデックス情報に示されるシーケンスと同様に、例えば以下のように表される。
{ ( i1, 1 ), ( i2, 2 ), …, ( iN, N) }
(ただし、1≦i1, …, iN≦m)
シーケンス情報照合部535は、シーケンス情報記憶部536に記憶されたシーケンス情報と、リーチャ50から受信したインデックス情報とを照合することにより、インデックス情報によって示されるシーケンスに対応する鍵束を送信するか否かを決定する。具体的には、シーケンス情報照合部535は、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部536に記憶されていない場合、インデックス情報によって示されるシーケンスに対応する鍵束を送信することを決定する。鍵束は、例えば、以下のように表される。ここでは、各ピースC1〜CNに各々対応する復号鍵が左から順に配列されて表されている。
{K( i1, 1 ), K( i2, 2 ), …, K( iN, N )}
(ただし、1≦i1, …, iN≦m)
そして、シーケンス情報照合部535は、鍵束を送信することを決定した場合、制御部530を介して、当該鍵束を当該リーチャ50へ送信するよう鍵供給部537に指示する。また、シーケンス情報照合部535は、鍵束を送信しないことを決定した場合、制御部530を介して、当該鍵束の当該リーチャ50への送信禁止を鍵供給部537に指示する。
鍵供給部537は、制御部530を介してシーケンス情報照合部535から鍵束の送信を指示されると、当該鍵束のシーケンスに応じた復号鍵を鍵記憶部534から各々読み出し、読み出した各復号鍵を含む鍵束を、ネットワークインターフェース部532を介してリーチャ50に送信する。
<トラッカ51の構成>
次に、トラッカ51の構成について説明する。トラッカ51は、リーチャ50からアクセスされると、P2PネットワークNTに接続されているノードにアクセスするためのノード情報を当該リーチャ50に対して送信する。ノード情報は、各ノードのIPアドレスとポート番号との組を含んでいる。図13は、ノード情報のデータ構成を例示する図である。同図においては、ノードA〜Bは各々、リーチャ50A〜50B、シーダ52A〜52Cのいずれかであり、当該各ノードのIPアドレスとポート番号との組が示されている。
(2)動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について図14を用いて説明する。尚、リーチャ50は、暗号化ピースを他のリーチャ50からも受信可能であるが、ここでは、説明の便宜上、暗号化ピースをシーダ52A〜52Cからの少なくとも1つから受信するものとする。
リーチャ50は、まず、販売サーバ54にアクセスして、Torrent Fileを取得する(ステップS1)。そして、リーチャ50は、Torrent Fileに含まれるトラッカ情報に含まれるトラッカ接続先情報を用いてトラッカ51にアクセスすると(ステップS2)、トラッカ51はリーチャ50に対して、ノード情報を送信する(ステップS3)。リーチャ50は、ノード情報を受信すると(ステップS4)、ノード情報を用いて、例えばシーダ52A〜52Cの少なくとも1つにアクセスする(ステップS5)。シーダ52は、リーチャ50からアクセスされると、図8に示したように、自身の保持する暗号化ピースのピースインデックスを示すピース情報をリーチャ50へ送信する(ステップS6)。リーチャ50は、ピース情報を受信すると(ステップS7)、取得したいピースのピースインデックスが少なくとも示されているピース情報を送信したシーダ52にアクセスする(ステップS8)。そして当該シーダ52に対して暗号化ピースを要求するピース要求をリーチャ50は送信する。一方、シーダ52は、優先ピースインデックス選定処理を行い、リーチャ50からピース要求を受信した場合には、当該ピース要求に応じて、暗号化ピース送信処理を行う(ステップS9)。
ここで、シーダ52が行う優先ピースインデックス選定処理及び暗号化ピース送信処理について図15を用いて説明する。シーダ52は、まず、優先ピースインデックス選定処理を行う(ステップS20)。図16は優先ピースインデックス選定処理の詳細な手順を示すフローチャートである。シーダ52は、送信状況テーブルを参照して、優先ピースインデックスが初期状態であるか否か、即ち、優先ピースインデックスフラグ‘1’が設定されているものがないか否かを判断する(ステップS100)。当該判断結果が否定的である場合、即ち、優先ピースインデックスが初期状態でない場合、シーダ52は、既に設定されている優先ピースインデックスフラグを利用するので、優先ピースインデックス選定処理を終了する。当該判断結果が肯定的である場合、即ち、優先ピースインデックスが初期状態である場合、シーダ52は、送信状況テーブルの各ピースインデックスjの暗号化ピース列jのそれぞれの送信回数を参照し(ステップS101)、暗号化ピース列毎に当該暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースの個数を計数する。そして、シーダ52は、暗号化ピース列毎に計数した未送信暗号化ピースの個数が最も多いピースインデックスを検索する(ステップS102)。なお、この際に未送信暗号化ピースがある暗号化ピース列が存在しない場合には、現段階で自身が保持する全ての暗号化ピースをシーダ52が送信していることを意味する。この場合、シーダ52は、本方式によらずにピース要求に応じて暗号化ピースをリーチャ50に提供したり、暗号化ピースの提供を止めたりしても良い。また、その後、何らかの経路で未送信の暗号化ピースが追加された場合には、シーダ52は、その暗号化ピースのピースインデックスを優先ピースインデックスとして選定して暗号化ピースの提供を再開しても良い。
ステップS102の後、シーダ52は、検索して得られたピースインデックスが唯一であるか否かを判断し(ステップS103)、当該判断結果が肯定的である場合、このピースインデックスを優先ピースインデックスとして選定する(ステップS105)。そして、シーダ52は、送信状況テーブルにおいて、優先ピースインデックスとして選定したピースインデックスに対応する優先ピースインデックスフラグを‘1’に設定する。ステップS103の判断結果が否定的である場合、未送信暗号化ピースの個数が同数であるピースが複数存在するということであり、優先ピースインデックスの候補が複数存在するということである。この場合、シーダ52は、それらのピースインデックスの中から一つのピースインデックスをランダムに選択し(ステップS104)、これを優先ピースインデックスとして選定する。そして、シーダ52は、上述と同様にして送信状況テーブルにおける優先ピースインデックスフラグの値を設定する(ステップS105)。
図15に戻り、その後、シーダ52は、リーチャ50からピース要求を受信すると(ステップS21:YES)、暗号化ピース送信処理を行うことになる。暗号化ピース送信処理では、シーダ52は、まず、ピースインデックス決定処理を行う(ステップS22)。ここでは、シーダ52は、優先ピースインデックス、即ち、送信状況テーブルにおいて優先ピースインデックスフラグが‘1’が設定されているピースインデックスを、リーチャ50に送信する候補とする暗号化ピースのピースインデックスとして決定する。
そして、シーダ52は、送信候補とする暗号化ピースのピースインデックスを決定できたか否かを判断して(ステップS23)、当該判断結果が肯定的である場合、次いで、バリエーションインデックス決定処理を行う(ステップS24)。ステップS23の判断結果が否定的である場合には、シーダ52は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ50に送信して、新たなピース要求を待ち受ける。尚、ここで、シーダ52はリーチャ50に通知メッセージを送信しなくても良い。この場合、シーダ52の処理負荷を軽減することができる。
図17はバリエーションインデックス決定処理の手順を示すフローチャートである。シーダ52は、まず、上述のピースインデックス決定処理で決定したピースインデックスを取得する(ステップS500)。そして、シーダ52は、そのピースインデックスをキーとして送信状況テーブルを参照して(ステップS501)、当該ピースインデックスの暗号化ピース列に未送信暗号化ピースが存在するか否かを判断する(ステップS502)。当該判断結果が否定的である場合には、シーダ52は、バリエーションインデックスを決定せずに、バリエーションインデックス決定処理を終了する。尚、ステップS502の判断は、シーダ52が暗号化ピース送信処理を多数のリーチャに対して並行して行う場合などにも未送信暗号化ピースが存在するか否かの判断を正確にするために行っている。しかし、この判断は、暗号化ピース送信処理を多数のリーチャに対して並行して行わない場合には省略しても良い。
さて、ステップS502の判断結果が肯定的である場合には、次いで、シーダ52は、ステップS500で取得したピースインデックスの暗号化ピース列における未送信暗号化ピースの個数を確認する(ステップS503)。この未送信暗号化ピースの個数が1つである場合、即ち、バリエーションインデックスが唯一に決定される場合、シーダ52は、当該未送信暗号化ピースのバリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する(ステップS505)。そして、シーダ52は、当該バリエーションインデックス決定処理を終了する。また、ステップS503で、未送信暗号化ピースの個数が複数ある場合、当該未送信暗号化ピースのバリエーションインデックスの中から1つのバリエーションインデックスをランダムに選択し(ステップS504)、当該バリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する(ステップS505)。そして、シーダ52は、当該バリエーションインデックス決定処理を終了する。なお、バリエーションインデックスの候補が複数ある場合その中から1つのバリエーションインデックスを、シーダ52は、ランダムに選択するのではなく、候補となるバリエーションインデックスに対応する暗号化ピースのP2PネットワークNTでの流通状況などに基づいて選択するようにしても良い。
図15に戻り、シーダ52は、ステップS22で決定したピースインデックスjと、ステップS24で決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースを外部記憶装置に実際に記憶しているか否かを判断する(ステップS25)。そして、当該判断結果が肯定的である場合、シーダ52は、当該暗号化ピースを外部記憶装置から読み出してこれをリーチャ50に送信する(ステップS26)。ステップS25における判断結果が否定的である場合、シーダ52は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ50に送信して、新たなピース要求を待ち受ける。尚、ここで、シーダ52はリーチャ50に通知メッセージを送信しなくても良い。
また、ステップS26の後、シーダ52は、送信した暗号化ピースに応じて、送信状況テーブル更新処理を行う(ステップS27)。図18は送信状況テーブル更新処理の手順を示すフローチャートである。シーダ52は、送信した暗号化ピースのピースインデックスj及びバリエーションインデックスiを取得して(ステップS800)、送信状況テーブルにおいて、当該インデックス(i,j)に対応する送信回数を1つ増やす(ステップS801)。次いで、シーダ52は、優先ピースインデックスの初期化条件が成立するか否かを判断する。具体的には、シーダ52は、優先ピースインデックスに対応する未送信暗号化ピースが存在するか否か、即ち、優先ピースインデックスフラグが‘1’に設定されているピースインデックスの暗号化ピース列において送信回数が‘0’の暗号化ピースが存在するか否かを判断する(ステップS802)。当該判断結果が肯定的である場合、シーダ52は、送信状況テーブル更新処理を終了する。ステップS802の判断結果が否定的である場合、即ち、優先ピースインデックスに対応する未送信暗号化ピースが存在しない場合、シーダ52は、送信状況テーブルにおいて全てのピースインデックスに対応付けられてる優先ピースインデックスフラグの値を‘0’に設定することにより優先ピースインデックスを初期化する(ステップS803)。そして、シーダ52は、送信状況テーブル更新処理を終了する。
一方、リーチャ50は、シーダ52から暗号化ピースを受信すると、コンテンツを構成する全てのピースC1〜CNに各々対応する暗号化ピースが取得できていない場合には、次いで、他のシーダ52(例えばシーダ53C)にアクセスする。そして、当該他のシーダ53Cからピース情報をリーチャ50は取得する。そして、リーチャ50は、上述と同様にして、ピース情報を用いて他のシーダ52にアクセスして、当該暗号化ピースの取得を試みる。リーチャ50は、このような処理を繰り返して、各暗号化ピースから構成される暗号化コンテンツ{E( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N ))[ CN ]}を得る。また、リーチャ50は、特定のシーダ52や他のリーチャ50などの通信相手から暗号化ピースを受信できない場合には、他の通信相手に同じ暗号化ピースを要求したり、同じ通信相手に違う暗号化ピースを要求したりしてもよい。
リーチャ50は、コンテンツを構成する各ピースに各々対応する暗号化ピースであって暗号化コンテンツを構成する全ての暗号化ピースを取得すると、各暗号化ピースを各々復号するための各復号鍵を含む鍵束を要求する要求メッセージを鍵サーバ53に送信する(ステップS10)。この要求メッセージには、各復号鍵に対応するシーケンスを示すインデックス情報{( i1, 1 ),…, ( iN, N)}が含まれる。
鍵サーバ53の認証・鍵交換処理部533は、ネットワークインターフェース部532を介して、当該要求メッセージを受信すると(ステップS11)、当該リーチャ50と相互認証を行い、認証成功の場合、要求を受理する旨の受理メッセージをリーチャ50に送信する(ステップS12)。リーチャ50は、鍵サーバ53から受理メッセージを受信すると(ステップS13)、鍵サーバ53からの鍵束の送信を待機する。
一方、鍵サーバ53のシーケンス情報照合部535は、ステップS11で受信された要求メッセージに含まれるインデックス情報を用いて、照合処理を行う(ステップS14)。図19は、照合処理の手順を示すフローチャートである。照合処理では、シーケンス情報照合部535は、ステップS11で受信された要求メッセージに含まれるインデックス情報と、シーケンス情報記憶部536に記憶されているシーケンス情報とを照合し(ステップS140)、インデックス情報に示されるシーケンスと同一のシーケンスを示すシーケンス情報がシーケンス情報記憶部536に記憶されている否かを判断する(ステップS141)。即ち、リーチャ50から要求されている鍵束が過去にリーチャ50のいずれかに送信されたか否かが判断される。
当該判断結果が否定的である場合(ステップS141:NO)、シーケンス情報照合部535は、インデックス情報に示されるシーケンスに対応する鍵束{K( i1, 1 ), K( i2, 2 ), …, K( iN, N )}を送信することを決定する。そして、シーケンス情報照合部535は、制御部530を介して、当該鍵束を当該リーチャ50へ送信するよう鍵供給部537に指示する。また、シーケンス情報照合部535は、当該シーケンスを示すシーケンス情報をシーケンス情報記憶部536に記憶させる(ステップS142)。鍵供給部537は、制御部530を介してシーケンス情報照合部535から送信を指示された鍵束を、鍵記憶部534から読み出しこれをネットワークインターフェース部532を介してリーチャ50に送信する(ステップS143)。尚、ステップS141の判断結果が肯定的である場合、シーケンス情報照合部535は、当該鍵束を送信しないことを決定し、制御部530を介して、当該鍵束の当該リーチャ50への送信禁止を鍵供給部537に指示する(ステップS144)。
図14に戻り、リーチャ50は、鍵束K( i1, 1 ), K( i2, 2 ), …, K( iN, N )を鍵サーバ53から受信した場合(ステップS15:YES)、鍵束に含まれる各復号鍵を用いて、各暗号化ピースE( K( i1, 1 ) )[ C1 ], E( K( i2, 2 ) )[ C2 ], …, E( K( iN, N )[ CN ])をそれぞれ復号し(ステップS16)、復号した各ピースC1〜CNを得て、これらから構成されるコンテンツCを得る。即ち、リーチャ50は、復号鍵K( i1, 1 )を用いてE( K( i1, 1 ) )[ C1 ]を復号して、ピースC1を得て、復号鍵K( i2, 2 )を用いてE( K( i2, 2 ) )[ C2 ]を復号して、ピースC2を得て、復号鍵K( iN, N )を用いてE( K( iN, N )[ CN ]を復号して、ピースCNを得て、他のピースについても同様にして得ることにより、各ピースC1〜CNから構成されるコンテンツCを得る。
尚、リーチャ50は、ステップS15で鍵束を受信することなく、図19のステップS143で鍵サーバ53から送信されたエラーメッセージを受信した場合、ステップS10で取得した各ピースを復号することができず、従って、コンテンツを利用できない。この場合、ステップS5に戻り、リーチャ50は、ステップS10で取得したシーケンスとは異なるシーケンスで各暗号化ピースを取得した後に、ステップS10以降の処理を再度行う。
以上のように、P2PネットワークNTを介して、同一のコンテンツを複数のリーチャ50に配信する場合、暗号化ピースのシーケンスを用いて、鍵サーバ53が鍵束の送信の可否を決定する。ここで、鍵サーバ53が、既に使用されたシーケンスの再使用を回避することにより、コンテンツをリーチャ50毎に個別化することができる。従って、例えば、1つの鍵束が漏洩したとしても、この鍵束に対応する暗号化コンテンツのみしか復号することができないので、コンテンツの不正使用を抑制することができる。また、予め定められたシーケンスではなく、リーチャ50が任意に取得した暗号化ピースにより定まるシーケンスを用いることにより、P2PネットワークNTの環境に応じたフレキシブルなコンテンツ配信を実現することができる。
また、以上においては、シーダ52は、リーチャ50からのピース要求に応じて暗号化ピースの送信を行うものの、自身が保持する暗号化ピースについて、未送信の暗号化ピースを全て送信することを優先して行う。即ち、シーダ52は、コンテンツ配信システムにおいて配信される暗号化されたコンテンツの一部であるピースを他の通信装置に送信するにあたって、同一のピースが複数の異なる鍵で暗号化された複数の暗号化ピースのうち自身の保持する暗号化ピースを全て送信されるまでは、他のピースを提供しない。このような構成によれば、複数のリーチャ50が同時期にシーダ52から取得する暗号化ピースが同じピースインデックスの暗号化ピースである可能性を高めることができる。従って、リーチャ同士がピースを共有することを抑制することができる。なぜなら、自身が既に保持している暗号化ピースを再取得するのはコストがかかるため、通常、暗号化ピースの共有や交換は、自身の保持しないピースインデックスの暗号化ピースが相手側から提供されることにより行われるからである。従って、本実施の形態における構成によれば、同一のピースに対する暗号化ピースのバリエーションを提供しきる間にリーチャ間で暗号化ピースを共有したり交換したりする機会を減らすことができる。即ち、複数の異なる暗号鍵で暗号化されたピースが送信される機会が増加して、P2PネットワークNT上に存在する暗号化ピースのバリエーションを増加させることができ、リーチャ50毎に異なった暗号化ピースを取得する可能性を高めることができる。その結果、配信される暗号化されたコンテンツの鍵が漏洩した場合の影響を軽減することができる。
以上、第1の実施の形態について説明したが、当該実施の形態に多様な変更または改良を加えることができる。
(3)変形例
<変形例1>
上述の実施の形態においては、Torrent Fileは上述のものに限らず、例えば、ファイル情報は、各暗号化ピースのハッシュ値を含んでいても良い。各暗号化ピースのハッシュ値とは、例えば以下のように表される。
{ hash( E( K( i, j ) )[ Cj ] ) }
(ただし、1≦i≦m、1≦j≦N)
図20は、このようなTorrent Fileのデータ構成を例示する図である。リーチャ50は、これらm×n個のハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。更に、このようなTorrent Fileに対し、Torrent Fileの生成者又は信頼できる第三者(例えば、コンテンツ製作者)がディジタル署名を付加しても良い。この場合、リーチャ50は、受信した各暗号化ピースの完全性に加えて正当性も確認することができる。
このような構成においては、更に、シーダ52は、ハッシュ値を含むピース情報をリーチャ50に送信するようにしても良い。図21は、ハッシュ値を含むインデックス情報を例示する図である。この場合も、リーチャ50は、ハッシュ値を用いて、受信した各暗号化ピースの完全性を確認することができる。
また、ファイル情報は、全てのインデックス(上記の例では1≦i≦m、1≦j≦Nの全ての( i, j ))についてのものである必要はなく、その一部についてのものであってもよい。
また、Torrent Fileにそのバージョン番号や有効期限情報を含めてもよい。この場合、リーチャ50は、取得したTorrent Fileがその時点において有効であるか否かを知ることができる。例えば、ある時点において取得したTorrent Fileが有効でない場合、リーチャ50はより新しいTorrent Fileを取得してもよいし、前記ある時点において取得したTorrent Fileを用いて暗号化ピースの取得を始め、シーダ52が(リーチャ50にとって)未知のインデックスに対応する暗号化ピースを保持している場合、シーダ52から前記未知のインデックスに対応する暗号化ピースを受信し、その受信後により新しいTorrent Fileを取得して受信した各暗号化ピースの完全性や正当性を確認してもよい。
<変形例2>
上述の実施の形態においては、リーチャ50は、ステップS10で、インデックス情報を要求メッセージに含ませて鍵サーバ53に送信したが、これに限らず、受理メッセージを受信した後にインデックス情報を鍵サーバ53へ送信してもよい。
<変形例3>
上述の実施の形態においては、ノード情報は、上述のものに限らず、ノードのIPアドレスとポート番号との組の代わりに、ノードのURLを含むようにしても良いし、ノードのIPアドレスとポート番号との組に加えて、ノードのURLが含まれていても良い。
<変形例4>
上述のステップS6では、シーダ52は、リーチャ50からのアクセスにより、自身の保持するピースのシーケンスを示すピース情報を送信したが、リーチャ50からのアクセスを待たずに、ピース情報を当該リーチャ50へ送信するようにしても良い。
<変形例5>
上述のステップS9では、シーダ52は、暗号化ピースをリーチャ50に送信したが、これに加えて、対応するインデックスを送信しても良い。例えば、送信する暗号化ピースがE( K( 1, 1 ) )[ C1 ]である場合、これに加えて、対応するインデックス( 1, 1 )をシーダ52はリーチャ50に送信しても良い。
<変形例6>
上述の実施の形態においては、リーチャ50は、暗号化ピースをシーダ52から受信するようにしたが、これに限らず、他のリーチャ50から暗号化ピースを取得するようにしても良い。また、鍵サーバ53や他のサーバが、暗号化ピースを送信する上述のシーダ52と同様の機能を有するように構成し、これからリーチャ50は暗号化ピースを取得するように構成しても良い。
<変形例7>
上述の実施の形態においては、各ピースC1〜CNを区別するためのインデックスjをピースインデックスとして取り扱ったが、コンテンツを構成するピースの順序と暗号化ピースの順序とは必ずしも同じでなくても良い。この場合、暗号化ピースを、コンテンツを構成するピースの順序に並び替えた場合の順序をピースインデックスとして取り扱えば良い。
<変形例8>
上述の送信状況テーブルにおいては、優先ピースインデックスを指し示すものとして、優先インデックスフラグを用いたが、これに限らず、優先ピースインデックスとして選定したピースインデックスの値自体を送信状況テーブルに記録するようにしても良い。
<変形例9>
上述のステップS20の優先ピースインデックス選定処理においては、優先ピースインデックスの候補となるピースインデックスが複数存在した場合は、シーダ52は、その中から1つをランダムに選択するとした。しかし、これに限らず、例えば、複数の候補の各ピースインデックスに対応する各暗号化ピース列に属する暗号化ピースのバリエーションインデックスの最大値が大きい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスをシーダ52は選択して、これを優先ピースインデックスとして選定するようにしても良い。このような構成によれば、同一のピースに対する暗号化ピースのバリエーションの数を重要度に応じて増やすという構成とした場合に、重要度が高い暗号化ピース程優先して送信することが可能となる。このため、鍵の漏洩による影響を限定することができる。
又は、複数の候補のピースインデックスの値が小さい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスを優先ピースインデックスとして選定するようにしても良い。このような構成によれば、シーダ52は、コンテンツの先頭のピースから順にそれに対応する暗号化ピースを送信することが可能となる。例えば、ピースインデックスの順序が、コンテンツを構成するピースの順序(再生順序)と同じであるとし、受信側のリーチャ50が暗号化ピースを先頭から順次復号して再生するという構成とした場合に、鍵の漏洩の影響を軽減しつつ、復号処理及び再生処理の遅延を防ぐことができる。また、ピースの順序と暗号化ピースの順序とが同じではなくその対応付けがランダムであるような場合には、暗号化ピースの順序としてのピースインデックスの値の大小ではなく、対応するピース自体の順序によって優先的にピースインデックスを優先ピースインデックスとして選定する構成としても良い。また、逆に、候補のピースインデックスの値が大きい程優先順位が高くなるように設定し、優先順位が最も高いピースインデックスを優先ピースインデックスとして選定するようにしても良い。このように、値の大きいピースインデックスを優先して送信することで、リーチャ50が、暗号化ピースを取得して直ぐに暗号鍵の取得や再生を行うことを防ぐことができる。このため、P2PネットワークNTにおいて暗号化ピースの送受信が行われる時間を確保して、再生までにかかる時間を平滑化することもできる。
又は、シーダ52自身が収集可能な周辺の暗号化ピースの分布状況に基づいて、複数の優先ピースインデックスの候補の中から1つを選択するようにしても良い。シーダ52の周辺の暗号化ピースの分布状況は、例えば、P2PネットワークNTにおいてシーダ52の周辺に存在するリーチャ50から、リーチャ50が既に取得した暗号化ピースのピースインデックスとバリエーションインデックスとを示すリストを取得してこれを分析することにより得るようにしても良い。また、シーダ52の周辺の暗号化ピースの分布状況を既に取得可能なトラッカ51から当該分布状況をシーダ52は取得するようにしても良い。この場合、シーダ52は、優先ピースインデックスの候補となるピースインデックスのうち、当該ピースインデックスに対応する暗号化ピース列に属する暗号化ピースの分布総数が最小のピースインデックスや、複数の暗号化ピースの送信回数の開きが大きく分布に偏りがあるピースインデックスを優先して、優先ピースインデックスとして選定する。このような構成によれば、暗号化ピースのその時点での分布状況に適したピースインデックスを優先ピースインデックスとして選定することができる。
<変形例10>
上述の変形例9において、優先ピースインデックスの候補が複数存在した場合の優先ピースインデックス選定処理の各変形例について説明したが、各変形例において優先ピースインデックスを選定する各選定基準のそれぞれに重み付けをして、これらを組み合わせて利用しても良い。また、未送信暗号化ピースの個数が同数のときの選定基準としてではなく、優先ピースインデックスの選定において、未送信暗号化ピースの個数と組み合わせて利用しても良い。この場合は、他の選定基準(例えば、バリエーションインデックスの値の大きさ)によっては、未送信暗号化ピースの個数が最大ではないピースインデックスが、優先ピースインデックスとして選定される。このような構成によれば、より柔軟で状況に応じた優先ピースインデックスの選定が可能となる。
<変形例11>
上述の実施の形態においては、シーダ52は、ピース要求に対して一つの暗号化ピースを送信するとしたが、一度に複数の暗号化ピースを送信しても良い。即ち、シーダ52は、優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースが複数ある場合これを一度にリーチャ50に送信するようにしても良い。但し、シーダ52は、ピース要求に対して図15のステップS24〜ステップS26を行った後にステップS27の送信状況テーブル更新処理を行い、複数の暗号化ピースの送信途中で、優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースがなくなった場合には、ステップS20の優先ピースインデックス選定処理を行って優先ピースインデックスを更新して、新たな優先ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースを送信しても良い。このように同一の暗号化ピース列から複数の暗号化ピースを送信する構成とすることで、シーダ52は特定の暗号化ピース列の暗号化ピースを素早く送信済みとすることができる。特に、バリエーションインデックスの最大値の大きい暗号化ピースに関して効果が大きい。また、暗号化ピースを受信するリーチャ50の帯域速度や他のリーチャ50との接続数に応じて暗号化ピースを提供することで、鍵の漏洩の影響の限定を意図して暗号化ピースを提供することができる。例えば、帯域が大きいリーチャ50には帯域が狭いリーチャ50よりも複数の暗号化ピースを送信しておくことで、そのリーチャ50が暗号化ピースを送信する側となった場合に単一の暗号化ピースを他のリーチャ50に高速に送信して、他のリーチャ50と共有してしまうことを避けることが可能である。
<変形例12>
上述のステップS27の送信状況テーブル更新処理において、優先ピースインデックスの初期化を、優先ピースインデックスに対応する暗号化ピース列に未送信暗号化ピースが存在しない場合に行うようにしたが、これに限らず、例えば、当該未送信暗号化ピースの個数がその暗号化ピース列のバリエーションインデックスに占める割合が閾値以下である場合に行うようにしても良い。また、優先ピースインデックスが設定されてから一定時間が経った場合に、優先ピースインデックスの初期化を行うようにしても良い。このような構成とすることで、リーチャ50の総数よりもバリエーションインデックスの数が多い場面で、暗号化ピース列における暗号化ピースのバリエーションを提供しきることが難しい状況であっても、以下のような効果が得られる。例えば、優先ピースインデックスに対応する暗号化ピースを既に受信したリーチャ50が他のピースインデックスの暗号化ピースを受信することを円滑に進めることができる。
また、優先ピースインデックスの初期化を行うか否かの判断は、判断時点で自身に接続しているリーチャ50の数(リーチャ数という)とその時点での優先ピースインデックスに対応する暗号化ピースのバリエーションインデックスの個数(以降、対象バリエーション数という)との関係に応じて行うようにしても良い。この場合、シーダ52は、自身に接続しているリーチャ50の数(リーチャ数)を検出する手段を有しており、ステップS802において、その手段によって検出したリーチャ数と対象バリエーション数とを比較する。そして、リーチャ数が対象バリエーション数より小さい場合には、シーダ52は、送信済である暗号化ピースのバリエーションインデックスの個数がリーチャ数と等しいか否かを判断する。そしてこれらの数が等しいことを初期化条件として、ステップS803と同様にして、シーダ52は優先ピースインデックスの初期化を行う。そして、シーダ52は、この段階のリーチャ数を初期化時リーチャ数として、またこの時点での優先ピースインデックスを初期化前優先ピースインデックスとして記憶しておく。そして、次に優先ピースインデックス選定処理を行うときには、シーダ52は、その時点でのリーチャ数と初期化時リーチャ数とを比較する。このとき、リーチャ数の方が初期化時リーチャ数より大きい場合、シーダ52は、初期化前優先ピースインデックスを優先ピースインデックスとして再設定する。リーチャ数が初期化時リーチャ数と等しいか又は初期化時リーチャ数より少ない場合には、シーダ52は、初期化前優先ピースインデックスを優先ピースインデックスの候補から外して、優先ピースインデックス選定処理を行う。ここで、リーチャ数の増加があった場合には、シーダ52は、初期化前優先ピースインデックスを優先ピースインデックスとして設定し得るが、そうではなく、初期化前優先ピースインデックスを優先ピースインデックスの候補の一つに加えるように構成しても良い。
なお、全てのバリエーションインデックスに対応する暗号化ピースを送信しきらないうちに優先ピースインデックスを更新し、結果的にそのピースインデックスの暗号化ピースの鍵の漏洩の影響を軽減するために、リーチャ数が対象バリエーション数を超えるまではシーダ52は暗号化ピースの提供をどのリーチャ50に対しても行わないように構成しても良い。またシーダ52は、優先ピースインデックス選定処理において、その時点でのリーチャ数よりも未送信暗号化ピース数が少ないピースインデックスのみを、優先ピースインデックスを選定する処理の対象とするようにしても良い。また、シーダ52は、優先ピースインデックス選定処理において優先ピースインデックスを更新する場合には、更新前のピースインデックスとその時点でのリーチャ数を記憶しておく。そして、シーダ52は、次の優先ピースインデックス選定処理でリーチャ数に変化が生じている場合、更新前のピースインデックスを優先して優先ピースインデックスとして設定できるか否かを判断するようにしても良い。このように構成することで、全てのバリエーションインデックスに対応する暗号化ピースを送信しきっていないピースインデックスについて、その暗号化ピースが多くのリーチャ50に共有される前に、他のピースインデックスに対応する暗号化ピースを送信することができるようになる。また、シーダ52における暗号化ピースの配信効率と両立するために、未送信暗号化ピースの個数がその暗号化ピース列のバリエーションインデックスに占める割合が閾値以下である場合に優先ピースインデックスの初期化を行うという上述の変形例における構成と組み合わせても良い。このような構成とすることで、対象バリエーション数がリーチャ数よりも多く、リーチャ数が対象バリエーション数よりも増加しないような場合でも、暗号化ピースの配信が可能となる。
また、上述のステップS27の送信状況テーブル更新処理において、ステップS802で、未送信暗号化ピースが存在する場合には、シーダ52は、優先ピースインデックスを更新する更新イベントを発生させるタイマを上書き方式により設定し、このタイマによって更新イベントを割り込みさせるように構成しても良い。図22は、本変形例にかかる送信状況テーブル更新処理の手順を示すフローチャートである。ステップS800〜S803の処理は上述の第1の実施の形態と同様である。ここでは、ステップS802の判断結果が肯定的である場合に、ステップS804で、シーダ52は、タイマによって更新イベントの割り込みを設定する。そして、更新イベントの割り込みが発生すると、ピースインデックス決定処理では、シーダ52は、その時点で設定されている優先ピースインデックスを除外したピースインデックスを対象として処理を行う。このピースインデックス決定処理は、初期状態が否かを確認する点と、その前に設定されていたピースインデックスを処理の対象外とする点とを除いて、上述のステップS20の処理と同様である。このような構成とすることで、リーチャ50の総数よりも対象バリエーション数が多く、新たなリーチャ50が暗号化ピースの受信を要求してこない状況であっても、優先ピースインデックスに対応する暗号化ピースを既に受信したリーチャ50が他のピースインデックスの暗号化ピースの受信を円滑に進めることができるような配信形態とすることができる。
また、上記したように、シーダ52が、設定した優先ピースインデックスに対応する暗号化ピース列に属する全てのバリエーションインデックスに対応する暗号化ピースを送信しきっていない事態が想定される場合、シーダ52は、優先ピースインデックスを新たに選定する時に、選定する前に優先ピースインデックスとして設定されていたピースインデックスに対して未送出フラグを送信状況テーブルにおいて設定するようにしても良い。そして、シーダ52は、ピースインデックス決定処理において、優先ピースインデックスフラグを用いて送信候補とする暗号化ピースのピースインデックスを決定する処理に加え、未送出フラグを用いて送信候補とする暗号化ピースのピースインデックスを決定する処理を適宜行うようにしても良い。即ち、シーダ52は、優先ピースインデックスフラグが‘1’に設定されているピースインデックス及び未送出フラグの値が‘1’に設定されているピースインデックスのうち少なくとも一方を優先ピースインデックスとして選定するようにしても良い。このような構成とすることで、未だ送信されていない暗号化ピースのバリエーションを提供する機会を設けることができる。また、優先ピースインデックスフラグによるピースインデックス決定処理と未送出フラグによるピースインデックス決定処理との優先順位を入れ替えることで、暗号化ピースの放出効率と暗号化ピースの配信効率とのどちらを優先させるのかを切り替えることができる。また、未送出フラグにより、送信候補とする暗号化ピースのピースインデックスを決定する場合に適用する優先順位としては、例えば、キュー構造であったりスタック構造であったりしても良いし、まったくランダムであっても良い。
<変形例13>
上述のステップS9でシーダ52が受信するピース要求には、本実施の形態にかかる暗号化ピース処理を行う通信装置向けのピース要求と、リーチャ50から要求に応じて無条件に暗号化ピースを提供する通信装置向けのピース要求との2つを含めておいて良い。P2PネットワークNTにおいて、リーチャ50から要求に応じて無条件に暗号化ピースを提供する通信装置が存在する場合であっても、ピース要求を受信した通信装置は、ピース要求に応じて適宜処理を行うことができ、リーチャ50に暗号化ピースを送信することができる。一方、リーチャ50は、ピース要求を送信する相手が前者の通信装置であるか後者の通信装置であるかに応じてメッセージの切り替えを行う必要がない。このため、リーチャ50が、前者の通信装置であるか後者の通信装置であるかをいちいち判断する必要がなく、リーチャ50の処理負担を軽減することができる。
また、上述のステップS9でシーダ52が受信するピース要求には、リーチャ50が指定するピースインデックスj(指定ピースインデックスという)とバリエーションインデックスi(指定バリエーションインデックスという)との組(i,j)を示すリストが含まれていても良い。この場合、ステップS22のピースインデックス決定処理では、シーダ52は、優先ピースインデックスと指定ピースインデックスとをそれぞれ比較して一致した場合に、当該指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する。そして、ステップS24のバリエーションインデックス決定処理では、シーダ52は、送信状況テーブルの送信回数を参照して、指定ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否か、即ち、当該暗号化ピースの送信回数が‘0’か否かを判断する。そして、当該判断結果が肯定的である場合、シーダ52は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ50に送信する。このような構成とすることで、リーチャ50は自身が所望した暗号化ピースが存在する場合には、それを効率的に取得することができる。
又は、上述のステップS9でシーダ52が受信するピース要求には、リーチャ50が指定するピースインデックスj(指定ピースインデックス)を示すリストが含まれていても良い。この場合、ステップS22のピースインデックス決定処理では、シーダ52は、優先ピースインデックスと指定ピースインデックスとをそれぞれ比較して一致した場合に、当該指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する。そして、ステップS24のバリエーションインデックス決定処理では、シーダ52は、送信状況テーブルにおいて、当該指定ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのバリエーションインデックスに対応する送信回数を参照して、当該暗号化ピース列に属する暗号化ピースのうち未送信暗号化ピースが存在するかを判断する。そして、当該判断結果が肯定的である場合、シーダ52は、当該未送信暗号化ピースのバリエーションインデックス及びピースインデックスに対応する暗号ピースを外部記憶装置から読み出してこれをリーチャ50に送信する。このような構成とすることで、リーチャ50は自身が所望したピースインデックスに対応する暗号化ピースを取得することができ、既に取得したピースインデックスに対応する暗号化ピースをシーダ52から送信されることを防止することができる。
<変形例14>
また、上述のステップS9でシーダ52が受信するピース要求には、リーチャ50が既にデータの一部を取得済みの暗号化ピース(一部取得済み暗号化ピースという)について未取得の部分のデータを要求する一部データ要求が含まれるようにしても良い。また、この一部データ要求と、データの全部を未取得の暗号化ピースを要求する未取得ピース要求とが区別されて各々含まれるようにしても良い。一部データ要求としては、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組(i,j)と、未取得の部分のデータのデータ範囲を指定する情報とを示すリストであっても良い。未取得ピース要求としては、未取得の暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組(i,j)を示すリスト又は指定ピースインデックスのみを示すリストであっても良い。図23は、本変形例にかかるピース要求のデータ構成を例示する図である。同図においては、一部データ要求として、例えば、(1,19)のインデックスに対応する暗号化ピースのデータのうち、100バイト目から400バイト目のデータが未取得のデータのデータ範囲として指定されていることが示されている。また、未取得ピース要求として、指定ピースインデックスのみを示すリストであることが示されている。
このような構成において、シーダ52は、ステップS22のピースインデックス決定処理では、優先ピースインデックスと、一部データ要求において示される指定ピースインデックスとを比較して、これらが一致した場合には、次のように処理をする。シーダ52は、ステップS24のバリエーションインデックス決定処理において、当該優先ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否かを判断する。そして、当該判断結果が肯定的である場合、シーダ52は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースのうち、指定されたデータ範囲のデータを外部記憶装置から読み出してこれをリーチャ50に送信する。このような構成とすることで、シーダ52はリーチャ50の保持するバリエーションインデックスを別途問い合わせる必要がなくなり、シーダ52とリーチャ50の処理負荷を削減できる。
また、一部データ要求に加え未取得ピース要求がピース要求に含まれる場合、シーダ52は、優先ピースインデックスと、一部データ要求において示される指定ピースインデックスとを比較してこれが一致しない場合に、優先ピースインデックスと、未取得ピース要求において示される指定ピースインデックスとを比較する。これらが一致した場合には、シーダ52は、ステップS24のバリエーションインデックス決定処理において、当該優先ピースインデクスに対応する暗号化ピース列に属する暗号化ピースのうち、指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースであるか否かを判断する。そして、当該判断結果が肯定的である場合、シーダ52は、当該指定バリエーションインデックス及び指定ピースインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ50に送信する。
また、一部データ要求において指定された指定バリエーションインデックスに対応する暗号化ピースが未送信暗号化ピースではない場合であっても、リーチャ50の一部取得済み暗号化ピースの完成を優先して、当該暗号化ピースを送信するようにしても良い。また、ピースインデックス決定処理において、優先ピースインデックスと一部データ要求において指定された指定ピースインデックスとを比較したときこれらが一致しない場合でも、指定ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定するようにしても良い。このような構成とすることで、リーチャ50は一部取得済み暗号化ピースについて必要なデータを優先して受信することができることから、暗号化ピースをより早く完成させることができるようになる。このため、その暗号化ピースを他のリーチャ50と共有できることから配信効率の向上が見こまれる。
尚、一部データ要求は、一部取得済み暗号化ピースを指定する指定ピースインデックス及び指定バリエーションインデックスの組(i,j)ではなく、指定ピースインデックスのみと、未取得のデータのデータ範囲を指定する情報とを示すリストであるようにしても良い。この場合のピースインデックス決定処理は上述と同様である。バリエーションインデックス決定処理では、シーダ52は、上述の実施の形態又は変形例に記載した少なくとも1つの方法又はその組み合わせによる方法で、送信対象の暗号化ピースのバリエーションインデックスを決定する。そして、ここでは、シーダ52は、ピースインデックス決定処理で決定したピースインデックスが、一部データ要求において指定されているか又は未取得要求において指定されているかを判断する。当該判断の結果、送信候補となる暗号化ピースのピースインデックスが未取得要求において指定されている場合、シーダ52は、当該ピースインデックス及び当該ピースインデックスに対応してバリエーションインデックス決定処理で決定したバリエーションインデックスに対応する暗号化ピースを外部記憶装置から読み出してこれをリーチャ50に送信する。一方、送信候補となる暗号化ピースのピースインデックスが一部データ得要求において指定されている場合、シーダ52は、一部取得済み暗号化ピースを指定する指定バリエーションインデックス及び未取得の部分のデータのデータ範囲を指定する情報を取得するための処理を行う。以下は当該処理の一例である。
まず、シーダ52は、送信候補の暗号化ピースのピースインデックスとして決定したピースインデックスをリーチャ50に通知する。ここで、シーダ52が、送信候補の暗号化ピースのピースインデックスを決定できなかった場合は、その旨を伝えるメッセージをリーチャ50に送信しても良いししなくても良い。前者の場合リーチャ50の処理効率が向上し得り、後者の場合シーダ52の処理効率及び攻撃耐性が向上し得る。一方、リーチャ50は、送信候補となる暗号化ピースのピースインデックスがシーダ52から通知されると、それに応答して、当該ピースインデックスに対応する一部取得済み暗号化ピースのバリエーションインデックス(指定バリエーションインデックス)を指定する情報及び未取得の部分のデータのデータ範囲を指定する情報をシーダ52へ送信する。シーダ52は、当該情報を受信すると、バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとを比較する。そして、これらが一致する場合は、シーダ52は、決定したピースインデックス及び指定バリエーションインデックスに対応する暗号化ピースのうち指定されたデータ範囲のデータを外部記憶装置から読み出してこれをリーチャ50に送信する。
バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとが一致しない場合には、シーダ52は、送信可能な暗号化ピースが存在しない旨をリーチャ50に通知しても良いし通知しなくても良い。この場合に期待される効果は上述の通りである。また、バリエーションインデックス決定処理で決定したバリエーションインデックスと、指定バリエーションインデックスとが一致した場合でも、指定されたデータ範囲によっては、シーダ52は、暗号化ピースの提供を拒否しても良い。例えば、データ範囲として暗号化ピースの先頭のデータから途中のデータまでが指定されているような場合である。これは、通常の暗号化ピースのやりとりでは先頭周辺のデータが欠損することは想定されないため、リーチャ50になんらかの攻撃意図があると判断することもできるからである。また、指定されたデータ範囲から想定される暗号化ピースの取得割合がある閾値を超えない場合なども、同様の理由により、暗号化ピースの提供を拒否する事例となりえる。
このように、指定されたデータ範囲によっても暗号化ピースを送信するか否かを判断することによって、通常想定されない動作をするリーチャ50による影響を排し、安全性を向上させることができる。即ち、以上のように、シーダ52は、送信の要求された暗号化ピースが、リーチャ50がデータの一部取得済みか又はデータの全部を未取得かで処理を分岐させることで、リーチャ50がデータの全部を未取得である暗号化ピースを提供する場合の処理負荷を軽減することができる。それとともに、一部取得済み暗号化ピースを提供する場合においても、シーダ52は、送信対象の暗号化ピースのバリエーションインデックスをリーチャ50に明かすことなく、更に、暗号化ピースの取得にある程度の手間をリーチャ50にかけさせることで、リーチャ50が数多くの暗号化ピースを無差別に取得しようとする行為に一定の抑止力を与えることができる。尚、ここではシーダ52はピースインデックスのみをリーチャ50に通知するとしたが、その際に、バリエーションインデックス決定処理で決定したバリエーションインデックスも併せて送信しても良い。この場合、リーチャ50は、当該暗号化ピースが自身の所望するものであるかどうかをより早く判断することができる。
[第2の実施の形態]
次に、コンテンツ配信システムの第2の実施の形態について説明する。なお、上述の第1の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
(1)構成
<シーダ52の構成>
本実施の形態にかかるコンテンツ配信システムにおいては、シーダ52の機能的構成が上述の第1の実施の形態におけるものと異なる。本実施の形態におけるシーダ52は、リーチャ50からのピース要求に応じて暗号化ピースの送信を行うものの、自身が保持する暗号化ピースについて、未送信の暗号化ピースを全て送信することを優先して行いつつ、配信効率の向上のために、場合によっては、未送信暗号化ピースを含まない暗号化ピース列の中から送信対象の暗号化ピースを選択してこれをリーチャ50に送信する。
図24は、本実施の形態にかかるシーダ52の機能的構成を例示する図である。シーダ52は、上述したピース情報送信部520と、ピース要求受信部521と、優先ピースインデックス選定部522と、ピースインデックス決定部523と、バリエーションインデックス決定部524と、送信状況テーブル更新部525と、ピース送信部526とに加え、送出済フラグ照会部527を有する。
送信状況テーブル更新部525は、上述の第1の実施の形態と同様にして、送信状況テーブルにおいて、送信回数の記録と優先ピースインデックスの初期化とを行う。更に、本実施の形態においては、送信状況テーブル更新部525は、優先ピースインデックスの初期化の際に、送信状況テーブルにおいて送出済フラグの値を設定する。図25は、本実施の形態にかかる送信状況テーブルのデータ構成を例示する図である。同図に示される送信状況テーブルにおいては、上述の第1の実施の形態と同様に、シーダ52が記憶している暗号化ピースのインデックス(i,j)に対応して各送信回数が記録されると共に、各暗号化ピース列に対して優先ピースインデックスフラグが対応付けられており、更に、本実施の形態においては、各暗号化ピース列に対して送出済フラグが対応付けられている。送出済フラグとは、優先ピースインデックスとして選定されたことのあるピースインデックスに対応する暗号化ピース列に属する暗号化ピースの全てを送信済であるか否かを示すものであり、初期値として‘OFF’が設定されている。送信状況テーブル更新部525は、優先ピースインデックスの初期化の際に、初期化前の優先ピースインデックスに対応する各暗号化ピース列に対する送出済フラグの値を‘ON’に設定する。
ピースインデックス決定部523は、ピース要求受信部521がピース要求を受信した場合、送信状況テーブルの優先ピースインデックスフラグを参照して、優先ピースインデックスとして選定されたピースインデックスが存在するか否かを判断し、当該判断結果が肯定的である場合は、上述の第1の実施の形態と同様である。当該判断結果が否定的である場合、ピースインデックス決定部523は、送出済フラグ照会部527を介して、送信状況テーブルにおいて送出済フラグが‘ON’に設定されているピースインデックスjが存在するか否かを判断する。そして、当該判断結果が肯定的である場合に、ピースインデックス決定部523は、送信候補とする暗号化ピースのピースインデックスjを決定する。
送出済フラグ照会部527は、送信状況テーブルの送出済フラグを参照して、送出済フラグが‘ON’に設定されているピースインデックスjを照会する。
ピース要求受信部521、優先ピースインデックス選定部522、バリエーションインデックス決定部524及びピース送信部526の各機能については上述の第1の実施の形態と略同様である。
尚、リーチャ50がシーダとして機能する場合の機能的構成についても、上述したシーダ52の機能的構成と略同様であるため、その説明を省略する。
(2)動作
次に、本実施の形態にかかるコンテンツ配信システムで行うコンテンツ配信処理の手順について説明する。尚、ここでも、リーチャ50は、暗号化ピースを他のリーチャ50からも受信可能であるが、説明の便宜上、暗号化ピースをシーダ52A〜52Cからの少なくとも1つから受信するものとする。本実施の形態にかかるコンテンツ配信処理の手順自体は上述の図14を用いて説明した通りである。本実施の形態においては図14のステップS9における暗号化ピース送信処理の手順の詳細が上述の第1の形態におけるものと異なる。図26は、本実施の形態にかかる優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。ステップS20では、シーダ52は、上述の第1の実施の形態と同様にして、優先ピースインデックス選定処理を行う。但し、ここでは、未送信暗号化ピースが存在しない状況であってもシーダ52は優先ピースインデックスを選定しないまま暗号化ピース送信処理を継続して暗号化ピースの送信を行うことを想定している。ステップS21〜S22までの処理は上述の第1の実施の形態と同様である。
ステップS30では、送信候補とする暗号化ピースのピースインデックスが決定されているか否か、即ち、送信状況テーブルにおいて優先ピースインデックスフラグが‘1’が設定されているピースインデックスが存在しその中から1つのピースインデックスが決定されているか否かをシーダ52は判断する。当該判断結果が肯定的である場合、上述の第1の実施の形態と同様にステップS24に進む。ステップS23の判断結果が否定的である場合は、ここでは、ステップS31に進む。ステップS31では、シーダ52は、送出済フラグ照会処理を行う。
図27は、送出済フラグ照会処理の手順を示すフローチャートである。シーダ52は、まず、送信状況テーブルにおいて送出済フラグが‘ON’に設定されているピースインデックスを照会する(ステップS600)。そして、シーダ52は、送出済フラグが‘ON’に設定されている該当のピースインデックスが存在するか否かを判断し(ステップS601)、当該判断結果が否定的である場合、送信候補とする暗号化ピースのピースインデックスを決定せずに、送出済フラグ照会処理を終了する。ステップS601の判断結果が肯定的である場合には、シーダ52は、該当のピースインデックスが複数存在するか否かを判断する(ステップS602)。当該判断結果が否定的である場合、シーダ52は、当該ピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定する(ステップS604)。ステップS602の判断結果が肯定的である場合、複数存在する該当のピースインデックスの中から1つのピースインデックスをランダムに選択する(ステップS603)。そして、シーダ52は、選択したピースインデックスを、送信候補とする暗号化ピースのピースインデックスとして決定して(ステップS604)、送出済フラグ照会処理を終了する。
以上のようにして、シーダ52は、各暗号化ピース列について送信状況テーブルにおいて記録されている送出済フラグを参照して、属する暗号化ピースの全てを送信済である暗号化ピース列に対応するピースインデックスの中から、送信候補とする暗号化ピースのピースインデックスを決定する。
図26に戻り、ステップS23では、シーダ52は、送信候補とする暗号化ピースのピースインデックスを決定できたか否かを判断して、当該判断結果が肯定的である場合、次いで、バリエーションインデックス決定処理を行う(ステップS24)。ステップS23の判断結果が否定的である場合には、シーダ52は、暗号化ピースを送信しない旨を示す通知メッセージをリーチャ50に送信して、新たなピース要求を待ち受ける。
図28は、本実施の形態にかかるバリエーションインデックス決定処理の手順を示すフローチャートである。ステップS500の処理は上述の第1の実施の形態と同様である。ステップS500の後ステップS507では、シーダ52は、取得したピースインデックスをキーとして送信状況テーブルを参照して、当該ピースインデックスが優先ピースインデックスであるか否か、即ち、当該ピースインデックスに対する優先ピースインデックスフラグの値が‘1’に設定されているか否かを判断する。当該判断結果が肯定的な場合、当該ピースインデックスが、優先ピースインデックスとして、送信候補の暗号化ピースのピースインデックスに決定されたことを意味している。この場合、シーダ52は、上述の第1の実施の形態と同様にしてステップS502〜S505の処理を行う。
一方、ステップS507の判断結果が否定的である場合、当該ピースインデックスが、優先ピースインデックスとしてではなく、送出済フラグによって、送信候補の暗号化ピースのピースインデックスに決定されたことを意味している。この場合、シーダ52は、送信状況テーブルに記録された送信回数に関らず、当該ピースインデックスに対応する暗号化ピース列に属する暗号化ピースのバリエーションインデックスの中から1つのバリエーションインデックスをランダムに選択する(ステップS508)。尚、シーダ52は、当該1つのバリエーションインデックスを、ランダムに選択するのではなく、P2PネットワークNTでの暗号化ピースの流通状況などに基づいて選択するようにしても良い。そして、シーダ52は、選択したバリエーションインデックスを、送信対象の暗号化ピースのバリエーションインデックスとして決定する(ステップS505)。
図26に戻ると、ステップS25〜S26の処理は上述の第1の実施の形態と同様である。ステップS26の後ステップS27では、シーダ52は、送信した暗号化ピースに応じて、以下のようにして送信状況テーブル更新処理を行う。図29は本実施の形態にかかる送信状況テーブル更新処理の手順を示すフローチャートである。ステップS800〜S802までの処理は上述の第1の実施の形態と同様である。ステップS802の後ステップS805では、シーダ52は、送信状況テーブルにおいて、優先ピースインデックスとして選定されているピースインデックスに対して、送出済フラグの値を‘ON’に設定する。その後、ステップS803では、シーダ52は、上述の第1の実施の形態と同様にして、優先ピースインデックスを初期化する。このように送出済フラグの値を設定して優先ピースインデックスを初期化した後に、ステップS20の優先ピースインデックス選定処理をシーダ52が行った際、優先ピースインデックスを選定できない場合がある。この場合に、上述のステップS23の判断結果が否定的となり、ステップS30の送出済フラグ照会処理におけるステップS601の判断結果が肯定的となる。
このようにしてシーダ52は、属する暗号化ピースの全てを送信済である暗号化ピース列について、リーチャ50の要求に応じて暗号化ピースを提供する。これにより、第1の実施の形態と同様にして鍵の漏洩による影響を軽減しつつも、暗号化ピースの配信効率を向上させることができる。
以上、第2の実施の形態について説明したが、当該実施の形態に多様な変更または改良を加えることができる。
(3)変形例
<変形例15>
上述の実施の形態の構成と、上述の第1の形態の変形例14で説明した一部取得済み暗号化ピースの送信を優先する構成とを併用しても良い。この場合、シーダ52は、送出済フラグによる暗号化ピースの送信と、一部データ要求による暗号化ピースの送信とのどちらを優先して行っても良い。
<変形例16>
上述の実施の形態においては、ピース要求が、上述の第1の実施の形態の変形例13で説明した指定ピースインデックスを含んでいても良い。この場合、シーダ52は、送出済フラグ照会処理のステップS600で、指定ピースインデックスのうち送信状況テーブルにおいて送出済フラグの値が‘ON’に設定されているピースインデックスを照会して、以降の処理を行えば良い。
<変形例17>
上述の実施の形態においては、シーダ52は、送出済フラグ照会処理において、ステップS603では、該当のピースインデックスが複数存在する場合その中から1つのピースインデックスを、ランダムに選択するものとしたが、送出済フラグが設定された順番や、各ピースインデックスの暗号化ピースの送信回数や、上述の第1の実施の形態の変形例9,14で記載した優先順位などの各選択基準に基づいて選択するようにしても良い。このようにして1つのピースインデックスを選択することで、特定のピースインデックスが他のピースインデックスより早く暗号化ピースを送信しきることを意図した変形例9,14と同様の効果を得ることができる。また、上述の選択基準を組み合わせて利用しても良い。例えば、各ピースインデックスに対応する暗号化ピース列について、送信回数の最大値から最小値を引いた値を優先順位として設定して、送信された暗号化ピースの送信回数の偏りが大きい暗号化ピース列を選択することができる。更に、(最大値から最小値を引いた値)×(バリエーションインデックスの大きさ)の値を優先順位として設定して、送信された暗号化ピースの送信回数の偏りの大きさに加えて、その暗号化ピースの重要度も加味した上で、送信候補とする暗号化ピースのピースインデックスを決定することができる。
また、このような優先順位を決定する処理は、上述の送信状況テーブル更新処理と併せて行って優先順位を送信状況テーブルに記録するようにしても良い。即ち、シーダ52は、送出済フラグが‘ON’に設定される対象のピースインデックスに対して、優先順位を各々設定してその値を送信状況テーブルに記録するようにする。図30は、本変形例にかかる送信状況テーブルを示す図である。同図においては、ピースインデックス‘0’に対して優先順位‘1’が記録されており、ピースインデックス‘n−1’に対して優先順位‘2’が記録されていることが示されている。シーダ52は送出済フラグ照会処理では送信状況テーブルに記録された優先順位を参照し、その参照結果に基づいてピースインデックス決定処理では、送信候補とする暗号化ピースのピースインデックスを決定するようにすれば良い。
また、上述の送出済フラグ及び優先順位に加え、変形例12にかかる未送出フラグを組み合わせて用いることにより、送信候補とする暗号化ピースのピースインデックスを決定するようにしても良い。このピースインデックスを決定する際に、送出済フラグ、優先順位及び未送出フラグのいずれを優先して用いるかは特に限定されない。
<変形例18>
上述の実施の形態においては、シーダ52は、バリエーションインデックス決定処理において、バリエーションインデックスの候補が複数ある場合その中から1つのバリエーションインデックスを、ランダムに選択するのではなく、送信回数に基づいて選択するようにしても良い。例えば、送信候補とする暗号化ピースのピースインデックスに対して複数存在するバリエーションインデックスに各々対応する各暗号化ピースの送信回数が異なる場合、送信回数が同数になるように、バリエーションインデックスを選択しても良い。例えば、ピースインデックスjに対して、バリエーションインデックスi1,i2,i3(1≦i1,i2,i3≦m)が候補として存在し、それぞれの暗号化ピース(i1,j)、暗号化ピース(i2,j)、および暗号化ピース(i3,j)の送信回数がそれぞれ‘1’,‘2’,‘3’であるものとする。この場合、シーダ52は、バリエーションインデックスi1を選択する。また、暗号化ピース(i1,j)、暗号化ピース(i2,j)、および暗号化ピース(i3,j)の送信回数がそれぞれ‘2’,‘3’,‘2’である場合にはシーダ52は、バリエーションインデックスi1又はi3のどちらかをランダムに選択するようにすれば良い。このような構成とすることで、それぞれの暗号化ピースをP2PネットワークNT上に偏り無く配信することができる。この結果、暗号化ピースの偏りがある状況と比較して、ユーザが保持する暗号化ピースの偏りを少なくすることができ、鍵の漏洩時の影響を軽減することができる。
[変形例]
なお、本発明は前記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
<変形例19>
上述した各実施の形態においては、コンテンツの各ピースへの分割や、各ピースの暗号化は、トラッカ51や、鍵サーバ53や、コンテンツ製作者が用意したサーバのいずれが行っても良い。また、各暗号化ピースは、例えば、トラッカ51、鍵サーバ53又は信頼できる第三者(例えば、コンテンツ製作者が用意したサーバ)からシーダ52A(初期シーダ)へ与えられるものとする。
また、上述した各実施の形態においては、復号鍵及び暗号鍵のうち少なくとも一方を鍵サーバ53自体が発行して生成するようにしても良いし、トラッカ51やコンテンツ製作者が用意したサーバが発行したり生成したりしたものを鍵サーバ53が取得するようにしても良い。
また、コンテンツCを分割した全てのピースC1〜CNが各々異なる暗号鍵で暗号化されているとしたが、これに限らず、一部のピースは同一の暗号鍵で暗号化されていても良い。
<変形例20>
上述した各実施の形態においては、トラッカ51、シーダ52及びリーチャ50の数は、上述したものに限らない。
また、P2PネットワークNTに販売サーバ54が接続され、リーチャ50は、販売サーバ54からTorrent Fileを取得するようにした。しかし、販売サーバ54はP2PネットワークNTに接続されていなくても良く、リーチャ50は、例えばCD−ROMなどの記録媒体に記録されたTorrent Fileを読み出すことにより、Torrent Fileを取得するようにしても良い。
また、リーチャ50は、鍵サーバ53とネットワークを介して接続されるようにしたが、ネットワークを介さず専用線などを介して接続されるようにしてもよいし、プロキシサーバを介して接続されるようにしても良い。これにより管理能力を高めたり、プロキシサーバの後段にある鍵サーバ53が直接攻撃されないようにしたりすることができる。
<変形例21>
上述した各実施の形態において、シーダ52で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、フレキシブルディスク(FD)、CD−R、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。この場合には、プログラムは、シーダ52において上記記録媒体から読み出して実行することにより主記憶装置(例えばRAM)上にロードされ、上記機能的構成において説明した各部が主記憶装置上に生成される。リーチャ50において実現される各種プログラムについても同様である。
<変形例22>
上述した第1の実施の形態においては、各暗号化ピースの送信回数と、優先ピースインデックスフラグとを1つの送信状況テーブルに記憶させこれを1つの外部記憶装置に記憶させるようにしたが、これらを別々のテーブルに記憶させるにしても良いし別々の記憶手段に記憶させるようにしても良い。第2の実施の形態における送出済フラグや、変形例12にかかる未送出フラグや、変形例17にかかる優先順位ついても同様である。更に、暗号化ピースを記憶する記憶装置と、送信状況テーブルを記憶する記憶装置とは同じであっても良いし、異なっていても良い。
また、上述した各実施の形態においては、優先ピース情報として優先ピースインデックスフラグを用いたが、これに限らず、優先ピースを特定する情報であればどのようなものであっても良い。
<変形例23>
上述の各実施の形態においては、シーダ52は、リーチャ50と同様に、リーチャ50や他のシーダ52から暗号化ピースを受信する機能を備えていても良い。そして、シーダ52は、ピース要求をリーチャ50から受信した場合、当該リーチャ50から少なくとも1つの暗号化ピースの少なくとも一部を受信しているか否かを判断し、当該判断結果に応じて、暗号化ピースの送信の可否を決定するようにしても良い。リーチャ50から少なくとも1つの暗号化ピースの少なくとも一部を受信しているか否かは、例えば、シーダ52がその時点で受信しているデータの受信量により判断することができる。そして、シーダ52は、当該判断結果が肯定的である場合に、暗号化ピースを当該リーチャ50に送信することを決定し、当該判断結果が否定的である場合には、暗号化ピースを当該リーチャ50に送信しないことを決定する。そして、決定結果が前者である場合に、シーダ52は、上述の各実施の形態と同様にして、暗号化ピースをリーチャ50に送信する。このような構成は、暗号化ピースの送受信を互いに行い合うことにより各々暗号化ピースを取得する通信システムに用いて好適である。
<変形例24>
上述の各実施の形態においては、シーダ52は、1つの暗号化ピースを複数回に分けてリーチャ50に送信するように構成しても良い。この場合、シーダ52は、当該暗号化ピースの送信に係るセッションを管理するためのセッション情報を記憶するセッション情報記憶テーブルを備える。セッション情報は、当該暗号化ピースの送信対象であるリーチャ50を識別するためのリーチャ識別情報と対応付けられて記憶されるものであり、当該リーチャ50がデータの一部を取得済みである暗号化ピース(継続暗号化ピース)のピースインデックス及びバリエーションインデックスと、送信済データ量と、新規セッション受入フラグとを含む。送信済データ量は、継続暗号化ピースについて当該リーチャ50が既に取得した部分のデータ量を示す。尚、暗号化ピースが更に複数のサブピースに分割されている構成である場合、送信済データ量は、当該リーチャ50が既に取得したサブピースに対して割り当てられたインデックスを示すものであっても良い。新規セッション受入フラグとは、シーダ52が、当該暗号化ピースの送信対象であるリーチャ50がデータの全部を未取得である暗号化ピース(新規暗号化ピース)を要求するピース要求(新規ピース要求)をどのように処理するかの判断基準となるものである。新規セッション受入フラグが‘ON’の場合には、リーチャ50からの新規ピース要求を受け入れて、新規暗号化ピースを提供可能であることを示し、新規セッション受入フラグが ‘OFF’の場合には、当該新規暗号化ピースを提供不可能であることを示す。シーダ52は起動時に新規セッション受入フラグを‘ON’に設定する。リーチャ識別情報は、例えば、リーチャ50に対して割り当てられたIPアドレスや接続元ポート番号や、リーチャ50を特定するID情報などである。以上のように、シーダ52は、セッション情報において継続暗号化ピースに関する情報とリーチャ50を識別するためのリーチャ識別情報とを対応付けて記憶する。このため、シーダ52は同時に複数のリーチャ50に暗号化ピースを送信する場合であってもセッションの識別が可能である。
図31は、本変形例に係るシーダ52の機能的構成を例示する図である。シーダ52は、上述の実施の形態で説明したピース情報送信部520と、ピース要求受信部521と、優先ピースインデックス選定部522と、ピースインデックス決定部523と、バリエーションインデックス決定部524と、送信状況テーブル更新部525と、ピース送信部526とに加え、セッション情報確認部528と、セッション情報更新部529とを更に有する。ピース要求受信部521は、ピース要求をリーチャ50から受信する際に、リーチャ識別情報を取得する。尚、リーチャ50から受信するピース要求が、継続暗号化ピースを要求する継続ピース要求である場合、そのデータ構成は例えば図32に示されるものとなる。同図に示されるように、継続ピース要求は、新規ピース要求フラグと、送信要求対象の継続暗号化ピースのピースインデックス及びバリエーションインデックスと、データ開始位置と、取得希望データ長とを含む。新規ピース要求フラグは、ピース要求が新規ピース要求であるか否かを示すものである。新規ピース要求フラグが‘ON’である場合、ピース要求が新規ピース要求であることを示し、新規ピース要求フラグが‘OFF’である場合、ピース要求が継続ピース要求であることを示す。ここでは、新規ピース要求フラグが‘OFF’に設定される。データ開始位置は、継続暗号化ピースの未取得のデータの開始位置を示す。取得希望データ長とは、継続暗号化ピースの未取得のデータのうちリーチャ50が取得を要求するデータのデータ長(データ量)を示すものであり、データ開始位置からのデータ長を示す。尚、ここでは、Torrent Fileに含まれるファイル情報においては、各暗号化ピースのデータ量が示されているものとする。リーチャ50は、このデータ量に基づいて、上述のデータ開始位置を算出したり、未取得である部分全体のデータ長を算出してこれに基づいて上述の取得希望データ長を算出したりする。尚、データ量やデータ長の算出基準は特に限定されない。
また、リーチャ50から受信するピース要求が新規ピース要求である場合、そのデータ構成は例えば図33に示されるものとなる。同図に示されるように、新規ピース要求は、新規ピース要求フラグと、取得を要求する取得希望データ長と、取得を要求するピースインデックスのリストとを含む。また、ここでは、新規ピース要求フラグは‘ON’に設定される。
図31の説明に戻る。セッション情報確認部528は、ピース要求受信部521が新規ピース要求をリーチャ50から受信した場合、セッション情報記憶テーブルに記憶されているセッション情報において当該リーチャ50のリーチャ識別情報に対応する新規セッション受入フラグを参照して、当該ピース要求を受け入れるか否かを判断する。そして、セッション情報確認部528は、当該新規ピース要求を受け入れた場合には、セッション情報更新部529を介して新規セッション受入フラグを’OFF’に設定する。また、セッション情報確認部528は、ピース要求受信部521が継続ピース要求をリーチャ50から受信した場合に、セッション情報記憶テーブルにおいて当該リーチャ50のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれるピースインデックス、バリエーションインデックス及び送信済みデータ量と、受信した継続ピース要求に含まれるピースインデックス、バリエーションインデックス及びデータ開始位置との間で整合がとれているかを確認して、当該継続ピース要求を受け入れるか否かを判断する。
また、セッション情報確認部528は、ピース送信部526が新規暗号化ピースをリーチャ50に送信する場合には、セッション情報記憶テーブルにおいて、セッション情報として当該リーチャ50の識別情報と対応付けて当該暗号化ピースのピースインデックス及びバリエーションインデックスと送信済データ量とを記憶する。また、セッション情報更新部529は、ピース送信部526が継続暗号化ピースを送信する場合には、送信されたデータのデータ量を算出して、セッション情報記憶テーブルのセッション情報における送信済データ量を更新する。そして、セッション情報確認部528は、この送信済データ量が当該暗号化ピースの全部のデータ量に達した場合に、当該暗号化ピースの送信が完了したと判断する。この場合、セッション情報確認部528は、セッション情報更新部529を介して、セッション情報記憶テーブルに記憶されているセッション情報に含まれる新規セッション受入フラグを’ON’に設定する。
セッション情報更新部529は、セッション情報確認部528の判断に応じて、新規セッション受入フラグを’ON’又は’OFF’に設定する。
次に、本変形例にかかるシーダ52が行う優先ピースインデックス選定処理及び暗号化ピース送信処理について図34を用いて説明する。ステップS20〜S21の処理は上述の第1の実施の形態と同様である。シーダ52はリーチャ50からピース要求を受信した場合(ステップS21:YES)、ここでは、以下のようにして暗号化ピース送信処理を行う。まず、ステップS40では、シーダ52は、リーチャ50からのピース要求が新規ピース要求であるか否かを判断する。ピース要求が例えば図32に例示されるデータ構成の継続ピース要求であり、新規ピース要求フラグが‘OFF’に設定されている場合、ステップS40の判断結果は否定的となり、ステップS45に進む。ステップS45では、シーダ52は、セッション情報記憶テーブルにおいて当該リーチャ50のリーチャ識別情報と対応付けられて記憶されているセッション情報を参照し、受信した継続ピース要求に含まれるピースインデックス及びバリエーションインデックスと、セッション情報に含まれるピースインデックス及びバリエーションインデックスとが等しいことを確認する。その確認後、シーダ52は、セッション情報に含まれる送信データ量と継続ピース要求に含まれる要求データ開始位置との間で整合がとれているかを確認する確認処理を行う(ステップS46)。これらの間で整合がとれていない場合、確認処理は失敗であるとする。また、要求データ開始位置が「0」である場合も、確認処理は失敗であるとする。即ち、要求データ開始位置が「0」である継続ピース要求を排除することで、特定のピースインデックス及びバリエーションインデックスに対応する暗号化ピースをその先頭位置から集めようとするリーチャ50の行為を排除できる。また、ここで排除する要求データ開始位置の閾値を「0」より大きくしても良く、この場合、上述のリーチャ50の行為をより困難にすることができる。
さて、上述の確認処理が成功した場合には(ステップS46:YES)、シーダ52は、当該リーチャ50がデータの一部を取得済みである暗号化ピースの残り部分が要求されていると判断し、ステップS26に進む。ステップS26では、シーダ52は、ステップS21で受信したピース要求に含まれるピースインデックス、バリエーションインデックス、データ開始位置及び取得希望データ長に応じた暗号化ピースのデータを外部記憶装置から読み出してこれをリーチャ50に送信する。尚、上述の確認処理が失敗した場合には(ステップS46:NO)、シーダ52は、ステップS21で受信したピース要求を破棄して、ステップS21に戻り、次のピース要求を待ち受ける。ここで、シーダ52は、暗号化ピースの提供を行わないことをリーチャ50に通知しても良いし、しなくても良い。
ステップS26の後、ステップS42では、シーダ52は、セッション情報記憶テーブルにおいて当該リーチャ50のリーチャ識別情報と対応付けて記憶されたセッション情報において、ステップS26で送信した暗号化ピースのピースインデックス、バリエーションインデックスに対応する送信済データ量を算出してこれを更新する。その後、シーダ52は、ステップS26において送信した暗号化ピースの送信が完了したか否かを判断する(ステップS43)。シーダ52は、ステップS26で送信した暗号化ピースの送信済データ量が当該暗号化ピースの全部のデータ量に達した場合に、当該暗号化ピースの送信が完了したと判断する。この場合(ステップS43:YES)、シーダ52は、上述の実施の形態と同様にして、送信状況テーブル更新処理を行う。また、シーダ52は、セッション情報記憶テーブルにおいて当該リーチャ50のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれる新規セッション受入フラグを’ON’に設定する。そして、ステップS21に戻り、シーダ52は、次のピース要求を待ち受ける。
一方、ステップS40で、シーダ52は、ピース要求が図33に例示されるようなデータ構成の新規ピース要求であり、新規ピース要求が‘ON’に設定されている場合、ここでの判断結果は肯定的となり、ステップS41に進む。ステップS41では、シーダ52は、セッション情報記憶テーブルにおいて当該リーチャ50のリーチャ識別情報と対応付けられて記憶されているセッション情報に含まれる新規セッション受入フラグを参照して、当該ピース要求を受け入れるか否かを判断する。新規セッション受入フラグが‘ON’に設定されている場合、シーダ52は、当該新規ピース要求を受け入れ、新規セッション受入フラグを’OFF’に設定して、ステップS22に進む。以降ステップS23〜S26の処理は上述の実施の形態と同様である。ステップS26では、シーダ52は、ステップS22で決定したピースインデックスjと、ステップS24で決定したバリエーションインデックスiとの組からなるインデックス(i,j)に対応する暗号化ピースについて、ステップS21で受信した新規ピース要求に含まれる取得希望データ量を有するデータを外部記憶装置から読み出してこれをリーチャ50に送信する。その後、シーダ52は、上述と同様にしてステップS42以降の処理を行う。
以上のような構成によれば、暗号化ピースのデータ量が多い場合であっても複数回に分けて効果的に暗号化ピースの送受信が可能となる。
尚、上述においては、図32〜33に例示するような新規ピース要求フラグを用いて、受信されたピース要求が新規ピース要求であるか否かをシーダ52は判断するようにした。しかし、これに限らず、シーダ52は、例えば、図33に示されるピース要求に含まれるバリエーションインデックスを参照して、この値が所定の特殊な値であるか否かを判断することにより、受信されたピース要求が新規ピース要求であるか否かを判断するようにしても良い。
また、本変形例を実施する場合、ピース要求の受信処理と、暗号化ピースの送信処理とが別のスレッドとしてそれぞれ実行される場合がある。この場合、暗号化ピースの送信処理であるステップS26の終了を待っていると、セッション情報を更新する処理であるステップS42や、新規セッション受入れフラグを‘OFF’に設定する処理であるステップS44や、送信状況テーブル更新処理であるステップS27などの各処理の実施に時間を要し、その結果、リーチャからの適切な新規ピース要求を受け入れないなどの事態が生じる可能性がある。そのため、ステップS43やステップS42やステップS44やステップS27などの処理を、暗号化ピースの送信処理であるステップS26の前に実施するようにしても良い。この場合、ステップS43において、暗号化ピースの送信が完了したか否かの判断は、ピース要求に含まれるセッション情報を基にして行えば良い。
第1の実施の形態にかかるコンテンツ配信システムの構成を示すブロック図である。 コンテンツが複数のピースに分割された状態を模式的に示す図である。 各暗号化ピースを模式的に示す図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 シーダ52Aが記憶している各暗号化ピースを例示する図である。 シーダ52の機能的構成を例示する図である。 ピース情報のデータ構成を例示する図である。 送信状況テーブルのデータ構成を例示する図である。 リーチャ50の機能的構成を例示する図である。 Torrent Fileを例示する図である。 鍵サーバ53の機能的構成を例示する図である。 ノード情報のデータ構成を例示する図である。 コンテンツ配信処理の手順を示すフローチャートである。 優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。 優先ピースインデックス選定処理の詳細な手順を示すフローチャートである。 バリエーションインデックス決定処理の手順を示すフローチャートである。 送信状況テーブル更新処理の手順を示すフローチャートである。 照合処理の手順を示すフローチャートである。 同実施の形態の一変形例にかかるTorrent Fileのデータ構成を例示する図である。 同実施の形態の一変形例にかかるハッシュ値を含むインデックス情報を例示する図である。 同実施の形態の一変形例にかかる送信状況テーブル更新処理の手順を示すフローチャートである。 同実施の形態の一変形例にかかるピース要求のデータ構成を例示する図である。 第2の実施の形態にかかるシーダ52の機能的構成を例示する図である。 送信状況テーブルのデータ構成を例示する図である。 優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。 送出済フラグ照会処理の手順を示すフローチャートである。 バリエーションインデックス決定処理の手順を示すフローチャートである。 送信状況テーブル更新処理の手順を示すフローチャートである。 同実施の形態の一変形例にかかる送信状況テーブルを示す図である。 同実施の形態の一変形例にかかるシーダ52の機能的構成を例示する図である。 同変形例にかかる継続ピース要求のデータ構成を例示する図である。 同変形例にかかる新規ピース要求のデータ構成を例示する図である。 同変形例にかかる優先ピースインデックス選定処理及び暗号化ピース送信処理の手順を示すフローチャートである。
符号の説明
50,50A,50B リーチャ(通信装置)
51 トラッカ(管理サーバ)
52,52A,52B,52C シーダ(通信装置)
53 鍵サーバ
54 販売サーバ
500 コンテンツ取得部
501 鍵束要求部
502 鍵束取得部
503 コンテンツ復号部
520 ピース情報送信部
521 ピース要求受信部(受信手段)
522 優先ピースインデックス選定部(選定手段、記憶制御手段)
523 ピースインデックス決定部(第1決定手段)
524 バリエーションインデックス決定部(第2決定手段)
525 送信状況テーブル更新部(第1更新手段、第2更新手段、記憶制御手段)
526 ピース送信部(送信手段)
527 送出済フラグ照会部(照会手段)
528 セッション情報確認部(確認手段)
529 セッション情報更新部(第3更新手段)
530 制御部
531 パケット処理部
532 ネットワークインターフェース部
533 認証・鍵交換処理部
534 鍵記憶部
535 シーケンス情報照合部
536 シーケンス情報記憶部
537 鍵供給部
538 暗号処理部
NT P2Pネットワーク

Claims (25)

  1. コンテンツの一部である複数のピースの送信を行う通信装置であって、
    前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、
    前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段と、
    前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、
    選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御手段と、
    暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、
    前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定手段と、
    送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定手段と、
    送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、
    前記送信手段によって送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新手段と、
    前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるように、前記第2記憶手段に記憶された当該優先ピース情報を前記第2記憶手段において更新する第2更新手段とを備える
    ことを特徴とする通信装置。
  2. 前記選定手段は、前記未送信暗号化ピースの個数が同数である第1ピースが複数存在する場合、当該各第1ピースに対応して存在する前記複数の暗号化ピースの個数に基づいて、前記優先ピースを選定する
    ことを特徴とする請求項1に記載の通信装置。
  3. 前記第1ピースに対応する前記複数の暗号化ピースには、前記複数のピースの各々を区別するためのピースインデックスと、前記複数の異なる暗号鍵の各々を区別するためのバリエーションインデックスとが各々対応付けられており、
    前記送信回数には、前記暗号化ピースに対応付けられた前記ピースインデックス及びバリエーションインデックスが対応付けられており、
    前記選定手段は、前記少なくとも1つの第1ピースに対応する前記複数の暗号化ピースについて、各前記複数の暗号化ピースに対応する前記ピースインデックスに対応付けられた前記送信回数が0回である前記未送信暗号化ピースの個数に基づいて、少なくとも1つの前記ピースインデックスを優先ピースとして選定し、
    前記記憶制御手段は、前記優先ピースとして選定された前記ピースインデックスを特定する情報を前記優先ピース情報として前記第2記憶手段に記憶させる
    ことを特徴とする請求項1又は2に記載の通信装置。
  4. 前記選定手段は、前記未送信暗号化ピースの個数が同数である前記ピースインデックスが複数存在する場合、当該各ピースインデックスの大小に基づいて、少なくとも1つの前記ピースインデックスを優先ピースとして選定する
    ことを特徴とする請求項3に記載の通信装置。
  5. 前記選定手段は、前記未送信暗号化ピースの個数が同数である第1ピースが複数存在する場合、他の通信装置が保持する暗号化ピースの個数に基づいて、前記優先ピースを選定する
    ことを特徴とする請求項1乃至4のいずれか一項に記載の通信装置。
  6. 前記要求受信手段は、要求する暗号化ピースに対応付けられている前記ピースインデックスと前記バリエーションインデックスとの組を指定する前記ピース要求を受信し、
    前記第1決定手段は、前記ピース要求が受信された場合、前記ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
    前記第2決定手段は、決定された前記ピースインデックス及び当該ピースインデックスとの組が前記ピース要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定する
    ことを特徴とする請求項3に記載の通信装置。
  7. 前記要求受信手段は、要求する暗号化ピースに対応付けられている前記ピースインデックスを指定する前記ピース要求を受信し、
    前記第1決定手段は、前記ピース要求が受信された場合、前記ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
    前記第2決定手段は、決定された前記ピースインデックスに対応付けられている前記複数の暗号化ピースのそれぞれについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定する
    ことを特徴とする請求項3に記載の通信装置。
  8. 前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックス及び前記バリエーションインデックスを指定すると共に、当該暗号化ピースの未取得のデータのデータ範囲を指定して、当該データを要求する一部データ要求を含む前記ピース要求を受信し、
    前記第1決定手段は、前記ピース要求に前記一部データ要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定し、
    前記第2決定手段は、決定された前記ピースインデックス及び当該ピースインデックスとの組が前記一部データ要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定し、
    前記送信手段は、送信対象として決定された前記暗号化ピースについて、前記一部データ要求によって指定された前記データ範囲のデータを前記他の通信装置に送信する
    ことを特徴とする請求項3に記載の通信装置。
  9. 前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックスを指定する一部データ要求を含む前記ピース要求を受信し、
    前記第1決定手段は、前記ピース要求に前記一部データ要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定する第3決定手段と、決定された前記ピースインデックスを前記他の通信装置に通知する通知手段と、決定された前記ピースインデックスが対応付けられており且つデータの一部を取得済みである暗号化ピースに対応付けられているバリエーションデックスと、当該暗号化ピースの未取得のデータのデータ範囲とを前記他の通信装置から受信する範囲受信手段とを有し、
    前記第2決定手段は、決定された前記ピースインデックス及び受信された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定し、
    前記送信手段は、送信対象として決定された前記暗号化ピースについて、受信された前記データ範囲のデータを前記他の通信装置に送信する
    ことを特徴とする請求項3に記載の通信装置。
  10. 前記要求受信手段は、前記他の通信装置がデータの一部を取得済みである暗号化ピースに対応付けられている前記ピースインデックス及び前記バリエーションインデックスを指定すると共に、当該暗号化ピースの未取得のデータのデータ範囲を指定して、当該データを要求する一部データ要求と、前記他の通信装置がデータの全部を未取得である暗号化ピースに対応付けられている前記ピースインデックスを指定し、当該暗号化ピースを要求する未取得ピース要求とを含むピース要求を受信し、
    前記第1決定手段は、前記ピース要求に前記一部データ要求及び前記未取得ピース要求が含まれる場合、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスが存在する場合、当該ピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定する第4決定手段と、前記一部データ要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスが存在しない場合、前記未取得ピース要求によって指定された前記ピースインデックスのうち、前記優先ピース情報によって特定される前記ピースインデックスと一致するピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定する第5決定手段とを有し、
    前記第2決定手段は、前記第4決定手段により前記ピースインデックスが決定された場合、当該ピースインデックス及び当該ピースインデックスとの組が前記一部データ要求において指定された前記バリエーションインデックスが対応付けられている暗号化ピースについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定し、前記第5決定手段により前記ピースインデックスが決定された場合、当該ピースインデックスに対応付けられている前記複数の暗号化ピースのそれぞれについて、前記送信回数を参照して、前記未送信暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定する
    ことを特徴とする請求項3に記載の通信装置。
  11. 前記優先ピースが選定されてから経過した時間に基づいて、前記優先ピースを更新するか否かを判断する第1判断手段を更に備え、
    前記第1決定手段は、前記優先ピースを更新すると判断された場合、前記優先ピース情報によって特定される前記複数の暗号化ピース以外であり前記少なくとも第1ピースに対応する前記複数の暗号化ピースを、送信候補として決定する
    ことを特徴とする請求項1乃至10のいずれか一項に記載の通信装置。
  12. 接続されている他の通信装置の数を検出する検出手段と、
    検出された前記他の通信装置の数が、前記優先ピースとして選定された前記複数の暗号化ピースの数より小さい場合に当該複数の暗号化ピースのうち前記未送信暗号化ピースの数と等しいか否かを判断する第2判断手段とを備え、
    前記記憶制御手段は、前記第2判断手段の判断結果が肯定的である場合に、前記優先ピース情報によって特定される前記優先ピースを初期化時優先ピースとして特定する初期化時優先ピース情報を前記第2記憶手段に記憶させると共に、検出された前記他の通信装置の数を初期化時装置数として前記第2記憶手段に記憶させ、
    前記第2更新手段は、前記第2判断手段の判断結果が肯定的である場合に、前記優先ピース情報を前記初期状態に更新し、
    前記選定手段は、前記優先ピース情報が更新された後に検出された前記他の通信装置の数が前記初期化時装置数より大きい場合、前記初期化時優先ピース情報によって特定される前記初期化時優先ピースを前記優先ピースとして再選定し、前記優先ピース情報が更新された後に検出された前記他の通信装置の数が前記初期化時装置数以下である場合、前記初期化時優先ピース情報によって特定される前記優先ピース以外で少なくとも1つの前記第1ピースに対応する前記複数の暗号化ピースを、前記優先ピースとして新たに選定する
    ことを特徴とする請求項1乃至11のいずれか一項に記載の通信装置。
  13. 前記記憶制御手段は、前記第1ピースが暗号化された前記複数の暗号化ピースの全てを送信済であるか否かを示す送出済フラグを前記ピースインデックスに対応付けて前記第2記憶手段に記憶させ、
    送信候補とする暗号化ピースの前記ピースインデックスが前記第1決定手段により決定されない場合に、前記送出済フラグを照会して、前記複数の暗号化ピースの全てを送信済であることを示す前記送出済フラグが対応付けられている前記ピースインデックスのうち少なくとも1つを、送信候補とする暗号化ピースのピースインデックスとして決定する送出済フラグ照会手段を更に備え、
    前記第2決定手段は、送信候補とする暗号化ピースのピースインデックスが前記送出済フラグ照会手段により決定された場合、当該ピースインデックスが対応付けられている暗号化ピースのうち少なくとも1つを、送信対象の暗号化ピースとして決定する
    ことを特徴とする請求項3に記載の通信装置。
  14. 前記送出済フラグ照会手段は、送信候補とする暗号化ピースの前記ピースインデックスが前記第1決定手段により決定されない場合に、前記送出済フラグを照会して、前記複数の暗号化ピースの全てを送信済であることを示す前記送出済フラグが対応付けられている前記ピースインデックスに対して優先順位を設定し、当該優先順位に応じて、送信候補とする暗号化ピースのピースインデックスを決定する
    ことを特徴とする請求項12に記載の通信装置。
  15. 前記記憶制御手段は、前記優先ピースとして選定された前記複数の暗号化ピースのうち前記未送信暗号化ピースが存在する場合に新たな前記優先ピースが選定される場合、新たに選定される前の前記優先ピースに対応する前記ピースインデックスに対して、前記未送信暗号化ピースの存在することを示す未送出フラグを対応付けて前記第2記憶手段に記憶させ、
    前記第1決定手段は、前記優先ピース情報及び前記未送出フラグのうち少なくとも一方を用いて、送信候補とする暗号化ピースのピースインデックスを決定する
    ことを特徴とする請求項3に記載の通信装置。
  16. 前記暗号化ピースを他の通信装置から受信するピース受信手段と、
    受信された前記暗号化ピースを前記第1記憶手段に記憶させるピース記憶制御手段とを更に備る
    ことを特徴とする請求項1乃至15のいずれか一項に記載の通信装置。
  17. 前記ピース要求が他の通信装置から受信された場合、前記ピース受信手段を介して当該他の通信装置から少なくとも1つの暗号化ピースの少なくとも一部を受信しているか否かを判断する受信判断手段と、
    前記受信判断手段の判断の結果に応じて、前記暗号化ピースを前記他の通信装置に送信するか否かを決定する送信決定手段とを備え、
    前記第1決定手段は、前記暗号化ピースを前記他の通信装置に送信すると決定された場合に、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する
    ことを特徴とする請求項16に記載の通信装置。
  18. 前記第1記憶手段は、コンテンツを構成する全ての複数のピースのそれぞれについて、少なくとも1つ以上の暗号鍵で暗号化された暗号化ピースを各々記憶する
    ことを特徴とする請求項1乃至17のいずれか一項に記載の通信装置。
  19. 前記他の通信装置がデータの一部を取得済みである継続暗号化ピースに対応付けられている前記ピースインデックス及びバリエーションインデックスと、前記一部のデータ量とを、当該他の通信装置を識別するための識別情報と対応付けてセッション情報として記憶する第3記憶手段と、
    前記暗号化ピースに対応付けられている前記ピースインデックス及びバリエーションインデックスと、前記継続暗号化ピースについて前記一部を除いたデータのデータ開始位置と、前記一部を除いたデータのうち取得を要求するデータの第1取得希望データ量とを指定すると共に前記識別情報を含む前記ピース要求である継続ピース要求を前記要求受信手段が前記他の通信装置から受信した場合、前記セッション情報と、前記継続ピース要求との整合性を確認する確認手段と、
    前記セッション情報を更新する第3更新手段とを更に備え、
    前記送信手段は、前記確認手段の確認結果に応じて、前記継続暗号化ピースについて前記データ開始位置から前記第1取得希望データ量を有するデータを前記他の通信装置に送信し、
    前記第3更新手段は、送信された前記データに基づいて、前記セッション情報を更新する
    ことを特徴とする請求項3に記載の通信装置。
  20. 前記第3記憶手段は、前記他の通信装置がデータの全部を未取得である新規暗号化ピースを要求すると共に前記識別情報を含む前記ピース要求である新規ピース要求を受け入れるか否かを示す新規受入フラグを前記識別情報と対応付けて更に記憶し、
    前記第3更新手段は、前記識別情報に対応する前記セッション情報の更新に伴い、前記継続暗号化ピースの前記一部のデータ量が当該継続暗号化ピースの全部のデータ量に達した場合、前記新規ピース要求を受け入れることを示すよう当該識別情報に対応する前記新規受入フラグを更新する
    ことを特徴とする請求項19に記載の通信装置。
  21. 前記要求受信手段は、前記新規暗号化ピースについて取得を要求する第2取得希望データ量を含む前記新規ピース要求を受信し、
    前記第1決定手段は、前記新規ピース要求が受信された場合且つ当該新規ピース要求に含まれる前記識別情報に対応する前記受入フラグが前記新規ピース要求を受け入れることを示す場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定し、
    前記送信手段は、前記新規暗号化ピースについて前記第2取得希望データ量を有するデータを前記他の通信装置に送信する
    ことを特徴とする請求項20に記載の通信装置。
  22. コンテンツの一部である複数のピースの送受信を行う第1通信装置及び第2通信装置がネットワークを介して接続され、
    第1通信装置及び第2通信装置は各々、
    前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、
    前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段と、
    前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定手段と、
    選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御手段と、
    暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信手段と、
    前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定手段と、
    送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定手段と、
    送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信手段と、
    前記送信手段によって送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新手段と、
    前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新手段と、
    前記暗号化ピースを他の通信装置から受信するピース受信手段と、
    受信された前記暗号化ピースを前記第1記憶手段に記憶させるピース記憶制御手段とを備え、
    前記第1通信装置の備える前記送信手段が、送信対象として決定された前記暗号化ピースを前記第2通信装置に送信し、
    前記第2通信装置の備える前記ピース受信手段が、前記第1通信装置の備える前記送信手段から送信された前記暗号化ピースを受信する
    ことを特徴とする通信システム。
  23. 前記第1通信装置は、
    前記ピース要求が前記第2通信装置から受信された場合、前記ピース受信手段を介して当該第2通信装置から少なくとも1つの暗号化ピースを受信しているか否かを判断する受信判断手段と、
    前記受信判断手段の判断の結果に応じて、前記暗号化ピースを前記第2通信装置に送信するか否かを決定する送信決定手段とを更に備え、
    前記第1通信装置の備える前記第1決定手段は、前記暗号化ピースを前記第2通信装置に送信すると決定された場合に、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する
    ことを特徴とする請求項22に記載の通信システム。
  24. コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段とを備える通信装置において実現される送信方法であって、
    前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、
    選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御ステップと、
    暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、
    前記ピース要求が受信された場合、前記優先ピース情報によって前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定ステップと、
    送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定ステップと、
    送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、
    前記送信ステップで送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新ステップと、
    前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新ステップとを含む
    ことを特徴とする送信方法。
  25. コンテンツの一部である複数のピースの送信を行う通信装置であって、前記複数のピースを各々暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する手段であって、前記複数のピースのうち少なくとも1つの第1ピースを複数の異なる暗号鍵で暗号化することによって得られる複数の暗号化ピースを記憶する第1記憶手段と、前記第1記憶手段に記憶された前記暗号化ピースのそれぞれの送信回数を記憶する第2記憶手段とを備える通信装置の有するコンピュータに実行させるための送信プログラムであって、
    前記第1ピースが暗号化された前記複数の暗号化ピースのうち前記送信回数が0回である未送信暗号化ピースの個数に基づいて、前記第1ピースのうち少なくとも1つの第1ピースに対応する前記複数の暗号化ピースを優先ピースとして選定する選定ステップと、
    選定された優先ピースを特定する優先ピース情報を前記第2記憶手段に記憶させる記憶制御ステップと、
    暗号化ピースを要求するピース要求を他の通信装置から受信する要求受信ステップと、
    前記ピース要求が受信された場合、前記優先ピース情報を参照して、前記優先ピースとして特定される前記複数の暗号化ピースを送信候補として決定する第1決定ステップと、
    送信候補として決定された前記複数の暗号化ピースのうち少なくとも1つの前記未送信暗号化ピースを送信対象として決定する第2決定ステップと、
    送信対象として決定された前記暗号化ピースを前記他の通信装置に送信する送信ステップと、
    前記送信ステップで送信された暗号化ピースに従い、前記第2記憶手段に記憶された前記暗号化ピースの送信回数を更新する第1更新ステップと、
    前記優先ピース情報によって優先ピースとして特定される複数の暗号化ピースのうち前記未送信暗号化ピースが存在しなくなった場合、前記優先ピース情報によって優先ピースが特定されない初期状態になるよう当該優先ピース情報を前記第2記憶手段において更新する第2更新ステップとを含む
    ことを特徴とする送信プログラム。
JP2008078239A 2008-03-25 2008-03-25 通信装置、システム、送信方法及びプログラム Expired - Fee Related JP5208549B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008078239A JP5208549B2 (ja) 2008-03-25 2008-03-25 通信装置、システム、送信方法及びプログラム
US12/333,704 US8175267B2 (en) 2008-03-25 2008-12-12 Communication apparatus, communication system, transmission method, and computer program product
CN2009101279783A CN101547201B (zh) 2008-03-25 2009-03-25 通信设备,通信系统及传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008078239A JP5208549B2 (ja) 2008-03-25 2008-03-25 通信装置、システム、送信方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2009232393A JP2009232393A (ja) 2009-10-08
JP5208549B2 true JP5208549B2 (ja) 2013-06-12

Family

ID=41119222

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008078239A Expired - Fee Related JP5208549B2 (ja) 2008-03-25 2008-03-25 通信装置、システム、送信方法及びプログラム

Country Status (3)

Country Link
US (1) US8175267B2 (ja)
JP (1) JP5208549B2 (ja)
CN (1) CN101547201B (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5395372B2 (ja) * 2008-06-19 2014-01-22 株式会社東芝 通信装置、鍵サーバ及びデータ
JP2010141567A (ja) * 2008-12-11 2010-06-24 Toshiba Corp 通信装置、通信方法及びプログラム
JP5284119B2 (ja) * 2009-01-16 2013-09-11 株式会社東芝 サーバ、情報処理方法及びプログラム
JP2011141580A (ja) * 2010-01-05 2011-07-21 Sony Corp アクセス制御装置、データ処理装置、アクセス制御方法およびプログラム
JP5286380B2 (ja) * 2011-03-07 2013-09-11 株式会社東芝 データ送信装置および送信方法
JP5612006B2 (ja) 2012-03-13 2014-10-22 株式会社東芝 データ送信装置、データ受信装置、及びプログラム
CN103457727B (zh) * 2012-05-29 2018-01-23 华为技术有限公司 一种实现媒体数据处理的方法、装置和系统
CN111698576B (zh) * 2020-06-23 2022-04-01 网易有道信息技术(杭州)有限公司 信息加密方法、解密方法、服务器、客户端及介质
US11595367B2 (en) * 2020-09-30 2023-02-28 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Selectively disclosing content of data center interconnect encrypted links

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2001249848A1 (en) * 2000-04-04 2001-10-15 Ecd Systems, Inc. Method and system for digital data delivery and reproduction
CA2519116C (en) * 2003-03-13 2012-11-13 Drm Technologies, Llc Secure streaming container
WO2005022428A1 (ja) * 2003-08-28 2005-03-10 Ibm Japan, Ltd. 属性情報提供サーバ、属性情報提供方法、およびプログラム
WO2005064836A1 (en) * 2003-12-22 2005-07-14 America Online, Inc A system and method for using a streaming protocol
US7165050B2 (en) 2004-09-20 2007-01-16 Aaron Marking Media on demand via peering
US7778417B2 (en) * 2005-05-17 2010-08-17 International Business Machines Corporation System and method for managing encrypted content using logical partitions
US7721088B2 (en) * 2006-07-27 2010-05-18 Panasonic Corporation Terminal device, server device, and content distribution system

Also Published As

Publication number Publication date
US8175267B2 (en) 2012-05-08
US20090249490A1 (en) 2009-10-01
CN101547201A (zh) 2009-09-30
CN101547201B (zh) 2012-12-05
JP2009232393A (ja) 2009-10-08

Similar Documents

Publication Publication Date Title
JP5208549B2 (ja) 通信装置、システム、送信方法及びプログラム
JP2010021888A (ja) 通信装置、鍵サーバ及び管理サーバ
US20090138714A1 (en) Communication apparatus, key server, management server, communication server, content distribution system, communication method, and recording medium
US8478893B2 (en) Data transmission to offline recipient nodes in a distributed network
EP2148488A1 (en) Peer-to-peer content distribution
KR101549803B1 (ko) 피어-투-피어 콘텐츠 배포 시스템에서 피어-수신된 콘텐츠의 완전성 검증
US8595492B2 (en) On-demand protection and authorization of playback of media assets
JP5526137B2 (ja) 選択的データ転送ストレージ
KR101252528B1 (ko) 데이터 전달 저장에서의 분해/재조립 방법
JP5395372B2 (ja) 通信装置、鍵サーバ及びデータ
JP2009129386A (ja) 配信方法、サーバ及び受信端末
JP2009193460A (ja) 情報処理装置、配信情報投入装置及び情報処理方法並びに情報処理用プログラム
CN110140335B (zh) 用于改进递送性能的资源分段
KR20150093113A (ko) 분산된 제작자들을 위한 콘텐츠-기반의 전송 보안
JP2009272927A (ja) 通信装置、サーバ、及びプログラム
JP2010124071A (ja) 通信装置、通信方法及びプログラム
JP2012003682A (ja) アクセス制御システム、アクセス制御方法、認証装置、認証システム
JP2009153091A (ja) 通信装置、鍵サーバ、管理サーバ、通信サーバ、通信方法及びプログラム
JP2006203505A (ja) コンテンツ配信システム、サーバ、ユーザ端末およびプログラム
JP4569535B2 (ja) データ配信システム及びサーバ
JP2014048719A (ja) 配信管理システム、配信管理方法、配信システム、及び、配信管理プログラム
RU2647635C2 (ru) Способ и система распространения контента в сети передачи данных со встроенным механизмом условного доступа
JP4926023B2 (ja) コンテンツ受信端末、コンテンツ配信端末、外部サーバ装置、ピアツーピアネットワークシステム及びコンピュータプログラム
JP4403124B2 (ja) コンテンツ共有のためのシステム、装置、方法およびプログラム
JP2011076507A (ja) 情報処理装置、情報通信システム、情報処理方法及び情報処理用プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101015

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130121

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: 20130129

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130220

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160301

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160301

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees