(57)【要約】【課題】同一のコンテンツを複数の受信装置に送信する際の負荷を低減させたデータ送信装置およびデータ送信方法を提供する。【解決手段】同一のコンテンツデータを複数のデータ受信装置に送信する際、マルチキャスト送信等が許されない場合に、第１受信装置に送信するパケットについてチェックサムを生成するときに得られた積算値をＣＰＵ１５内のレジスタに保持しておく。そして、第２受信装置以降の受信装置に対してチェックサムを生成するときには、保持した積算値と、第１受信装置との宛先アドレスの差分とに基づいて、第２パケットに対する積算値を算出し、第２チェックサムを生成する。【選択図】図２
2006211227.tif 000002
【特許請求の範囲】
【請求項１】
一のコンテンツデータを複数の受信装置に送信するデータ送信装置であって、
前記一のコンテンツデータと、受信装置毎に異なる識別データとを有するパケットであって、各受信装置に対応する複数のパケットを生成するパケット生成部と、
前記複数の受信装置のうち第１受信装置に対応する第１パケットのデータを積算した積算値に基づいて、前記第１パケットに対する第１チェックサムを生成するチェックサム生成部と、
前記第１受信装置と、第１受信装置以外の第２受信装置との識別データの差分を取得し、当該識別データの差分と前記積算値とに基づいて、前記第２受信装置に対応する第２パケットの第２チェックサムを生成するチェックサム更新部と、
前記チェックサム生成部またはチェックサム更新部により生成されたチェックサムを含むパケットを、前記複数の受信装置に順次送信するデータ送信部と、
を有するデータ送信装置。
【請求項２】
前記第１パケットは、前記パケット生成部が生成した最初のパケットである
請求項１記載のデータ送信装置。
【請求項３】
前記識別データは、少なくとも受信装置のアドレスデータを含む
請求項１記載のデータ送信装置。
【請求項４】
前記パケット生成部は、受信装置毎に異なるヘッダデータを有する複数のパケットを生成し、
前記チェックサム更新部は、前記第１受信装置と、第１受信装置以外の第２受信装置とに対応するヘッダデータの積算値差分を取得し、当該積算値差分と前記積算値とに基づいて、前記第２受信装置に対応する第２パケットの第２チェックサムを生成する
請求項１記載のデータ送信装置。
【請求項５】
一のコンテンツデータを複数の受信装置に送信するためのデータ送信方法であって、
前記一のコンテンツデータと、複数の受信装置のうち第１受信装置固有の識別データとを有するパケットであって、前記第１受信装置に対応する第１パケットを生成するステップと、
第１パケットのデータを積算し、その積算値に基づいて前記第１パケットに対する第１チェックサムを生成し、前記第１パケットに付加するステップと、
前記第１パケットを前記第１受信装置に送信するステップと、
前記第１受信装置と、第１受信装置以外の第２受信装置との識別データの差分を算出するステップと、
当該識別データの差分と前記積算値とに基づいて、前記第２受信装置に対応する第２チェックサムを生成するステップと、
前記一のコンテンツデータに対して、前記第２チェックサムと前記第２受信装置の識別データとを付加し、前記第２受信装置に対応する第２パケットを生成するステップと、
前記第２パケットを前記第２受信装置に送信するステップと、
を有するデータ送信方法。
【請求項６】
前記識別データは、少なくとも受信装置のアドレスデータを含む
請求項５記載のデータ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像、音声等の様々なコンテンツデータをストリームデータとして複数の受信装置に配信するデータ送信装置およびデータ送信方法に関する。
【背景技術】
【０００２】
昨今、インターネット通信など、様々な通信媒体を介した画像、音声データ等の様々なコンテンツのデータ転送が盛んに行われている。特に、近年においては、インターネット上のデータ転送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。
ストリーム型伝送方式は、送信側から受信端末にデータ送信が行われている間に、並列して受信データの再生処理を実行するものであり、インターネット電話・遠隔テレビ会議や、たとえばビデオオンデマンド（ＶＯＤ）等、様々なコンテンツをストリーミング映像配信によって行うサービスに利用されている。
【０００３】
また、放送・通信・蓄積といったすべてのアプリケーションに対して汎用的に使用できる動画像圧縮方式として、ＭＰＥＧ(Moving Picture Experts Group)が知られている。
上記ストリーム型伝送方式では、ＭＰＥＧによるトランスポートストリーム（以下、ＭＰＥＧ−ＴＳと称する）を、イーサネット（登録商標）コントローラあるいはＩＥＥＥ８０２．１１に準拠した無線コントローラにより伝送することが行われている。たとえば、ＭＰＥＧ−ＴＳは、ＲＴＰ(Real-time Transport Protocol)／ＵＤＰ(User Datagram Protocol)やＨＴＴＰ(Hyper Text Transfer Protocol)／ＴＣＰ(Transport Control Protocol)などのプロトコルに従ってパケット単位で伝送される。
【０００４】
このようなストリーム型伝送方式では、パケット処理に対する負荷が大きく、高速・大容量のデータ転送におけるボトルネックとなっているため、この負荷を軽減するための様々な技術開発が行われている。
たとえば、下記特許文献１には、イーサネット対応コントローラと弾性バッファとを有し、受信したＴＣＰパケットを再組み立て／再転送することなく処理し、パケット処理の負荷を低減させる技術が提案されている。
【０００５】
【特許文献１】米国公開特許２００４００４２４８３号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、ネットワーク上で著作権に対応したコンテンツの伝送を行うための規格として、ＤＴＣＰ／ＩＰ(Digital Transmission Content Protection over Internet Protocol)が知られている。ＤＴＣＰ／ＩＰは、ＩＥＥＥ１３９４用の著作権保護方式として規格化されたＤＴＣＰ方式をＩＰネットワークに対応させるために、機能およびセキュリティの強化が図られた伝送方式である。
【０００７】
ＤＴＣＰ／ＩＰによる伝送においては、コンテンツが意図しない宛て先に送信されることを防止するため、送信装置は、いわゆるマルチキャスト送信ではなく、受信装置に対して１：１で認証およびコンテンツの伝送を行う。したがって、送信装置は、同一のコンテンツを複数の受信装置に転送する場合であっても、すべての受信装置に対して送信処理（パケット生成、認証、送信処理）を行う必要があり、その処理負荷が非常に大きいという課題がある。
【０００８】
たとえば、ＤＴＣＰ／ＩＰによる伝送においては、１台の送信装置に対し、規格上３４台の受信装置まで接続することが可能であるが、ＨＤ（高密度）動画のコンテンツ（２５Ｍｂｐｓ／本）を８台分（２００Ｍｂｐｓ）送信する場合、２０００ＭＩＰＳ級のＣＰＵを使用してもＣＰＵの負荷率は約８０％に達してしまうため、送信側のＣＰＵは実質上他の処理を実行することができない。
したがって、ＤＴＣＰ／ＩＰによる伝送では、送信側のＣＰＵの負荷を低減させることが特に要望される。
【０００９】
上述した観点に鑑み、本発明の目的は、同一のコンテンツを複数の受信装置に送信する際の処理の負荷を低減させたデータ送信装置およびデータ送信方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を克服するために、本発明の第１の観点は、一のコンテンツデータを複数の受信装置に送信するデータ送信装置であって、前記一のコンテンツデータと、受信装置毎に異なる識別データとを有するパケットであって、各受信装置に対応する複数のパケットを生成するパケット生成部と、前記複数の受信装置のうち第１受信装置に対応する第１パケットのデータを積算した積算値に基づいて、前記第１パケットに対する第１チェックサムを生成するチェックサム生成部と、前記第１受信装置と、第１受信装置以外の第２受信装置との識別データの差分を取得し、当該識別データの差分と前記積算値とに基づいて、前記第２受信装置に対応する第２パケットの第２チェックサムを生成するチェックサム更新部と、前記チェックサム生成部またはチェックサム更新部により生成されたチェックサムを含むパケットを、前記複数の受信装置に順次送信するデータ送信部と、を有するデータ送信装置である。
【００１１】
好適には、前記第１パケットは、前記パケット生成部が生成した最初のパケットである。
【００１２】
好適には、前記識別データは、少なくとも受信装置のアドレスデータを含む。
【００１３】
好適には、前記パケット生成部は、受信装置毎に異なるヘッダデータを有する複数のパケットを生成し、前記チェックサム更新部は、前記第１受信装置と、第１受信装置以外の第２受信装置とに対応するヘッダデータの積算値差分を取得し、当該積算値差分と前記積算値とに基づいて、前記第２受信装置に対応する第２パケットの第２チェックサムを生成する。
【００１４】
上記課題を克服するために、本発明の第２の観点は、一のコンテンツデータを複数の受信装置に送信するためのデータ送信方法であって、前記一のコンテンツデータと、複数の受信装置のうち第１受信装置固有の識別データとを有するパケットであって、前記第１受信装置に対応する第１パケットを生成するステップと、第１パケットのデータを積算し、その積算値に基づいて前記第１パケットに対する第１チェックサムを生成し、前記第１パケットに付加するステップと、前記第１パケットを前記第１受信装置に送信するステップと、前記第１受信装置と、第１受信装置以外の第２受信装置との識別データの差分を算出するステップと、当該識別データの差分と前記積算値とに基づいて、前記第２受信装置に対応する第２チェックサムを生成するステップと、前記一のコンテンツデータに対して、前記第２チェックサムと前記第２受信装置の識別データとを付加し、前記第２受信装置に対応する第２パケットを生成するステップと、前記第２パケットを前記第２受信装置に送信するステップと、を有するデータ送信方法である。
【００１５】
好適には、前記識別データは、少なくとも受信装置のアドレスデータを含む。
【００１６】
本発明に係るデータ送信装置の作用は、以下の通りである。
すなわち、パケット生成部は、一のコンテンツデータと、複数の受信装置のうち第１受信装置固有の識別データとを有するパケットであって、前記第１受信装置に対応する第１パケットを生成する。パケット生成部は、第１パケットのデータを積算し、その積算値に基づいて前記第１パケットに対する第１チェックサムを生成し、前記第１パケットに付加する。データ送信部は、第１パケットを第１受信装置に送信する。
次に、第２受信装置に対しては、先ず、第１受信装置との識別データの差分を算出する。そして、チェックサム更新部は、その識別データの差分と、第１チェックサムを生成する際に得られた積算値とに基づいて、第２受信装置に対応する第２チェックサムを生成する。
さらに、パケット生成部は、前記一のコンテンツデータに対して、生成された第２チェックサムと第２受信装置の識別データとを付加し、前記第２受信装置に対応する第２パケットを生成し、データ送信部は、第２パケットを第２受信装置に送信する。
この第２受信装置に対する処理は、残りの複数の受信装置のすべてに対して同様に行われる。
【発明の効果】
【００１７】
本発明によれば、同一のコンテンツを複数の受信装置に送信する場合に、チェックサム演算における積算値の算出を第１受信装置に対してのみ行えばよいので、全体として、送信に伴う処理の負荷を低減させることができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明に係るデータ送信装置の一実施形態について添付図面に関連付けて説明する。
図１は、実施形態に係るデータ送受信システムのコンテンツ送信態様を模式的に表した図である。
【００１９】
本実施形態に係るデータ送信装置１は、ＤＴＣＰ／ＩＰ規格に準拠してコンテンツデータを複数のデータ受信装置に送信する。ここで、ＤＴＣＰ／ＩＰ規格のデータ伝送においては、意図しない宛先にデータが送信されないことを保証するため、いわゆるブロードキャストあるいはマルチキャスト送信は許可されていない。
したがって、同一のコンテンツデータを複数のデータ受信装置に送信する場合であっても、図１に示すように、データ送信装置１は、ＴＣＰ／ＩＰパケット（以下、単にパケット，あるいはＴＣＰパケットと略記する）をその宛先（データ受信装置２ａ，２ｂ，２ｃ，２ｄ）毎に別々に作成する必要がある。なお、図１では、１つのパケットの送信を１つの矢印で示している。
【００２０】
データ送信装置１では、送信するパケット毎にそのパケットのチェックサムデータを生成する必要があるが、そのチェックサムの演算方法を改良することで、ＤＴＣＰ／ＩＰ規格に準拠したパケット送信に伴うＣＰＵの負荷を低減することを目的としている。
【００２１】
図２は、本発明に係るデータ処理装置を含むデータ送受信システムの一実施形態を示すシステム構成図である。
なお、図２に示すデータ送受信システムでは、データ送信装置１とデータ受信装置２とが１：１でデータの授受を行っているかのように記載されているが、実際には、データ送信装置１から同一のコンテンツデータがデータ受信装置２と同一の構成を有する複数のデータ受信装置に配信される。また、図２に示した例では、地上波デジタル放送による動画コンテンツをＴＶセットで再生する場合について示している。
【００２２】
以下、図２に示すデータ送受信システムの構成について説明する。
本実施形態に係るデータ送受信システムは、画像データを送信するデータ送信装置１、画像データを受信するデータ受信装置２、画像データを再生するＴＶセット３、から構成される。
【００２３】
データ送信装置１は、受信アンテナ１１、デジタルチューナ１２、チャンネルデコーダ１３、ＤＴＣＰ／ＩＰ暗号化器１４、ＣＰＵ１５、インタフェース１６、を含んで構成される。
以下では、ＭＰＥＧによる符号化を一例としてＭＰＥＧ−ＴＳ（トランスポートストリーム）データの場合を説明するが、パケット毎にチェックサムが演算されるストリームデータであれば、ＭＰＥＧ−ＴＳデータ以外のストリームデータに適用可能である。
【００２４】
デジタルチューナ１２は、受信アンテナ１１が受信した地上波デジタル放送波に用いるＯＦＤＭ(Orthogonal Frequency Division Multiplexing)の周波数を周波数変換によりダウンコンバートして、任意のチャンネル（放送局）の地上波デジタル放送信号Ｓ１２を抽出する。
チャンネルデコーダ１３は、地上波デジタル放送信号Ｓ１２を、たとえばＱＰＳＫ復調して復調信号を生成するとともに、当該復調信号から、コンテンツデータとしてのトランスポートストリームデータ（ＭＰＥＧ−ＴＳデータ）Ｓ１３を生成する。その際、このＭＰＥＧ−ＴＳデータＳ１３は、所定のバイト長、たとえば１５００バイト以下のデータ単位（分割データ）に分割される。
なお、以下の説明においては、送信対象の分割データを、それぞれコンテンツデータ＃１，コンテンツデータ＃２，…，コンテンツデータ＃Ｎと表記する。
【００２５】
ＤＴＣＰ／ＩＰ暗号化器１４は、ＭＰＥＧ−ＴＳデータＳ１３を暗号化し、暗号化ＭＰＥＧ−ＴＳデータＳ１４を生成する。暗号化の方法としては、たとえばＡＥＳ−１２８／２５６方式が使用される。
また、ＤＴＣＰ／ＩＰ暗号化器１４は、通信を確立させるときに、データ受信装置２のＤＴＣＰ／ＩＰ復号器２４と認証処理を行う。
【００２６】
ＣＰＵ１５は、データ送信装置１の全体の処理を統括するとともに、暗号化ＭＰＥＧ−ＴＳデータＳ１４に対して、ＲＴＰ／ＵＤＰやＨＴＴＰ／ＴＣＰなどのプロトコルに従ったパケット単位のデータを生成する。
すなわち、ＣＰＵ１５では、暗号化された分割データに対して、ＴＣＰヘッダとＩＰヘッダを付加してＴＣＰパケットを生成する。その際に、ＴＣＰパケットに対するチェックサムデータを生成し、そのチェックサムデータをＴＣＰヘッダ内の所定のアドレスに書き込む。ＣＰＵ１５によるチェックサムの演算処理については、後述する。
【００２７】
ＣＰＵ１５により生成されたパケットは、たとえば、イーサネットコントローラあるいはＩＥＥＥ８０２．１１に準拠した無線コントローラ等を含むインタフェース１６を通して、データ受信装置２に対して送信される。
【００２８】
データ受信装置２は、インタフェース２１、ＣＰＵ２２、ＦＩＦＯバッファ２３と、ＤＴＣＰ／ＩＰ復号器２４、ＭＰＥＧ−ＴＳデコーダ２５、を含んで構成される。
データ受信装置２では、データ送信装置１より送信された、動画コンテンツとしてのＴＣＰパケットを順次復号して、ＴＶセット３の表示画面上でその動画コンテンツを再生する。
【００２９】
インタフェース２１は、送信側からの信号を正しく受信できるように、たとえば、イーサネットコントローラあるいはＩＥＥＥ８０２．１１に準拠した無線コントローラ等を含む。
ＣＰＵ２２は、データ受信装置２全体の処理を統括するとともに、ＲＴＰ／ＵＤＰやＨＴＴＰ／ＴＣＰなどのプロトコルに従ったパケット単位の受信データからＭＰＥＧ−ＴＳパケットデータを抽出して、ＦＩＦＯバッファ２３に順次格納する。
【００３０】
なお、ＭＰＥＧ−ＴＳパケットを伝送する際には、ネットワークの特性上、パケットドロップが発生する場合があり、その場合には、パケットの再送信を行われる。
その際、上記パケットドロップおよびパケット再送信が行われた場合に元々のパケット間のタイミングを補償すること、ＤＴＣＰ／ＩＰ復号器２４での処理による遅延に対してタイミングを補償すること等を目的として、データ受信装置２は、受信したＭＰＥＧ−ＴＳデータをＦＩＦＯバッファ２３に一時的に格納する構成としている。
なお、ＦＩＦＯバッファ２３は、ＣＰＵ２２内部に構成されていてもよい。
【００３１】
ＣＰＵ２２では、送信されてきた各パケットのチェックサムの値が正しい値であるかを確認する。すなわち、送信側で行われたチェックサム演算と同様の演算を行って、各パケットに書き込まれたチェックサムと一致するか否かを確認する。そして、一致していれば、そのパケットをＦＩＦＯバッファ２３に転送し、一致していなければ、データ送信装置１に対して、そのパケットの再送信を要求する。
なお、本実施形態に係るデータ送受信システムにおいて、データ受信装置２では、受信した単一のパケットに対してのみチェックサム演算を行えばよいので、チェックサム演算に伴うＣＰＵ２２の負荷は、データ送信装置１のＣＰＵ１５ほど重くはない。
【００３２】
ＦＩＦＯバッファ２３に一時的に格納されたパケットは、所定のタイミングで順次ＤＴＣＰ／ＩＰ復号器２４により暗号が解除（復号化）され、ＭＰＥＧ−ＴＳとしての信号Ｓ２４として出力される。そして、このＭＰＥＧ−ＴＳは、ＭＰＥＧ−ＴＳデコーダ２５によりデコードされて、表示のためにＴＶセット３に送出される。
【００３３】
以上、図２に関連付けて本実施形態に係るデータ送受信システムの構成について述べたが、データ送信装置の構成は、上述した構成に限られない。
すなわち、図２では、データ送信装置がコンテンツデータを受信アンテナ経由で取得する場合について説明したが、これに限られず、データ送信装置は、光ディスクやハードディスク等のデータストレージから取得するようにしてもよい。
【００３４】
図３は、データ送信装置がデータストレージからコンテンツデータを取得する場合の一構成例を示す図である。
図３に示すデータ送信装置４は、光ディスクやハードディスク等のデータストレージ４１、バス−ＡＴＡブリッジ４２、ＤＴＣＰ／ＩＰエンジン４３、ＣＰＵ４４、ＥＰＲＯＭ４５、ＳＤＲＡＭ４６、インタフェース４７を含んで構成される。
データ送信装置４では、ＣＰＵ４４と、バス−ＡＴＡブリッジ４２，ＤＴＣＰ／ＩＰエンジン４３，インタフェース４７とがシステムバスにより接続され、データストレージ４１とバス−ＡＴＡブリッジ４２とがＡＴＡインタフェースにより接続されて、相互にデータ転送が行われる。
【００３５】
図３に示すデータ送信装置４では、先ず、データストレージ４１に格納されたコンテンツデータが、バス−ＡＴＡブリッジ４２を介して、ＣＰＵ４４に転送される。ＣＰＵ４４は、転送されたコンテンツデータをＤＴＣＰ／ＩＰエンジン４３に転送し、そこで暗号化が行われる。そして、暗号化されたコンテンツデータは、ＣＰＵ４４によりパケット化され、イーサコントローラ等を含むインタフェース４７を介して図示しないデータ受信装置へ送信される。
図３に示すデータ送信装置４においても、同一のコンテンツデータを複数のデータ受信装置２に配信する際に各パケットに付加するチェックサムの演算は、ＣＰＵにより実行される。
【００３６】
次に、データ送信装置１のＣＰＵ１５（または、データ送信装置４のＣＰＵ４４）によって行われる、ＴＣＰパケットのチェックサム演算処理について、図４〜６に関連付けて説明する。
【００３７】
図４は、ＴＣＰパケットの構成の概略を示す図である。
図４に示すように、ＣＰＵ１５により生成されるＴＣＰパケットは、ＴＣＰヘッダとコンテンツデータ（分割データ）を含み、ＴＣＰヘッダ（以下、ヘッダと略記する）には、パケットの宛先アドレスと送信元アドレスとが書き込まれている。
【００３８】
宛先アドレスは、以下デスティネーションアドレスとも称し、データ受信装置２固有の識別データである。送信元アドレスは、以下ソースアドレスとも称し、データ送信装置１固有の識別データである。
なお、ＴＣＰパケットは、１６ビット単位でデータが配列されているとする。
【００３９】
ＣＰＵ１５は、図４に示すように、ＴＣＰパケットについて最初のアドレスから最後のアドレスまでのすべての１６ビットデータを積算し、その積算値を図示しない３２ビットのレジスタに保持する。その際、ヘッダの９ワード目のアドレスにチェックサムを書き込むので、この９ワード目のアドレスは、１６進数で「０ｘ００００」のデータとし、実質的に積算を行わない。
さらに、３２ビットのレジスタに保持されるデータに対して、上位１６ビットのデータと下位１６ビットのデータとを加算し、その加算結果を反転した結果がチェックサムの値である。このチェックサムがヘッダの９ワード目に書き込まれる。
【００４０】
データ送信装置１のＣＰＵ１５は、同一のコンテンツデータを送信する場合には、１台目のデータ受信装置に送信するパケットについて上述したチェックサム演算を行うが、２台目以降のデータ受信装置に送信するパケットについては、すでに行われた１台目に対して得られた積算値を利用して演算負荷を低減する。
【００４１】
図５は、同一のコンテンツデータを複数のデータ受信装置に送信する場合の処理を模式的に表した図である。
図５では、コンテンツデータが分割された複数の分割データに対して、順次パケットを生成し、送信する場合の処理を示す。図では、コンテンツデータ＃１についての処理を例示するが、他の分割データ（コンテンツデータ＃２，＃３，…，＃Ｎ，…）についても同様である。また、図５では、３つのデータ受信装置として、第１〜第３受信装置に同一のコンテンツデータを送信する場合について示す。
【００４２】
図５において、データ送信装置１では、コンテンツデータ＃１がＤＴＣＰ／ＩＰ暗号化器１４により暗号化され（ステップＳＴ１）、ＣＰＵ１５により、第１受信装置に対してＴＣＰ／ＩＰもしくはＵＤＰ／ＩＰ規格に準拠したパケットが生成される（ステップＳＴ２）。そして、生成されたパケットに対して、上述したチェックサム演算を行って、ヘッダにチェックサムを書き込む。さらに、生成されたパケットは、インタフェース１６により第１受信装置に送信される（ステップＳＴ３）。
【００４３】
なお、チェックサム演算を行う際に、第１受信装置に対するパケットに対して得られた、３２ビットレジスタに格納された積算値（Ｘ０）は、すべての受信装置に対してコンテンツデータ＃１の送信が完了するまで、そのレジスタに保持しておく。
【００４４】
２台目以降の受信装置に対する処理では、すでに１台目向けに生成されたパケットを利用してＣＰＵ１５の負荷を低減する。すなわち、コンテンツデータ＃１は１台目と同一であり、ヘッダでは、宛先アドレスが１台目と異なるだけであるため、１台目向けに生成されたパケットを更新することによって第２受信装置向けのパケットを生成し（ステップＳＴ４）、送信する（ステップＳＴ５）。
【００４５】
ここで、第１受信装置向けに生成されたパケットを第１パケット、第１パケットに書き込まれたチェックサムを第１チェックサムとし、第２受信装置向けに生成するパケットを第２パケット、第２パケットに書き込むべきチェックサムを第２チェックサムと称する。
すると、第１パケットおよび第２パケットに含まれるコンテンツデータ＃１は、全く同一のデータであるため、第２パケットは、第１パケットと比較して、ヘッダの中の宛先アドレス（デスティネーションアドレス）とチェックサムを更新すればよい。
【００４６】
パケットの更新は、具体的には以下の通りである。
（ａ）積算値の変更処理
まず、下記式（１）に従って、チェックサム演算における積算値を変更する。
Ｘ＝Ｘ０−ａ１＋ａ２      …（１）
なお、
ａ１：第１受信装置の宛先アドレス
ａ２：第２受信装置の宛先アドレス
Ｘ０：３２ビットレジスタに保持する積算値
Ｘ  ：更新された積算値
【００４７】
（ｂ）反転処理
上記式（１）により得られた積算値Ｘを反転処理して、第２チェックサムを生成する。
【００４８】
上記処理（ａ）および（ｂ）に示したように、第２チェックサムを生成する際には、大容量のコンテンツデータを再度積算する必要がないので、ＣＰＵの負荷が大幅に軽減される。
【００４９】
第３受信装置向けの処理についても、第２受信装置向けの処理と同様に、第１受信装置向けに生成されたパケットを更新することによって第２受信装置向けのパケットを生成し（ステップＳＴ６）、送信する（ステップＳＴ７）。
【００５０】
次に、ＣＰＵ１５により行われるチェックサム演算の処理について、フローチャートを用いて、より具体的に説明する。
図６は、同一のコンテンツデータを複数のデータ受信装置に送信する複数のパケットを生成する場合のチェックサムの演算処理を示すフローチャートである。
なお、図６において、ステップＳＴ１０〜ＳＴ１７の処理は、図５における第１受信装置向けのパケットに書き込むチェックサムを算出する処理であり、ステップＳＴ１８〜ＳＴ２０は、図５における第２受信装置以降の受信装置に対するパケットに書き込むべきチェックサムを算出する処理である。
【００５１】
図６に示すように、第１受信装置向けのパケットについて、各アドレスのデータを順次１６ビットレジスタに入力して積算し、積算結果を３２ビットレジスタに格納する（ステップＳＴ１０，１１）。ヘッダの９ワード目は、チェックサムを書き込む領域であるため、「０ｘ００００」とし、パケットの最後のアドレスまで積算を行う（ステップＳＴ１２〜１４）。そして、ステップＳＴ１０〜１４で得られた積算値に対して、ステップＳＴ１５では、送信元アドレス（ソースアドレス）と宛先アドレス（デスティネーションアドレス）、プロトコル番号、パケットのバイト長を加算し、３２ビットレジスタに格納する。
さらに、３２ビットレジスタの上位１６ビットの値と下位１６ビットの値を加算して反転し（ステップＳＴ１６）、第１受信装置向けのパケットに対するチェックサムを出力する（ステップＳＴ１７）。
【００５２】
第２受信装置以降の受信装置向けのパケットについては、送信対象のコンテンツデータが第１受信装置向けにすでに生成したパケットに含まれるコンテンツデータと異なる場合には（ステップＳＴ１８）、図６の処理を終了し、ステップＳＴ１０〜ＳＴ１７と同様の処理によってチェックサムを生成する。
一方、送信対象のコンテンツデータが第１受信装置向けにすでに生成したパケットに含まれるコンテンツデータと同一である場合には（ステップＳＴ１８）、前述した式（１）に従って、宛先アドレスの差分に応じてチェックサムを生成し（ステップＳＴ１９）、出力する（ステップＳＴ２０）。
【００５３】
以上説明したように、本実施形態に係るデータ送信装置１によれば、同一のコンテンツデータを複数のデータ受信装置に送信する際、マルチキャスト送信等が許されない場合に、第１受信装置に送信するパケットについてチェックサムを生成するときに得られた積算値をレジスタに保持しておく。そして、第２受信装置以降の受信装置に対してチェックサムを生成するときには、保持した積算値と、第１受信装置との宛先アドレスの差分とに基づいて、第２パケットに対する積算値を算出し、第２チェックサムを生成するので、以下の効果が得られる。
すなわち、２台目以降の受信装置に送信するパケットに対して、再度積算演算を行う必要がないので、データ送信装置１のＣＰＵの負荷が大幅に軽減される。特に、大容量のコンテンツデータを多数の受信装置に送信する場合に、ＣＰＵの負荷の軽減代が顕著である。
【００５４】
なお、本発明は上述した実施形態の内容に限定されず、本発明の要旨を変更しない範囲で当業者が適宜改変し得るものである。
たとえば、上述した実施形態では、最初に送信対象となる受信装置向けのパケットに対してチェックサムを演算し、２番目以降に送信対象となる受信装置向けのパケットに対して、そのチェックサムを更新するように構成したが、チェックサムを演算する対象となるパケットは、最初に送信対象となる受信装置向けのパケットに限られず、任意のタイミングで設定し得る。
【００５５】
上述した実施形態では、受信装置間の宛先アドレスの差分を考慮して第２受信装置以降の受信装置に対するチェックサムを生成したが、ヘッダの積算値の差分を考慮してチェックサムを生成してもよい。かかる場合には、宛先アドレスの差分のみを考慮する場合と比較すると、ＣＰＵの負荷が若干重くなるが、大容量のコンテンツデータと比較してヘッダデータのデータ量は小さいため、すべての受信装置に対して１からチェックサムを演算する場合と比較すればＣＰＵの負荷軽減の効果がある。
また、受信装置毎にヘッダの内容のうち複数のデータ項目を変更する必要がある場合には、ヘッダの積算値の差分を考慮すべき場合があり得る。
かかる場合には、第１受信装置に対するチェックサム演算の際に、パケット全体の積算値とヘッダの積算値とをそれぞれ３２ビットレジスタに格納しておき、第２受信装置以降の受信装置に対するチェックサム演算では、第１受信装置とのヘッダの積算値の差分に基づいて、すでに格納した積算値を変更する。
【００５６】
本発明の識別データは、本実施形態では宛先アドレスに相当するが、これに限られない。
ヘッダにおいて、受信装置毎に異なる他のデータ項目があれば、その他のデータ項目のデータ差分を考慮して、積算値を変更する必要があることは明らかである。
たとえば、積算値の変更処理を以下式（２）のように行う。
【００５７】
Ｘ＝Ｘ０−（ｉ１１−ｉ２１）−（ｉ１２−ｉ２２）−…          …（２）
なお、
ｉ１１，ｉ１２，…：第１受信装置の識別データ１，識別データ２，…
ｉ２１，ｉ２２，…：第２受信装置の識別データ１，識別データ２，…
Ｘ０  ：３２ビットレジスタに保持する積算値
Ｘ    ：更新された積算値
【００５８】
＜改良例＞
以下、上述した実施形態の改良例について述べる。
上述した実施形態に係るデータ送信装置１では、第１受信装置に対するチェックサムの演算をＣＰＵ内部で行っているが、以下に述べる改良例では、このチェックサム演算処理をＣＰＵの外部のハードウエア（ＡＳＩＣ等）で行うことで、ＣＰＵの負荷をさらに低減させることを目的としている。
したがって、本改良例に係るデータ送信装置のシステム構成は、図２に示したデータ送信装置１の構成と同様であり、ＣＰＵ１５の処理の一部（チェックサム生成部分）が外部のチェックサム生成用ＡＳＩＣで実行される。
【００５９】
図７は、チェックサム生成用ＡＳＩＣ１７の構成を示す図である。
チェックサム生成用ＡＳＩＣ１７は、１６ビットのシフトレジスタ１７１、３２ビットのレジスタ１７２，１７３、加算器１７４、遅延器１７５を含む。
図７において、シフトレジスタ１７１には、コンテンツデータ（分割データ）が順次１６ビット単位でチェックサム生成用ＡＳＩＣ１７に入力されてシフトされる。レジスタ１７２，１７３には、コンテンツデータのデータの積算値が格納されていく。
レジスタ１７３には、チェックサム生成用ＡＳＩＣ１７がパケットを処理する際には、外部のＣＰＵによりＣＬＲ端子を介してリセットされる。
【００６０】
チェックサム生成用ＡＳＩＣ１７は以下の通り動作する。
まず、データ＃１とレジスタ１７３の積算値（最初は「０」）と加算器１７４により加算されて、レジスタ１７２にデータ＃１が格納される。
次に、レジスタ１７２に格納されたデータ＃１は遅延器１７５により遅延されてレジスタ１７３に転送される。さらに、シフトレジスタ１７１でシフトされたデータ＃２と、レジスタ１７３に格納されたデータ＃１とが加算され、（データ＃１＋データ＃２）がレジスタ１７２に格納される。
以上、同様に処理が行われる結果、レジスタ１７２には、コンテンツデータの積算値が格納されることになる。
【００６１】
さらに、レジスタ１７２に格納された積算値に対して、送信元アドレス（ソースアドレス）と宛先アドレス（デスティネーションアドレス）、プロトコル番号、パケットのバイト長を加算する。この３２ビットの加算結果のうち上位１６ビットと下位１６ビットと加算し、その結果を反転する。この積算値に対する処理を、チェックサム生成用ＡＳＩＣ１７内に論理回路で構成する。
【００６２】
以上のように、同一のコンテンツデータを複数の受信装置に配信する際に、最初に送信対象となる受信装置に対するチェックサムの生成をＣＰＵによらずに行うことで、さらにＣＰＵの負荷を軽減することができる。
【図面の簡単な説明】
【００６３】
【図１】実施形態に係るデータ送受信システムのコンテンツ送信態様を模式的に表した図である。
【図２】本発明に係るデータ処理装置を含むデータ送受信システムの一実施形態を示すシステム構成図である。
【図３】データ送信装置がデータストレージからコンテンツデータを取得する場合の一構成例を示す図である。
【図４】ＴＣＰパケットの構成の概略を示す図である。
【図５】同一のコンテンツデータを複数のデータ受信装置に送信する場合の処理を模式的に表した図である。
【図６】同一のコンテンツデータを複数のデータ受信装置に送信する複数のパケットを生成する場合のチェックサムの演算処理を示すフローチャートである。
【図７】チェックサム生成用ＡＳＩＣの構成を示す図である。
【符号の説明】
【００６４】
１…データ送信装置、１１…受信アンテナ、１２…デジタルチューナ、１３…チャンネルデコーダ、１４…ＤＴＣＰ／ＩＰ暗号化器、１５…ＣＰＵ、１６…インタフェース、２，２ａ，２ｂ，２ｃ，２ｄ…データ受信装置、２１…インタフェース、２２…ＣＰＵ、２３…ＦＩＦＯバッファ、２４…ＤＴＣＰ／ＩＰ復号器、２５…ＭＰＥＧ−ＴＳデコーダ、３…ＴＶセット、４…データ送信装置、４１…データストレージ、４２…バス−ＡＴＡブリッジ、４３…ＤＴＣＰ／ＩＰエンジン、４４…ＣＰＵ、４５…ＥＰＲＯＭ、４６…ＳＤＲＡＭ、４７…インタフェース、５…ルータ、１７…チェックサム生成用ＡＳＩＣ、１７１…シフトレジスタ、１７２，１７３…レジスタ、１７４…加算器、１７５…遅延器。
【図１】
2006211227.tif 000003
【図２】
2006211227.tif 000004
【図３】
2006211227.tif 000005
【図４】
2006211227.tif 000006
【図５】
2006211227.tif 000007
【図６】
2006211227.tif 000008
【図７】
2006211227.tif 000009