JP2019508953A - マルチメディアシステムにおける情報交換メカニズムおよびネットワーク伝送方法 - Google Patents

Abstract

本発明は２つの形式のマルチメディアシステムにおける情報交換メカニズムおよびネットワーク伝送方法を提供する。その１つは交換情報エージェントを採用して双方向の迅速な情報交換を実現することであり、従来のメディア伝送システムにおける高効率かつ柔軟な双方向の情報交換メカニズムが欠けている問題を解決することができ、同時に、全てのメディア伝送システムに応用することができる。もう１つはプロトコル伝送フォーマットに対してデータパケットを強制的に最小構成にすることによって、プロトコルフォーマットが迅速な情報交換に適応されるように、プロトコルフォーマットのヘッダデータの大きさを簡略化し、プロトコルフォーマットのヘッダデータのサイズを簡略化することにより、従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換メカニズムが欠けている問題を解決することができる。同時に、ビデオストリームにおける静止画像に用いられる最適化伝送メカニズムを提供し、１つ前のフレームの画像が静止しているフレームデータに対して標識ビットを追加し、該標識ビットの情報のみを伝送し該フレームデータのメカニズムを伝送せず、ストリームメディアビデオにおける静止画像フレームによる帯域幅の占用およびトラフィック無駄の問題を解決する。
【選択図】図１

Description

本発明は、マルチメディアシステムにおける情報交換メカニズムに関し、より正確には、マルチメディアシステムにおける情報交換メカニズム、ネットワーク伝送方法および最適化伝送メカニズムに関する。

クラウドコンピューティング、モノのインターネット（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ：ＩｏＴ）、スマートウェアラブルデバイスなど次世代アプリケーションの消費形態が興っている。これにともない、従来のオーディオおよびビデオメディアに基づく一方向データ伝送は、既に各種アプリケーションのニーズを満たさなくなっている。次世代マルチメディア伝送システムにおける新しいデータ伝送フォーマットは、各種可能なデータタイプを含むべきであり、同時に通信する双方は双方向通信をサポートすることにより異なるビジネスロジックおよびビジネスプロセスを実現する必要がある。

リアルタイムな情報交換は、将来マルチメディアシステムにおけるデータ交換の重要な趨勢になりつつあり、ユーザは交換データをリアルタイムにサーバーへアップロードすることによって、サーバーがユーザの現在の操作および作業状態を把握できるようにする必要がある。他方、サーバーは取得した情報に対して分析および計算を行い、迅速にレスポンスして、処理結果をリアルタイムにユーザへ伝送する。その特徴は、一回の情報データ量は小さいが、交換頻度が非常に高く、アップロード、プッシュダウンのリアルタイム性に対する要求が非常に高いことである。このため、メッセージフォーマットは簡単であり、オーバーヘッドが小さければ小さいほどよい。従って、このような迅速な情報交換に対するフォーマット設計およびネットワーク伝送方法の設計は、非常に重要である。

非リアルタイムな情報交換は、主にリソースが交換情報をリクエスト／レスポンスすることであり、その目的は、ユーザが自身の必要に応じてサーバー側のリソースのデータを能動的にリクエストするというニーズを満たすことである。その特徴は会話型の交換であり、非リアルタイムに頻繁に交換するが、クライアント側からサーバー側までの通信リンクのサポート、およびサーバーの効果的なレスポンスが必要である。プロセスは、ユーザが番組ストリームを受信した後、それにより提供される記述ファイルおよびメディアデータを含む利用可能なリソース情報を得てから、サーバー側に対して相応するデータをリクエストし、サーバーはリクエストを受信した後、リクエストの正当性を確認し、正当である場合は確認情報を送信するとともにデータを伝送し、そうでなければ失敗情報を送信する。高効率なマルチメディア伝送システムは、より軽量型のリクエストおよびレスポンスの交換方式を満たすべきであり、同時にマルチメディアに対する交換フォーマットについてもサポートすべきである。

検索によれば、出願番号がＣＮ２００３１０１２３７１０．５である中国特許文献には、マルチメディアオブジェクト付き番組内容および番組ガイドデータの通信しやすい番組固有情報データ構造に関するシステムが開示され、マルチメディアオブジェクトは、オーディオ、ビデオ、動画、静止画像、インターネット、電子メール、テキストおよびその他のタイプのデータを含む。該データ構造は、受動的に視聴されるような一方向通信アプリケーションおよび交換タイプ機能のような双方向通信アプリケーションをサポートする。デコーダは、パケット化された番組データおよび補助説明情報を含む番組固有情報を処理し、補助説明情報はマルチメディアオブジェクトタイプ、位置およびその他の説明的なインジケータを含む。これらのインジケータは異なる情報源から得られたマルチメディアオブジェクトの取得およびデコーディングに用いられ、ビデオ番組内容または番組ガイドを表示する複合ビデオ画像において表されるようにする。追加された補助位置および取得された説明情報を利用して、補充の番組固有情報ユニットおよび番組内容データを取得することができる。しかしながら、該文献に係る発明は、依然として従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換が欠けている問題を上手く解決することができない。

また、現在のネットワークトラフィックにおいて、マルチメディアサービス、特にビデオサービスはインターネットの大部分のトラフィックを占めている。如何にネットワーク伝送におけるビデオデータが占める帯域幅を効果的に低下させるかは、新しい研究ホットスポットとなっている。

現在、市場で幅広く使用されているＨ．２６４、ＨＥＶＣなどのビデオコーディング技術は、フレーム内コーディングおよびフレーム間コーディングなどの技術を採用し、極めて高いコーディング圧縮率およびコーディング効率を有するとともに、ユーザエクスペリエンスに殆ど影響を与えない。Ｈ．２６４によって圧縮されたビデオデータは、ネットワーク伝送過程において必要な帯域幅がより少なく、より経済的である。従って、Ｈ．２６４は発表されてすぐ巨大な成功を呼び、２０１１年末まで、すでに８０％のビデオがＨ．２６４を使用してコーディングされている。

Ｈ．２６４、ＨＥＶＣのフレーム間コーディング技術は、動き推定および動き補正などの技術に基づき、ビデオの前後フレームの間の類似性を利用して、前後フレームの間の違いに対してコーディングし、よって、低い符号レートでコーディングすることができる。しかしながら、ある特定のビデオアプリケーションシーン、例えば、リモートデスクトップやリモートビデオモニタリングなどのシーンに対して、Ｈ．２６４、ＨＥＶＣを使用してコーディングするには依然としてある程度の不備がある。このようなシーンと一般的なビデオアプリケイションとの主な区別は、大部分の時間において、ビデオ内容が変化せずまたは変化が非常に小さいことである。ビデオ内容が変化しない時間帯に、フレーム間コーディング、例えばＨ．２６４などのコーディング技術を採用しても、ビデオの各フレームに対してコーディングしなければならないため、依然として一定の帯域幅を占め、トラフィックを無駄にする。

検索によれば、公開番号がＣＮ１０１８８９４４７Ａである中国特許文献には、データをコーディングする方法が開示され、該方法は、（ａ）複数の連続したビデオフレームのデータを含むビデオストリームのデータをキャプチャすることと、（ｂ）１つまたは複数の、それぞれが上記ビデオストリームに対してランダムな時間間隔でキャプチャしたものである静止画像をキャプチャすることと、（ｃ）順に各静止画像を上記ビデオフレーム内に組み込むことによって組み合わせデータストリームを形成することと、（ｄ）順序パラメータセットにおける新しい構成プロパティの定義を修正することによって伝達される高解像度の静止画像の存在を利用することで、（ｅ）上記組み合わせデータストリームをコーディングすることと、（ｆ）コーディングした後の組み合わせデータストリームを一方向伝送として送信することと、を含む。

また、公開番号がＣＮ１０１８７８６４９Ａである中国特許文献にも、ビデオとシリアルに高解像度のデジタル静止画像をコーディングするために拡張されたＡＶＣ標準が開示されている。

しかしながら、上述の文献に係る発明は、依然として上記問題を解決することができなかった。

本発明は、従来技術における問題に鑑みてなされたものであり、マルチメディアシステムにおける情報交換メカニズムおよびネットワーク伝送方法を提供することであり、従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換メカニズムが欠けている問題を解決するとともに、ビデオストリームにおける静止画像に用いられる最適化伝送メカニズムを提供することにより、ビデオストリームにおける画像が変化しない場合、ビデオコーディングによる帯域幅の占用およびトラフィックの無駄を減少させることを目的とする。

上記目的を達成するための本発明に係る第１態様によれば、マルチメディアシステムにおける情報交換メカニズムであって、メッセージを採用して双方向、迅速な情報交換を実現し、前記メッセージは、メッセージ識別フィールドと、メッセージバージョン番号フィールドと、メッセージ長識別フィールドと、現在のメッセージペイロード（ｐａｙｌｏａｄ）のペイロードデータフィールドと、を含む。

さらに、前記現在のメッセージペイロード（ｐａｙｌｏａｄ）のペイロードデータフィールドは、メッセージ内容種別識別フィールドを含み、または、予備フィールドをさらに含む。

さらに、前記現在のメッセージペイロード（ｐａｙｌｏａｄ）のペイロードデータフィールドは、該メッセージのシリアル番号を示すフィールドと、該メッセージに関連付けるメッセージのシリアル番号を示すフィールドと、フィードバック状態を示すフィールドと、該メッセージの内容フォーマットを示すフィールドと、該メッセージの内容データ長を示すフィールドと、現在の交換情報を示すバイトデータフィールドと、を含む。

