JP2010503257A - データネットワーク上においてデータファイルを伝送する方法及びシステム - Google Patents

Abstract

一形態において、本発明は、データネットワーク上における伝送のためにデータファイルを変更する方法を提供する。方法は、オリジナルのデータファイルを受信するステップと、ヘッダファイルを生成するステップとを有し、ヘッダファイルは、オリジナルのデータファイルのバイトを単位とした長さを含む。オリジナルのデータファイル内で少なくとも１つの反復バイトのシーケンスを識別し、反復バイトのシーケンスは、反復バイトのシーケンス内において連続的に反復されるバイト値を有する。反復バイトのシーケンスを、反復マーカー、反復されるバイト値、及び反復されるバイト値が反復バイトのシーケンス内において発生する回数を表す反復頻度値によって置換することにより、変更されたデータファイルを生成する。更に、反復マーカーをヘッダファイルに追加する。本発明は、データネットワーク上でデータファイルをリモート装置に伝送する方法を更に提供する。

Description

本発明は、データネットワーク上においてリモート装置に対してデータファイルを伝送する方法に関する。更に詳しくは、但し、限定を伴うことなしに、本発明は、オーディオデータファイル及び／又はビデオデータファイルをストリーミング（ｓｔｒｅａｍｉｎｇ）する方法に関するものである。

電子バイナリファイルは、多くの様々な使用法のための多くの種々のフォーマットにおいて存在する。これらのフォーマットは、画像、音声、テキスト、データ、実行可能ファイル等の保存に適したフォーマットを含む。

電子バイナリオーディオファイル及びビデオファイルは、何種類かの異なるデータフォーマットにおいて入手可能である。これらのデータフォーマットの中のいくつかは、ＷＡＶ及びＡＶＩ等の可逆圧縮（ｌｏｓｓｌｅｓｓ ｃｏｍｐｒｅｓｓｉｏｎ）を使用している。非可逆圧縮（ｌｏｓｓｙ ｃｏｍｐｒｅｓｓｉｏｎ）を使用するようなその他のデータフォーマットは、ＭＰ２、ＭＰ３、及びその他のものを含む。

これらのデータフォーマットは、パーソナルコンピュータ、携帯型装置、及びその他のハードウェア等のリモート装置上における再生に適している。インターネット又はその他のネットワーク上においてデータファイルを伝送し、後の時点又は日付においてアクセスし、保存し、又は再生することが可能である。これらのデータフォーマットの中のいくつかは、データファイルの一部をリモート装置上において再生又はアクセスしつつ、データファイルの残りの部分又は少なくとも更なる一部をリモート装置に伝送することを実現する方式において伝送されることが可能である。このような後者の伝送方法をストリーミングと呼んでいる。

従来、オーディオ又はビデオのストリーミングに使用される電子バイナリファイルは、高レベルの非可逆圧縮を使用し、データネットワーク上において伝送されるファイルのサイズを低減させている。この高レベルの非可逆圧縮は、供給されるオーディオ又はビデオの品質の大幅な低下をもたらす。ビデオの場合には、例えば再生画面が小さい携帯型装置上においては、品質の低下は明らかではない。これらの小さな再生画面上において再生するために伝送を必要とするデータ量は相対的に小さい。

したがって、本発明の目的は、バイナリオーディオファイル及びビデオファイルを含むデータファイルをストリーミングするための改良された方法もしくは代替の方法を提供するか、又は上記問題点に対処するための少なくとも有用な選択肢を社会に提供することにある。

一形態において、本発明は、データネットワーク上における伝送のためにデータファイルを変更する方法を有する。この方法は、オリジナルのデータファイルを受信するステップと、ヘッダファイルを生成するステップとを有し、このヘッダファイルは、オリジナルのデータファイルのバイトを単位とした長さを含む。オリジナルのデータファイル内において少なくとも１つの反復バイトのシーケンスを識別する。反復バイトのシーケンスは、反復バイトのシーケンス内において連続的に反復されるバイト値を有する。反復バイトのシーケンスを、反復マーカー、反復されるバイト値、及び、反復されるバイト値が反復バイトのシーケンス内において発生する回数を表す反復頻度値によって置換することにより、変更されたデータファイルを生成する。更に、反復マーカーをヘッダファイルに追加する。

別の形態において、本発明は、データネットワーク上においてデータファイルをリモート装置に伝送する方法を有する。データファイルは、複数の順序付けされたデータセグメントと、ヘッダファイルとを有し、このヘッダファイルは、データファイル内のセグメントの数を表すセグメント頻度値を含む。この方法は、ヘッダファイルをデータネットワーク上においてリモート装置に伝送するステップを有する。第１実行スレッドの要求により、複数の順序付けされたデータセグメントの中の第１データセグメントをデータネットワーク上においてリモート装置に伝送し、且つ、カウンタ値の値を増加させる。これと同時に、第２実行スレッドの要求により、複数の順序付けされたデータセグメントの中の第２データセグメントをデータネットワーク上においてリモート装置に伝送し、且つ、カウンタ値の値を増加させる。第１及び第２実行スレッドの要求により、後続の交互に伝送されるべきデータセグメントをデータネットワーク上においてリモート装置に伝送し、且つ、後続のデータセグメントの全てのもの又はいくつかのものを伝送した後に、カウンタ値の値を増加させる。

本明細書及び本特許請求の範囲の請求項において使用される「〜を有すること（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、「〜から少なくとも部分的に構成される」ということを意味している。即ち、「〜を有すること（ｃｏｍｐｒｉｓｉｎｇ）」を含む本明細書及び本特許請求の範囲の請求項の記述内容を解釈する際には、（それぞれの記述内容において、この用語によって言及されたもの以外の）特徴も存在することが可能である。「〜を有する（ｃｏｍｐｒｉｓｅ）」及び「〜を含む（ｃｏｍｐｒｉｓｅｄ）」等の関係する用語も、同様に解釈されたい。

又、本発明は、広義には、個別又は集合的に、本出願の本明細書において参照された又は示された部品、要素、及び特徴と、これらの部品、要素、又は特徴の任意の複数のもののいずれかの組み合わせ又は全ての組み合わせにあると解釈されることが可能であり、且つ、本発明が関係する技術分野において既知の均等物を有する特定の完全体が本明細書において言及されている場合には、そのような既知の均等物も、個別に記述されているかのように本明細書に包含されるものと見なされるべきである。

