JP2006520039A - メディアデータストリームを処理するための方法、データ構造、及びシステム - Google Patents

Abstract

【課題】メディアストリーミング、特にメディアデータの圧縮、解凍、及び再生に関する技術を提供する。
【解決手段】メディアデータの圧縮、ストリーミング、及び再生のための方法、メディアデータ構造、及びシステム。メディアデータのフレームに対するデータ部分が比較され、類似データ部分は、圧縮メディアデータに一回保存される。メタデータ構造は、圧縮メディアデータ内の各類似データ部分をメディアデータ内のその適切なフレームにマップする。自己読込及び自己実行型のメディアプレイヤーが受信者に送信される。一実施形態では、メディアプレイヤーは、ネットワークデータ伝送速度を検出し、それに従って設定される。次に、メディアプレイヤーは、メタデータ構造及び圧縮メディアデータを要求し、メディアデータのフレームの受信、解凍、及び再生を自動的に開始する。

Description

本発明の実施形態は、一般的にメディアストリーミングに関し、より具体的にはメディアデータの圧縮、解凍、及び再生に関する。

ネットワーク上のメディアデータ（例えば、音声、映像、グラフィック、及び画像など）の送信は、今日の高度に結合及びワイヤ接続された経済ではありふれたことになっている。消費者及び組織は、メディアデータの受信及び再生時に大量のネットワーク帯域幅及び他のコンピュータリソースを消費している。その結果、メディアデータの取得及び再生時の帯域幅及びリソース消費の管理及び軽減のために様々な技術が試みられている。

例えば、メディアデータがネットワーク接続を通じて最初に利用可能にった時に、そのソリューションは、第一にネットワーク接続をＴ１、光ファイバ、ケーブル、「デジタル加入者線（ＤＳＬ）」、ブロードバンド、及びその他へアップグレードすることであった。このソリューションは、ネットワーク上のメディアデータの送信に関わる負荷を処理するために、より多くの帯域幅能力を有するハードウエア接続の方向に変えられた。しかし、データ伝送速度は、送信者及び受信者が共に高帯域幅ネットワーク接続を有する場合にのみ改善することができるものである。すなわち、伝送速度は、送信者−受信者関係における最小公倍数的な接続に関連している。

従って、ソリューションは、より高い帯域幅のネットワーク接続に加えて、ソフトウエアの方へより多くの焦点を当てるように進展した。このようなソリューションの１つにメディアストリーミングと呼ばれるものがある。この技術を用いることにより、送信者は、メディアデータをパケットへと分割し、ネットワーク上で個々のパケットを順次受信者へと送信する。受信者は、メディアデータが再生される前に付加的なストリーミングソフトウエアを用いて所定の量のメディアデータをバッファに入れる。メディアデータの再生が始まった状態で、受信者は、通常はメディアデータの連続した再生を体験するが、これは、受信者がある量のメディアデータを消費すると、バッファに入れられた量のデータが、まだ消費されていない新たなメディアデータによって置換されるためである。

より高い帯域幅のネットワーク接続及びストリーミング技術は、ネットワーク上のメディアデータの配信及び消費の好ましい方法であることに変わりはない。しかし、受信者がメディアデータを実際に消費することができる前に、受信者は、受信者のコンピュータ装置上にメディアプレイヤーをダウンロードしてインストールする必要がある。これらのメディアプレイヤーは、「ワールド・ワイド・ウェブ（ＷＷＷ）」ブラウザを通じてインターネット上で容易に入手可能である。いくつかの例には、マイクロソフト製「ウィンドウズ・メディア・プレイヤー」、アップル製「クイックタイム・メディア・プレイヤー」、リアル・ネットワーク製「リアル・プレイヤーズ」、及びその他が含まれる。

一般的に、市販のメディアプレイヤーの各々は、レジストレーションを要求し、場合によってはメディアプレイヤーをダウンロードするコンピュータ装置の再起動を要求することがある。一部のものは、実際に、恐らくより多くの機能及びオンラインサポートを伴うメディアプレイヤーの有料バージョンへのアップグレードを受信者へしつこく勧誘している。電子勧誘は、受信者がメディアプレイヤーを利用する度に表示されるポップアップ広告と同様に、受信者に対して迷惑になる可能性がある。更に、職場環境においては、個々の社員の各々が自分のコンピュータ上にフリーソフトウエア（フリーウエア）をダウンロードすることは、一般的に望ましくないものである。これは、フリーウエアはサポートされておらず、予期せぬ故障、又はメンテナンス、サポート、及びアップグレードのようなデスクトップ管理に関する他の問題を引き起こす可能性があるからである。

