特表 2024-534296 リアルタイムデータ送受信方法及びその装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-20

(54)【発明の名称】リアルタイムデータ送受信方法及びその装置

(51)【国際特許分類】

   H04L 51/046 20220101AFI20240912BHJP

   H04L 51/08 20220101ALI20240912BHJP

   H04N 21/643 20110101ALI20240912BHJP

【ＦＩ】

H04L51/046

H04L51/08

H04N21/643

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023563839

(86)(22)【出願日】2023-02-09

(85)【翻訳文提出日】2023-10-17

(86)【国際出願番号】 KR2023001923

(87)【国際公開番号】W WO2024043420

(87)【国際公開日】2024-02-29

(31)【優先権主張番号】10-2022-0105640

(32)【優先日】2022-08-23

(33)【優先権主張国・地域又は機関】KR

(81)【指定国・地域】

(71)【出願人】

【識別番号】521442257

【氏名又は名称】チームグリット

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100111235

【弁理士】

【氏名又は名称】原 裕子

(74)【代理人】

【識別番号】100195257

【弁理士】

【氏名又は名称】大渕 一志

(72)【発明者】

【氏名】カン、 ソン イル

(72)【発明者】

【氏名】キム、 キ リョン

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164GA02

5C164TA08S

5C164TB11P

(57)【要約】

リアルタイムデータ送受信方法及びその装置が開示される。送信装置は、第１データメッセージのデータ形態情報を含む第１情報メッセージをテキスト基盤で伝送し、複数の第１データメッセージを連続して伝送する。第１データメッセージ及び第１情報メッセージは、少なくとも１以上のパケットによって構成され、アプリケーションにおいて区分自在である論理的送受信データ単位のメッセージである。

【特許請求の範囲】

【請求項1】

送信装置が遂行するリアルタイムデータ伝送方法であって、
第１データメッセージのデータ形態情報を含む第１情報メッセージをテキスト基盤に伝送する段階と、
複数の第１データメッセージを連続して伝送する段階と
を含み、
前記第１データメッセージ及び前記第１情報メッセージは、少なくとも１以上のパケットによって構成され、アプリケーションにおいて区分自在である論理的送受信データ単位のメッセージであることを特徴とする、リアルタイムデータ伝送方法。

【請求項2】

前記第１情報メッセージは、前記データ形態情報を、ＭＩＭＥ（Multipurpose Internet Mail Extensions）形式で定義することを特徴とする、請求項１に記載のリアルタイムデータ伝送方法。

【請求項3】

前記第１情報メッセージを伝送する段階は、
一定周期でもって繰り返して第１情報メッセージを伝送する段階を含むことを特徴とする、請求項１に記載のリアルタイムデータ伝送方法。

【請求項4】

新たなデータ形態情報を含む第２情報メッセージを伝送する段階と、
前記第２情報メッセージの伝送後、新たなデータ形態の第２データメッセージを伝送する段階と
をさらに含むことを特徴とする、請求項１に記載のリアルタイムデータ伝送方法。

【請求項5】

少なくとも１以上の受信子と、ウェブ基盤の伝送プロトコルとを利用して連結された状態をそのまま維持しながら、前記第１情報メッセージ、前記第１データメッセージ、前記第２情報メッセージ、前記第２データメッセージを伝送することを特徴とする、請求項４に記載のリアルタイムデータ伝送方法。

【請求項6】

受信装置が遂行するリアルタイムデータ受信方法であって、
テキスト基盤で伝送される第１情報メッセージを受信すれば、前記第１情報メッセージを介し、データ形態情報を把握する段階と、
前記データ形態情報を基に、前記第１情報メッセージの受信後に受信するデータメッセージを処理する段階と
を含むことを特徴とする、リアルタイムデータ受信方法。

【請求項7】

前記第１情報メッセージと異なる第２情報メッセージを受信すれば、前記第２情報メッセージ後に受信した第２データメッセージを、前記第２情報メッセージに含まれたデータ形態情報を利用して処理する段階をさらに含むことを特徴とする、請求項６に記載のリアルタイムデータ受信方法。