以下、〔図面の簡単な説明〕の欄に記述された添付図面を参照し、データネットワーク上においてデータファイルを伝送する方法及びシステムの好適な実施形態について説明することとする。

本発明に係る方法が実行される１つの好適なシステムを示すブロック図である。 データファイルを変更する方法を示すフローチャートである。 変更されたデータファイルを伝送する方法を示すフローチャートである。 好適なフォームヘッダファイルを示す図である。 １つの好適なフォームデータ圧縮法を示すフローチャートである。 更なる好適なフォームデータ圧縮法を示すフローチャートである。 別の更なる好適なフォームデータ圧縮法を示すフローチャートである。

図１は、ネットワーク上におけるデータファイルの伝送に適した１つの好適なフォームシステム（ｆｏｒｍ ｓｙｓｔｅｍ）１００を示している。代表的なデータファイル１０５は、バイナリオーディオファイル及び／又はビデオファイルであってよい。データファイル１０５は、ＷＡＶ、ＡＶＩ、ＭＰ２、ＭＰ３、ＡＣ３、ＭＰ４、Ｈ２６４、Ｘｖｉｄ、ＤｉｖＸ、ＷＭＡ、ＷＭＶ、ＭＯＶ、ＶＯＢ、ＰＰＴ、ＰＰＳ、ＤＯＣ、ＸＬＳ、ＤＯＣ、ＺＩＰ、ＲＡＲ、ＰＰＭ等を含む任意のバイナリフォーマットにおけるものであってよい。データファイル１０５は、通常、演算装置１１５の一部を形成しているか又は当該演算装置１１５に少なくともインターフェイスで接続された二次記憶装置１１０内に保存される。演算装置１１５は、ダイレクトアクセスメモリ１２５及びディスプレイ１３０にインターフェイスで接続されたプロセッサ１２０を少なくとも含む。演算装置は、例えば、データエントリ装置（図示されてはいない）及び出力装置（図示されてはいない）等のその他のコンポーネントを含むか又はこれらのコンポーネントにインターフェイスで接続されることが可能であることを理解されたい。

後述する内容は、データファイル１０５を変更し、変更又は出力されたデータファイル１３５を生成するための１つの手法である。以下、１つ又は複数のデータネットワーク１５０上における伝送の前に、オリジナルのデータファイル１０５を変更する手法について説明する。データネットワーク１５０は、インターネット及び任意のその他の適切なネットワークファイル伝送構造又はネットワークファイル伝送プロセスを含む。出力されたデータファイル１３５は、データネットワーク１５０上においてリモート装置１６０に伝送される。

リモート装置１６０は、パーソナルコンピュータ、携帯型装置、又は、その画面上でオーディオファイル及び／又はビデオファイルをユーザーに対して表示することが可能であるような任意のその他の適切なハードウェアを含む。リモート装置１６０は、通常、例えば、ウィンドウズ（登録商標）・メディア・プレーヤー（Ｗｉｎｄｏｗｓ（登録商標） Ｍｅｄｉａ Ｐｌａｙｅｒ）、リアル・プレーヤー（Ｒｅａｌ Ｐｌａｙｅｒ）、ＶＬＣ等のビューアー（ｖｉｅｗｅｒ）コンポーネント１６５を含むか又はこれにインターフェイスで接続されている。ビューアーコンポーネント１６５により、リモート装置を操作するユーザーに対してバイナリオーディオデータファイル及びビデオデータファイルを再生することが可能である。

又、リモート装置１６０は、ストリーミングサーバー１７０をも含む。或いは、この代わりに、ストリーミングサーバー１７０は、リモート装置１６０とは離れた場所に配置されるが、このリモート装置１６０に関連付けられている。ストリーミングサーバーの動作については、更に詳細に後述することとする。ストリーミングサーバー１７０により、出力データファイル１３５の一部又はセグメントを１つ又は複数のデータネットワーク１５０上において伝送することが可能であり、且つ、ビューアー１６５によってユーザーに表示するべくストリーミングサーバー１７０上にキャッシングすることが可能である。或いは、この代わりに、伝送されたデータファイルは、リモート装置１６０上に保存される。

システム１００は、ファイルモディファイア（ｆｉｌｅ ｍｏｄｉｆｉｅｒ）コンポーネント１８０を更に含む。ファイルモディファイアコンポーネント１８０については、更に後述する。このファイルモディファイアコンポーネント１８０は、コンピュータメモリ内に保持されたソフトウェアコンポーネントを含む。

一実施例においては、リモート装置１６０は、複数の実行スレッド１９０及びセグメントカウンタ１９５を含むか、又はこれらに関連付けられている。ｎの値は、少なくとも２になるものと予想される。各々の実行スレッドは、後述するように、新しいセグメントを処理するべく構成される。

図２は、ファイルモディファイア（即ち、ファイルモディファイアコンポーネント）１８０がデータファイル１０５を変更し、出力データファイル１３５を生成するための好適なフォーム方法（ｆｏｒｍ ｍｅｔｈｏｄ）２００を示している。このような変更は、データファイルがデータネットワーク１５０上において伝送されるか又は部分的に伝送される時点において実行可能である。或いは、この代わりに、変更プロセスは、予め実行され、二次記憶装置１１０内に保存される。二次記憶装置は、ハードドライブ、コンピュータキャッシュ、コンパクトディスク、ＤＶＤ等を含む。

後述する変更プロセスは、後述する代替方法の１つ又は複数のものとの関連において、又はこれらの代替方法を伴うことなしに、ビデオフォーマット又はオーディオフォーマットに対して適用可能である。ビデオフォーマットと同様に、その他のデータフォーマットも、上記変更プロセス又は当該データフォーマットの特性に固有の変更プロセスと共に動作可能であることを理解されたい。ファイルは、任意のタイプのネットワーク上におけるバイナリ情報の伝送に対応した任意のフォーマットにおけるものであってよい。

プロセス２００における第１のステップは、ファイルモディファイア１８０が、変更プロセスの適用対象であるオリジナルのデータファイル１０５を受信するか、又は、少なくともこのデータファイル１０５に対してアクセスするというものである（ステップ２０５）。