本発明において、メッセージは会話型で交換し、ユーザリクエストとシステムレスポンスとのフォーマットは有機的に統一されており、本メカニズムをサポートするサーバーおよびクライアントの双方は、ｈｔｔｐプロトコルのインターフェースがなくても、マルチメディアのリソースリクエスト／レスポンスなどに対する軽量型交換アプリケーションを実現することができる。これはメディアネットワーク伝送のために、極めて大きい便利を提供する。

また、本発明により提供される柔軟なメッセージボディフォーマットメカニズムに合わせ、様々なメディアビジネスの具体的なニーズに対して、適切で具体的なメッセージフォーマットを設計することができる。迅速かつ高効率な伝送プロトコルに柔軟でカスタマイズ可能なメッセージボディフォーマットを合わせることにより、本発明は、全てのメディア伝送システムに応用可能である。

上記目的を達成するための本発明に係る第２態様によれば、上記マルチメディアシステムにおける情報交換メカニズムに基づくマルチメディアシステムにおける情報データを交換するためのネットワーク伝送方法であって、端末設備が所定のメッセージフォーマットに従って、メッセージをデータパケットにパケット化するステップと、データパケットをネットワークサーバーに伝送するステップと、サーバーが所定のメッセージフォーマットに従って、データパケットに対してペイロードデータを解析し、相応する処理およびレスポンスを行うステップと、を含み、サーバーから端末設備まで上記対応するステップを行う。

本発明により提供されるネットワーク伝送方法は、さらに、
ネットワーク端末設備が、メッセージボディの予めカスタマイズされた拡張可能なメッセージフォーマット内の具体的なビットペイロードデータフィールドのフォーマットまたはカスタムのフォーマットに従って、メッセージボディ「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドをパケット化するステップａと、
ネットワーク端末設備が、交換メッセージエージェントのフォーマットに従って、メッセージ全体をパケット化するステップｂと、
ネットワーク端末設備が、選択したネットワーク通信プロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、メッセージをプロトコル「ｐａｙｌｏａｄ」にパケット化するステップｃと、
ネットワーク端末設備が、プロトコルフォーマットの定義に従って、１つまたは複数のｐａｃｋｅｔネットワーク伝送データパケットを生成するステップｄと、
ネットワークサーバーが、１つまたは複数のクライアントにより提出されたｐａｃｋｅｔデータパケットを受信した後、データパケットプロトコルヘッダに従って、完全なプロトコルレベルの「ｐａｙｌｏａｄ」データフィールドを解析するステップｅと、
ネットワークサーバーが、選択したネットワークプロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、完全なメッセージボディデータフィールドを解析するステップｆと、
ネットワークサーバーが、メッセージヘッダの定義に従って、メッセージボディのビットペイロードデータフィールド（即ち、「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドに含まれるデータ）を解析するステップｇと、
ネットワークサーバーが、メッセージの定義またはカスタムされたフォーマットに従って、ビットペイロードデータフィールド（即ち、「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドに含まれるデータ）を解析し、相応する処理およびレスポンスを行うステップｈと、
を含む。

サーバー側からネットワーク端末設備までの通信も、上記ステップのとおりに行う。該データフォーマットおよび応用方法は、ネットワークの双方向通信要求を満たす。

上記目的を達成するための本発明に係る第３態様によれば、マルチメディアシステムにおける迅速な情報交換メカニズムであって、プロトコル伝送フォーマットに対してデータパケットを強制的に最小構成にし、プロトコルフォーマットのヘッダデータのサイズを簡略化することにより、プロトコルフォーマットを迅速な情報交換に適応させることを含み、前記プロトコルフォーマットのヘッダデータのサイズを簡略化することは、データパケット識別子（Ｐａｃｋｅｔ＿ｉｄ）、タイムスタンプ（Ｔｉｍｅｓｔａｍｐ）、データパケットシリアル番号（Ｐａｃｋｅｔ＿ｓｑｕｅｎｃｅ＿ｎｕｍｂｅｒ）の３つのフィールドのいずれか１つまたは２つまたは３つに対する簡略化であり、バイト数が小さいインジケータを利用して該３つのフィールドを使用するか否かを指示することにより、プロトコルフォーマットのヘッダデータのバイト数を小さくし、よってプロトコルフォーマットを迅速な情報交換に適応させる。

具体的には、前記プロトコルフォーマットのヘッダデータのサイズを簡略化することとは、元のプロトコル伝送フォーマットにおける予備フィールドを標識ビットに選択し、Ｐａｃｋｅｔ＿ｉｄ、Ｔｉｍｅｓｔａｍｐ、Ｐａｃｋｅｔ＿ｓｑｕｅｎｃｅ＿ｎｕｍｂｅｒの３つのフィールドを簡略化することを使用するか否かの選択肢を提供することにより、プロトコルフォーマットのヘッダデータのバイト数を小さくし、よってプロトコルフォーマットを迅速な情報交換に適応させる。

さらに、インジケータに採用されるアルファベット、符号などのタイプは限定されない。

さらに、インジケータに採用されるＴ、ＰおよびＦ識別フィールドは、それぞれ１つのバイトを占める。

さらに、前記プロトコルフォーマットのヘッダデータのサイズを簡略化することは、具体的には、元のプロトコル伝送フォーマットにおける予備フィールドを選択してそれぞれＴ識別フィールドに修正することであり、Ｔは、ｔｉｍｅｓｔａｍｐ＿ｆｌａｇタイムスタンプ識別子であり、１に設定するとｔｉｍｅｓｔａｍｐフィールドを使用し、０に設定すると使用せず、交換情報が極めて高いリアルタイム性を有する場合、即ち、クライアント側またはサーバー側が該情報を受信すると即座にレスポンスする場合、該フィールドを０に設定するが、前提としては信頼できる下位層の通信プロトコルを提供することである。

さらに、前記プロトコルフォーマットのヘッダデータのサイズを簡略化することは、具体的には、元のプロトコル伝送フォーマットにおける予備フィールドを選択してそれぞれＰ識別フィールドに修正することであり、Ｐは、ｐａｃｋｅｔ＿ｉｄ＿ｆｌａｇデータパケット識別子であり、１に設定するとｐａｃｋｅｔ＿ｉｄフィールドを使用し、０に設定すると使用せず、ペイロード情報量が小さく、１つのデータパケットを入れて伝送することができるかまたはデータパケットを下位層のプロトコルに引き渡して実現することができる場合、該フィールドを０に設定するが、前提としては信頼できる下位層の通信プロトコルを提供することである。

さらに、前記プロトコルフォーマットのヘッダデータのサイズを簡略化することは、具体的には、元のプロトコル伝送フォーマットにおける予備フィールドを選択してそれぞれＦ識別フィールドに修正することであり、Ｆは、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｆｌａｇデータパケット識別子であり、１に設定するとｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドを使用し、０に設定すると使用せず、該フィールドは「Ｐ」フィールドと合わせて使用されており、「Ｐ」フィールドを０に設定する条件を満たす場合、該フィールドを０に設定する。

本発明に係る上記プロトコルフォーマットのヘッダデータのサイズを簡略化することによれば、バイト数を大幅に減少し、よってネットワーク伝送の速度を向上させ、迅速なネットワーク情報交換に適応することができる。さらに、該迅速なネットワーク情報交換の前提において、様々なメディアビジネスの具体的なニーズに対して、迅速なメッセージ交換フォーマットおよび双方向にリソースの迅速なリクエスト/レスポンスメッセージフォーマットを設計することができ、迅速、高効率な伝送プロトコルに柔軟かつカスタマイズ可能なメッセージボディフォーマットを合わせることにより、本発明は全てのメディア伝送システムに応用できる。

前記迅速な情報交換において、迅速に交換されたメッセージ実体はシグナリングモードにおいて伝送される。

さらに、前記迅速な情報交換において、迅速な交換情報エージェントは、リアルタイムな交換メッセージメッセージ識別フィールドと、メッセージのバージョン番号フィールドと、メッセージ長識別フィールドと、拡張フィールドと、現在のメッセージペイロード（ｐａｙｌｏａｄ）を示すデータフィールドと、を含む。

さらに、異なるタイプのメッセージペイロードは異なるフォーマットを備え、リアルタイムな交換メッセージペイロード（ｐａｙｌｏａｄ）は、現在のメッセージシグナリングペイロード部分に拡張可能なデータ部分が含まれるか否かを示す拡張標識ビットフィールドと、該メッセージシグナリングに含まれた交換データ数を示すフィールドと、現在の交換情報を示すタイプと、現在の交換データ長を示すフィールドと、現在の交換情報を示すバイトデータフィールドと、ユーザによるカスタムまたは将来の拡張に用いられるデータフォーマットデータフィールドと、を含み、リソースリクエスト／レスポンスメッセージペイロード（ｐａｙｌｏａｄ）は、現在のユーザがリソースをリクエストする方法を示すリソースリクエスト方法識別フィールドと、現在のメッセージシグナリングペイロード部分に拡張可能なデータ部分が含まれるか否かを示す拡張標識ビットフィールドと、を含む。

前記リアルタイムな交換メッセージペイロード（ｐａｙｌｏａｄ）に対して、本発明はその汎用フォーマットを予め定義し、具体的なメッセージフォーマットの定義を予め設定する。リソースリクエスト／レスポンスメッセージは会話型交換であり、ユーザリクエストとシステムレスポンスとのフォーマットは有機的に統一されており、本メカニズムをサポートするサーバーおよびクライアント側の双方は、ｈｔｔｐプロトコルのインターフェースがなくても、マルチメディアのリソースリクエスト／レスポンスなどに対する軽量型交換アプリケーションを実現することができる。これはメディアネットワーク伝送のために、極めて大きい便利を提供する。