すなわち、メディアプレイヤーのダウンロード、インストール、及び使用は、時間を浪費し、禁止され（一部の環境において）、迷惑である可能性がある。それに加えて、インターネットユーザの多くの割合は、未だにインターネットへの標準ダイヤルアップ接続を有しており、高帯域幅機器及び／又はサービスプロバイダを有していない。従って、メディアデータが彼らのコンピュータ装置上でバッファに入れられて再生される前に長い開始待ち時間があるために、彼らのネットワーク接続は、メディアストリーミングを未だに困難で苛立たしい作業にしている。結果的に、多くのインターネットユーザは、全くメディアデータを消費しないという選択を行うのである。

この状況を緩和するために、送信者からストリーミングされる時にメディアデータを圧縮し、ユーザによってメディアデータが消費される時に解凍するという試みが為されてきた。しかし、従来的に入手可能な最良のメディア圧縮／解凍技術でも、低帯域幅インターネットユーザに関する問題を認めうるほどには解決していない。

従って、メディアプレイヤーを配信し、メディアデータを圧縮し、メディアデータを再生するための改良された手段及び技術に対する必要性が存在する。これらの手段及び技術は、低帯域幅インターネットのユーザが専用のメディアプレイヤーのインストールを必要とせずにより時間効率的にメディアデータを消費することを可能にすべきである。

本発明の様々な実施形態では、メディアデータを処理する技術が呈示される。メディアデータのためのメディアフレームは、データ部分として評価される。類似のデータ部分は、圧縮メディアデータに一回保存される。メタデータ構造は、圧縮メディアデータを元のメディアデータに関連する密集したメディアフレーム内へ解凍するためのマッピングを提供する。自己再生型及び自己実行型のメディアプレイヤーが、要求を行っている受信者へネットワーク上で送られる。メディアプレイヤーは、圧縮メディアデータを用いてメタデータ構造を設定して取得する。次に、メディアプレイヤーは、メタデータ構造及び圧縮メディアデータを用いて、受信者のためにメディアデータを解凍して再生する。

より具体的に、本発明の一実施形態では、メディアデータを処理する方法が説明される。メディアデータのメディアデータフレームに対するデータ部分が評価される。次に、類似のデータ部分は、圧縮メディアデータに対する単一のデータ部分として反復して保存される。メタデータ構造は、類似データ部分が関連するメディアデータフレームに対する、単一データ部分におけるデータ部分の各々の関連性を識別するために生成される。最終的に、メディアプレイヤー、メタデータ構造、及び圧縮メディアデータは、ネットワーク上でストリーミングされる。

メディアデータを処理するための革新的な方法、データ構造、及びシステムを説明する。以下の実施形態の詳細説明においては、本発明の一部を形成し、かつ実施することができる本発明の特定的な実施形態を限定的ではなく例示的に示す添付図を参照する。これらの実施形態は、当業者が理解し、その後実施することができる程十分に説明されるが、他の実施形態も利用可能であり、構造的、論理的、及び電気的変更を本開示の精神及び範囲から逸脱することなく行うことができるものとする。従って、以下の詳細説明は、限定する意味で捉えるべきではなく、本明細書に開示される本発明の実施形態の範囲は、特許請求の範囲のみによって規定されものである。

ここで使用されているように、「メディアデータ」という語句は、単に例示的に音声、映像、グラフィック、画像、テキスト、及びこれらの組合せのようなマルチメディアに関するデータを含む。ストリーミングは、メディアデータを設定可能なバイトチャンク、ブロック、又はフレームへ分解し、これらの部分を１人又はそれ以上の受信者のコンピュータ装置へネットワーク上で順次送信することを意味する。ネットワークは、配線されたものとすることができる（例えば、直接（２地点間）、間接（例えば、インターネットのような「ワイド・エリア・ネットワーク（ＷＡＮ）」）、及びその他）。ネットワークはまた、無線とすることもできる（例えば、赤外線、無線周波数（ＲＦ）、衛星、携帯電話、及びその他）。更に、ネットワークは、互いにインタフェースで接続された配線及び無線ネットワークの組合せとすることもできる。