ファイルモディファイア１８０は、オリジナルのデータファイル１０５及び当該データファイル１０５に対して実施された任意の変更を記述するキー情報を含むことになるヘッダファイルを生成する（ステップ２１０）。適切なヘッダファイルフォーマットの例については、後述する。

バイトを単位としたオリジナルのデータファイルの長さ（ファイル長）をヘッダファイルに追加する（ステップ２１５）。

データファイル１０５をスキャンし、オリジナルのデータファイル内に発生していない最大で３つの一意の４バイトのバイトシーケンス又はバイトグループを識別する（ステップ２２０）。

データファイルがビデオファイルのタイプである場合には（ステップ２２５）、任意選択により、キーフレームポイントについてビデオファイルをスキャンする。キーフレームとは、ビデオデータファイルの圧縮において別のフレーム内の画像を参照することなしにエンコード処理がなされたフレームである。本出願におけるキーフレームは、イントラフレーム又はＩフレームとも呼ばれる。

Ｉフレームは、しばしば、先行するキーフレームから算出された１つ又は複数のインターフレームによって後続される。Ｉフレームは、それ自体を除いて、ピクチャを参照することなしにコーディングされたピクチャである。Ｉフレームをエンコーダによって生成してランダムのアクセスポイントを生成し、デコーダがそのピクチャの場所において最初からデコード処理を適切に開始することができるようにすることが可能である。又、Ｉフレームは、微分画像の細部（ｄｉｆｆｅｒｅｎｔｉａｔｉｎｇ ｉｍａｇｅ ｄｅｔａｉｌｓ）が有効なデータフレームの生成を妨げている場合にも、生成されることが可能である。Ｉフレームは、通常、その他のピクチャのタイプよりも、エンコード処理のために多くのビットを必要としている。

キーフレームを表す少なくともいくつかの、好ましくは、全てのバイナリデータを除去し（ステップ２３０）、且つ、一意の４バイトのバイトシーケンスの中の１つによって当該バイナリデータを置換する。

任意選択により、ビデオファイルをフレームについて更にスキャンする。Ｂフレームは、代表的なビデオ圧縮設計において見出される３つのピクチャのタイプの中の１つである。３つの主要なピクチャのタイプは、イントラピクチャ（Ｉｎｔｒａ ｐｉｃｔｕｒｅ）、予測ピクチャ（Ｐｒｅｄｉｃｔｅｄ ｐｉｃｔｕｒｅ）、及び双予測ピクチャ（Ｂｉ−ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ）と呼ばれている。イントラピクチャ、予測ピクチャ、及び双予測ピクチャは、いずれも、当技術分野において周知のビデオ圧縮設計のコンポーネントである。例えば、Ｉピクチャ、Ｂピクチャ、もしくはＰピクチャ、又はＩフレーム、Ｂフレーム、もしくはＰフレーム等の全てのフレーム情報を除去し（ステップ２３５）、且つ、各々の発生を一意の４バイトのバイトシーケンスの中の別のものによって置換する。

ビデオファイルのタイプ及びその他のファイルのタイプの場合には、全ての反復を除去する（ステップ２４０）。好適なフォームデータ変換は、ランレングスエンコーディング（ｒｕｎ ｌｅｎｇｔｈ ｅｎｃｏｄｉｎｇ）である。同一のバイト値が連続的に反復されるデータのシーケンスは、カウント値又は頻度値によって後続されるバイト値の単一の発生によって置換される。これらの反復バイトのシーケンスの少なくとも１つは、オリジナルのデータファイル内において識別される。

オリジナルのデータファイル内において発生しない一意の４バイトのバイトシーケンスの中の別のものを反復マーカーとして選択する。データファイル内に存在している際には、反復マーカーは、ランレングスエンコーディングが適用されたデータ値を意味している。

反復バイトのシーケンスを、反復マーカー、反復されるバイトの値、及び反復頻度値によって置換する。反復頻度値は、反復されるバイト値が反復バイトのシーケンス内において発生する回数を表している。通常、６〜２６０回にわたって連続的に反復される全ての値を除去し、且つ、６バイトストリングによって置換する。この６バイトストリングは、反復マーカー、反復されるバイト値、及び反復頻度値を含む。

反復マーカーとして機能する一意の４バイトのバイトシーケンスをヘッダファイルに書き込むことにより、ヘッダファイルを更新する。又、データファイルがビデオファイルのタイプである場合には、キーフレームポイント及びフレームをそれぞれ表すバイトシーケンスも、ヘッダファイルに書き込まれる。

ファイルのタイプがビデオファイル又はオーディオファイルのタイプである場合に（ステップ２４５）、この手法における１つの任意選択のステップは、ファイルをセグメント化するというものである（ステップ２５０）。ここでは、ファイルを一連の順序付けされたデータセグメントにセグメント化する。セグメントは、任意のサイズであってよいが、通常は、約５３４，２８８バイト〜１，５７２，８６４バイトである。セグメントは、それぞれ、同一サイズであってよく、最後のセグメントは、サイズが小さい。或いは、この代わりに、セグメントの各々は、サイズが異なっている。

一例においては、ファイルを１メガバイト（長さが１，０４８，５７６バイト）の等しいセグメントにセグメント化している。或いは、この代わりに、別の形態においては、１つのキーフレーム、いくつかのキーフレーム、又は１メガバイトのバイトシーケンスの後に出現する最初のキーフレームの前又は後において、ファイルをセグメント化している。キーフレームに基づいてファイルをセグメント化することにより、その他のビデオファイルからその他のセグメントを挿入することが可能である。データファイルを構成しているセグメントの数をヘッダファイル内に挿入することにより、ヘッダファイルを更新する。

別個のデータファイルとして保持された複数の別個のファイルセグメントが結果的に得られるように、データファイルをセグメント化することが可能であることを理解されたい。或いは、この代わりに、データファイルは、単一のデータファイルとして保持される。必要に応じて、データファイル内の異なるオフセットから読み取ることにより、個々のデータセグメントを生成する。

更なる任意選択のステップは、１つ又は複数のデータ変換法をセグメントの中のいくつか又は全部に適用するというものである。これらのデータ変換法の中のいくつかは、１つ又は複数のセグメントのデータ圧縮を含む（ステップ２５５）。