【請求項8】

前記第１情報メッセージは、前記データ形態情報を、ＭＩＭＥ（Multipurpose Internet Mail Extensions）形式で定義することを特徴とする、請求項６に記載のリアルタイムデータ伝送方法。

【請求項9】

請求項１に記載の方法を遂行するためのコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを送受信する方法及びその装置に係り、さらに詳細には、多様な形式のデータをリアルタイムで送受信する方法及びその装置に関する。

【背景技術】

【0002】

映像や音声のようなマルチメディアデータをリアルタイムで伝送するために使用する多様なプロトコルが存在する。例えば、ＣＣＴＶ（closed circuit television）で主に使用されるＲＴＳＰ（real-time streaming protocol）、ＴＶ会議で使用されるＷｅｂＲＴＣ（Web Real-Time Communication）、超低遅延放送のためのＳＲＴ（secure reliable transport）またはＲＩＳＴ（Reliable Internet Stream Transport）のような多様なプロトコルが存在する。従来の多様なプロトコルは、特定データ形式の伝送や、アプリケーションの伝送に適するように最適化されているので、１つのプロトコルでもって、さまざまな形式のデータを伝送することが容易ではない。

【0003】

さまざまな種類のプロトコルを混用して使用すれば、相互連動時、プロトコル変換、フォーマット変換、コーデック変換などによる処理負担が増大し、システムの要求性能が高くなるか、あるいは運用複雑性が増大するという短所がある。例えば、最近、リアルタイムプロトコルとして注目されているＷｅｂＲＴＣは、支援するコーデックが高仕様のものであるか、あるいはウェブ標準の特性上、無料で標準化されたコーデックにおいて、使用が制限されており、新たなコーデックをＷｅｂＲＴＣに逸早く適用して使用することができず、またＷｅｂＲＴＣは、伝送データを軽量化された形態に最適化させて使用することができないために、性能が低い低仕様ＩｏＴ機器に適用し難いという短所がある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明の実施形態がなそうとする技術的課題は、ハードウェアの仕様とその数とにかかわらず、多様な形式のデータをリアルタイムで伝送することができるリアルタイムデータ送受信方法及びその装置を提供するところにある。

【課題を解決するための手段】

【0005】

前述の技術的課題を達成するための、本発明の実施形態によるリアルタイムデータ伝送方法の一例は、送信装置が遂行するリアルタイムデータ伝送方法において、第１データメッセージのデータ形態情報を含む第１情報メッセージをテキスト基盤に伝送する段階と、複数の第１データメッセージを連続して伝送する段階と、を含み、前記第１データメッセージ及び前記第１情報メッセージは、少なくとも１以上のパケットによって構成され、アプリケーションにおいて区分自在である論理的送受信データ単位のメッセージである。

【0006】

前述の技術的課題を達成するための、本発明の実施形態によるリアルタイムデータ受信方法の一例は、受信装置が遂行するリアルタイムデータ受信方法において、テキスト基盤で伝送される第１情報メッセージを受信すれば、前記第１情報メッセージを介してデータ形態情報を把握する段階と、前記データ形態情報を基に、前記第１情報メッセージの受信後に受信するデータメッセージを処理する段階と、を含む。

【発明の効果】

【0007】

本発明の実施形態によれば、多様な形式のデータをリアルタイムで伝送することができる。他の実施形態として、新たなコーデックや、新たな伝送技法が導入されても、コーデック変換やフォーマット変換なしに、そのまま受容して伝送することができるので、コーデック変換やフォーマット変換などによる情報損失や処理遅延のような問題を最小化させながら、多様なプロトコルにおいて使用されるデータ形式を受容することができる。さらに他の実施形態として、新たなプロトコルを、ＡＰＩ（application programming interface）形態で多様に定義して使用することができ、新たなプロトコル受容に係わる拡張性にもすぐれるのである。