送信者は、メディアデータ・コンテント・プロバイダである。これは、組織、政府、個人、又はこれらのエンティティの１つに代わって作用する自動アプリケーションとすることができる。受信者は、送信者と同様なエンティティとすることができるが、受信者は、メディアデータの消費者である。すなわち、実行されているトランザクション（例えば、送信又は消費）により、１つのトランザクションで送信者が受信者でもあり、また受信者が送信者でもあるように、送信者及び受信者の役割が入れ替わることができる。

メディアプレイヤーは、受信し、必要であれば解凍し、必要であれば暗号解読し、そして受信者のコンピュータ環境においてメディアデータを再生するように設計された１つ又はそれ以上のソフトウエアアプリケーションである。メディアプレイヤーは、本開示の教示に従って自動読込み、設定、及びメディアデータ処理を行うように設計されて修正された既存の入手可能な任意のメディアプレイヤー又はこれと同じことができるように設計されたカスタム開発メディアプレイヤーとすることができる。本発明の一実施形態では、メディアプレイヤーは、受信者のコンピュータ装置のアプリケーション（例えば、ＷＷＷブラウザ及びその他）内において手動の介入なしにダウンロードされ、読込まれ、及び実行されることが可能なＪＡＶＡアプレットである。

本発明の様々な実施形態によって処理される最初のメディアデータは、既存の任意のメディアデータフォーマットを取ることができる。従って、このフォーマットは、「ムービング・ピクチャー・エキスパート・グループ（ＭＰＥＧ）」フォーマット、「オーディオ・ビデオ・インターリーブド（ＡＶＩ）」フォーマット、及び「クイックタイム・ムービー・フォーマット（ＭＯＶ）」を取ることができる。また、メディアデータフォーマットは、検証の目的で暗号化することができ、又はそれ自身が圧縮フォーマットとすることもできる。

データ部分は、メディアデータフレームの各部分に付随する特性（例えば、色、寸法、及び解像度など）を参照する。メディアデータは、複数のフレームを含み、これらのフレームが正しい順番に継ぎ合わされ、アプリケーション内のメディアプレイヤーによって連続して再生された時、受信者は、メディアデータの完全かつ滑らかな再生を体験する。従って、メディアデータは多くのフレームを含み、個々のフレームは、データ特性を有する複数のデータ部分に分解することができる。

図１は、本発明の一実施形態によるメディアデータを処理する方法１００の流れ図である。方法１００は、コンピュータアクセス可能媒体上の１つ又はそれ以上のソフトウエアアプリケーションによって実行され、コンピュータ装置（例えば、処理及び記憶能力のある任意の装置）によって実行される。更に、送信者は、送信者のコンピュータ環境において方法１００を用い、ネットワーク上でメディアデータ及びメディアプレイヤーを受信者のコンピュータ装置へストリーミングする。次に、受信者は、メディアプレイヤーを用いてストリーミングされたメディアデータを消費する。

１０１において、メディアデータは、ネットワーク上で受信者に対して処理されるように受信又は識別される。上述のように、元来のメディアデータフォーマットは、任意のフォーマット（例えば、ＭＯＶ、ＡＶＩ、ＭＰＥＧ、カスタム開発型、及びその他）とすることができる。メディアデータフォーマットは、圧縮及び／又は暗号化することができる。
受信者からメディアデータを消費するという要求が受信されると、メディアデータは受信又は識別される。一部の実施形態では、自動化された処理が自動的に受信者へメディアデータをストリーミングする要求をトリガ又は生成するので、特定の要求が無くてもよい。

１０２では、メディアデータの個々のフレームがデータ部分毎に評価される。データ部分のサイズは、方法１００内で設定可能である。評価されたデータ部分は、メディアフレームに付随するデータ特性である。これらの特性は、単に例示的に色特性、寸法特性、解像度特性、及びその他を含む。評価時には、現在の処理データ部分に対して過去に処理されたデータ部分が比較され、類似データ部分（例えば、類似のデータ特性を有する）が判断される。データ部分は、それらが同一又はそれらのデータ特性が実質的に類似している場合に、類似していると判断することができる。実質的な類似とは何であるかは、後で受信者に対してメディアデータが再生される時にメディアデータに対する品質の高低をもたらすように方法１００内で設定することができる。