上記目的を達成するための本発明に係る第４態様によれば、上記マルチメディアシステムにおける迅速な情報交換メカニズムに基づくマルチメディアシステムにおける交換情報データのネットワーク伝送方法であって、
ネットワーク端末設備が、メッセージボディの予め定義された迅速な交換メッセージペイロードデータフィールド（ｐａｙｌｏａｄ）のフォーマットまたはカスタムのｐａｙｌｏａｄフォーマットに従って、メッセージボディ「ｐａｙｌｏａｄ」フィールドをパケット化するステップａと、
ネットワーク端末設備が、迅速な交換メッセージエージェントのフォーマットに従って、メッセージ全体をパケット化するステップｂと、
ネットワーク端末設備が、ＭＭＴ（ＩＳＯ／ＩＥＣ ２３００８−１）の元のプロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、メッセージをプロトコル「ｐａｙｌｏａｄ」にパケット化するステップｃと、
ネットワーク端末設備が、プロトコルフォーマットの定義に従って、１つまたは複数のｐａｃｋｅｔネットワーク伝送データパケットを生成するステップｄと、
ネットワークサーバーが、１つまたは複数のクライアントにより提出されたｐａｃｋｅｔデータパケットを受信した後、データパケットプロトコルヘッダに従って、完全なプロトコルレベルの「ｐａｙｌｏａｄ」データフィールドを解析するステップｅと、
ネットワークサーバーが、プロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、完全なメッセージボディデータフィールドを解析するステップｆと、
ネットワークサーバーが、メッセージヘッダの定義に従って、メッセージボディの「ｐａｙｌｏａｄ」データフィールドを解析するステップｇと、
ネットワークサーバーが、メッセージの定義またはカスタムされたフォーマットに従って、メッセージ「ｐａｙｌｏａｄ」データフィールドを解読し、相応する処理およびレスポンスを行うステップｈと、
を含む。

サーバー側からネットワーク端末設備までの通信も、上記ステップのとおりに行う。該データフォーマットおよび応用方法は、ネットワークの双方向通信要求を満たす。

上記目的を達成するための本発明に係る第５態様によれば、ビデオストリームにおける静止画像に用いられる最適化伝送メカニズムであって、１つ前のフレームの画像の静止で変化しないフレームデータに対して標識ビットを追加し、該標識ビットの情報のみ伝送し該標識ビットのデータを伝送しないメカニズムであり、ストリームメディアビデオ伝送における静止画像フレームによる帯域幅の占用およびトラフィックの無駄の問題を解決する。

具体的には、前記ビデオストリームにおける静止画像に用いられる最適化伝送メカニズムは、既存のビデオ伝送パケットヘッダのフォーマットに対し、伝送されるパケットヘッダまたはシグナリングにおいてビデオ画像静止フレーム標識ビットを設置し、ビデオ伝送中において、静止のビデオフレーム画像に対応するデータパケットに対し、パケットヘッダまたはシグナリングにおけるビデオ静止フレーム標識ビット情報のみを送信し、相応する静止フレームデータを切り捨て、クライアント側はビデオ静止フレーム標識ビットを受信した後、１つ前のフレームの画像を利用して現在のフレームの画像を再構築する。

好ましい一実施形態として、前記伝送されるパケットヘッダまたはシグナリングにおいてビデオ静止フレーム標識ビットを設置することは、ＭＭＴＰパケットヘッダにおける予備フィールドから１つのビットを取り出してビデオ静止フレーム標識ビットとし、現在のＭＭＴＰパケットに対応するフレームデータが１つ前のフレームと同じであることを指示することを指す。

好ましい一実施形態として、前記伝送されるパケットヘッダまたはシグナリングにおいてビデオ静止フレーム標識ビットを設置することは、ＤＵ ｈｅａｄｅｒにおけるｐｒｉｏｒｉｔｙフィールドを使用し、特定の値を取って現在のＭＭＴＰパケットに対応するフレームデータが１つ前のフレームと同じであることを表示することを指す。

従来技術に比べて、本発明の好適な効果は以下のとおりである。
（１）本発明に係る第１態様および第２態様の技術的解決手段によれば、情報交換メカニズムは様々な異なる交換型データの特徴に対し、統一の交換型データの伝送フォーマットを設計することができ、統一の交換型データを伝送することによって、通信する双方は異なるタイプのデータに適応するために発生するオーバーヘッドを大幅に節約することができ、さらに、メッセージボディにおける「ｐａｙｌｏａｄ」データフィールドもカスタムすることを許可し、メッセージヘッダにおける予備フィールドに合わせて、システムの拡張を非常に便利に実現することができる。本発明は、メディアネットワークの伝送効率を効果的に向上させることができる。

（２）本発明に係る第３態様および第４態様の技術的解決手段によれば、迅速な情報交換メカニズムは、様々な異なる交換型データの特徴に対し、統一の交換型データの伝送フォーマットを設計することができ、統一の交換型データを伝送することによって、通信する双方は異なるタイプのデータに適応するために発生するオーバーヘッドを大幅に節約することができ、さらに、メッセージボディにおける「ｐａｙｌｏａｄ」データフィールドもカスタムすることを許可し、メッセージヘッダにおける予備フィールドに合わせて、システムの拡張を非常に便利に実現することができる。本発明は、メディアネットワークの伝送効率を効果的に向上させることができる。

（３）本発明に係る第５態様の技術的解決手段によれば、ＭＭＴＰパケットヘッダ、ＤＵ ｈｅａｄｅｒなどのような現在のビデオデータ伝送におけるパケットヘッダまたはシグナリングに対して、相応する静止フレーム標識ビットを設置し、標識ビットのみを伝送し、相応するフレームデータを伝送しない方法によって、ネットワーク帯域幅の使用を節約し、ストリームメディアビデオ伝送における静止画像フレームによる帯域幅の占用およびトラフィックの無駄を解決する。

本発明の実施例１における交換メッセージのメッセージ応用を示す図である。 本発明の実施例２におけるメッセージの伝送および解析のプロセスを示すフローチャートである。 本発明の実施例２におけるＭＭＴＰ元のプロトコル伝送フォーマットのデータパケットフォーマットを強制的に最小構成にすることを示す図である。 本発明の実施例２におけるリアルタイムな交換メッセージ応用を示す図である。 本発明の実施例２における簡略化した後の最小データヘッダフォーマットを示す図である。 本発明の実施例２におけるリソースリクエスト／レスポンスメッセージ応用を示す図である。 本発明の実施例２におけるＭＭＴの従来のｐａｙｌｏａｄのヘッダデータフォーマットを示す図である。 本発明の実施例３におけるＭＭＴＰパケットヘッダにおける予備フィールドを静止フレーム標識ビットとすることを示す図である。 本発明の実施例３におけるＤＵ ｈｅａｄｅｒにおけるｐｒｉｏｒｉｔｙフィールドを使用することを示す図である。

以下、図面を参照しながら非限定な実施例について詳細に説明することにより、本発明のその他の特徴、目的および利点を明確にする。
以下、本発明に係る実施例に対して詳細に説明する。本発明に係る実施例は、本発明に係る技術的解決手段を前提にして実施されており、詳細な実施形態および具体的な操作過程を提供している。指摘すべきことは、いわゆる当業者であれば、本発明の技術的思想から逸脱しない前提において、さらに様々な変形および改良を行うことができ、これらはいずれも本発明の保護範囲に属する。

（実施例１）
本実施例では、マルチメディア伝送システムにおける情報交換メカニズムを提供することにより従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換メカニズムが欠けている問題を解決する。上記メカニズムでは、統一の交換型データの伝送フォーマットを設計し、統一の交換型データを伝送することによって、異なる種別のデータに適応するために発生するオーバーヘッドを節約する。

以下、本実施例の詳細について例を挙げながら説明する。本実施例の一実施形態において、交換情報エージェントは、表３に示すように、メッセージの識別コードを示すメッセージ識別フィールド（ｍｅｓｓａｇｅ＿ｉｄ）と、メッセージのバージョン番号を示すメッセージバージョン番号フィールド（ｖｅｒｓｉｏｎ）と、メッセージの長さを示すメッセージ長識別フィールド（ｌｅｎｇｔｈ）と、含まれているメッセージのペイロードを示す現在のメッセージペイロード（ｐａｙｌｏａｄ）のペイロードデータフィールド（ｍｅｓｓａｇｅ＿ｐａｙｌｏａｄ）と、を含む。

さらに、本実施例の一実施形態において、ペイロードデータフィールドは、少なくとも含まれているメッセージがサーバーとクライアントとの間において、アップリンク状態であるかまたはダウンリンク状態であるかを示すメッセージ内容種別識別フィールド（ＰＲＲ＿ｔｙｐｅ）を含む。好ましくは、少なくとも予備情報機能を示す予備フィールド（ｒｅｓｅｒｖｅｄ）をさらに含む。

予備フィールドのビット長および割り当ての数は限定されず、好ましくは、バイト内のビット数（１バイトは８ビットである）の整数倍とメッセージ内容種別識別フィールドのビット数との間のビット数量の差により決定されており、表３に示すように、バイト内のビットが８ビットである場合、ＰＲＲ＿ｔｙｐｅは１ビットを占め、本実施例においては予備フィールドを７ビットに設定し、「１１１１１１１」に割り当て、８の整数倍に設定することにより情報処理を便利にする。

ここで、メッセージ内容種別識別フィールドは異なる値の割り当てによってアップリンク状態またはダウンリンク状態をそれぞれ示す。メッセージ内容種別識別フィールドは、表１におけるＰＲＲ＿ｔｙｐｅフィールド値のように、「０」に割り当てることによりアップリンク状態を示し、「１」に割り当てることによりダウンリンク状態を示す。