【図面の簡単な説明】

【0008】

【図1】本発明の実施形態によるデータ送受信装置の一例を図示した図である。

【図2】本発明の実施形態によるストリーミングデータの伝送方法の一例を図示した図である。

【図3】本発明の実施形態による情報メッセージの表示形式の一例を図示した図である。

【図4】本発明の実施形態による情報メッセージの表示形式の一例を図示した図である。

【図5】本発明の実施形態による多様な種類のストリーミングデータを伝送する方法の一例を図示した図である。

【図6】本発明の実施形態による情報メッセージを周期的に伝送する方法の一例を図示した図である。

【図7】本発明の実施形態による送信装置がリアルタイムでデータを送信する方法の一例を図示したフローチャートである。

【図8】本発明の実施形態による受信装置がリアルタイムでデータを受信する方法の一例を図示したフローチャートである。

【図9】本発明の実施形態によるストリーミングデータ処理のための状態遷移図の一例を図示した図である。

【発明を実施するための形態】

【0009】

以下において、添付図面を参照し、本発明の実施形態によるリアルタイムデータ送受信方法及びその装置について詳細に説明する。

【0010】

図１は、本発明の実施形態によるデータ送受信装置の一例を図示した図面である。

【0011】

図１を参照すれば、送信装置１００は、ストリーミングデータを伝送する主体であり、受信装置１１０は、ストリーミングデータを受信する主体である。送信装置１００及び受信装置１１０は、いずれもインターネット通信が可能な端末であり、一般コンピュータ、サーバ、スマートホンのような多様な種類でもある。例えば、送信装置１００は、放送や広告などのために、マルチメディアデータを送信する装置でもある。

【0012】

本実施形態は、説明の便宜のために、１つの受信装置１１０を図示しているが、複数の受信装置１１０が、送信装置１００に連結されうる。すなわち、送信装置１００は、複数の受信装置１１０にストリーミングデータを、ブロードキャスティングまたはマルチキャスティングのような多様な方法でもって伝送することができる。

【0013】

送信装置１００及び受信装置１１０は、ウェブ基盤の伝送プロトコルを利用し、ストリーミングデータを送受信することができる。例えば、送受信装置（送信装置１００及び受信装置１１０）は、ウェブトランスポート（WebTransport）やウェブソケット（Web Socket）などを利用し、ストリーミングデータを送受信することができる。

【0014】

ストリーミングデータは、送信装置１００がリアルタイムで伝送するデータである。該ストリーミングデータは、イメージデータ、ビデオデータ、オーディオデータ、テキストデータのように、その種類が多様でもあり、特定種類に限定されるものではない。受信装置１００は、ストリーミングデータを受信すれば、リアルタイムで再生することができる。

【0015】

ストリーミングデータは、多様なコーデックや、多様な圧縮形式のデータでもある。例えば、第１ビデオデータは、第１コーデックによって圧縮され、第２ビデオデータは、第２コーデックによって圧縮されうる。イメージデータ、オーディオデータ、テキストデータなども、その種類は、同一であっても、使用されるコーデックや圧縮方法などが、互いに異なりうる。

【0016】

従来には、データを伝送するとき、データの種類に合う最適プロトコルを使用した。例えば、送信装置がＣＣＴＶを伝送する場合には、ＲＴＳＰを使用し、ＴＶ会議動画を伝送する場合には、ＷｅｂＲＴＣなどを使用する。従って、従来には、送信装置が伝送するストリーミングデータの種類により、それぞれ互いに異なる伝送プロトコルを使用しなければならないという不都合が存在する。

【0017】

それにより、本実施形態は、送信装置１００と受信装置１１０とを、ウェブ基盤の伝送プロトコルで連結した後、多様な種類のストリーミングデータを伝送することができる方法を提示する。それについては、図２以下で具体的に説明する。

【0018】

図２は、本発明の実施形態によるストリーミングデータ伝送方法の一例を図示した図面である。

【0019】