１０３において、メディアデータは、方法１００によって反復して処理され、メディアデータに関する個々のフレーム内に類似データ部分が見出される。類似データ部分が過去に処理されたデータ部分から検出される時に、これらの類似データ部分は、方法１００により反復して生成されたメディアデータの圧縮バージョンに２回目は保存されない。すなわち、類似データ部分は、圧縮メディアデータに一回保存される。メディアデータに関する最初のデータ部分の処理時には、１０２での評価は不必要であり、逆に、最初のデータ部分は、そのまま圧縮メディアデータへ保存される。しかし、最初のデータ部分に続く全てのデータ部分については、１つ又はそれ以上の類似データ部分が検出される可能性がある。こうした状況においては、これらの類似データ部分は、圧縮メディアデータに２回保存されることはない。

１０３における処理が進む時に、反復的に構成されている圧縮メディアデータに対して、１０４でメタデータ構造が生成される。メタデータ構造は、圧縮されている元来のメディアデータ内の連続的位置を識別する各類似データ構造に対するマッピングを提供する。すなわち、単一のデータ部分は、この特定のデータ部分が元のメディアデータ内の複数のメディアデータフレームに付随することを示す複数のマッピングを有することができる。一実施形態では、メタデータ構造は、圧縮メディアデータ内の類似データ部分に対する適切なマッピングを提供する数値的な位置の値を有する文字列である。勿論、当業者が認めるように、圧縮メディアデータから元のメディアデータへの適切なマッピングを提供する任意のデータ構造を利用しても本開示の教義を達成することができる。従って、全てのこのようなメタデータ構造は、本発明の幅広い範囲に該当するように意図されている。

メディアデータがメタデータ構造及び圧縮メディアデータによって表わされた状態で、メタデータ構造は、圧縮メディアデータの最初の部分に添付されて連続したデータ列を表し、この後１０５において、これがネットワーク上で受信者へとストリーミングされることになる。
１０１から１０５で説明した処理と同時に又は平行して、方法１００は、ネットワーク上で受信者へメディアプレイヤーを配信する準備を行うものである。すなわち、１１０において、受信者のコンピュータ環境に対するメディアプレイヤーが識別される。一部の実施形態では、このメディアプレイヤーは、受信者が積極的に選択して設定することができる。例えば、受信者は、ＷＷＷブラウザを通じてインターネットのようなネットワーク上でメディアデータを要求することができる。この要求中に、受信者は、希望するメディアプレイヤーを選択するか、又はランダム・アクセス・メモリ（ＲＡＭ）機能、ブラウザアプレット機能、及びブラウザタイプ（例えば、ネットスケープ、ＡＯＬ，インターネット・エクスプローラ、及びその他）のような受信者から受信する「ユニフォーム・リソース・ロケータ（ＵＲＬ）」要求データから自動的に得ることができない他の設定可能なオプションを提供するように求められることになる。

１１１では、メディアプレイヤーは、受信者又は受信者のＵＲＬ要求データにより供給された自動又は手動による情報に基づいて設定され、メディアプレイヤーは、ネットワーク上で受信者へと送信される。メディアデータプレイヤーは、ソフトウエアコードが、メディアプレイヤーの実行可能バージョンを発生させるための事前コンパイル又は静的リンクが不要な自己実行型であるように、翻訳言語によって書かれている。更に、メディアプレイヤーは、受信者のコンピュータ環境へのダウンロードが完了した状態で、自動的に読込んで実行するように設計されている。ソフトウエアモジュールのような１つの例示的な手段は、ＪＡＶＡアプレットをサポートするアプリケーション内において自己読込及び自己実行を行うことができるＪＡＶＡアプレットのようなアプレットとして書かれたメディアプレイヤーである。既存のＷＷＷブラウザのほとんどは、ＪＡＶＡアプレットをサポートすることになる。勿論、本発明の教義を達成するために、自己実行型及び自己読込型のアプリケーションアプレットとして書かれた任意のメディアプレイヤーを使用することができる。全てのこのような方法は、本発明の幅広い範囲に該当するように意図されている。

メディアプレイヤーが読込まれて自動実行されると、１１２において、メディアプレイヤーは、受信者のコンピュータ環境によってサポートされているネットワークのデータ伝送速度を検出し、それに従って１１３において設定を実行する。受信者のコンピュータ環境のデータ伝送速度により、メディアプレイヤーは、連続したメディア再生を可能にするためにどれ程のバッファスペース及びどれ程の圧縮メディアデータを送信者から受信者へストリーミングすることができるかを知ることができる。一部の実施形態では、この設定は、受信者が１１０においてメディアプレイヤーを選択して設定を行う時点で発生し、従って、これらの実施形態では、１１２及び１１３における検出又は設定は不必要である。