さらに、メッセージ内容種別識別フィールドがアップリンク状態である場合、即ち、本実施例において「０」に割り当てる形式に対応して、メッセージは、該メッセージのアップリンクシリアル番号を示すメッセージアップリンクシリアル番号識別フィールドである該メッセージのシリアル番号を示すフィールドと、アップリンクバイトデータフィールドのフォーマットを示す該メッセージの内容フォーマットを示すフィールドと、アップリンクバイトデータフィールドの長さを示す該メッセージの内容の長さを示すフィールドと、現在の交換がアップリンク状態である場合のバイトストリームを含むアップリンクバイトデータフィールドである現在の交換情報のバイトデータフィールドと、を含む。

さらに、メッセージ内容種別の識別フィールドがダウンリンク状態である場合、即ち、本実施例において「１」に割り当てる形式に対応して、メッセージは、該メッセージのダウンリンクシリアル番号を示すメッセージダウンリンクシリアル番号識別フィールドである該メッセージに関連するメッセージのシリアル番号を示すフィールドと、フィードバック状態フィールドにより示し、かつ現在の交換がダウンリンク状態である際のバイトストリームを含むダウンリンクバイトデータフィールドであるフィードバック状態のフィールドと、を含み、上記ダウンシリアル番号と上記アップリンクシリアルとは関連づけており、該関連方式はアップリンクおよびダウンリンクする際にシリアル番号が同じであり、所定の方式が対応していることを含む。

本実施例において、表２に示すように、フィードバック状態フィールドは異なる値の割り当てにより、少なくとも３つのフィードバック状態を対応するように示し、即ち、表２における０ｘ００、０ｘ０１および０ｘ０２により対応する３つであり、それぞれ、情報のアップリンク伝送に失敗し、少なくとも事前設定の時間内に受信が完了されていない場合を含む第１フィードバック状態と、情報のアップリンク伝送に成功した第２フィードバック状態と、情報のアップリンク伝送に成功し、上記メッセージはフィードバックデータとして理解できるダウンリンクのバイトストリームを含む第３フィードバック状態である。

本実施例において、さらに好ましくは、上記３つのフィードバック状態以外に、さらに、ＩＳＯ標準を予備する第４フィードバック状態、プライベートフィールドを予備する第５フィードバック状態を予備フィードバック状態として提供し、該予備フィードバック状態は任意の１つまたは２つまたは複数であってよい。各フィードバック状態と値の割り当てとの対応関係は、表２に示すとおりである。

さらに、フィードバック状態の示されたフィールドが上記第３フィードバック状態において、即ち、本実施例における値の割り当てが「０ｘ０２」に対応する形式において（良好な互換性を保持するために、フィードバック状態フィールドの値の割り当ては標準Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＨＴＴＰ）プロトコルの状態コードｓｔａｔｕｓ ｃｏｄｅｓの値を参照することができる）、上記メッセージは、現在の交換情報のダウンリンクのバイト内容である現在の交換情報を示すバイトデータフィールドと、該ダウンリンクバイトストリームの内容フォーマットを示すフィールドである該メッセージの内容フォーマットを示すフィールドと、該ダウンリンクバイトストリームの内容長さを示すフィールドである該メッセージの内容データ長さを示すフィールドと、を含む。

要するに、本発明に対し、メッセージにおけるデータフォーマット全体の構造は以下の表３に示す交換メッセージフォーマットを参照することができる。

表３において、Ｕｉｍｓｂｆは符号なし整数を示し、即ち、「ｕｎｓｉｎｇｅｄ ｉｎｔｅｇｅｒ， ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔ ｆｉｒｓｔ」であり、数字は該データ項が占めるビット数を表示する。Ｂｓｌｂｆはビット列を表し、即ち、「Ｂｉｔ ｓｔｒｉｎｇ， ｌｅｆｔ ｂｉｔ ｆｉｒｓｔ」である。

注意すべきことは、表３は本発明の実施例の好ましい一態様にすぎず、各フィールド、データ、内容の長さ、位置およびフォーマットに対する限定にならない。

上記マルチメディア伝送システムにおける情報交換メカニズムに基づき、本実施例はさらに交換情報データのネットワーク伝送方法を提供し、一実施形態として、本実施例に係るメッセージデータのネットワーク伝送方法は、ネットワーク端末設備（クライアント）とネットワークサーバーとの間に応用され、具体的には、
ネットワーク端末設備が、メッセージボディの予めカスタマイズされた交換メッセージエージェントフォーマットにおける具体的なビットペイロードデータフィールドのフォーマットまたはカスタムのフォーマットに従って、メッセージボディ「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドをパケット化するステップａと、
ネットワーク端末設備が、交換メッセージエージェントのフォーマットに従って、メッセージ全体をパケット化するステップｂと、
ネットワーク端末設備が、選択したネットワーク通信プロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、メッセージをプロトコル「ｐａｙｌｏａｄ」にパケット化するステップｃと、
ネットワーク端末設備が、プロトコルフォーマットの定義に従って、１つまたは複数のｐａｃｋｅｔネットワーク伝送データパケットを生成するステップｄと、
ネットワークサーバーが、１つまたは複数のクライアントにより提出されたｐａｃｋｅｔデータパケットを受信した後、データパケットプロトコルヘッダに従って、完全なプロトコルレベルの「ｐａｙｌｏａｄ」データフィールドを解析するステップｅと、
ネットワークサーバーが、選択したネットワークプロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、完全なメッセージボディデータフィールドを解析するステップｆと、
ネットワークサーバーが、メッセージヘッダの定義に従って、メッセージボディのビットペイロードデータフィールド（即ち、「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドに含まれたデータ）を解析するステップｇと、
ネットワークサーバーが、メッセージの定義またはカスタムされたフォーマットに従って、ビットペイロードデータフィールド（即ち、「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」フィールドに含まれたデータ）を解析し、相応する処理およびレスポンスを行うステップｈと、
を含む。

サーバー側からネットワーク端末設備までの通信も、上記ステップのとおりに行う。該データフォーマットおよび応用方法は、ネットワークの双方向通信要求を満たす。

一実施形態として、本実施例に係るメッセージフォーマットによりユーザがカスタマイズしたｊｓｏｎフォーマットのメッセージ内容を伝送することを例として、メッセージ交換の実施ステップを説明する。本実施例は良好な拡張性および柔軟性を有し、ユーザはｊｓｏｎ等のフォーマットを非常に便利に使用して、自分のカスタマイズ情報を伝送することができる。以下は、実際のステップについての説明である。

情報内容をｊｓｏｎファイルに書き込む。例えば、ユーザが番組を選択して放送し、放送中にプレーヤのプログレスバをドラッグすることにより直接番組のある時点にジャンプして視聴する。この場合、該時点情報をアップロードしなければならないため、特定の位置からデータパケットを取得し始める。該リクエストに従って生成されるｊｓｏｎファイル内容は以下の通りである。
｛”ｅｖｅｎｔＴｙｐｅ”：”ｒｅｑｕｅｓｔ＿ｍｏｖｉｅ＿ｂｙ＿ｔｉｍｅ”，”ｍｏｖｉｅＩＤ”：”１２３”，”ｔｉｍｅ”：”１７：５０”｝

この例において、「ＰＲＲ＿ｔｙｐｅ」フィールド値を「０」に設定し、「ＰＯＳＴ＿ｓｅｒｉａｌ＿ｎｕｍｂｅｒ」フィールド値を「１１１」に設定し、「ｍｉｍｅ＿ｔｙｐｅ（）」フィールド値を、ｍｉｍｅ標準に従ってｊｓｏｎファイルタイプに対応する値に設定する。

該ｊｓｏｎファイルをｂｉｔストリームとしてメッセージボディの「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」データフィールドに書き込み、その後、メッセージを送信すればよく、具体的なメッセージ伝送の下位層は任意の互いに適応するプロトコルおよび物理層を使用することができる。

サーバーは該アップロードメッセージを受信した後、相応する解析を行い、フィードバック情報を提供する。フィードバック情報内容もｊｓｏｎフォーマットを用いて構成する。そうすると、サーバーにより返信されるダウンロードメッセージに対し、具体的な値の設定は以下の通りである。

「ＰＲＲ＿ｔｙｐｅ」フィールド値を「１」に設定し、「Ｒｅｓｐｏｎｓｅ＿ｎｕｍｂｅｒ」フィールド値を「１１１」に設定し、「ｓｔａｔｕｓ＿ｎｕｍｂｅｒ」フィールド値を「０ｘ０２」に設定し、「ｍｉｍｅ＿ｔｙｐｅ（）」フィールド値を、ｍｉｍｅ標準に従ってｊｓｏｎファイルタイプに対応する値に設定する。そして、該ｊｓｏｎファイルをｂｉｔストリームとしてメッセージボディの「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」データフィールドに書き込み、その後、メッセージを送信する。
該プロセスは、図１に示されるとおりである。

標準でないメッセージフォーマットを介して情報交換を行う方式は、異なるサーバーおよびクライアントに対して繰り返した開発を行わなければならない。これに対して、本発明によれば、情報フォーマットの標準化を介して、マルチメディア伝送ネットワークを構成する複雑性を効果的に低下させることができる。

理解すべきことは、以上は本発明の一実施例に過ぎず、本発明はさらにその他の伝送システムに応用されることができ、具体的なビジネスニーズに対し、伝送必要なネットワーク交換情報データを抽出し、情報データをメッセージの「ｐａｙｌｏａｄ」における「ＰＲＲ＿ｄａｔａ＿ｂｙｔｅ」データフィールドに書き込んだ後、交換情報データのネットワーク伝送方法に記載されたステップ通りに実行さえすれば、実現することができる。このことは、本発明に係る技術的解決手段をもとに、いわゆる当業者は容易に理解できる。