第１の好適なフォームデータ圧縮法においては、個々のセグメントをブロックに分割しており、各々のブロックは、２５６バイトを上回ってはいない。データ圧縮法については、図５を参照して更に後述する。これらのブロックは、個々のセグメントのサブシーケンスである。個々のブロックが１２８を上回る数の一意のバイト値を有する場合には、データ変換をブロックに適用し、ブロック内の一意のバイト値の頻度を、１２８個以下の一意の値、又は２５６個の一意の値に増大させる。データ変換は、１つ又は複数の変換データのセット又はマスクを、ブロック内の各々の値に対して複数回にわたって適用するステップを伴う。個々のブロックに対して適用されるべく、最大で６５，５３５個の異なる変換データのセットが利用可能であると想定される。

個別のブロック内において２５６個の一意の値が実現可能である場合には、関連するパーミュテーション（ｐｅｒｍｕｔａｔｉｏｎ）をデータファイルに書き戻す。これは、２１０．５バイトにおいて実現可能である。１２８個以下の一意のバイトが実現される場合には、このパーミュテーションは、２２４バイトにおいて書き戻される。

２５６個の一意の値、又は１２８個以下の一意の値が実現されない場合には、オーバーレイ又はマスク値をゼロ（０）又はヌル（ｎｕｌｌ）として書き込む。ゼロ又はヌルは、関連するバイナリ情報がデコード処理又は圧縮されたデータの解凍を必要としないことを意味している。

上記の圧縮法は、本発明者らによる「データ圧縮システム及び方法（Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ）」という名称の国際公開第２００５／０３９０５７号として公開された特許明細書に更に記述されており、この内容は、本特許明細書中で引用されることにより、本特許明細書に包含されている。

或いは、この代わりに、又はこれに加えて、第２の好適なフォームデータ圧縮法を１つ又は複数のセグメントに適用する。この第２のデータ圧縮法については、図６を参照して更に後述する。セグメント全体をスキャンし、且つ、各々のバイト値の発生の回数を保持する。次いで、置換を実行し、この場合には、最も多く反復されたバイト値を０のバイト値によって置換する。次の最も多く反復された値を１のバイト値によって置換し、以下、これを同様に継続し、最後に、最も少なく反復されたバイト値を２５５のバイト値によって置換する。この結果、セグメントは、最も頻繁な値が相対的に小さなバイト値になるように構造化されることになる。オリジナルのバイト値及び置換値のテーブルは、５１２バイトを必要とし、且つ、ヘッダファイルに追加される。

或いは、この代わりに、又はこれに加えて、第３の好適なフォームデータ圧縮法を適用する。これについては、図７を参照して更に説明する。この手法は、本発明者らによる「データ圧縮システム及び方法（Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ）」という名称の国際公開第２００５／０３９０５７号として公開された特許明細書の一変形である。１つのセグメントをバイトシーケンスのグループに分解することが可能である。予め定められた数の一意の値が各々のデータセグメント内において発生する時点まで、単一のデータ変換のセットを複数のセグメントの各々に対して反復的に適用する。

一例においては、ファイルを２５６バイトのバイトシーケンスに分解し、且つ、０、１、２、３、４、．．．、２５５のデータ変換を順番に各々のバイト値に対して適用している。このデータ変換は、前述の第２データ圧縮法と同様の方式において適用される。次いで、バイトシーケンスをスキャンし、且つ、バイト値の一意の数のカウントを実行する。この例においては、１６２個の一意の値が求められているが（１６２個の一意の値は、２５６バイトの全ての可能な構造の約７．９％において発生する）、この値は、変化可能である。１６２個の一意のバイト値がセグメント内において識別されない場合には、同一のデータ変換を同一のセグメントに対して再度適用し、且つ、このようなプロセスを反復する。１６２個の一意の値の識別が完了したら、変換マスクを適用した回数を記録する。変換マスクを適用した回数を記録する値は、インデックスファイル又はヘッダファイルに書き込まれることが可能であり、或いは、２５６個の変換済みのバイト値の開始点又は終了点に包含することも可能である。

この段階で、データシーケンスは、全ての可能なシーケンスサイズの組み合わせの既知のサブセットを含んでいる。このサブセットをバイト値変換として又はインデックス値として記録可能である。１６２個の一意の値の場合には、インデックスを生成するべく必要とされる値の数は、可能な２５６個の値の構造の合計数の約７．９％である。

バイトセグメントのサイズは、変化可能である。識別される一意の値の数は、変化可能である。セグメント内において識別された一意の値の数は、設定された数に固定されることも可能であり、その数以下であってもよく、又はその数以上であってもよい。

或いは、この代わりに、又はこれに加えて、前述の方法の任意の組み合わせを使用して変更された又は変更されなかったデータファイルの全体に可逆圧縮法を適用することも可能である（ステップ２６０）。

更なる追加のステップは、暗号化をファイル全体に適用するというものである（ステップ２６５）。或いは、この代わりに、個別の暗号化関数を個々のセグメントに適用することも可能であり、この場合には、ビデオファイル又はオーディオファイルが関係しており、且つ、そのファイルは、セグメント化されている。

前述の出力データファイルを生成するためのデータファイルの変更の後に、出力又は変更されたデータファイルをデータネットワーク１５０上においてリモート装置１６０に伝送する。図３は、変更されたデータファイルを伝送する好適なフォームプロセス（ｆｏｒｍ ｐｒｏｃｅｓｓ）３００を示している。

まず、ヘッダファイルを演算装置１１５からストリーミングサーバー１７０に伝送する（ステップ３０５）。ヘッダファイルは、前述のように、１つ又は複数の４バイト置換コード及び置換された値と、この図３の方法が使用されている場合には、ファイルが分割されたセグメントの数とを含む。又、ヘッダは、各々のセグメントのタイプ、オーバーレイマスキング情報、ストリーミング、閲覧、再生、又は使用開始の前のダウンロードに必要とされるセグメントの数、並びに、使用された圧縮法の任意の追加フォーム及びタイプをも包含することが可能である。