１１４では、メディアプレイヤーは、自動的に送信者と連絡を取り、圧縮メディアデータを受信者へストリーミングする際に圧縮メディアデータが分解される好ましいデータチャンクを識別する。これに対する応答の中で、方法１００は、圧縮メディアデータの最初のチャンクを用いてメタデータ構造をストリーミングする。この後、メディアプレイヤーは、メタデータ構造を取得し、マッピングを読取り、受信者のコンピュータ装置上で最初のチャンクをバッファに入れる。最初のバッファが満たされた状態で、メディアプレイヤーは、メタデータ構造を読取り、バッファから圧縮メディアデータを解凍し、受信者のコンピュータ装置上で非圧縮メディアデータを再生する。
１０６、１１４、及び１１５における処理は、平行して連続的に全ての圧縮メディアデータが受信者のコンピュータ装置において受信され、メディアプレイヤーによって再生されるまで続く。

更に、一部の実施形態では、１０１〜１０５で示した処理は、バッチで実行され、１１４で要求するメディアプレイヤーに対して容易に利用可能にすることができる。従って、メタデータ構造及び圧縮メディアデータは、送信者のコンピュータ環境に対して容易にアクセス可能な場所にネイティブに保存することができる。これは、方法１００を用いてメディアデータを定期的に配信するコンテントプロバイダには特に有益であろう。それはまた、コンテントプロバイダをメディアデータコンテントのためのデータウェアハウスとして利用する受信者に対しても有益と考えられる。

ここで、当業者は、上述の様々な実施形態の説明を読んだ上で、これまで産業界で利用可能であったものよりも如何にメディアデータをより効率的に処理することができるかを認めるものである。受信者は、もはや専用の不愉快なメディアプレイヤーのダウンロード及びインストールに苦労しなくても済むことになる。更に、本発明の圧縮技術は、元のメディアデータのサイズをこれまで産業界で利用可能であったものを超えて実質的に縮小することを可能にするので、低帯域幅ネットワーク接続の受信者は、時間効率の良い方法でメディア再生を体験することができる。更に、本開示の教義により、メディア再生に伴う初期の開始待ち時間が短縮されるために、高帯域幅ネットワーク接続の受信者でも、より時間効率の良いメディア再生を体験することができる。

図２は、本発明の一実施形態によるメディアデータ構造２００を示す図である。メディアデータ構造は、１つ又はそれ以上のコンピュータ可読媒体２０１に存在している。当業者は、メディアデータ構造２００が論理的に組み立て可能であり、かつ複数の異なる場所及びコンピュータ可読メディア２０１から取得することができることを認めるので、メディアデータ構造２００は、単一のコンピュータ可読メディア２０１上に隣接して保存される必要はない。

メディアデータの送信者又はメディアデータ・コンテント・プロバイダは、メディアデータ構造２００を利用する。メディアデータ構造２００は、メディアプレイヤー２０２、メタデータ構造２０３、及び圧縮メディアデータ２０４を含む。メディアデータ構造２００は、完全収容型データ構造２００であり、これを用いてより効率的にメディアデータ２１０の再生及びストリーミングを行うことができる。データ構造２００は、メディア２１０が自動的に再生されて、より小さなデータサイズに圧縮されることを可能にする。従って、メディアデータ２１０がコンピュータ装置上で再生可能になる前にダウンロードし、インストールし、更にコンピュータ装置を再起動する必要はない。更に、より小さな圧縮メディアデータ２０４は、メディアデータ２１０が再生される前の開始待ち時間の短縮を可能にする。

圧縮メディアデータ２０４は、類似データ部分が一回保存されるメディアデータ２１０のメディアフレームからのデータ部分を表している。データ部分のサイズ及びデータ部分を規定するデータ特性は、メディアデータ構造２００を生成する方法の設定可能な特性である。一例として、データ部分は、色特性、ピクセル特性、解像度特性、音声特性、及びその他を含むことができる。
メタデータ構造２０３は、圧縮メディアデータ２０４からメディアデータ２１０の非圧縮バージョンへのマッピングを提供する。一部の実施形態では、このマッピングは、各個々に保存されたデータ部分のそれが元のメディアデータ２１０に関連付けられた場所及び／又はフレームを識別する数字列である。