図２を参照すれば、送信装置は、情報メッセージ２１０とデータメッセージ２２０とのフローを受信装置に伝送する。情報メッセージ２１０及びデータメッセージ２２０は、アプリケーションが区別することができる論理的送受信データ単位のメッセージであり、少なくとも１以上のパケットで構成される。該パケットは、ＴＣＰ（transmission control protocol）、ＵＤＰ（user datagram protocol）のような下位伝送層の送受信データ単位である。該パケットは、多様なコーデックや、多様な圧縮プロトコル（例えば、ＪＰＥＰなど）、または多様な伝送プロトコル（例えば、ＷｅｂＲＴＣ、ＲＴＳＰなど）の形式でもある。

【0020】

一実施形態として、情報メッセージ２１０とデータメッセージ２２０とを区分するためにデータメッセージ２２０は、バイナリ（binary）メッセージ形式を使用し、情報メッセージ２１０は、テキスト（text）メッセージ形式を使用することができる。他の実施形態として、下位伝送層のパケットに、２つのメッセージ（情報メッセージ２１０及びデータメッセージ２２０）を区分するための追加ヘッダやタイプを定義して使用することができる。以下においては、データメッセージ２２０は、バイナリメッセージ形式で伝送し、情報メッセージ２１０は、テキストメッセージ形式で伝送し、受信装置１１０が両メッセージを区分する場合を仮定して説明する。

【0021】

送信装置１００が伝送するストリーミングデータは、複数のデータメッセージ２２０単位で伝送される。情報メッセージ２１０は、データメッセージ２２０のデータ形態情報を含む。例えば、データメッセージ２２０が、ＶＰ８コーデックによって圧縮されたビデオデータである場合、情報メッセージ２１０は、データメッセージ２２０のデータ形態が「ビデオデータ」であり、コーデックが「ＶＰ８」であるという情報を含む。送信装置１００は、ストリーミングデータを構成するパケットのフォーマットを変更する必要なしに、ストリーミングデータのパケット自体をデータメッセージ単位で伝送すればよい。

【0022】

送信装置１００と受信装置１１０は、相互間において、いかなる種類のストリーミングデータを伝送するかということを事前に協議せず、送信装置１００が、一方的に多様な種類のストリーミングデータを伝送する。受信装置１１０が情報メッセージ２１０を容易に解釈することができるように、情報メッセージ２１０は、テキスト基盤で伝送される。情報メッセージ２１０をテキスト基盤に伝送する方法の例として、ＭＩＭＥ（Multipurpose Internet Mail Extensions）形式を使用することができる。それ以外にも、情報メッセージ２１０をテキスト基盤に伝送する多様な方法が、本実施形態に適用されうる。ただし、以下においては、説明の便宜のために、情報メッセージ２１０を、ＭＩＭＥ形式を利用して定義して伝送する場合を仮定して説明する。

【0023】

一実施形態として、送信装置１００は、ストリーミングデータを伝送するとき、新たな受信装置が、伝送中間からストリーミングデータを受信して再生することができるように情報メッセージ２１０を、一定周期で繰り返して伝送することができる。それについては、図６でさらに説明する。

【0024】

他の実施形態として、送信装置１００は、受信装置１１０と新たな連結を設定する必要なしに、連結をそのまま維持したまま、多様な種類のストリーミングデータをリアルタイムで伝送することができる。そのために、送信装置１００は、伝送するストリーミングデータの種類が変更されるたびに、情報メッセージ２１０を伝送することができる。それについては、図５でさらに説明する。

【0025】

図３及び図４は、本発明の実施形態による情報メッセージの表示形式の一例を図示した図面である。

【0026】

