(57)【要約】      （修正有）【課題】ＷｅｂＳｏｃｋｅｔプロトコルを用いてフラグメント化されたデータを配信しているときに、他のデータを割り込んで送信可能なプッシュ型配信サーバを提供する。【解決手段】プッシュ配信サーバ４のフラグメント生成手段１４は、コンテンツデータにヘッダ情報及びトレイラ情報を付与してカプセル化データを生成し、カプセル化データを断片データに分割し、フラグメント化フレームを生成する。緊急データフラグメント生成手段１６は、緊急データを入力すると、フラグメント生成手段１４と同様にカプセル化データを生成してフラグメント化フレームを生成する。フラグメント多重化手段１８は、コンテンツデータのフラグメント化フレームを受信端末へ送信しているときに、緊急データを割り込んで送信する場合、中断フレームを受信端末へ送信する。フラグメント多重化手段１８は、緊急データの送信が終了すると、再開フレームを受信端末へ送信する。【選択図】図４
2014235453.tif 000002
【特許請求の範囲】
【請求項１】
ＷｅｂＳｏｃｋｅｔプロトコルを用いて所定のデータを受信端末へ送信するプッシュ配信サーバにおいて、
所定のデータを入力し、前記データに対し、前記データの識別子、及び前記データの開始位置を含むか否かを示す開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記データの終了位置を含むか否かを示す終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された最後の断片データを送信するものであるか否かを示す第１の制御情報、及び前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された途中の断片データを継続して送信するものであるか否かを示す第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成するフラグメント生成手段と、
前記フラグメント生成手段により生成されたフラグメント化フレームを前記受信端末へ送信するフラグメント送信手段と、を備え、
前記フラグメント送信手段は、
前記データのフラグメント化フレームの送信を中断し、他のデータのフラグメント化フレームを割り込んで送信する場合、
前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、
前記中断したデータのフラグメント化フレームの送信を再開する場合、
前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信する、ことを特徴とするプッシュ配信サーバ。
【請求項２】
請求項１に記載のプッシュ配信サーバにおいて、
前記フラグメント送信手段に代わる新たなフラグメント送信手段は、
前記データのフラグメント化フレームの送信を中断し、他のデータのフラグメント化フレームを割り込んで送信する場合、
前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、前記他のデータのフラグメント化フレームを前記受信端末へ送信し、
前記中断したデータのフラグメント化フレームの送信を再開する場合、
前記他のデータにおける全てのフラグメント化フレームを前記受信端末へ送信した後、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信し、前記中断したデータにおける残りのフラグメント化フレームを前記受信端末へ送信する、ことを特徴とするプッシュ配信サーバ。
【請求項３】
請求項１または２に記載のプッシュ配信サーバにおいて、
前記フラグメント生成手段の代わりに、第１のフラグメント生成手段及び第２のフラグメント生成手段を備え、さらに、第１のフラグメントバッファ及び第２のフラグメントバッファを備え、
前記第１のフラグメント生成手段は、
前記データを入力し、前記データに対し、前記開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記第１の制御情報及び前記第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成し、前記フラグメント化フレームを前記第１のフラグメントバッファに格納し、
前記第２のフラグメント生成手段は、
前記他のデータを入力し、前記他のデータに対し、前記開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記第１の制御情報及び前記第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成し、前記フラグメント化フレームを前記第２のフラグメントバッファに格納し、
前記フラグメント送信手段は、
前記第１のフラグメントバッファに前記データのフラグメント化フレームが格納されると、前記第１のフラグメントバッファから前記データのフラグメント化フレームを読み出して前記受信端末へ送信し、
前記データのフラグメント化フレームの送信を中断し、前記他のデータのフラグメント化フレームを割り込んで送信する場合、
前記第２のフラグメントバッファに前記他のデータのフラグメント化フレームが格納されると、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、前記第２のフラグメントバッファから前記他のデータのフラグメント化フレームを読み出して前記受信端末へ送信し、
前記中断したデータのフラグメント化フレームの送信を再開する場合、
前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信し、前記第１のフラグメントバッファから前記データにおける残りのフラグメント化フレームを読み出して前記受信端末へ送信する、ことを特徴とするプッシュ配信サーバ。
【請求項４】
請求項１から３までのいずれか一項に記載のプッシュ配信サーバにおいて、
前記フラグメント送信手段が送信する中断フレームのヘッダには、前記カプセル化データから分割された最後の断片データを送信するものであることを示す第１の制御情報が含まれる、ことを特徴とするプッシュ配信サーバ。
【請求項５】
所定のデータに対し、前記データの識別子、及び前記データの開始位置を含むか否かを示す開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記データの終了位置を含むか否かを示す終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された最後の断片データを送信するものであるか否かを示す第１の制御情報、及び前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された途中の断片データを継続して送信するものであるか否かを示す第２の制御情報を生成し、ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成して送信するプッシュ配信サーバから、前記ＷｅｂＳｏｃｋｅｔプロトコルを用いて前記フラグメント化フレームを受信する受信端末において、
前記受信したフラグメント化フレーム毎に、前記フラグメント化フレームのヘッダから前記第１及び第２の制御情報を抽出すると共に、前記フラグメント化フレームのペイロードから前記カプセル化データを構成する断片データを抽出し、前記第１及び第２の制御情報の組み合わせと、前記ヘッダ情報及びトレイラ情報の存在との関係が格納されたテーブルを参照して、前記抽出した断片データから、前記識別子を含むヘッダ情報及びトレイラ情報を抽出し、前記ヘッダ情報及びトレイラ情報のいずれかまたは両方を抽出できない場合、前記抽出できなかったヘッダ情報に対し所定の情報を設定すると共に、前記抽出できなかったトレイラ情報に対し所定の情報を設定し、前記抽出または設定したヘッダ情報及びトレイラ情報に基づいて、前記抽出した断片データから前記データの断片を抽出し、前記データを復元するフラグメント復元手段と、
前記フラグメント復元手段により抽出された前記データの断片を、前記フラグメント復元手段により抽出または設定された前記ヘッダ情報の識別子に対応付けて記憶する記憶手段と、
前記記憶手段から復元された前記データを入力し、前記データをデコードするデコーダと、
前記デコーダによりデコードされた前記データを、当該受信端末のユーザへ提示する提示部と、を備え、
前記フラグメント復元手段は、
前記データのフラグメント化フレームを受信しているときに、前記プッシュ配信サーバから、前記データのフラグメント化フレームの送信を中断して他のデータのフラグメント化フレームを割り込んで送信することを示すフレームであって、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダが付与され、前記終了位置を含まないことを示す前記終了／継続識別フラグがペイロードに格納された中断フレームを受信した場合、
前記中断フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記テーブルを参照して、前記中断フレームのペイロードから前記トレイラ情報の前記終了／継続識別フラグを抽出し、
前記プッシュ配信サーバから、前記中断したデータのフラグメント化フレームの送信を再開することを示すフレームであって、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダが付与され、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグがペイロードに格納された再開フレームを受信した場合、
前記再開フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記テーブルを参照して、前記再開フレームのペイロードから前記ヘッダ情報に含まれる前記中断したデータの識別子及び前記開始／継続識別フラグを抽出する、ことを特徴とする受信端末。
【請求項６】
請求項５に記載の受信端末において、
前記フラグメント送信手段が送信する中断フレームのヘッダには、前記カプセル化データから分割された最後の断片データを送信するものであることを示す第１の制御情報が含まれており、
前記フラグメント復元手段に代わる新たなフラグメント復元手段は、
前記受信したフラグメント化フレームを前記記憶手段に格納し、前記受信したフラグメント化フレームのヘッダまたは前記受信した中断フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記第１の制御情報が、前記カプセル化データから分割された最後の断片データを送信するものであることを示している場合、前記記憶手段に格納したフラグメント化フレームを読み出してそのペイロードから前記カプセル化データを構成する断片データを抽出し、前記抽出した断片データから前記データの断片を抽出する、ことを特徴とする受信端末。
【請求項７】
コンピュータを、請求項５または６に記載の受信端末として機能させるための受信プログラム。
【請求項８】
請求項１のプッシュ配信サーバと、請求項５の受信端末とを備えて構成されるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュ配信サーバからＷｅｂＳｏｃｋｅｔプロトコルを用いてフラグメント化されたデータを配信しているときに、他のデータを割り込んで送信するプッシュ配信サーバ、受信端末、受信プログラム及びシステムに関する。
【背景技術】
【０００２】
近年、インターネットでは、配信サーバからユーザの受信端末へ自動的に情報を送りつけるプッシュ型の情報配信サービスの実施が期待されている。例えば、テレビ放送番組の進行に合わせた関連情報、個々のユーザニーズに応じた天気の最新情報、交通の最新情報等のような刻一刻と変化する情報をプッシュ配信する。これにより、ユーザは、特別な更新作業を行うことなく、最新の情報を取得することができる。
【０００３】
従来は、このようなプッシュ型の情報配信サービスを実施する手法として、主にＨＴＴＰプロトコルを利用して、受信端末が一定時間毎に配信サーバに対して自動的に更新情報を問い合わせ、更新情報が存在する場合は、当該情報を受信する擬似的なプッシュ配信が主流であった。
【０００４】
しかし、擬似的なプッシュ配信では、配信サーバと受信端末との間でデータのやり取りが頻繁に発生するほか、ＨＴＴＰコネクションを長時間占有することにより、同一配信サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるという問題があった。
【０００５】
この問題を解決する技術として、ＷｅｂＳｏｃｋｅｔプロトコルの規格策定作業が、インターネットの標準化団体であるＷ３ＣとＩＥＴＦによって進められている（非特許文献１）。ＷｅｂＳｏｃｋｅｔプロトコルは、配信サーバと受信端末との間で一旦コネクションを確立した後は、必要な通信は全てそのコネクション上の専用プロトコルを用いて行われる。ＨＴＴＰコネクションと比較すると、無駄な通信を抑えることができ、一つのコネクションで全てのデータ送受信を行うことにより同一配信サーバに接続する他のアプリケーションへの影響が少なくなる等のメリットがある。
【０００６】
図１２は、ＷｅｂＳｏｃｋｅｔプロトコルに従って伝送されるフレームの構成を示す図である。図１２では、フレームの構成を３２ビット単位で表している。ＷｅｂＳｏｃｋｅｔプロトコルに従って伝送されるフレームは、ヘッダ及びペイロードから構成され、データは、ペイロードに格納され、このフレームの並びにより伝送される。未知のサイズのデータを送信する場合、事前にデータの全てをバッファすることなく送信できるようにするため、また、サイズの大きいデータが出力ネットワークインタフェースを占有することがないようにするため、ＷｅｂＳｏｃｋｅｔプロトコルには、送信すべきデータ（メッセージ）を断片化（フラグメント化）して伝送する機能がサポートされている。
【０００７】
フレームのヘッダには、１ビット長のＦＩＮ及び４ビット長のｏｐｃｏｄｅの制御情報が含まれており、フラグメント化されたデータを伝送するために、これらの制御情報が用いられる。ＦＩＮは、送信すべきデータの中で最後のフラグメントのフレームであることを示す情報であり、最初のフラグメントのフレームが最後のフラグメントのフレームであってもよい。ｏｐｃｏｄｅは、ペイロードに格納されるデータの解釈方法を定義する情報であると共に、送信すべきデータの中で途中（継続）のフラグメントのフレームであることを示す情報である。具体的には、０のときは継続フレームを示し、２のときはバイナリフレームを示し、その他の値については図１２に示すとおりである。
【０００８】
図１３は、フラグメント化されたデータを送信する場合のＦＩＮ及びｏｐｃｏｄｅを説明する図である。フラグメント化されたデータを送信する場合、ＦＩＮビットがクリア（０）され、ｏｐｃｏｄｅが０以外（図１３の例では２）に設定された１個のフレーム（最初のフレーム）から始まり、ＦＩＮビットがクリアされ、ｏｐｃｏｄｅが０に設定された０個以上のフレーム（次のフレーム）が後続し、ＦＩＮビットがセットされ（１に設定され）、ｏｐｃｏｄｅが０に設定された１個のフレーム（最後のフレーム）で終了する。送信すべきデータが複数のデータにフラグメント化された場合、この送信すべきデータは、概念的には、フラグメント化されたデータが格納されたそれぞれのペイロードを連結して１つのペイロードを構成したときの、当該ペイロードに格納された単独の大きなデータと等価である。
【０００９】
ところで、一般的なデータを配信しているときに、他のデータを送信したい場合があり得る。例えば、ストリームデータを再生表示端末へ配信しているときに、別のストリームデータの配信を行う場合に、再生表示端末での操作及び接続の切断と再接続を行う必要がないストリーム配信システムが開示されている（特許文献１）。具体的には、再生表示端末、プロキシサーバ、第１の配信サーバ及び第２の配信サーバを備えて構成されるストリーム配信システムにおいて、プロキシサーバは、第１の配信サーバから再生表示端末へストリームデータを中継しているときに、第２の配信サーバから割り込み要求があると、第１のサーバへ一時停止の要求を送信し、第２の配信サーバから再生表示端末へ別のストリームデータを中継する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００８−１７７６５７号公報
【非特許文献】
【００１１】
【非特許文献１】RFC 6455,“The WebSocket Protocol”、［online］、２０１１年１２月、［平成２５年５月１日検索］、インターネット＜ＵＲＬ：http://tools.ietf.org/html/rfc6455＞
【発明の概要】
【発明が解決しようとする課題】
【００１２】
前述のプッシュ型の情報配信サービスにおいて、一般的なデータの配信に加え、即座にユーザに伝えるべき緊急性の高いデータが存在する。このような緊急性の高いデータは、即時性を高めるため、配信中のデータに割り込んで送られることが望ましい。
【００１３】
しかしながら、ＷｅｂＳｏｃｋｅｔプロトコルを用いた場合には、配信サーバと受信端末との間で確立された一つのセッションにおいて、一つの送信すべきデータに属するフラグメント化されたデータを送信する複数のフレームの間に、別のデータのフレームが挿入されることは禁止されている。したがって、一つの送信すべきデータに属するフラグメント化されたデータが格納される全てのフレームの送信が終了するまで、別のデータを送信することができない。このため、一般的なデータを配信しているときに、緊急性の高いデータを即座にユーザに伝えることは困難であった。これは、一般的なデータを配信しているときに、そのデータに割り込んで他のデータを配信する場合も同様である。
【００１４】
前述の特許文献１のストリーム配信システムによる技術を用いることにより、緊急性の高いデータまたは他のデータを、配信中のデータに割り込んで送信することは可能である。しかし、この技術は、ＷｅｂＳｏｃｋｅｔプロトコルを用いたものではないから、ＷｅｂＳｏｃｋｅｔプロトコルを用いたデータ配信にそのまま適用することができない。
【００１５】
そこで、本発明はかかる課題に鑑みてなされたものであり、その目的は、プッシュ配信サーバからＷｅｂＳｏｃｋｅｔプロトコルを用いてフラグメント化されたデータを配信しているときに、他のデータを割り込んで送信することを可能とするプッシュ配信サーバ、受信端末、受信プログラム及びシステムを提供することにある。
【課題を解決するための手段】
【００１６】
前記目的を達成するために、請求項１のプッシュ配信サーバは、ＷｅｂＳｏｃｋｅｔプロトコルを用いて所定のデータを受信端末へ送信するプッシュ配信サーバにおいて、所定のデータを入力し、前記データに対し、前記データの識別子、及び前記データの開始位置を含むか否かを示す開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記データの終了位置を含むか否かを示す終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された最後の断片データを送信するものであるか否かを示す第１の制御情報、及び前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された途中の断片データを継続して送信するものであるか否かを示す第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成するフラグメント生成手段と、前記フラグメント生成手段により生成されたフラグメント化フレームを前記受信端末へ送信するフラグメント送信手段と、を備え、前記フラグメント送信手段が、前記データのフラグメント化フレームの送信を中断し、他のデータのフラグメント化フレームを割り込んで送信する場合、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、前記中断したデータのフラグメント化フレームの送信を再開する場合、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信する、ことを特徴とする。
【００１７】
また、請求項２のプッシュ配信サーバは、請求項１に記載のプッシュ配信サーバにおいて、前記フラグメント送信手段に代わる新たなフラグメント送信手段が、前記データのフラグメント化フレームの送信を中断し、他のデータのフラグメント化フレームを割り込んで送信する場合、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、前記他のデータのフラグメント化フレームを前記受信端末へ送信し、前記中断したデータのフラグメント化フレームの送信を再開する場合、前記他のデータにおける全てのフラグメント化フレームを前記受信端末へ送信した後、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信し、前記中断したデータにおける残りのフラグメント化フレームを前記受信端末へ送信する、ことを特徴とする。
【００１８】
また、請求項３のプッシュ配信サーバは、請求項１または２に記載のプッシュ配信サーバにおいて、前記フラグメント生成手段の代わりに、第１のフラグメント生成手段及び第２のフラグメント生成手段を備え、さらに、第１のフラグメントバッファ及び第２のフラグメントバッファを備え、前記第１のフラグメント生成手段が、前記データを入力し、前記データに対し、前記開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記第１の制御情報及び前記第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成し、前記フラグメント化フレームを前記第１のフラグメントバッファに格納し、前記第２のフラグメント生成手段が、前記他のデータを入力し、前記他のデータに対し、前記開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記第１の制御情報及び前記第２の制御情報を生成し、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成し、前記フラグメント化フレームを前記第２のフラグメントバッファに格納し、前記フラグメント送信手段が、前記第１のフラグメントバッファに前記データのフラグメント化フレームが格納されると、前記第１のフラグメントバッファから前記データのフラグメント化フレームを読み出して前記受信端末へ送信し、前記データのフラグメント化フレームの送信を中断し、前記他のデータのフラグメント化フレームを割り込んで送信する場合、前記第２のフラグメントバッファに前記他のデータのフラグメント化フレームが格納されると、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記終了位置を含まないことを示す前記終了／継続識別フラグをペイロードに格納した中断フレームを生成し、前記中断フレームを前記受信端末へ送信し、前記第２のフラグメントバッファから前記他のデータのフラグメント化フレームを読み出して前記受信端末へ送信し、前記中断したデータのフラグメント化フレームの送信を再開する場合、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダを付与して、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグをペイロードに格納した再開フレームを生成し、前記再開フレームを前記受信端末へ送信し、前記第１のフラグメントバッファから前記データにおける残りのフラグメント化フレームを読み出して前記受信端末へ送信する、ことを特徴とする。
【００１９】
また、請求項４のプッシュ配信サーバは、請求項１から３までのいずれか一項に記載のプッシュ配信サーバにおいて、前記フラグメント送信手段が送信する中断フレームのヘッダには、前記カプセル化データから分割された最後の断片データを送信するものであることを示す第１の制御情報が含まれる、ことを特徴とする。
【００２０】
さらに、請求項５の受信端末は、所定のデータに対し、前記データの識別子、及び前記データの開始位置を含むか否かを示す開始／継続識別フラグを含むヘッダ情報を付与すると共に、前記データの終了位置を含むか否かを示す終了／継続識別フラグを含むトレイラ情報を付与してカプセル化データを生成し、前記カプセル化データを所定長毎の断片データに分割し、前記断片データのそれぞれについて、前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された最後の断片データを送信するものであるか否かを示す第１の制御情報、及び前記断片データを送信するフラグメント化フレームが、前記カプセル化データから分割された途中の断片データを継続して送信するものであるか否かを示す第２の制御情報を生成し、ＷｅｂＳｏｃｋｅｔプロトコルに用いる前記第１及び第２の制御情報を含むへッダを付与し、前記断片データをペイロードに格納してフラグメント化フレームを生成して送信するプッシュ配信サーバから、前記ＷｅｂＳｏｃｋｅｔプロトコルを用いて前記フラグメント化フレームを受信する受信端末において、前記受信したフラグメント化フレーム毎に、前記フラグメント化フレームのヘッダから前記第１及び第２の制御情報を抽出すると共に、前記フラグメント化フレームのペイロードから前記カプセル化データを構成する断片データを抽出し、前記第１及び第２の制御情報の組み合わせと、前記ヘッダ情報及びトレイラ情報の存在との関係が格納されたテーブルを参照して、前記抽出した断片データから、前記識別子を含むヘッダ情報及びトレイラ情報を抽出し、前記ヘッダ情報及びトレイラ情報のいずれかまたは両方を抽出できない場合、前記抽出できなかったヘッダ情報に対し所定の情報を設定すると共に、前記抽出できなかったトレイラ情報に対し所定の情報を設定し、前記抽出または設定したヘッダ情報及びトレイラ情報に基づいて、前記抽出した断片データから前記データの断片を抽出し、前記データを復元するフラグメント復元手段と、前記フラグメント復元手段により抽出された前記データの断片を、前記フラグメント復元手段により抽出または設定された前記ヘッダ情報の識別子に対応付けて記憶する記憶手段と、前記記憶手段から復元された前記データを入力し、前記データをデコードするデコーダと、前記デコーダによりデコードされた前記データを、当該受信端末のユーザへ提示する提示部と、を備え、前記フラグメント復元手段が、前記データのフラグメント化フレームを受信しているときに、前記プッシュ配信サーバから、前記データのフラグメント化フレームの送信を中断して他のデータのフラグメント化フレームを割り込んで送信することを示すフレームであって、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダが付与され、前記終了位置を含まないことを示す前記終了／継続識別フラグがペイロードに格納された中断フレームを受信した場合、前記中断フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記テーブルを参照して、前記中断フレームのペイロードから前記トレイラ情報の前記終了／継続識別フラグを抽出し、前記プッシュ配信サーバから、前記中断したデータのフラグメント化フレームの送信を再開することを示すフレームであって、前記ＷｅｂＳｏｃｋｅｔプロトコルに用いるヘッダが付与され、前記中断したデータの識別子、及び前記開始位置を含まないことを示す前記開始／継続識別フラグがペイロードに格納された再開フレームを受信した場合、前記再開フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記テーブルを参照して、前記再開フレームのペイロードから前記ヘッダ情報に含まれる前記中断したデータの識別子及び前記開始／継続識別フラグを抽出する、ことを特徴とする。
【００２１】
また、請求項６の受信端末は、請求項５に記載の受信端末において、前記フラグメント送信手段が送信する中断フレームのヘッダには、前記カプセル化データから分割された最後の断片データを送信するものであることを示す第１の制御情報が含まれており、前記フラグメント復元手段に代わる新たなフラグメント復元手段が、前記受信したフラグメント化フレームを前記記憶手段に格納し、前記受信したフラグメント化フレームのヘッダまたは前記受信した中断フレームのヘッダから前記第１及び第２の制御情報を抽出し、前記第１の制御情報が、前記カプセル化データから分割された最後の断片データを送信するものであることを示している場合、前記記憶手段に格納したフラグメント化フレームを読み出してそのペイロードから前記カプセル化データを構成する断片データを抽出し、前記抽出した断片データから前記データの断片を抽出する、ことを特徴とする。
【００２２】
さらに、請求項７の受信プログラムは、コンピュータを、請求項５または６に記載の受信端末として機能させることを特徴とする。
【００２３】
さらに、請求項８のシステムは、請求項１のプッシュ配信サーバと、請求項５の受信端末とを備えて構成されることを特徴とする。
【発明の効果】
【００２４】
以上のように、本発明によれば、プッシュ配信サーバからＷｅｂＳｏｃｋｅｔプロトコルを用いてフラグメント化されたデータを配信しているときに、フラグメント化されたデータが格納される全てのフレームの送信が終了するのを待つことなく、他のデータを割り込んで送信することができる。これにより、ＷｅｂＳｏｃｋｅｔプロトコルを用いたデータ配信において、例えば、緊急性の高いデータを即座にユーザに伝えることが可能となり、また、異なるデータを並列に送信することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態によるコンテンツ配信システムの全体構成の概略を説明する図である。
【図２】コンテンツ配信システムにて用いるデータ及びフレームの構成を示す図である。
【図３】フレームのヘッダに格納されたＦＩＮ及びｏｐｃｏｄｅの組み合わせと、カプセル化データのヘッダ情報及びトレイラ情報の存在との関係を示す図である。
【図４】本発明の実施形態によるプッシュ配信サーバの構成を示すブロック図である。
【図５】プッシュ配信サーバに備えたフラグメント多重化手段の処理を示すフローチャートである。
【図６】コンテンツデータ及び緊急データの送受信シーケンスを説明する図である。
【図７】本発明の実施形態による受信端末の構成を示すブロック図である。
【図８】受信端末の処理を示すフローチャートである。
【図９】Ｔａｇ、ｈｃｏｄｅ及びｔｃｏｄｅの抽出／設定処理（ステップＳ８０３）を示すフローチャートである。
【図１０】コンテンツデータの断片の抽出／格納処理（ステップＳ８０４）を示すフローチャートである。
【図１１】図９及び図１０の処理を説明する補足図である。
【図１２】ＷｅｂＳｏｃｋｅｔプロトコルに従って伝送されるフレームの構成を示す図である。
【図１３】フラグメント化されたデータを送信する場合のＦＩＮ及びｏｐｃｏｄｅを説明する図である。
【発明を実施するための形態】
【００２６】
以下、本発明を実施するための形態について図面を用いて詳細に説明する。
〔コンテンツ配信システム〕
図１は、本発明の実施形態によるコンテンツ配信システムの全体構成の概略を説明する図である。このコンテンツ配信システム１は、コンテンツサーバ２、緊急データサーバ３、プッシュ配信サーバ４及び受信端末５−１〜５−４（以下、総称して受信端末５という。）を備えて構成される。プッシュ配信サーバ４とコンテンツサーバ２及び緊急データサーバ３とは、コンテンツ中継ネットワーク６を介して接続される。また、プッシュ配信サーバ４と複数の受信端末５とは、インターネット７を介して接続される。
【００２７】
コンテンツサーバ２は、コンテンツの配信元となるサーバであり、コンテンツ中継ネットワーク６を介してプッシュ配信サーバ４と接続し、コンテンツをコンテンツ中継ネットワーク６、プッシュ配信サーバ４及びインターネット７を介して受信端末５へ送信する。コンテンツサーバ２は、１台だけでなく複数台であってもよい。コンテンツは、例えばテキスト、画像、動画、音声等の情報である。
【００２８】
緊急データサーバ３は、受信端末５のユーザに即座に伝えるべき緊急データの配信元となるサーバである。緊急データサーバ３は、コンテンツ中継ネットワーク６を介してプッシュ配信サーバ４と接続し、緊急データをコンテンツ中継ネットワーク６、プッシュ配信サーバ４及びインターネット７を介して受信端末５へ送信する。
【００２９】
プッシュ配信サーバ４は、ＷｅｂＳｏｃｋｅｔプロトコルを用いて受信端末５と接続し、コンテンツサーバ２からのコンテンツ及び緊急データサーバ３からの緊急データを、インターネット７を介して受信端末５へプッシュ配信する。
【００３０】
受信端末５は、ＷｅｂＳｏｃｋｅｔプロトコルを用いてプッシュ配信サーバ４と接続し、プッシュ配信サーバ４から送信されたコンテンツ及び緊急データを、インターネット７を介して受信し、受信したコンテンツ及び緊急データをユーザへ提示する。
【００３１】
〔データ及びフレームの構成〕
図２は、図１に示したコンテンツ配信システム１にて用いるデータ及びフレームの構成を示す図である。
【００３２】
図２に示すコンテンツデータは、コンテンツサーバ２から送信されるコンテンツまたはコンテンツの一部である。また、図２に示す緊急データは、緊急データサーバ３から送信される緊急データまたは緊急データの一部である。コンテンツデータ及び緊急データは、例えばテキスト、画像、動画、音声等であり、緊急データは、コンテンツデータと同様に扱われる。
【００３３】
カプセル化データは、コンテンツデータにヘッダ情報及びトレイラ情報を付与することでカプセル化したデータである。ヘッダ情報は、コンテンツ識別子（Ｔａｇ：タグ）及び開始／継続識別フラグ（ｈｃｏｄｅ）を含んで構成され、トレイラ情報は、終了／継続識別フラグ（ｔｃｏｄｅ）を含んで構成される。
【００３４】
コンテンツ識別子（Ｔａｇ）は、コンテンツデータを識別するためのタグであり、図２の例では０００１が付与されている。開始／継続識別フラグ（ｈｃｏｄｅ）は、カプセル化データがコンテンツデータの開始位置を含んでいるか否かを示すフラグである。ｈｃｏｄｅ＝１の場合は、コンテンツデータの開始位置を含んでおり、ｈｃｏｄｅ＝０の場合は、コンテンツデータの開始位置を含んでおらず、以前のカプセル化データと同一のコンテンツ識別子（Ｔａｇ）のカプセル化データであって、以前のカプセル化データに継続するカプセル化データであることを示している。
【００３５】
終了／継続識別フラグ（ｔｃｏｄｅ）は、カプセル化データがコンテンツデータの終了位置を含んでいるか否かを示すフラグである。ｔｃｏｄｅ＝１の場合は、コンテンツデータの終了位置を含んでおり、ｔｃｏｄｅ＝０の場合は、コンテンツデータの終了位置を含んでおらず、コンテンツデータの終了位置が、同一コンテンツ識別子（Ｔａｇ）を有する以後のカプセル化データに含まれることを示している。
【００３６】
フラグメント化フレームは、図１２に示したＷｅｂＳｏｃｋｅｔプロトコルに従ったフレームであり、カプセル化データが任意の大きさの断片データにフラグメント化され、その断片データがペイロードに格納されたフレームである。
【００３７】
図２の例は、カプセル化データが３つの断片データにフラグメント化され、その３つの断片データのそれぞれがフラグメント化フレームのペイロードに格納されていることを示している。フラグメント化フレームのヘッダに含まれるＦＩＮ及びｏｐｃｏｄｅの形式は、ＷｅｂＳｏｃｋｅｔプロトコルの仕様に従っている。先頭のフラグメント化フレームのヘッダには、ＦＩＮ＝０（３つ目の断片データが格納された最後のフラグメント化フレームではないことを示す）、ｏｐｃｏｄｅ＝２（バイナリフレームであることを示す）が設定されている。２番目のフラグメント化フレームのヘッダには、ＦＩＮ＝０、ｏｐｃｏｄｅ＝０（継続フレームであることを示す）が設定されている。最後のフラグメント化フレームのヘッダには、ＦＩＮ＝１（３つ目の断片データが格納された最後のフラグメント化フレームであることを示す）、ｏｐｃｏｄｅ＝０が設定されている。尚、図２のフラグメント化フレームの構成において、ＦＩＮ及びｏｐｃｏｄｅ以外のヘッダの記述は省略されている。
【００３８】
中断フレームは、ＷｅｂＳｏｃｋｅｔプロトコルに従ったフレームであり、そのペイロードにはカプセル化データのトレイラ情報のみを含む。この中断フレームは、一つのカプセル化データに属するフラグメント化フレームの送信を中断するときに用いられる。受信側は、この中断フレームを受信することにより、そのフラグメント化フレームに対応するコンテンツデータの送信が中断することを認識することができる。
【００３９】
中断フレームのヘッダにはＦＩＮ＝１（最後のフラグメント化フレームであることを示す）、ｏｐｃｏｄｅ＝０（継続フレームであることを示す）が設定され、ペイロードにはカプセル化データのｔｃｏｄｅ＝０（コンテンツデータの終了位置は、同一コンテンツ識別子（Ｔａｇ）を有する以後のカプセル化データに含まれることを示す）が設定されている。受信側は、中断フレームのヘッダがＦＩＮ＝１である場合、ＷｅｂＳｏｃｋｅｔプロトコルに従った一連のフラグメント化フレームの受信処理を終了させることができる。
【００４０】
再開フレームは、ＷｅｂＳｏｃｋｅｔプロトコルに従ったフレームであり、そのペイロードにはカプセル化データのヘッダ情報のみを含む。この再開フレームは、中断フレームにより中断されたフラグメント化フレームの送信を再開するときに用いられる。受信側は、この再開フレームを受信することにより、以前中断したコンテンツデータの送信が再開することを認識することができる。
【００４１】
再開フレームのヘッダにはＦＩＮ＝０（最後のフラグメント化フレームではないことを示す）、ｏｐｃｏｄｅ＝２（バイナリフレームであることを示す）が設定され、ペイロードには、送信が再開されるコンテンツデータのコンテンツ識別子（本例ではＴａｇ＝０００１）、及びｈｃｏｄｅ＝０（コンテンツデータの開始位置を含んでいないことを示す）が設定されている。再開フレームのペイロードに、送信が再開されるコンテンツデータのコンテンツ識別子（Ｔａｇ）が含まれているのは、送信が再開されるコンテンツデータのフラグメント化フレームにはそのコンテンツ識別子（Ｔａｇ）が含まれていないからである。受信側は、この再開フレームを受信することにより、当該再開フレームに含まれるコンテンツ識別子（Ｔａｇ）を、後に送信されるフラグメント化フレームのコンテンツ識別子（Ｔａｇ）として認識することができる。
【００４２】
尚、前述のカプセル化データ、中断フレーム及び再開フレームは、従来技術に対して追加した新たなデータ及びフレームである。また、フラグメント化フレーム、中断フレーム及び再開フレームにカプセル化データのヘッダ情報またはトレイラ情報が含まれているか否かは、そのヘッダに格納されたＦＩＮ及びｏｐｃｏｄｅの組み合わせにより認識することができる。
【００４３】
図３は、これらのフレームのヘッダに格納されたＦＩＮ及びｏｐｃｏｄｅの組み合わせと、カプセル化データのヘッダ情報及びトレイラ情報の存在との関係を示す図である。図３に示すように、フレームのヘッダに格納されたＦＩＮ及びｏｐｃｏｄｅの組み合わせから、フレームのペイロードにカプセル化データのヘッダ情報及び／またはトレイラ情報が格納されているか否かを認識することができる。
【００４４】
例えば、フレームのヘッダにＦＩＮ＝０及びｏｐｃｏｄｅ＝０が格納されている場合、当該フレームのペイロードには、カプセル化データのヘッダ情報及びトレイラ情報が格納されていないことが認識される。また、フレームのヘッダにＦＩＮ＝０及びｏｐｃｏｄｅ＝２（０以外）が格納されている場合、当該フレームのペイロードには、カプセル化データのヘッダ情報が格納されており、トレイラ情報が格納されていないことが認識される。その他、フレームのヘッダにＦＩＮ＝１及びｏｐｃｏｄｅ＝０等が格納されている場合は、図３に示すとおりである。
【００４５】
このように、受信側は、受信したフレームのヘッダに格納されたＦＩＮ及びｏｐｃｏｄｅの組み合わせについて、図３に示した情報が格納されたテーブルを参照することにより、受信したフレームのペイロードにカプセル化データのヘッダ情報及び／またはトレイラ情報が格納されているか否かを認識することができる。
【００４６】
〔プッシュ配信サーバ〕
次に、図１に示したプッシュ配信サーバ４について説明する。図４は、本発明の実施形態によるプッシュ配信サーバ４の構成を示すブロック図である。このプッシュ配信サーバ４は、セッション制御手段１０、コンテンツデータ入力手段１１、緊急データ入力手段１２、タグ管理手段１３、フラグメント生成手段１４、フラグメントバッファ１５、緊急データフラグメント生成手段１６、緊急データフラグメントバッファ１７、フラグメント多重化手段１８、パケット送信手段１９及び通信Ｉ／Ｆ２０，２１を備えている。尚、プッシュ配信サーバ４は、複数組のコンテンツデータ入力手段１１及びフラグメント生成手段１４を備えるようにしてもよい。フラグメント多重化手段１８及びパケット送信手段１９によりフラグメント送信手段が構成される。
【００４７】
セッション制御手段１０は、受信端末５から通信Ｉ／Ｆ２１を介して接続要求を受け付け、ＷｅｂＳｏｃｋｅｔプロトコルに従って、当該プッシュ配信サーバ４と接続要求を送信してきた受信端末５との間でコンテンツデータ送信用のセッションを確立する。また、セッション制御手段１０は、受信端末５から通信Ｉ／Ｆ２１を介して切断要求を受け付け、当該セッションを切断する。
【００４８】
コンテンツデータ入力手段１１は、コンテンツサーバ２から通信Ｉ／Ｆ２０を介してコンテンツデータを逐次受信し、受信したコンテンツデータをフラグメント生成手段１４に出力する。
【００４９】
緊急データ入力手段１２は、緊急データサーバ３から通信Ｉ／Ｆ２０を介して緊急データを受信し、受信した緊急データを緊急データフラグメント生成手段１６に出力する。
【００５０】
タグ管理手段１３は、当該プッシュ配信サーバ４において、同時期に配信されるコンテンツデータ及び緊急データを識別するためのコンテンツ識別子（タグ）を生成及び管理する。そして、タグ管理手段１３は、当該プッシュ配信サーバ４によるコンテンツデータ及び緊急データの送信に応じて、対応するコンテンツデータのコンテンツ識別子（タグ）をフラグメント生成手段１４に出力し、対応する緊急データのコンテンツ識別子（タグ）を緊急データフラグメント生成手段１６に出力する。
【００５１】
フラグメント生成手段１４は、コンテンツデータ入力手段１１からコンテンツデータを入力すると共に、タグ管理手段１３からコンテンツ識別子（タグ）を入力し、コンテンツ識別子（タグ）をｔａｇに設定すると共に、１をｈｃｏｄｅ及びｔｃｏｄｅにそれぞれ設定し、所定のヘッダ情報及び所定のトレイラ情報を生成し、コンテンツデータにヘッダ情報及びトレイラ情報を付与し、図２に示したカプセル化データを生成する。そして、フラグメント生成手段１４は、生成したカプセル化データを所定のＮバイト（例えば１ｋバイト）毎の断片データに分割し、所定のヘッダを生成して断片データにヘッダを付与すると共に、断片データをペイロードに格納し、図２に示したフラグメント化フレームを生成する。フラグメント生成手段１４は、生成したフラグメント化フレームをフラグメントバッファ１５に格納する。
【００５２】
緊急データフラグメント生成手段１６は、緊急データ入力手段１２から緊急データを入力すると共に、タグ管理手段１３からコンテンツ識別子（タグ）を入力し、コンテンツ識別子（タグ）をｔａｇに設定する等して、所定のヘッダ情報及び所定のトレイラ情報を生成し、緊急データにヘッダ情報及びトレイラ情報を付与し、図２に示したカプセル化データを生成する。そして、緊急データフラグメント生成手段１６は、生成したカプセル化データを所定のＮバイト（例えば１ｋバイト）毎の断片データに分割し、所定のヘッダを生成して断片データにヘッダを付与すると共に、断片データをペイロードに格納し、図２に示したフラグメント化フレームを生成する。緊急データフラグメント生成手段１６は、生成したフラグメント化フレームを緊急データフラグメントバッファ１７に格納する。
【００５３】
フラグメント多重化手段１８は、フラグメントバッファ１５及び緊急データフラグメントバッファ１７にフラグメント化フレームが蓄積されているか否かを確認する。そして、フラグメント多重化手段１８は、フラグメントバッファ１５にフラグメント化フレームが蓄積されていることを確認すると、フラグメントバッファ１５からフラグメント化フレームを読み出す。また、フラグメント多重化手段１８は、緊急データフラグメントバッファ１７にフラグメント化フレームが蓄積されていることを確認すると、緊急データフラグメントバッファ１７からフラグメント化フレームを読み出す。この場合、フラグメント多重化手段１８は、緊急データフラグメントバッファ１７からの読み出し処理をフラグメントバッファ１５からの読み出し処理よりも優先して行う。そして、フラグメント多重化手段１８は、読み出したフラグメント化フレームを多重化し、フラグメント化フレームをパケット送信手段１９に出力する。
【００５４】
ここで、フラグメント多重化手段１８は、当該プッシュ配信サーバ４がコンテンツデータを送信しているときに緊急データを割り込んで送信する場合、図２に示した中断フレームを生成してパケット送信手段１９に出力する。また、フラグメント多重化手段１８は、中断したコンテンツデータの送信を再開する場合、図２に示した再開フレームを生成してパケット送信手段１９に出力する。
【００５５】
パケット送信手段１９は、フラグメント多重化手段１８からフラグメント化フレームを入力し、フラグメント化フレームをパケットに収容する。そして、パケット送信手段１９は、フラグメント化フレームを収容したパケットを、当該プッシュ配信サーバ４と受信端末５との間で確立したコンテンツデータ送信用のセッションにより、通信Ｉ／Ｆ２１を介して受信端末５へ送信する。
【００５６】
（フラグメント多重化手段）
次に、図４に示したフラグメント多重化手段１８の処理について詳細に説明する。図５は、フラグメント多重化手段１８の処理を示すフローチャートである。まず、フラグメント多重化手段１８は、緊急データフラグメントバッファ１７にフラグメント化フレームが蓄積されているか否かを確認する（ステップＳ５０１）。フラグメント多重化手段１８は、ステップＳ５０１において、緊急データフラグメントバッファ１７にフラグメント化フレームが蓄積されていることを確認した場合（ステップＳ５０１：Ｙ）、コンテンツデータのフラグメント化フレームを送信中であるか否かを判定する（ステップＳ５０２）。
【００５７】
フラグメント多重化手段１８は、ステップＳ５０２において、コンテンツデータのフラグメント化フレームを送信中であると判定した場合（ステップＳ５０２：Ｙ）、図２に示した中断フレームを生成してパケット送信手段１９に出力し（ステップＳ５０３）、ステップＳ５０４へ移行する。例えば、コンテンツデータのフラグメント化フレームを送信中であるとは、図２に示したフラグメント化フレームにおいて、１番目のフラグメント化フレームを送信した以降であり、３番目のフラグメント化フレームを送信する以前である場合をいう。これにより、送信中のコンテンツデータの送信が中断される。この場合、フラグメント多重化手段１８は、送信を中断したコンテンツデータのコンテンツ識別子（Ｔａｇ）を中断タグとして保持する。
【００５８】
一方、フラグメント多重化手段１８は、ステップＳ５０２において、コンテンツデータのフラグメント化フレームを送信中でないと判定した場合（ステップＳ５０２：Ｎ）、ステップＳ５０４へ移行する。
【００５９】
フラグメント多重化手段１８は、ステップＳ５０２またはステップＳ５０３から移行して、緊急データフラグメントバッファ１７からフラグメント化フレームを読み出し、読み出した緊急データのフラグメント化フレームをパケット送信手段１９に出力する（ステップＳ５０４）。そして、ステップＳ５０９へ移行する。
【００６０】
一方、フラグメント多重化手段１８は、ステップＳ５０１において、緊急データフラグメントバッファ１７にフラグメント化フレームが蓄積されていないことを確認した場合（ステップＳ５０１：Ｎ）、フラグメントバッファ１５にフラグメント化フレームが蓄積されているか否かを確認する（ステップＳ５０５）。フラグメント多重化手段１８は、ステップＳ５０５において、フラグメントバッファ１５にフラグメント化フレームが蓄積されていないことを確認した場合（ステップＳ５０５：Ｎ）、ステップＳ５０１へ移行する。
【００６１】
一方、フラグメント多重化手段１８は、ステップＳ５０５において、フラグメントバッファ１５にフラグメント化フレームが蓄積されていることを確認した場合（ステップＳ５０５：Ｙ）、フラグメントバッファ１５に蓄積されているフラグメント化フレームのコンテンツデータについて、それと同一のコンテンツ識別子（Ｔａｇ）のフラグメント化フレームの送信を中断しているか否かを確認する（ステップＳ５０６）。具体的には、フラグメント多重化手段１８は、ステップＳ５０３において保持した中断タグが存在する場合であって、フラグメントバッファ１５に蓄積されているフラグメント化フレームのコンテンツ識別子（Ｔａｇ）と、その中断タグの示すコンテンツ識別子（Ｔａｇ）とが同一であるか否かを確認する。これらのコンテンツ識別子（Ｔａｇ）が同一の場合は、送信を中断していると判断し、同一でない場合は、送信を中断していないと判断する。
【００６２】
フラグメント多重化手段１８は、ステップＳ５０６において、当該コンテンツ識別子（Ｔａｇ）のフラグメント化フレームの送信を中断していることを確認した場合（ステップＳ５０６：Ｙ）、図２に示した再開フレームを生成してパケット送信手段１９に出力し（ステップＳ５０７）、ステップＳ５０８へ移行する。この場合、フラグメント多重化手段１８は、再開フレームのペイロードに格納するＴａｇ（送信を再開するコンテンツデータのＴａｇ）に、中断タグの示すコンテンツ識別子（Ｔａｇ）を設定し、中断タグをクリアする。
【００６３】
一方、フラグメント多重化手段１８は、ステップＳ５０６において、当該コンテンツ識別子（Ｔａｇ）のフラグメント化フレームの送信を中断していないことを確認した場合（ステップＳ５０６：Ｎ）、ステップＳ５０８へ移行する。
【００６４】
フラグメント多重化手段１８は、ステップＳ５０６またはステップＳ５０７から移行して、フラグメントバッファ１５からフラグメント化フレームを読み出し、読み出したコンテンツデータのフラグメント化フレームをパケット送信手段１９に出力する（ステップＳ５０８）。そして、ステップＳ５０９へ移行する。
【００６５】
フラグメント多重化手段１８は、ステップＳ５０４またはステップＳ５０８から移行して、送信すべきコンテンツデータ及び緊急データに対応する全てのパケットの送信が終了しているか否かを判定し（ステップＳ５０９）、全てのパケットの送信が終了していないと判定した場合（ステップＳ５０９：Ｎ）、ステップＳ５０１へ移行し、全てのパケットの送信が終了していると判定した場合（ステップＳ５０９：Ｙ）、処理を終了する。この場合、フラグメント多重化手段１８は、セッション制御手段１０からセッションが切断されたことを示す情報を入力したときに、全てのパケットの送信が終了していると判定し、処理を終了する。
【００６６】
〔送受信シーケンス〕
次に、コンテンツサーバ２、緊急データサーバ３、プッシュ配信サーバ４及び受信端末５におけるコンテンツデータ及び緊急データの送受信シーケンスについて説明する。図６は、その送受信シーケンスを説明する図である。
【００６７】
コンテンツサーバ２がコンテンツデータをプッシュ配信サーバ４へ送信すると（ステップＳ６０１）、プッシュ配信サーバ４は、コンテンツデータを受信し、コンテンツデータに対してコンテンツ識別子（Ｔａｇ＝１）を付与してカプセル化データ及びフラグメント化フレームを生成する（ステップＳ６０２）。そして、プッシュ配信サーバ４は、Ｔａｇ＝１のフラグメント化フレームを収容したパケットを受信端末５へ送信する（ステップＳ６０３）。
【００６８】
緊急データサーバ３が受信端末５のユーザに即座に伝えるべき緊急データを生成してプッシュ配信サーバ４へ送信すると（ステップＳ６０４）、プッシュ配信サーバ４は、緊急データを受信し、緊急データに対してコンテンツ識別子（Ｔａｇ＝２）を付与してカプセル化データ及びフラグメント化フレームを生成する（ステップＳ６０５）。そして、プッシュ配信サーバ４は、中断フレームを生成し（ステップＳ６０６）、中断フレームを収容したパケットを受信端末５へ送信する（ステップＳ６０７）。これにより、Ｔａｇ＝１のコンテンツデータの送信が中断する。
【００６９】
プッシュ配信サーバ４は、Ｔａｇ＝２のフラグメント化フレームを収容したパケット（緊急データのパケット）を受信端末５へ送信する（ステップＳ６０８）。そして、プッシュ配信サーバ４は、緊急データの送信が完了すると、中断していたＴａｇ＝１のコンテンツデータの送信を再開するため、再開フレームを生成し（ステップＳ６０９）、再開フレームを収容したパケットを受信端末５へ送信する（ステップＳ６１０）。そして、プッシュ配信サーバ４は、Ｔａｇ＝１のフラグメント化フレームを収容したパケットを継続して受信端末５へ送信する（ステップＳ６１１）。
【００７０】
これにより、プッシュ配信サーバ４からＷｅｂＳｏｃｋｅｔプロトコルを用いてＴａｇ＝１のコンテンツデータのフラグメント化フレームを配信しているときに、Ｔａｇ＝２の緊急データを割り込んで送信することができる。したがって、一般的なコンテンツデータを配信しているときに、緊急データを即座にユーザに伝えることができる。
【００７１】
以上のように、本発明の実施形態によるプッシュ配信サーバ４によれば、フラグメント生成手段１４は、コンテンツデータを入力すると、ヘッダ情報及びトレイラ情報を生成し、コンテンツデータにヘッダ情報及びトレイラ情報を付与してカプセル化し、カプセル化データを生成するようにした。そして、フラグメント生成手段１４は、生成したカプセル化データを所定長毎の断片データに分割し、ヘッダを生成して断片データをペイロードに格納し、フラグメント化フレームを生成するようにした。ヘッダ情報には、コンテンツ識別子（Ｔａｇ）、及びコンテンツデータの開始位置を含むか否かを示す開始／継続識別フラグ（ｈｃｏｄｅ）を含む。トレイラ情報には、コンテンツデータの終了位置を含むか否かを示す終了／継続識別フラグ（ｔｃｏｄｅ）を含む。
【００７２】
また、緊急データフラグメント生成手段１６は、緊急データを入力すると、フラグメント生成手段１４と同様にカプセル化データを生成し、フラグメント化フレームを生成するようにした。
【００７３】
そして、フラグメント多重化手段１８は、コンテンツデータのフラグメント化フレームを、パケット送信手段１９を介して受信端末５へ送信しているときに、緊急データを割り込んで送信する場合、緊急データのフラグメント化フレームを送信する前に、中断フレームを受信端末５へ送信するようにした。これにより、プッシュ配信サーバ４は受信端末５に対して、コンテンツデータの送信が中断することを伝えることができ、受信端末５は、中断フレームを受信することで、コンテンツデータの送信が中断することを認識することができる。
【００７４】
そして、フラグメント多重化手段１８は、緊急データの送信が終了すると、送信が中断していたコンテンツデータの送信を再開するための再開フレームを、受信端末５へ送信する。これにより、プッシュ配信サーバ４は受信端末５に対して、コンテンツデータの送信が再開することを伝えることができ、受信端末５は、再開フレームを受信することで、コンテンツデータの送信が再開することを認識することができる。再開フレームには、再開するコンテンツデータのコンテンツ識別子（Ｔａｇ）を含む。
【００７５】
これにより、プッシュ配信サーバ４は、ＷｅｂＳｏｃｋｅｔプロトコルを用いてコンテンツデータのフラグメント化フレームを送信しているときに、当該コンテンツデータの全てのフラグメント化フレームの送信が終了するのを待つことなく、緊急データを割り込んで送信することができる。したがって、ＷｅｂＳｏｃｋｅｔプロトコルを用いたデータ配信において、緊急データを割り込んで受信端末５へ送信することができ、緊急データを即座にユーザに伝えることが可能となる。また、ＷｅｂＳｏｃｋｅｔプロトコルを用いて緊急データの割り込み送信を実現するから、ＷｅｂＳｏｃｋｅｔプロトコルを実装する既存のシステムを使用することができる。
【００７６】
〔受信端末〕
次に、図１に示した受信端末５について説明する。図７は、本発明の実施形態による受信端末５の構成を示すブロック図である。この受信端末５は、接続制御手段３０、パケット受信手段３１、フラグメント復元手段３２、コンテンツデータ記憶手段３３、デコーダ３４、提示部３５及び通信Ｉ／Ｆ３６を備えている。
【００７７】
接続制御手段３０は、受信開始時に、接続要求を、通信Ｉ／Ｆ３６を介してプッシュ配信サーバ４へ送信し、ＷｅｂＳｏｃｋｅｔプロトコルに従って、当該受信端末５とプッシュ配信サーバ４との間でコンテンツデータ受信用のセッションを確立する。また、接続制御手段３０は、受信終了時に、切断要求を、通信Ｉ／Ｆ３６を介してプッシュ配信サーバ４へ送信し、当該セッションを切断する。
【００７８】
パケット受信手段３１は、当該受信端末５とプッシュ配信サーバ４との間で確立したコンテンツデータ受信用のセッションにより、プッシュ配信サーバ４から通信Ｉ／Ｆ３６を介してパケットを受信し、受信したパケットをフラグメント復元手段３２に出力する。
【００７９】
フラグメント復元手段３２は、パケット受信手段３１からパケットを入力し、ＷｅｂＳｏｃｋｅｔのフレーミングプロトコルに従って、入力したパケットからフラグメント化フレーム、中断フレームまたは再開フレームを復元し、復元したフラグメント化フレーム、中断フレームまたは再開フレームのペイロードに格納されているデータを抽出する。これにより、フラグメント化フレームから、カプセル化データから分割された断片データが抽出され、中断フレームからｔｃｏｄｅ＝０が抽出され、再開フレームからコンテンツ識別子（Ｔａｇ）及びｈｃｏｄｅ＝０が抽出される。中断フレーム及び再開フレームからは、カプセル化データから分割された断片データが抽出されることはない。
【００８０】
フラグメント復元手段３２は、抽出したカプセル化データを構成する断片データから、コンテンツデータの断片及びコンテンツ識別子（Ｔａｇ）を抽出し、コンテンツ識別子（Ｔａｇ）に対応付けてコンテンツデータの断片をコンテンツデータ記憶手段３３に格納する。この場合、フラグメント化フレームが、カプセル化データのヘッダ情報を含まない場合は、フラグメント復元手段３２は、直前に復元したフラグメント化フレームのコンテンツ識別子（Ｔａｇ）を用いて、当該コンテンツ識別子（Ｔａｇ）に対応付けてコンテンツデータの断片をコンテンツデータ記憶手段３３に格納する。尚、中断フレームまたは再開フレームの場合、コンテンツデータの断片がコンテンツデータ記憶手段３３に格納されることはない。
【００８１】
フラグメント復元手段３２は、コンテンツデータを構成する全ての断片をコンテンツデータ記憶手段３３に格納した場合、コンテンツデータの復元が完了したと判定し、コンテンツ識別子（Ｔａｇ）に対応付けてコンテンツデータ復元完了フラグをコンテンツデータ記憶手段３３に格納する。コンテンツデータ復元完了フラグは、一つのコンテンツデータの復元が完了したか否かを示すフラグである。つまり、フラグメント復元手段３２は、復元したフラグメント化フレームにＦＩＮ＝１、ｏｐｃｏｄｅ＝０、ｔｃｏｄｅ＝１が設定されており、当該フラグメント化フレームに含まれるコンテンツデータの断片をコンテンツデータ記憶手段３３に格納した場合、コンテンツデータの復元が完了したと判定し、コンテンツデータ復元完了フラグをコンテンツデータ記憶手段３３に格納する。
【００８２】
コンテンツデータ記憶手段３３は、コンテンツ識別子（Ｔａｇ）に対応付けてコンテンツデータの断片を記憶する。コンテンツデータ記憶手段３３は、当該コンテンツ識別子（Ｔａｇ）に対応するコンテンツデータの断片の全てを記憶したことを確認した場合、すなわち、当該コンテンツ識別子（Ｔａｇ）に対応するコンテンツデータ復元完了フラグを記憶したことを確認した場合、当該コンテンツデータの復元が完了したと判定し、当該コンテンツ識別子（Ｔａｇ）に対応する復元したコンテンツデータをデコーダ３４に出力する。
【００８３】
デコーダ３４は、コンテンツデータ記憶手段３３からその復元したコンテンツデータを入力し、入力したコンテンツデータをデコードし、提示部３５に出力する。提示部３５は、デコーダ３４からデコードされたコンテンツデータを入力し、ユーザへ提示する。
【００８４】
（受信端末の処理）
次に、図７に示した受信端末５の処理について詳細に説明する。図８は、受信端末５の処理を示すフローチャートである。まず、受信端末５のパケット受信手段３１は、プッシュ配信サーバ４からパケットを受信し（ステップＳ８０１）、フラグメント復元手段３２は、パケット受信手段３１が受信したパケットからフラグメント化フレーム、中断フレームまたは再開フレームを復元し、復元したフレームのヘッダからＦＩＮ及びｏｐｃｏｄｅを抽出すると共に、ペイロードからカプセル化データを構成する断片データ等を抽出する（ステップＳ８０２）。前述のとおり、フラグメント化フレームの場合は、カプセル化データを構成する断片データが抽出され、中断フレームの場合はｔｃｏｄｅ＝０が抽出され、再開フレームの場合はコンテンツ識別子（Ｔａｇ、送信を再開するコンテンツデータのＴａｇ、以下「Ｔａｇ」と記載する。）及びｈｃｏｄｅ＝０が抽出される。
【００８５】
フラグメント復元手段３２は、ＦＩＮ及びｏｐｃｏｄｅに基づいて、断片データ等に含まれるＴａｇ、ｈｃｏｄｅ及びｔｃｏｄｅを抽出し、またはＴａｇ、ｈｃｏｄｅ及びｔｃｏｄｅを設定する（ステップＳ８０３）。具体的には、フラグメント復元手段３２は、図３に示したＦＩＮ及びｏｐｃｏｄｅの組み合わせとヘッダ情報及びトレイラ情報の存在との関係を示す情報が格納されたテーブルを参照し、復元したフレームから抽出したＦＩＮ及びｏｐｃｏｄｅに基づいて、フレームのペイロードにカプセル化データのヘッダ情報及び／またはトレイラ情報が格納されているか否かを認識する。そして、フラグメント復元手段３２は、フレームのペイロードにカプセル化データのヘッダ情報が格納されている場合、ヘッダ情報に含まれるＴａｇ及びｈｃｏｄｅを抽出し、フレームのペイロードにカプセル化データのトレイラ情報が格納されている場合、トレイラ情報に含まれるｔｃｏｄｅを抽出する。また、フラグメント復元手段３２は、これらの情報を抽出できない場合、ｔａｇ、ｈｃｏｄｅ及びｔｃｏｄｅを所定値に設定する。
【００８６】
図９は、図８に示したＴａｇ、ｈｃｏｄｅ及びｔｃｏｄｅの抽出／設定処理（ステップＳ８０３）を示すフローチャートであり、図１１は、図９及び後述する図１０の処理を説明する補足図である。フラグメント復元手段３２は、抽出したヘッダのｏｐｃｏｄｅが０以外であるか否かを判定し（ステップＳ９０１）、ｏｐｃｏｄｅが０以外であると判定した場合（ステップＳ９０１：Ｙ）、抽出したカプセル化データを構成する断片データ等からそのヘッダ情報を復元し、Ｔａｇ及びｈｃｏｄｅを抽出し（ステップＳ９０２）、ステップＳ９０４へ移行する。
【００８７】
一方、フラグメント復元手段３２は、ステップＳ９０１において、ｏｐｃｏｄｅが０以外でないと判定した場合（ステップＳ９０１：Ｎ）、抽出したカプセル化データを構成する断片データ等にはそのヘッダ情報が存在しないから、直前に復元したフレームのＴａｇを自身のＴａｇに設定し、ｈｃｏｄｅを０に設定し（ステップＳ９０３）、ステップＳ９０４へ移行する。
【００８８】
これにより、図１１に示すように、１番目に復元したフラグメント化フレームに対するステップＳ９０２の処理において、カプセル化データのヘッダ情報が復元され、Ｔａｇ＝０００１及びｈｃｏｄｅ＝１が抽出される。また、２番目及び３番目に復元したフラグメント化フレームに対するステップＳ９０３の処理において、Ｔａｇ＝０００１（直前に復元した１番目のフラグメント化フレームから抽出したＴａｇ＝０００１）及びｈｃｏｄｅ＝０に設定される。
【００８９】
図９に戻って、フラグメント復元手段３２は、ステップＳ９０２またはステップＳ９０３から移行して、抽出したヘッダのＦＩＮが１であるか否かを判定し（ステップＳ９０４）、ＦＩＮが１でないと判定した場合（ステップＳ９０４：Ｎ）、ｔｃｏｄｅを０に設定する（ステップＳ９０６）。
【００９０】
一方、フラグメント復元手段３２は、ステップＳ９０４において、ＦＩＮが１であると判定した場合（ステップＳ９０４：Ｙ）、抽出したカプセル化データを構成する断片データ等からそのトレイラ情報を復元し、ｔｃｏｄｅを抽出する（ステップＳ９０５）。
【００９１】
これにより、図１１に示すように、１番目に復元したフラグメント化フレームに対するステップＳ９０６の処理において、ｔｃｏｄｅ＝０に設定される。また、２番目及び３番目に復元したフラグメント化フレームに対するステップＳ９０５の処理において、カプセル化データのトレイラ情報が復元され、ｔｃｏｄｅ＝１が抽出される。
【００９２】
図８に戻って、フラグメント復元手段３２は、ステップＳ８０３から移行して、抽出したカプセル化データを構成する断片データから、コンテンツデータの断片を抽出し、ステップＳ８０３において抽出または設定したＴａｇに対応付けてコンテンツデータの断片をコンテンツデータ記憶手段３３に格納する（ステップＳ８０４）。尚、中断フレーム及び再開フレームの場合はコンテンツデータの断片が存在しないから、フラグメント復元手段３２は、コンテンツデータの断片を抽出することができず、コンテンツデータ記憶手段３３への格納処理を行わない。
【００９３】
図１０は、図８に示したコンテンツデータの断片の抽出／格納処理（ステップＳ８０４）を示すフローチャートである。フラグメント復元手段３２は、カプセル化データを構成する断片データからコンテンツデータの断片を抽出し（ステップＳ１００１）、ｈｃｏｄｅが１であるか否かを判定する（ステップＳ１００２）。
【００９４】
フラグメント復元手段３２は、ステップＳ１００２において、ｈｃｏｄｅが１であると判定した場合（ステップＳ１００２：Ｙ）、当該コンテンツデータの断片は新たなコンテンツデータの最初の断片であると判断し、Ｔａｇと対応付けたコンテンツデータの断片を、コンテンツデータ記憶手段３３に新たに格納する（ステップＳ１００３）。一方、フラグメント復元手段３２は、ステップＳ１００２において、ｈｃｏｄｅが１でないと判定した場合（ステップＳ１００２：Ｎ）、当該コンテンツデータの断片は新たなコンテンツデータの断片ではなく、継続する断片であると判断し、Ｔａｇと対応付けたコンテンツデータの断片を、コンテンツデータ記憶手段３３に格納することで、既に格納済みのコンテンツデータの末尾に追加する（ステップＳ１００４）。
【００９５】
これにより、図１１に示すように、ステップＳ１００３の処理にて、１番目のフラグメント化フレームから抽出されたコンテンツデータの断片Ａが、Ｔａｇ＝０００１に対応してコンテンツデータ記憶手段３３に格納される。また、ステップＳ１００４の処理にて、２番目及び３番目のフラグメント化フレームから抽出されたコンテンツデータの断片Ｂ，Ｃが、Ｔａｇ＝０００１に対応してコンテンツデータ記憶手段３３に格納される。
【００９６】
図８に戻って、フラグメント復元手段３２は、ステップＳ８０４から移行して、ｔｃｏｄｅが１であるか否かを判定し（ステップＳ８０５）、ｔｃｏｄｅが１でないと判定した場合（ステップＳ８０５：Ｎ）、コンテンツデータの復元が終了していないと判断してステップＳ８０１へ移行し、ステップＳ８０１からステップＳ８０４にて次のフラグメント化フレームに対する処理を行い、コンテンツデータの断片をコンテンツデータ記憶手段３３に格納する。
【００９７】
一方、フラグメント復元手段３２は、ステップＳ８０５において、ｔｃｏｄｅが１であると判定した場合（ステップＳ８０５：Ｙ）、コンテンツデータを構成する全ての断片が揃ったためコンテンツデータの復元が終了したと判断し、当該Ｔａｇに対応付けたコンテンツデータ復元完了フラグをコンテンツデータ記憶手段３３に格納する。
【００９８】
コンテンツデータ記憶手段３３は、当該Ｔａｇに対応するコンテンツデータ復元完了フラグを記憶したことを確認し、当該Ｔａｇに対応するコンテンツデータをデコーダ３４に出力する（ステップＳ８０６）。デコーダ３４は、コンテンツデータ記憶手段３３からコンテンツデータを入力し、入力したコンテンツデータをデコードして提示部３５に出力し、提示部３５は、コンテンツデータをユーザへ提示する（ステップＳ８０７）。
【００９９】
受信端末５は、全てのパケットの受信を終了したか、またはプッシュ配信サーバ４との間のセッションを切断したかにより、受信終了であるか否かを判定し（ステップＳ８０８）、受信終了でないと判定した場合（ステップＳ８０８：Ｎ）、ステップＳ８０１へ移行し、受信終了であると判定した場合（ステップＳ８０８：Ｙ）、処理を終了する。
【０１００】
ここで、フラグメント復元手段３２は、ステップＳ８０２において、パケットから中断フレームを復元した場合、中断フレームのヘッダからＦＩＮ＝１及びｏｐｃｏｄｅ＝０を抽出し、ペイロードからデータ（ｔｃｏｄｅ＝０）を抽出する。そして、フラグメント復元手段３２は、ステップＳ９０１、ステップＳ９０３、ステップＳ９０４、ステップＳ９０５、ステップＳ１００１及びステップＳ１００２の処理を行い、ステップＳ１００４において、コンテンツデータ記憶手段３３への格納処理を行わない。
【０１０１】
また、フラグメント復元手段３２は、ステップＳ８０２において、パケットから再開フレームを復元した場合、再開フレームのヘッダからＦＩＮ＝０及びｏｐｃｏｄｅ＝２を抽出し、ペイロードからデータ（Ｔａｇ及びｈｃｏｄｅ＝０）を抽出する。そして、フラグメント復元手段３２は、ステップＳ９０１、ステップＳ９０２、ステップＳ９０４、ステップＳ９０６、ステップＳ１００１及びステップＳ１００２の処理を行い、ステップＳ９０２において、Ｔａｇ及びｈｃｏｄｅ＝０を抽出し、ステップＳ１００４において、コンテンツデータ記憶手段３３への格納処理を行わない。
【０１０２】
これにより、受信端末５は、フラグメント化フレームと同様のＷｅｂＳｏｃｋｅｔプロトコルに従った処理により、中断フレーム及び再開フレームに対する処理を行うことができる。また、コンテンツデータ記憶手段３３には、Ｔａｇに対応付けてコンテンツデータの断片が格納されるから、通常のコンテンツデータの断片とは別に、緊急データの断片を格納することができる。したがって、コンテンツデータ記憶手段３３に、通常のコンテンツデータの断片及び緊急データの断片が格納された場合であっても、通常のコンテンツデータと緊急データとを区別することができ、デコーダ３４は、通常のコンテンツデータに対して割り込んだ緊急データをデコードし、提示部３５が緊急データをユーザへ提示することができる。
【０１０３】
以上のように、本発明の実施形態による受信端末５によれば、フラグメント復元手段３２は、受信したコンテンツデータのフラグメント化フレーム毎に、これらのペイロードからデータを抽出し、ヘッダからＦＩＮ及びｏｐｃｏｄｅを抽出して所定のテーブル（図３に示した情報が格納されたテーブル）を参照することで、抽出したデータを用いて、カプセル化データのヘッダ情報（Ｔａｇ及びｈｃｏｄｅ）及びトレイラ情報（ｔｃｏｄｅ）を抽出または設定するようにした。そして、フラグメント復元手段３２は、フラグメント化フレーム毎に、ペイロードから抽出したデータからコンテンツデータの断片を抽出し、Ｔａｇに対応付けてコンテンツデータの断片をコンテンツデータ記憶手段３３に格納することで、コンテンツデータを復元するようにした。緊急データを受信する場合も、コンテンツデータと同様の処理にて、緊急データを復元することができる。
【０１０４】
また、フラグメント復元手段３２は、受信した中断フレーム（ヘッダにＦＩＮ＝１及びｏｐｃｏｄｅ＝０を含み、ペイロードにカプセル化データのトレイラ情報であるｔｃｏｄｅ＝０を含む）及び再開フレーム（ヘッダにＦＩＮ＝０及びｏｐｃｏｄｅ＝２を含み、ペイロードにカプセル化データのヘッダ情報であるＴａｇ及びｈｃｏｄｅ＝０を含む）に対し、フラグメント化フレームと同様の処理を行うようにした。この場合、中断フレーム及び再開フレームには、コンテンツデータの断片が含まれないから、中断フレーム及び再開フレームからコンテンツデータの断片は抽出されない。また、再開フレームには、送信が再開するコンテンツデータのＴａｇが含まれるから、受信端末５は、後続して受信するフラグメント化フレームに含まれるコンテンツデータの断片のＴａｇを認識することができる。
【０１０５】
つまり、受信端末５は、コンテンツデータのフラグメント化フレームを受信しているときに、中断フレームを受信し、緊急データの全てのフラグメント化フレームを受信して緊急データを復元する。そして、受信端末５は、再開フレームを受信し、後続するコンテンツデータの残りのフラグメント化フレームを受信してコンテンツデータを復元する。
【０１０６】
これにより、受信端末５は、プッシュ配信サーバ４からＷｅｂＳｏｃｋｅｔプロトコルを用いてコンテンツデータのフラグメント化フレームを受信しているときに、当該コンテンツデータの全てのフラグメント化フレームの受信が終了するのを待つことなく、緊急データを割り込んで受信することができる。これにより、ＷｅｂＳｏｃｋｅｔプロトコルを用いたデータ配信において、緊急データを割り込んで受信することができ、緊急データを即座にユーザに伝えることが可能となる。
【０１０７】
また、受信端末５は、緊急データの割り込みを受けた場合、これまでに受信したコンテンツデータの断片を破棄する必要がない。また、受信端末５は、緊急データを復元した後に、これまでに受信したコンテンツデータの断片と、後続するフラグメント化フレームのペイロードに含まれるコンテンツデータの断片とを連結し、元のコンテンツデータを復元することができる。したがって、プッシュ配信サーバ４においてコンテンツデータを再送する等の処理が不要になり、受信端末５においても再送されたフラグメント化フレームの受信処理が不要になり、データの伝送効率が向上する。また、ＷｅｂＳｏｃｋｅｔプロトコルを用いて緊急データの割り込み受信を実現するから、ＷｅｂＳｏｃｋｅｔプロトコルを実装する既存のシステムを使用することができる。
【０１０８】
本発明の実施形態による受信端末５は、受信したフラグメント化フレーム毎に、カプセル化データのヘッダ情報であるＴａｇ及びｈｃｏｄｅ並びにトレイラ情報であるｔｃｏｄｅを抽出または設定し、フラグメント化フレームからコンテンツデータの断片を抽出してコンテンツデータ記憶手段３３に格納するようにした。この受信処理は、カプセル化データを生成することなく、フラグメント化フレームからコンテンツデータの断片を直接抽出し、コンテンツデータを復元するものである。これに対し、受信したフラグメント化フレームからカプセル化データを生成し、カプセル化データからコンテンツデータを復元するようにしてもよい。
【０１０９】
具体的には、本発明による他の実施形態の受信端末５は、受信したフラグメント化フレームをバッファに格納し、フラグメント化フレームのヘッダに格納されたＦＩＮが１であることを判定した場合、それまでにバッファに格納したフラグメント化フレームからカプセル化データの断片データを抽出し、断片データを結合してカプセル化データを生成し、カプセル化データからコンテンツデータを抽出してＴａｇと対応付けてコンテンツデータ記憶手段３３に格納する。これにより、コンテンツデータが復元される。
【０１１０】
また、他の実施形態による受信端末５は、中断フレームを受信した場合には、中断フレームのヘッダに格納されたＦＩＮが１であることを判定し、それまでにバッファに格納したフラグメント化フレームからカプセル化データの断片データを抽出し、前述と同様の処理にて、断片データを結合して途中のカプセル化データを生成し、途中のカプセル化データから断片を抽出してＴａｇと対応付けてコンテンツデータ記憶手段３３に格納する。そして、受信端末５は、再開フレームを受信した場合、後続するフラグメント化フレームを受信してＦＩＮが１であることを判定した場合、それまでにバッファに格納したフラグメント化フレームからカプセル化データの断片データを抽出し、前述と同様の処理にて、断片データを結合して途中のカプセル化データを生成し、途中のカプセル化データから断片を抽出してＴａｇと対応付けてコンテンツデータ記憶手段３３に格納する。これにより、コンテンツデータが復元される。
【０１１１】
このように、本発明による他の実施形態による受信端末５によれば、フラグメント化フレーム毎に、カプセル化データのヘッダ情報であるＴａｇ及びｈｃｏｄｅ並びにトレイラ情報であるｔｃｏｄｅを抽出または設定する処理が不要になるから、処理負担を軽減することができる。
【０１１２】
尚、本発明の実施形態によるプッシュ配信サーバ４のハードウェア構成、並びに本発明の実施形態及び他の実施形態による受信端末５のハードウェア構成としては、通常のコンピュータをそれぞれ使用することができる。プッシュ配信サーバ４及び受信端末５は、ＣＰＵ、ＲＡＭ等の揮発性の記憶媒体、ＲＯＭ等の不揮発性の記憶媒体、及びインターフェース等を備えたコンピュータによってそれぞれ構成される。プッシュ配信サーバ４に備えたセッション制御手段１０、コンテンツデータ入力手段１１、緊急データ入力手段１２、タグ管理手段１３、フラグメント生成手段１４、フラグメントバッファ１５、緊急データフラグメント生成手段１６、緊急データフラグメントバッファ１７、フラグメント多重化手段１８、パケット送信手段１９、通信Ｉ／Ｆ２０，２１の各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。また、受信端末５に備えた接続制御手段３０、パケット受信手段３１、フラグメント復元手段３２、コンテンツデータ記憶手段３３、デコーダ３４、提示部３５及び通信Ｉ／Ｆ３６の各機能も、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。これらのプログラムは、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記憶媒体に格納して頒布することもでき、ネットワークを介して送受信することもできる。
【０１１３】
以上、実施形態を挙げて本発明を説明したが、本発明は前記実施形態に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。前記実施形態では、データを送信しているときに、緊急データを割り込んで送信する場合について説明したが、本発明は、データを送信しているときに、緊急データではない他のデータを割り込んで送信する場合、または複数の異なるデータを並列に送信する場合にも適用がある。
【符号の説明】
【０１１４】
１  コンテンツ配信システム
２  コンテンツサーバ
３  緊急データサーバ
４  プッシュ配信サーバ
５  受信端末
６  コンテンツ中継ネットワーク
７  インターネット
１０  セッション制御手段
１１  コンテンツデータ入力手段
１２  緊急データ入力手段
１３  タグ管理手段
１４  フラグメント生成手段
１５  フラグメントバッファ
１６  緊急データフラグメント生成手段
１７  緊急データフラグメントバッファ
１８  フラグメント多重化手段
１９  パケット送信手段
２０，２１，３６  通信Ｉ／Ｆ
３０  接続制御手段
３１  パケット受信手段
３２  フラグメント復元手段
３３  コンテンツデータ記憶手段
３４  デコーダ
３５  提示部
【図１】
2014235453.tif 000003
【図２】
2014235453.tif 000004
【図３】
2014235453.tif 000005
【図４】
2014235453.tif 000006
【図５】
2014235453.tif 000007
【図６】
2014235453.tif 000008
【図７】
2014235453.tif 000009
【図８】
2014235453.tif 000010
【図９】
2014235453.tif 000011
【図１０】
2014235453.tif 000012
【図１１】
2014235453.tif 000013
【図１２】
2014235453.tif 000014
【図１３】
2014235453.tif 000015