メディアプレイヤー２０２は、自己読込型、自己実行型、及び自己設定型のアプリケーションである。一部の実施形態では、メディアプレイヤー２０２は、処理を行うために介入又は設定を必要としない。従って、メディアプレイヤー２０２は、処理中のコンピュータ装置のデータ伝送速度及びメディアプレイヤー２０２を利用するアプリケーションなどを自動的に検出することができる。他の実施形態では、メディアプレイヤー２０２は設定可能であり、メディアプレイヤー２０２を利用するアプリケーション、ネットワークデータ伝送速度、及び受信中のコンピュータ装置の他の属性又は特性のようなものに対する手動調節を可能にする。

圧縮メディアデータ２０４は、設定可能なバイトサイズへ分解することができる。一部の実施形態では、メディアプレイヤー２０２は、受信中のコンピュータ装置のネットワークデータ伝送速度に基づくバイトサイズの設定を提供する。更に、一部の実施形態では、ストリーミングアプリケーション２２０は、圧縮メディアデータ２０４を望ましいバイトサイズでネットワーク２３０上で意図する受信者のコンピュータ装置２４０へ供給する。

データ構造２００の一実施形態では、受信者２４０からメディアデータ２１０を取得して消費するという要求が受信される。メディアプレイヤー２０２が識別され、任意的に、受信者のコンピュータ装置に対して設定され、ネットワーク２３０上で受信者２４０へ送信される。メディアプレイヤー２０２は、自己読込を行い、受信者のコンピュータ装置において介入なしに処理を開始する。メディアプレイヤー２０２は、次に、任意的にネットワークデータ伝送機能を検出し、ネットワーク２３０上で圧縮メディアデータ２０４を受信者２４０へ送信するための最適ブロックサイズを選択する。次に、メディアプレイヤー２０２は、自動的に設定を行い、ネットワーク２３０上で圧縮メディアデータ２０４の最初のブロックを要求する。最初のブロックは、ブロックの最初の部分としてメタデータ構造２０３を含む。メディアプレイヤー２０２は、メタデータ構造２０３を用いて受信者のコンピュータ装置上で解凍を行い、メタデータ構造２１０を自動的に再生する。

他の実施形態では、ストリーミングアプリケーション２２０によるネットワーク２３０上での受信者２４０への圧縮メディアデータ２０４のストリーミングが開始される前に、メタデータ構造２０３及びメディアプレイヤーは、受信者２４０へ一緒に送られる。更に他の実施形態では、初期設定のデータブロックサイズは、メディアプレイヤー２０２、メタデータ構造２０３、及び圧縮メディアデータ２０４の最初の部分のネットワーク２３０上での受信者２４０へのストリーミングに用いられる。他の実施形態では、受信者２４０は、メディアデータ２１０のコンテントプロバイダの送信者との過去の接触を通じて以前にメタデータ構造２００を使用したことがあるであろう。これらの実施形態では、メディアプレイヤー２０２は、受信者のアプリケーション内に存在することが許される場合があり、従って、既に存在している場合がある。従って、メディアプレイヤー２０２を受信者２４０に再送する必要がないことになる。

ここで、メディアデータ構造２００が如何に産業界において従来達成されたものを超える大きな利点を機能的にもたらすかが理解される。より具体的には、メディアデータ２１０は、今や圧縮メディアデータ２０４として実質的に圧縮され、ネットワーク２３０上でより高速に送信されて受信者２４０により消費されることを可能にすることができる。更に、受信者がメディアデータ２１０を消費することができる前に受信者がアプリケーションを取得し、ダウンロードし、インストールし、恐らくは再起動さえもする必要がないように、メディアプレイヤー２０２は、メディアデータ構造２００内に含まれている。

図３は、本発明の一実施形態によるメディアデータ処理システム３００を示す図である。メディアデータ処理システム３００は、コンピュータ処理環境内の１つ又はそれ以上のソフトウエアアプリケーションとして実施される。メディアデータ処理システム３００は、メディアプレイヤー３１０、メタデータ構造３２０、及びストリーミングアプリケーション３３０を含む。
メディアプレイヤー３１０は、１つ又はそれ以上のソフトウエアアプリケーションとして実施され、メディアプレイヤー３１０がコンパイル又は他のモジュールへの静的リンクを必要とせずに自己実行することができるように、翻訳ソフトウエアプログラミング言語で書かれるものである。一実施形態では、メディアプレイヤー３１０は、ブラウザ内で自己読込型、自己実行型、及び自己設定型のＪＡＶＡアプレットとして書かれている。

