モバイルイメージング（画像化）アプリケーション、装置のアーキテクチャ、サービス・プラットフォーム・アーキテクチャとサービス（ＭＯＢＩＬＥＩＭＡＧＩＮＧＡＰＰＬＩＣＡＴＩＯＮ，ＤＥＶＩＣＥＡＲＣＨＩＴＥＣＴＵＲＥ，ＳＥＲＶＩＣＥＰＬＡＴＦＯＲＭＡＲＣＨＩＴＥＣＴＵＲＥａｎｄＳＥＲＶＩＣＥＳ）
モバイル機器およびモニタリングアプリケーションにおける静止画像およびビデオ画像の圧縮および復元のためのシステムと方法を提供する。無線および有線ネットワークでの静止画像およびビデオ画像の送信、保存、編集およびトランスコーディングと表示可能機器での視聴のための、モバイル機器およびカメラのアーキテクチャと、サービスプラットフォームのアーキテクチャへの対応を同様に提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連発明＞
本件出願は出願番号60/654,058で2005年2月16日に出願されたアメリカ合衆国の仮出願の優先権主張を伴うものである。
本出願が全面的に参照して関連するのは、さらに、2005年9月20日に申請された米国の出願11/232,165番; 2005年9月21日に申請された米国の出願11/232,726番; 2005年9月21日に申請された米国の出願11/232,725番; 2005年10月12日に申請された米国の出願11/249,561番；および2005年10月13日に申請された米国の出願11/250,797番である。
この出願は、下記のものすべてを全目的に組み入れている：
Sweldens、WimのThe Lifting Scheme：双直交ウェーブレットのカスタム・デザインの構築。Appl. Comput. Harmon. Anal. 3(2):186-200, 1996 ；
米国特許出願10/418,363、2003年4月17日出願、発明の名称WAVELET TRANSFORM SYSTEM、METHOD AND COMPUTER PROGRAM PRODUCTで、発明者は、William C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders ；
米国特許出願10/447,514、2003年5月28日出願、CHROMA TEMPORAL RATE REDUCTION AND HIGH-QUALITY PAUSE SYSTEM, AND METHODで、発明者はSteven E.Saunders、Krasimir D.KolarovおよびWilliam C.Lynch ；
米国特許出願10/447,455、2003年5月28日出願、PILE PROCESSING SYSTEM AND METHOD FOR PARALLEL PROCESSORで、発明者はWilliam C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders ；
Golomb, S.W.(1966). "Run-length encoding" IEEEトランズアクション情報理論、IT-12(3):399−401 ；
R. F. Riceの " いくつかの実際的なユニバーサルノイズレコード化技術 " ジェット推進研究所、パサデナ、カリフォルニア、JPL出版、79-22 1979年3月 ；
J.Teuholaの "クラスタード・ビット-ベクトル用圧縮方法 " 情報処理レター、1978年10月の7 vol. pp. 308 ? 311 ；
米国特許出願10/447,455、2003年5月28日出願の PILE PROCESSING SYSTEM AND METHOD FOR PARALLEL PROCESSORS、発明者はWilliam C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders。
本発明は、
出願番号11/232,726で2005年9月21日にアメリカ合衆国に出願された"Multiple Technique Entropy Coding System and Method" であって、出願番号60/612,652で2004年9月22日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号11/232,725で2005年9月21日にアメリカ合衆国に出願された"Permutation Procrastination" であって、出願番号60/612,651で2004年9月22日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号11/232,165で2005年9月20日にアメリカ合衆国に出願された"Compression Rate Control System and Method with Variable Subband Processing" であって、出願番号60/612,311で2004年9月21日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号10/955,240で2004年9月29日にアメリカ合衆国に出願された"System and Method for Temporal Out-of-Order Compression and Multi-Source Compression Rate Control" で、現在、アメリカ特許公告No. US 2005/0105609で2005年5月19日に公告されたものであって、出願番号60/612,311で2004年9月22日のアメリカ特許仮出願と、共に2003年9月30日出願の出願番号60/507,148と出願番号60/507,147のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/944,437で2004年9月16日にアメリカ合衆国に出願された"Multiple Codec-Imager System and Method" で、現在、アメリカ特許公告No. US 2005/0104752で2005年5月19日に公告された出願であって、出願番号60/390,380で2002年6月21日のアメリカ特許仮出願と、出願番号60/374,061で2002年4月19日出願のアメリカ特許仮出願からの優先権主張を伴う2004年11月30日に発行されたアメリカ特許第6,825,780号の継続である出願の一部継続出願であり、；
出願番号10/477,455で2003年5月28日にアメリカ合衆国に出願された"Pile-Processing System and Method for Parallel Processors" で、現在、アメリカ特許公告No. US 2003/0229733で2003年12月11日公告された出願であって共に2002年5月28日出願の出願番号60/385,253と出願番号60/385,250のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/447,514で2003年5月28日にアメリカ合衆国に出願された"Chroma Temporal Rate Reduction and High-Quality Pause System and Method" で、現在、アメリカ特許公告No. US 2003/02355340で2003年12月25日に公告された出願であって共に2002年6月21日出願の出願番号60/390,345と出願番号60/390,492のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/418,649で2003年4月17日にアメリカ合衆国に出願された"System, Method and Computer Program Product for Image and Video Transcoding" で、現在、アメリカ特許公告No. US 2003/0206597で2003年11月6日に公告された出願であって2002年4月19日出願の出願番号60/374,069のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/418,363で2003年4月17日にアメリカ合衆国に出願された"Wavelet Transform System, Method and Computer Program Product" で、現在、アメリカ特許公告No. US 2003/0198395で2003年10月23日に公告された出願であって2002年6月21日出願の出願番号60/385,254のアメリカ特許出願と共に2002年4月19日出願の出願番号60/373,974と出願番号60/373,966のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願である。
本出願が全面的に参照して関連するのは、2005年1月25日に発行されたアメリカ特許第6,847,317号の"System and Method for a Dyadic-Monotonic (DM) Codec"と、2004年11月30日に発行されたアメリカ特許第6,825,780号の"Multiple Codec-Imager System and Method"である。
直接デジタル化されたイメージやビデオには多くのビットが必要となる。そこでイメージやビデオは記憶・伝送・その他の使用のために圧縮するのが一般的である。いくつかの基本的な圧縮方法が知られており、数多くのそれらの異型が存在している。一般的な方法は変換・量子化・エントロピー符号以下の３段階の工程からなる。多くのイメージ・ビデオコンプレッサはこれらの基本構成とその変形を保有しているものである。
ビデオコンプレッサにおける変換ステージの目的は、ソース画像のエネルギーと情報を、画像若しくはシーケンスの固有の類似点やパターンを利用して、できる限りコンパクトな型にまとめることである。全ての可能性あるインプットを圧縮できるコンプレッサは存在しない。そこで、我々は代表的なインプットにうまく働き、ランダムインプットや病的なインプットに反応しないコンプレッサを開発した。MPEG-2、MPEG-4のような多くの画像圧縮方法やビデオ圧縮方法において離散コサイン変換（DCT）が変換処理として使用されている。MPEG-4スタティックテクスチャ（static texture）圧縮処理では変換処理（段階）としてウェーブレット変換が使用されている。
変換処理（段階）後の非量子化情報において、再構築された復元情報は正確なオリジナルの再現とはならない。エントロピー符号化は一般的にはロスのない工程であり、この工程では、量子化および符号化の後に情報が保存されるので、デコーダの中で正確に再生産できる。従って、どの情報を無視するかの決定は後述するエントロピー符号化の段階に影響を及ぼさない。
ワークステーションコンピュータ上で高度に複雑なエンコーダを実行できるようなスタジオの現場で、ビデオコンテンツのエンコーディングに利用されているのは、本来、ビデオ放送・ストリーミングアプリケーション用に開発された、限定されたDCT（離散コサイン変換）によるビデオコーデック（圧縮復元）技術である。このようなコンピュータ的に複雑なエンコーダ（符号装置）が、コンピュータ的に簡素で比較的高価ではないデコーダ（プレーヤ）である需要者の再生装置にインストールされる。しかしながら、非対称なエンコーダとデコーダ技術はモバイルメディア機器ではうまくマッチせず、ビデオメッセージはリアルタイムで携帯電話（携帯送受信機）に捕えられ、また、再生される。その結果、モバイル機器のビデオ画像は、他の消費者向け製品より、より小さいサイズとなり、さらに低いフレーム率に限定される。
【０００２】
＜発明の背景と、発明の要約＞
本発明は、機器により記録される静止画像とビデオ画像に関する方法、装置、システムおよびアーキテクチャに関連するものである。本発明は以下のものを包含する。すなわち、モバイル機器、関連するモバイル機器アーキテクチャ、サービス・プラットホームアーキテクチャ、および送信・記憶・編集・共有・マーケッティング、無線および有線のネットワーク・システムを通じた静止画像・ビデオ画像の変換、ディスプレイ装置による閲覧のための方法とサービスを包含し、これはネットワークや前述のものに関連するその他のシステムサービスに限られない。また、本発明は、イメージの録画技術の改良および関連するモバイル機器とサービスプラットホームのアーキテクチャの改良にもまた関連している。
【０００３】
本発明は、動画または静止画像の圧縮および／または復元のためのソフトウェア単体実行によるビデオコーデック（圧縮復元）およびカムコーダ（ビデオカメラ）アプリケーションから構成される。また、本発明の関与する範囲は、インフラストラクチャ（基盤）関連の製品および方法と工程、さらに、携帯送受信機用ビデオコーデック（圧縮復元）およびカムコーダ（ビデオカメラ）技術のソフトウェアに関するビデオメッセージの配備と共有サービスならびに、一般に配備される汎用および専用のビデオフォーマットとの完全な相互利用性を支援するための編集技術と交換技術を配備するための多機能モバイルサービス（MMS）のインフラストラクチャ技術を含む。さらに、本発明は、モバイル機器のモバイル利用者が創作したビデオコンテンツのための革新的モバイルビデオブログとマーケッティングを確立し、これを可能にし、更に配信する、革新的MMS（多機能モバイルサービス）を実施する方法、工程ならびにビジネス工程からなる。
【０００４】
＜図面の簡単な説明＞
図１はモバイル画像通信のビデオ画像サイズの制限を示す。
【０００５】
図２は情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【０００６】
図３はモバイル画像送受信機の構成を示す。
【０００７】
図４はモバイル画像サービス・プラットフォームの構成を示す。
【０００８】
図５は従来のビデオコーデックの技術の比較図を示す。
【０００９】
図６は改良された情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【００１０】
図７は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１１】
図８はビデオコーデックの効果の比較図を示す。
【００１２】
図９は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１３】
図１０は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１４】
図１１は改良されたモバイル画像サービスのプラットフォームの構成を示す。
【００１５】
図１２は展開したMMSCビデオ・ゲートウェイのネットワークを通じた（OTN）アップグレードを示す。
【００１６】
図１３はビデオMMSがトランスコーディングを必要としない自立再生を示す。
【００１７】
図１４はメディア・プロデュース・サービスの展開に必要なビデオ編集サーバの複雑性、コストおよび数の縮小を示す。
【００１８】
図１５はモバイル・ビデオ・サービスのプラットフォームを示す。
【００１９】
図１６は、より高品質のマルチメディア携帯送受信機（携帯電話）・サービスのより速くより低いコストの開発と展開を示す。
【００２０】
図１７は本発明のモバイル・ビデオ・サービスを示す。
【００２１】
図１８は本発明のブロードバンドのマルチメディア装置およびサービスへのアプリケーションを示す。
【００２２】
図１９は本発明のソフトウェア画像アプリケーションに対する実装オプションを示す。
【００２３】
図２０は本発明のハードウェアでアクセラレートされた画像アプリケーションの実装オプションを示す。
【００２４】
図２１は本発明のハイブリッド・ハードウェアでアクセラレートされたソフトウェア画像アプリケーションの実装オプションを示す。
【００２５】
図２２は単純化されたマルチメディア携帯送受信機（携帯電話）プラットフォームのアーキテクチャのアプリケーションを示す。
【００２６】
図２３はGSM/GPRSネットワーク上でのモバイルビデオ通信デモの要素を示す。
【００２７】
図２４は本発明にかかる特定のMMS機能を示す。
【００２８】
＜ 発明の詳細な説明 ＞
＜ウェーブレット画像処理＞
ウェーブレット変換は、１次元または１次元より上の次元における一つのデータセットの一対のウェーブレットフィルタの連続仕様からなる。静止画像の圧縮では、２次元（水平と垂直）のウェーブレット変換が使用される。本発明にかかるビデオコーデックでは３次元（水平と垂直と時間）のウェーブレット変換が使用される。改良された対称な３次元ウェーブレット変換によるビデオコーデック（codec＝圧縮還元）装置によれば、モバイル装置のコンピュータ上の複雑性と電力の消費量の削減改善についてDCTによるコーデックを用いた装置より望ましく、また、静止画像の処理においてもシングルコーデックによるビデオイメージの処理にも同時サポートが可能である。この静止画像とシングルコーデックによるビデオイメージの同時サポートは、それぞれに必要とされていた（ビデオ用の）MPEG又は静止画像用のJPEGコーデックを削減または不要にするか若しくは圧縮効果とその結果としてのモーションJPEGの記憶特性を大幅に改善させた。改良された対称な３次元ウェーブレット変換によるビデオ処理装置は、利用者の作成したビデオの自動またはマニュアルの編集や、利用者の作成したビデオのデータベースの記憶、検索ならびに復元をサポートするMMS基盤となる装置のコンピュータ上の複雑性と電力の消費量の削減を可能にする。
【００２９】
＜モバイルビデオ通信とサービス＞
本発明は、モバイル機器にインストールされる改良されたビデオコンテンツの獲得、圧縮、送信、編集、記憶、共有、に関連した新たな方法、サービス、方式に関するものである。本発明は、遠隔通信（無線と有線のどちらのプロバイダによるものも含む）、インターネット、ケーブル（電信）その他の定置またはモバイルの無線サービスプロバイダを含むデータおよび多機能操作機に応用されるものである。本発明は、豊かなコンテンツ、高度な利用領域、利用者毎の平均収益（ARPU）を提供するものである。モバイルマルチメディアサービス（MMS）は、テキストを基礎とするショート通信サービス（SMS）の進化である。本発明によれば、提示される有望な新たなモバイルメディアサービス（MMS）仕様は、ビデオ通信と共有とターゲットとされた視聴者の個人的情報と交信するというニーズを可能にする改革である。モバイル画像通信と共有は更に、モバイル携帯機器に（静止画像用）デジタルカメラ機能および／またはカムコーダ（ビデオカメラ）機能を必要とし、これにより、加入者が送ろうとするビデオ情報を撮影（encord＝記号化）し、受信したビデオ情報を再生（decord＝復元）することが出来る。本発明の特徴であるこれらの機能は従来技術からも可能であったとしても実現できなかった。
【００３０】
本発明によれば、モバイル機器は、統合された利用者の多機能娯楽プラットフォームに発展していくことができる。産業界の投資は実施的に技術とプラットフォームに向けられてきた。その技術やプラットホームとは、テレビ放送番組（ニュースクリップ、スポーツハイライトや特別な"mobisodes"といったポピュラー番組のような）のリパッケージ、その他のスタジオ発のビデオコンテンツ（映画予告や音楽ビデオのような）をモバイル機器に送信して閲覧することを可能とするようなものである。後者のケースでは、モバイル機器利用者はビデオ消費者の新分野として開拓されている。しかしながら、この後者のケースではほとんど、大規模な放送会社の圧縮したビデオコンテンツを利用している。しかしながら、本発明により、世界のモバイル操作者は、単なるメディアの受信者というより加入者を（この発明により可能となる）メディア創作者としてサポートする重要な新しい機会が獲得できる。本発明で可能となるモバイル機器のスタンドアローンのデジタルカメラやカメラ付きレコーダと同様の写真やビデオの獲得と共有機能は、高速セル方式や固定無線データネットワークの進歩および集合とともに新たなサービスのための基礎技術である。本発明では更に、開発コストの削減とカメラ付きレコーダ電話やビデオ送信共有の基盤装置の両方の小売価格の削減が可能となり、これは、この装置や関連するモバイルメディア／データサービスを既存の市場やこれからの市場で大規模に商業的に採用することの鍵となる。
【００３１】
従来のモバイル画像通信／共有サービスとアプリケーションは、典型的な受信して他の多機能機器で再生するテレビ、パーソナルコンピュータ、デジタルビデオカメラ付きレコーダ、パーソナルメディア再生機より小さいサイズと低いフレーム率のビデオ画像に厳しく制限されていた（図１参照）。モバイル画像送信サービスとアプリケーションは、VGA（またはこれより大きな）ビデオのフレーム率が30fpsまたは本発明で提供されるそれ以上の高速を望まれるものをサポートすることが出来る。
【００３２】
＜適応情報源・通信路符号化結合(ADAPTIVE JOINT SOURCE-CHANNEL CODING)＞
モバイルネットワークのビデオ送信は、テキスト、オーディオ、静止画像のような他のデータ／メディア型の送信に比べて高度なデータ率が必要であるのでとても興味深い。さらに、モバイルネットワークのノイズとエラー特性の変動に伴うチャネルの帯域幅の変化と制限は、ビデオ移送に拘束と困難性を負わせる。本発明では、様々な情報源符号化の技術がビデオのビットストリームを異なるチャネル状態に適用するために用いられる（図２参照）。本発明にかかるこの情報源・通信路符号化結合（joint source-channel cording）はチャネルの帯域幅の変化とエラー特性に適応させるためにスケーラブル（拡大縮小可能）である。また、本発明はスケーラビリティ（拡縮可能性）をマルチキャストのシナリオのために支援し、異なる機器のビデオストリームの受信端では復号するコンピュータ出力と表示能力は異なる制限範囲となる。
【００３３】
図２で示すように、本発明によればビデオ情報源の列３０はまず情報源符号化３２（圧縮）され、エラー訂正コード（ECC）で通信路符号化３４される。モバイルネットワークでは、情報源の符号化の典型としてH.263、MPEG-4やモーションJPEGのようなDCTを基礎とする圧縮技術が使用される。通信路符号化の方法としては、Reed-Solomonコード、BCHコード、FECコードやターボコードがある。情報源とチャネルが共にコード化されたビデオのビットストリームはレート制御３６を通過してベストに再構築されるビデオ品質を実現しつつチャネル帯域幅の要件に適合する。レート制御は圧縮されたビデオストリームの離散レート歪（discrete rate-distortion）を、ビデオストリームがチャネル３８を介して伝送される前にコンピュータ化（computations）する。モバイル機器のコンピュータ上の制限で、典型的なレート制御ではチャネル帯域幅だけが考慮され、伝送チャネルのエラー特性については明確には考慮されていなかった。
【００３４】
本発明には望ましいことであり、また、実現可能なことは、高度なコンピュータ効率のあるアルゴリズムに基づく改良された適応可能な情報源・通信路符号化を使用することである。これにより、情報源符号化３２、通信路符号化３４とレート制御３６の３つの全てについて再構築されるビデオ信号の瞬時の平均品質（ビデオレートvsデストーション(distortion)）の両方を最大限に制御するために瞬時（instantaneous）と予測（predicted）できるチャネル帯域幅とエラー状態が利用可能となる。
【００３５】
改良された適応できる情報源・通信路符号化の技術の更なる利点は、本発明の視点からは、無線携帯とMMSサービスのプロバイダに大きな範囲の通信サービスの品質（QoS）を提供し、利用者と企業利用者に価格レベルを提供することにより無線ネットワークのインフラストラクチャ（基盤構造）を使って生み出す収益を最大化している。
【００３６】
マルチキャストシナリオは、多くのユーザーによって復号可能な単独の適応ビデオ・ビット・ストリームを要求する。これは現代の、大規模な、異種混交のネットワーク、このようなネットワークは帯域幅の制限により個々のユーザーに向けて特に調節された多数の同時放送ビデオ信号を送信することが不可能となる、では特に重要である。単独の適応ビデオ・ビット・ストリームのマルチキャストは、必要とされる帯域幅を大いに低くする。その反面、広帯域の無線または回線接続のハイエンドユーザーそして制限された帯域幅とエラーを起こしやすい通信手段を備えた携帯電話ユーザーを含む、多数のユーザーに復号可能なビデオ・ビット・ストリームの作成を要求する。モバイル機器におけるコンピュータ能力の制限のため、適応率制御装置の精度は一般的にとても粗末である。例えば、基礎層と１つの強化層からなる２層のビットストリームしか生成できない。
【００３７】
チャネルタイプ（無線および有線）、チャネル帯域幅、チャネルノイズ／エラー特性、ユーザー機器、そしてユーザサービスに関して、より高レベルの異種混交ネットワークへの支持を可能にするために、高い計算効率を備えたアルゴリズムに基づく改良した適応情報源・通信路符号化結合(adaptive joint-source channel coding)を利用することは、望ましく、本発明の態様によって可能になる。
【００３８】
＜モバイル画像送受信機(MOBILE IMAGING HANDSET)のアーキテクチャ＞
携帯送受信機（携帯電話）へのデジタル・カムコーダ（ビデオカメラ）機能の付加は、ハードウェア、ソフトウェア、または、ハードウェアとソフトウェアの組み合わせのいずれかに、通常、下記の機能の付加が要求される（図３参照）。
・プリアンプとアナログ・デジタル（A/D）信号変換回路網に相当する撮像装置アレイ（典型的にはCMOSまたはCCDピクセルアレイ）。
・プレプロセス、符号化／復号化（コーデック）、ポスト・プロセス等の画像処理機能。
・無線または有線ネットワークでの非同時送信または同時ストリーミングに対する処理画像のバッファリング。
・一つ以上の画像表示スクリーン。
・内蔵式または取外し可能な、ローカルの画像ストレージ。
【００３９】
MPEG-4等のDCT変換を基礎としたコーデックを使用すると、商用の画像利用可能な携帯送受信機（携帯電話）は、それらが通常取り込まれ表示される他のマルチメディア機器、例えば、テレビ、パーソナルコンピュータ、デジタル・カムコーダ（ビデオカメラ）およびパーソナルメディアプレイヤ等、に比べて、小さいサイズそして低フレーム率のビデオ画像の取り込みに制限される。これら後者の機器は、通常、30フレーム毎秒（fps）またはより高い表示速度で、VGA形式（640×480ピクセル）またはより大きなビデオ画像に保存／表示される。一方、商用の画像利用可能な携帯送受信機（携帯電話）は、15fpsまたはより低い表示速度で、QVGA形式（320×240ピクセル）、QCIF形式（176×144ピクセル）またはより小さいビデオ画像保存に制限される（例えば、図１参照）。この低いビデオ取り込み性能の原因は、過剰なコンピュータ上の要件、処理装置消費電力、そして、全部の数、形式、そしてDCT変換を使用したビデオ圧縮／非圧縮と関係するコンピュータ上の手順のシーケンスが義務付けられたバッファ・メモリによる。
【００４０】
商用のビデオ・コーデックとマイクロプロセッサ技術を使うことは、30fpsまたはより高水準ののフレーム率で、VGA（またはより大きな）ビデオの取り込みを目的とするモバイル画像送受信機にとって、とても複雑で、電力を必要とし、高価なアーキテクチャの原因となる。このような携帯送受信機（携帯電話）のアーキテクチャは、より大きなバッファメモリブロック（１メガバイト以上の典型的なメモリ容量）とともに、ソフトウェアプログラム、そして、縮小命令セット（RISC）プロセッサ、デジタルシグナルプロセッサ（DSP）、特定用途向け集積回路（ASIC）および再構成可能な処理装置（RPD）の組み合わせで動くハードウェア・アクセラレータの両方の組み合わせを利用したコーデックを必要とする。これらのコーデック機能は、そのようなRISCプロセッサ、DSP、ASIC、マルチメディアプロセッサおよびRPDを別々の集積回路（IC）として使用することによって実装できる。または、システム・イン・パッケージ（SIP）若しくはシステム・オン・チップ（SoC）の中に統合した１つ以上のRISCプロセッサ、DSP、ASIC、マルチメディアプロセッサおよびRPDを組み合わせることができる。
【００４１】
RISCプロセッサ、またはDSPで動作するコーデック機能は、典型的には、プログラミングエラーの修正または機能のアップグレードのために変更可能であるという利点をともなった、ソフトウェアルーチンである。特定の複合体（certain complex）を実装することの不利点、ソフトウェアとしての反復的なコーデック機能は、結果的に全体的なプロセッサ資源および消費電力要求が、モバイルコミュニケーション機器のそれらを通常越えることである。
ASICおよびマルチメディアプロセッサで動作するコーデック機能は、典型的には複合体の固定ハードウェア実装であり、反復的なコンピュータ上の手順、通常は、特別に調整されたハードウェア加速が全体的なコーデックの電力消費を大幅に低減できるという利点をともなう。固定ハードウェアに特定のコーデック機能を実装することの不利点は、長期でより高価な設計段階、固定されたシリコン実装の中にエラーが発見された場合における高価な製品のリコールの危険性、そして、画像アプリケーションに新しく作成された機能が付加される場合に製品に配備された固定シリコン機能アップグレードができないことである。
RPDで動作するコーデック機能は、典型的には、最終的なモバイル画像送受信機のハードウェア加速と機能性の追加または変更能力の両方を要求するルーティンである。RPDに特定のコーデック機能を実装する不利点は、ハードウェアの再構成を可能とするために、固定されたASICと比較して、より大きな数のシリコンゲートとより高い電力消費となることである。
【００４２】
複雑性を低減または除去する画像アプリケーションは、上記アーキテクチャを簡素化し、大量な商業展開で携帯送受信機（携帯電話）コストを両立させるために、反復的なコーデック機能がモバイル画像送受信機を全てのソフトウェア構成で30fpsのフレーム率でVGA（またはより大きな）ビデオ取得能力があるようにすることが望ましい。本発明はこれらの目的を上手く達成し、可能とする最初の技術である。
【００４３】
マルチメディア携帯送受信機（携帯電話）は、写真とビデオ通信の能力をサポートするだけではなく、付加的なマルティメディア能力（音声、音楽、画像）の多様性、そして、固定および可動性の無線アクセス・モード、2.5Gと3Gのセルラーアクセス、WiBro、HSDPA、WiFi、無線LAN、そしてブルートゥースを含むがこれに限定されるものではない、の多様性を要求する。そのような機器を開発、展開およびサポートすることを含んだ複雑性と危険性は、新たな利益を創出するサービスとアプリケーションをより効果的に展開するため、そして高価な機器のリコールを避けるために、無線（OTA）配給と多くの機能およびアプリケーション経営に非常に利益をもたらす。
【００４４】
ソフトウェア単体実行による画像アプリケーションは、携帯送受信機（携帯電話）製品、携帯電話事業者、そして他のMMSサービス・プロバイダーによる無線（OTA）配給と画像アプリケーションの運営を有効にすることが望ましい。
【００４５】
＜モバイルJAVAアプリケーション＞
Java技術は、一つの言語と一つの技術で、デスクトップのサーバーからモバイル機器まで広範囲の機器をもたらす。この範囲の機器のアプリケーションは異なっているが、Java技術はこれらの重要な違いを克服して動作し、ある分野で有能な開発者が広範囲の装置とアプリケーションにわたって彼らの技術を活用することを可能にする。
【００４６】
サン・マイクロシステムによって、1999年6月に、最初にJavaコミュニティーに発表されたJ2ME（Java２、Micro Edition）は、Java開発者の多様なニーズを満たす広範な先制の一部であった。Java2プラットフォームとともに、サンは３つのエディションに分類してJava技術のアーキテクチャを再定義した。スタンダード・エディション（J2SE）は、デスクトップ展開と、低価格なビジネスアプリケーションの実用的な解決案として提供された。エンタープライズ・エディション（J2EE）は、企業環境のためのアプリケーションを専門としている開発者のためのものであった。マイクロ・エディション（J2ME）は、制限されたハードウェア資源、例えば、PDA、携帯電話、ページャ（ポケベル）、テレビのセット・トップ・ボックス、遠隔情報操作装置およびその他多くの家庭用電化製品と埋め込み装置等、の機器に従事する開発者のために発表された。
【００４７】
J2MEは、わずか128KBのRAMと、これらが使用される典型的なデスクトップおよびサーバーコンピュータに比べてかなり劣るプロセッサを備えた機械に向けられた。J2MEは、実質的には一組のプロファイルから構成される。それぞれのプロファイルは、特定タイプの機器、例えば携帯電話、PDAなど、を定義する。そして、特定タイプの機器および機器をサポートするJava仮想マシンの仕様に必要な最小限のクラスライブラリのセットから構成される。全てのJ2MEプロファイルに規定された仮想マシンは、必ずしもJava2スタンダード・エディション（J2SE）およびJava2エンタープライズ・エディション（J2EE）で使われた仮想マシンと同じであるとは限らない。
【００４８】
プロセッサ能力、メモリ、固定ストレージおよびユーザインターフェースの相違のため、上記に記載された全ての機器に対して、最適な若しくは最適に近い、単独のJ2ME技術を定義することはとても困難である。
この問題に取り組むため、サンは、J2MEを区分にするための機器適合の定義を共有後、さらに再共有した。最初に、サンは使用目的を無視して、処理能力、メモリそして記憶容量に基づいて２つの広範なカテゴリに共有した。
同社は、次に、少なくとも最低限のJava言語機能を備えながら、それぞれのカテゴリの中で、機器の制約の範囲内で動作する、余分な装備を取り除いたJava言語のバージョンを定義した。
【００４９】
次に、サンは、それぞれこれら２つのカテゴリの中で、同じような役割を持つ機器のクラスを特定した。例えば、全ての携帯電話は、製品にかかわらず、１つのクラスの中に含まれた。Javaコミュニティ・プロセス（JCP）との協力により、サンはその後、それぞれの機器のクラスに特有の追加機能性を定義した。
【００５０】
最初の共有は、２つのJ2ME想定環境（configuration）、コネクテッド・デバイス・コンフィギュレーション（CDC）およびコネクテッド・リミテッド・デバイス・コンフィギュレーション（CLDC）、を作り出した。想定環境は、Java仮想マシン（JVM）と機器の選択グループに対しランタイム環境を規定する最低限のクラス・ライブラリとAPIのセットとできる。想定環境は、展開された機器の種類によって強いられた資源制約の範囲内で適合するJava言語の、最小共通基準サブセットを特定できる。ユーザインターフェース、機能そして使用法によって大きな変動性があるために、典型的な想定環境は、ユーザインターフェース・ツールキットおよび固定ストレージAPIのような重要な部分を定義しない。代わりに、その機能の定義付けはいわゆるプロファイルに属する。
【００５１】
J2MEプロファイルは、ページャおよび携帯電話のような機器の特定クラスを扱う産業主導型グループによって規定されたJavaAPIのセットとすることができる。それぞれのプロファイルは、その想定環境によって提供されたJava言語の最小共通基準サブセットの上部に構築され、その想定環境を補うように作られている。携帯送受信機（携帯電話）に重要な２つのプロファイルは、CDCを補助するファウンデーション・プロファイル（Foundation profile）、および、ＣＬＤＣを補助するモバイル情報デバイス・プロファイル（MIDP）である。より多くのプロファイルが進行中であり、仕様およびリファレンス実装が開発され発売されている。
【００５２】
The Java Technology for the Wireless Industry（JTWI）仕様、JSR185、は、次世代のJava技術を可能にする携帯電話に対する業界標準プラットフォームを規定する。JTWIは、主要な携帯機器製造業、無線通信事業者およびソフトベンダーの専門グループによるJavaコミュニティプロセス（JCP）によって創設された。JTWIは、全てのJTWI対応機器、適応可能なCLDC1.1（JSR139）およびMMAPI（JSR135）と同様にCLDC1.0（JSR30）、MIDP2.0（JSR118）およびWMA1.1（JSR120）、に含まれる技術を規定する。モバイルマルチメディア機器に対する技術およびインターフェースを定義した２つの追加JTWI仕様は、JSR-135（"Mobile Media API"）およびJSR-234（"Advanced Multimedia Supplements"）である。
【００５３】
JTWI仕様は、API断片化を最小限にして既に携帯電話のために開発されたアプリケーションの実質基準を拡張する一方で、高容量機器の機能性の制約を引き上げる。
JTWIの利点は以下を含む：
・相互運用性： この効果の目標は、アプリケーション開発者のための予測可能な環境と、機器製造業者のための配送可能な機能セットを配信することである。その目的は、JTWI標準に適合することによる２つの利点である。製造業者は広範囲の互換性のあるアプリケーションによる利益を享受し、ソフトウェア開発者はそれらのアプリケーションをサポートする広範囲の機器の利益を享受する。
・安全性仕様の明確化： JSR185仕様は、MIDP2.0仕様で規定した"Recommended Security Policy for GSM/UMTS-Compliant Devices"に関し、信用できないアプリケーションに対して幾つかの明確化を導入する。それはMIDP2.0で定義されたベースMIDlet suiteセキュリティ・フレームワークのベースを拡張する。
・ロードマップ： JTWI仕様の重要な特徴は、ソフトウェア開発者がJTWI準拠機器に期待できる共通の機能性の大要であるロードマップである。2003年1月、携帯電話の進化と調和した追加機能性を記述し、6から9月の間隔で出現することを期待されたロードマップシリーズの第一号が現れた。ロードマップは、全ての関係者がより信頼のもてる将来に対して計画をすることを可能にする：通信事業者はアプリケーション展開戦略のより優れた計画を立てることができ、機器製造業者は製品計画においてより優れた決定ができ、そして、コンテンツ開発者はアプリケーション開発努力のための明確な指針を予見することができる。特に通信事業者は、将来的に、現在、公衆インターネットにはびこるウイルス、ワーム、そして他の“アタック”（"attacks"）のようなセキュリティー違反から、根本的な無線通信／ネットワーク機能を取り出し／保護するJavaVMに頼るであろう。
【００５４】
Javaベース画像アプリケーションは、全てのJava対応送受信機にわたる「一度コードを書けば、どんな環境でも動作する」携帯性、また、ウイルス、ワーム、そして他のモバイルネットワークセキュリティ“アタック”（"attacks"）に対抗するJavaVMセキュリティおよび携帯送受信機（携帯電話）／ネットワーク構造安定性、そして、単純化した無線コーデックおよびアプリケーションダウンロード手順にとって望ましい。そのようなJavaベース画像アプリケーションは、JTWI仕様、JSR-135（"Mobile Media API"）およびJSR-234（"Advanced Multimedia Supplements"）に準拠する。本発明の形態はこれらの利点を提供する。
【００５５】
＜モバイル画像サービスプラットホームのアーキテクチャ＞
本発明の態様によるモバイル画像サービスプラットホームのアーキテクチャの重要な構造は、以下を含む（図４参照）。
・携帯電話機 ６０
・移動体基地局（BTS） ６２
・基地局制御装置／無線ネットワーク制御装置（BSC/RNC） ６４
・移動体交換局（MSC） ６６
・ゲートウェイ・サービス・ノード（GSN） ６８
・モバイルマルチメディアサービス制御装置（MMSC） ７０
【００５６】
本発明の態様によるMMSCに含まれた典型的な機能は、以下を含む（図４参照）。
・映像ゲートウェイ ７２
・通信会社サーバ ７４
・MMSアプリケーション・サーバ ７６
・ストレージ・サーバ ７８
【００５７】
本発明の態様によるMMSCのビデオゲートウェイは、画像サービスプラットフォームによってサポートされた異なるビデオフォーマット間のトランスコードに役立つ。トランスコーディングは、また、携帯電話ネットワークで使用される異なる音声コーデックをサポートする無線オペレータによって利用され、対応する音声トランスコーダはRNCに組込まれる。そのようなモバイル画像サービスプラットフォームを図４に示すアーキテクチャとともにアップグレードすることは、従来のアーキテクチャなら、通常、新たな送受信機を展開し、そして、手動で新しいハードウェアをMMSCビデオゲートウェイに付加することを必要とする。一部のモバイルビデオ通信および共有利用アプリケーションは、トランスコーディングと関連する費用と複雑性を削除することは望ましい。現在の発明の態様の一つとして、各送信されたビデオ・ストリームとともにソフトウェア・デコーダを組み込み、公共の送受話機およびPVビデオプレーヤにおける"自立再生"（"self-playing"）機能を可能にする能力がある。
【００５８】
MMSCの中のMMSアプリケーション・サーバは、ユーザー作成ビデオのデータベース・ストレージ、検索、および修正と同様に、自動または手動のユーザー作成ビデオの編集のようなアプリケーションもサポートできる。そのような機能の実装を要件とするコンピュータの複雑性は、標準のパーソナルコンピュータ（PC）およびサーバで使用されている安価で性能の低いCPUチップで動作する単純なソフトウェアプリケーションよりも、一般的に高価で高性能な特定用途向け集積回路（ASIC）およびデジタルシグナルプロセッサ（DSP）が必要な対応ビデオ処理機能とともに、モバイルオペレータによってインストールされる専門化したサーバを必要とする。
【００５９】
本発明の態様によって与えられるように、本発明の態様によるソフトウェア単体実行による・モバイル画像アプリケーション・サービス・プラットフォームは、展開された携帯送受信機（携帯電話）の自動無線アップグレード、展開されたMMSCの自動無線アップグレードのサポートのために望ましく、標準PCとサーバで使用されているモバイルビデオアプリケーションへサポートする。
本発明の態様による携帯送受信機（携帯電話）画像アプリケーションのJava実装は、ウイルス、ワーム、および他の“アタック”（"attacks"）に対抗する改良した送受信機／ネットワークの構造安定性に関して望ましく、モバイルネットワークオペレータが、全国的な調整機関によって要求されるサービスの品質と信頼性を提供することを可能にする
【００６０】
＜問題＞
モバイルビデオ通信および共有利用サービスの展開は、映像圧縮技術の本質的な限界にさらされている。
【００６１】
一方では、そのようなモバイルビデオサービスは、今やホームシネマ品質放送−VGAのような30フレーム毎秒のフルサイズ画像方式、の映像と同等の市場に乗り出している。他方で、本来、放送およびストリーミングのアプリケーションのために開発された現存する映像技術を使用して、このような大容量データ処理を行うことは、携帯電話のリアルタイム・ビデオ・キャプチャ（符号化）に利用可能なコンピュータリソースおよびバッテリ電力を大幅に超過する。放送およびストリーミングのアプリケーションは、高複雑性エンコーダがコンピュータワークステーション上で動作可能なスタジオ環境における映像コンテンツの符号化に依存する。ビデオメッセージは携帯送受信機（携帯電話）にリアルタイムで取り込まれるため、より小さいサイズおよびより低いフレーム率に制限される。
【００６２】
結果、今日のモバイルビデオサービスは原始的である；加入者がデジタル・カムコーダ（ビデオカメラ）に期待するようになったテレビ電話機能を複製するところまできている機能と比較して、写真は小さく（QCIF、QVGA）、粗い（15fpsまたはそれ以下）である。モバイル加入者に提供される原始的なビデオ画像品質は、産業界によるライフスタイルの広告で宣伝される鮮明なhigh-definition video(HDV)に程遠い。モバイル加入者は、広範囲に採用されカメラ一体型（カムコーダ）電話および関連するモバイル映像サービスに割増価格を払う前に、30fpsパフォーマンスのフルVGA（すなわちカムコーダと同様）を要求している。
【００６３】
本発明者は別として、営利事業要求と技術能力をはるかに上回る全体のコストおよび電力消費を伴いながら、VGA30fpsパフォーマンスの提供を試みようとして、競合するビデオ・コーデック・プロバイダーは、非常に高価で多大な時間を必要とする開発計画にもかかわらず、未だ複雑な混合ソフトウェア・コーデック＋ハードウェア・アクセラレータによる解決方法を提供するのみである。携帯送受信機（携帯電話）はこのように小さく粗い画像か、高価な高消費電力構造に制限される。大衆市場に採用されるには、サービス展開はとても高価であり、サービスの品質はとても低い。
【００６４】
新しい、若しくは特定のハードウェアが必要ならば、MMSC基盤をアップグレードすることも、同様に費用がかかる。ソフトウェア単体実行アプリケーションとサービス・プラットフォームは、携帯送受信機（携帯電話）の自動無線アップグレード、MMSCビデオゲートウェイのネットワーク通信によるアップグレードを可能にし、標準ＰＣおよびサーバを使用したモバイルビデオアプリケーションをサポートすることが望ましい。異なったビデオフォーマット間でのトランスコーディングの必要性も、同様に、追加費用と複雑性が加わる
【００６５】
＜解決法＞
特に本発明の態様によるこの問題の解決法は、携帯送受信機（携帯電話）構造の複雑性およびモバイル画像サービス・プラットフォーム構造の複雑性を低減し、ソフトウェア単体実行アプリケーションとして携帯送受信機（携帯電話）に実装できる、非常に単純な画像アプリケーション（コーデック）である。
本発明の態様によって、ソフトウェア単体実行によるビデオ・コーデック・ソリューションは、マルチメディア携帯送受信機（携帯電話）におけるベースバンド・プロセッサとビデオ・アクセラレータの費用と要件を大幅に低減または排除する。無線ダウンロードによるコーデック・ポストプロダクションをインストールする能力と組み合わせて、このソフトウェア単体実行ソリューションは、携帯送受信機（携帯電話）の発展とビデオ通信サービスの構造および展開の複雑性、リスクおよびコストを大幅に低減する。
本発明によるソフトウェア・ビデオ・トランスコーダおよび編集、保存、検索する修正アプリケーションは、そのようなアプリケーションで動作する標準PCおよびサーバの使用と同じように、展開されたMMS制御（MMSC）基盤の自動的なネットワークによるアップグレードを可能にするさらに、本発明のウェーブレット・トランスコーダは、通信事業者に、ウェーブレット・ビデオ・フォーマットと他の標準ベースおよび独自仕様のビデオフォーマットとの間の完全な相互運用性を提供する。本発明は、また、ソフトウェアデコーダが各送信ビデオストリームとともに取り込まれ、公共の携帯送受信機（携帯電話）およびPVビデオプレーヤでの"自立再生"（"self-playing"）機能を可能にし、トランスコーディング全体の費用と複雑性を排除する。
本発明のソフトウェア単体実行によるビデオ・プラットフォームは、新しいMMSサービスの急速な展開を可能にし、本発明の実施態様の一部も、他の現存する技術では得られない目的達成処理速度およびビデオ製品精度を可能にする。そのような新しいMMSサービスが本発明の特徴である。
本発明のウェーブレット・コーデックは、静止画像およびビデオの両方を効果的に処理する能力が際立っており、モバイル画像メールおよびビデオ通信サービスの両方を同時にサポートできる単独の低コストおよび低電力ソリューションとともに、別々のMPEGおよびJPEGコーデックに置き換えることができる。
【００６６】
本実施態様において、正確な態様、図、または実施例では、“Droplet”態様若しくは実施態様と記載している。本出願において、“Droplet”とは、本発明の実施態様を参照して理解される。
【００６７】
＜改良されたウェーブレット・ベースの画像処理＞
本発明の態様は、DCTベースのコーデックと比べ非常に低いコンピュータ複雑性を備えたビデオ圧縮／非圧縮（コーデック）装置における三次元（３D）ウェーブレット変換を利用する（図５では、従来のDCTエンコーダ技術と本発明の典型的な技術との相対的なコンピュータ要件の比較を提供している。）。ウェーブレット変換段階のアプリケーションは、また、大いに低減したコンピュータ上の複雑性とともに、量子化およびエントロピー符号化段階の設計を可能にする。モバイル画像アプリケーション、機器、およびサービスに対する本発明の３次元ウェーブレット・コーデックのさらなる効果は、以下を含む。
・対称的な、低複雑性ビデオの符号化および復号化
・ソフトウェアおよびハードウェア両方のコーデック実装に対する低プロセッサ電力要件
・ネイティブコードおよびJavaアプリケーションの両方として、現存する商用携帯送受信機（携帯電話）と互換性がある30fps（またはより高い）のフレーム率でのVGA（またはより大きな）ビデオのソフトウェア単体実行による符号化および復号化
・SoCインテグレーションのための、低ゲートカウントASICコア
・低バッファメモリ要件
・静止画像（〜JPEG）およびビデオ（〜MPEG）両方の単独コーデックサポート
・短いGOP（Group of Pictures）による単純化されたビデオ編集（カット、挿入、テキスト・オーバーレイ）
・短いGOPによるビデオコーデックをともなった単純同期化
・短いGOPによる改良ビデオストリーミングに対する低遅延時間
・適応率制御、マルチキャスティング、および情報源・通信路符号化結合(joint-source channel coding)に対する微粒子（fine grain）拡張性
・新興のHDTVビデオフォーマットの低複雑度パフォーマンス・スケーリング
・コンパクト・ソフトウェア・デコーダ（例えば、40ｋB以下のような）は、公共の携帯送受信機（携帯電話）およびＰＣビデオプレーヤと互換性がある"自立再生"（"self-playing"）ビデオメッセージが可能な各ビデオストリームと一体化可能である。
【００６８】
以上の効果は本発明に含まれる以下の特徴により達成される。
【００６９】
リフティング構成における16bit・32bit二項（short dyadic integer）フィルター係数を用いたウェーブレット変換アプリケーション： 本発明の実施では、ハール、２−６、および５−３ウェーブレット変換や様々なウェーブレット変換が使用される。これらは加算、除算および小幅な固定シフト(small fixed shifts)のみを必要とし、乗算や浮動小数点操作は不要である。
【００７０】
リフティングスキームによる計算： これらのフィルタはリフティングスキームを用いて計算され、現場（in-place）計算を可能とする。このことにより、レジスタの使用およびRAMの一時的占有を最小化し、照会先をローカルで済ませてキャッシュの使用効率を高める。
【００７１】
カスタマイズされたピラミッド構造でのピラミッド方式ウェーブレット変換： 本発明の実施では、ウェーブレット変換シーケンスにおいて、先の段階の結果となるデータの半分に基づいて各段階を計算する。その結果、総合した計算は各段階の数字から殆ど独立したものとなる。本発明の実施では、このピラミッドをカスタマイズして上記リフティングスキームの利点を活用し、レジスタの使用およびキャッシュメモリの処理能力をさらに効率化する。
【００７２】
ブロック構造： 多くのウェーブレット圧縮とは対照的に、本発明では画像を長方形のブロックに共有し、各ブロックを、他のブロックとは別個独立に処理を進める。これにより、メモリ参照をローカルで済ませることができ、プロセッサ内に残るデータを利用しながら変換ピラミッドの全体を実行できる。そのため、多くの場合プロセッサ内で移動するデータ量を大幅に小さくできる。このブロック構造は、とりわけハードウェアでの実施に有益である。それは信号を流す上で中間ストレージに大きな容量が不要となるからである。
【００７３】
ブロック境界フィルター： 本発明では、本出願で援用するアメリカ国特許出願番号10/418,363で詳述される修正フィルターの計算を行うことで、各ブロックの境界における明瞭なノイズを防止することもできる。
【００７４】
一時的彩度除去： 本発明の特徴により、フィールド毎の彩度差信号の処理も回避でき、その代わりに本出願で援用するアメリカ国特許出願番号10/447,514で詳述されている、一つのGOP（Group of Pictures）の彩度についての単フィールドを使用する。
【００７５】
三次元ウェーブレットを用いた時間圧縮（temporal compression）： 本発明の実施では、MPEGのような従来の動画圧縮手法における、非常にコストの高い動きの検出と補償の操作は用いない。その代わりに、本発明の実施ではフィールドからフィールドへの（field-to-field）時間ウェーブレット変換（temporal wavelet transform）を計算する。これにより計算コストを大幅に削減できる。この処理では、リフティングスキームとともに16bit・32bit（short integer)フィルタが使用されることもある。
【００７６】
二進数量子化： 本発明の実施例において、圧縮過程における量子化ステップは、係数分配域全体を通じて均一に二値化操作を行うことにより達成する。これにより従来の量子化において要求されたサンプル毎の乗算・除算を回避する。
【００７７】
パイリング： 本発明の実施例において、以下に述べるエントロピー符号化手法によって扱われるデータ量は、連続ゼロ変換を経て削減される。本発明の実施ではアメリカ国特許出願番号10/447,455において公開されている方法と発明が、並行処理アーキテクチャ上の連続したゼロの計上に利用される。
【００７８】
循環型（Cycle-efficient）エントロピー符号化： 本発明の実施例において、圧縮過程におけるエントロピー符号化のステップは、従来的表検索（table lookup）と入力シンボルの直接計算とを重ね合わせて処理するという技術により達成される。シンボル割り当ては特性化されているので、ライス−ゴロム符号化や、指数ゴロム符号化、Dyadic Monotonicのような単純なエントロピー符号化手法を用いることができる。エントロピー符号化の手法に何を選択するかは、プロセッサプラットホームの能力に従って変化する頻度が高い。
【００７９】
＜改良された適応情報源・通信路符号化結合(adaptive joint-source channel coding)＞
本発明の特徴によるウェーブレットベースコーデックのきめ細かい拡張性は、改良適応レートコントロールや、マルチキャスティング、情報源・通信路符号化結合(joint-source channel coding)を可能とする。コンピュータ上の複雑性を軽減し、本発明のウェーブレットアルゴリズムのより高い計算効率性により、ある瞬間の予測されたチャネル帯域幅とエラー状態に関する情報を、ソースコーダ、チャネルコーダ、レートコントローラの３つ全てにおいて利用することが可能となり、再構築された動画信号（図６参照）の瞬時および平均時双方の画質（ビデオレート対歪曲収差）管理を最適化する。本発明により改良された適応情報源・通信路符号化結合(adaptive joint-source channel coding)によって、無線通信会社やMMSサービスプロバイダは、サービスの質（Quality of Service : QoS）の効率性をより高くでき、個人消費者や企業顧客が求める価格まで引き下げることが可能となる。計算効率性をより高くしたアルゴリズムに基づいた改良適応情報源・通信路符号化結合(adaptive joint-source channel coding)を利用することで、ネットワーク上の異種混交をより高いレベルにおいて実現するサポートが可能となる。ここでの異種とは、通信の形式（無線と有線）、通信帯域、通信におけるノイズ又はエラーの特質、ユーザ使用機器、およびユーザ使用サービスという観点においてである。
【００８０】
＜改良されたモバイル画像送受信機のプラットホームアーキテクチャ＞
図７が表すのは、本発明の特徴と実施に従って改良されたモバイル画像送受信機のプラットホームアーキテクチャである。本発明の特徴による画像処理アプリケーションは、ソフトウェア単体実行アプリケーションとして実装され、RISCプロセッサにおいてネイティブコード（マシン語プログラム）若しくはJavaアプリケーションとして実行される。Javaコード化の加速操作はRISCプロセッサ自体に実装することが可能であり、若しくは別個のJavaアクセラレータICを使用して行うこともできる。このJavaアクセラレータはスタンドアローン（独立型）ICとして実装することも可能であり、またはこのICをSIPかSoCのいずれかにおける他の機能と統合することも可能である。
【００８１】
図７が示される、改良されたモバイル画像送受信機のプラットホームアーキテクチャは、モバイルビデオアプリケーションのための（これまでの機器やシステムでは必要とされるであろう）別個のDSP、ASIC、マルチメディアプロセッサ、またはRFD処理ブロックを不要とする。また、このアーキテクチャは携帯電話機における画像処理で必要とされるバッファメモリをも大幅に削減している。
【００８２】
図８は、本発明によるフルビデオ（VGA／30fps）のエンコーディングでは必要とされる計算性能を低く抑えることができていることを表している。この必要とされる性能の削減は、本件出願の優先出願日以後にMPEG-4およびH-264ビデオコーデックに基づいた現時点の技術が達成している能力値と比較対照して、という意味においてである。
【００８３】
図９が表すのは、市販されるカムコーダ（ビデオカメラ）付GSM携帯電話機のプラットホームにおける本発明の特徴を実装する部分である。既存のGSMベースバンド／マルチメディアSoC（図９で示されるTexas社製OMAP850）は、QCIF／15fpsビデオカメラ機能のため、ハードウェアクセラレータや、DSP、RISCプロセッサを必要とする。これに対し、本発明は、このプラットホームでVGA／30fpsビデオカメラ機能を実現する。この実現はRISCプロセッサ上で実行されるソフトウェアのみの使用で可能となり、ハードウェアクセラレータやDSPを必要としない。
【００８４】
図１０が表すのは、市販されるカムコーダ（ビデオカメラ）付CDMA携帯電話機のプラットホームにおける本発明の特徴を実装する部分である。既存のCDMAベースバンド／マルチメディアSoC（図１０で示されるQualcomm社製MSM6500）は、QCIF／15fpsカムコーダ（ビデオカメラ）機能のため、ハードウェアクセラレータや、DSP、RISCプロセッサを必要とする。これに対し、本発明は、このプラットホームでVGA／30fpsカムコーダ（ビデオカメラ）機能を実現する。この実現はRISCプロセッサ上で実行されるソフトウェアのみの使用で可能となり、ハードウェアクセラレータやDSPを必要としない。
【００８５】
＜改良されたモバイル機器を通じた画像サービスのプラットホームアーキテクチャ＞
本発明の実施態様である改良されたモバイル機器を通じた画像サービスのプラットホームアーキテクチャの構成要素（図11参照）：
・携帯電話機 １６０
・携帯電話中継基地（BTS） １６２
・中継基地管制機／無線通信管制機（BNS／RNC） １６４
・携帯電話交換センター（MSC） １６６
・ゲートウェイサービス接続ポイント（GSN） １６８
・モバイルマルチメディアサービス管制機（MMSC） １７０
・画像サービスダウンロードサーバー １７１
【００８６】
MMSCの典型的機能（図１１参照）：
・動画ゲートウェイ １７２
・通信会社サーバー １７４
・MMSアプリケーションサーバー １７６
・ストレージサーバー １７８
【００８７】
本発明の実施例の特徴に基づいた、改良された画像サービスのプラットホームの展開は次の手順を採る。
【００８８】
手順１
【００８９】
展開されたMMSCのアップデートに供するビデオゲートウェイトランスコーダアプリケーションおよび／又はビデオ通信・共有アプリケーションが利用可能であるという信号を、ネットワークに送信する。アップデートファイルは、ネットワークを通じて自動的に、若しくは手動操作でインストールされる。
【００９０】
手順２
【００９１】
ビデオゲートウェイトランスコーダアプリケーションおよび／又はビデオ通信・共有アプリケーションについて、ネットワークを通じて自動的に、若しくは手動操作により、インストールおよび設定を行う（図１２参照）。
【００９２】
手順３
【００９３】
モバイル動画ファイルがダウンロードおよびインストール可能であるという信号を、登録された携帯電話機に送信する。
【００９４】
手順４
【００９５】
登録機が受信し、取引決済が正常に完了すると、モバイルビデオファイルがダウンロードされ、インストールされる。
【００９６】
手順５
【００９７】
携帯電話機のアップグレードが完了した旨の信号をネットワークに送信する。サービスおよび関連アプリケーションを利用可能にする。モバイル動画ファイルの代金を、登録者の月額使用料金請求書に計上するために、記録更新を行う。
【００９８】
本発明の特徴として図１３が示すのは、ソフトウェアデコーダと伝送されるビデオストリームを一体化することで"自立再生"するビデオMMSの機能性が達成されることである。
【００９９】
本発明の特徴として図１４が示すのは、ビデオアプリケーションサーバーの複雑性、コスト、数を削減することである。このサーバーはメディアプロデュースサービスの展開に必要とされ、ユーザーが創作したビデオの貯蔵、検索、復旧だけでなく、ユーザー創作ビデオの自動ないし手動の編集も行われる。
【０１００】
本発明の特徴として図１５が示すのは、ビデオの送信・共有・呼出を行うプラットホームの機能的要素である。このプラットホームは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そしてビデオの編集およびデータの貯蔵・検索・復旧を組み入れたものである。
【０１０１】
本発明の特徴として図１６が示すのは、より高品質なマルチメディア携帯電話機とサービスを、より速く、より低コストで開発・展開できるという観点からの利点である。この利点には、革新的な個人マルチメディア市場プラットホームを展開できることが含まれ、このプラットホームにおいて、ユーザーが創作したオーディオないしビデオのコンテンツの"ソフト"コピー（ダウンロード）または"ハード"コピー（DVD）を、ユーザーは試聴や共有、売買することが可能となる。本発明によって、より効率的なビデオの"タグ付け"もまた可能となる。このタグ付けは、データベースの索引付けや、ネットワーク（RSS）情報提供、E-bay、Google、Yahoo、Microsoftや他のポータルサイトのような既存のウェーブ上の市場との橋渡しのサポートに用いられる。
【０１０２】
本発明の特徴として図１７が示すのは、革新的モバイルビデオサービスである。このサービスは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そしてビデオの編集およびデータの貯蔵、検索、復旧に基づいている。
【０１０３】
本発明の特徴として図１８が示すのは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そして動画の編集およびデータの貯蔵・検索・復旧を組み入れた、ビデオの送信・共有・呼出を行う上記のプラットホームのアプリケーションソフトである。このアプリケーションは、固定無線、移動無線および有線のアーキテクチャの要素を組み合わせた"集中型"ネットワークだけでなく、固定無線、移動無線、有線のネットワーク上で行われる新しい動画サービスを展開するために用いられる。
【０１０４】
＜パフォーマンス＞
本発明によって改良された、ウェーブレットに基づくモバイルビデオ動画処理アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、携帯送受信機（携帯電話）アーキテクチャおよびサービスプラットホームアーキテクチャを内包することにより、より高画質なモバイルビデオ画像、携帯送受信機（携帯電話）のコストの削減、アーキテクチャの単純化およびサービス展開コストの削減という目的が達成される。
【０１０５】
＜様々な実施例＞
本発明の特徴の実施により、モバイル画像送受信機アーキテクチャを高度なものとなる。たとえば、ソフトウェア単体実行のウェーブレットに基づく画像処理アプリケーションとして、実装オプションがいくつか考えうる（図１９参照）。画像処理アプリケーションは無線（OTA：over the air）ダウンロード（400a、400b、400c）を通じて、携帯送受信機（携帯電話）402aのベースバンドマルチメディア処理部、着脱可能ストレージ機器402b、または画像処理モジュール402cにインストールされる。希望すれば、画像処理アプリケーションは製造過程中または店頭販売時において携帯送受信機（携帯電話）のベースバンドマルチメディア処理部、着脱可能ストレージ機器、または画像処理モジュールにインストールすることも可能である。追加的実装オプションは、モバイル機器のアーキテクチャの発展型として組み入れることもまた可能である。
【０１０６】
本発明の特徴により、モバイル画像送受信機のパフォーマンスはさらに向上し、コストと電気消費は一層削減される。このことは、ハードウェアベースの処理リソースを通じて計算機的要素を加速化することを手段とする。その理由は、現在発展中であるモバイル機器の計算処理ハードウェア（ASIC、DSP、マルチメディアプロセッサ、RPD）や、集積回路技術（SoC、SIP）を活用するためである。これらの携帯電話機におけるハードウェアベースの処理リソースを集中させるため、ハードウェアのみによるオプションが実行されうる（図２０参照）。このハードウェアオプションには、携帯送受信機（携帯電話）のベースバンドマルチメディア処理部や着脱可能ストレージ機器、画像処理モジュールが含まれる。
【０１０７】
図２１に示されるように、本発明による画像処理アプリケーションによって提供される複合型アーキテクチャは、ハードウェア面におけるコンピュータ的な集中的、反復的、固定的である機能の実行および、ソフトウェア面における製造後に改良が望まれ、必要とされる機能の実行を通じて、処理能力向上に資する。
【０１０８】
本発明の特徴によって、モバイルカムコーダ（ビデオカメラ）機器のアーキテクチャ、配置およびメンテナンスを単純化できる可能性を、図２２は示している。
【０１０９】
＜効果＞
本発明におけるソフトウェア単体実行による画像処理は、マルチメディア携帯電話機でのベースバンドプロセッサとビデオアクセラレータのコストおよび必要部品を大幅に削減させる。無線（OTA：over the air）ダウンロードを経由した撮影後編集コーデックのインストール・メンテナンス機能を併用することで、このソフトウェア単体実行による画像処理によって、携帯電話機開発と動画通信サービス展開の双方の複雑性、リスクおよびコストの大幅な削減を可能とする。
【０１１０】
本発明により、携帯電話通信会社は最上級のモバイルビデオ通信・共有プラットホームを利用でき、ビデオ画質、携帯送受信機（携帯電話）小売価格およびサービス展開コストの点で、大衆市場における個人消費者や企業顧客の需要に応えることが可能となる。本発明は、カムコーダ（ビデオカメラ）付携帯電話機で、フルサイズ動画（VGA：640×480ピクセル）を毎秒30フレーム（fps）でリアルタイム撮影することを可能とする最高品質のソフトウェア単体実行アプリケーションを提供する。これは、本発明の特徴によって、圧倒的多数のマルチメディア携帯送受信機（携帯電話）に既に内蔵されている標準的RISCプロセッサを使用するだけで可能となる。携帯電話通信会社は、本発明によって単純化された動画処理・流通の技術と、新しいソフトウェア単体実行プラットホームとを統合化して、既存の携帯送受信機（携帯電話）やモバイルマルチメディアメッセージサービス（MMS）のインフラを使用した包括的展開を可能としうる。上記ソフトウェア単体実行モバイルビデオカメラアプリケーションを補完するものとして、携帯電話通信会社は、本発明によるコンテンツ管理プラットホームの特徴を利用することで、圧縮された画像・動画を、この技術に従って音声や文章と統合し、完成されたモバイルマルチメディアメッセージや"着信音"とするモジュールが利用できる。このコンテンツ管理プラットホームでは、このようなモジュールだけでなく、オン・ザ・フライ（中間出力を必要としない）編集や、サムネイルプレビュー、マルチメディアメールボックス、オンラインストレージ、共有、マーケティングサービスおよび登録管理をも利用可能とする。
【０１１１】
下記の例１では、デモンストレーションの構成要素、設定および操作が記載されているが、このデモが紹介するのは本発明におけるソフトウェアのみによるモバイルビデオメッセージプラットホームの特徴を実施することで得られる機能と利点である。デモでは市販されているGSM/GPRSマルチメディア携帯送受信機（携帯電話）が使用され、あらゆる商業的GSM/GPRSネットワークにおいて操作されることが意図された。実演は充分な成功を収めた。このデモンストレーションはCDMA携帯送受信機（携帯電話）を使用し、商業的CDMAネットワークにおいて操作される形でも容易に行うことができる。例１のデモでは、"Droplet"というコード名が付けられ、例１においてそのように標示された、デモと一連のファイルが実行される。
例１
図２３と図２４で図示されるように、デモンストレーションは次の５つの要素を含む。
１．MMSサービスプロバイダーのサーバーコンピュータから、本発明によるソフトウェア単体実行の"DTV"ビデオコーデックアプリケーションを、無線通信を介して（OTA：over the air）ダウンロードして、マルチメディア携帯送受信機（携帯電話）にインストールする。
２．DTVビデオコーデックを使って、マルチメディア携帯送受信機（携帯電話）の内の高画質（VGA、30fps）ビデオメッセージを圧縮する。
３．圧縮されたビデオメッセージ（本発明によるDVTフォーマット形式）をMMSサーバに送信する。これはコンピュータやテレビに転送・再生するためのフルサイズ解像度（VGA/30fps）でも、携帯送受信機（携帯電話）への転送・再生用に縮小した低解像度（QCIF/15fps）でも同様である。
４．ネットワークに接続されたコンピュータへのメールアラートや携帯送受信機（携帯電話）へのSMSアラートを通じて、MMSサーバから、圧縮されたビデオ画像がダウンロード可能となったという知らせが送信される。
５．圧縮されたビデオメッセージは、本発明によるDTVデコーダと一緒にダウンロードされる。これは"自立再生"（"self-playing"）機能、すなわち、ネット接続コンピュータ上（VGA/30fps）または携帯送受信機（携帯電話）上（QCIF/15fps）でデコードし、パソコンや携帯送受信機（携帯電話）に既にインストールされている一般的ビデオプレーヤーソフトを使って再生できるようにするためである。
【０１１２】
＜ビデオメッセージデモに使用された機器＞
２．１ 携帯送受信機（携帯電話）
【０１１３】
例１に記述される実験の説明。以下の二種類の市販されているGSM/GPRSマルチメディア携帯送受信機（携帯電話）を使用する。類似するその他多くのマルチメディア携帯送受信機（携帯電話）でも代替可能である。
【０１１４】
２．１．１ T-Mobile MDA-II PDA-Phone（HTC社製）
・ローカルGSM/GPRSネットワークで使用可能な状態にある
・インターネット上のデータにアクセスできる状態にある
・MDA-II Phoneクレードル（携帯電話機とパソコンを接続するUSB2.0ケーブル付属）
・OS：Windows Mobile 2003 Pocket PC with Phone Edition
【０１１５】
２．１．２ O2 Xphone Smartphone（HTC社製）
・ローカルGSM/GPRSネットワークで使用可能な状態にある
・インターネット上のデータにアクセスできる状態にある
・携帯送受信機（携帯電話）とパソコンを接続するUSB2.0ケーブル
・OS：Windows Mobile 2003 Smartphone Edition
【０１１６】
２．２． コンピュータ
【０１１７】
２．２．１ パーソナルコンピュータ（ラップトップ型あるいはデスクトップ型）
【０１１８】
例１に記述される実験の説明。ラップトップ型コンピュータを使用し、以下の設定を行う。
・モデル：ソニー社製 Vaio PCG-K33P
・プロセッサ／メモリ：Pentium 4 3.06GHz、512MB RAM
・グラフィックス：ATI社製 Radeon IGP 345M（64MB RAM）
・ストレージ：60GB
・接続ポート：IEEE1394ポート×1、USB2.0ポート×2
・OS：Windows XP
・プリインストールされているビデオアプリケーション：Windows Movie Maker
【０１１９】
２．２．２ リモートサーバー
【０１２０】
例１に記述される実験の説明。UNIX規格のリモートサーバーを使用し、以下のMMS機能を実演する。
【０１２１】
MDA-II携帯送受信機（携帯電話）によるダウンロード用DTVコーデックの保存
・Xphone機によるダウンロード用DTVプレイヤーアプリケーションを保存する
・MDA-II機から圧縮されたビデオメッセージを受信し、保存もしくは転送する。
・SMSメッセージを送信し、ビデオメッセージがダウンロード可能であることをXphone機に知らせる。
・Xphone機のブラウザを介したアクセスにより、DTVプレイヤーアプリケーションおよびQCIF/15fps動画メッセージの双方をダウンロードすることが可能になる。
【０１２２】
２．３ ビデオ撮影（ビデオキャプチャ）
【０１２３】
例１に記述される実験の説明。次の市販カムコーダ（ビデオカメラ）を使用して、外部素材を高画質動画シーケンスとし、携帯送受信機（携帯電話）で実行される本発明のDTVコーデックにより圧縮する。
・キャノン社製 ZR65DV Camcorder（カムコーダ（ビデオカメラ）とPVとの接続にはIEEE1394ケーブルを使用）
【０１２４】
ほとんどの市販カメラ付携帯電話機で現在使用されている低機能な画像モジュールではなく、外部カムコーダ（ビデオカメラ）を使用することで、本発明のDTVコーデックとモバイルビデオ通信能力の有利性をより効果的に実例説明することが可能となる。
【０１２５】
カムコーダ（ビデオカメラ）で撮影され、圧縮されたデジタルビデオ動画ファイルはまずパソコン上でUYVY動画フォーマットに伸展変換される。その後MDA-II携帯送受信機（携帯電話）に転送され、本発明のDTVコーデックによってエンコード／圧縮される。UYVY形式は典型的なビデオフォーマットであり、マルチメディア携帯送受信機（携帯電話）におけるビデオコーデックに装填されることが予想される。
【０１２６】
＜実験のための機器設定＞
３．１ パソコンの設定
【０１２７】
３．１．１ 本発明を利用したドロップレットデモパッケージのダウンロード
・URL「http://droplet-tech.com/demo_partner_access.html」をパソコンのウェブブラウザで開く。
・リンク「Demo Package -- January 2005」（WinZip圧縮ファイル）を選択する。
・このリンクをクリックし、パソコンにデモパッケージファイルのダウンロードを開始する。
・選択したフォルダの中にZipファイルを置く。
・Zipファイルを解凍すると、以下のファイル／フォルダが展開される。
○デモパッケージ「read me」文書ファイル（Demo_package_readme.html）
○以下のフォルダ
・MDA_DTV：MDA-IIクライアントUlアプリケーションソフト
・Xphone_DTV：XphoneUlクライアントアプリケーションソフト
・PC_player：パソコン上でDTVファイルを実行するファイル
・Virtual_Dub1.6.3：異なるビデオフォーマットを相互変換するPC用アプリケーションソフト
・MMS_server：サーバーコンピュータのためのサンプルモニタリングスクリプトプログラム
・Canon_driver：ビデオカメラのドライバソフト
・PHMRegEditor：レジストリエディタ（MDA-IIとXphoneのインストール用）
・Ewesoft：Xphone 用Java仮装マシーン
【０１２８】
３．１．２ J9 JVM（Java仮想マシン）インストレーション・パッケージをダウンロードする。
・URL「http://droplet−tech.com/ftp_accss.html」をパソコンのウェブブラウザで開く。・
・“J9−JVM”（WinZip アーカイブ）リンクを選択する
・J9 JVMパッケージをＰＣにダウンロード開始するためにこのリンクをクリックする
・ジップ・ファイル“weme57prod_pp_1.zip”を選択したフォルダに入れる。
【０１２９】
３．１．３ DirectX 9.0 SDK (DTVのPCプレイヤで使用）をダウンロードしてインストールする。
・無料のSDKがマイクロソフトのウェーブサイトからダウンロードできる。
・http://msdn.microsoft.com/library/default.asp?url=/downloads/list/direct.asp
・このダウンロードは大きいので（〜230MB）注意を要する.
・DirectX Utilities＞GraphEdit機能を作動させて有効に設定されたかを確認する。
【０１３０】
３．１．４ 本発明にかかるDroplet DTV PCプレーヤをパソコン（PC）上にインストールする。
・ソフトウェア・パッケージはPC_player のディレクトリの中のデモ・パッケージで見つけることができる。ファイルはPC_player.zipと呼ばれる。
・テストPCの" C: "ドライブに " C: ＼DTV_PCplayer_Demo＼ "としてパッケージを開く（解凍する）。 もし、実際のパスが異なる場合は、RegisterFilter.batとUnRegisterFilter.batを編集する。
・フォルダを開き、バッチ・ファイル" RegisterFilter. bat"をダブルクリックしてDirectShowフィルタを登録する。
【０１３１】
３．１．５ PCにVirtual Dubをダウンロードしインストールする。
デモの現在のバージョンでは、Virtual Dubはカムコーダ（ビデオカメラ）で撮影されたように、圧縮したDVビデオ・ファイルに変換され、 PCの中の復元（減圧）したUYVYビデオ・フォーマットに入れられていた。復元されたビデオファイルはその後、MDA-II携帯電話へ本発明のDTV コーデック（codec）による符号づけ/圧縮のために入力される。UYVYはマルチメディア携帯電話のビデオコーデック（codec）へ入力される典型的なビデオフォーマットである。
・ソフトウェア・パッケージは、Virtual_Dubディレクトリのデモ・パッケージの中で見つかる。
・一方、ソフトウェア・パッケージも次のURLで見つけることができる：
http://jaist.dl.sourceforge.net/sourceforge/virtualdub/VirtualDub-1.6.3.zip
・Virtual_Dubでは、ディレクトリがVirtualDub.exeと呼ばれるファイルである。これは選択されており、アプリケーションは作動すると確認されている。
【０１３２】
３．１．６ PCにCanon ZR65カムコーダ（camcorder）・ドライバをインストール
する
・Canonドライバ・パッケージは、Canon_driverディレクトリのデモ・パッケージの中で見つかる。
・一方、ドライバもhttp://www.canon.comで見つけることができる。
・Canon_driverディレクトリは開かれ、またサブフォルダ"ZR65WI503EN"と、サブフォルダ " 英語（English）" が選択され、さらにその後、実行可能なプログラム" SETUP.EXE "がCanonカムコーダ（camcorder）・ドライバをインストールするために作動する。
【０１３３】
３．２ 遠隔MMSサーバの構成
デモの中で、遠隔MMSサーバはFTPサーバ〔携帯電話（携帯送受信機）へのビデオコーデックファイルのダウンロードを可能にし、記録する携帯電話（携帯送受信機）からのビデオファイルのネットワークストレージを可能にする〕、としても、メール・サーバ〔記録する携帯電話（携帯送受信機）からビデオメッセージのemail/SMS通知、およびネットワーキングされたコンピューターおよび他の携帯電話（携帯送受信機）によるダウンロードを可能にすること〕としても機能する。機能的に、サーバは送信中のビデオメッセージを他の携帯電話（携帯送受信機）へSMS通知するためにSMSメッセージを送信することができなければならない。
・次のディレクトリを持つためにFTPサイトを形成する。
○ public_html
・あらかじめ、MDA-II携帯電話（携帯送受信機）による後のダウンロードのために、サーバにDTVコーデック(ファイルDtvMDADemo.exe)をインストールする。このファイルはトップレベルのバイナリモードでFTPサーバに転送される。
・あらかじめXphoneによる次のダウンロードのために、サーバにDTVデコーダ(ファイルDtvXphoneDemo.exe)をインストールする。 このファイルはトップレベルのバイナリモードでFTPサーバに転送される。
・サンプル・モニタリング・スクリプトはMMS_serverディレクトリ(ファイル名: monitor.php)のDropletデモ・パッケージの中にある。
・このモニタリング・スクリプトはUnixベースのサーバ上ではcrontabとされる。このスクリプトは、ftp:/public_htmlディレクトリ中で新しいファイル(.Inkで終わる)の存在を毎分モニターする。
・もしユーザがDropletデモ・サーバ以外にサーバ上で上記のサンプル・モニタリング・スクリプトを使用することに決めれば、それがローカルのサーバ/ネットワーク環境としてカスタマイズされる。
【０１３４】
３．３ MDA-IIの構成
クレイドル/USBケーブルで(前記セクション３．１のようにあらかじめ構成された)PCにMDA-IIを接続する。
【０１３５】
３．３．１ 安定GPRS接続のためのレジストリ・エントリの修正
安定GPRS接続を確保するために、デフォルトセッティングの60秒より大きくなるようにタイムアウト期間を増加する。携帯電話（携帯送受信機）メーカ（HTC）は推奨できる変更レジストリを提供する。もし、装置上にレジストリ・エディタがインストールされていない場合は、最初にDropletのデモ・パッケージに含まれている" PHMRegEditor "のディレクトリによりレジストリ・エディタをインストールする。
・PCの仮ディレクトリにファイルPHMRegEdit.msiをインストールする。
・PCの同じディレクトリにCABファイルであるregedit.Mrln_ARM.CABをインストールする
・ダブルクリックしてPHMRegEdit.msiを作動させ、その後の指示に従う。
・MDA-IIと同期させる
・MDA-II上のWindowsズ・ディレクトリにregedit.Mrln_ARM.CABファイルをコピーする。
・MDA-IIの中のファイルをダブルクリックすることにより、CABファイルが適切にインストールされるであろう。
・PHMRegEdit.msiを作動させて、指示に従う。
生じるプログラムPHMEditorは、ディレクトリ＼プログラム・ファイル＼PHMツールのMDA-IIにインストールされる。
・上記のディレクトリのプログラムregedit(レジストリ・エディタ)をスタートする
○ Select
HKEY_LOCAL_MACHlNE＼SOFTWARE＼Microsoft＼ConnMgr＼Planner＼Settings
○ CacheTimeの設定を300（5分をタイムアウト期間とする)に変更する。
○ SuspendResumeの設定を〜GPRS(タイムアウトを考慮に入れない)に変更する
・レジストリ・エディタから出る。
・変更した設定が効果を現わすようにソフトリセットを作動させる。
【０１３６】
３．３．２ IBM J9 JVMをインストールする。
・前述の３．３．１でPC上にダウンロードした" weme57prod_pp_wm_1.zip "ファイルを開く（解凍する）。５つのファイルがある。
○ inst_pp_wm.html
○ readme_pp_wm.html
○ weme-wm2003-arm-ppro10-5.7.1-P-20040723-1833.bin
○ weme-wm2003-arm-ppro10-5.7.1-P-20040723-1833.exe
○ weme57_ppc_pp_1.pdf
・inst_pp_wm.html.ファイルを開く。インストレーションの指令を呼んでその指示に従う。
【０１３７】
３．３．３ MDA-II携帯電話（携帯送受信機）のUlアプリケーションをインストールする。
３．１．１で既に記述したようにPCの上で既に開かれた（解凍された）ファイルの中でこのアプリケーションは見つけられる。
・ディレクトリMDA_DTVの中のデモ・パッケージには"mms_client"と呼ばれるサブフォルダが含まれている。これらは３つのファイルからなる。
デモ・パッケージには
○ " application.properties "
○ "Droplet.jar "
○ "Droplet.lnk "
・ファイル" application.properties"と" Droplet.jar "をPCからMDAディレクリ＼ProgramFiles＼J9＼PPRO10＼examplesへコピィする。
・ファイル" Droplet.lnk "をMDAディレクトリ＼windous＼StartMenuにコピーする。
・MDA-IIが正確に形成されたことを確認するために、スタート・メニュをクリックする。Dropletと呼ばれるアイコンが利用可能となる。
・機能性を確認するために、Dropletアイコンを選択すると新しいウィンドウが出てくる。それは３つのボタンからなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
注：MDA-II携帯電話（携帯送受信機）Ulアプリケーションのための情報コードが例えばディレクトリMDA_DTV＼mms_client_srcの下で利用可能である。
これによりMDA-IIはデモとして形成される。
【０１３８】
３．３．４ Pictpocket映画・ビデオ・プレーヤ(オプション)をインストールする。
MDA-IIの上のデフォルト・ビデオ・プレーヤーがデコードされたDropletビデオ・ファイルで見ることができるので、このステップはオプションである。サードパーティー（部外第三者）のビデオ・プレーヤをインストールすることにより、本発明にかかるデコードされたビデオファイルが多機能モバイル装置ビデオ・プレーヤーと互換性あることが実証される。
・MDA-II携帯電話（携帯送受信機）上で、Digisoftからの"Pictpocket映画"アプリケーションがインストールされる。
・Pictpocket映画の14日間お試しバージョンはベンダ（販売主側）のウェーブサイト: www.digisoftdirect.comからダウンロードすることができる。
【０１３９】
３．４ Xphoneを形成する。
USBケーブルでPCにXphoneを接続する。
【０１４０】
３．４．１ 安定GPRS接続へレジストリ・エントリを修正する
安定したGPRS接続を保証するために、タイムアウト期間を60秒のデフォルト設定より大きくするように増加する必要がある。携帯電話（携帯送受信機）メーカ(HTC)は推奨できるレジストリの変更を提示した。もし、装置にレジストリ・エディタがインストールされていない場合は、まず" PHMRegEditor " ディレクトリにあるDropletデモ・パッケージに含まれているレジストリ・エディタをインストールする。
・PC上のTemp（仮の）ディレクトリにファイルPHMRegEdit.msiをインストールする。
・PC上の同じディレクトリ中にCABファイルregedit.Mrln_ARM.CABをインストールする。
・ダブルクリックすることによりPHMRegEdit.msiを作動さて、指示に従う。
・XphoneをPCと同期させる。
・Xphone上のWindows・ディレクトリにファイルregedit.Mrln_ARM.CABをコピーする。
・Xphoneの中のそのファイルをダブルクリックしてCABファイルを適切にインストールする。
・PHMRegEdit.msiを作動させて、指示に従う。
生じるプログラムPHMEditorは、ディレクトリ＼プログラム・ファイル＼PHMツールのXphoneにインストールされる。
・上記のディレクトリからのプログラムregedit(レジストリ・エディタ)をスタートさせる。
○ Select
HKEY_LOCAL_MACHlNE＼SOFTWARE＼Microsoft＼ConnMgr＼Planner＼Settings
○ CacheTimeの設定を300（5分をタイムアウト期間とする)に変更する。
○ SuspendResumeの設定を〜GPRS(タイムアウトを考慮に入れない)に変更する
・レジストリ・エディタから出る。
・変更した設定が効果を現わすようにソフト・リセットを作動させる。
【０１４１】
３．４．２ Ewesoft JVMをインストールする。
・ディレクトリEwesoftの中のデモ・パッケージにはEwe143-CAB-SmartPhone.zipと呼ばれるファイルがある。PC上でこのファイルを解凍する。Ewe143-SmartPhone2003.arm.CAB-と呼ばれるファイルを使用する。
・Storage＼windows＼Start Menu＼Accessoriesと呼ばれるXphoneディレクトリにEwe-SmartPhone2003.arm.CABファイルをコピーする。
・Accessoriesを開始させる。CABファイルはメニュー項目として表示される
CABファイルを選択し、次にVMをインストールする。
・インストールにより、スタート・メニューに現われる新しいEweフォルダが作成される。
・そのフォルダの中でEwe VM自体と、正確なインストールを確認する"Solitaire"デモ・アプリケーションを見つける。
【０１４２】
３．４．３ Xphone携帯電話（携帯送受信機）Ulアプリケーションのインストール
・ディレクトリXphone_DTVの中のデモ・パッケージには"mms_client"と呼ばれるサブフォルダがある。これらは３つのファイルからなる。
○ " application.properties "
○ "Droplet.jar "
○ "Droplet.lnk "
・ファイル" application.properties"と" Droplet.jar "をPCからXphoneディレクリ/Storage/windous/StartMenu/Ewe/へコピーする。
・ファイル" Droplet.lnk "をXphoneディレクトリ: /Storage/windous/StartMenu/にコピーする。
・Xphoneが正確に形成されたことを確認するために、スタート・メニューをクリックする。Dropletと呼ばれるアイコンが利用可能となる。
・機能性を確認するために、Dropletアイコンを選択すると新しいウィンドウが出てくる。それは３つのボタンからなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
これによりMDA-IIはデモとして形成される。
【０１４３】
＜デモの作動（実行）＞
４．１ MDA-II上にビデオコーデックをダウンロードしてインストールする
・MDAから、スタート・メニューをクリックするとDropletアイコンがリストに現われる。
・Dropletアイコンを選択すると新しいウィンドウが出てくる。それは3つボタンの選択からなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
・Download/installコーデックボタンをクリックする。
・次のメッセージが現れる。
○ FTPホスト: xx.xx.xx.xxxに接続
(これはサーバのIPアドレスとなる)
○ 接続
○ サーバにログイン
○ ログイン完了
○ コーデックファイルのダウンロードの開始
○ ダウンロードの完了
○ ビデオコーデックのインストール成功。接続終了
・コーデックのダウンロードが成功したことを確認するために、MDA上のマイドキュメント・ディレクトリに進む。DtvMDADemo.exeと呼ばれるファイルが、ダウンロードされた日付およびタイムスタンプ付きで提示される。
【０１４４】
４．２ 携帯電話（携帯送受信機）によるビデオメッセージの記録
このバージョンのデモでは、MDA-II携帯電話（携帯送受信機）は、外部のビデオカメラ（ビデオカムコーダー）からの圧縮されていない高品質の生中継ビデオが入力され符号化／圧縮（エンコード／コンプレス）されていた。一方、MDA-II はVGA撮影できるカメラを装備しているが、それは、単に静止画像をその解像度で撮影するにすぎない。MDA-IIによるビデオ撮影は、QCIF(装置上の3GPPフォーマットで自動的に圧縮される10fpsビデオ)に制限されている。
【０１４５】
４．２．１ カムコーダ（ビデオカメラ）のPCへの接続
・Firewire(1394)ケーブルを使用して、PCにキャノン・ビデオカメラ（カムコーダ）を接続する。ビデオカメラ（カムコーダ）には４ピンのコネクター端子がある。
・一旦Firewireケーブルが接続され、ビデオカメラ（カムコーダ）が"カメラ"モードに調整されれば、PCのOS(このデモ・バージョンではWindowsXP Professional)は撮影のいくつかのオプションを供する。
・"Windows Movie Maker"を選択すれば、映画メーカー・アプリケーションが導入される。
【０１４６】
４．２．２ PC上にカムコーダ（ビデオカメラ）からビデオシーケンスを取得する。
・映画メーカーの中から"ビデオ装置からの取得"を選択し、PC上にそれを格納するための取得ファイルと場所の名前を選択する。
・次のスクリーンではビデオセッティングが求められ；"デジタル装置フォーマット(DV- AVI)"を選択する。それは、DVフォーマットでのビデオを撮影であり、高品質(ほとんどlossless)なビデオ撮影フォーマットである。
・次のスクリーンは、"撮影開始"と"撮影終了"のインターフェースとともに撮影されたビデオのプレビュウ・ウインドウを表示する。多くの無線携帯電話（携帯送受信機）では大容量の搭載記憶素子を装備してないので、2-3秒のフルモーションビデオ(60-90フレーム）がより速いコンピュータ化の録画として示唆されていた。
・一旦ビデオシーケンスが録画されれば.AVIフォーマットにある、Windows Movie Makerプログラムから出ることができる。
・このドキュメントについては、レコーダ・ファイルの名前は" testDV.avi "と仮定されている。(ファイルは.AVIフォーマットにあり、すべての個々のフレームの付いたインターリーブされたオーディオ・ビデオファイルは次々に整えられる。)。
【０１４７】
４．２．３ PC上の圧縮されてないDVビデオ・シーケンス
・前のステップで撮影されたビデオは、インテグレーテッド（統合された）オーディオとしてDVフォーマット(720×480ピクセル、約28Mbpsで30 fps)に圧縮される。フルモーション撮影をシミュレートするために、ビデオは通常の圧縮されてないUYVYフォーマットで、VGAサイズ(640×480ピクセル)にスケールを落として、オーディオ情報は分離する。
・このデモについては、MDAにエンコードするために２つのソース・ファイルを作成する必要がある： １つはVGA(640×480)@30fpsであり、他はQClF(160×144)@15fpsである。
・VirtualDub1.6.3ディレクトリから"VirtualDub.exe"を実行可能に作動する。
a. "File"の中で"Open video file"を使用し、" testDV.avi "をオプションで使用する
b. "Audio"の中で"No audio"ファイルをオプションで選択する
c. "Video"の中で"Filters"をオプションで選択する。"Add（追加）"を選び、メニューをスクロールダウンして"resize（サイズ変更）"フィルタを設定する。"New width（新しい幅）"として640、"New height（新しい高さ）"として480をセットする。""Filter Mode（フィルタ・モード）"として"Precise Bicubic (A=0.75)"をセットする。
d. "Video"の中で"Color depth（色の深さ）" を選択する。左のコラムの出力フォーマットに" 4:2:2 YCbCr(UYVY) " フォーマットをセットする。
e. "Video"の中で"Compression（圧縮）" オプションが"Uncompressed（圧縮されてない）RGB/YC bCr"にセットされていることを確認する。
f. もし非常に長いビデオシーケンスが撮影された場合は、"Video"の中の"Select range"オプションを選択することにより短くすることができる。典型的に合理的に操作できるビデオの大規模は60-90のフレーム(2-3秒のビデオ)である。スタートは撮影されるビデオによって、始めから（"Start offset" of 0）でも、あるいはどこかのシーケンスの途中からでもよい。例えば、2秒(60フレーム)の圧縮されていないUYVYビデオVGA(640x480)シーケンスは、コンピューター上で36MBのデータである。
g. 圧縮されていないファイルの保存のために"File" と"Save as AVI..."を選択する。"testVGA_UYVY.avi "ファイルを呼ぶ。エンコードされる生の(圧縮されていない)UYVY VGA入力ファイルであり、MDA-II携帯電話（携帯送受信機）上で符号化され／圧縮される。
・QCIF（GPRS接続によって別の携帯電話（携帯送受信機）にビデオ・クリップを送るために推奨される）用のファイルの作成:
○ 上記ステップcで、１６０を入力する"New width（新しい幅）"として１６０を入力する。"New height（新しい高さ）"として１４４を入力する。
○ 上記ステップgで、ファイルを"testVGA_UYVY.avi "と命名する。
【０１４８】
４．２．４ 圧縮されていないビデオシーケンスのMDA-II携帯電話（携帯送受信機）への転送
・圧縮されていないビデオファイル"testVGA_UYVY.avi"と"testQcif_UYVY.avi"をPCからMDAへ転送する。
・圧縮するために、MDA-IIのマイドキュメント・ディレクトリにこれらのファイルをコピーする。
・中間ストレージのために、上記の大きなソース・ファイル(圧縮されていないビデオ入力)は、装置の"Storage Card"に入れられ、次に、圧縮のためにマイドキュメント・ディレクトリにコピーされる。
・PCからMDAを分離する。
この時点で、圧縮されていないビデオシーケンスが携帯電話（携帯送受信機）の中にあり、従前にダウンロードされ携帯電話（携帯送受信機）にインストールされているエンコーダ・ソフトウェアである本発明にかかる"Droplet"で圧縮される準備ができている状態である。
【０１４９】
４．２．５ MDA-II携帯電話（携帯送受信機）の中での在来のビデオシーケンスの圧縮
ビデオコーデックおよび圧縮されていないビデオシーケンスが、MDA-II 携帯電話（携帯送受信機）に旨くダウンロードされ、携帯電話（携帯送受信機）には符号化（encode）／圧縮を実行する準備がととのった。
・MDA上で、MyDocumentsディレクトリに行く。
・" DtvMDADemo " アプリケーションを見つけて選択する。
・UIウィンドウが出て、順次ユーザは情報を入力する:
○ ソース・ファイル：ファイルの名前にはUYVYフォーマットに圧縮されていないビデオを含んでいる(これは前のステップで生成されたファイルである)。
○ デスティネーション（指定）ファイル：このファイルには圧縮されたビデオシーケンスが格納される。(圧縮されたファイルは .dtvで終わる拡張子を持つ) このデモでは、ファイル名はbitstream.dtvとなる。
○ 水平および垂直のフレームサイズ
○ VGAビデオをエンコード（符号化）するためのパラメーターはそれぞれ640と480
○ QCIFビデオをエンコード（符号化）するためのパラメーターはそれぞれ160と144
○ 入力ファイルのタイプ：YUV 4:2:2、デフォルト（標準設定）
○ 圧縮レート：12レベル、デフォルト（標準設定）
○ 圧縮されるフレームの範囲：典型的には"全て"をセットする。(注：もしユーザがこれを変更することを選択しても、DTVが1グループの画像として2つのフレームを処理するので、指定するフレームの総数は偶数となる。)
○ "エンコード（符号化）する"か"デコード（復元）する"あるいは両方を選択する。
○ スタートを選択する。
・首尾よく完了したら、上記のデスティネーション（指定）ファイル領域で特定の圧縮されたbitstream.dtvファイルはMDA-II上の"マイドキュメント"のディレクトリの中に作成される。
・ファイル名が変更された場合、.dtvファイル拡張子を維持することが重要である。
・注意：上記の符号化は２度実行される。一度はQCI F/15fpsのためで、もう一度はVGA/30fpsのためである。
・復元されたQCIFファイルも、GPRSネットワークによる他の携帯電話（携帯送受信機）へのMMS送信されるために、MDA-IIの"マイドキュメント＼DTV Output" に保存される。
【０１５０】
４．３ PC上でのVGA/30 fpsビデオ・メッセージの転送/再生
PC上でエンコードされたVGAファイルを実行には、MDA-IIからPCにファイルを転送する必要がある。現在のGPRSデータ転送速度(~20-40kb/s)ではモバイルネットワークにより、圧縮したVGAビデオを1秒送るのにおよそ16秒かかる。高速3GまたはWiFiネットワークによれば、取り敢えずフルVGA/30 fpsビデオ・ファイルのより効率的な転送が可能である。このデモでは、MDA-II携帯電話（携帯送受信機）とPCとの間のUSB接続がファイル・トランスファーを促進するために利用される。
・cradle/USBによってPCにMDA-IIを接続する。(これが現在のデジタル・カメラやカムコーダ（ビデオカメラ）がデジタル写真やビデオを転送するためにホームPCに接続される標準の方法であることに注意する。)
・MDA-IIからPCに、エンコードされたか又は圧縮されたVGAファイル
(＼MyDocument＼bitstream.dtv)をコピーする。ファイルは次のディレクトリにコピーされる："C: ＼DTV_PCplayer_Demo＼"
・MDA-II装置はUSB1ポートに装備されているので、USB2へのVGA/30 fpsファイルのより速い転送がPCで可能であり、MDA-IIのリムーバブルメモリーカードに最初にそれらをコピーし、次に、カードを離脱し、PCのUSB2ポートにそれを直接接続して、転送のためのUSB2カード読み取り機を使用することにより実現することができる。
・一旦ファイル・トランスファーが完了したら、PCのディレクトリ"C: ＼DTV_PCplayer_Demo＼"に行き、ファイル"dtvplayer.grf"または" dtvplayer_Win2K.gif"(OS付属)をダブルクリックし、次に、VGA/30 fpsビデオを見るために" プレー " ボタン（またはメニュー項目の" プレー "を選択）をクリックする。
・クリップを止めるためには、単に、アプリケーションを出ることである(GraphEdit)。
【０１５１】
４．４ GPRSによるMMSメッセージとしてのQCIF/15 fpsビデオの送信
このセクションは、GPRSを介してMDA-II携帯電話（携帯送受信機）からMMSサーバへ圧縮したQCIF/15fpsビデオを送信する能力を示す。SMS通知が、ビデオのMMSがダウンロードと再生の準備ができること表示して、目標となった携帯電話（携帯送受信機）(この場合Xphone)に送られる。一方、目標とされた受信装置がネットワーキングされたコンピューターである場合、電子email通知が送られる。
【０１５２】
４．４．１ GPRSによるMMSサーバへのQCIF/15 fpsビデオの送信
・MDA-IIのスタート・メニューをクリックすると、Dropletアイコンはメニュ・リストが現われる。
・Dropletアイコンを選択すると、新しいウィンドウが現れる。それは３つの選択ボタンからなる。
○ コーデックのダウンロード/インストール
○ ビデオ撮影
○ ビデオメッセージの送信
・"ビデオメッセージ送信"ボタンをクリックする。
・ファイルを選択する新しいウィンドウが開く。
○ 送りたいファイル(この場合圧縮したQCIF/15 fpsビデオ・ファイル)を選択
○ 新しいウィンドウが、目標となる電話番号/emailアドレスに入るために開く。
○ emailアドレスが入力されると(@シンボルの存在によって確認され)、選択されたファイルは、email通知とともに送信される。
○ もし、" @ "の記号のない文字列が入力された場合、file/SMS通知がmailto："string" @tmomail.netに送られ、対応する、この場合、"string"として電話番号の入ったT-モバイル加入者に送られる。
・XphoneにMMSメッセージとして圧縮したビデオを送るには、携帯電話（携帯送受信機）の電話番号を入力する。
・ユーザは、GPRS接続を確立するように促される。これは、例えばインターネットエクスプローラに到達してどこかの既知のURLに行くことで完了する。
・一旦GPRS接続が旨く確立されたら、" OK "をクリックする。
・次のステータス・メッセージが現われるべきところで、新しいウィンドウは開く。
○ FTPホスト: xx.xx.xx.xxxに接続
(これはサーバのIPアドレスとなる)
○ 接続
○ サーバにログイン
○ ログイン完了
○ ディレクトリの:public_htmlへの変更
○ 変更完了
○ ビデオファイル<selected video file name>.dtvのアップロード開始
○ アップロードの完了
○ リンクファイル<selected video file name>. lnkのアップロード開始
○ アップロードの完了
○ ビデオファイルの送信の成功。接続終了。
注：２つの新しいファイル（<selected video file name>.dtvと<selected video file name>. lnk）がftpサーバ上のpublic_htmlディレクトリ中に現われる。
【０１５３】
４．４．２ MMSサーバからSMS通知が送られる。
・サーバ上で走るスクリプトがftpロケーションpublic_htmlを呼び（polls）、新しいファイルの存在を確認する。
・新しいファイルが存在する時、サーバ・スクリプトは<new file>.lnkファイルを解析し、送られるビデオファイルの名前と目的（指示先）携帯電話（携帯送受信機）番号またはメールアドレスを抽出する。
・スクリプトはemailまたはモバイルSMSのいずれかによって目標とされた指示先へSMS通知メッセージを送る。
【０１５４】
４．４．３ 受信携帯電話（携帯送受信機）のビデオメッセージとDTVデコーダのダウンロード
このセクションは、XphoneでSMS通知を受け取り、MMSサーバに接続し、DTVデコーダと一緒にQCIF/15fpsビデオ・ファイルをダウンロードするという能力を実証する。ビデオファイルとデコーダを受け取ってから、Xphone上でファイルはデコードされ実演される。
・XphoneはSMSメッセージを受け取る。
・SMSメッセージを開く。内部はビデオファイルをダウンロードするロケーションとなる。
・DTVビデオ・ファイルをダウンロードする。
○ インターネットエクスプローラを開く。
○ ビデオファイルの存在する位置のURLを打ち込む（タイプイン）。
○ ビデオファイルがXphoneにダウンロードされる。
○ さらに、Xphoneビデオ・デコーダをダウンロードする必要がある(もしそれがまだXphoneの上にない場合)。一度ダウンロードされたら、Xphoneデコーダ・ファイル(DtvXphoneDemo.exe)はXphoneのマイドキュメント・ディレクトリの中に置かれる。
・DtvXphoneDemo.exeを作動させる。
・Ulウィンドウが、ユーザの情報入力を可能にするように現れる(アプリケーションはbitstream.dtv fileの処理を標準設定)。
○ 水平および垂直のフレームサイズ。
○ QCIFビデオをデコードするため、パラメーターはそれぞれ160と144。
○ 圧縮されるフレームの範囲：典型的には"全て"をセットする。(注：もしユーザがこれを変更することを選択しても、DTVが１グループの画像として２つのフレームを処理するので、指定するフレームの総数は偶数となる。)
○ 他の全てのフィールドは無視する。
○ "デコード"を選択する。
○ スタートを選択する。
○ 圧縮されていないAVIファイル(それはモバイル携帯電話（携帯送受信機）上で見つかるほとんどのビデオプレーヤーによって実行することの可能なもの)を形成する。
・Xphoneの上のビデオ・ファイルを実行するには、単に形成されたファイルをクリックすれば、中にあるマイクロソフト・メディア・プレーヤーがビデオを再生するだろう。
【０１５５】
４．４．４ Xphone上での他のFTP接続の使用
本発明にかかるDropletによって可能にされた柔軟性を開示するために、すべてのソフトウェア・ビデオ送信プラットフォームが開示される。QCIF/15fpsビデオ・メッセージをダウンロードする単純なSmartphone FTPアプリケーションの使用、およびXphone携帯電話（携帯送受信機）へDropletデコーダをダウンロードするソフトウェア・ビデオも開示される。
・Xphone上のWindowsズSmartphones装置のためのOrneta FTPアプリケーションが使用される。
・Orneta FTPアプリケーション・インストーラーは次のものからのPCにダウンロードすることができる：
http://www.handango.com/PlatformProductDetail.jsp?productType=2&platformld=11&siteld=1&Sectionld=0&catalog=1&productld=87548
・Xphoneに接続しているPCを使用して、Orneta FTPをインストールする指示に従う。
・次のアドレスから無料で登録コードを獲得する：
http://x.msmobiles.com/free-smartphone-software/default.aspx
・ビデオメッセージをダウンロードし、MMSサーバからのDropletデコーダをダウンロードするXphoneの上のOrneta FTPアプリケーション：
○ GPRS接続の開始
○ スタート・メニューからのOrneta FTPアプリケーションの設定
○ Menu/ Settings/Set Download Folderからchoose Windowsを選択
○ 特定されたMMSサーバ(例えば、セクション4.1のよう)に接続
○ ダウンロード：Dropletビデオ・エンコーダ"DtvXphoneDemo.exe"を選択してダウンロード
○ Menu/Settings/Setの中のダウンロードフォルダから＼Storage＼My Documents＼を選択
○ MMSサーバに再度接続
○ ビデオ・ファイルQCIF/15である"bitstream dtv"をダウンロード
○ Exit
これで、実施例１の詳述を終了する。
【０１５６】
本発明の特徴は構成の一部として、全てがソフトウェアからなるカメラ付きレコーダ（カムコーダ）電話のアプリケーションでは、毎秒30フレーム(fps)のフル（VGA）サイズの画像(640×480)のリアルタイム撮影が可能であり、大多数のマルチメディア携帯電話（携帯送受信機）に使用されている単一基準のRISCプロセッサーが使用されている。対照的に、モバイル携帯電話（携帯送受信機）のバッテリーのパワーは制約があり、現在のMPEGベースのカメラ付きレコーダ（カムコーダ）電話では、4-15 fpsでQCIFあるいはCIFサイズ(1/16thあるいは1/4、VGAのサイズ)にイメージのリアルタイム撮影のサポートは制限されている。しかし、これらの小さく変わりやすいビデオ・クリップさえ複雑で高価な携帯電話（携帯送受信機）のプラットフォームの設計となり、その中でビデオ機能はハードウェアとソフトウェアのコンビネーションとして実装されており、多機能処理装置であるRISCプロセッサー、ASICおよびDSPを共有しなければならない。
【０１５７】
モバイルのオペレーター環境について、本発明の複雑性を回避したビデオ処理および電送技術は、既存のモバイルの携帯電話（携帯送受信機）、およびモバイルマルチメディア通信サービス・コントローラ(MMSC)のインフラストラクチュアを利用しながら、ターンキー配備を可能にする強力な新しい創造性のあるソフトウェア単体実行ビデオ通信プラットフォームへと統合される。上記のモバイル・カムコーダ（ビデオカメラ）・アプリケーションを補充した本発明の実施例の管理プラットフォームでは、圧縮したイメージとビデオを統合するためのモジュールを、テキストや音を一体とした完全なモバイルマルチメディア・メッセージやオン・ザ・フライ・エディティング、サムネイルプレビュウ・マルチメディアメールボックス、オン・ライン・リポジトリ・サービスおよびサブスクリプション管理と伴に提供する。
【０１５８】
＜作動(効率)の比較（PERFORMANCE COMPARISON）＞
最適化したMPEG-2/MPEG-4 コーデックと本発明にかかるビデオコーデックを対比した場合、利用者は消費電力でソフトウェアおよびハードウェアの両方の実装により、後述の表１参照)の通り、30-40Xの減少が提供できた。ハードウェア製品の実装コストは、著しく減少し、必要となるCMOSゲート数も10倍縮小し、約 1,000,000から100,000となり、対応するsilicon real estate需要も同様である。
フルサイズ(VGA)でフルフレームレート(30 fps)のビデオ処理にあって、本発明の改良ビデオコーデックのデザインでは、内部で必要となるメモリの容量を数メガバイトから128キロバイトに減少し、モバイル携帯送受信機（携帯電話）に搭載されているメモリ資源を他に収入を発生する要素やアプリケーション用に解放した。本発明にかかるコーデックは静止画像もビデオも両方を効率的に処理することができるので、MPEGとJPEGの別々に分かれていたコーデックを１つの廉価で低出力のソルーションに取り替えることができる。
【０１５９】
VGAの展開やサポートにおいて、30fpsのカムコーダ（ビデオカメラ）電話において、また関連サービスにおいて十分利用可能であるが、本発明にかかるユニークなモバイルのビデオプラットフォーム技術はさらに次のもののコンビネーションによって、広範囲の他のモバイルのビデオサービスを通じて十分な利点が示されている：計測可能な画像のサイズ：QCIF(176×144)−D1(720×480)、単純化されたビデオ編集(カット、挿入する、テキスト・オーバーレイなど)、音声コーデック備えた単純化された同期、および、低い潜在率の増強されたビデオストリーミングの効率。
【表１】
表１、コーデック実行効率比較：モバイル送受信機（携帯電話）アプリケーション
【０１６０】
本発明はまた、モバイル送受信機（携帯電話）用の特許性のあるソフトウェア・ビデオコーデック／カムコーダ（ビデオカメラ）（codec/camcorder）アプリケーションに関連したプレミアム・ビデオ配信サービスの配備を可能にするMMSインフラストラクチュア製品とからなる。本発明の更なる特徴は、進歩したトランスコーディングアプリケーションが、他の一般に展開する標準ベースまたは所有しているビデオフォーマットとの完全な相互利用可能性をサポートすることからなる。さらに含まれているものは、本発明の圧縮したイメージおよびビデオと音とテキストと一緒にした完全なモバイルのマルチメディア・メッセージと"着信音"（"ring-tone"）ならびに対応するMMSメッセージ管理能力一式とを共に統合するためのモジュールを提供するコンテント管理プラットフォームである。
このコンテント管理プラットフォームは、無線通信者とMMSサービス・プロバイダーの両者によって、ソフトウェアモジュールのセットとして、既存のMMSインフラストラクチュアへの迅速でコスト効率の良いアップグレードとして、または、新しいMMSコントローラ装置用のスタンド・アロンのサーバとして使用することができる。特許性のあるMMSインフラストラクチュア製品は次のものを含むであろう：
製品と記述
＞DTV-VGTビデオ・ゲートウエイTranscoder：
DropletDTVフォーマットと他のMPEG-2やMPEG-4、Motion-JPEG、マイクロソフト・メディアおよびRealVideoのようなビデオフォーマットとの間のビデオのコンテンツの変換をサポートするために既存のMMSビデオ・ゲートウエイをアップグレードするためのソフトウェア・トランスコーダ（Transcoder）アプリケーション。
＞DTV-CMP ソフトウェアコンテンツ管理プラットフォーム：
既存のMMSメッセージ・アプリケーション・サーバをアップグレードするための一式のコンテンツ管理ソフトウェアモジュール:、音およびテキスト、オン・ザ・フライ・エディティング、サムネイルプレビュウ、マルチメディアメールボックス、オン・ライン・レポジトリ・サービスおよびサブスクリプション管理と一緒に本発明の圧縮したイメージおよびビデオを統合するMMSメッセージと"着信音（ring-tone）"の生成。
＞DTV-CMSコンテンツ管理サーバ：
新しいMMSC配備用のサーバベースの統合ソフトウェアコンテンツ管理プラットフォーム。
【０１６１】
本発明は、さらにコンテンツ管理サービスプラットフォームのソフトウェアのモジュールあるいはスタンド・アロン・サーバであって次のものを含むであるものを含む：
＞モバイル・マルチメディアコンポーザ： 本発明の改良されたウェーブレットで圧縮したイメージおよびビデオを音およびテキストとともに１つのメッセージに統合する。
＞プレビュープレーヤ： 本発明のウェーブレットで圧縮したイメージとビデオと統合したMMSメッセージで“サムネイル”プレビューとを提供する。
＞モバイル・マルチメディア・エディタ: 本発明のウェーブレットで圧縮したイメージとビデオと、ツールとフィルタで統合したMMSメッセージでオン・ザ・フライ・エディティングを可能にした。
＞マルチメディア着信音（ring-tone）クリエーター： ウェーブレットで圧縮したイメージおよびビデオと多音の着信音（ring-tone）と他の音を組み合わせることによってユーザが個人のマルチメディア"着信音（ring-tone）"を作成することを可能にする。
＞モバイル・マルチメディア・アルバムまたは"Mblog"： 本発明のウェーブレットで圧縮したイメージ、ビデオおよび統合されたMMSメッセージのためのリポジトリ（情報データベース）。
＞モバイル・マルチメディア・サブスクリプション管理： 本発明のウェーブレットを圧縮したイメージとビデオと統合したMMSメッセージをコピーして/転送する。：追加の記憶装置の購入：DVDハード・コピーの購入。
＞モバイル・マルチメディア・メールボックス： 本発明で統合されたMMSのためのSMSで管理されたインの箱とアウトの箱。
＞モバイル・マルチメディア・アドレス帳： モバイル・マルチメディアの接触の管理。
【０１６２】
本発明の実施例を提供することに注目すべきである:
＞柔軟で迅速で、コスト効率の良いOTA（無線）/OTN（ネットを介する）は、インストールされたMMSインフラストラクチュアからの増加ROIをアップグレードする。
＞進化したトランスコーディングは他の一般に展開した標準ベースものと所有しているビデオフォーマットとの完全な相互操作をサポートする。
＞既存のMMSインフラストラクチュアをアップグレードするためのソフトウェアのモジュールの一式として、あるいは新しいMMS装置用のスタンドアローン（独立型）のサーバとして利用可能なコンテンツ管理プラットフォーム
【０１６３】
＜JSR-135：モバイル・メディアAPIスペシフィケーション(MOBILE MEDIA API SPECIFICATION) ＞
本発明のDTV-JVC Javaビデオ・コーデックは、下記を含むJavaコミュニティー・プロセスJSR-135に定義されたプレーヤー機能性をすべてサポートする、復元されたビデオイメージを生成する：
Int getDisplayHeight( )の取得
ビデオに流れる電流の実際の高さを返す。
Int getDisplayWidth( )の取得
ビデオに流れる電流の実際の幅を返す。
Int getDisplayX( )の取得
ビデオが放映された時のGUIオブジェクトに関するビデオのXコーディネートを返す。
Int getDisplayY( )
ビデオが放映された時は、GUIオブジェクトに関するビデオのYコーディネートを返す。
byte〔〕 getSnapshot(java.lang.String imageType)
表示されたコンテンツのスナップ写真を得る。
Int getSourceHeigh( )
ソースビデオの高さを返す。
Int getSourceWidth( )
ソースビデオの幅を返す。
java.lang.Object initDisplayMode(int mode, java.lang.Object arg)
ビデオの放映状態によりモードを初期化する。
Void setDisplayFullScreen(ブールのfullScreenMode)
ビデオ・クリップがfullscreenになるように関連領域のサイズをセットする。
Void setDisplayLocation(int x，int y)
ビデオが放映される場合、キャンバスの位置をビデオのロケーションとしてセットする。
Void setDisplaySize(int幅，int高さ)
ビデオイメージのサイズを変更する。
Void setVisible(ブール、可視)
ビデオを放映するか、切断するか。
【０１６４】
＜JSR-234: 進化したマルチメディア補充(ADVANCED MULTIMEDIA SUPPLEMENTS) ＞
本発明のDTV-JVC Javaビデオコーデックは、下記を含むJavaコミュニティー・プロセスJSR-234に定義されたプレーヤーイフェクトコントロールのすべてをサポートする復元されたビデオイメージを生成する、:
ImageFilterControl
ImageFilterControlはモノクロ（単彩色）とそうでないものの様々なイメージ・フィルタをセットするために使用することができるイメージ効果である。
IimageTonalityControl
ImageTonalityControlは明るさ、コントラストおよびガンマ(明度)のような様々なイメージ・セッティングをセットするために使用することができる効果である。
ImageTransforrnControl
ImageTransformControlはイメージをトリミング、ズーム、鏡映し、反転、引伸し、回転させるために使用される。
OverlayControl
OverlayControlは、ビデオの先頭画面や静止画像のオーバーレイ・イメージのセッティングをコントロールする、
WhiteBalanceControl
WhiteBalanceControlは、白のバランスの変更によるイメージ/ビデオの影響。
【０１６５】
本発明は、さらにモバイルのビデオのブログサービスを確立し、提供し、操作するための製品と方法およびプロセスとからなる。このサービスは、全てのユーザに、撮影（shoot）、編集、保存、シェア、および、個人ビデオの"公表"、更にオンライン映画の可能なビデオ電話を提供する。
【０１６６】
ユーザに関しては、" Mobedia "とコード名の付けられたモバイルビデオのブログ（blog）サービスを、本発明にかかる製品として提供する:
１． モバイル携帯電話（携帯送受信機）にプリインストールすることができるMobediaソフトウェアのカムコーダー・アプリケーションで、どのビデオ電話でもJavaが使えるものならユーザはダウンロードしてインストールすることができる。
２． Mobedia ソフトウェアのカムコーダー・アプリケーションを使用すると、 ユーザは、彼らのモバイル携帯電話（携帯送受信機）を使用して、フルVGA/30 fps(あるいはさらに高品質の)ビデオを撮影することができる。
３． Mobedia ソフトウェアの映画アプリケーションを使用すると、ユーザはブラウズ/編集の取得やタイトル追加等ができ、" splice(接続) "をマルチで（重複して）取ると、本発明にかかるソフトウェアのカムコーダー・アプリケーションを使用して個人の映画が制作できる。
４． Mobediaソフトウェアの映画アプリケーションの単純なバージョンは、ユーザに無料で配布されるであろう、一方、より充実した " Chinema-Pro " バージョンはユーザによって購入される。
Mobediaサーバと名付けられたサーバに本発明の特徴は提供され：
５． Mobedia携帯電話（携帯送受信機）のクライアントのソフトウェアを使用すると、ユーザは撮影したビデオを、モバイル、固定、無線、有線接続を介して、撮影したビデオをMobediaサーバに伝送することができる。
６． Mobediaサブスクリプションサービスは、ユーザが撮ったビデオや映画をサーバ(有料ストレージ)にアーカイブ保管することを可能にする、また、外部に更なるエディションをオンラインで持ち出したりダウンロードしたり、さらに様々なポピュラーなフォーマットでビデオ保存したり、DVD(有料)にコピーを請求することもできる。
７． Mobediaサブスクリプションサービスは、ユーザがMobediaサイト上で映画アルバムを作成することを可能とし、友達、家族、同僚などを招待してそれらの映画の鑑賞をするかあるいは贈り物としてDVD(有料)にコピーを注文することができる。
友達・家族やその他に対して、本発明にかかるMobediaタイプは提供され:
８． 友達、家族、同僚などは、ユーザの映画、ダウンロードおよび保存コピー(有料)を見ることについてemailによる招待を受け、また、自身のためのDVD(有料)のコピーを注文することができる。
一般の視聴者(映画モデル)に対して、本発明にかかるMobediaは提供する:
９． Droplet のMobediaサブスクリプションサービスは、彼等の映画を一般大衆に"公表する"のを許可しており、Mobedia映画サイト上で見ることができる。
１０． 一般の視聴者は、公表された映画のアーカイブをMobedia映画サイト上のランキング、主題、カテゴリー等や無料で見られるプリビュウで検索することができる。
１１． 一般の視聴者は、お金を払えば見ることもダウンロードすることも、DVDにコピーすることもできる。
【０１６７】
下記の方法およびプロセスは、本発明の特徴を含むもので、現在の技術によって排他的に実施可能である。
収入源/ビジネスモデル:
・映画メーカー: サーバ・スペース、ファイルのダウンロード、DVDの注文について対価を支払う。増強されたバージョンの編集用のソフトウェアに対価を支払う。
・ 友達、家族、その他: ファイルのダウンロードとDVDを注文について対科価を払う。
・一般的の視聴者： 映画全体を観る(試写だけは無料)場合、DVDを注文する場合またはダウンロードする場合は対価を支払う。
−映画メーカーは、一般的な視聴者から支払われた料金についてシェア（取り分）を獲得する。
・モバイル・オペレーター：増加したデータ交通量に応じて歳入シェアリングモデルから対価を支払う。
本発明の特徴のサービス・コンポーネントは次のものからなる:
・本発明にかかる個人のビデオコンテンツの撮影、伝送と管理のためのモバイル・ビデオ・メッセージ・プラットフォーム(サーバと携帯電話（携帯送受信機）ソフトウェア・アプリケーション)
・本発明のMobediaのソフトウェアのビデオ・カムコーダー・アプリケーションは、どのjava/ビデオ電話でのビデオ撮影をも可能にする。
・本発明のMobediaのソフトウェアのビデオ映画のクライアント・アプリケーションは、基礎的なビデオプロダクションと編集および観察に関する技術(単純なものとプロバージョン)を含んでいる。
・本発明のMobediaのソフトウェアのビデオ映画のウェーブベースのコンテンツ管理アプリケーションは、Mobedia映画の映画アルバム、パーソナル・ムービング・シェアリング（personal moving sharing）およびMobedia映画の"出版"をサポートする。 .
【０１６８】
ここに示されるのは、改善されたモバイル画像アプリケーションと、携帯送受信機（携帯電話）アーキテクチャーおよびサービス・プラットフォーム・アーキテクチャーであり、本質的にモバイルの加入者に高品質の静止画像とビデオ画像を提供することに関する技術的な複雑性とコストの削減のための結合である。改善された適応性のあるジョイント−ソース・チャネル・コーディング技術は、無線キャリアとMMSサービス・プロバイダーが、大きな範囲のサービスの質(QoS)の効率と、消費者と企業の顧客への価格レベルの提示に対応する能力であり、それにより、この無線ネットワーク・インフラストラクチュアを使用することによって生じる収入を最大化する。改善された適応性のあるジョイント−ソースチャネル・コーディング技術は、より高い計算上の効率を備えたアルゴリズムに基づいており、チャネルタイプ(無線か有線か)、チャネル帯域幅、チャネル雑音/エラー特性、ユーザ装置およびユーザ・サービスの点から、より高いレベルのネットワーク均質性（homogeneity）をサポートすることを可能にしている。さらに提供されたのは、モバイル電話における静止画像と動画ビデオの分野に、増強された革新的なサービスを提供する方法、装置、プロセスおよびビジネス方法である。
【０１６９】
さらに、本発明の特徴として追加的に提供するのは、以下の要約の通りである。
【０１７０】
改善されたウェーブレットを基礎とするコーデックを利用するモバイル画像アプリケーション。このアプリケーションはソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７１】
また、微粒子（fine grain）伸縮性を使った上述の改善されたウェーブレットベースのコーデックによる改善されたジョイント−ソース・チャネル・コーディングからなるシステムと方法を提供するもので、復元されるビデオ信号の瞬間と平均の質(ビデオ・レート対ひずみ)の両方を最大にコントロールするために、情報源コーダー、チャネル・コーダーおよび適応性のあるレート・コントローラーのすべての３つのチャネル帯域幅およびエラー条件の瞬間値と予定値の両方の情報を利用している。さらに提供されたシステムと方法は、消費者と企業のMMS顧客のためにサービスの質の(QoS)効率と価格レベルをより大きな範囲な適用することができ、チャネル・タイプ(固定無線通信、モバイルの無線通信および有線通信)、チャネル帯域幅、チャネル雑音/エラー特性、ユーザ装置、および改善されたマルチキャスティングを含むユーザ・サービスでのネットワーク異成分のはるかに高いレベルのサポートをすることができる。
【０１７２】
モバイルカムコーダー（ビデオカメラ）・アプリケーションもまた提供される。このアプリケーションは、モバイル機器におけるフル・カムコーダー能力のため、前述の２節の特徴と関連する画像の前処理と後処理に関する機能および音声録音とを組み合わせたものであり、ソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７３】
モバイル画像アプリケーションもまた提供される。このアプリケーションは、改良されたウェーブレットに基づくコーデックを使用し、Javaアプリケーションとして実装される。この実装はソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７４】
さらに提供されるのは、モバイル・カムコーダ・アプリケーションで、モバイル機器におけるフル・カムコーダ能力のため、前節で述べたアプリケーションと画像の前処理と後処理に関する機能および音声録音とを組み合わせたものである。このアプリケーションはソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７５】
さらに提供されたのは、画像の出来るモバイル送受信機（携帯電話）のアーキテクチャであってpects として利用されものであり、この要約の前節の特徴であるモバイル画像アプリケーションが、携帯送受信機（携帯電話）の送受話器basebandのマルチメディア処理セクション、画像モジュール、または着脱可能なストレージメディアに組み入れられている。
【０１７６】
さらに提供されたのは、上述の画像が使用可能な携帯送受信機（携帯電話）における上記要約の上記の特徴がある無線デリバリまたはアップグレードである。
【０１７７】
さらに提供されたのは、システムで、画像が使用可能な携帯送受信機（携帯電話）へ上記の特徴およびシステムのPOSインストールあるいはアップグレードを可能にする。
【０１７８】
さらに提供されたのは、モバイル画像トランスコーダで、他が所有する標準ベースの画像フォーマットとこの要約の上記の特徴を普遍的に互換可能にする全てがソフトウェアのアプリケーションで、自動のネットワークを介したアップグレードまたはマニュアル操作でMMSCビデオ・ゲートウェイの中へ配信またはインストールされる。
【０１７９】
さらに提供されたのは、モバイル画像サービス・プラットフォーム・アーキテクチャと、方法およびシステムで、この要約の特徴をすべて組み合わせている。
【０１８０】
上記がこの発明の実施例の特徴であり、各種の代案、修正および等価物が使用されるであろう。したがって、上記の記述は、添付の請求項で定義される発明の範囲の制限となるものではない。
【図面の簡単な説明】
【０１８１】
【図１】モバイル画像通信のビデオ画像サイズの制限を示す。
【図２】情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【図３】モバイル画像携帯機器の構成を示す。
【図４】モバイル画像サービス・プラットフォームの構成を示す。
【図５】従来のビデオコーデックの技術の比較図を示す。
【図６】改良された情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【図７】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【図８】ビデオコーデックの効果の比較図を示す。
【図９】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【図１０】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【０１８２】
【図１１】改良されたモバイル画像サービスのプラットフォームの構成を示す。
【図１２】展開したMMSCビデオ・ゲートウェイのネットワークを通じた（OTN）アップグレードを示す。
【図１３】ビデオMMSがトランスコーディングを必要としない自立再生を示す。
【図１４】メディア・プロデュース・サービスの展開に必要なビデオ編集サーバの複雑性、コストおよび数の縮小を示す。
【図１５】モバイル・ビデオ・サービスのプラットフォームを示す。
【図１６】より高品質のマルチメディア携帯送受信機（携帯電話）・サービスのより速くより低いコストの開発と展開を示す。
【図１７】は本発明のモバイル・ビデオ・サービスを示す。
【図１８】は本発明のブロードバンドのマルチメディア装置およびサービスへのアプリケーションを示す。
【図１９】本発明のソフトウェア画像アプリケーションに対する実装オプションを示す。
【図２０】本発明のハードウェアでアクセラレートされた画像アプリケーションの実装オプションを示す。
【０１８３】
【図２１】本発明のハイブリッド・ハードウェアでアクセラレートされたソフトウェア画像アプリケーションの実装オプションを示す。
【図２２】単純化されたマルチメディア携帯送受信機（携帯電話）プラットフォームのアーキテクチャのアプリケーションを示す。
【図２３】GSM/GPRSネットワーク上でのモバイルビデオ通信デモの要素を示す。
【図２４】本発明にかかる特定のMMS機能を示す。
【技術分野】
【０００１】
＜関連発明＞
本件出願は出願番号60/654,058で2005年2月16日に出願されたアメリカ合衆国の仮出願の優先権主張を伴うものである。
本出願が全面的に参照して関連するのは、さらに、2005年9月20日に申請された米国の出願11/232,165番; 2005年9月21日に申請された米国の出願11/232,726番; 2005年9月21日に申請された米国の出願11/232,725番; 2005年10月12日に申請された米国の出願11/249,561番；および2005年10月13日に申請された米国の出願11/250,797番である。
この出願は、下記のものすべてを全目的に組み入れている：
Sweldens、WimのThe Lifting Scheme：双直交ウェーブレットのカスタム・デザインの構築。Appl. Comput. Harmon. Anal. 3(2):186-200, 1996 ；
米国特許出願10/418,363、2003年4月17日出願、発明の名称WAVELET TRANSFORM SYSTEM、METHOD AND COMPUTER PROGRAM PRODUCTで、発明者は、William C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders ；
米国特許出願10/447,514、2003年5月28日出願、CHROMA TEMPORAL RATE REDUCTION AND HIGH-QUALITY PAUSE SYSTEM, AND METHODで、発明者はSteven E.Saunders、Krasimir D.KolarovおよびWilliam C.Lynch ；
米国特許出願10/447,455、2003年5月28日出願、PILE PROCESSING SYSTEM AND METHOD FOR PARALLEL PROCESSORで、発明者はWilliam C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders ；
Golomb, S.W.(1966). "Run-length encoding" IEEEトランズアクション情報理論、IT-12(3):399−401 ；
R. F. Riceの " いくつかの実際的なユニバーサルノイズレコード化技術 " ジェット推進研究所、パサデナ、カリフォルニア、JPL出版、79-22 1979年3月 ；
J.Teuholaの "クラスタード・ビット-ベクトル用圧縮方法 " 情報処理レター、1978年10月の7 vol. pp. 308 ? 311 ；
米国特許出願10/447,455、2003年5月28日出願の PILE PROCESSING SYSTEM AND METHOD FOR PARALLEL PROCESSORS、発明者はWilliam C.Lynch、Krasimir D.KolarovおよびSteven E.Saunders。
本発明は、
出願番号11/232,726で2005年9月21日にアメリカ合衆国に出願された"Multiple Technique Entropy Coding System and Method" であって、出願番号60/612,652で2004年9月22日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号11/232,725で2005年9月21日にアメリカ合衆国に出願された"Permutation Procrastination" であって、出願番号60/612,651で2004年9月22日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号11/232,165で2005年9月20日にアメリカ合衆国に出願された"Compression Rate Control System and Method with Variable Subband Processing" であって、出願番号60/612,311で2004年9月21日に出願されたアメリカ特許仮出願の優先権主張を伴う出願の一部継続出願であり、；
出願番号10/955,240で2004年9月29日にアメリカ合衆国に出願された"System and Method for Temporal Out-of-Order Compression and Multi-Source Compression Rate Control" で、現在、アメリカ特許公告No. US 2005/0105609で2005年5月19日に公告されたものであって、出願番号60/612,311で2004年9月22日のアメリカ特許仮出願と、共に2003年9月30日出願の出願番号60/507,148と出願番号60/507,147のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/944,437で2004年9月16日にアメリカ合衆国に出願された"Multiple Codec-Imager System and Method" で、現在、アメリカ特許公告No. US 2005/0104752で2005年5月19日に公告された出願であって、出願番号60/390,380で2002年6月21日のアメリカ特許仮出願と、出願番号60/374,061で2002年4月19日出願のアメリカ特許仮出願からの優先権主張を伴う2004年11月30日に発行されたアメリカ特許第6,825,780号の継続である出願の一部継続出願であり、；
出願番号10/477,455で2003年5月28日にアメリカ合衆国に出願された"Pile-Processing System and Method for Parallel Processors" で、現在、アメリカ特許公告No. US 2003/0229733で2003年12月11日公告された出願であって共に2002年5月28日出願の出願番号60/385,253と出願番号60/385,250のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/447,514で2003年5月28日にアメリカ合衆国に出願された"Chroma Temporal Rate Reduction and High-Quality Pause System and Method" で、現在、アメリカ特許公告No. US 2003/02355340で2003年12月25日に公告された出願であって共に2002年6月21日出願の出願番号60/390,345と出願番号60/390,492のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/418,649で2003年4月17日にアメリカ合衆国に出願された"System, Method and Computer Program Product for Image and Video Transcoding" で、現在、アメリカ特許公告No. US 2003/0206597で2003年11月6日に公告された出願であって2002年4月19日出願の出願番号60/374,069のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願であり、；
出願番号10/418,363で2003年4月17日にアメリカ合衆国に出願された"Wavelet Transform System, Method and Computer Program Product" で、現在、アメリカ特許公告No. US 2003/0198395で2003年10月23日に公告された出願であって2002年6月21日出願の出願番号60/385,254のアメリカ特許出願と共に2002年4月19日出願の出願番号60/373,974と出願番号60/373,966のアメリカ特許仮出願からの優先権主張を伴う出願の一部継続出願である。
本出願が全面的に参照して関連するのは、2005年1月25日に発行されたアメリカ特許第6,847,317号の"System and Method for a Dyadic-Monotonic (DM) Codec"と、2004年11月30日に発行されたアメリカ特許第6,825,780号の"Multiple Codec-Imager System and Method"である。
直接デジタル化されたイメージやビデオには多くのビットが必要となる。そこでイメージやビデオは記憶・伝送・その他の使用のために圧縮するのが一般的である。いくつかの基本的な圧縮方法が知られており、数多くのそれらの異型が存在している。一般的な方法は変換・量子化・エントロピー符号以下の３段階の工程からなる。多くのイメージ・ビデオコンプレッサはこれらの基本構成とその変形を保有しているものである。
ビデオコンプレッサにおける変換ステージの目的は、ソース画像のエネルギーと情報を、画像若しくはシーケンスの固有の類似点やパターンを利用して、できる限りコンパクトな型にまとめることである。全ての可能性あるインプットを圧縮できるコンプレッサは存在しない。そこで、我々は代表的なインプットにうまく働き、ランダムインプットや病的なインプットに反応しないコンプレッサを開発した。MPEG-2、MPEG-4のような多くの画像圧縮方法やビデオ圧縮方法において離散コサイン変換（DCT）が変換処理として使用されている。MPEG-4スタティックテクスチャ（static texture）圧縮処理では変換処理（段階）としてウェーブレット変換が使用されている。
変換処理（段階）後の非量子化情報において、再構築された復元情報は正確なオリジナルの再現とはならない。エントロピー符号化は一般的にはロスのない工程であり、この工程では、量子化および符号化の後に情報が保存されるので、デコーダの中で正確に再生産できる。従って、どの情報を無視するかの決定は後述するエントロピー符号化の段階に影響を及ぼさない。
ワークステーションコンピュータ上で高度に複雑なエンコーダを実行できるようなスタジオの現場で、ビデオコンテンツのエンコーディングに利用されているのは、本来、ビデオ放送・ストリーミングアプリケーション用に開発された、限定されたDCT（離散コサイン変換）によるビデオコーデック（圧縮復元）技術である。このようなコンピュータ的に複雑なエンコーダ（符号装置）が、コンピュータ的に簡素で比較的高価ではないデコーダ（プレーヤ）である需要者の再生装置にインストールされる。しかしながら、非対称なエンコーダとデコーダ技術はモバイルメディア機器ではうまくマッチせず、ビデオメッセージはリアルタイムで携帯電話（携帯送受信機）に捕えられ、また、再生される。その結果、モバイル機器のビデオ画像は、他の消費者向け製品より、より小さいサイズとなり、さらに低いフレーム率に限定される。
【０００２】
＜発明の背景と、発明の要約＞
本発明は、機器により記録される静止画像とビデオ画像に関する方法、装置、システムおよびアーキテクチャに関連するものである。本発明は以下のものを包含する。すなわち、モバイル機器、関連するモバイル機器アーキテクチャ、サービス・プラットホームアーキテクチャ、および送信・記憶・編集・共有・マーケッティング、無線および有線のネットワーク・システムを通じた静止画像・ビデオ画像の変換、ディスプレイ装置による閲覧のための方法とサービスを包含し、これはネットワークや前述のものに関連するその他のシステムサービスに限られない。また、本発明は、イメージの録画技術の改良および関連するモバイル機器とサービスプラットホームのアーキテクチャの改良にもまた関連している。
【０００３】
本発明は、動画または静止画像の圧縮および／または復元のためのソフトウェア単体実行によるビデオコーデック（圧縮復元）およびカムコーダ（ビデオカメラ）アプリケーションから構成される。また、本発明の関与する範囲は、インフラストラクチャ（基盤）関連の製品および方法と工程、さらに、携帯送受信機用ビデオコーデック（圧縮復元）およびカムコーダ（ビデオカメラ）技術のソフトウェアに関するビデオメッセージの配備と共有サービスならびに、一般に配備される汎用および専用のビデオフォーマットとの完全な相互利用性を支援するための編集技術と交換技術を配備するための多機能モバイルサービス（MMS）のインフラストラクチャ技術を含む。さらに、本発明は、モバイル機器のモバイル利用者が創作したビデオコンテンツのための革新的モバイルビデオブログとマーケッティングを確立し、これを可能にし、更に配信する、革新的MMS（多機能モバイルサービス）を実施する方法、工程ならびにビジネス工程からなる。
【０００４】
＜図面の簡単な説明＞
図１はモバイル画像通信のビデオ画像サイズの制限を示す。
【０００５】
図２は情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【０００６】
図３はモバイル画像送受信機の構成を示す。
【０００７】
図４はモバイル画像サービス・プラットフォームの構成を示す。
【０００８】
図５は従来のビデオコーデックの技術の比較図を示す。
【０００９】
図６は改良された情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【００１０】
図７は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１１】
図８はビデオコーデックの効果の比較図を示す。
【００１２】
図９は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１３】
図１０は改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【００１４】
図１１は改良されたモバイル画像サービスのプラットフォームの構成を示す。
【００１５】
図１２は展開したMMSCビデオ・ゲートウェイのネットワークを通じた（OTN）アップグレードを示す。
【００１６】
図１３はビデオMMSがトランスコーディングを必要としない自立再生を示す。
【００１７】
図１４はメディア・プロデュース・サービスの展開に必要なビデオ編集サーバの複雑性、コストおよび数の縮小を示す。
【００１８】
図１５はモバイル・ビデオ・サービスのプラットフォームを示す。
【００１９】
図１６は、より高品質のマルチメディア携帯送受信機（携帯電話）・サービスのより速くより低いコストの開発と展開を示す。
【００２０】
図１７は本発明のモバイル・ビデオ・サービスを示す。
【００２１】
図１８は本発明のブロードバンドのマルチメディア装置およびサービスへのアプリケーションを示す。
【００２２】
図１９は本発明のソフトウェア画像アプリケーションに対する実装オプションを示す。
【００２３】
図２０は本発明のハードウェアでアクセラレートされた画像アプリケーションの実装オプションを示す。
【００２４】
図２１は本発明のハイブリッド・ハードウェアでアクセラレートされたソフトウェア画像アプリケーションの実装オプションを示す。
【００２５】
図２２は単純化されたマルチメディア携帯送受信機（携帯電話）プラットフォームのアーキテクチャのアプリケーションを示す。
【００２６】
図２３はGSM/GPRSネットワーク上でのモバイルビデオ通信デモの要素を示す。
【００２７】
図２４は本発明にかかる特定のMMS機能を示す。
【００２８】
＜ 発明の詳細な説明 ＞
＜ウェーブレット画像処理＞
ウェーブレット変換は、１次元または１次元より上の次元における一つのデータセットの一対のウェーブレットフィルタの連続仕様からなる。静止画像の圧縮では、２次元（水平と垂直）のウェーブレット変換が使用される。本発明にかかるビデオコーデックでは３次元（水平と垂直と時間）のウェーブレット変換が使用される。改良された対称な３次元ウェーブレット変換によるビデオコーデック（codec＝圧縮還元）装置によれば、モバイル装置のコンピュータ上の複雑性と電力の消費量の削減改善についてDCTによるコーデックを用いた装置より望ましく、また、静止画像の処理においてもシングルコーデックによるビデオイメージの処理にも同時サポートが可能である。この静止画像とシングルコーデックによるビデオイメージの同時サポートは、それぞれに必要とされていた（ビデオ用の）MPEG又は静止画像用のJPEGコーデックを削減または不要にするか若しくは圧縮効果とその結果としてのモーションJPEGの記憶特性を大幅に改善させた。改良された対称な３次元ウェーブレット変換によるビデオ処理装置は、利用者の作成したビデオの自動またはマニュアルの編集や、利用者の作成したビデオのデータベースの記憶、検索ならびに復元をサポートするMMS基盤となる装置のコンピュータ上の複雑性と電力の消費量の削減を可能にする。
【００２９】
＜モバイルビデオ通信とサービス＞
本発明は、モバイル機器にインストールされる改良されたビデオコンテンツの獲得、圧縮、送信、編集、記憶、共有、に関連した新たな方法、サービス、方式に関するものである。本発明は、遠隔通信（無線と有線のどちらのプロバイダによるものも含む）、インターネット、ケーブル（電信）その他の定置またはモバイルの無線サービスプロバイダを含むデータおよび多機能操作機に応用されるものである。本発明は、豊かなコンテンツ、高度な利用領域、利用者毎の平均収益（ARPU）を提供するものである。モバイルマルチメディアサービス（MMS）は、テキストを基礎とするショート通信サービス（SMS）の進化である。本発明によれば、提示される有望な新たなモバイルメディアサービス（MMS）仕様は、ビデオ通信と共有とターゲットとされた視聴者の個人的情報と交信するというニーズを可能にする改革である。モバイル画像通信と共有は更に、モバイル携帯機器に（静止画像用）デジタルカメラ機能および／またはカムコーダ（ビデオカメラ）機能を必要とし、これにより、加入者が送ろうとするビデオ情報を撮影（encord＝記号化）し、受信したビデオ情報を再生（decord＝復元）することが出来る。本発明の特徴であるこれらの機能は従来技術からも可能であったとしても実現できなかった。
【００３０】
本発明によれば、モバイル機器は、統合された利用者の多機能娯楽プラットフォームに発展していくことができる。産業界の投資は実施的に技術とプラットフォームに向けられてきた。その技術やプラットホームとは、テレビ放送番組（ニュースクリップ、スポーツハイライトや特別な"mobisodes"といったポピュラー番組のような）のリパッケージ、その他のスタジオ発のビデオコンテンツ（映画予告や音楽ビデオのような）をモバイル機器に送信して閲覧することを可能とするようなものである。後者のケースでは、モバイル機器利用者はビデオ消費者の新分野として開拓されている。しかしながら、この後者のケースではほとんど、大規模な放送会社の圧縮したビデオコンテンツを利用している。しかしながら、本発明により、世界のモバイル操作者は、単なるメディアの受信者というより加入者を（この発明により可能となる）メディア創作者としてサポートする重要な新しい機会が獲得できる。本発明で可能となるモバイル機器のスタンドアローンのデジタルカメラやカメラ付きレコーダと同様の写真やビデオの獲得と共有機能は、高速セル方式や固定無線データネットワークの進歩および集合とともに新たなサービスのための基礎技術である。本発明では更に、開発コストの削減とカメラ付きレコーダ電話やビデオ送信共有の基盤装置の両方の小売価格の削減が可能となり、これは、この装置や関連するモバイルメディア／データサービスを既存の市場やこれからの市場で大規模に商業的に採用することの鍵となる。
【００３１】
従来のモバイル画像通信／共有サービスとアプリケーションは、典型的な受信して他の多機能機器で再生するテレビ、パーソナルコンピュータ、デジタルビデオカメラ付きレコーダ、パーソナルメディア再生機より小さいサイズと低いフレーム率のビデオ画像に厳しく制限されていた（図１参照）。モバイル画像送信サービスとアプリケーションは、VGA（またはこれより大きな）ビデオのフレーム率が30fpsまたは本発明で提供されるそれ以上の高速を望まれるものをサポートすることが出来る。
【００３２】
＜適応情報源・通信路符号化結合(ADAPTIVE JOINT SOURCE-CHANNEL CODING)＞
モバイルネットワークのビデオ送信は、テキスト、オーディオ、静止画像のような他のデータ／メディア型の送信に比べて高度なデータ率が必要であるのでとても興味深い。さらに、モバイルネットワークのノイズとエラー特性の変動に伴うチャネルの帯域幅の変化と制限は、ビデオ移送に拘束と困難性を負わせる。本発明では、様々な情報源符号化の技術がビデオのビットストリームを異なるチャネル状態に適用するために用いられる（図２参照）。本発明にかかるこの情報源・通信路符号化結合（joint source-channel cording）はチャネルの帯域幅の変化とエラー特性に適応させるためにスケーラブル（拡大縮小可能）である。また、本発明はスケーラビリティ（拡縮可能性）をマルチキャストのシナリオのために支援し、異なる機器のビデオストリームの受信端では復号するコンピュータ出力と表示能力は異なる制限範囲となる。
【００３３】
図２で示すように、本発明によればビデオ情報源の列３０はまず情報源符号化３２（圧縮）され、エラー訂正コード（ECC）で通信路符号化３４される。モバイルネットワークでは、情報源の符号化の典型としてH.263、MPEG-4やモーションJPEGのようなDCTを基礎とする圧縮技術が使用される。通信路符号化の方法としては、Reed-Solomonコード、BCHコード、FECコードやターボコードがある。情報源とチャネルが共にコード化されたビデオのビットストリームはレート制御３６を通過してベストに再構築されるビデオ品質を実現しつつチャネル帯域幅の要件に適合する。レート制御は圧縮されたビデオストリームの離散レート歪（discrete rate-distortion）を、ビデオストリームがチャネル３８を介して伝送される前にコンピュータ化（computations）する。モバイル機器のコンピュータ上の制限で、典型的なレート制御ではチャネル帯域幅だけが考慮され、伝送チャネルのエラー特性については明確には考慮されていなかった。
【００３４】
本発明には望ましいことであり、また、実現可能なことは、高度なコンピュータ効率のあるアルゴリズムに基づく改良された適応可能な情報源・通信路符号化を使用することである。これにより、情報源符号化３２、通信路符号化３４とレート制御３６の３つの全てについて再構築されるビデオ信号の瞬時の平均品質（ビデオレートvsデストーション(distortion)）の両方を最大限に制御するために瞬時（instantaneous）と予測（predicted）できるチャネル帯域幅とエラー状態が利用可能となる。
【００３５】
改良された適応できる情報源・通信路符号化の技術の更なる利点は、本発明の視点からは、無線携帯とMMSサービスのプロバイダに大きな範囲の通信サービスの品質（QoS）を提供し、利用者と企業利用者に価格レベルを提供することにより無線ネットワークのインフラストラクチャ（基盤構造）を使って生み出す収益を最大化している。
【００３６】
マルチキャストシナリオは、多くのユーザーによって復号可能な単独の適応ビデオ・ビット・ストリームを要求する。これは現代の、大規模な、異種混交のネットワーク、このようなネットワークは帯域幅の制限により個々のユーザーに向けて特に調節された多数の同時放送ビデオ信号を送信することが不可能となる、では特に重要である。単独の適応ビデオ・ビット・ストリームのマルチキャストは、必要とされる帯域幅を大いに低くする。その反面、広帯域の無線または回線接続のハイエンドユーザーそして制限された帯域幅とエラーを起こしやすい通信手段を備えた携帯電話ユーザーを含む、多数のユーザーに復号可能なビデオ・ビット・ストリームの作成を要求する。モバイル機器におけるコンピュータ能力の制限のため、適応率制御装置の精度は一般的にとても粗末である。例えば、基礎層と１つの強化層からなる２層のビットストリームしか生成できない。
【００３７】
チャネルタイプ（無線および有線）、チャネル帯域幅、チャネルノイズ／エラー特性、ユーザー機器、そしてユーザサービスに関して、より高レベルの異種混交ネットワークへの支持を可能にするために、高い計算効率を備えたアルゴリズムに基づく改良した適応情報源・通信路符号化結合(adaptive joint-source channel coding)を利用することは、望ましく、本発明の態様によって可能になる。
【００３８】
＜モバイル画像送受信機(MOBILE IMAGING HANDSET)のアーキテクチャ＞
携帯送受信機（携帯電話）へのデジタル・カムコーダ（ビデオカメラ）機能の付加は、ハードウェア、ソフトウェア、または、ハードウェアとソフトウェアの組み合わせのいずれかに、通常、下記の機能の付加が要求される（図３参照）。
・プリアンプとアナログ・デジタル（A/D）信号変換回路網に相当する撮像装置アレイ（典型的にはCMOSまたはCCDピクセルアレイ）。
・プレプロセス、符号化／復号化（コーデック）、ポスト・プロセス等の画像処理機能。
・無線または有線ネットワークでの非同時送信または同時ストリーミングに対する処理画像のバッファリング。
・一つ以上の画像表示スクリーン。
・内蔵式または取外し可能な、ローカルの画像ストレージ。
【００３９】
MPEG-4等のDCT変換を基礎としたコーデックを使用すると、商用の画像利用可能な携帯送受信機（携帯電話）は、それらが通常取り込まれ表示される他のマルチメディア機器、例えば、テレビ、パーソナルコンピュータ、デジタル・カムコーダ（ビデオカメラ）およびパーソナルメディアプレイヤ等、に比べて、小さいサイズそして低フレーム率のビデオ画像の取り込みに制限される。これら後者の機器は、通常、30フレーム毎秒（fps）またはより高い表示速度で、VGA形式（640×480ピクセル）またはより大きなビデオ画像に保存／表示される。一方、商用の画像利用可能な携帯送受信機（携帯電話）は、15fpsまたはより低い表示速度で、QVGA形式（320×240ピクセル）、QCIF形式（176×144ピクセル）またはより小さいビデオ画像保存に制限される（例えば、図１参照）。この低いビデオ取り込み性能の原因は、過剰なコンピュータ上の要件、処理装置消費電力、そして、全部の数、形式、そしてDCT変換を使用したビデオ圧縮／非圧縮と関係するコンピュータ上の手順のシーケンスが義務付けられたバッファ・メモリによる。
【００４０】
商用のビデオ・コーデックとマイクロプロセッサ技術を使うことは、30fpsまたはより高水準ののフレーム率で、VGA（またはより大きな）ビデオの取り込みを目的とするモバイル画像送受信機にとって、とても複雑で、電力を必要とし、高価なアーキテクチャの原因となる。このような携帯送受信機（携帯電話）のアーキテクチャは、より大きなバッファメモリブロック（１メガバイト以上の典型的なメモリ容量）とともに、ソフトウェアプログラム、そして、縮小命令セット（RISC）プロセッサ、デジタルシグナルプロセッサ（DSP）、特定用途向け集積回路（ASIC）および再構成可能な処理装置（RPD）の組み合わせで動くハードウェア・アクセラレータの両方の組み合わせを利用したコーデックを必要とする。これらのコーデック機能は、そのようなRISCプロセッサ、DSP、ASIC、マルチメディアプロセッサおよびRPDを別々の集積回路（IC）として使用することによって実装できる。または、システム・イン・パッケージ（SIP）若しくはシステム・オン・チップ（SoC）の中に統合した１つ以上のRISCプロセッサ、DSP、ASIC、マルチメディアプロセッサおよびRPDを組み合わせることができる。
【００４１】
RISCプロセッサ、またはDSPで動作するコーデック機能は、典型的には、プログラミングエラーの修正または機能のアップグレードのために変更可能であるという利点をともなった、ソフトウェアルーチンである。特定の複合体（certain complex）を実装することの不利点、ソフトウェアとしての反復的なコーデック機能は、結果的に全体的なプロセッサ資源および消費電力要求が、モバイルコミュニケーション機器のそれらを通常越えることである。
ASICおよびマルチメディアプロセッサで動作するコーデック機能は、典型的には複合体の固定ハードウェア実装であり、反復的なコンピュータ上の手順、通常は、特別に調整されたハードウェア加速が全体的なコーデックの電力消費を大幅に低減できるという利点をともなう。固定ハードウェアに特定のコーデック機能を実装することの不利点は、長期でより高価な設計段階、固定されたシリコン実装の中にエラーが発見された場合における高価な製品のリコールの危険性、そして、画像アプリケーションに新しく作成された機能が付加される場合に製品に配備された固定シリコン機能アップグレードができないことである。
RPDで動作するコーデック機能は、典型的には、最終的なモバイル画像送受信機のハードウェア加速と機能性の追加または変更能力の両方を要求するルーティンである。RPDに特定のコーデック機能を実装する不利点は、ハードウェアの再構成を可能とするために、固定されたASICと比較して、より大きな数のシリコンゲートとより高い電力消費となることである。
【００４２】
複雑性を低減または除去する画像アプリケーションは、上記アーキテクチャを簡素化し、大量な商業展開で携帯送受信機（携帯電話）コストを両立させるために、反復的なコーデック機能がモバイル画像送受信機を全てのソフトウェア構成で30fpsのフレーム率でVGA（またはより大きな）ビデオ取得能力があるようにすることが望ましい。本発明はこれらの目的を上手く達成し、可能とする最初の技術である。
【００４３】
マルチメディア携帯送受信機（携帯電話）は、写真とビデオ通信の能力をサポートするだけではなく、付加的なマルティメディア能力（音声、音楽、画像）の多様性、そして、固定および可動性の無線アクセス・モード、2.5Gと3Gのセルラーアクセス、WiBro、HSDPA、WiFi、無線LAN、そしてブルートゥースを含むがこれに限定されるものではない、の多様性を要求する。そのような機器を開発、展開およびサポートすることを含んだ複雑性と危険性は、新たな利益を創出するサービスとアプリケーションをより効果的に展開するため、そして高価な機器のリコールを避けるために、無線（OTA）配給と多くの機能およびアプリケーション経営に非常に利益をもたらす。
【００４４】
ソフトウェア単体実行による画像アプリケーションは、携帯送受信機（携帯電話）製品、携帯電話事業者、そして他のMMSサービス・プロバイダーによる無線（OTA）配給と画像アプリケーションの運営を有効にすることが望ましい。
【００４５】
＜モバイルJAVAアプリケーション＞
Java技術は、一つの言語と一つの技術で、デスクトップのサーバーからモバイル機器まで広範囲の機器をもたらす。この範囲の機器のアプリケーションは異なっているが、Java技術はこれらの重要な違いを克服して動作し、ある分野で有能な開発者が広範囲の装置とアプリケーションにわたって彼らの技術を活用することを可能にする。
【００４６】
サン・マイクロシステムによって、1999年6月に、最初にJavaコミュニティーに発表されたJ2ME（Java２、Micro Edition）は、Java開発者の多様なニーズを満たす広範な先制の一部であった。Java2プラットフォームとともに、サンは３つのエディションに分類してJava技術のアーキテクチャを再定義した。スタンダード・エディション（J2SE）は、デスクトップ展開と、低価格なビジネスアプリケーションの実用的な解決案として提供された。エンタープライズ・エディション（J2EE）は、企業環境のためのアプリケーションを専門としている開発者のためのものであった。マイクロ・エディション（J2ME）は、制限されたハードウェア資源、例えば、PDA、携帯電話、ページャ（ポケベル）、テレビのセット・トップ・ボックス、遠隔情報操作装置およびその他多くの家庭用電化製品と埋め込み装置等、の機器に従事する開発者のために発表された。
【００４７】
J2MEは、わずか128KBのRAMと、これらが使用される典型的なデスクトップおよびサーバーコンピュータに比べてかなり劣るプロセッサを備えた機械に向けられた。J2MEは、実質的には一組のプロファイルから構成される。それぞれのプロファイルは、特定タイプの機器、例えば携帯電話、PDAなど、を定義する。そして、特定タイプの機器および機器をサポートするJava仮想マシンの仕様に必要な最小限のクラスライブラリのセットから構成される。全てのJ2MEプロファイルに規定された仮想マシンは、必ずしもJava2スタンダード・エディション（J2SE）およびJava2エンタープライズ・エディション（J2EE）で使われた仮想マシンと同じであるとは限らない。
【００４８】
プロセッサ能力、メモリ、固定ストレージおよびユーザインターフェースの相違のため、上記に記載された全ての機器に対して、最適な若しくは最適に近い、単独のJ2ME技術を定義することはとても困難である。
この問題に取り組むため、サンは、J2MEを区分にするための機器適合の定義を共有後、さらに再共有した。最初に、サンは使用目的を無視して、処理能力、メモリそして記憶容量に基づいて２つの広範なカテゴリに共有した。
同社は、次に、少なくとも最低限のJava言語機能を備えながら、それぞれのカテゴリの中で、機器の制約の範囲内で動作する、余分な装備を取り除いたJava言語のバージョンを定義した。
【００４９】
次に、サンは、それぞれこれら２つのカテゴリの中で、同じような役割を持つ機器のクラスを特定した。例えば、全ての携帯電話は、製品にかかわらず、１つのクラスの中に含まれた。Javaコミュニティ・プロセス（JCP）との協力により、サンはその後、それぞれの機器のクラスに特有の追加機能性を定義した。
【００５０】
最初の共有は、２つのJ2ME想定環境（configuration）、コネクテッド・デバイス・コンフィギュレーション（CDC）およびコネクテッド・リミテッド・デバイス・コンフィギュレーション（CLDC）、を作り出した。想定環境は、Java仮想マシン（JVM）と機器の選択グループに対しランタイム環境を規定する最低限のクラス・ライブラリとAPIのセットとできる。想定環境は、展開された機器の種類によって強いられた資源制約の範囲内で適合するJava言語の、最小共通基準サブセットを特定できる。ユーザインターフェース、機能そして使用法によって大きな変動性があるために、典型的な想定環境は、ユーザインターフェース・ツールキットおよび固定ストレージAPIのような重要な部分を定義しない。代わりに、その機能の定義付けはいわゆるプロファイルに属する。
【００５１】
J2MEプロファイルは、ページャおよび携帯電話のような機器の特定クラスを扱う産業主導型グループによって規定されたJavaAPIのセットとすることができる。それぞれのプロファイルは、その想定環境によって提供されたJava言語の最小共通基準サブセットの上部に構築され、その想定環境を補うように作られている。携帯送受信機（携帯電話）に重要な２つのプロファイルは、CDCを補助するファウンデーション・プロファイル（Foundation profile）、および、ＣＬＤＣを補助するモバイル情報デバイス・プロファイル（MIDP）である。より多くのプロファイルが進行中であり、仕様およびリファレンス実装が開発され発売されている。
【００５２】
The Java Technology for the Wireless Industry（JTWI）仕様、JSR185、は、次世代のJava技術を可能にする携帯電話に対する業界標準プラットフォームを規定する。JTWIは、主要な携帯機器製造業、無線通信事業者およびソフトベンダーの専門グループによるJavaコミュニティプロセス（JCP）によって創設された。JTWIは、全てのJTWI対応機器、適応可能なCLDC1.1（JSR139）およびMMAPI（JSR135）と同様にCLDC1.0（JSR30）、MIDP2.0（JSR118）およびWMA1.1（JSR120）、に含まれる技術を規定する。モバイルマルチメディア機器に対する技術およびインターフェースを定義した２つの追加JTWI仕様は、JSR-135（"Mobile Media API"）およびJSR-234（"Advanced Multimedia Supplements"）である。
【００５３】
JTWI仕様は、API断片化を最小限にして既に携帯電話のために開発されたアプリケーションの実質基準を拡張する一方で、高容量機器の機能性の制約を引き上げる。
JTWIの利点は以下を含む：
・相互運用性： この効果の目標は、アプリケーション開発者のための予測可能な環境と、機器製造業者のための配送可能な機能セットを配信することである。その目的は、JTWI標準に適合することによる２つの利点である。製造業者は広範囲の互換性のあるアプリケーションによる利益を享受し、ソフトウェア開発者はそれらのアプリケーションをサポートする広範囲の機器の利益を享受する。
・安全性仕様の明確化： JSR185仕様は、MIDP2.0仕様で規定した"Recommended Security Policy for GSM/UMTS-Compliant Devices"に関し、信用できないアプリケーションに対して幾つかの明確化を導入する。それはMIDP2.0で定義されたベースMIDlet suiteセキュリティ・フレームワークのベースを拡張する。
・ロードマップ： JTWI仕様の重要な特徴は、ソフトウェア開発者がJTWI準拠機器に期待できる共通の機能性の大要であるロードマップである。2003年1月、携帯電話の進化と調和した追加機能性を記述し、6から9月の間隔で出現することを期待されたロードマップシリーズの第一号が現れた。ロードマップは、全ての関係者がより信頼のもてる将来に対して計画をすることを可能にする：通信事業者はアプリケーション展開戦略のより優れた計画を立てることができ、機器製造業者は製品計画においてより優れた決定ができ、そして、コンテンツ開発者はアプリケーション開発努力のための明確な指針を予見することができる。特に通信事業者は、将来的に、現在、公衆インターネットにはびこるウイルス、ワーム、そして他の“アタック”（"attacks"）のようなセキュリティー違反から、根本的な無線通信／ネットワーク機能を取り出し／保護するJavaVMに頼るであろう。
【００５４】
Javaベース画像アプリケーションは、全てのJava対応送受信機にわたる「一度コードを書けば、どんな環境でも動作する」携帯性、また、ウイルス、ワーム、そして他のモバイルネットワークセキュリティ“アタック”（"attacks"）に対抗するJavaVMセキュリティおよび携帯送受信機（携帯電話）／ネットワーク構造安定性、そして、単純化した無線コーデックおよびアプリケーションダウンロード手順にとって望ましい。そのようなJavaベース画像アプリケーションは、JTWI仕様、JSR-135（"Mobile Media API"）およびJSR-234（"Advanced Multimedia Supplements"）に準拠する。本発明の形態はこれらの利点を提供する。
【００５５】
＜モバイル画像サービスプラットホームのアーキテクチャ＞
本発明の態様によるモバイル画像サービスプラットホームのアーキテクチャの重要な構造は、以下を含む（図４参照）。
・携帯電話機 ６０
・移動体基地局（BTS） ６２
・基地局制御装置／無線ネットワーク制御装置（BSC/RNC） ６４
・移動体交換局（MSC） ６６
・ゲートウェイ・サービス・ノード（GSN） ６８
・モバイルマルチメディアサービス制御装置（MMSC） ７０
【００５６】
本発明の態様によるMMSCに含まれた典型的な機能は、以下を含む（図４参照）。
・映像ゲートウェイ ７２
・通信会社サーバ ７４
・MMSアプリケーション・サーバ ７６
・ストレージ・サーバ ７８
【００５７】
本発明の態様によるMMSCのビデオゲートウェイは、画像サービスプラットフォームによってサポートされた異なるビデオフォーマット間のトランスコードに役立つ。トランスコーディングは、また、携帯電話ネットワークで使用される異なる音声コーデックをサポートする無線オペレータによって利用され、対応する音声トランスコーダはRNCに組込まれる。そのようなモバイル画像サービスプラットフォームを図４に示すアーキテクチャとともにアップグレードすることは、従来のアーキテクチャなら、通常、新たな送受信機を展開し、そして、手動で新しいハードウェアをMMSCビデオゲートウェイに付加することを必要とする。一部のモバイルビデオ通信および共有利用アプリケーションは、トランスコーディングと関連する費用と複雑性を削除することは望ましい。現在の発明の態様の一つとして、各送信されたビデオ・ストリームとともにソフトウェア・デコーダを組み込み、公共の送受話機およびPVビデオプレーヤにおける"自立再生"（"self-playing"）機能を可能にする能力がある。
【００５８】
MMSCの中のMMSアプリケーション・サーバは、ユーザー作成ビデオのデータベース・ストレージ、検索、および修正と同様に、自動または手動のユーザー作成ビデオの編集のようなアプリケーションもサポートできる。そのような機能の実装を要件とするコンピュータの複雑性は、標準のパーソナルコンピュータ（PC）およびサーバで使用されている安価で性能の低いCPUチップで動作する単純なソフトウェアプリケーションよりも、一般的に高価で高性能な特定用途向け集積回路（ASIC）およびデジタルシグナルプロセッサ（DSP）が必要な対応ビデオ処理機能とともに、モバイルオペレータによってインストールされる専門化したサーバを必要とする。
【００５９】
本発明の態様によって与えられるように、本発明の態様によるソフトウェア単体実行による・モバイル画像アプリケーション・サービス・プラットフォームは、展開された携帯送受信機（携帯電話）の自動無線アップグレード、展開されたMMSCの自動無線アップグレードのサポートのために望ましく、標準PCとサーバで使用されているモバイルビデオアプリケーションへサポートする。
本発明の態様による携帯送受信機（携帯電話）画像アプリケーションのJava実装は、ウイルス、ワーム、および他の“アタック”（"attacks"）に対抗する改良した送受信機／ネットワークの構造安定性に関して望ましく、モバイルネットワークオペレータが、全国的な調整機関によって要求されるサービスの品質と信頼性を提供することを可能にする
【００６０】
＜問題＞
モバイルビデオ通信および共有利用サービスの展開は、映像圧縮技術の本質的な限界にさらされている。
【００６１】
一方では、そのようなモバイルビデオサービスは、今やホームシネマ品質放送−VGAのような30フレーム毎秒のフルサイズ画像方式、の映像と同等の市場に乗り出している。他方で、本来、放送およびストリーミングのアプリケーションのために開発された現存する映像技術を使用して、このような大容量データ処理を行うことは、携帯電話のリアルタイム・ビデオ・キャプチャ（符号化）に利用可能なコンピュータリソースおよびバッテリ電力を大幅に超過する。放送およびストリーミングのアプリケーションは、高複雑性エンコーダがコンピュータワークステーション上で動作可能なスタジオ環境における映像コンテンツの符号化に依存する。ビデオメッセージは携帯送受信機（携帯電話）にリアルタイムで取り込まれるため、より小さいサイズおよびより低いフレーム率に制限される。
【００６２】
結果、今日のモバイルビデオサービスは原始的である；加入者がデジタル・カムコーダ（ビデオカメラ）に期待するようになったテレビ電話機能を複製するところまできている機能と比較して、写真は小さく（QCIF、QVGA）、粗い（15fpsまたはそれ以下）である。モバイル加入者に提供される原始的なビデオ画像品質は、産業界によるライフスタイルの広告で宣伝される鮮明なhigh-definition video(HDV)に程遠い。モバイル加入者は、広範囲に採用されカメラ一体型（カムコーダ）電話および関連するモバイル映像サービスに割増価格を払う前に、30fpsパフォーマンスのフルVGA（すなわちカムコーダと同様）を要求している。
【００６３】
本発明者は別として、営利事業要求と技術能力をはるかに上回る全体のコストおよび電力消費を伴いながら、VGA30fpsパフォーマンスの提供を試みようとして、競合するビデオ・コーデック・プロバイダーは、非常に高価で多大な時間を必要とする開発計画にもかかわらず、未だ複雑な混合ソフトウェア・コーデック＋ハードウェア・アクセラレータによる解決方法を提供するのみである。携帯送受信機（携帯電話）はこのように小さく粗い画像か、高価な高消費電力構造に制限される。大衆市場に採用されるには、サービス展開はとても高価であり、サービスの品質はとても低い。
【００６４】
新しい、若しくは特定のハードウェアが必要ならば、MMSC基盤をアップグレードすることも、同様に費用がかかる。ソフトウェア単体実行アプリケーションとサービス・プラットフォームは、携帯送受信機（携帯電話）の自動無線アップグレード、MMSCビデオゲートウェイのネットワーク通信によるアップグレードを可能にし、標準ＰＣおよびサーバを使用したモバイルビデオアプリケーションをサポートすることが望ましい。異なったビデオフォーマット間でのトランスコーディングの必要性も、同様に、追加費用と複雑性が加わる
【００６５】
＜解決法＞
特に本発明の態様によるこの問題の解決法は、携帯送受信機（携帯電話）構造の複雑性およびモバイル画像サービス・プラットフォーム構造の複雑性を低減し、ソフトウェア単体実行アプリケーションとして携帯送受信機（携帯電話）に実装できる、非常に単純な画像アプリケーション（コーデック）である。
本発明の態様によって、ソフトウェア単体実行によるビデオ・コーデック・ソリューションは、マルチメディア携帯送受信機（携帯電話）におけるベースバンド・プロセッサとビデオ・アクセラレータの費用と要件を大幅に低減または排除する。無線ダウンロードによるコーデック・ポストプロダクションをインストールする能力と組み合わせて、このソフトウェア単体実行ソリューションは、携帯送受信機（携帯電話）の発展とビデオ通信サービスの構造および展開の複雑性、リスクおよびコストを大幅に低減する。
本発明によるソフトウェア・ビデオ・トランスコーダおよび編集、保存、検索する修正アプリケーションは、そのようなアプリケーションで動作する標準PCおよびサーバの使用と同じように、展開されたMMS制御（MMSC）基盤の自動的なネットワークによるアップグレードを可能にするさらに、本発明のウェーブレット・トランスコーダは、通信事業者に、ウェーブレット・ビデオ・フォーマットと他の標準ベースおよび独自仕様のビデオフォーマットとの間の完全な相互運用性を提供する。本発明は、また、ソフトウェアデコーダが各送信ビデオストリームとともに取り込まれ、公共の携帯送受信機（携帯電話）およびPVビデオプレーヤでの"自立再生"（"self-playing"）機能を可能にし、トランスコーディング全体の費用と複雑性を排除する。
本発明のソフトウェア単体実行によるビデオ・プラットフォームは、新しいMMSサービスの急速な展開を可能にし、本発明の実施態様の一部も、他の現存する技術では得られない目的達成処理速度およびビデオ製品精度を可能にする。そのような新しいMMSサービスが本発明の特徴である。
本発明のウェーブレット・コーデックは、静止画像およびビデオの両方を効果的に処理する能力が際立っており、モバイル画像メールおよびビデオ通信サービスの両方を同時にサポートできる単独の低コストおよび低電力ソリューションとともに、別々のMPEGおよびJPEGコーデックに置き換えることができる。
【００６６】
本実施態様において、正確な態様、図、または実施例では、“Droplet”態様若しくは実施態様と記載している。本出願において、“Droplet”とは、本発明の実施態様を参照して理解される。
【００６７】
＜改良されたウェーブレット・ベースの画像処理＞
本発明の態様は、DCTベースのコーデックと比べ非常に低いコンピュータ複雑性を備えたビデオ圧縮／非圧縮（コーデック）装置における三次元（３D）ウェーブレット変換を利用する（図５では、従来のDCTエンコーダ技術と本発明の典型的な技術との相対的なコンピュータ要件の比較を提供している。）。ウェーブレット変換段階のアプリケーションは、また、大いに低減したコンピュータ上の複雑性とともに、量子化およびエントロピー符号化段階の設計を可能にする。モバイル画像アプリケーション、機器、およびサービスに対する本発明の３次元ウェーブレット・コーデックのさらなる効果は、以下を含む。
・対称的な、低複雑性ビデオの符号化および復号化
・ソフトウェアおよびハードウェア両方のコーデック実装に対する低プロセッサ電力要件
・ネイティブコードおよびJavaアプリケーションの両方として、現存する商用携帯送受信機（携帯電話）と互換性がある30fps（またはより高い）のフレーム率でのVGA（またはより大きな）ビデオのソフトウェア単体実行による符号化および復号化
・SoCインテグレーションのための、低ゲートカウントASICコア
・低バッファメモリ要件
・静止画像（〜JPEG）およびビデオ（〜MPEG）両方の単独コーデックサポート
・短いGOP（Group of Pictures）による単純化されたビデオ編集（カット、挿入、テキスト・オーバーレイ）
・短いGOPによるビデオコーデックをともなった単純同期化
・短いGOPによる改良ビデオストリーミングに対する低遅延時間
・適応率制御、マルチキャスティング、および情報源・通信路符号化結合(joint-source channel coding)に対する微粒子（fine grain）拡張性
・新興のHDTVビデオフォーマットの低複雑度パフォーマンス・スケーリング
・コンパクト・ソフトウェア・デコーダ（例えば、40ｋB以下のような）は、公共の携帯送受信機（携帯電話）およびＰＣビデオプレーヤと互換性がある"自立再生"（"self-playing"）ビデオメッセージが可能な各ビデオストリームと一体化可能である。
【００６８】
以上の効果は本発明に含まれる以下の特徴により達成される。
【００６９】
リフティング構成における16bit・32bit二項（short dyadic integer）フィルター係数を用いたウェーブレット変換アプリケーション： 本発明の実施では、ハール、２−６、および５−３ウェーブレット変換や様々なウェーブレット変換が使用される。これらは加算、除算および小幅な固定シフト(small fixed shifts)のみを必要とし、乗算や浮動小数点操作は不要である。
【００７０】
リフティングスキームによる計算： これらのフィルタはリフティングスキームを用いて計算され、現場（in-place）計算を可能とする。このことにより、レジスタの使用およびRAMの一時的占有を最小化し、照会先をローカルで済ませてキャッシュの使用効率を高める。
【００７１】
カスタマイズされたピラミッド構造でのピラミッド方式ウェーブレット変換： 本発明の実施では、ウェーブレット変換シーケンスにおいて、先の段階の結果となるデータの半分に基づいて各段階を計算する。その結果、総合した計算は各段階の数字から殆ど独立したものとなる。本発明の実施では、このピラミッドをカスタマイズして上記リフティングスキームの利点を活用し、レジスタの使用およびキャッシュメモリの処理能力をさらに効率化する。
【００７２】
ブロック構造： 多くのウェーブレット圧縮とは対照的に、本発明では画像を長方形のブロックに共有し、各ブロックを、他のブロックとは別個独立に処理を進める。これにより、メモリ参照をローカルで済ませることができ、プロセッサ内に残るデータを利用しながら変換ピラミッドの全体を実行できる。そのため、多くの場合プロセッサ内で移動するデータ量を大幅に小さくできる。このブロック構造は、とりわけハードウェアでの実施に有益である。それは信号を流す上で中間ストレージに大きな容量が不要となるからである。
【００７３】
ブロック境界フィルター： 本発明では、本出願で援用するアメリカ国特許出願番号10/418,363で詳述される修正フィルターの計算を行うことで、各ブロックの境界における明瞭なノイズを防止することもできる。
【００７４】
一時的彩度除去： 本発明の特徴により、フィールド毎の彩度差信号の処理も回避でき、その代わりに本出願で援用するアメリカ国特許出願番号10/447,514で詳述されている、一つのGOP（Group of Pictures）の彩度についての単フィールドを使用する。
【００７５】
三次元ウェーブレットを用いた時間圧縮（temporal compression）： 本発明の実施では、MPEGのような従来の動画圧縮手法における、非常にコストの高い動きの検出と補償の操作は用いない。その代わりに、本発明の実施ではフィールドからフィールドへの（field-to-field）時間ウェーブレット変換（temporal wavelet transform）を計算する。これにより計算コストを大幅に削減できる。この処理では、リフティングスキームとともに16bit・32bit（short integer)フィルタが使用されることもある。
【００７６】
二進数量子化： 本発明の実施例において、圧縮過程における量子化ステップは、係数分配域全体を通じて均一に二値化操作を行うことにより達成する。これにより従来の量子化において要求されたサンプル毎の乗算・除算を回避する。
【００７７】
パイリング： 本発明の実施例において、以下に述べるエントロピー符号化手法によって扱われるデータ量は、連続ゼロ変換を経て削減される。本発明の実施ではアメリカ国特許出願番号10/447,455において公開されている方法と発明が、並行処理アーキテクチャ上の連続したゼロの計上に利用される。
【００７８】
循環型（Cycle-efficient）エントロピー符号化： 本発明の実施例において、圧縮過程におけるエントロピー符号化のステップは、従来的表検索（table lookup）と入力シンボルの直接計算とを重ね合わせて処理するという技術により達成される。シンボル割り当ては特性化されているので、ライス−ゴロム符号化や、指数ゴロム符号化、Dyadic Monotonicのような単純なエントロピー符号化手法を用いることができる。エントロピー符号化の手法に何を選択するかは、プロセッサプラットホームの能力に従って変化する頻度が高い。
【００７９】
＜改良された適応情報源・通信路符号化結合(adaptive joint-source channel coding)＞
本発明の特徴によるウェーブレットベースコーデックのきめ細かい拡張性は、改良適応レートコントロールや、マルチキャスティング、情報源・通信路符号化結合(joint-source channel coding)を可能とする。コンピュータ上の複雑性を軽減し、本発明のウェーブレットアルゴリズムのより高い計算効率性により、ある瞬間の予測されたチャネル帯域幅とエラー状態に関する情報を、ソースコーダ、チャネルコーダ、レートコントローラの３つ全てにおいて利用することが可能となり、再構築された動画信号（図６参照）の瞬時および平均時双方の画質（ビデオレート対歪曲収差）管理を最適化する。本発明により改良された適応情報源・通信路符号化結合(adaptive joint-source channel coding)によって、無線通信会社やMMSサービスプロバイダは、サービスの質（Quality of Service : QoS）の効率性をより高くでき、個人消費者や企業顧客が求める価格まで引き下げることが可能となる。計算効率性をより高くしたアルゴリズムに基づいた改良適応情報源・通信路符号化結合(adaptive joint-source channel coding)を利用することで、ネットワーク上の異種混交をより高いレベルにおいて実現するサポートが可能となる。ここでの異種とは、通信の形式（無線と有線）、通信帯域、通信におけるノイズ又はエラーの特質、ユーザ使用機器、およびユーザ使用サービスという観点においてである。
【００８０】
＜改良されたモバイル画像送受信機のプラットホームアーキテクチャ＞
図７が表すのは、本発明の特徴と実施に従って改良されたモバイル画像送受信機のプラットホームアーキテクチャである。本発明の特徴による画像処理アプリケーションは、ソフトウェア単体実行アプリケーションとして実装され、RISCプロセッサにおいてネイティブコード（マシン語プログラム）若しくはJavaアプリケーションとして実行される。Javaコード化の加速操作はRISCプロセッサ自体に実装することが可能であり、若しくは別個のJavaアクセラレータICを使用して行うこともできる。このJavaアクセラレータはスタンドアローン（独立型）ICとして実装することも可能であり、またはこのICをSIPかSoCのいずれかにおける他の機能と統合することも可能である。
【００８１】
図７が示される、改良されたモバイル画像送受信機のプラットホームアーキテクチャは、モバイルビデオアプリケーションのための（これまでの機器やシステムでは必要とされるであろう）別個のDSP、ASIC、マルチメディアプロセッサ、またはRFD処理ブロックを不要とする。また、このアーキテクチャは携帯電話機における画像処理で必要とされるバッファメモリをも大幅に削減している。
【００８２】
図８は、本発明によるフルビデオ（VGA／30fps）のエンコーディングでは必要とされる計算性能を低く抑えることができていることを表している。この必要とされる性能の削減は、本件出願の優先出願日以後にMPEG-4およびH-264ビデオコーデックに基づいた現時点の技術が達成している能力値と比較対照して、という意味においてである。
【００８３】
図９が表すのは、市販されるカムコーダ（ビデオカメラ）付GSM携帯電話機のプラットホームにおける本発明の特徴を実装する部分である。既存のGSMベースバンド／マルチメディアSoC（図９で示されるTexas社製OMAP850）は、QCIF／15fpsビデオカメラ機能のため、ハードウェアクセラレータや、DSP、RISCプロセッサを必要とする。これに対し、本発明は、このプラットホームでVGA／30fpsビデオカメラ機能を実現する。この実現はRISCプロセッサ上で実行されるソフトウェアのみの使用で可能となり、ハードウェアクセラレータやDSPを必要としない。
【００８４】
図１０が表すのは、市販されるカムコーダ（ビデオカメラ）付CDMA携帯電話機のプラットホームにおける本発明の特徴を実装する部分である。既存のCDMAベースバンド／マルチメディアSoC（図１０で示されるQualcomm社製MSM6500）は、QCIF／15fpsカムコーダ（ビデオカメラ）機能のため、ハードウェアクセラレータや、DSP、RISCプロセッサを必要とする。これに対し、本発明は、このプラットホームでVGA／30fpsカムコーダ（ビデオカメラ）機能を実現する。この実現はRISCプロセッサ上で実行されるソフトウェアのみの使用で可能となり、ハードウェアクセラレータやDSPを必要としない。
【００８５】
＜改良されたモバイル機器を通じた画像サービスのプラットホームアーキテクチャ＞
本発明の実施態様である改良されたモバイル機器を通じた画像サービスのプラットホームアーキテクチャの構成要素（図11参照）：
・携帯電話機 １６０
・携帯電話中継基地（BTS） １６２
・中継基地管制機／無線通信管制機（BNS／RNC） １６４
・携帯電話交換センター（MSC） １６６
・ゲートウェイサービス接続ポイント（GSN） １６８
・モバイルマルチメディアサービス管制機（MMSC） １７０
・画像サービスダウンロードサーバー １７１
【００８６】
MMSCの典型的機能（図１１参照）：
・動画ゲートウェイ １７２
・通信会社サーバー １７４
・MMSアプリケーションサーバー １７６
・ストレージサーバー １７８
【００８７】
本発明の実施例の特徴に基づいた、改良された画像サービスのプラットホームの展開は次の手順を採る。
【００８８】
手順１
【００８９】
展開されたMMSCのアップデートに供するビデオゲートウェイトランスコーダアプリケーションおよび／又はビデオ通信・共有アプリケーションが利用可能であるという信号を、ネットワークに送信する。アップデートファイルは、ネットワークを通じて自動的に、若しくは手動操作でインストールされる。
【００９０】
手順２
【００９１】
ビデオゲートウェイトランスコーダアプリケーションおよび／又はビデオ通信・共有アプリケーションについて、ネットワークを通じて自動的に、若しくは手動操作により、インストールおよび設定を行う（図１２参照）。
【００９２】
手順３
【００９３】
モバイル動画ファイルがダウンロードおよびインストール可能であるという信号を、登録された携帯電話機に送信する。
【００９４】
手順４
【００９５】
登録機が受信し、取引決済が正常に完了すると、モバイルビデオファイルがダウンロードされ、インストールされる。
【００９６】
手順５
【００９７】
携帯電話機のアップグレードが完了した旨の信号をネットワークに送信する。サービスおよび関連アプリケーションを利用可能にする。モバイル動画ファイルの代金を、登録者の月額使用料金請求書に計上するために、記録更新を行う。
【００９８】
本発明の特徴として図１３が示すのは、ソフトウェアデコーダと伝送されるビデオストリームを一体化することで"自立再生"するビデオMMSの機能性が達成されることである。
【００９９】
本発明の特徴として図１４が示すのは、ビデオアプリケーションサーバーの複雑性、コスト、数を削減することである。このサーバーはメディアプロデュースサービスの展開に必要とされ、ユーザーが創作したビデオの貯蔵、検索、復旧だけでなく、ユーザー創作ビデオの自動ないし手動の編集も行われる。
【０１００】
本発明の特徴として図１５が示すのは、ビデオの送信・共有・呼出を行うプラットホームの機能的要素である。このプラットホームは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そしてビデオの編集およびデータの貯蔵・検索・復旧を組み入れたものである。
【０１０１】
本発明の特徴として図１６が示すのは、より高品質なマルチメディア携帯電話機とサービスを、より速く、より低コストで開発・展開できるという観点からの利点である。この利点には、革新的な個人マルチメディア市場プラットホームを展開できることが含まれ、このプラットホームにおいて、ユーザーが創作したオーディオないしビデオのコンテンツの"ソフト"コピー（ダウンロード）または"ハード"コピー（DVD）を、ユーザーは試聴や共有、売買することが可能となる。本発明によって、より効率的なビデオの"タグ付け"もまた可能となる。このタグ付けは、データベースの索引付けや、ネットワーク（RSS）情報提供、E-bay、Google、Yahoo、Microsoftや他のポータルサイトのような既存のウェーブ上の市場との橋渡しのサポートに用いられる。
【０１０２】
本発明の特徴として図１７が示すのは、革新的モバイルビデオサービスである。このサービスは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そしてビデオの編集およびデータの貯蔵、検索、復旧に基づいている。
【０１０３】
本発明の特徴として図１８が示すのは、本発明によるウェーブレットベースのコーデック／カムコーダ（ビデオカメラ）アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、そして動画の編集およびデータの貯蔵・検索・復旧を組み入れた、ビデオの送信・共有・呼出を行う上記のプラットホームのアプリケーションソフトである。このアプリケーションは、固定無線、移動無線および有線のアーキテクチャの要素を組み合わせた"集中型"ネットワークだけでなく、固定無線、移動無線、有線のネットワーク上で行われる新しい動画サービスを展開するために用いられる。
【０１０４】
＜パフォーマンス＞
本発明によって改良された、ウェーブレットに基づくモバイルビデオ動画処理アプリケーション、情報源・通信路符号化結合(joint-source channel coding)、携帯送受信機（携帯電話）アーキテクチャおよびサービスプラットホームアーキテクチャを内包することにより、より高画質なモバイルビデオ画像、携帯送受信機（携帯電話）のコストの削減、アーキテクチャの単純化およびサービス展開コストの削減という目的が達成される。
【０１０５】
＜様々な実施例＞
本発明の特徴の実施により、モバイル画像送受信機アーキテクチャを高度なものとなる。たとえば、ソフトウェア単体実行のウェーブレットに基づく画像処理アプリケーションとして、実装オプションがいくつか考えうる（図１９参照）。画像処理アプリケーションは無線（OTA：over the air）ダウンロード（400a、400b、400c）を通じて、携帯送受信機（携帯電話）402aのベースバンドマルチメディア処理部、着脱可能ストレージ機器402b、または画像処理モジュール402cにインストールされる。希望すれば、画像処理アプリケーションは製造過程中または店頭販売時において携帯送受信機（携帯電話）のベースバンドマルチメディア処理部、着脱可能ストレージ機器、または画像処理モジュールにインストールすることも可能である。追加的実装オプションは、モバイル機器のアーキテクチャの発展型として組み入れることもまた可能である。
【０１０６】
本発明の特徴により、モバイル画像送受信機のパフォーマンスはさらに向上し、コストと電気消費は一層削減される。このことは、ハードウェアベースの処理リソースを通じて計算機的要素を加速化することを手段とする。その理由は、現在発展中であるモバイル機器の計算処理ハードウェア（ASIC、DSP、マルチメディアプロセッサ、RPD）や、集積回路技術（SoC、SIP）を活用するためである。これらの携帯電話機におけるハードウェアベースの処理リソースを集中させるため、ハードウェアのみによるオプションが実行されうる（図２０参照）。このハードウェアオプションには、携帯送受信機（携帯電話）のベースバンドマルチメディア処理部や着脱可能ストレージ機器、画像処理モジュールが含まれる。
【０１０７】
図２１に示されるように、本発明による画像処理アプリケーションによって提供される複合型アーキテクチャは、ハードウェア面におけるコンピュータ的な集中的、反復的、固定的である機能の実行および、ソフトウェア面における製造後に改良が望まれ、必要とされる機能の実行を通じて、処理能力向上に資する。
【０１０８】
本発明の特徴によって、モバイルカムコーダ（ビデオカメラ）機器のアーキテクチャ、配置およびメンテナンスを単純化できる可能性を、図２２は示している。
【０１０９】
＜効果＞
本発明におけるソフトウェア単体実行による画像処理は、マルチメディア携帯電話機でのベースバンドプロセッサとビデオアクセラレータのコストおよび必要部品を大幅に削減させる。無線（OTA：over the air）ダウンロードを経由した撮影後編集コーデックのインストール・メンテナンス機能を併用することで、このソフトウェア単体実行による画像処理によって、携帯電話機開発と動画通信サービス展開の双方の複雑性、リスクおよびコストの大幅な削減を可能とする。
【０１１０】
本発明により、携帯電話通信会社は最上級のモバイルビデオ通信・共有プラットホームを利用でき、ビデオ画質、携帯送受信機（携帯電話）小売価格およびサービス展開コストの点で、大衆市場における個人消費者や企業顧客の需要に応えることが可能となる。本発明は、カムコーダ（ビデオカメラ）付携帯電話機で、フルサイズ動画（VGA：640×480ピクセル）を毎秒30フレーム（fps）でリアルタイム撮影することを可能とする最高品質のソフトウェア単体実行アプリケーションを提供する。これは、本発明の特徴によって、圧倒的多数のマルチメディア携帯送受信機（携帯電話）に既に内蔵されている標準的RISCプロセッサを使用するだけで可能となる。携帯電話通信会社は、本発明によって単純化された動画処理・流通の技術と、新しいソフトウェア単体実行プラットホームとを統合化して、既存の携帯送受信機（携帯電話）やモバイルマルチメディアメッセージサービス（MMS）のインフラを使用した包括的展開を可能としうる。上記ソフトウェア単体実行モバイルビデオカメラアプリケーションを補完するものとして、携帯電話通信会社は、本発明によるコンテンツ管理プラットホームの特徴を利用することで、圧縮された画像・動画を、この技術に従って音声や文章と統合し、完成されたモバイルマルチメディアメッセージや"着信音"とするモジュールが利用できる。このコンテンツ管理プラットホームでは、このようなモジュールだけでなく、オン・ザ・フライ（中間出力を必要としない）編集や、サムネイルプレビュー、マルチメディアメールボックス、オンラインストレージ、共有、マーケティングサービスおよび登録管理をも利用可能とする。
【０１１１】
下記の例１では、デモンストレーションの構成要素、設定および操作が記載されているが、このデモが紹介するのは本発明におけるソフトウェアのみによるモバイルビデオメッセージプラットホームの特徴を実施することで得られる機能と利点である。デモでは市販されているGSM/GPRSマルチメディア携帯送受信機（携帯電話）が使用され、あらゆる商業的GSM/GPRSネットワークにおいて操作されることが意図された。実演は充分な成功を収めた。このデモンストレーションはCDMA携帯送受信機（携帯電話）を使用し、商業的CDMAネットワークにおいて操作される形でも容易に行うことができる。例１のデモでは、"Droplet"というコード名が付けられ、例１においてそのように標示された、デモと一連のファイルが実行される。
例１
図２３と図２４で図示されるように、デモンストレーションは次の５つの要素を含む。
１．MMSサービスプロバイダーのサーバーコンピュータから、本発明によるソフトウェア単体実行の"DTV"ビデオコーデックアプリケーションを、無線通信を介して（OTA：over the air）ダウンロードして、マルチメディア携帯送受信機（携帯電話）にインストールする。
２．DTVビデオコーデックを使って、マルチメディア携帯送受信機（携帯電話）の内の高画質（VGA、30fps）ビデオメッセージを圧縮する。
３．圧縮されたビデオメッセージ（本発明によるDVTフォーマット形式）をMMSサーバに送信する。これはコンピュータやテレビに転送・再生するためのフルサイズ解像度（VGA/30fps）でも、携帯送受信機（携帯電話）への転送・再生用に縮小した低解像度（QCIF/15fps）でも同様である。
４．ネットワークに接続されたコンピュータへのメールアラートや携帯送受信機（携帯電話）へのSMSアラートを通じて、MMSサーバから、圧縮されたビデオ画像がダウンロード可能となったという知らせが送信される。
５．圧縮されたビデオメッセージは、本発明によるDTVデコーダと一緒にダウンロードされる。これは"自立再生"（"self-playing"）機能、すなわち、ネット接続コンピュータ上（VGA/30fps）または携帯送受信機（携帯電話）上（QCIF/15fps）でデコードし、パソコンや携帯送受信機（携帯電話）に既にインストールされている一般的ビデオプレーヤーソフトを使って再生できるようにするためである。
【０１１２】
＜ビデオメッセージデモに使用された機器＞
２．１ 携帯送受信機（携帯電話）
【０１１３】
例１に記述される実験の説明。以下の二種類の市販されているGSM/GPRSマルチメディア携帯送受信機（携帯電話）を使用する。類似するその他多くのマルチメディア携帯送受信機（携帯電話）でも代替可能である。
【０１１４】
２．１．１ T-Mobile MDA-II PDA-Phone（HTC社製）
・ローカルGSM/GPRSネットワークで使用可能な状態にある
・インターネット上のデータにアクセスできる状態にある
・MDA-II Phoneクレードル（携帯電話機とパソコンを接続するUSB2.0ケーブル付属）
・OS：Windows Mobile 2003 Pocket PC with Phone Edition
【０１１５】
２．１．２ O2 Xphone Smartphone（HTC社製）
・ローカルGSM/GPRSネットワークで使用可能な状態にある
・インターネット上のデータにアクセスできる状態にある
・携帯送受信機（携帯電話）とパソコンを接続するUSB2.0ケーブル
・OS：Windows Mobile 2003 Smartphone Edition
【０１１６】
２．２． コンピュータ
【０１１７】
２．２．１ パーソナルコンピュータ（ラップトップ型あるいはデスクトップ型）
【０１１８】
例１に記述される実験の説明。ラップトップ型コンピュータを使用し、以下の設定を行う。
・モデル：ソニー社製 Vaio PCG-K33P
・プロセッサ／メモリ：Pentium 4 3.06GHz、512MB RAM
・グラフィックス：ATI社製 Radeon IGP 345M（64MB RAM）
・ストレージ：60GB
・接続ポート：IEEE1394ポート×1、USB2.0ポート×2
・OS：Windows XP
・プリインストールされているビデオアプリケーション：Windows Movie Maker
【０１１９】
２．２．２ リモートサーバー
【０１２０】
例１に記述される実験の説明。UNIX規格のリモートサーバーを使用し、以下のMMS機能を実演する。
【０１２１】
MDA-II携帯送受信機（携帯電話）によるダウンロード用DTVコーデックの保存
・Xphone機によるダウンロード用DTVプレイヤーアプリケーションを保存する
・MDA-II機から圧縮されたビデオメッセージを受信し、保存もしくは転送する。
・SMSメッセージを送信し、ビデオメッセージがダウンロード可能であることをXphone機に知らせる。
・Xphone機のブラウザを介したアクセスにより、DTVプレイヤーアプリケーションおよびQCIF/15fps動画メッセージの双方をダウンロードすることが可能になる。
【０１２２】
２．３ ビデオ撮影（ビデオキャプチャ）
【０１２３】
例１に記述される実験の説明。次の市販カムコーダ（ビデオカメラ）を使用して、外部素材を高画質動画シーケンスとし、携帯送受信機（携帯電話）で実行される本発明のDTVコーデックにより圧縮する。
・キャノン社製 ZR65DV Camcorder（カムコーダ（ビデオカメラ）とPVとの接続にはIEEE1394ケーブルを使用）
【０１２４】
ほとんどの市販カメラ付携帯電話機で現在使用されている低機能な画像モジュールではなく、外部カムコーダ（ビデオカメラ）を使用することで、本発明のDTVコーデックとモバイルビデオ通信能力の有利性をより効果的に実例説明することが可能となる。
【０１２５】
カムコーダ（ビデオカメラ）で撮影され、圧縮されたデジタルビデオ動画ファイルはまずパソコン上でUYVY動画フォーマットに伸展変換される。その後MDA-II携帯送受信機（携帯電話）に転送され、本発明のDTVコーデックによってエンコード／圧縮される。UYVY形式は典型的なビデオフォーマットであり、マルチメディア携帯送受信機（携帯電話）におけるビデオコーデックに装填されることが予想される。
【０１２６】
＜実験のための機器設定＞
３．１ パソコンの設定
【０１２７】
３．１．１ 本発明を利用したドロップレットデモパッケージのダウンロード
・URL「http://droplet-tech.com/demo_partner_access.html」をパソコンのウェブブラウザで開く。
・リンク「Demo Package -- January 2005」（WinZip圧縮ファイル）を選択する。
・このリンクをクリックし、パソコンにデモパッケージファイルのダウンロードを開始する。
・選択したフォルダの中にZipファイルを置く。
・Zipファイルを解凍すると、以下のファイル／フォルダが展開される。
○デモパッケージ「read me」文書ファイル（Demo_package_readme.html）
○以下のフォルダ
・MDA_DTV：MDA-IIクライアントUlアプリケーションソフト
・Xphone_DTV：XphoneUlクライアントアプリケーションソフト
・PC_player：パソコン上でDTVファイルを実行するファイル
・Virtual_Dub1.6.3：異なるビデオフォーマットを相互変換するPC用アプリケーションソフト
・MMS_server：サーバーコンピュータのためのサンプルモニタリングスクリプトプログラム
・Canon_driver：ビデオカメラのドライバソフト
・PHMRegEditor：レジストリエディタ（MDA-IIとXphoneのインストール用）
・Ewesoft：Xphone 用Java仮装マシーン
【０１２８】
３．１．２ J9 JVM（Java仮想マシン）インストレーション・パッケージをダウンロードする。
・URL「http://droplet−tech.com/ftp_accss.html」をパソコンのウェブブラウザで開く。・
・“J9−JVM”（WinZip アーカイブ）リンクを選択する
・J9 JVMパッケージをＰＣにダウンロード開始するためにこのリンクをクリックする
・ジップ・ファイル“weme57prod_pp_1.zip”を選択したフォルダに入れる。
【０１２９】
３．１．３ DirectX 9.0 SDK (DTVのPCプレイヤで使用）をダウンロードしてインストールする。
・無料のSDKがマイクロソフトのウェーブサイトからダウンロードできる。
・http://msdn.microsoft.com/library/default.asp?url=/downloads/list/direct.asp
・このダウンロードは大きいので（〜230MB）注意を要する.
・DirectX Utilities＞GraphEdit機能を作動させて有効に設定されたかを確認する。
【０１３０】
３．１．４ 本発明にかかるDroplet DTV PCプレーヤをパソコン（PC）上にインストールする。
・ソフトウェア・パッケージはPC_player のディレクトリの中のデモ・パッケージで見つけることができる。ファイルはPC_player.zipと呼ばれる。
・テストPCの" C: "ドライブに " C: ＼DTV_PCplayer_Demo＼ "としてパッケージを開く（解凍する）。 もし、実際のパスが異なる場合は、RegisterFilter.batとUnRegisterFilter.batを編集する。
・フォルダを開き、バッチ・ファイル" RegisterFilter. bat"をダブルクリックしてDirectShowフィルタを登録する。
【０１３１】
３．１．５ PCにVirtual Dubをダウンロードしインストールする。
デモの現在のバージョンでは、Virtual Dubはカムコーダ（ビデオカメラ）で撮影されたように、圧縮したDVビデオ・ファイルに変換され、 PCの中の復元（減圧）したUYVYビデオ・フォーマットに入れられていた。復元されたビデオファイルはその後、MDA-II携帯電話へ本発明のDTV コーデック（codec）による符号づけ/圧縮のために入力される。UYVYはマルチメディア携帯電話のビデオコーデック（codec）へ入力される典型的なビデオフォーマットである。
・ソフトウェア・パッケージは、Virtual_Dubディレクトリのデモ・パッケージの中で見つかる。
・一方、ソフトウェア・パッケージも次のURLで見つけることができる：
http://jaist.dl.sourceforge.net/sourceforge/virtualdub/VirtualDub-1.6.3.zip
・Virtual_Dubでは、ディレクトリがVirtualDub.exeと呼ばれるファイルである。これは選択されており、アプリケーションは作動すると確認されている。
【０１３２】
３．１．６ PCにCanon ZR65カムコーダ（camcorder）・ドライバをインストール
する
・Canonドライバ・パッケージは、Canon_driverディレクトリのデモ・パッケージの中で見つかる。
・一方、ドライバもhttp://www.canon.comで見つけることができる。
・Canon_driverディレクトリは開かれ、またサブフォルダ"ZR65WI503EN"と、サブフォルダ " 英語（English）" が選択され、さらにその後、実行可能なプログラム" SETUP.EXE "がCanonカムコーダ（camcorder）・ドライバをインストールするために作動する。
【０１３３】
３．２ 遠隔MMSサーバの構成
デモの中で、遠隔MMSサーバはFTPサーバ〔携帯電話（携帯送受信機）へのビデオコーデックファイルのダウンロードを可能にし、記録する携帯電話（携帯送受信機）からのビデオファイルのネットワークストレージを可能にする〕、としても、メール・サーバ〔記録する携帯電話（携帯送受信機）からビデオメッセージのemail/SMS通知、およびネットワーキングされたコンピューターおよび他の携帯電話（携帯送受信機）によるダウンロードを可能にすること〕としても機能する。機能的に、サーバは送信中のビデオメッセージを他の携帯電話（携帯送受信機）へSMS通知するためにSMSメッセージを送信することができなければならない。
・次のディレクトリを持つためにFTPサイトを形成する。
○ public_html
・あらかじめ、MDA-II携帯電話（携帯送受信機）による後のダウンロードのために、サーバにDTVコーデック(ファイルDtvMDADemo.exe)をインストールする。このファイルはトップレベルのバイナリモードでFTPサーバに転送される。
・あらかじめXphoneによる次のダウンロードのために、サーバにDTVデコーダ(ファイルDtvXphoneDemo.exe)をインストールする。 このファイルはトップレベルのバイナリモードでFTPサーバに転送される。
・サンプル・モニタリング・スクリプトはMMS_serverディレクトリ(ファイル名: monitor.php)のDropletデモ・パッケージの中にある。
・このモニタリング・スクリプトはUnixベースのサーバ上ではcrontabとされる。このスクリプトは、ftp:/public_htmlディレクトリ中で新しいファイル(.Inkで終わる)の存在を毎分モニターする。
・もしユーザがDropletデモ・サーバ以外にサーバ上で上記のサンプル・モニタリング・スクリプトを使用することに決めれば、それがローカルのサーバ/ネットワーク環境としてカスタマイズされる。
【０１３４】
３．３ MDA-IIの構成
クレイドル/USBケーブルで(前記セクション３．１のようにあらかじめ構成された)PCにMDA-IIを接続する。
【０１３５】
３．３．１ 安定GPRS接続のためのレジストリ・エントリの修正
安定GPRS接続を確保するために、デフォルトセッティングの60秒より大きくなるようにタイムアウト期間を増加する。携帯電話（携帯送受信機）メーカ（HTC）は推奨できる変更レジストリを提供する。もし、装置上にレジストリ・エディタがインストールされていない場合は、最初にDropletのデモ・パッケージに含まれている" PHMRegEditor "のディレクトリによりレジストリ・エディタをインストールする。
・PCの仮ディレクトリにファイルPHMRegEdit.msiをインストールする。
・PCの同じディレクトリにCABファイルであるregedit.Mrln_ARM.CABをインストールする
・ダブルクリックしてPHMRegEdit.msiを作動させ、その後の指示に従う。
・MDA-IIと同期させる
・MDA-II上のWindowsズ・ディレクトリにregedit.Mrln_ARM.CABファイルをコピーする。
・MDA-IIの中のファイルをダブルクリックすることにより、CABファイルが適切にインストールされるであろう。
・PHMRegEdit.msiを作動させて、指示に従う。
生じるプログラムPHMEditorは、ディレクトリ＼プログラム・ファイル＼PHMツールのMDA-IIにインストールされる。
・上記のディレクトリのプログラムregedit(レジストリ・エディタ)をスタートする
○ Select
HKEY_LOCAL_MACHlNE＼SOFTWARE＼Microsoft＼ConnMgr＼Planner＼Settings
○ CacheTimeの設定を300（5分をタイムアウト期間とする)に変更する。
○ SuspendResumeの設定を〜GPRS(タイムアウトを考慮に入れない)に変更する
・レジストリ・エディタから出る。
・変更した設定が効果を現わすようにソフトリセットを作動させる。
【０１３６】
３．３．２ IBM J9 JVMをインストールする。
・前述の３．３．１でPC上にダウンロードした" weme57prod_pp_wm_1.zip "ファイルを開く（解凍する）。５つのファイルがある。
○ inst_pp_wm.html
○ readme_pp_wm.html
○ weme-wm2003-arm-ppro10-5.7.1-P-20040723-1833.bin
○ weme-wm2003-arm-ppro10-5.7.1-P-20040723-1833.exe
○ weme57_ppc_pp_1.pdf
・inst_pp_wm.html.ファイルを開く。インストレーションの指令を呼んでその指示に従う。
【０１３７】
３．３．３ MDA-II携帯電話（携帯送受信機）のUlアプリケーションをインストールする。
３．１．１で既に記述したようにPCの上で既に開かれた（解凍された）ファイルの中でこのアプリケーションは見つけられる。
・ディレクトリMDA_DTVの中のデモ・パッケージには"mms_client"と呼ばれるサブフォルダが含まれている。これらは３つのファイルからなる。
デモ・パッケージには
○ " application.properties "
○ "Droplet.jar "
○ "Droplet.lnk "
・ファイル" application.properties"と" Droplet.jar "をPCからMDAディレクリ＼ProgramFiles＼J9＼PPRO10＼examplesへコピィする。
・ファイル" Droplet.lnk "をMDAディレクトリ＼windous＼StartMenuにコピーする。
・MDA-IIが正確に形成されたことを確認するために、スタート・メニュをクリックする。Dropletと呼ばれるアイコンが利用可能となる。
・機能性を確認するために、Dropletアイコンを選択すると新しいウィンドウが出てくる。それは３つのボタンからなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
注：MDA-II携帯電話（携帯送受信機）Ulアプリケーションのための情報コードが例えばディレクトリMDA_DTV＼mms_client_srcの下で利用可能である。
これによりMDA-IIはデモとして形成される。
【０１３８】
３．３．４ Pictpocket映画・ビデオ・プレーヤ(オプション)をインストールする。
MDA-IIの上のデフォルト・ビデオ・プレーヤーがデコードされたDropletビデオ・ファイルで見ることができるので、このステップはオプションである。サードパーティー（部外第三者）のビデオ・プレーヤをインストールすることにより、本発明にかかるデコードされたビデオファイルが多機能モバイル装置ビデオ・プレーヤーと互換性あることが実証される。
・MDA-II携帯電話（携帯送受信機）上で、Digisoftからの"Pictpocket映画"アプリケーションがインストールされる。
・Pictpocket映画の14日間お試しバージョンはベンダ（販売主側）のウェーブサイト: www.digisoftdirect.comからダウンロードすることができる。
【０１３９】
３．４ Xphoneを形成する。
USBケーブルでPCにXphoneを接続する。
【０１４０】
３．４．１ 安定GPRS接続へレジストリ・エントリを修正する
安定したGPRS接続を保証するために、タイムアウト期間を60秒のデフォルト設定より大きくするように増加する必要がある。携帯電話（携帯送受信機）メーカ(HTC)は推奨できるレジストリの変更を提示した。もし、装置にレジストリ・エディタがインストールされていない場合は、まず" PHMRegEditor " ディレクトリにあるDropletデモ・パッケージに含まれているレジストリ・エディタをインストールする。
・PC上のTemp（仮の）ディレクトリにファイルPHMRegEdit.msiをインストールする。
・PC上の同じディレクトリ中にCABファイルregedit.Mrln_ARM.CABをインストールする。
・ダブルクリックすることによりPHMRegEdit.msiを作動さて、指示に従う。
・XphoneをPCと同期させる。
・Xphone上のWindows・ディレクトリにファイルregedit.Mrln_ARM.CABをコピーする。
・Xphoneの中のそのファイルをダブルクリックしてCABファイルを適切にインストールする。
・PHMRegEdit.msiを作動させて、指示に従う。
生じるプログラムPHMEditorは、ディレクトリ＼プログラム・ファイル＼PHMツールのXphoneにインストールされる。
・上記のディレクトリからのプログラムregedit(レジストリ・エディタ)をスタートさせる。
○ Select
HKEY_LOCAL_MACHlNE＼SOFTWARE＼Microsoft＼ConnMgr＼Planner＼Settings
○ CacheTimeの設定を300（5分をタイムアウト期間とする)に変更する。
○ SuspendResumeの設定を〜GPRS(タイムアウトを考慮に入れない)に変更する
・レジストリ・エディタから出る。
・変更した設定が効果を現わすようにソフト・リセットを作動させる。
【０１４１】
３．４．２ Ewesoft JVMをインストールする。
・ディレクトリEwesoftの中のデモ・パッケージにはEwe143-CAB-SmartPhone.zipと呼ばれるファイルがある。PC上でこのファイルを解凍する。Ewe143-SmartPhone2003.arm.CAB-と呼ばれるファイルを使用する。
・Storage＼windows＼Start Menu＼Accessoriesと呼ばれるXphoneディレクトリにEwe-SmartPhone2003.arm.CABファイルをコピーする。
・Accessoriesを開始させる。CABファイルはメニュー項目として表示される
CABファイルを選択し、次にVMをインストールする。
・インストールにより、スタート・メニューに現われる新しいEweフォルダが作成される。
・そのフォルダの中でEwe VM自体と、正確なインストールを確認する"Solitaire"デモ・アプリケーションを見つける。
【０１４２】
３．４．３ Xphone携帯電話（携帯送受信機）Ulアプリケーションのインストール
・ディレクトリXphone_DTVの中のデモ・パッケージには"mms_client"と呼ばれるサブフォルダがある。これらは３つのファイルからなる。
○ " application.properties "
○ "Droplet.jar "
○ "Droplet.lnk "
・ファイル" application.properties"と" Droplet.jar "をPCからXphoneディレクリ/Storage/windous/StartMenu/Ewe/へコピーする。
・ファイル" Droplet.lnk "をXphoneディレクトリ: /Storage/windous/StartMenu/にコピーする。
・Xphoneが正確に形成されたことを確認するために、スタート・メニューをクリックする。Dropletと呼ばれるアイコンが利用可能となる。
・機能性を確認するために、Dropletアイコンを選択すると新しいウィンドウが出てくる。それは３つのボタンからなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
これによりMDA-IIはデモとして形成される。
【０１４３】
＜デモの作動（実行）＞
４．１ MDA-II上にビデオコーデックをダウンロードしてインストールする
・MDAから、スタート・メニューをクリックするとDropletアイコンがリストに現われる。
・Dropletアイコンを選択すると新しいウィンドウが出てくる。それは3つボタンの選択からなる。
○ コーデックのDownload/install
○ ビデオ撮影
○ ビデオメッセージの送信
・Download/installコーデックボタンをクリックする。
・次のメッセージが現れる。
○ FTPホスト: xx.xx.xx.xxxに接続
(これはサーバのIPアドレスとなる)
○ 接続
○ サーバにログイン
○ ログイン完了
○ コーデックファイルのダウンロードの開始
○ ダウンロードの完了
○ ビデオコーデックのインストール成功。接続終了
・コーデックのダウンロードが成功したことを確認するために、MDA上のマイドキュメント・ディレクトリに進む。DtvMDADemo.exeと呼ばれるファイルが、ダウンロードされた日付およびタイムスタンプ付きで提示される。
【０１４４】
４．２ 携帯電話（携帯送受信機）によるビデオメッセージの記録
このバージョンのデモでは、MDA-II携帯電話（携帯送受信機）は、外部のビデオカメラ（ビデオカムコーダー）からの圧縮されていない高品質の生中継ビデオが入力され符号化／圧縮（エンコード／コンプレス）されていた。一方、MDA-II はVGA撮影できるカメラを装備しているが、それは、単に静止画像をその解像度で撮影するにすぎない。MDA-IIによるビデオ撮影は、QCIF(装置上の3GPPフォーマットで自動的に圧縮される10fpsビデオ)に制限されている。
【０１４５】
４．２．１ カムコーダ（ビデオカメラ）のPCへの接続
・Firewire(1394)ケーブルを使用して、PCにキャノン・ビデオカメラ（カムコーダ）を接続する。ビデオカメラ（カムコーダ）には４ピンのコネクター端子がある。
・一旦Firewireケーブルが接続され、ビデオカメラ（カムコーダ）が"カメラ"モードに調整されれば、PCのOS(このデモ・バージョンではWindowsXP Professional)は撮影のいくつかのオプションを供する。
・"Windows Movie Maker"を選択すれば、映画メーカー・アプリケーションが導入される。
【０１４６】
４．２．２ PC上にカムコーダ（ビデオカメラ）からビデオシーケンスを取得する。
・映画メーカーの中から"ビデオ装置からの取得"を選択し、PC上にそれを格納するための取得ファイルと場所の名前を選択する。
・次のスクリーンではビデオセッティングが求められ；"デジタル装置フォーマット(DV- AVI)"を選択する。それは、DVフォーマットでのビデオを撮影であり、高品質(ほとんどlossless)なビデオ撮影フォーマットである。
・次のスクリーンは、"撮影開始"と"撮影終了"のインターフェースとともに撮影されたビデオのプレビュウ・ウインドウを表示する。多くの無線携帯電話（携帯送受信機）では大容量の搭載記憶素子を装備してないので、2-3秒のフルモーションビデオ(60-90フレーム）がより速いコンピュータ化の録画として示唆されていた。
・一旦ビデオシーケンスが録画されれば.AVIフォーマットにある、Windows Movie Makerプログラムから出ることができる。
・このドキュメントについては、レコーダ・ファイルの名前は" testDV.avi "と仮定されている。(ファイルは.AVIフォーマットにあり、すべての個々のフレームの付いたインターリーブされたオーディオ・ビデオファイルは次々に整えられる。)。
【０１４７】
４．２．３ PC上の圧縮されてないDVビデオ・シーケンス
・前のステップで撮影されたビデオは、インテグレーテッド（統合された）オーディオとしてDVフォーマット(720×480ピクセル、約28Mbpsで30 fps)に圧縮される。フルモーション撮影をシミュレートするために、ビデオは通常の圧縮されてないUYVYフォーマットで、VGAサイズ(640×480ピクセル)にスケールを落として、オーディオ情報は分離する。
・このデモについては、MDAにエンコードするために２つのソース・ファイルを作成する必要がある： １つはVGA(640×480)@30fpsであり、他はQClF(160×144)@15fpsである。
・VirtualDub1.6.3ディレクトリから"VirtualDub.exe"を実行可能に作動する。
a. "File"の中で"Open video file"を使用し、" testDV.avi "をオプションで使用する
b. "Audio"の中で"No audio"ファイルをオプションで選択する
c. "Video"の中で"Filters"をオプションで選択する。"Add（追加）"を選び、メニューをスクロールダウンして"resize（サイズ変更）"フィルタを設定する。"New width（新しい幅）"として640、"New height（新しい高さ）"として480をセットする。""Filter Mode（フィルタ・モード）"として"Precise Bicubic (A=0.75)"をセットする。
d. "Video"の中で"Color depth（色の深さ）" を選択する。左のコラムの出力フォーマットに" 4:2:2 YCbCr(UYVY) " フォーマットをセットする。
e. "Video"の中で"Compression（圧縮）" オプションが"Uncompressed（圧縮されてない）RGB/YC bCr"にセットされていることを確認する。
f. もし非常に長いビデオシーケンスが撮影された場合は、"Video"の中の"Select range"オプションを選択することにより短くすることができる。典型的に合理的に操作できるビデオの大規模は60-90のフレーム(2-3秒のビデオ)である。スタートは撮影されるビデオによって、始めから（"Start offset" of 0）でも、あるいはどこかのシーケンスの途中からでもよい。例えば、2秒(60フレーム)の圧縮されていないUYVYビデオVGA(640x480)シーケンスは、コンピューター上で36MBのデータである。
g. 圧縮されていないファイルの保存のために"File" と"Save as AVI..."を選択する。"testVGA_UYVY.avi "ファイルを呼ぶ。エンコードされる生の(圧縮されていない)UYVY VGA入力ファイルであり、MDA-II携帯電話（携帯送受信機）上で符号化され／圧縮される。
・QCIF（GPRS接続によって別の携帯電話（携帯送受信機）にビデオ・クリップを送るために推奨される）用のファイルの作成:
○ 上記ステップcで、１６０を入力する"New width（新しい幅）"として１６０を入力する。"New height（新しい高さ）"として１４４を入力する。
○ 上記ステップgで、ファイルを"testVGA_UYVY.avi "と命名する。
【０１４８】
４．２．４ 圧縮されていないビデオシーケンスのMDA-II携帯電話（携帯送受信機）への転送
・圧縮されていないビデオファイル"testVGA_UYVY.avi"と"testQcif_UYVY.avi"をPCからMDAへ転送する。
・圧縮するために、MDA-IIのマイドキュメント・ディレクトリにこれらのファイルをコピーする。
・中間ストレージのために、上記の大きなソース・ファイル(圧縮されていないビデオ入力)は、装置の"Storage Card"に入れられ、次に、圧縮のためにマイドキュメント・ディレクトリにコピーされる。
・PCからMDAを分離する。
この時点で、圧縮されていないビデオシーケンスが携帯電話（携帯送受信機）の中にあり、従前にダウンロードされ携帯電話（携帯送受信機）にインストールされているエンコーダ・ソフトウェアである本発明にかかる"Droplet"で圧縮される準備ができている状態である。
【０１４９】
４．２．５ MDA-II携帯電話（携帯送受信機）の中での在来のビデオシーケンスの圧縮
ビデオコーデックおよび圧縮されていないビデオシーケンスが、MDA-II 携帯電話（携帯送受信機）に旨くダウンロードされ、携帯電話（携帯送受信機）には符号化（encode）／圧縮を実行する準備がととのった。
・MDA上で、MyDocumentsディレクトリに行く。
・" DtvMDADemo " アプリケーションを見つけて選択する。
・UIウィンドウが出て、順次ユーザは情報を入力する:
○ ソース・ファイル：ファイルの名前にはUYVYフォーマットに圧縮されていないビデオを含んでいる(これは前のステップで生成されたファイルである)。
○ デスティネーション（指定）ファイル：このファイルには圧縮されたビデオシーケンスが格納される。(圧縮されたファイルは .dtvで終わる拡張子を持つ) このデモでは、ファイル名はbitstream.dtvとなる。
○ 水平および垂直のフレームサイズ
○ VGAビデオをエンコード（符号化）するためのパラメーターはそれぞれ640と480
○ QCIFビデオをエンコード（符号化）するためのパラメーターはそれぞれ160と144
○ 入力ファイルのタイプ：YUV 4:2:2、デフォルト（標準設定）
○ 圧縮レート：12レベル、デフォルト（標準設定）
○ 圧縮されるフレームの範囲：典型的には"全て"をセットする。(注：もしユーザがこれを変更することを選択しても、DTVが1グループの画像として2つのフレームを処理するので、指定するフレームの総数は偶数となる。)
○ "エンコード（符号化）する"か"デコード（復元）する"あるいは両方を選択する。
○ スタートを選択する。
・首尾よく完了したら、上記のデスティネーション（指定）ファイル領域で特定の圧縮されたbitstream.dtvファイルはMDA-II上の"マイドキュメント"のディレクトリの中に作成される。
・ファイル名が変更された場合、.dtvファイル拡張子を維持することが重要である。
・注意：上記の符号化は２度実行される。一度はQCI F/15fpsのためで、もう一度はVGA/30fpsのためである。
・復元されたQCIFファイルも、GPRSネットワークによる他の携帯電話（携帯送受信機）へのMMS送信されるために、MDA-IIの"マイドキュメント＼DTV Output" に保存される。
【０１５０】
４．３ PC上でのVGA/30 fpsビデオ・メッセージの転送/再生
PC上でエンコードされたVGAファイルを実行には、MDA-IIからPCにファイルを転送する必要がある。現在のGPRSデータ転送速度(~20-40kb/s)ではモバイルネットワークにより、圧縮したVGAビデオを1秒送るのにおよそ16秒かかる。高速3GまたはWiFiネットワークによれば、取り敢えずフルVGA/30 fpsビデオ・ファイルのより効率的な転送が可能である。このデモでは、MDA-II携帯電話（携帯送受信機）とPCとの間のUSB接続がファイル・トランスファーを促進するために利用される。
・cradle/USBによってPCにMDA-IIを接続する。(これが現在のデジタル・カメラやカムコーダ（ビデオカメラ）がデジタル写真やビデオを転送するためにホームPCに接続される標準の方法であることに注意する。)
・MDA-IIからPCに、エンコードされたか又は圧縮されたVGAファイル
(＼MyDocument＼bitstream.dtv)をコピーする。ファイルは次のディレクトリにコピーされる："C: ＼DTV_PCplayer_Demo＼"
・MDA-II装置はUSB1ポートに装備されているので、USB2へのVGA/30 fpsファイルのより速い転送がPCで可能であり、MDA-IIのリムーバブルメモリーカードに最初にそれらをコピーし、次に、カードを離脱し、PCのUSB2ポートにそれを直接接続して、転送のためのUSB2カード読み取り機を使用することにより実現することができる。
・一旦ファイル・トランスファーが完了したら、PCのディレクトリ"C: ＼DTV_PCplayer_Demo＼"に行き、ファイル"dtvplayer.grf"または" dtvplayer_Win2K.gif"(OS付属)をダブルクリックし、次に、VGA/30 fpsビデオを見るために" プレー " ボタン（またはメニュー項目の" プレー "を選択）をクリックする。
・クリップを止めるためには、単に、アプリケーションを出ることである(GraphEdit)。
【０１５１】
４．４ GPRSによるMMSメッセージとしてのQCIF/15 fpsビデオの送信
このセクションは、GPRSを介してMDA-II携帯電話（携帯送受信機）からMMSサーバへ圧縮したQCIF/15fpsビデオを送信する能力を示す。SMS通知が、ビデオのMMSがダウンロードと再生の準備ができること表示して、目標となった携帯電話（携帯送受信機）(この場合Xphone)に送られる。一方、目標とされた受信装置がネットワーキングされたコンピューターである場合、電子email通知が送られる。
【０１５２】
４．４．１ GPRSによるMMSサーバへのQCIF/15 fpsビデオの送信
・MDA-IIのスタート・メニューをクリックすると、Dropletアイコンはメニュ・リストが現われる。
・Dropletアイコンを選択すると、新しいウィンドウが現れる。それは３つの選択ボタンからなる。
○ コーデックのダウンロード/インストール
○ ビデオ撮影
○ ビデオメッセージの送信
・"ビデオメッセージ送信"ボタンをクリックする。
・ファイルを選択する新しいウィンドウが開く。
○ 送りたいファイル(この場合圧縮したQCIF/15 fpsビデオ・ファイル)を選択
○ 新しいウィンドウが、目標となる電話番号/emailアドレスに入るために開く。
○ emailアドレスが入力されると(@シンボルの存在によって確認され)、選択されたファイルは、email通知とともに送信される。
○ もし、" @ "の記号のない文字列が入力された場合、file/SMS通知がmailto："string" @tmomail.netに送られ、対応する、この場合、"string"として電話番号の入ったT-モバイル加入者に送られる。
・XphoneにMMSメッセージとして圧縮したビデオを送るには、携帯電話（携帯送受信機）の電話番号を入力する。
・ユーザは、GPRS接続を確立するように促される。これは、例えばインターネットエクスプローラに到達してどこかの既知のURLに行くことで完了する。
・一旦GPRS接続が旨く確立されたら、" OK "をクリックする。
・次のステータス・メッセージが現われるべきところで、新しいウィンドウは開く。
○ FTPホスト: xx.xx.xx.xxxに接続
(これはサーバのIPアドレスとなる)
○ 接続
○ サーバにログイン
○ ログイン完了
○ ディレクトリの:public_htmlへの変更
○ 変更完了
○ ビデオファイル<selected video file name>.dtvのアップロード開始
○ アップロードの完了
○ リンクファイル<selected video file name>. lnkのアップロード開始
○ アップロードの完了
○ ビデオファイルの送信の成功。接続終了。
注：２つの新しいファイル（<selected video file name>.dtvと<selected video file name>. lnk）がftpサーバ上のpublic_htmlディレクトリ中に現われる。
【０１５３】
４．４．２ MMSサーバからSMS通知が送られる。
・サーバ上で走るスクリプトがftpロケーションpublic_htmlを呼び（polls）、新しいファイルの存在を確認する。
・新しいファイルが存在する時、サーバ・スクリプトは<new file>.lnkファイルを解析し、送られるビデオファイルの名前と目的（指示先）携帯電話（携帯送受信機）番号またはメールアドレスを抽出する。
・スクリプトはemailまたはモバイルSMSのいずれかによって目標とされた指示先へSMS通知メッセージを送る。
【０１５４】
４．４．３ 受信携帯電話（携帯送受信機）のビデオメッセージとDTVデコーダのダウンロード
このセクションは、XphoneでSMS通知を受け取り、MMSサーバに接続し、DTVデコーダと一緒にQCIF/15fpsビデオ・ファイルをダウンロードするという能力を実証する。ビデオファイルとデコーダを受け取ってから、Xphone上でファイルはデコードされ実演される。
・XphoneはSMSメッセージを受け取る。
・SMSメッセージを開く。内部はビデオファイルをダウンロードするロケーションとなる。
・DTVビデオ・ファイルをダウンロードする。
○ インターネットエクスプローラを開く。
○ ビデオファイルの存在する位置のURLを打ち込む（タイプイン）。
○ ビデオファイルがXphoneにダウンロードされる。
○ さらに、Xphoneビデオ・デコーダをダウンロードする必要がある(もしそれがまだXphoneの上にない場合)。一度ダウンロードされたら、Xphoneデコーダ・ファイル(DtvXphoneDemo.exe)はXphoneのマイドキュメント・ディレクトリの中に置かれる。
・DtvXphoneDemo.exeを作動させる。
・Ulウィンドウが、ユーザの情報入力を可能にするように現れる(アプリケーションはbitstream.dtv fileの処理を標準設定)。
○ 水平および垂直のフレームサイズ。
○ QCIFビデオをデコードするため、パラメーターはそれぞれ160と144。
○ 圧縮されるフレームの範囲：典型的には"全て"をセットする。(注：もしユーザがこれを変更することを選択しても、DTVが１グループの画像として２つのフレームを処理するので、指定するフレームの総数は偶数となる。)
○ 他の全てのフィールドは無視する。
○ "デコード"を選択する。
○ スタートを選択する。
○ 圧縮されていないAVIファイル(それはモバイル携帯電話（携帯送受信機）上で見つかるほとんどのビデオプレーヤーによって実行することの可能なもの)を形成する。
・Xphoneの上のビデオ・ファイルを実行するには、単に形成されたファイルをクリックすれば、中にあるマイクロソフト・メディア・プレーヤーがビデオを再生するだろう。
【０１５５】
４．４．４ Xphone上での他のFTP接続の使用
本発明にかかるDropletによって可能にされた柔軟性を開示するために、すべてのソフトウェア・ビデオ送信プラットフォームが開示される。QCIF/15fpsビデオ・メッセージをダウンロードする単純なSmartphone FTPアプリケーションの使用、およびXphone携帯電話（携帯送受信機）へDropletデコーダをダウンロードするソフトウェア・ビデオも開示される。
・Xphone上のWindowsズSmartphones装置のためのOrneta FTPアプリケーションが使用される。
・Orneta FTPアプリケーション・インストーラーは次のものからのPCにダウンロードすることができる：
http://www.handango.com/PlatformProductDetail.jsp?productType=2&platformld=11&siteld=1&Sectionld=0&catalog=1&productld=87548
・Xphoneに接続しているPCを使用して、Orneta FTPをインストールする指示に従う。
・次のアドレスから無料で登録コードを獲得する：
http://x.msmobiles.com/free-smartphone-software/default.aspx
・ビデオメッセージをダウンロードし、MMSサーバからのDropletデコーダをダウンロードするXphoneの上のOrneta FTPアプリケーション：
○ GPRS接続の開始
○ スタート・メニューからのOrneta FTPアプリケーションの設定
○ Menu/ Settings/Set Download Folderからchoose Windowsを選択
○ 特定されたMMSサーバ(例えば、セクション4.1のよう)に接続
○ ダウンロード：Dropletビデオ・エンコーダ"DtvXphoneDemo.exe"を選択してダウンロード
○ Menu/Settings/Setの中のダウンロードフォルダから＼Storage＼My Documents＼を選択
○ MMSサーバに再度接続
○ ビデオ・ファイルQCIF/15である"bitstream dtv"をダウンロード
○ Exit
これで、実施例１の詳述を終了する。
【０１５６】
本発明の特徴は構成の一部として、全てがソフトウェアからなるカメラ付きレコーダ（カムコーダ）電話のアプリケーションでは、毎秒30フレーム(fps)のフル（VGA）サイズの画像(640×480)のリアルタイム撮影が可能であり、大多数のマルチメディア携帯電話（携帯送受信機）に使用されている単一基準のRISCプロセッサーが使用されている。対照的に、モバイル携帯電話（携帯送受信機）のバッテリーのパワーは制約があり、現在のMPEGベースのカメラ付きレコーダ（カムコーダ）電話では、4-15 fpsでQCIFあるいはCIFサイズ(1/16thあるいは1/4、VGAのサイズ)にイメージのリアルタイム撮影のサポートは制限されている。しかし、これらの小さく変わりやすいビデオ・クリップさえ複雑で高価な携帯電話（携帯送受信機）のプラットフォームの設計となり、その中でビデオ機能はハードウェアとソフトウェアのコンビネーションとして実装されており、多機能処理装置であるRISCプロセッサー、ASICおよびDSPを共有しなければならない。
【０１５７】
モバイルのオペレーター環境について、本発明の複雑性を回避したビデオ処理および電送技術は、既存のモバイルの携帯電話（携帯送受信機）、およびモバイルマルチメディア通信サービス・コントローラ(MMSC)のインフラストラクチュアを利用しながら、ターンキー配備を可能にする強力な新しい創造性のあるソフトウェア単体実行ビデオ通信プラットフォームへと統合される。上記のモバイル・カムコーダ（ビデオカメラ）・アプリケーションを補充した本発明の実施例の管理プラットフォームでは、圧縮したイメージとビデオを統合するためのモジュールを、テキストや音を一体とした完全なモバイルマルチメディア・メッセージやオン・ザ・フライ・エディティング、サムネイルプレビュウ・マルチメディアメールボックス、オン・ライン・リポジトリ・サービスおよびサブスクリプション管理と伴に提供する。
【０１５８】
＜作動(効率)の比較（PERFORMANCE COMPARISON）＞
最適化したMPEG-2/MPEG-4 コーデックと本発明にかかるビデオコーデックを対比した場合、利用者は消費電力でソフトウェアおよびハードウェアの両方の実装により、後述の表１参照)の通り、30-40Xの減少が提供できた。ハードウェア製品の実装コストは、著しく減少し、必要となるCMOSゲート数も10倍縮小し、約 1,000,000から100,000となり、対応するsilicon real estate需要も同様である。
フルサイズ(VGA)でフルフレームレート(30 fps)のビデオ処理にあって、本発明の改良ビデオコーデックのデザインでは、内部で必要となるメモリの容量を数メガバイトから128キロバイトに減少し、モバイル携帯送受信機（携帯電話）に搭載されているメモリ資源を他に収入を発生する要素やアプリケーション用に解放した。本発明にかかるコーデックは静止画像もビデオも両方を効率的に処理することができるので、MPEGとJPEGの別々に分かれていたコーデックを１つの廉価で低出力のソルーションに取り替えることができる。
【０１５９】
VGAの展開やサポートにおいて、30fpsのカムコーダ（ビデオカメラ）電話において、また関連サービスにおいて十分利用可能であるが、本発明にかかるユニークなモバイルのビデオプラットフォーム技術はさらに次のもののコンビネーションによって、広範囲の他のモバイルのビデオサービスを通じて十分な利点が示されている：計測可能な画像のサイズ：QCIF(176×144)−D1(720×480)、単純化されたビデオ編集(カット、挿入する、テキスト・オーバーレイなど)、音声コーデック備えた単純化された同期、および、低い潜在率の増強されたビデオストリーミングの効率。
【表１】
表１、コーデック実行効率比較：モバイル送受信機（携帯電話）アプリケーション
【０１６０】
本発明はまた、モバイル送受信機（携帯電話）用の特許性のあるソフトウェア・ビデオコーデック／カムコーダ（ビデオカメラ）（codec/camcorder）アプリケーションに関連したプレミアム・ビデオ配信サービスの配備を可能にするMMSインフラストラクチュア製品とからなる。本発明の更なる特徴は、進歩したトランスコーディングアプリケーションが、他の一般に展開する標準ベースまたは所有しているビデオフォーマットとの完全な相互利用可能性をサポートすることからなる。さらに含まれているものは、本発明の圧縮したイメージおよびビデオと音とテキストと一緒にした完全なモバイルのマルチメディア・メッセージと"着信音"（"ring-tone"）ならびに対応するMMSメッセージ管理能力一式とを共に統合するためのモジュールを提供するコンテント管理プラットフォームである。
このコンテント管理プラットフォームは、無線通信者とMMSサービス・プロバイダーの両者によって、ソフトウェアモジュールのセットとして、既存のMMSインフラストラクチュアへの迅速でコスト効率の良いアップグレードとして、または、新しいMMSコントローラ装置用のスタンド・アロンのサーバとして使用することができる。特許性のあるMMSインフラストラクチュア製品は次のものを含むであろう：
製品と記述
＞DTV-VGTビデオ・ゲートウエイTranscoder：
DropletDTVフォーマットと他のMPEG-2やMPEG-4、Motion-JPEG、マイクロソフト・メディアおよびRealVideoのようなビデオフォーマットとの間のビデオのコンテンツの変換をサポートするために既存のMMSビデオ・ゲートウエイをアップグレードするためのソフトウェア・トランスコーダ（Transcoder）アプリケーション。
＞DTV-CMP ソフトウェアコンテンツ管理プラットフォーム：
既存のMMSメッセージ・アプリケーション・サーバをアップグレードするための一式のコンテンツ管理ソフトウェアモジュール:、音およびテキスト、オン・ザ・フライ・エディティング、サムネイルプレビュウ、マルチメディアメールボックス、オン・ライン・レポジトリ・サービスおよびサブスクリプション管理と一緒に本発明の圧縮したイメージおよびビデオを統合するMMSメッセージと"着信音（ring-tone）"の生成。
＞DTV-CMSコンテンツ管理サーバ：
新しいMMSC配備用のサーバベースの統合ソフトウェアコンテンツ管理プラットフォーム。
【０１６１】
本発明は、さらにコンテンツ管理サービスプラットフォームのソフトウェアのモジュールあるいはスタンド・アロン・サーバであって次のものを含むであるものを含む：
＞モバイル・マルチメディアコンポーザ： 本発明の改良されたウェーブレットで圧縮したイメージおよびビデオを音およびテキストとともに１つのメッセージに統合する。
＞プレビュープレーヤ： 本発明のウェーブレットで圧縮したイメージとビデオと統合したMMSメッセージで“サムネイル”プレビューとを提供する。
＞モバイル・マルチメディア・エディタ: 本発明のウェーブレットで圧縮したイメージとビデオと、ツールとフィルタで統合したMMSメッセージでオン・ザ・フライ・エディティングを可能にした。
＞マルチメディア着信音（ring-tone）クリエーター： ウェーブレットで圧縮したイメージおよびビデオと多音の着信音（ring-tone）と他の音を組み合わせることによってユーザが個人のマルチメディア"着信音（ring-tone）"を作成することを可能にする。
＞モバイル・マルチメディア・アルバムまたは"Mblog"： 本発明のウェーブレットで圧縮したイメージ、ビデオおよび統合されたMMSメッセージのためのリポジトリ（情報データベース）。
＞モバイル・マルチメディア・サブスクリプション管理： 本発明のウェーブレットを圧縮したイメージとビデオと統合したMMSメッセージをコピーして/転送する。：追加の記憶装置の購入：DVDハード・コピーの購入。
＞モバイル・マルチメディア・メールボックス： 本発明で統合されたMMSのためのSMSで管理されたインの箱とアウトの箱。
＞モバイル・マルチメディア・アドレス帳： モバイル・マルチメディアの接触の管理。
【０１６２】
本発明の実施例を提供することに注目すべきである:
＞柔軟で迅速で、コスト効率の良いOTA（無線）/OTN（ネットを介する）は、インストールされたMMSインフラストラクチュアからの増加ROIをアップグレードする。
＞進化したトランスコーディングは他の一般に展開した標準ベースものと所有しているビデオフォーマットとの完全な相互操作をサポートする。
＞既存のMMSインフラストラクチュアをアップグレードするためのソフトウェアのモジュールの一式として、あるいは新しいMMS装置用のスタンドアローン（独立型）のサーバとして利用可能なコンテンツ管理プラットフォーム
【０１６３】
＜JSR-135：モバイル・メディアAPIスペシフィケーション(MOBILE MEDIA API SPECIFICATION) ＞
本発明のDTV-JVC Javaビデオ・コーデックは、下記を含むJavaコミュニティー・プロセスJSR-135に定義されたプレーヤー機能性をすべてサポートする、復元されたビデオイメージを生成する：
Int getDisplayHeight( )の取得
ビデオに流れる電流の実際の高さを返す。
Int getDisplayWidth( )の取得
ビデオに流れる電流の実際の幅を返す。
Int getDisplayX( )の取得
ビデオが放映された時のGUIオブジェクトに関するビデオのXコーディネートを返す。
Int getDisplayY( )
ビデオが放映された時は、GUIオブジェクトに関するビデオのYコーディネートを返す。
byte〔〕 getSnapshot(java.lang.String imageType)
表示されたコンテンツのスナップ写真を得る。
Int getSourceHeigh( )
ソースビデオの高さを返す。
Int getSourceWidth( )
ソースビデオの幅を返す。
java.lang.Object initDisplayMode(int mode, java.lang.Object arg)
ビデオの放映状態によりモードを初期化する。
Void setDisplayFullScreen(ブールのfullScreenMode)
ビデオ・クリップがfullscreenになるように関連領域のサイズをセットする。
Void setDisplayLocation(int x，int y)
ビデオが放映される場合、キャンバスの位置をビデオのロケーションとしてセットする。
Void setDisplaySize(int幅，int高さ)
ビデオイメージのサイズを変更する。
Void setVisible(ブール、可視)
ビデオを放映するか、切断するか。
【０１６４】
＜JSR-234: 進化したマルチメディア補充(ADVANCED MULTIMEDIA SUPPLEMENTS) ＞
本発明のDTV-JVC Javaビデオコーデックは、下記を含むJavaコミュニティー・プロセスJSR-234に定義されたプレーヤーイフェクトコントロールのすべてをサポートする復元されたビデオイメージを生成する、:
ImageFilterControl
ImageFilterControlはモノクロ（単彩色）とそうでないものの様々なイメージ・フィルタをセットするために使用することができるイメージ効果である。
IimageTonalityControl
ImageTonalityControlは明るさ、コントラストおよびガンマ(明度)のような様々なイメージ・セッティングをセットするために使用することができる効果である。
ImageTransforrnControl
ImageTransformControlはイメージをトリミング、ズーム、鏡映し、反転、引伸し、回転させるために使用される。
OverlayControl
OverlayControlは、ビデオの先頭画面や静止画像のオーバーレイ・イメージのセッティングをコントロールする、
WhiteBalanceControl
WhiteBalanceControlは、白のバランスの変更によるイメージ/ビデオの影響。
【０１６５】
本発明は、さらにモバイルのビデオのブログサービスを確立し、提供し、操作するための製品と方法およびプロセスとからなる。このサービスは、全てのユーザに、撮影（shoot）、編集、保存、シェア、および、個人ビデオの"公表"、更にオンライン映画の可能なビデオ電話を提供する。
【０１６６】
ユーザに関しては、" Mobedia "とコード名の付けられたモバイルビデオのブログ（blog）サービスを、本発明にかかる製品として提供する:
１． モバイル携帯電話（携帯送受信機）にプリインストールすることができるMobediaソフトウェアのカムコーダー・アプリケーションで、どのビデオ電話でもJavaが使えるものならユーザはダウンロードしてインストールすることができる。
２． Mobedia ソフトウェアのカムコーダー・アプリケーションを使用すると、 ユーザは、彼らのモバイル携帯電話（携帯送受信機）を使用して、フルVGA/30 fps(あるいはさらに高品質の)ビデオを撮影することができる。
３． Mobedia ソフトウェアの映画アプリケーションを使用すると、ユーザはブラウズ/編集の取得やタイトル追加等ができ、" splice(接続) "をマルチで（重複して）取ると、本発明にかかるソフトウェアのカムコーダー・アプリケーションを使用して個人の映画が制作できる。
４． Mobediaソフトウェアの映画アプリケーションの単純なバージョンは、ユーザに無料で配布されるであろう、一方、より充実した " Chinema-Pro " バージョンはユーザによって購入される。
Mobediaサーバと名付けられたサーバに本発明の特徴は提供され：
５． Mobedia携帯電話（携帯送受信機）のクライアントのソフトウェアを使用すると、ユーザは撮影したビデオを、モバイル、固定、無線、有線接続を介して、撮影したビデオをMobediaサーバに伝送することができる。
６． Mobediaサブスクリプションサービスは、ユーザが撮ったビデオや映画をサーバ(有料ストレージ)にアーカイブ保管することを可能にする、また、外部に更なるエディションをオンラインで持ち出したりダウンロードしたり、さらに様々なポピュラーなフォーマットでビデオ保存したり、DVD(有料)にコピーを請求することもできる。
７． Mobediaサブスクリプションサービスは、ユーザがMobediaサイト上で映画アルバムを作成することを可能とし、友達、家族、同僚などを招待してそれらの映画の鑑賞をするかあるいは贈り物としてDVD(有料)にコピーを注文することができる。
友達・家族やその他に対して、本発明にかかるMobediaタイプは提供され:
８． 友達、家族、同僚などは、ユーザの映画、ダウンロードおよび保存コピー(有料)を見ることについてemailによる招待を受け、また、自身のためのDVD(有料)のコピーを注文することができる。
一般の視聴者(映画モデル)に対して、本発明にかかるMobediaは提供する:
９． Droplet のMobediaサブスクリプションサービスは、彼等の映画を一般大衆に"公表する"のを許可しており、Mobedia映画サイト上で見ることができる。
１０． 一般の視聴者は、公表された映画のアーカイブをMobedia映画サイト上のランキング、主題、カテゴリー等や無料で見られるプリビュウで検索することができる。
１１． 一般の視聴者は、お金を払えば見ることもダウンロードすることも、DVDにコピーすることもできる。
【０１６７】
下記の方法およびプロセスは、本発明の特徴を含むもので、現在の技術によって排他的に実施可能である。
収入源/ビジネスモデル:
・映画メーカー: サーバ・スペース、ファイルのダウンロード、DVDの注文について対価を支払う。増強されたバージョンの編集用のソフトウェアに対価を支払う。
・ 友達、家族、その他: ファイルのダウンロードとDVDを注文について対科価を払う。
・一般的の視聴者： 映画全体を観る(試写だけは無料)場合、DVDを注文する場合またはダウンロードする場合は対価を支払う。
−映画メーカーは、一般的な視聴者から支払われた料金についてシェア（取り分）を獲得する。
・モバイル・オペレーター：増加したデータ交通量に応じて歳入シェアリングモデルから対価を支払う。
本発明の特徴のサービス・コンポーネントは次のものからなる:
・本発明にかかる個人のビデオコンテンツの撮影、伝送と管理のためのモバイル・ビデオ・メッセージ・プラットフォーム(サーバと携帯電話（携帯送受信機）ソフトウェア・アプリケーション)
・本発明のMobediaのソフトウェアのビデオ・カムコーダー・アプリケーションは、どのjava/ビデオ電話でのビデオ撮影をも可能にする。
・本発明のMobediaのソフトウェアのビデオ映画のクライアント・アプリケーションは、基礎的なビデオプロダクションと編集および観察に関する技術(単純なものとプロバージョン)を含んでいる。
・本発明のMobediaのソフトウェアのビデオ映画のウェーブベースのコンテンツ管理アプリケーションは、Mobedia映画の映画アルバム、パーソナル・ムービング・シェアリング（personal moving sharing）およびMobedia映画の"出版"をサポートする。 .
【０１６８】
ここに示されるのは、改善されたモバイル画像アプリケーションと、携帯送受信機（携帯電話）アーキテクチャーおよびサービス・プラットフォーム・アーキテクチャーであり、本質的にモバイルの加入者に高品質の静止画像とビデオ画像を提供することに関する技術的な複雑性とコストの削減のための結合である。改善された適応性のあるジョイント−ソース・チャネル・コーディング技術は、無線キャリアとMMSサービス・プロバイダーが、大きな範囲のサービスの質(QoS)の効率と、消費者と企業の顧客への価格レベルの提示に対応する能力であり、それにより、この無線ネットワーク・インフラストラクチュアを使用することによって生じる収入を最大化する。改善された適応性のあるジョイント−ソースチャネル・コーディング技術は、より高い計算上の効率を備えたアルゴリズムに基づいており、チャネルタイプ(無線か有線か)、チャネル帯域幅、チャネル雑音/エラー特性、ユーザ装置およびユーザ・サービスの点から、より高いレベルのネットワーク均質性（homogeneity）をサポートすることを可能にしている。さらに提供されたのは、モバイル電話における静止画像と動画ビデオの分野に、増強された革新的なサービスを提供する方法、装置、プロセスおよびビジネス方法である。
【０１６９】
さらに、本発明の特徴として追加的に提供するのは、以下の要約の通りである。
【０１７０】
改善されたウェーブレットを基礎とするコーデックを利用するモバイル画像アプリケーション。このアプリケーションはソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７１】
また、微粒子（fine grain）伸縮性を使った上述の改善されたウェーブレットベースのコーデックによる改善されたジョイント−ソース・チャネル・コーディングからなるシステムと方法を提供するもので、復元されるビデオ信号の瞬間と平均の質(ビデオ・レート対ひずみ)の両方を最大にコントロールするために、情報源コーダー、チャネル・コーダーおよび適応性のあるレート・コントローラーのすべての３つのチャネル帯域幅およびエラー条件の瞬間値と予定値の両方の情報を利用している。さらに提供されたシステムと方法は、消費者と企業のMMS顧客のためにサービスの質の(QoS)効率と価格レベルをより大きな範囲な適用することができ、チャネル・タイプ(固定無線通信、モバイルの無線通信および有線通信)、チャネル帯域幅、チャネル雑音/エラー特性、ユーザ装置、および改善されたマルチキャスティングを含むユーザ・サービスでのネットワーク異成分のはるかに高いレベルのサポートをすることができる。
【０１７２】
モバイルカムコーダー（ビデオカメラ）・アプリケーションもまた提供される。このアプリケーションは、モバイル機器におけるフル・カムコーダー能力のため、前述の２節の特徴と関連する画像の前処理と後処理に関する機能および音声録音とを組み合わせたものであり、ソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７３】
モバイル画像アプリケーションもまた提供される。このアプリケーションは、改良されたウェーブレットに基づくコーデックを使用し、Javaアプリケーションとして実装される。この実装はソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７４】
さらに提供されるのは、モバイル・カムコーダ・アプリケーションで、モバイル機器におけるフル・カムコーダ能力のため、前節で述べたアプリケーションと画像の前処理と後処理に関する機能および音声録音とを組み合わせたものである。このアプリケーションはソフトウェア単体実行による実装、ハードウェアのみの実装、若しくはソフトウェア＋ハードウェアのハイブリッド実装の形態をとる。
【０１７５】
さらに提供されたのは、画像の出来るモバイル送受信機（携帯電話）のアーキテクチャであってpects として利用されものであり、この要約の前節の特徴であるモバイル画像アプリケーションが、携帯送受信機（携帯電話）の送受話器basebandのマルチメディア処理セクション、画像モジュール、または着脱可能なストレージメディアに組み入れられている。
【０１７６】
さらに提供されたのは、上述の画像が使用可能な携帯送受信機（携帯電話）における上記要約の上記の特徴がある無線デリバリまたはアップグレードである。
【０１７７】
さらに提供されたのは、システムで、画像が使用可能な携帯送受信機（携帯電話）へ上記の特徴およびシステムのPOSインストールあるいはアップグレードを可能にする。
【０１７８】
さらに提供されたのは、モバイル画像トランスコーダで、他が所有する標準ベースの画像フォーマットとこの要約の上記の特徴を普遍的に互換可能にする全てがソフトウェアのアプリケーションで、自動のネットワークを介したアップグレードまたはマニュアル操作でMMSCビデオ・ゲートウェイの中へ配信またはインストールされる。
【０１７９】
さらに提供されたのは、モバイル画像サービス・プラットフォーム・アーキテクチャと、方法およびシステムで、この要約の特徴をすべて組み合わせている。
【０１８０】
上記がこの発明の実施例の特徴であり、各種の代案、修正および等価物が使用されるであろう。したがって、上記の記述は、添付の請求項で定義される発明の範囲の制限となるものではない。
【図面の簡単な説明】
【０１８１】
【図１】モバイル画像通信のビデオ画像サイズの制限を示す。
【図２】情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【図３】モバイル画像携帯機器の構成を示す。
【図４】モバイル画像サービス・プラットフォームの構成を示す。
【図５】従来のビデオコーデックの技術の比較図を示す。
【図６】改良された情報源・通信路符号化結合（joint source-channel cording）のシステム図を示す。（a）エンコーダ（b）デコーダ
【図７】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【図８】ビデオコーデックの効果の比較図を示す。
【図９】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【図１０】改良されたモバイル画像送受信機のプラットフォームの構成を示す。
【０１８２】
【図１１】改良されたモバイル画像サービスのプラットフォームの構成を示す。
【図１２】展開したMMSCビデオ・ゲートウェイのネットワークを通じた（OTN）アップグレードを示す。
【図１３】ビデオMMSがトランスコーディングを必要としない自立再生を示す。
【図１４】メディア・プロデュース・サービスの展開に必要なビデオ編集サーバの複雑性、コストおよび数の縮小を示す。
【図１５】モバイル・ビデオ・サービスのプラットフォームを示す。
【図１６】より高品質のマルチメディア携帯送受信機（携帯電話）・サービスのより速くより低いコストの開発と展開を示す。
【図１７】は本発明のモバイル・ビデオ・サービスを示す。
【図１８】は本発明のブロードバンドのマルチメディア装置およびサービスへのアプリケーションを示す。
【図１９】本発明のソフトウェア画像アプリケーションに対する実装オプションを示す。
【図２０】本発明のハードウェアでアクセラレートされた画像アプリケーションの実装オプションを示す。
【０１８３】
【図２１】本発明のハイブリッド・ハードウェアでアクセラレートされたソフトウェア画像アプリケーションの実装オプションを示す。
【図２２】単純化されたマルチメディア携帯送受信機（携帯電話）プラットフォームのアーキテクチャのアプリケーションを示す。
【図２３】GSM/GPRSネットワーク上でのモバイルビデオ通信デモの要素を示す。
【図２４】本発明にかかる特定のMMS機能を示す。
【特許請求の範囲】
【請求項１】
イメージ(画像)サービス・プラットフォームの展開方法は次のステップからなる、
ネットワークに接続されたダウンロード・サーバにトランスコーダ・アプリケーションを提供し、
トランスコーダ・アプリケーションが展開に使用可能であることをネットワークに送信し、
ダウンロード・サーバからネットワーク上にあるビデオゲートウェイに向けて、ネットワークを通じてトランスコーダ・アプリケーションを展開する。
【請求項２】
請求項１記載の方法は、さらに、展開されたトランスコーダ・アプリケーションをビデオゲートウェイに自動的にインストールするステップを含む。
【請求項１】
イメージ(画像)サービス・プラットフォームの展開方法は次のステップからなる、
ネットワークに接続されたダウンロード・サーバにトランスコーダ・アプリケーションを提供し、
トランスコーダ・アプリケーションが展開に使用可能であることをネットワークに送信し、
ダウンロード・サーバからネットワーク上にあるビデオゲートウェイに向けて、ネットワークを通じてトランスコーダ・アプリケーションを展開する。
【請求項２】
請求項１記載の方法は、さらに、展開されたトランスコーダ・アプリケーションをビデオゲートウェイに自動的にインストールするステップを含む。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公表番号】特表２００８−５３７８５４（Ｐ２００８−５３７８５４Ａ）
【公表日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願番号】特願２００７−５５６３８０（Ｐ２００７−５５６３８０）
【出願日】平成１８年２月１６日（２００６．２．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００６／００５８９１
【国際公開番号】ＷＯ２００６／０８９２５４
【国際公開日】平成１８年８月２４日（２００６．８．２４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
２．ＷＩＮＤＯＷＳ
３．ＰＥＮＴＩＵＭ
４．ＵＮＩＸ
【出願人】（５０７２７４９６２）ドロップレット テクノロジー，インク． (1)
【Ｆターム（参考）】
【公表日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願日】平成１８年２月１６日（２００６．２．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００６／００５８９１
【国際公開番号】ＷＯ２００６／０８９２５４
【国際公開日】平成１８年８月２４日（２００６．８．２４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
２．ＷＩＮＤＯＷＳ
３．ＰＥＮＴＩＵＭ
４．ＵＮＩＸ
【出願人】（５０７２７４９６２）ドロップレット テクノロジー，インク． (1)
【Ｆターム（参考）】
[ Back to top ]