（実施例２）
本実施例は、他の１つのマルチメディア伝送システムにおける迅速な情報交換メカニズムを提供し、プロトコル伝送フォーマットのデータパケットを強制的に最小構成にすることに対し、プロトコルフォーマットヘッダデータのサイズを簡略化し、プロトコルフォーマットを迅速な情報交換に適応させ、さらに、迅速なメッセージ交換フォーマットおよび双方向リソース迅速リクエスト／レスポンスメッセージフォーマットを対応するように設計することにより、全てのメディア伝送システムに応用することができ、同時に相応するネットワーク伝送方法を提供することにより、該迅速な情報交換におけるデータフォーマットを応用することで、従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換メカニズムが欠けている問題を解決する。
以下、一実施例を提供することにより、本実施例の実施の詳細について例示的に説明する。

（１）プロトコルの改良
本実施例における交換情報のプロトコルフォーマットは、ＭＭＴＰプロトコルを改良することにより高効率、迅速なネットワーク情報交換にさらに適応させ、応用される範囲を全てのメディア伝送システムに拡大させ、ＭＭＴＰプロトコルに限定されないようにする。

選択可能なフィールド以外に、ＭＭＴＰの元のプロトコル伝送フォーマットの強制的に最小構成にするデータパケットは、プロトコルのバージョンを示すフィールド「Ｖ」と、「ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ」データフィールドが存在するか否かを示す標識フィールド「Ｃ」と、「ＦＥＣ」（前方誤り訂正）データフィールドが存在するか否かを示す標識フィールド「ＦＥＣ」と、拡張ヘッダデータフィールドが存在するか否かを示す標識フィールド「Ｘ」と、該ペイロード情報内容がランダムアクセスポイント（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）特性を備えるか否かを示す標識フィールド「Ｒ」と、予備フィールド「ｒ」および「ＲＥＳ」と、ペイロード情報の種別を示す標識フィールド「Ｔｙｐｅ」と、Ｐａｃｋｅｔ＿ｉｄ識別フィールドと、Ｔｉｍｅｓｔａｍｐタイムスタンプフィールドと、Ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒシリアル番号識別フィールドと、を含む。
そのバイトフォーマットは、図３に示されるとおりである。

本実施例では、交換情報の高効率、迅速な要求に対し、元のフォーマットにおける予備フィールド（即ち、「ｒ」および「ＲＥＳ」フィールド）を標識ビットとして使用し、Ｐａｃｋｅｔ＿ｉｄ、Ｔｉｍｅｓｔａｍｐ、Ｐａｃｋｅｔ＿ｓｑｕｅｎｃｅ＿ｎｕｍｂｅｒの３つのフィールドを簡略化する選択肢を提供することによって、プロトコルフォーマットヘッダデータのサイズを効果的に簡略化している。

元の予備フィールド位置の「ｒ」（１ｂｉｔ）を「Ｔ」識別フィールドに修正する。
「Ｔ」は、ｔｉｍｅｓｔａｍｐ＿ｆｌａｇであり、１に設定するとｔｉｍｅｓｔａｍｐフィールドを使用し、０に設定すると使用しない。交換情報が極めて高いリアルタイム性を有する場合、即ち、クライアント側またはサーバー側が該情報を受信して即座にレスポンスする場合、該フィールドを０に設定することができるが、前提は信頼できる下位層の通信プロトコルを提供することである。

元の予備フィールド位置の「ＲＥＳ」（２ｂｉｔｓ）を「Ｐ」および「Ｆ」識別フィールド（各１ｂｉｔ）に修正する。
「Ｐ」は、ｐａｃｋｅｔ＿ｉｄ＿ｆｌａｇであり、１に設定するとｐａｃｋｅｔ＿ｉｄフィールドを使用し、０に設定すると使用しない。ペイロード情報量が小さく、１つのデータパケットを入れて伝送することができる場合、またはデータパケットを下位層のプロトコルに引き渡して実現できる場合、該フィールドを０に設定することができるが、前提は信頼できる下位層の通信プロトコルを提供することである。

「Ｆ」は、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｆｌａｇであり、１に設定するとｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドを使用し、０に設定すると使用しない。該フィールドは一般的に「Ｐ」フィールドと合わせて使用されており、「Ｐ」フィールドを０に設定する条件を満たす場合、該フィールドを０に設定することもできる。

元のＭＭＴの各強制フィールドに合わせて、簡略化した後の最小データヘッダフォーマットは、図５に示すとおりである。

明らかに、簡略化した後の最小構成のプロトコルフォーマットは、バイト数が大幅に減少されているため、ネットワーク伝送の速度を向上させる。

互換性をさらによく保持するために、迅速に交換するメッセージ実体はＭＭＴＰのシグナリングモードにおいて伝送することができ、ここでは、図７に示すように、ＭＭＴの従来のｐａｙｌｏａｄのヘッダデータフォーマットを示す。

ＭＭＴＰシグナリングモードのデータヘッダ部分は、断片集約を示すフィールド「ｆ＿ｉ」と、データフィールドが１つのシグナリングしか含まないか否かを示すフィールド「Ａ」と、残りの受信待ち組み合わせられた断片の数を示すフィールド「ｆｒａｇ＿ｃｏｕｎｔｅｒ」と、予備フィールド「ｒｅｓ」と、情報長フィールドの長さを示すフィールド「Ｈ」と、情報長を表示するフィールド「ＭＳＧ＿ｌｅｎｇｔｈ」と、を含む。

しかし、再び強調すべきことは、本実施例はＭＭＴプロトコルの応用シーンに限定されない。メッセージボディペイロードデータフィールド（ｐａｙｌｏａｄ）フォーマットは柔軟でカスタマイズ可能であるため、理論的に本実施例のメッセージメカニズムは、任意のメディアシステムの情報交換伝送に適用することができる。

（２）迅速な交換情報エージェントのフォーマット
迅速な交換情報エージェントは、リアルタイムにメッセージを交換するメッセージ識別フィールドと、メッセージのバージョン番号フィールドと、メッセージ長識別フィールドと、拡張フィールドと、現在のメッセージペイロード（ｐａｙｌｏａｄ）を示すデータフィールドと、を含む。

具体的な一実施形態として、表４のフォーマットを採用することができる。

より具体的には、異なる種別のメッセージペイロードには異なる具体的なフォーマットが有り、よって、本実施例は様々なメッセージニーズを柔軟、高効率に対応することができることが分かる。一実施形態において、メッセージペイロードが採用することができる具体的なフォーマットは以下のとおりである。

１）リアルタイム交換メッセージペイロード（ｐａｙｌｏａｄ）の定義
リアルタイム交換メッセージ（Ｒｅａｌ−ｔｉｍｅ Ｉｎｔｅｒａｃｔｉｏｎ Ｍｅｓｓａｇｅ、ＲＩＣ＿ｍｅｓｓａｇｅ）は、リアルタイムな交換データを伝送するのに用いられる。該メッセージの主な特徴は、メッセージデータ量が少なく、頻度が高く、アップロードのリアルタイム性に対する要求が高い一部のシーンのニーズを満足することができることである。その汎用フォーマットを予め定義し、具体的なメッセージフォーマットの定義を予め設定することも、本実施例の一部と見なされるべきである。

リアルタイム交換メッセージペイロードは、現在のメッセージシグナリングペイロード部分に拡張可能なデータ部分が含まれるか否かを示す拡張標識ビットフィールドと、該メッセージシグナリングに含まれた交換データ数を示すフィールドと、現在の交換情報を示す種別と、現在の交換データ長を示すフィールドと、現在の交換情報を示すバイトデータフィールドと、ユーザカスタムまたは将来の拡張に用いられるデータフォーマットデータフィールドと、を含み、情報フォーマット全体の構造は、表５のリアルタイムな交換メッセージフォーマットリストに示されるとおりである。

２）リソースリクエスト／レスポンスメッセージペイロード（ｐａｙｌｏａｄ）の定義
リソースリクエスト／レスポンスメッセージ（Ｒｅｓｏｕｒｃｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ、 ３Ｒ＿ｍｅｓｓａｇｅ）の主な特徴は、会話型交換であり、ユーザリクエストとシステムレスポンスとのフォーマットは有機的に統一されている。本メッセージは、ｈｔｔｐプロトコルメカニズムの設計思想およびその利点を吸収し、メディアネットワークにおける最も幅広いアプリケーションに対して、クライアント側がサーバー側からリソースを取得するとのネットワーク交換を新しく設計している。よって、本メカニズムをサポートするサーバー側およびクライアント側の双方は、ｈｔｔｐプロトコルのインターフェースがなくても、マルチメディアのリソースリクエスト／レスポンスなどに対する軽量型交換アプリケーションを実現することができる。これはメディアネットワーク伝送のために、極めて大きな便利を提供する。

図６は、リソースリクエスト／レスポンスメッセージの応用を示す図であり、リソースリクエスト／レスポンスメッセージは、以下のフィールドを含む。リソースリクエスト方法識別フィールドであって、現在のユーザがリソースをリクエストする方法を示し、タイプ値および説明は、表６に示すとおりである。
拡張標識ビットフィールドであって、現在のメッセージシグナリングペイロード部分に拡張可能なデータ部分が含まれるか否かを示す。

より具体的には、現在のユーザリクエストリソースを示す方法タイプフィールドが「ＲＥＱＵＥＳＴ＿ＧＥＴ」に対応するように割り振られる形式において、ユーザがＧＥＴ方式を使用してリソースのＵＲＬ情報長をリクエストするフィールドと、ユーザがＧＥＴ方式を使用してリソースのＵＲＬ具体的内容をリクエストするフィールドと、を含む。

より具体的には、現在のユーザリクエストリソースを示す方法タイプフィールドが「ＲＥＱＵＥＳＴ＿ＰＯＳＴ」に対応するように割り振られる形式において、現在のユーザがＰＯＳＴ方式を使用してリソースを要求するデータタイプを示すフィールドを含み、タイプ値および説明は、表７に示すとおりである。