図３を参照すれば、情報メッセージ２１０は、ＭＩＭＥ形式を利用して伝送するデータメッセージ２２０のデータ形態情報を定義することができる。例えば、情報メッセージ２１０は、ストリーミングデータの種類及び形式や、コーデックのような情報を含むものでもある。例えば、ストリーミングデータがＪＰＥＧによって圧縮されたイメージデータであるならば、情報メッセージ２１０は、イメージデータを示す「image」と、該イメージの大きさ、及び圧縮コーデックがＪＰＥＧであることを示す情報と、を含むものでもある。情報メッセージ２１０は、テキスト形式によって定義されるので、オプションを拡張したり、データ形態（すなわち、新たなメディア）を新たに追加して定義したりして使用することができる。

【0027】

図４を参照すれば、情報メッセージ２１０は、ストリーミングデータを構成するパケットが、いかなるプロトコルの形式によるデータであるかといことを区分する情報を含むものでもある。例えば、図４において、ストリーミングデータがビデオデータ形態であるならば、情報メッセージには、「packet＝」オプションを使用し、ストリーミングデータを構成するパケット形式を定義することができる。該パケット形式において、ＲＴＰ（Real-Time Transport Protocol）、ＴＳ（transport stream）、ＧＤＰ（Gstreamer Data Protocol）、rawのような多様な形式が存在する。該情報メッセージは、ストリーミングデータのパケットがコーデック結果として出てきたデータであるならば、「packet＝ｃｏｄｅｃ」を含み、ストリーミングデータのパケットが、ＲＴＰ形式によるデータであるならば、「packet＝ｒｔｐ」を含むものでもある。「packet＝ｃｏｄｅｃ」のように、効率性のために、別途のヘッダを追加せず、圧縮コーデックなどによって生成されたパケット自体を即座に伝送することができる。すなわち、該ストリーミングデータが、多様なコーデックや、ＲＴＰ、ＲＴＣＰのような多様なプロトコルによって作られたデータである場合、該ストリーミングデータのパケット自体を変更する必要なしに、パケット自体を、図２の伝送方法を介し、そのまま伝送することができる。受信装置１１０は、情報メッセージ２１０を介し、ストリーミングデータが、ＲＴＰ、ＲＴＣＰのようなパケット形式であるか否かということを知ることができ、それを介し、受信されたデータメッセージを、当該プロトコルで処理して再生することができる。

【0028】

本実施形態は、ウェブ互換性と可読性とを考慮し、テキスト基盤のＭＩＭＥ形式の規則を利用するだけであるので、情報メッセージ２１０が、必ずしもＭＩＭＥと一致する必要がない。例えば、送信装置１００は、標準ＨＴＴＰＭＩＭＥ情報の形式によるものの、多様なストリーミングデータやパケット形式などをユーザが定義して使用することができるＡＰＩを提供することができる。

【0029】

本実施形態は、情報メッセージ２１０を利用し、多様な形態のストリーミングデータを伝送することができるので、多様なプロトコルのデータ形式を、内部的に受容することが可能であるので、互いに異なるプロトコルを連動させるとき、変換の負担なしに、効率性を失わず、利便性をもって使用することができる。また、もっとも複雑なＷｅｂＲＴＣ形式のデータから、最も簡単な形態のデータ形式のデータを伝送することができ、非常に幅広いストリーミングアプリケーションを支援することができる。すなわち、本実施形態のデータ送受信方法を適用し、低仕様のＩｏＴ機器でも、マルチメディアストリーミングを具現することができ、高仕様の機器においても、さらに最適化された伝送技法でもって、高品質の低遅延ストリーミングを具現することができる。

【0030】

図５は、本発明の実施形態による多様な種類のストリーミングデータを伝送する方法の一例を図示した図面である。

【0031】

図５を参照すれば、送信装置１００は、受信装置１１０と通信が連結された状態でもって、イメージデータ５１０、映像データ５１２、オーディオデータ５１４などを順次にリアルタイムに伝送することができる。送信装置１００は、受信装置１１０に伝送するストリーミングデータのデータ形態が何であるかということを知らせるために、ストリーミングデータを伝送する前、まず情報メッセージ（第１情報メッセージ５００、第２情報メッセージ５０２、第３情報メッセージ５０４）を伝送する。

【0032】