使用される場合には、ストリーミングサーバー１７０は、リモート装置１６０がデータネットワーク１５０上において利用可能である帯域幅又はダウンロード速度を判定する。利用可能な帯域幅をヘッダファイル内の関連情報と比較し、更なるセグメントをデータネットワーク１５０上において伝送しつつ、リモート装置１６０上においてセグメントの使用を可能にするためにダウンロードすることが必要なファイルのセグメントの数を判定する。

リモート装置１６０又はストリーミングサーバー１７０上においては、複数の個別の実行スレッドが稼働している。後述する方法においては、２つのスレッドをＴｈｒｅａｄＯｄｄ及びＴｈｒｅａｄＥｖｅｎと呼んでいる。ＴｈｒｅａｄＯｄｄは、奇数の番号を有するセグメントのダウンロードを処理し、ＴｈｒｅａｄＥｖｅｎは、偶数の番号を有するセグメントのダウンロードを処理する。

ＴｈｒｅａｄＯｄｄ及びＴｈｒｅａｄＥｖｅｎは、主として、後述する方法において奇数及び偶数のセグメントをダウンロードするべく設計されている。但し、いくつかのケースにおいては、ＴｈｒｅａｄＯｄｄは、偶数の番号を有するセグメントをダウンロードし、且つ、ＴｈｒｅａｄＥｖｅｎは、奇数の番号を有するセグメントをダウンロードすることになる。

特定のセグメントがダウンロードを終了した際に、ＴｈｅａｄＯｄｄ又はＴｈｒｅａｄＥｖｅｎである制御スレッドは、次のセグメントのダウンロードを許容する。ＴｈｒｅａｄＯｄｄ及びＴｈｒｅａｄＥｖｅｎという両方の実行スレッドは、同時に動作する。この結果、ネットワーク接続部を介してダウンロード可能なデータ量が増大する。

第１データセグメントをリモート装置１６０に伝送又はダウンロードする（ステップ３１０）。

セグメントが伝送された後に、セグメントカウンタの値を増加させる（ステップ３１５）。好適な形態においては、カウンタは、ちょうど１ではなく、順序付けされたデータセグメントのシーケンス内におけるセグメント番号だけ、増加する。カウンタをチェックし、バッファリングが完了して再生が可能である時期を判定する。

セグメントを異なる速度においてダウンロードすることは可能である。カウンタをセグメント番号だけ増加させることにより、例えば、セグメント１、２、３、及び５がビューアーにダウンロード及び送信されることを防止している。カウンタが増加するのに伴って、セグメントを順序どおりにソートする（ステップ３２０）。

ステップ３１０及び３１５は、奇数の番号を有するセグメントをダウンロードするＴｈｒｅａｄＯｄｄを表している。又、偶数の番号を有するセグメントをダウンロードするＴｈｒｅａｄＥｖｅｎも同時に稼働している。ＴｈｒｅａｄＥｖｅｎは、セグメントをダウンロードし３２５、且つ、カウンタをセグメント番号だけ増加させている（ステップ３３０）。

十分な数のセグメントのダウンロードが完了することにより（ステップ３３５）、十分なバッファが確立される。デコード処理及び／又は暗号解読（ステップ３４５）、或いは、ユーザーによる閲覧、再生、又は使用のために（ステップ３５０）、ソートされたダウンロード済みのセグメントをビューアー１６５に伝達する（ステップ３４０）。

ストリーミング、再生、閲覧、又は使用が開始されたら、第１データセグメントをメモリのアレイ内に読み込む。メモリ内において、ヘッダファイルが示しているように、ファイルをデコード／暗号解読する。実際には、デコード処理及び暗号解読は、図２を参照しつつ前述したような圧縮及びインデックス付与（ｉｎｄｅｘｉｎｇ）のための変更の逆転である。このプロセスは、各々のセグメントに適用される。ファイルは、好ましくは、エンコード処理がなされた状態又は暗号化された状態において、ストリーミングサーバー１７０及び／又はリモート装置１６０に関連付けられた記憶装置内に保存される。これらのファイルがネイティブフォーマット（ｎａｔｉｖｅ ｆｏｒｍａｔ）において存在するのは、ランダムアクセスメモリ内においてのみである。

上記プロセスは、低品質又は低ビットレートのビデオファイル用の追加のステップを包含することが可能である。このステップは、フレームグラビング・ソフトウェア（ｆｒａｍｅ ｇｒａｂｂｉｎｇ ｓｏｆｔｗａｒｅ）を介したビデオの再生を伴い、この場合には、各々のフレームを、オリジナルのビデオファイルと同一のフレーム／秒のレートにおいてｊｐｇファイルのタイプ又はｂｍｐファイルのタイプに複写する。各々のフレームは、再生のためにビューアーに伝達される前に、画像クリーンアップアルゴリズムに伝達される。

画像クリーンアップアルゴリズムは、いくつかのピクセルに跨って色の広がり（ｃｏｌｏｕｒ ｓｐｒｅａｄ）を平均化し、且つ、通常は低品質の画像に関連するピクシレーション（ｐｉｘｉｌａｔｉｏｎ）を除去する。この場合にも、このステップは、ストリーミングサーバー１７０又はリモート装置１６０内のメモリ内において実行される。

ストリーミングサーバーは、リモート装置１６０上におけるソフトウェア駆動型の仮想サーバーである。ローカルのストリーミングサーバー１７０は、非標準ポートを介して接続されたウェブサーバーである。ポートは、プログラムが読み込まれる際に判定され、且つ、オペレーティングシステム環境内における競合を防止するべく、必要に応じて、プログラムによって調節可能である。ビデオが選択され、且つ、バッファ要件が満足された後に、再生ウィンドウがローカルのストリーミングサーバーに対して要求を行うと、ネイティブフォーマットメディアがローカルのストリーミングサーバーに対して提示される。

コンテンツに対する要求が到来すると、ローカルのストリーミングサーバーは、必要とされているセグメントの全体、このケースにおいては、セグメント１のダウンロードが完了していることを確認するべくチェックする。このセグメントのダウンロードが完了している場合には、このセグメントが、再生のためにビューアー１６５に供給される。セグメントが供給されたら、ストリーミングスレッドは、次のセグメントが、ダウンロードのための準備が整っており、且つ、供給のために準備された状態にあることをチェックし、次いで、このセグメントをローカルのストリーミングサーバーに供給する。