ここで、より具体的には、該ＰＯＳＴ方式でリソースをリクエストするデータタイプを示すフィールドに対して「０ｘ００００」を割り振る場合において、リクエストされるメディアリソースを位置決めし、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる、リクエストされるリソースを示す唯一のＡｓｓｅｔ識別番号フィールドと、現在のメッセージがリクエストするＡｓｓｅｔを示す編集番号フィールドと、を含み、異なる編集番号はメディアリソースの異なる編集バージョンに対応し、それに含まれるＭＰＵリスト関係は関連する説明から取得することができ、完全バージョンのｅｄｉｔ＿ｉｄフィールドのデフォルト値は０であり、プロトコルが編集番号方式をサポートしない場合、該フィールドは０に設定される。

ここで、より具体的には、該ＰＯＳＴ方式に対してリソースをリクエストするデータタイプのフィールドに「０ｘ０００１」または「０ｘ０００２」または「０ｘ０００３」を割り振る場合、リクエストされるメディアリソースを位置決めし、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる、リクエストされるリソースを示す唯一のＡｓｓｅｔ識別番号フィールドと、具体的なメディア処理ユニットを位置決めし、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる、メディア処理ユニットのメディアリソースにおける唯一のシリアル番号を示すフィールドと、を含む。

ここで、より具体的には、該ＰＯＳＴ方式要求に対しリソースをリクエストするデータタイプのフィールドに対して「０ｘ０００４」を割り振る場合、その定義がＩＳＯ／ＩＥＣ ２３００８−１によって得られるリソース集合ｐａｃｋａｇｅを示す唯一の識別番号フィールドと、シグナリングの種別を識別し、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる、該リソース集合に関連するシグナリングの情報種別を示す唯一の識別番号フィールドと、シグナリングの更新バージョンを識別し、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる、該リソース集合に関連するシグナリングの情報バージョン番号を表示するフィールドと、を含む。

ここで、より具体的には、該ＰＯＳＴ方式のリソースをリクエストするデータタイプを示すフィールドに対して「０ｘ０００５」を割り振る場合、具体的なユーザアカウントを位置決めするユーザアカウントを唯一に示す識別番号フィールドと、データベースの種別を説明し、具体的な値は種別に対応し、アプリケーションに基づいて定義することができる、アップロードデータベース種別を示すフィールドと、サーバーにおけるユーザデータベースをメンテナンスし更新する、アップロードデータベースのバージョンを示すフィールドと、アップロードデータベースデータフィールドの長さを示すフィールドと、アップロードデータベースデータフィールドフィールドと、を含む。

ここで、より具体的には、該ＰＯＳＴ方式のリソースをリクエストするデータタイプを示すフィールドに対して「０ｘ０００６」を割り振る場合、サーバーが対応のファイルフォーマットに応じてデータを解析するように指示する、ユーザアップロードの汎化ファイルＭＩＭＥ種別を示すフィールドと、アップロードの汎化ファイルデータフィールドの長さを示すフィールドと、アップロードの汎化ファイルデータフィールドと、を含む。

より具体的には、現在のユーザリクエストリソースを示す方法タイプフィールドに対して割り振った値が「ＲＥＳＰＯＮＳＥ＿ＧＥＴ」の形式である場合、サーバーリターン状態を説明するフィールドを含み、その値および説明は、表８に示すとおりである。

ここで、より具体的には、サーバーリターン状態を示すフィールドに「０ｘ０２」を割り振る場合、該リソースを消費することができるか否かを事前に検査するように事前にクライアント側に告知する、サーバーによりリターンされたユーザーリクエストデータＭＩＭＥ種別を指示するフィールドと、リターン内容を示すバイト長フィールドと、リターン内容を示すデータフィールドフィールドと、を含む。

より具体的には、現在のユーザリクエストリソースを示す方法タイプフィールドに割り振られた値が「ＲＥＳＰＯＮＳＥ＿ＰＯＳＴ」に対応する場合、サーバーリターン状態を説明するフィールドを含み、その値および説明は、上記表８に示すとおりである。

ここで、より具体的には、サーバーリターン状態を示すフィールドに対し「０ｘ０３」を割り振る場合、伝送パケット番号を唯一に示すフィールドを含み、その値とＡｓｓｅｔ＿ｉｄ値とは１対１対応であり、その定義はＩＳＯ／ＩＥＣ ２３００８−１によって得られる。また、リターンリソースが位置する伝送パケットを指示する。

ユーザカスタムまたは将来の拡張に用いられるデータフィールドを含む。

情報フォーマット全体の構造は、表９および表１０に示すリソースリクエスト／レスポンスメッセージフォーマットリストを参照できる。

３）メッセージ交換の実施ステップ
本実施例により提供される交換情報データのネットワーク伝送方法は、
ネットワーク端末設備が、メッセージボディの予め定義された迅速な交換メッセージペイロードデータフィールド（ｐａｙｌｏａｄ）のフォーマットまたはカスタムのｐａｙｌｏａｄフォーマットに従って、メッセージボディ「ｐａｙｌｏａｄ」フィールドをパケット化するステップａと、
ネットワーク端末設備が、迅速な交換メッセージエージェントのフォーマットに従って、メッセージ全体をパケット化するステップｂと、
ネットワーク端末設備が、ＭＭＴ（ＩＳＯ／ＩＥＣ ２３００８−１）の元のプロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、メッセージをプロトコル「ｐａｙｌｏａｄ」にパケット化するステップｃと、
ネットワーク端末設備が、プロトコルフォーマットの定義に従って、１つまたは複数のｐａｃｋｅｔネットワーク伝送データパケットを生成するステップｄと、
ネットワークサーバーが、１つまたは複数のクライアントにより提出されたｐａｃｋｅｔデータパケットを受信した後、データパケットプロトコルヘッダに従って、完全なプロトコルレベルの「ｐａｙｌｏａｄ」データフィールドを解析するステップｅと、
ネットワークサーバーが、プロトコル「ｐａｙｌｏａｄ」フォーマットの定義に従って、完全なメッセージボディデータフィールドを解析するステップｆと、
ネットワークサーバーが、メッセージヘッダの定義に従って、メッセージボディの「ｐａｙｌｏａｄ」データフィールドを解析するステップｇと、
ネットワークサーバーが、メッセージの定義またはカスタムされたフォーマットに従って、メッセージ「ｐａｙｌｏａｄ」データフィールドを解読するステップｈと、
を含む。また、相応する処理およびレスポンスを行う。

サーバー側からネットワーク端末設備までの通信も、上記ステップのとおりに行う。該データフォーマットおよび応用方法は、ネットワークの双方向通信要求を満たす。

さらに、一実施形態として、本実施例に係るメッセージデータのネットワーク伝送方法は、ネットワーク端末設備とネットワークサーバーとの間に応用される。

１）特定のデータのリアルタイムな交換メッセージをフィードバックする
以下、クラウドデスクトップアプリケーションにおいて、該迅速な交換データタイプを用いてマウス、キーボードなどのサーバーにリアルタイムにフィードバックする必要のあるデータを伝送する具体的な使用方法について説明する。

以下の方式に従ってフィールド値を決定する。
メッセージ識別子フィールドを使用し、ある特定値を取り該伝送データを交換データの伝送に用いることを指示し、メッセージにおけるバージョンを使用して現在の時間データの該時間におけるシリアル番号を表示し、１つのメッセージを更新するたびに、本フィールド値に１を加算し、最大値に達した後、改めて０に設定する。

メッセージにおけるメッセージデータタイプを使用して異なる種別のマウス、キーボードなどのリアルタイムな交換イベントを示し、対応する交換データタイプの選択は、表１１に示すとおりである。

メッセージにおける交換データ長を使用して現在のイベントに対応するデータのサイズを示し、対応する交換データのデータ定義は、表１２に示すとおりである。

その後、図４の構造に従って、順にデータフィールドを書き込む。完全なメッセージ「ｐａｙｌｏａｄ」データフィールドを書き込んだ後、再び上記「メッセージ交換の実施ステップ」に従って、メッセージを送信する。

仮想現実設備における多種多様なアップリンクデータ、例えば、ジャイロスコープデータ、加速度計データ、磁気コンパスデータ、ジョイスティックデータ、触覚フィードバックデータ、力覚フィードバックデータに対し、いずれも相応する交換データタイプおよび交換データフォーマットを定義することによって、メディアシステムにおける伝送を実現することができる。

２）本実施例のメッセージフォーマットを用いてユーザカスタムのｊｓｏｎフォーマットのメッセージ内容を伝送する。

本実施例は、良好な拡張性および柔軟性を有し、ユーザはｊｓｏｎなどのフォーマットを非常に便利に使用して、自分のカスタム情報を伝送することができる。以下、実際のステップについて説明する。

表１３に示すように、１つの定義されていないプライベートフィールド予備値を選択して、現在のメッセージのメッセージ識別子値とする。

情報内容をｊｓｏｎファイルに書き込む。例えば、ユーザが番組を選択して放送し、番組放送中にプレーヤのプログレスバをドラッグすることにより直接プログラムのある時点にジャンプして視聴する。この場合、該時点情報をアップロードしなければならず、よって特定の位置からデータパケットを取得し始める。よって、該リクエストに従って生成されたｊｓｏｎファイル内容は、｛”ｅｖｅｎｔＴｙｐｅ”：”ｒｅｑｕｅｓｔ＿ｍｏｖｉｅ＿ｂｙ＿ｔｉｍｅ”，”ｍｏｖｉｅＩＤ”：”１２３”，”ｔｉｍｅ”：”１７：５０”｝であり、該ｊｓｏｎファイルをｂｉｔストリームとしてメッセージ本体の「ｐａｙｌｏａｄ」データフィールドに書き込み、その後、上記「メッセージ交換の実施ステップ」に従って、メッセージを送信すればよい。