例えば、送信装置１００は、イメージデータ５１０を伝送する前、ストリーミングデータのデータ形態がイメージであるか否かということを示す第１情報メッセージ５００を伝送する。また、送信装置１００は、映像データ５１２を伝送する前、ストリーミングデータのデータ形態が映像であるか否かということを示す第２情報メッセージ５０２を伝送し、オーディオデータ５１４を伝送する前、ストリーミングデータのデータ形態がオーディオであるか否かということを示す第３情報メッセージ５０４を伝送する。従って、受信装置１１０は、第１情報メッセージ５００、第２情報メッセージ５０２及び第３情報メッセージ５０４を介して受信されるストリーミングデータがいかなる種類のデータであるかということを把握することができる。情報メッセージ（第１情報メッセージ５００、第２情報メッセージ５０２、第３情報メッセージ５０４）は、テキスト基盤で伝送されるので、受信装置１１０は、情報メッセージをそのまま読み取り、その内容を確認することができる。

【0033】

他の例として、送信装置１００は、第１データメッセージを伝送していて、若干の間、第２データメッセージを伝送し、再び第１データメッセージを続けて伝送することができる。そのために、送信装置１００は、第１データメッセージに係わる第１情報メッセージ、第２データメッセージに係わる第２情報メッセージ、さらに第１データメッセージに係わる第１情報メッセージを、それぞれのデータメッセージ伝送前に伝送することができる。

【0034】

図６は、本発明の実施形態による情報メッセージを周期的に伝送する方法の一例を図示した図面である。

【0035】

図６を参照すれば、送信装置１００は、１種類のストリーミングデータのデータメッセージ６１０，６１２，６１４を伝送しながら、周期的に、第１情報メッセージ６００を伝送することができる。第１情報メッセージ６００の繰り返し伝送周期は、アプリケーションなどによって多様に設定されうる。

【0036】

新たな第２受信装置（図示せず）は、ストリーミングデータの伝送中、送信装置１００に接続し、中間部分からストリーミングデータを受信することができる。しかしながら、第２受信装置（図示せず）は、中間部分から受信したデータメッセージがいかなる種類のストリーミングデータであるかということを知ることができず、それを再生することができない。第２受信装置（図示せず）は、ストリーミングデータの種類を把握するために、第１情報メッセージ６００を受信するまで待つ。例えば、第２受信装置（図示せず）は、２番目に伝送された第１情報メッセージ６００を受信すれば、ストリーミングデータのデータ形態を把握し、その次に受信するデータメッセージ６１４を、把握されたデータ形態によって処理して再生することができる。第２受信装置（図示せず）は、第１情報メッセージ６００の受信前に受信したデータメッセージは、いずれも廃棄するのである。

【0037】

図７は、本発明の実施形態による送信装置が、リアルタイムでデータを送信する方法の一例を図示したフローチャートである。

【0038】

図７を参照すれば、送信装置１００は、第１データメッセージのデータ形態情報を含む第１情報メッセージをテキスト基盤に伝送する（Ｓ７００）。送信装置１００は、第１情報メッセージの伝送後、複数の第１データメッセージを連続して伝送することができる（Ｓ７１０）。ここで、前記第１データメッセージ及び前記第１情報メッセージは、少なくとも１以上のパケットによって構成され、アプリケーションにおいて区分自在である論理的送受信データ単位のメッセージである。該第１情報メッセージは、ＭＩＭＥ形式に定義されており、その一例が、図３及び図４に図示されている。

【0039】

他の実施形態として、送信装置１００は、中間において、ストリーミングデータを受信する受信装置のために、一定周期でもって、第１情報メッセージを繰り返し伝送することができる。それに係わる例が、図６に図示されている。

【0040】

第１データメッセージのデータ形態と異なる第２データメッセージを伝送しようとするとき、送信装置１００は、第２データメッセージのデータ形態を示す第２情報メッセージを伝送する（Ｓ７２０）。送信装置１００は、第２情報メッセージ伝送後、第２データメッセージを伝送する（Ｓ７３０）。他の実施形態として、送信装置１００は、第２情報メッセージを一定周期でもって、繰り返して伝送することができる。