メタデータ構造３２０は、メディアデータの圧縮バージョン３２２と元の処理済みメディアデータ３２４との間のマッピングである。このマッピングは、メディアデータの解凍時にメディアデータ３２４に呈示されるように圧縮メディアデータ３２２に単独で保存されたデータ部分に対する位置的情報を識別するものである。類似データ部分は、圧縮メディアデータ３２２に一回保存される。類似データ部分は、メディアデータ３２４に含まれた特定のフレームにメタデータ構造３２０を通じてマップすることになる。

ストリーミングアプリケーション３１０は、第１に又は最初にメディアプレイヤー３１０をネットワーク３４０上でブラウザアプリケーション３５０へ送信する。メディアプレイヤー３１０は、次に、自己読込し、自己実行し、必要に応じて自己設定することになる。次に、メディアプレイヤー３１０は、ストリーミングアプリケーション３３０からメタデータ構造３２０を要求し、ストリーミングアプリケーション３３０は、設定されたデータブロックサイズで圧縮メディアデータ３２２の送信を開始する。メディアプレイヤー３１０は、ブラウザ３５０内で実行され、メタデータ構造３２０及び圧縮メディアデータ３２２を受信する。メディアプレイヤー３１０は、圧縮メディアデータ３２２を解凍してメディアデータ３２４を非圧縮フォーマットで再生するために、メタデータ構造３２０を読取って処理するように作動可能である。

ここで、インターネットのようなネットワーク上でメディアデータ３２０を如何により効率的に処理して再生することができるかが十分に認められる。これらの技術は、受信者による消費セッション中にメディアプレイヤー３１０を自動的に送信することを可能にするものである。メディアプレイヤー３１０は、自動的に読込み、実行し、設定し、メタデータ構造を用いてこれまで産業界で達成されたものよりも効率的な方法で圧縮メディアデータ３２２を解凍する。

以上の説明は、限定的ではなく例証を意図していることは理解されるものとする。上述の説明を考察すれば、当業者には他の多くの実施形態が明らかであろう。本発明の実施形態の範囲は、従って、特許請求の範囲、並びにこのような特許請求の範囲の権利が及ぶ均等物の全ての範囲を参照して判断されるべきである。
「要約」は、読者が技術的開示内容の性質及び要旨を直ちに確認することを可能にする「要約」を要求する「３７Ｃ．Ｆ．Ｒ．§１．７２（ｂ）」に従って提供されたことを強調しておきたい。これは、それが特許請求の範囲又は意味を解釈又は制限するために使用されないという理解の下に提出されたものである。

上述の「発明を実施するための最良の形態」では、開示内容を分かり易くするために様々な特徴が１つの実施形態に一緒にまとめられている。この開示の方法は、本発明の請求する実施形態が各特許請求の範囲に明示的に列記したもの以上の特徴を必要とするという意図を反映しているとは解釈されないものとする。反対に、特許請求の範囲が示すように、革新的な内容は、単一の開示した実施形態の全ての特徴よりも少ないものである。すなわち、特許請求の範囲は、各請求項が別々の例示的実施形態としてそれ自体を主張しながら、ここに「発明を実施するための最良の形態」に組み込まれるものである。

本発明の一実施形態によるメディアデータを処理する方法の流れ図である。 本発明の一実施形態によるメディアデータ構造を示す図である。 本発明の一実施形態によるメディアデータ処理システムの図である。

Claims (20)

1. メディアデータのメディアデータフレームに対するデータ部分を評価する段階と、
   圧縮メディアデータに対する単一データ部分内の類似データ部分を反復して保存する段階と、
   前記単一データ部分内の前記データ部分の各々に関して、前記類似データ部分が付随する前記メディアデータフレームに対する関連性を識別するメタデータ構造を生成する段階と、
   ネットワーク上でメディアプレイヤー、前記メタデータ構造、及び前記圧縮メディアデータをストリーミングする段階と、
   を含むことを特徴とする、メディアデータを処理する方法。