標準でない情報フォーマットによって情報交換を行う方式は、異なるサーバークライアント側に対して繰り返した開発を行わなければならない。これに対して、本実施例によれば、情報フォーマットの標準化を介して、マルチメディア伝送ネットワークを構築する複雑性を効果的に低下させることができる。同時に、プロトコルに対する改良により、ネットワーク情報交換の性能を大幅に向上させることができる。特に、ネットワーク帯域幅が混雑している状況において、ユーザの満足度は十分に向上される。

本実施例により提供されるマルチメディアシステムにおける迅速な情報交換メカニズムは、主にプロトコルフォーマットヘッダデータのサイズを簡略化することにより、プロトコルフォーマットを迅速な情報交換に適応させ、さらに意図的にメッセージ交換フォーマットおよび交換方法を設計し、全てのメディア伝送システムに用いることができる。

理解すべきことは、以上は本実施例の一実施形態に過ぎず、本実施例はさらにその他の伝送システムに応用されることができ、具体的なビジネスニーズに対して、伝送必要のあるネットワーク交換情報データを抽出し、情報データを情報の「ｐａｙｌｏａｄ」データフィールドに書き込んだ後、交換情報データのネットワーク伝送方法に記載されたステップに従えば、実現することができ、本実施例に係る技術的解決手段をもとに、いわゆる当業者は容易に理解できる。

上記２つの実施例は２つの異なる形式のマルチメディアシステムにおける交換情報データの全体的なネットワーク伝送方法およびメカニズムを実現し、ここで、実施例２は伝送メカニズムにおける具体的なプロトコルフォーマットヘッダデータのサイズを簡略化することで、Ｐａｃｋｅｔ＿ｉｄ、Ｔｉｍｅｓｔａｍｐ、Ｐａｃｋｅｔ＿ｓｑｕｅｎｃｅ＿ｎｕｍｂｅｒの３つのフィールドを使用するか否かの標識ビットを提供し、プロトコルフォーマットヘッダデータバイト数を小さくする。実施例１および実施例２は異なる種別のメッセージを設計することによって使用しないタスクを遂行し、例えば、交換操作情報を伝達するリアルタイムな交換メッセージ、サーバーと交換し、リソースリクエストまたはデータアップロードを行い、具体的なメッセージを、交換メッセージフォーマット（ＰＲＲ）、リソースリクエスト/レスポンスメッセージフォーマット（３Ｒ）、リアルタイムな交換メッセージフォーマット（ＲＩＣ）にパッケージ化するリソースリクエスト相応メッセージであり、最終的に従来のメディア伝送システムにおける高効率、双方向、迅速な情報交換メカニズムが欠けている問題を解決する。

（実施例３）
本実施例では、ビデオストリームにおける静止画像に用いられる最適化伝送メカニズムを提供する。

本実施例において、ＭＭＴＰパケットヘッダ、ＤＵ ｈｅａｄｅｒのようなビデオにより伝送されるパケットヘッダまたはシグナリングにおいて、静止フレーム標識ビットを設定して該データパケットに含まれるビデオデータペイロードが空であること、その対応するフレームデータは１つ前のフレームと同じであることを示す。新たに追加された標識ビットはＭＭＴＰパケットヘッダ、ＤＵ ｈｅａｄｅｒまたはシグナリングなどの位置に含ませることができ、以下では２つの具体的な技術解決手段を提供する。

１．ＭＭＴＰパケットヘッダにおける予備フィールドから１つのビットを取り出して静止フレーム標識ビットとし、現在のＭＭＴＰパケットに対応するフレームデータが１つ前のフレームと同じであることを示す。

従来のシステムの互換性を考慮して、ＭＭＴＰパケットヘッダの予備フィールドの１ビットを取り出して標識ビットとし、該ＭＭＴＰパケットに対応するビデオフレーム情報と１つ前のフレームが同じであることを示す。

ＭＭＴＰパケットヘッダの予備フィールドの定義はｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇであり、具体的には、次のとおりである。ｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇ（Ｓ）は、現在のデータパケットに対応するフレーム情報が静止フレームであるか否かを示し、フィールドを０に設定する場合、該データパケットに対応するフレームデータが静止フレームでなく、ペイロードが空でないことを示す。一方で、フィールドを１に設定する場合、該データパケットに対応するフレームデータが静止フレームであり、該データパケットのペイロードが空であることを示す。

新たに定義されたｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇは、図８に示すように、ＭＭＴＰパケットヘッダの第５ビットに位置する。

以下、ＭＭＴＰパケットヘッダにおける予備フィールドから１つのビットを取り出して静止フレーム標識ビットとすることを例として、静止フレーム標識ビットを使用することによって伝送過程に使用される帯域幅およびデータトラフィックを節約するステップを提供する。

（ステップＳ１）
サーバー側は、コーディングされていないビデオデータの前後画像を比較し、ビデオ画像が静止している時に対応するデータフレームを取得する。

（ステップＳ２）
サーバーはビデオ情報をコーディングし、コーディングした後のフレームデータを取得する。

（ステップＳ３）
コーディングされた後のデータをＭＭＴＰにパケット化した場合、あるフレームがステップＳ１において静止フレームに認識された場合は相応するＭＭＴＰパケットにおけるｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇ（Ｓ）フィールドを１に設定し、該データパケットに対応するフレームデータが静止フレームであり、該データパケットのペイロードが空であることを表示し、その他の非静止フレームに対する処理方式は変わらない。

（ステップＳ４）
受信側は受信したＭＭＴＰパケットを解析する。ｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇ（Ｓ）フィールドが０である場合、該フレームデータをデコーダに送信する。一方、ｓｔａｔｉｃ＿ｆｒａｍｅ＿ｆｌａｇ（Ｓ）フィールドが１である場合、データをデコーダに送信せず、直接デコーダの１つ前のフレームのデコーディング結果を繰り返して画像を再構築する。

２．ＤＵ ｈｅａｄｅｒにおけるｐｒｉｏｒｉｔｙフィールドを使用し、特定値を取って現在のＭＭＴＰパケットに対応するフレームデータと１つ前のフレームが同じであることを表示する。

ＤＵ ｈｅａｄｅｒにおけるｐｒｉｏｒｉｔｙフィールドは１つのメディアユニット内における該データユニットに含まれるビデオフレームの優先度を説明し、使用において、該フィールドを「全て０」に設定し、ＤＵ ｈｅａｄｅｒに対応するフレームデータと１つ前のフレームが同じであり、ペイロードが空であることを示す。ｐｒｉｏｒｉｔｙフィールドの標準における位置は、図９に示すとおりである。

以下、ＤＵ ｈｅａｄｅｒにおけるｐｒｉｏｒｉｔｙフィールドを使用して標識ビットを指示することを例として、静止フレーム標識ビットを使用することで伝送過程に使用される帯域幅およびデータトラフィックを節約するステップを提供する。

（ステップＳ１）
サーバー側は、コーディングされていないビデオデータの前後画像を比較し、ビデオ画像が静止している時に対応するデータフレームを取得する。

（ステップＳ２）
サーバーは相応するビデオコーディング方式を使用してビデオ情報をコーディングし、コーディングした後のフレームデータを取得する。

（ステップＳ３）
コーディングされた後のデータをＭＭＴＰにパケット化した場合、あるフレームがステップＳ１において静止フレームに認識された場合は相応するＭＭＴＰパケットにおけるＤＵ ｈｅａｄｅｒのｐｒｉｏｒｉｔｙ値を「全て０」に設定し、ＤＵ ｐａｙｌｏａｄ内容は空であり、その他の非静止フレームに対する処理方式は変わらない。

（ステップＳ４）
受信側は受信したＭＭＴＰパケットを解析する。ｐｒｉｏｒｉｔｙフィールドが「全て０」でない場合、該フレームデータをデコーダに送信する。一方、ｐｒｉｏｒｉｔｙフィールドが「全て０」である場合、データをデコーダに送信せず、直接デコーダの１つ前のフレームのデコーディング結果を繰り返して画像を再構築する。

上記実施例は本実施例の一部の実施形態に過ぎず、本実施例はさらにその他の状況においてシグナリングまたはヘッダに相応する静止フレーム標識ビットを設定することができ、標識ビットのみを伝送し相応するフレームデータを伝送しない方法によって、ネットワーク帯域幅の使用を節約し、ストリームメディアビデオ伝送における静止画像フレームによる帯域幅の占用およびトラフィックの無駄の問題を解決する。

以上、本発明の具体的な実施例を説明したが、理解すべきことは、本発明は上記特定の実施形態に限定されず、いわゆる当業者であれば、特許請求の範囲内で様々な変形または補正を行うことができ、これは本発明の実質的な内容に影響しない。

Claims (26)

1. マルチメディアシステムにおける情報交換メカニズムであって、
   メッセージの識別コードを示すメッセージ識別フィールドと、
   メッセージのバージョン番号を示すメッセージバージョン番号フィールドと、
   メッセージの長さを示すメッセージ長識別フィールドと、
   含まれているメッセージのペイロードを示すペイロードデータフィールドと、
   を含むメッセージを用いて双方向かつ迅速な交換を実現する、
   ことを特徴とするマルチメディアシステムにおける情報交換メカニズム。
2. 前記ペイロードデータフィールドは、
   少なくとも含まれているメッセージがサーバーとクライアントとの間においてアップリンク状態であるかまたはダウンリンク状態であるかを示すメッセージ内容種別識別フィールドを含む、
   ことを特徴とする請求項１に記載のマルチメディアシステムにおける情報交換メカニズム。