このような手順は、全てのセグメントがローカルのストリーミングサーバーに供給される時点まで、供給プロセスの全体を通じて継続される。セグメントは、ローカルのストリーミングサーバーへの供給が完了したら、削除可能であるが、この動作は、ローカルの要件に応じて変更可能である。

必要とされているセグメントの供給の準備が整っていないとローカルのストリーミングサーバーが判定した場合には、再生ウィンドウとの間の接続は維持されるが、データは送信されない。このようなイベントは、ユーザーには、再生における休止として現れる。この場合には、十分なメディアの供給プロセスの準備が整う時点まで、バッファリングを実現しつつ、ビューアーがその他のストリーミング供給を受信するように、追加のコンテンツ供給を実施することが可能である。十分なデータのストリーミングの準備が完了したら、再生を再開する。データは、ビューアーが受信可能であるのと同程度に迅速にビューアーに供給されることから、ビューアーがバッファリングするべく選択するデータ量は、ローカルのストリーミングサーバーとは無関係である。ビューアーは、データがその時点において正常に供給されているかのように動作する。

前述のプロセスは、短い初期のバッファリング期間を伴って、ＤＶＤに近い品質のビデオを、１メガバイト又は１２８キロバイトの接続部にて供給する潜在力を有している。このバッファリング期間は、ビデオの初期の期間に必要とされるデータ量に応じて変化する。約９２キロバイト／秒においてダウンロードされた映画の開始時点に多数のシーンの変化を伴う１５０分の映画の場合には、再生が開始される前に、９０秒のバッファリング期間が存在する。

図４は、前述のファイルの変更の後の好適なフォームヘッダファイルを示している。好適なフォームヘッダファイル４００は、ファイル長の値４０５を含む。ファイル長の値は、図２のステップ２１５を参照して前述したように、ヘッダファイルに追加されたオリジナルのデータファイルのバイトを単位とした長さを表している。

キーフレームマーカー４１０は、キーフレームを識別する３つの一意の４バイトのバイトシーケンスの中の１つである。フレームマーカー４１５は、例えば、Ｉピクチャ、Ｂピクチャ、もしくはＰピクチャ、又はＩフレーム、Ｂフレーム、もしくはＰフレーム等のフレーム情報を識別する第２の一意の４バイトのバイトシーケンスである。反復マーカー４２０は、反復マーカーの直後のデータのランレングスエンコーディングを通知する第３の一意の４バイトのバイトシーケンスである。

データファイルがセグメント化されている場合には、セグメントの合計数がセグメント合計４２５として表される。

データ変換が個別のセグメント又はデータファイルに適用されている場合には、ヘッダファイルは、更なるデータ値を含むことになる。これらのデータ値は、変換データのセットの識別子４３０を含む。上記のデータ値は、前述の第１データ圧縮法に関係している。この手法においては、識別子４３０は、データに適用された変換データのセットを一意に識別している。

バイト置換が前述の第２の好適なフォームデータ圧縮法に従って実行されている場合には、ヘッダファイルは、バイト置換テーブル４３５を含むことになる。バイト置換テーブルは、長さが約５１２バイトになるものと想定される。これは、最も多く反復されたバイト値、第２の最も多く反復されたバイト値、そして、以下同様に継続し、最も少なく反復されたバイト値までを含むことになる。

第３実行データ圧縮法が適用されている場合には、ヘッダファイルは、データファイルに適用されたデータ変換の数４４０を更に含むことになる。

図５は、個別のセグメント又はデータファイルに適用される１つの好適なフォームデータ圧縮法を示している。好適なフォーム手法（ｆｏｒｍ ｔｅｃｈｎｉｑｕｅ）５００は、まず、オリジナルファイルを受信するか又はこれにアクセスする（ステップ５０５）。ファイルを個別のバイトグループにセグメント化する（ステップ５１０）。好ましくは、各々のバイトグループは、２５６バイトを上回っていない。

各々のセグメント（セグメント「ｎ」）を順番にチェックする（ステップ５１５）。個別のセグメントをチェックし、一意のバイト値の数を識別する（ステップ５２０）。

セグメント内に１２８を上回る数の一意のバイト値が存在し（ステップ５２５）、且つ、更には、２５６を下回る数の一意のバイト値が存在する場合には（ステップ５３０）、変換を適用し、ブロック内の一意のバイト値の頻度を増大させる（ステップ５３５）。前述のように、適切なデータ変換は、１つ又は複数の変換データのセット又はマスクをブロック内の各々の値に対して複数回にわたって適用するステップを伴う。個別のブロックに適用するべく、最大で６５，５３５個の異なる変換セットが利用可能であると想定される。この結果、変換の後に、出力データファイル内に２５６個の一意のバイト値が存在する場合には（ステップ５４０）、最初のビット値を１に設定する（ステップ５４５）。出力ファイル内の次のビット値も１に設定する。第２ビット値は、出力データファイル内に２５６個の一意のバイト値が存在することを識別している。次いで、変換識別子を出力データファイルに追加する（ステップ５５０）。変換識別子は、長さが約２バイトになると予想される。

２５６個の一意の値が個別のブロック内において実現可能である場合には、関連するパーミュテーションをデータファイルに書き戻すか又は追加する（ステップ５５５）。このパーミュテーションは、長さが約２１０．５バイトになると予想される。

合計で２１２．７５バイトが、２５６バイトのバイトシーケンスを置換すると予想される（ステップ５６０）。

変換を適用するステップ５３５を適用した後に、２５６個の一意のバイト値が存在していない場合には、ステップ５６５に示されているように、出力データファイルの最初のビット値を０（ゼロ）に設定する。次いで、オリジナルの２５６バイトをデータファイルに追加する。

一意のバイト値の数を識別するステップ５２０の後に、１２８未満の数の一意のバイト値が存在する場合には（ステップ５２５）、ステップ５６５に示されているように、出力データファイルの最初のビット値を１に設定する。１の直後のビット値は、その値が０であり、これは、１２８未満の数の一意の値が存在することを意味している。関連するパーミュテーションをデータファイルに追加するが（ステップ５７０）、このデータファイルは、長さが約２２４バイトになると予想される。この場合には、合計で２２４．２５バイトが、２５６バイトのバイトシーケンスを置換する（ステップ５７５）。