2. 生成する段階において、前記メタデータ構造は、前記データ部分の１つが前記メディアデータ内で付随する前記メディアフレームの１つを識別する各類似データ部分に対する数値的位置を含むことを特徴とする請求項１に記載の方法。
3. ストリーミングする段階において、前記圧縮メディアデータは、データブロックに分けられて前記ネットワーク上で１回に１ブロックづつ送られることを特徴とする請求項１に記載の方法。
4. 評価する段階において、前記メディアデータは、評価時に既に圧縮フォーマットになっていることを特徴とする請求項１に記載の方法。
5. 評価する段階において、前記メディアデータは、「ムービング・ピクチャー・エキスパート・グループ（ＭＰＥＧ）」フォーマット、「オーディオ・ビデオ・インターリーブド（ＡＶＩ）」フォーマット、及び「クイックタイム・ムービー・フォーマット（ＭＯＶ）」のうちの少なくとも１つであることを特徴とする請求項１に記載の方法。
6. 受信者により、前記ネットワーク上で前記メディアプレイヤー、前記メタデータ構造、及び前記圧縮メディアデータを受信する段階を更に含むことを特徴とする請求項１に記載の方法。
7. 前記圧縮メディアデータを解凍して再生するために自動的に実行されて前記メタデータ構造を読取る前記メディアプレイヤーを前記受信者のコンピュータ装置上で自動的に読取って開始する段階を更に含むことを特徴とする請求項６に記載の方法。
8. コンピュータ可読媒体上にあるメディアデータ構造であって、
   類似データ部分が一回保存されるメディアデータの圧縮部分と、
   前記圧縮部分の各データ部分を前記メディアデータに対する適切なフレームにマップするために用いられるメタデータ構造と、
   受信時にコンピュータ装置上で自動的に読取られて処理されるメディアプレイヤーと、
   を含み、
   前記メディアプレイヤーは、前記メタデータ構造を処理して、前記圧縮部分の非圧縮フォーマットを取得して複製し、前記メディアデータを自動的に再生する、
   ことを特徴とする構造。
9. 前記メディアプレイヤーは、前記メディアデータを取得して再生する前に、受信しているコンピュータ装置のデータ伝送速度を自動的に検出することを特徴とする請求項８に記載のメディアデータ構造。
10. 前記圧縮部分は、設定可能なサイズのデータブロックに分解されることを特徴とする請求項８に記載のメディアデータ構造。
11. ストリーミングアプリケーションが、ネットワーク上で最初に前記メディアプレイヤー、続いて前記メタデータ構造、次に前記ブロックの各々を順次ストリーミングすることを特徴とする請求項９に記載のメディアデータ構造。
12. 前記メディアプレイヤーは、受信者のブラウザ内で自動的に読取られて実行されることを特徴とする請求項８に記載のメディアデータ構造。
13. 前記メディアプレイヤー、前記メタデータ構造、及び前記圧縮部分は、「インターネット」であるネットワーク上でストリーミングされることを特徴とする請求項１２に記載のメディアデータ構造。
14. 「ハイパーテキスト転送（ＨＴＴＰ）」又は「セキュア・ソケット・レイヤー上のＨＴＴＰ（ＨＴＰＰＳ）」プロトコルが、前記メディアプレイヤー、前記メタデータ構造、及び前記圧縮部分を「インターネット」上で前記ブラウザへストリーミングするのに用いられることを特徴とする請求項１３に記載のメディアデータ構造。
15. ブラウザ内に自動的に読取って実行することができるメディアプレイヤーと、
    圧縮メディアデータからデータ部分を識別し、各データ部分を非圧縮メディアデータの適切なフレームに関連付けるメタデータ構造と、
    最初にネットワーク上で前記メディアプレイヤーを前記ブラウザに送信し、該メディアプレイヤーに応答して前記メタデータ構造及び前記圧縮メディアデータを該ブラウザに送信するストリーミングアプリケーションと、
    を含むことを特徴とするメディアデータ処理システム。
16. 前記圧縮メディアデータは、前記非圧縮メディアデータのフレームに対する類似データ部分を一回収容することを特徴とする請求項１５に記載のメディアデータ処理システム。
17. 前記ストリーミングアプリケーションは、前記圧縮メディアデータを設定可能なデータブロックサイズで前記ブラウザに送信することを特徴とする請求項１５に記載のメディアデータ処理システム。
18. 前記メタデータ構造は、最初の文字列として前記圧縮メディアデータに添付されることを特徴とする請求項１５に記載のメディアデータ処理システム。
19. 前記メディアプレイヤーは、前記ブラウザ内に自動的に読取られて実行され、該ブラウザのネットワーク接続に対する伝送速度を検出し、次に、自身を設定して前記ストリーミングアプリケーションからの前記メタデータ構造及び前記圧縮メディアデータを要求することを特徴とする請求項１５に記載のメディアデータ処理システム。
20. 前記メディアプレイヤーは、実行可能ブラウザアプレットとして実施されることを特徴とする請求項１５に記載のメディアデータ処理システム。

Images