【0041】

送信装置１００と受信装置１１０は、ウェブ連結をそのまま維持したまま、互いに異なる種類のストリーミングデータをリアルタイムで送受信することができる。例えば、送信装置１００は、前述の第１情報メッセージ、少なくとも１以上の第１データメッセージ、第２情報メッセージ、少なくとも１以上の第２データメッセージを１つの連結を介し、順次に伝送することができる。

【0042】

図８は、本発明の実施形態による受信装置がリアルタイムでデータを受信する方法の一例を図示したフローチャートである。

【0043】

図８を参照すれば、受信装置１１０は、テキスト基盤で伝送される第１情報メッセージを受信すれば（Ｓ８００）、第１情報メッセージを介し、ストリーミングデータのデータ形態を把握する（Ｓ８１０）。受信装置１１０は、データ形態情報を基に、第１情報メッセージの受信後に受信するデータメッセージを処理して再生する（Ｓ８２０）。例えば、該ストリーミングデータが、特定コーデックやＲＴＰによって生成されたパケットを含む場合、受信装置１１０は、第１情報メッセージを基に、ストリーミングデータのパケットを、特定コーデックまたはＲＴＰなどによってデコーディングして解釈することができる。受信装置１１０は、ストリーミングデータ（例えば、ビデオ、オーディオなど）を、データ形態に合う各自の再生装置（ビデオ再生アプリケーション、オーディオ再生アプリケーションなど）に伝達して再生することができる。

【0044】

他の実施形態として、受信装置１１０は、送信装置１００が伝送するストリーミングデータを始めは受信せず、中間において送信装置１００に接続し、中間からストリーミングデータを受信することができる。そのとき、受信装置１１０は、第１情報メッセージを受信する前に受信した第１データメッセージを廃棄し、第１情報メッセージを受信した後で受信した第１データメッセージを処理して再生することができる。

【0045】

図９は、本発明の実施形態によるストリーミングデータ処理のための状態遷移図の一例を図示した図面である。

【0046】

図９を参照すれば、受信装置１１０は、初期状態（９００）において、情報メッセージを受信するために待機する。テキスト基盤の情報メッセージを受信すれば、受信装置１１０は、情報メッセージ解読状態（９１０）に遷移する。もし情報メッセージ解読にエラーがあれば、受信装置１１０は、さらに初期状態９００に戻り、新たな情報メッセージを受信するまで待機する。

【0047】

情報メッセージ解読が正常に完了すれば、受信装置１１０は、データメッセージの受信状態及び処理状態（９２０）に遷移する。データメッセージの受信中及び処理中に情報メッセージを受信すれば、受信装置１１０は、情報メッセージ解読状態（９１０）にさらに遷移する。解読にエラーが生ずれば、受信装置１１０は、新たな情報メッセージを受信するまで、初期状態９００で待機する。さらに、受信装置１１０は、データメッセージの受信状態及び処理状態（９２０）において、伝送エラーや伝送中断などが生ずれば、初期状態９００になり、情報メッセージ受信を待機する。

【0048】

本発明は、またコンピュータで読み取り可能な記録媒体に、コンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取られうるデータが保存される全種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ－ＲＯＭ、ＳＳＤ、光データ保存装置などがある。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータ読み取り可能なコードが保存されて実行されうる。

【0049】

以上、本発明につき、その望ましい実施形態を中心に説明した。本発明が属する技術分野において通常の知識を有する者であるならば、本発明が、本発明の本質的な特性からはずれない範囲において変形された形態に具現されうるということを理解することができるであろう。従って、開示された実施形態は、限定的な観点ではなく、説明的な観点から考慮されなければならない。本発明の範囲は、前述の説明ではなく、特許請求の範囲に示されており、それと同等な範囲内にある全ての違いは、本発明に含まれるものであると解釈されなければならないのである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】