上記方法の適用の後に、ステップ５８０に示されているように、関連するバイトのバイトシーケンスを書き出す。次いで、次のセグメントを処理する（ステップ５１５）。

図６を参照すれば、第２データ圧縮法をセグメントの１つ又は複数のものに適用することが可能である。手法６００は、オリジナルのファイルを受信するか又はこれにアクセスする（ステップ６０５）。セグメント全体をスキャンし、且つ、各々のバイト値の発生の回数を保持する（ステップ６１０）。ステップ６１５に示されているように、最も頻繁に発生しているバイト値を０によって置換する。

ステップ６２０に示されているように、第２の最も頻繁に出現するバイト値を値「１」によって置換する。これは、ステップ６２５に示されているように、「Ｎ」番目の最も頻繁に発生するバイト値が、それぞれの値Ｎ−１によって個別に置換されるように、一般的なケースにおいて反復される。

ファイルを新しい値によって置換することにより、新しい出力ファイルを生成する（ステップ６３０）。

発生順序においてバイトのテーブルを生成し（ステップ６３５）、且つ、このテーブル又はリストをヘッダファイルに書き込む（ステップ６４０）。

図７は、図２を参照しつつ前述したような第３の好適なフォームデータ圧縮法を示している。手法７００の第１ステップは、オリジナルファイルを受信するか又はこれにアクセスするというものである（ステップ７０５）。ファイルを２５６バイトセグメントにセグメント化する（ステップ７１０）。前述のように、このセグメント化は、実際のものであるか又は仮想的なものである。

次のステップは、モジュロバイトのオフセット値を算出するというものである（ステップ７１５）。個々のセグメントがＮバイトを格納していると仮定すれば、新しいバイト値ｂ₁．．．ｂ_nは、次のように算出される。

ｂ_n＝ｂ_n＋（ｎ−１） ｍｏｄｕｌｏ ２５６

ここで、ｎは、１〜Ｎの範囲である。

この場合に、Ｎ＝２５６であり、第１バイト値には、０が追加され、第２バイト値には、１が追加され、そして、以下同様に継続し、最後に、２５６番目の値に、２５５が追加される。新しい値は、ｍｏｄｕｌｏ ２５６を使用することによって算出される。これは、新しく算出されたバイト値又はオフセットが２５５を超過できないことを保証している。

又、これは、様々なビット長にも適用可能である。前述のケースは、２５６の値を有する８ビット又は１バイトを包含することが可能である。この代わりに、ビット数は、７ビットであってもよく、この場合には、ｍｏｄｕｌｅ １２８が使用されることになるであろう。別の代替肢は、１０ビットであり、この場合には、ｍｏｄｕｌｅ １０２４が使用されることになるであろう。例えば、１８０バイト（８ビット）等の更に小さなバイトのセットを使用することも可能であろう。これらの値には、ｍｏｄｕｌｏ ２５６が使用されることになるが、ｎは、１〜１８０の範囲内のものになるであろう。

バイトシーケンスをスキャンし、且つ、一意のバイト値の数のカウントを実行する。予め定められた数の一意のバイト値が実現されている場合には（ステップ７２０）、０のビット値をインデックスファイルに書き込む。或いは、この代わりに、０の値をヘッダファイルに書き込む（ステップ７２５）。

次いで、一意のセグメント値の関連するパーミュテーションをファイルに書き込む（ステップ７３０）。

予め定められた数の一意の値が実現されず、且つ、Ｎが２５６以下である場合には、Ｎの値をバイト数Ｎに追加する（ステップ７１５）。或いは、この代わりに、Ｎが２５６を上回っている場合には、１のビット値をインデックスファイルに書き込み、オリジナルのバイト値をファイルに書き込む。或いは、この代わりに、０の値をヘッダファイルに書き込み、変更されたバイト値をファイルに書き込む。

以上、その好適な実施形態を含む本発明について説明した。当業者には明らかであるような変更及び改良も、添付の特許請求の範囲の請求項によって規定された本発明の範囲内に包含されるものと解釈されたい。

Claims (26)

1. データネットワーク上における伝送のためにデータファイルを変更する方法において、
   オリジナルのデータファイルを受信するステップと、
   ヘッダファイルを生成するステップであって、前記ヘッダファイルは、前記オリジナルのデータファイルのバイトを単位とした長さを含むステップと、
   前記オリジナルのデータファイル内において少なくとも１つの反復バイトのシーケンスを識別するステップであって、前記反復バイトのシーケンスは、前記反復バイトのシーケンス内において連続的に反復されるバイト値を有するステップと、
   前記反復バイトのシーケンスを、反復マーカー、前記反復されるバイト値、及び、前記反復されるバイト値が前記反復バイトのシーケンス内において発生する回数を表す反復頻度値によって置換することにより、変更されたデータファイルを生成するステップと、
   前記反復マーカーを前記ヘッダファイルに追加するステップとを有することを特徴とする方法。
2. 前記反復マーカーは、前記オリジナルのデータファイル内において発生しない４バイトのシーケンスを有する請求項１記載の方法。
3. 前記反復頻度値は、バイト値を有する請求項２記載の方法。
4. 前記反復バイトのシーケンスは、２６０バイトの最大長を有する請求項３記載の方法。
5. 前記反復バイトのシーケンスは、６バイトの最小長を有する請求項３記載の方法。
6. 前記オリジナルのデータファイル内における個々のバイト値の発生の数を表す複数のバイト頻度値を算出するステップと、
   前記オリジナルのデータファイル内のバイト値を、前記バイト頻度値に少なくとも部分的に基づいて選択された置換値によって置換するステップとを更に有する請求項１から５のいずれか一項に記載の方法。