3. 前記ペイロードデータフィールドは、
   少なくとも予備メッセージ機能を示す予備フィールドをさらに含む、
   ことを特徴とする請求項１に記載のマルチメディアシステムにおける情報交換メカニズム。
4. 少なくとも予備メッセージ機能を示し、そのビット長は、バイトにおけるビット数の整数倍と前記メッセージ内容種別識別フィールドのビット数との間のビット数の差によって決定される予備フィールドをさらに含む、
   ことを特徴とする請求項２に記載のマルチメディアシステムにおける情報交換メカニズム。
5. 前記メッセージ内容種別識別フィールドに異なる値を割り振ることによって前記アップリンク状態またはダウンリンク状態をそれぞれ示す、
   ことを特徴とする請求項２に記載のマルチメディアシステムにおける情報交換メカニズム。
6. 前記メッセージ内容種別識別フィールドに０を割り振ることによって前記アップリンク状態を示し、１を割り振ることによって前記ダウンリンク状態を示す、
   ことを特徴とする請求項５に記載のマルチメディアシステムにおける情報交換メカニズム。
7. 前記メッセージ内容種別識別フィールドが前記アップリンク状態であると示された場合、前記メッセージは、
   該メッセージのアップリンクシリアル番号を示すメッセージアップリンクシリアル番号識別フィールドと、
   現在の交換がアップリンク状態であるバイトストリームを含むアップリンクバイトデータフィールドと、
   前記アップリンクバイトデータフィールドのフォーマットを示す内容フォーマットフィールドと、
   前記アップリンクバイトデータフィールドの長さを示す内容長フィールドと、
   を含む、ことを特徴とする請求項５に記載のマルチメディアシステムにおける情報交換メカニズム。
8. 前記メッセージ内容種別識別フィールドが前記ダウンリンク状態であると示された場合、前記メッセージは、
   該メッセージのダウンリンクシリアル番号を示すメッセージダウンリンクシリアル番号識別フィールドと、
   フィードバック状態フィールドを介して示されており、現在の交換がダウンリンク状態であるバイトストリームを含むダウンリンクバイトデータフィールドと、
   を含む、ことを特徴とする請求項５に記載のマルチメディアシステムにおける情報交換メカニズム。
9. シリアル番号識別を介して示されたダウンリンクシリアル番号とアップリンクシリアル番号とは互いに関連している、
   ことを特徴とする請求項５に記載のマルチメディアシステムにおける情報交換メカニズム。
10. 前記フィードバック状態フィールドは異なる値を割り振ることによって少なくとも３つのフィードバック状態に対応して示し、該フィードバック状態は、
    情報のアップリンク伝送に失敗し、少なくとも事前設定の時間内に受信が完了していない場合を含む第１フィードバック状態と、
    情報のアップリンク伝送に成功した第２フィードバック状態と、
    情報のアップリンク伝送に成功し、前記メッセージはダウンリンク中のバイトストリームを含む第３フィードバック状態と、
    を含む、ことを特徴とする請求項８に記載のマルチメディアシステムにおける情報交換メカニズム。
11. フィードバック状態フィールドは、前記第１フィードバック状態においては「０Ｘ００」に割り振られ、前記第２フィードバック状態においては「０Ｘ０１」に割り振られ、前記第３フィードバック状態においては「０Ｘ０２」に割り振られている、
    ことを特徴とする請求項１０に記載のマルチメディアシステムにおける情報交換メカニズム。
12. 前記フィードバック状態フィールドは、異なる値を割り振ることによって、少なくともＩＳＯ標準のための予備およびプライベートフィールドのための予備のうちいずれか１つまたは２つを含む予備フィードバック状態をさらに対応するように示す、
    ことを特徴とする請求項１０に記載のマルチメディアシステムにおける情報交換メカニズム。
13. 前記フィードバック状態フィールドはＩＳＯ標準のための予備のフィードバック状態においては「０Ｘ０２〜０Ｘ７Ｆ」に割り振られ、プライベートフィールドのための予備のフィードバック状態においては「０Ｘ８Ｆ〜０ＸＦＦ」に割り振られている、
    ことを特徴とする請求項１２に記載のマルチメディアシステムにおける情報交換メカニズム。
14. 前記第３フィードバック状態において、前記ダウンリンクバイトストリームは、
    現在の交換におけるダウンリンクバイトストリーム内容と、
    該ダウンリンクバイトストリームの内容フォーマットを示すフィールドと、
    該ダウンリンクバイトストリームの内容長を示すフィールドと、
    を含む、ことを特徴とする請求項１０に記載のマルチメディアシステムにおける情報交換メカニズム。
15. 前記ペイロードデータフィールドは、
    メッセージ内容種別識別フィールドと、
    メッセージシリアル番号フィールドと、
    該メッセージに関連するメッセージを示すシリアル番号フィールドと、
    フィードバック状態を示すフィールドと、
    現在の交換情報のバイトデータフィールドと、
    前記バイトデータフィールドの内容フォーマットを示すフィールドと、
    前記バイトデータフィールドの内容長を示すフィールドと、
    を含む、ことを特徴とする請求項１に記載のマルチメディアシステムにおける情報交換メカニズム。
16. 前記メッセージは、
    占めるビット長が１６であり、フォーマットが符号なし整数であるメッセージ識別フィールドと、
    占めるビット長が８であり、フォーマットが符号なし整数であるメッセージバージョン番号フィールドと、
    占めるビット長が３２であり、フォーマットが符号なし整数であるメッセージ長識別フィールドと、
    占めるビット長が１であり、フォーマットがビット列であるメッセージ識別フィールドと、
    占めるビット長が７であり、フォーマットがビット列である予備フィールドと、
    占めるビット長が８であり、フォーマットが符号なし整数であるメッセージアップリンクシリアル番号識別フィールドと、
    占めるビット長が８であり、フォーマットが符号なし整数であるメッセージダウンリンクシリアル番号識別フィールドと、
    占めるビット長が１６であり、フォーマットが符号なし整数である内容長フィールドと、
    占めるビット長が８であり、フォーマットが符号なし整数であるメッセージダウンリンクシリアル番号識別フィールドと、
    占めるビット長が８であり、フォーマットが符号なし整数であるメッセージアップリンクシリアル番号識別フィールドと、
    を含み、
    第３フィードバック状態において、前記メッセージは、内容長フィールドが占めるビット長が１６であり、フォーマットが符号なしデータであるダウンリンクバイトストリームを含み、
    該ダウンリンクバイトストリームの内容を示し、占めるビット長が８の整数倍であり、フォーマットが符号なしデータである、
    ことを特徴とする請求項１に記載のマルチメディアシステムにおける情報交換メカニズム。
17. 前記予備フィールドに１１１１１１１を割り振ることを特徴とする請求項１６に記載のマルチメディアシステムにおける情報交換メカニズム。
18. 請求項１〜１７のいずれか一項に記載のマルチメディアシステムにおける情報交換メカニズムを採用するマルチメディアシステムにおける情報交換ネットワークの伝送方法であって、
    端末設備が、所定のメッセージフォーマットに従って、メッセージをデータパケットにパケット化するステップと、
    データパケットをネットワークサーバーに伝送するステップと、
    サーバーが、所定のメッセージフォーマットに従って、データパケットに対してペイロードデータを解析し、相応する処理およびレスポンスを行うステップと、
    を含み、
    サーバーから端末設備まで上記対応するステップを行う、
    ことを特徴とするマルチメディアシステムにおける情報交換ネットワークの伝送方法。
19. 所定のメッセージフォーマットは国際協定標準および／またはカスタム標準を含むことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
20. 前記端末設備が、所定のメッセージフォーマットに従って、メッセージをデータパケットにパケット化するステップは、
    端末設備が、メッセージの予めカスタマイズされたビットペイロードデータフィールドのフォーマットまたはカスタムのフォーマットに従って、アップリンクバイトストリームをパケット化するステップと、
    端末設備が、所定のメッセージフォーマットに従って、メッセージ全体をパケット化するステップと、
    を含む、ことを特徴とする要求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
21. ビットペイロードデータフィールドのフォーマットは、アップリンクバイトストリームデータおよびダウンリンクバイトストリームデータのフォーマットに基づくものである、ことを特徴とする請求項２０に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
22. ネットワーク端末設備が、選択したネットワーク通信プロトコルフォーマットに従って、メッセージ全体をパケット化しプロトコルパケット化を行うことをさらに含む、ことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
23. パケット化した後、
    端末設備が、プロトコルフォーマットの定義に従って、１つまたは複数のｐａｃｋｅｔデータパケットを生成することを含む、データパケットを生成するステップをさらに含む、ことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
24. サーバーが、受信したデータパケットを処理するステップは、
    サーバーが、１つまたは複数のクライアントにより提出されたｐａｃｋｅｔデータパケットを受信した後、データパケットプロトコルヘッダに従って、完全なプロトコルレベルのペイロードデータフィールドを解析することを含む、
    ことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
25. サーバーが、受信したデータパケットを処理するステップは、
    サーバーが、対応するネットワーク通信プロトコルフォーマットのペイロードフォーマットの定義に従って、完全なメッセージを解析することをさらに含む、
    ことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。
26. サーバーが、受信したデータパケットを解析するステップは、
    サーバーが、メッセージにおけるメッセージヘッダの定義に従って、メッセージのビットペイロードデータフィールドに含まれるデータを解析することと、
    サーバーが、メッセージの定義またはカスタムしたフォーマットに従って、ビットペイロードデータフィールドに含まれるデータを解析することと、
    を含む、ことを特徴とする請求項１８に記載のマルチメディアシステムにおける情報交換ネットワークの伝送方法。