(57)【要約】【課題】ストリーミング番組の時間情報を隠蔽し、クライアントとして契約しているユーザの趣味趣向が容易に解析されることを防止する。【解決手段】クライアント側の受信再生装置１が、再生したい番組データのリクエストと、他の任意の番組の少なくとも一部のデータであるダミーの番組データのリクエストとを発生させる要求発生部１１，１２および１６と、再生装置１３とを有する。これらのリクエストに応じてサーバから送られてくるパケットデータが受信され、これがダミーの番組データであるか否かが識別情報Ｓをもとに判別されると、再生装置１３は、ダミーの番組データでないパケットデータを再生する。【選択図】  図２
2005005986.tif 000002
【特許請求の範囲】
【請求項１】
通信回線を利用して番組データの配信を行うサーバに、再生したい番組データの少なくとも種類と開始時刻とを要求し、当該要求に応じて、前記サーバから前記通信回線を利用して分割された状態で送られてくる前記番組データを順次受信しながら再生する番組データの受信再生装置であって、
前記再生したい番組データの要求と、他の任意の番組の少なくとも一部のデータであるダミーの番組データの要求とを発生させる要求発生部と、
前記要求発生部で発生させた要求に応じて前記サーバから送られてくるデータを受信し、当該受信したデータがダミーの番組データであるか否かを前記要求発生部からの識別情報をもとに判別し、ダミーの番組データでない場合に当該受信したデータを再生するデータ受信再生部と、
を有する番組データの受信再生装置。
【請求項２】
前記要求発生部は、前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力する
請求項１に記載の番組データの受信再生装置。
【請求項３】
前記要求発生部は、前記再生したい番組データの要求と、当該再生したい番組データを基準として周期的に開始時刻が決められた前記ダミーの番組データの要求とを発生させ、当該２つの要求を前記サーバに出力する
請求項１に記載の番組データの受信再生装置。
【請求項４】
前記要求発生部は、
前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力する第１の要求発生部と、
前記再生したい番組データを基準として周期的に開始時刻が決められたダミーの番組データの要求を発生させ、前記サーバに出力する第２の要求発生部と、
を含む請求項１に記載の番組データの受信再生装置。
【請求項５】
クライアントが再生したい番組データの少なくとも種類と開始時刻とを含む要求を通信回線から受信し、当該要求に応じた番組データの配信を、前記通信回線を利用して行う番組データの配信装置であって、
前記要求を受けたときは、前記再生したい番組データの前および後の少なくとも一方にダミーデータを付加し、見かけ上１つの番組データとして、当該要求に応じた時刻に前記クライアントに送信する
番組データの配信装置。
【請求項６】
前記ダミーデータは、前記クライアントが再生したい番組以外の任意の番組の少なくとも一部のデータである
請求項５に記載の番組データの配信装置。
【請求項７】
通信回線を利用して番組データの配信を行うサーバに、再生したい番組データの少なくとも種類と開始時刻とを要求し、当該要求に応じて、前記サーバから前記通信回線を利用して分割された状態で送られてくる前記番組データを順次受信しながら再生する番組データの受信再生方法であって、
前記再生したい番組データの要求と、他の任意の番組の少なくとも一部のデータであるダミーの番組データの要求とを発生させ、前記サーバに出力するステップと、
前記要求の発生時に番組データの識別情報を生成するステップと、
前記要求に応じて前記サーバから送られてくるデータを受信し、当該受信したデータがダミーの番組データであるか否かを、前記識別情報をもとに判別するステップと、
前記受信したデータがダミーの番組データでない場合に、当該受信したデータを再生するステップと、
を含む番組データの受信再生方法。
【請求項８】
前記要求を発生させるステップでは、前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力する
請求項７に記載の番組データの受信再生方法。
【請求項９】
前記要求を発生させるステップでは、前記再生したい番組データの要求と、当該再生したい番組データを基準として周期的に開始時刻が決められた前記ダミーの番組データの要求とを発生させ、当該２つの要求を前記サーバに出力する
請求項７に記載の番組データの受信再生方法。
【請求項１０】
前記要求を発生させるステップが、
前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力するステップと、
前記再生したい番組データを基準として周期的に開始時刻が決められたダミーの番組データの要求を発生させ、前記サーバに出力するステップと、
を含む請求項７に記載の番組データの受信再生方法。
【請求項１１】
クライアントが再生したい番組データの少なくとも種類と開始時刻とを含む要求を通信回線から受信し、当該要求に応じた番組データの配信を、前記通信回線を利用して行う番組データの配信方法であって、
前記要求を受けたときは、前記再生したい番組データの前および後の少なくとも一方にダミーデータを付加し、見かけ上１つの番組データとして、当該要求に応じた時刻に前記クライアントに送信する
番組データの配信方法。
【請求項１２】
前記ダミーデータは、前記クライアントが再生したい番組以外の任意の番組の少なくとも一部のデータである
請求項１１に記載の番組データの配信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パケット等の単位に分割して配信された音声や映像などの番組データを順次受信しながら再生する、いわゆるストリーミングによる番組データの受信再生装置と、その方法に関する。また、本発明は、クライアントからの要求に応じた番組データの配信装置と、その方法に関する。
【０００２】
【従来の技術】
インターネット等の通信回線を利用した、いわゆるストリーミングと称される番組データの配信技術が知られている（たとえば、特許文献１参照）。
ストリーミングでは、番組を配信する会社の番組配信サーバ（以下、ストリーミングサーバという）が、クライアントのコンピュータからの要求に応じて、要求された番組内容（コンテンツ）をパケット等の細かな単位に分割して、要求に応じた時刻に順次配信する。クライアントは、送られてくるパケットデータをコンピュータ内のバッファにある程度蓄積しながら順次、ディスプレイに表示するなどして実時間で再生する。
【０００３】
また、ストリーミングによる番組配信には、ストリーミングサーバとクライアントとが１対１の関係で送受信を行うユニキャストストリーミングと、複数のクライアントコンピュータが同じコンテンツを同時視聴できるマルチキャストストリーミングとに分類されるが、いずれの場合も、インターネットなどの通信回線の経路途中には多くのインタネットサービスプロバイダ（ＩＳＰ）が接続されているため、番組データが他のＩＳＰにキャッシュされるおそれがある。
【０００４】
ここで、番組配信会社にクライアントとして契約している、あるユーザが、自分の趣味趣向に応じた番組の配信をそのストリーミングサーバに対し要求し、その番組の受信を定期的に繰り返すとする。その場合、通信回線途中の他のＩＳＰがキャッシュしたデータを解析することで、たとえば「○○という歌手が好きである」といった、そのユーザの趣味趣向が把握されてしまう可能性がある。これはライブ放送などでは、その会社があらかじめ作成した番組配信のスケジュール表をユーザが見て、自分の好きな番組を定期的に予約するといったユーザの行動にある一定の規則性があるためである。
【０００５】
また、このような過去に行った番組視聴などの行動の規則性を解析することで、将来のユーザの行動を予測する技術も発達してきている（たとえば、特許文献２参照）。
【０００６】
これらの個人情報の解析を困難にし、また、契約していないユーザが番組を盗むことを防止する意味でも、通常、ストリーミングするデータを暗号化することにより番組内容が、契約したクライアント以外の他人に知られないようにしている。たとえばＲＦＣ２４０１といった暗号化の標準規格では、ＩＰｓｅｃ（ＩＰ  ｓｅｃｕｒｉｔｙ  ｐｒｏｔｏｃｏｌ）を定め、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットのペイロード部分、すなわちストリーミングするデータそのものを保護している。
【０００７】
【特許文献１】
特開２００３−８７７５１号公報
【特許文献２】
特開２００１−１３４７０６号公報
【０００８】
【発明が解決しようとする課題】
ところが、このような暗号化により受信しているデータの中身が隠蔽されたとしても、たとえば「７月２日の１５：００から２時間のストリーミングをしていた」、あるいは「毎週火曜日の２３：００から２３：３０までストリーミングをしている」などのストリーミングの開始時刻、時間および周期などの時間情報は隠蔽することができない。これは、通常の暗号化処理はその処理の前後でデータサイズが変わらないため、時間情報は暗号化しても変化しないためである。
そのため、通信経路途中でキャッシュされた時間情報が、ストリーミングの番組スケジュール表と照らし合わされると、あるユーザの視聴番組は「常に△△というタレントが出ている番組が放送されている時間帯と重なっている」ことが解析によりわかってしまい、その解析によりユーザの趣味趣向が推測される危険性が高い。
【０００９】
本発明の第１の目的は、いわゆるストリーミングにおいて番組の時間情報を隠蔽し、クライアントとして契約しているユーザの趣味趣向が容易に解析されることを防止した番組データの受信再生装置と、その方法とを提供することにある。また、本発明の第２の目的は、番組の時間情報を隠蔽して、クライアントとして契約しているユーザの趣味趣向が容易に解析されることを防止した番組データの配信を、当該クライアントからの要求に応じて行う番組データの配信装置と、その方法に関する。
【００１０】
【課題を解決するための手段】
本発明に係る番組データの受信再生装置は、上記した第１の目的を達成するためのものであり、通信回線を利用して番組データの配信を行うサーバに、再生したい番組データの少なくとも種類と開始時刻とを要求し、当該要求に応じて、前記サーバから前記通信回線を利用して分割された状態で送られてくる前記番組データを順次受信しながら再生する番組データの受信再生装置であって、前記再生したい番組データの要求と、他の任意の番組の少なくとも一部のデータであるダミーの番組データの要求とを発生させる要求発生部と、前記要求発生部で発生させた要求に応じて前記サーバから送られてくるデータを受信し、当該受信したデータがダミーの番組データであるか否かを前記要求発生部からの識別情報をもとに判別し、ダミーの番組データでない場合に当該受信したデータを再生するデータ受信再生部と、を有する。
【００１１】
好適に、前記要求発生部は、前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力する。
あるいは、好適に、前記要求発生部は、前記再生したい番組データの要求と、当該再生したい番組データを基準として周期的に開始時刻が決められた前記ダミーの番組データの要求とを発生させ、当該２つの要求を前記サーバに出力する。
【００１２】
本発明に係る番組データの受信再生方法は、前記第１の目的を達成するためのものであり、通信回線を利用して番組データの配信を行うサーバに、再生したい番組データの少なくとも種類と開始時刻とを要求し、当該要求に応じて、前記サーバから前記通信回線を利用して分割された状態で送られてくる前記番組データを順次受信しながら再生する番組データの受信再生方法であって、前記再生したい番組データの要求と、他の任意の番組の少なくとも一部のデータであるダミーの番組データの要求とを発生させ、前記サーバに出力するステップと、前記要求の発生時に番組データの識別情報を生成するステップと、前記要求に応じて前記サーバから送られてくるデータを受信し、当該受信したデータがダミーの番組データであるか否かを、前記識別情報をもとに判別するステップと、前記受信したデータがダミーの番組データでない場合に、当該受信したデータを再生するステップと、を含む。
【００１３】
好適に、前記要求を発生させるステップでは、前記再生したい番組データの開始前、終了後の少なくとも一方に前記ダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させ、前記サーバに出力する。
あるいは、好適に、前記要求を発生させるステップでは、前記再生したい番組データの要求と、当該再生したい番組データを基準として周期的に開始時刻が決められた前記ダミーの番組データの要求とを発生させ、当該２つの要求を前記サーバに出力する。
【００１４】
このように構成された番組データの受信再生装置およびその方法によれば、クライアントが再生したい番組を選択し、その配信の要求を発生させる際に、要求発生部が（または、その要求発生に対応するステップでは）、再生したい番組のほかに、他の任意の番組データの少なくとも一部のデータからなるダミーの番組データの要求を発生させる。本発明では、その２つの要求の発生の好ましい仕方が２種類ある。
第１の要求発生の仕方では、再生したい番組データの開始前、終了後の少なくとも一方にダミーの番組データを付加し、見かけ上１つの番組データとした要求を発生させる。これにより見かけ上、クライアントが出した要求が示す番組データは、開始時刻と終了時刻の一方または双方が、再生したい番組より時間的にずれたものとなる。ただし、発生した要求には再生したい番組は必ず含まれている。また、どこまでがダミーの番組データでどこからが再生したい番組データであるかの識別情報は、このクライアント側の受信再生装置内に保持されるので、外に漏れない。
第２の要求発生の仕方では、再生したい番組データの要求と、当該再生したい番組データを基準として周期的に開始時刻が決められたダミーの番組データの要求とを発生させる。これにより２種類の要求が混在しているが、見かけ上、どの要求が再生したい番組データのもので、どの要求がダミーの番組データのものかの識別情報は、このクライアント側の内に保持されるので、外に漏れない。
何れの場合でも、発生させた要求は通信回線を介して外部のサーバに送られ、識別情報は内部の受信再生部に送られる。
【００１５】
この要求を通信回線から受信したサーバが、当該要求に応じて番組データの配信を行うと、その番組データがパケット等の単位に分割されサーバから順次送られてくる。受信再生装置の受信再生部が（または、その受信再生に対応するステップでは）、この番組データの分割単位を順次受信し、当該受信した分割単位のデータがダミーの番組データであるか否かを、入力された識別情報をもとに判別する。再生（のステップ）では、受信した分割単位のデータがダミーの番組データの場合に再生を行わないが、それ以外の場合に、当該受信した分割単位のデータが順次再生され、視聴に供せられる。
【００１６】
本発明に係る番組データの配信装置は、前記第２の目的を達成するためのものであり、クライアントが再生したい番組データの少なくとも種類と開始時刻とを含む要求を通信回線から受信し、当該要求に応じた番組データの配信を、前記通信回線を利用して行う番組データの配信装置であって、前記要求を受けたときは、前記再生したい番組データの前および後の少なくとも一方にダミーデータを付加し、見かけ上１つの番組データとして、当該要求に応じた時刻に前記クライアントに送信する。
【００１７】
本発明に係る番組データの配信方法は、前記第２の目的を達成するためのものであり、クライアントが再生したい番組データの少なくとも種類と開始時刻とを含む要求を通信回線から受信し、当該要求に応じた番組データの配信を、前記通信回線を利用して行う番組データの配信方法であって、前記要求を受けたときは、前記再生したい番組データの前および後の少なくとも一方にダミーデータを付加し、見かけ上１つの番組データとして、当該要求に応じた時刻に前記クライアントに送信する。
【００１８】
このように構成された番組データの配信装置およびその方法によれば、クライアントが再生したい番組を選択し、その配信の要求を当該配信装置に通信回線を利用して送ると、その要求を配信装置が受信する。配信装置は、受けた要求に応じてクライアントが再生したい番組データを選択し、その番組データの前および後の少なくとも一方にダミーデータを付加する。ダミーデータは再生の可能、不可能は問わない。このダミーデータを付加した番組データは、見かけ上１つの番組データとして、要求に応じた時刻にクライアントに送信される。ダミーデータは見たい番組の、好ましくは最後に付加されているとすると、再生不能の場合は視聴したい番組の終了時点で再生が停止するし、再生可能の場合は、視聴したい番組が終了すると通常、クライアントが再生を停止させる。停止させない場合でも、ダミーの番組は当該クライアントにとっては余り意味のない視聴価値が小さい番組である。
【００１９】
【発明の実施の形態】
図１に、本実施の形態で使用される通信回線例としてインターネットを模式的に示す。
インターネット通信網３０には、多数のパーソナルコンピュータやインターネットサービスプロバイダ（ＩＳＰ）３１が有機的に接続されてデータの相互通信環境が構築されている。あるユーザがパーソナルコンピュータ３２を介してストリーミングを行う場合、このユーザはストリーミングの配給元、たとえば番組の配信会社（ＩＳＰ３１のひとつ）と契約を交わしクライアントの立場にある。以下、このユーザおよびそのパーソナルコンピュータ３２を「（ストリーミング）クライアント」と称し、番組の配信会社のサーバ２を「ストリーミングサーバ」という。
【００２０】
クライアント３２は、再生して視聴したい番組を、配給会社から供給される情報を参照して選択し、予約等を入れる。このときクライアント３２から、図示のように要求（以下、リクエストメッセージという）がストリーミングサーバ２に送信される。この要求を受けたサーバ２は、当該要求に応じたストリーミングデータ（以下、番組データ）をストリームデータコンテンツ記憶媒体から読み出して、圧縮や暗号化などの必要な処理を施し、かつ、パケットに分割し、予定時刻になったらパケットを順次クライアント３２に向けて送信する。
クライアント３２は、順次送信されてくる番組パケットデータを受信し、内部のバッファに数パケット分蓄積しながら、リアルタイムで再生する。これによりディスプレイで映像を見たり、スピーカーから音楽を聴いたりして番組内容をユーザが楽しむことができる。
【００２１】
以下、このようなインターネットによるストリーミングを例に、本発明の実施の形態を、図を参照しつつ説明する。
【００２２】
［第１の実施の形態］
本実施の形態では、クライアントが配信を要求した番組データの開始または終了時刻を隠蔽するために、この配信を要求した番組データにダミーの番組データを付加する。サーバ側では、このダミーの番組データを付加した番組データは１つの番組データとして取り扱われる。ここで、「ダミーの番組データ」とは、見かけ上は、他のストリーミングの通常の番組データと変わらないが、クライアントが再生したい本来の番組データと区別するという意味で使用する。ダミーの番組データの長さに限定はないが、ダミーを付加した番組データを通常の番組データと区別しにくくするために、ダミーを付加した番組データは、たとえばＴＶのライブ放送の場合、現行のＴＶ地上波放送のように１５分単位の長さにするのが望ましい。
【００２３】
図２に、本発明の実施の形態に係る番組データの受信再生装置、たとえばクライアントのパーソナルコンピュータの構成を示す。
この受信再生装置１は、ストリーミング予定時刻記憶媒体１０と、ダミーの番組データのストリーミング要求（以下、ダミーのリクエスト（メッセージ）ともいう）の発生装置１１と、再生したい番組データのリクエスト発生装置１２と、再生装置（および記憶媒体）１３と、ネットワークインタフェース１４と、時計１５と、ＣＰＵ等の制御部１６とを有している。なお、この受信再生装置１は、基本的にはストリーミングの機能を有しているが、ＶＯＤ（ビデオオンデマンド）の場合、購入の契約を結んでいる場合もありえるのでストリーミング（リアルタイムの再生）後に、購入したビデオコンテンツを保存する機能も備える。このため、記憶媒体が再生装置１３に付属している場合がある。
【００２４】
制御部１６は、図示を省略しているがすべての構成と接続され、全体の制御を行う。制御部１６では、ダミーのリクエスト発生装置１１から出力されるダミーのリクエストと、リクエスト発生装置１２から出力される再生したい番組データのリクエストとを合わせたリクエストメッセージの作成が行われる。このリクエストメッセージは、再生したい番組データにダミーの番組データを付加した見かけ上１つの番組データのリクエストを表している。作成されたリクエストメッセージは、ネットワークインタフェース１４からサーバに向けて出力される。リクエストメッセージを作成するというとき具体的な方法は種々あるが、たとえば、本来の番組の開始または終了の少なくとも一方の時刻を見かけ上ずらす処理を行う。この処理については後述する。
この制御部１６、上記ダミーのリクエスト発生装置１１およびリクエスト発生装置１２が、本発明における「要求発生部」の一実施態様を構成する。
【００２５】
このリクエストメッセージに応じて配信された番組パケットデータをネットワークインタフェース１４が受信すると、制御部１６内、または、制御部１６に制御された再生装置１３内で、この番組パケットデータが、再生したい番組データに属するかダミーの番組データに属するかが判別される。図２においては、この判別機能を再生装置１３自身がもっている場合を想定し、その判別の基礎データとして制御部１６が識別情報Ｓを再生装置１３に供給している。
制御部１６、再生装置１３およびネットワークインタフェース１４が、本発明における「データ受信再生部」の一実施態様を構成する。
【００２６】
ストリーミング予定時刻記憶媒体１０は、配信スケジュールの予約機能をもたせる場合に必要な構成であり、ユーザ３２Ａの操作により記憶内容の書き換えが可能である。なお、時計１５は現在時間を照合するために、この記憶媒体１０に接続されているが制御部１６に内蔵させてもよい。
【００２７】
図３に、本発明の実施の形態に係るストリーミングサーバの構成を示す。
ストリーミングサーバ２は、ストリーミング予定時刻記憶媒体２０と、ストリーミングコンテンツ記憶媒体２１と、ネットワークインタフェース２２と、時計２３と、ＣＰＵ等の制御部２４とを有する。なお、制御部２４は、すべての構成と接続され全体の制御を行う。
【００２８】
ストリーミング予定時刻記憶媒体２０は、公開している番組スケジュール表を格納している。また、ストリーミングコンテンツ記憶媒体２１に、必要に応じて圧縮し暗号化された番組データ内容が格納されている。
クライアントから送られ、ネットワークインタフェース２２に受信されたリクエストメッセージが、たとえば制御部２４により、この番組スケジュール表と照合される。このとき、ストリーミングの予約が、既に行われている予約と競合していないかがチェックされる。また、時計２３から得た現在の時刻を参照し、すでに配信予定が過ぎている予約を破棄するなどの処理も行う。照合結果がストリーミングコンテンツ記憶媒体２１に出力されて、そこで配信すべき番組コンテンツが選択され、制御部２４により管理されながら、予定時刻になったら、この番組コンテンツが番組パケットデータとしてネットワークインタフェース２２からクライアントに向けて送信される。
【００２９】
図４に、番組の開始時刻、終了時間およびその差（番組時間）の定義を示す。
現在の時刻をｔとし、この時刻ｔが実時間軸上で変化しているとする。この実時間軸上の番組の開始時刻を（ｘ）、番組の終了時刻を（ｘ＋Δｔ）とすると、その差（Δｔ）が映像や音楽の番組の放送時間と等価な時間（番組時間）となる。なお、パケットが一部届かない、あるいは、遅れた場合は間引かれて（映像の場合、解像度等を落として）放映が続行されるのが普通なので、この番組時間は殆ど変化しないとする。ただし、開始時刻や終了時刻は、サーバ側の番組スケジュール表の時刻であり、サーバ側の実時刻とは異なる。ここで現在の時刻ｔとは、クライアント側の実時刻であるとし、サーバ側ではこれに送受信時間遅れ（タイムラグ）を加味したタイムスタンプなどを利用して時間管理しているものとする。
【００３０】
図５に、本実施の形態のダミーの番組データの追加による、見かけ上の開始時刻および終了時刻の変化を実時間軸上で示している。
本実施の形態では、本来の開始時刻（ｘ）の前に見かけ上の開始時刻（ｘ−ｒ０）を設定する場合、本来の終了時刻（ｘ＋Δｔ）の後に見かけ上の終了時刻（ｘ＋Δｔ＋ｒ１）を設定する場合、その両方を設定する場合の３通りの実施態様がある。ここで（ｒ０）と（ｒ１）は、０より大きな値である。
【００３１】
つぎに、開始時刻と終了時刻の両方をずらす場合を例として、図６に沿ってダミーの番組データを付加するようなストリーミングのフローを説明する。図７は、このストリーミングのリクエストまたはデータの流れを示す図である。
ステップＳＴ１において、ユーザの操作にもとづいて番組が選択されると、番組スケジュール表に規定された当該番組の開始時刻（ｘ）と終了時刻（ｘ＋Δｔ）が一意に決まる。この番組の予約情報は、ストリーミング予定時刻記憶媒体１０に格納される。ステップＳＴ２では、たとえば制御部１６が、内部に保持した乱数表などを用いて、正の数値ｒ０とｒ１を求める。
【００３２】
ステップＳＴ３において見かけ上の開始時刻（ｘ−ｒ０）が設定され、ステップＳＴ４において見かけ上の終了時刻（ｘ＋Δｔ＋ｒ１）が設定される。この見かけ上の時刻の情報は、実質的にダミーの番組データの長さを決めるものであることから、制御部１６等に保存される。この見かけ上の時刻の情報は、本発明における「識別情報」の一実施態様を構成する。
以上によりダミーの番組データが見かけ上付加されたリクエストメッセージの作成が終了し、このリクエストメッセージがサーバに向けて送信される（ＳＴ５）。
【００３３】
図７に示すように、リクエストメッセージが示す予約情報を、サーバがデータベース（ストリーミング予定時刻記憶媒体２０）に保存し、番組配信の予定時刻に合わせてネットワークインタフェース２２を介して番組パケットデータとして配信を開始する。
【００３４】
クライアントの受信再生装置が、この番組パケットデータを受信すると（ＳＴ６）、つぎのステップＳＴ７〜ＳＴ９でデータ判別と再生等が行われる。詳細には、制御部１６が、保存しておいた見かけ上の時刻情報（識別情報Ｓ）を再生装置１３に出力すると、再生装置１３が、送られてくる番組パケットデータが本来再生したい番組データに属するか、前記見かけ上の時間シフトにより生じたダミーの番組データに属するかを判別し、本来再生したいものだけを再生する。再生しないデータは廃棄される。最初に送られてきたパケットデータの幾つかが（ｘ−ｒ０≦ｔ＜ｘ）と判断されるとダミーであるとして廃棄される（ＳＴ７）。（ｘ≦ｔ≦ｘ＋Δｔ）を満たすパケットデータは再生（および保存）されユーザの視聴に供せられる（ＳＴ８）。本来の番組終了後のパケットデータは（ｘ＋Δｔ＜ｔ≦ｘ＋Δｔ＋ｒ１）であるとして廃棄され（ＳＴ９）、１つの番組のストリーミングが終了する。
【００３５】
第１の実施の形態では、番組データの開始時刻と終了時刻の少なくとも一方が隠蔽されることから、ユーザの趣味趣向が解析できない、あるいは、解析できたとしても曖昧な情報しか得られなくなる。
【００３６】
なお、ＶＯＤ（ビデオオンデマンド）のように要求に応じてその都度ストリーミングを行うような場合、番組データがたとえ暗号化されて送られたとしても、多くの暗号化アルゴリズムが暗号前のデータサイズと、暗号化後のデータサイズが一致するため、ストリーミングしたデータサイズから内容を推測される危険性がある。そこで、本実施の形態のクライアント側で廃棄されるダミーの番組データの送信要求を出す上記効果は、ＶＯＤ型のストリーミングの場合にも得ることができる。ただし、ＶＯＤ型の場合、見かけ上の開始時刻を設定すると開始時刻（つまりは、終了時刻）が遅くなってしまうので、図６に示すステップＳＴ２では、ｒ０＝０と設定することが望ましい。
【００３７】
［第２の実施の形態］
第２の実施の形態では、ダミーの番組データのみからなる不要なストリーミングを故意に、かつ周期的に発生させ、ストリーミングの周期性を隠蔽する。
【００３８】
図８に、このダミーのストリーミングの発生を実時間軸上で示す。ここでは、既に予約により設定されたストリーミングの開始時刻（ｙ＋Δｔ）があるときに、それより前に、今回新たにストリーミングの開始時刻（ｙ）を設定する場合を例として説明する。このようにするのは、この両者の開始時刻の差（Δｔ）を不必要に多くして全体的に目立たなくする手法をとるためである。なお、この周期を変えることによっても規則性の隠蔽あるいは希釈が可能である。
ここでは、この開始時刻の差（Δｔ）を時間軸上の前（時間を遡る）側と後（時間が経過する）側にそれぞれ繰り返す場合を説明するが、その一方のみ行うこともできる。前に設定された不要なダミーストリーミングの開始時刻は（ｙ−Δｔ）となり、後に設定された不要なダミーストリーミングの開始時刻は（ｙ＋２Δｔ）となる。
【００３９】
つぎに、図９に沿ってダミーストリーミングのフローを説明する。このストリーミングのリクエストまたはデータの大まかな流れは、図７と同じである。なお、以下で、特に示さない以外は制御部１６により実行される。
ステップＳＴ１０において、ユーザの操作にもとづいて番組が選択されると、番組スケジュール表に規定された当該番組の開始時刻（ｙ）が一意に決まる。この番組の予約情報は、ストリーミング予定時刻記憶媒体１０に格納される。ステップＳＴ１１では、ストリーミング予定時刻記憶媒体１０の記憶内容を参照して、すでに実行ずみのストリーミングの開始時刻との差（Δｔ）を求める。ここでは、０＜Δｔとする。
【００４０】
つぎに自然数をとる繰り返しパラメータｎを初期値「１」に設定し（ＳＴ１２）、つぎのステップＳＴ１３で、現在時刻より後にダミーのストリーミングの開始時刻が入るか否かが調べられる。ここではｎ＝１なので（ｔ＜ｙ−Δｔ）が成立すれば、つぎのステップＳＴ１４において、この（ｙ−Δｔ）を開始時刻とするダミーのストリーミングが設定され、ｎがインクリメントされる（ＳＴ１５）。これらステップＳＴ１３〜ＳＴ１５の処理は、ステップＳＴ１３の判断が「Ｎｏ」となって、これ以上前側に設定ができないと判断されるまで繰り返される。その後は、フローがステップＳＴ１６に移行し、後側の設定が実行される。
【００４１】
ここで、あらかじめ自然数をとる後方側の繰り返し制限パラメータｍが規定されている。この値は任意に選択してもよいし、乱数表などを用いて決定してもよい。
【００４２】
繰り返しパラメータｎを初期値「２」に設定し（ＳＴ１６）、つぎのステップＳＴ１７で、最初に予約された開始時刻（ｙ＋Δｔ）より後でパラメータｍにより規定される範囲内にダミーのストリーミングの開始時刻が入るか否かが調べられる。ここではｎ＝２なので（２＜（ｍ＋２））が成立すれば、つぎのステップＳＴ１８において、この（ｙ＋２Δｔ）を開始時刻とするダミーのストリーミングが設定され、ｎがインクリメントされる（ＳＴ１９）。これらステップＳＴ１７〜ＳＴ１９の処理は、ステップＳＴ１７の判断が「Ｎｏ」となって、これ以上後側に設定ができないと判断されるまで繰り返される。
【００４３】
その後は、フローがステップＳＴ２０に移行し、以後、リクエストの送信（ＳＴ２０）、データ受信（ＳＴ２１）およびパケットデータの廃棄、あるいは、再生（および保存）が実行され（ＳＴ２２）、ストリーミングが終了する。
【００４４】
つぎに、あらかじめストリーミングの予約がない場合であるが、この場合は、ステップＳＴ１１のΔｔを、乱数表などを用いて求める。また、ステップＳＴ１６ではｎの初期値を「１」とすること、つぎのステップＳＴ１７ではｎ＜（ｍ＋１）の判断を行うことが、図９に示す場合と異なる。
【００４５】
上記説明では、ダミーのストリーミングの開始時間をΔｔ間隔として周期性をもたせたが、前回のストリーミングの終了時刻からつぎのストリーミングの開始時刻までの間隔、つまり何もデータが流れていない期間を一定としてもよい。また、Δｔの代わりに乱数表を用いて求めた値を使用し、毎回新たにストリーミングの開始時間の間隔を決定してもよい。この場合、周期性が崩れることで個人情報を隠蔽できる。
【００４６】
第２の実施の形態では、周期性が隠蔽または希釈されるためユーザの趣味趣向が解析されにくくなり、解析されたとしても曖昧な情報しかえられなくなる。なお、この第２の実施の形態と第１の実施の形態の両方の方法を適用すると、より一層解析が困難となるため、望ましい。
【００４７】
［第３の実施の形態］
第３の実施の形態では、サーバ（配信装置２）側での個人情報の隠蔽方法を、図３を用いて説明する。
ここでは、たとえば制御部２４が、送られてきたリクエストが示すクライアントが再生したい番組データを選択し、その番組データの前および後の少なくとも一方、望ましくは番組データの後にダミーデータを付加する。ダミーデータは再生の可能、不可能は問わない。このダミーデータを付加した番組データは、見かけ上１つの番組データとして、要求に応じた時刻にクライアントに送信される。ダミーデータは見たい番組の、望ましくは最後に付加されているので、再生不能の場合は視聴したい番組の終了時点で再生が停止するし、再生可能の場合は、視聴したい番組が終了すると通常、クライアントが再生を停止させる。停止させない場合でも、ダミーの番組は当該クライアントにとっては余り意味のない視聴価値は小さい番組である。
【００４８】
なお、このデータの付加情報は暗号化してクライアントに送り、クライアントが解読して、上記した他の実施の形態のように不要なデータを廃棄してもよい。また、第１から第３の実施の形態を組み合わせると、より一層個人情報の隠蔽効果が得られる。
【００４９】
以上は、クライアント側でダミーの番組データの送信要求の作成と、そのパケットデータの再生判断を行ったが、すべての主導権をサーバ側に持たせ、クライアントではダミーデータを意識しないでも、第３の実施の形態のように再生を自動的に停止させることができる。あるいは、クライアントにとって余り価値のない付加的なデータが添付されるが、ストリーミングではクライアントのハードディスクなどの記憶媒体を殆ど番組データが占有しない、これが実用上問題になることはない。
【００５０】
【発明の効果】
本発明によれば、サーバから送られる番組データには、クライアントが再生して視聴したい番組データと、そうでないダミーの番組データ（またはダミーデータ）とが混在して送られてくる。見かけ上はすべて番組データであることに変わりなく、その結果、悪意ある第３者が通信回線途中で、この番組データをキャッシュしても、クライアントの趣味趣向やその規則性が解析できないか、できたとしても、非常に曖昧な情報しか得られない。
とくにダミーの番組データ（またはダミーデータ）が、再生したい番組データの前後の一方または双方に付加して送られる場合は、クライアントが視聴したい番組の開始と終了の時刻の少なくとも一方が隠蔽されたものとなる。また、ダミーの番組データが、再生したい番組データを基準に周期的に作られる場合は、クライアントの番組視聴に関する周期性が隠蔽または希釈されたものとなる。とくに、この２つを組み合わせると、クライアントの趣味趣向の解析はきわめて困難なものとなる。
【図面の簡単な説明】
【図１】本実施の形態で使用される通信回線例としてインターネットを模式的に示す図である。
【図２】本発明の実施の形態に係る番組データの受信再生装置の構成を示すブロック図である。
【図３】本発明の実施の形態に係るストリーミングサーバの構成を示すブロック図である。
【図４】番組の開始時刻、終了時間およびその差（番組時間）の定義を示す図である。
【図５】第１の実施の形態のダミーの番組データの追加による、見かけ上の開始時刻および終了時刻の変化を実時間軸上で示す図である。
【図６】第１の実施の形態に係るストリーミングの処理のフローチャートである。
【図７】ストリーミングのリクエストまたはデータの流れを示す図である。
【図８】第２の実施の形態のダミーのストリーミングの発生を実時間軸上で示す図である。
【図９】第１の実施の形態に係るストリーミングの処理のフローチャートである。
【符号の説明】
１…受信再生装置、２…配信装置、１１，１２，１６…要求生成部、１３，１４，１６…受信再生部、３２…クライアント、Ｓ…識別情報
【図１】
2005005986.tif 000003
【図２】
2005005986.tif 000004
【図３】
2005005986.tif 000005
【図４】
2005005986.tif 000006
【図５】
2005005986.tif 000007
【図６】
2005005986.tif 000008
【図７】
2005005986.tif 000009
【図８】
2005005986.tif 000010
【図９】
2005005986.tif 000011