7. 相対的に大きなバイト頻度値を有するバイトのために相対的に小さな置換値を選択するステップを更に有する請求項６記載の方法。
8. ｎ番目の最も頻繁に発生するバイト値を値ｎ−１によって置換するステップを更に有する請求項７記載の方法。
9. 置換されたバイトを前記ヘッダファイルに追加するステップを更に有する請求項６から８のいずれか一項に記載の方法。
10. 前記オリジナルのデータファイル内における頻度が減少する順序で前記置換されたバイトを前記ヘッダファイルに追加するステップを更に有する請求項９記載の方法。
11. ａ）前記オリジナルのデータファイル内における個々のバイトのバイトオフセット値を算出するステップと、
    ｂ）前記バイトオフセット値に少なくとも部分的に基づいて前記オリジナルのデータファイル内のバイトにデータ変換を適用するステップと、
    ｃ）前記データ変換がなされた前記データファイル内の一意のバイト値の数を算出するステップと、
    ｄ）前記算出された数を予め定められた閾値と比較するステップと、
    ｅ）前記算出された数が前記予め定められた閾値未満である場合に、前記のステップａ）〜ステップｄ）を反復するステップとを更に有する請求項１から１０のいずれか一項に記載の方法。
12. 前記データ変換は、ｂ_n＝ｂ_n＋（ｎ−１） ｍｏｄｕｌｅ ｘを有する請求項１１記載の方法。
13. ｘ＝２５６である請求項１２記載の方法。
14. ｎは、１〜２５６の範囲内である請求項１２又は１３記載の方法。
15. データネットワーク上においてデータファイルをリモート装置に伝送する方法であって、前記データファイルは、複数の順序付けされたデータセグメントと、ヘッダファイルとを有し、前記ヘッダファイルは、前記データファイル内における前記セグメントの数を表すセグメント頻度値及び／又は圧縮されたデータの解凍に必要なその他の値を含み、前記方法は、
    前記データネットワーク上において前記ヘッダファイルを前記リモート装置に伝送するステップと、
    第２のデータセグメント又は後続のデータセグメントと同時に、第１実行スレッドの要求により、前記データネットワーク上において前記複数の順序付けされたデータセグメントの中の第１データセグメントを前記リモート装置に伝送するステップと、
    カウンタ値の値を増加させるステップと、
    前記第１のデータセグメント又は更なるデータセグメントと同時に、第２実行スレッドの要求により、前記データネットワーク上において前記複数の順序付けされたデータセグメントの中の第２データセグメントを前記リモート装置に伝送するステップと、
    前記カウンタ値の値を増加させるステップと、
    前記第１及び第２実行スレッドの要求により、同時に、後続の交互に伝送されるべきデータセグメントを前記データネットワーク上において前記リモート装置に伝送するステップと、
    前記後続のデータセグメントの全てのもの又はいくつかのものを伝送した後に、前記カウンタ値の値を増加させるステップとを有することを特徴とする方法。
16. 前記順序付けされたデータセグメントは、関連付けられた個別の序数値を有する請求項１５記載の方法。
17. 前記カウンタ値は、前記データネットワーク上においてごく最近伝送された前記データセグメントに関連付けられた前記序数値だけ増加する請求項１６記載の方法。
18. 前記ヘッダファイルは、バッファ数を含み、前記バッファ数は、セグメントの閾値数を表す請求項１７記載の方法。
19. 前記データファイルは、ビデオデータファイルを表す請求項１８記載の方法。
20. 前記データネットワーク上において前記ビデオデータファイルの更なるセグメントを伝送しつつ、前記リモート装置上において前記ビデオデータファイルの１つ又は複数のセグメントをユーザーに対して再生するステップを更に有する請求項１９記載の方法。
21. １つ又は複数のデータ変換を前記データファイル又はその一部に適用するステップを更に有する請求項１５記載の方法。
22. 前記１つ又は複数のデータ変換は、前記セグメントの中の１つ又は複数のものの少なくとも一部分内における一意のバイト値の数を増大させるデータ変換を含む請求項２１記載の方法。
23. 前記１つ又は複数のデータ変換は、データ圧縮法を含む請求項２１記載の方法。
24. 前記１つ又は複数のデータ変換は、暗号化法を含む請求項２１記載の方法。
25. データネットワーク上における伝送のためにデータファイルを変更するべく動作可能なデータ変更システムにおいて、
    前記データファイルを受信し、且つ、ヘッダファイルを生成するべく構成されるファイルモディファイアであって、前記ヘッダファイルは、前記オリジナルのデータファイルのバイトを単位とした長さを含むファイルモディファイアと、
    前記オリジナルのデータファイル内において少なくとも１つの反復バイトのシーケンスを識別するべく構成される反復コンポーネントであって、前記反復バイトのシーケンスは、前記反復バイトのシーケンス内において連続的に反復されるバイト値を有する反復コンポーネントとを備え、
    前記反復コンポーネントは、前記反復バイトのシーケンスを、反復マーカー、前記反復されるバイト値、及び、前記反復されるバイト値が前記反復バイトのシーケンス内において発生する回数を表す反復頻度値によって置換することにより、変更されたデータファイルを生成し、且つ、前記反復マーカーを前記ヘッダファイルに追加するべく更に構成されることを特徴とするデータ変更システム。
26. データネットワーク上においてデータファイルをリモート装置に伝送するべく動作可能なデータファイル伝送システムであって、前記データファイルは、複数の順序付けされたデータセグメントと、ヘッダファイルとを有し、前記ヘッダファイルは、前記データファイル内における前記セグメントの数を表すセグメント頻度値及び／又は圧縮されたデータの解凍のために必要なその他の値を含み、前記データファイル伝送システムは、
    前記データネットワーク上において前記ヘッダファイルを前記リモート装置に伝送し、
    第２のデータセグメント又は後続のデータセグメントと同時に、第１実行スレッドの要求により、前記データネットワーク上において前記複数の順序付けされたデータセグメントの中の第１データセグメントを前記リモート装置に伝送し、
    カウンタ値の値を増加させ、
    前記第１のデータセグメント又は更なるデータセグメントと同時に、第２実行スレッドの要求により、前記データネットワーク上において前記複数の順序付けされたデータセグメントの中の第２データセグメントを前記リモート装置に伝送し、
    前記カウンタ値の値を増加させ、
    前記第１及び第２実行スレッドの要求により、同時に、前記データネットワーク上において後続の交互に伝送されるべきデータセグメントを前記リモート装置に伝送し、且つ、
    前記後続のデータセグメントの全てのもの又はいくつかのものを伝送した後に、前記カウンタ値の値を増加させるべく構成されることを特徴とするデータファイル伝送システム。

Images