JP4280737B2

JP4280737B2 - ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいてｇｅｔ＿Ｄａｔａオペレーションを用いた要求フィールドの提供方法

Info

Publication number: JP4280737B2
Application number: JP2005259706A
Authority: JP
Inventors: 鐘説李; 錫弼李; 泰範林; 慶老尹
Original assignee: Korea Electronics Technology Institute
Current assignee: Korea Electronics Technology Institute
Priority date: 2004-09-17
Filing date: 2005-09-07
Publication date: 2009-06-17
Anticipated expiration: 2025-09-07
Also published as: US7917529B2; EP1638336A1; US8060526B2; US20110125785A1; US20060074848A1; US20110119301A1; JP2006085698A; US8055676B2

Description

本発明は、ＴＶ−Ａｎｙｔｉｍｅサービスに関するものであって、特にＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいてget_Dataオペレーションを用いた要求フィールドの提供方法に関するものである。

最近、デジタル放送サービスの本格化にしたがって、多チャンネル・多媒体環境において、注文型放送サービスを提供するための技術に関する研究が盛んに進められている。一例として、民間国際標準であるＴＶ−Ａｎｙｔｉｍｅは、コンテンツの記述（description）情報を表現するメタデータに基づいて、ユーザが自身の嗜好（preference）情報と前記メタデータとをマッチングすることにより、所望するコンテンツを格納して、自由な時間に視聴可能にするエニタイム（anytime）サービスを提供するための標準規格である。

メタデータは、上述のようにコンテンツに関する記述情報として、ＴＶ−Ａｎｙｔｉｍｅでは、ＭＰＥＧ−７で規定された内容に基づく（content−based）記述及びＥＰＧ（電子プログラムガイド）情報を含み、ユーザが所望するコンテンツを容易に探索・選択可能にする。メタデータ標準は、２つのパートから構成され、パートＡは、メタデータを記述するためのフォーマット、すなわち、スキーマを定義したものであって、ＸＭＬ（eXtensible Markup Language）基盤のＭＰＥＧ−７ＤＤＬ（Description Definition Language）（ISO/IEC 15938−2）を活用する。また、パートＢは、メタデータの伝送に関するものであって、二進フォーマット［ＭＰＥＧ−７ＢｉＭ（Binary Format for MPEG-7）］（ISO/IEC 15938-1）、断片化（fragmentation）、カプセル化（encapsulation）、及び索引（indexing）技法を含んでいる。

図１は、ＴＶ−Ａｎｙｔｉｍｅメタデータの構成を示すものであって、プログラム記述メタデータ（Program description Metadata）及びユーザ記述メタデータ（User description Metadata）を含み、プログラム記述メタデータは、コンテンツ記述メタデータ及びインスタンス（instance）記述メタデータから構成されている。一つのプログラムに対するメタデータは、ＣＲＩＤ（Content Reference Identifier）と呼ばれるコンテンツ参照識別子で相互に連関付けられる。

コンテンツ記述メタデータは、コンテンツ制作者によって生成され、プログラムタイトル、ジャンル、要約、批評家レビューなどを含む。インスタンス記述メタデータは、コンテンツ・プロバイダによって生成され、ロケーション（放送時間、チャンネル、ＵＲＬなど）、使用規則（usage rule）、伝送パラメータ（delivery parameter）などを含む。最後に、ユーザ記述メタデータは、ユーザ嗜好（User preference）、使用履歴（usage history）、個人ブックマーク（personal bookmark）などを含み、ユーザによって生成される。

ＴＶ−Ａｎｙｔｉｍｅ標準は、リターンパスを通じた双方向メタデータサービスのために、２つの類型のメタデータウェブサービスを定義しており、これは、well-defined behaviorと入出力セットに対するリモートプロシージャ（remote procedure）である。ＸＭＬ基盤のＷＳＤＬ（Web Service description Language，ウェブサービス記述言語）標準において、上述のリモートプロシージャは、ＳＯＡＰ（Simple Object Access Protocol）オペレーションの形態で定義されており、メタデータ検索のための‘get_Data’オペレーションと、ユーザ記述提出（User description submission）のための‘submit_Data’オペレーションとがある。なお、上述のＳＯＡＰプロトコルは、分散環境においてオブジェクトにアクセス可能とするＸＭＬ通信プロトコルである。

ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて用いられる要求（Request）／応答（Response）の類型は、‘urn：tva：transport：2002’のネームスペースに定義され、前記ネームスペースは、種々のメッセージに対する検証のためのツールとして提供される。メタデータ仕様とコンテンツ参照（Content referencing）標準で定義される類型（タイプ）は、伝送（transport）ネームスペースにおいて参照される。スキーマ断片（Schema fragment）は、上述のネームスペースで定義され、ネームスペース提供者は、スキーマ断片において’tns：’と定義される。完全なＸＭＬスキーマファイルは、tva_transport_types_v10.xsdである。

１．get_Dataオペレーション
get_Dataオペレーションは、クライアントがプログラムまたはプログラムグループに対して、ＴＶ−Ａｎｙｔｉｍｅデータをサーバから検索する機能を提供する。ＴＶ−Ａｎｙｔｉｍｅメタデータ提供者が、get_Dataオペレーションを用いて提供可能な機能を例示すると、以下のとおりである。
−ＣＲＩＤリストを用いてＣＲＩＤに対するコンテンツ参照データを返還すること。
−ＣＲＩＤリストを用いてＣＲＩＤに対するＴＶ−Ａｎｙｔｉｍｅメタデータを返還すること。
−特定のメタデータ属性（Attribute）（例えば、ジャンル、俳優など）に対する問合せを受信し、これに該当するプログラムを返還すること。
−特定の時間または特定のチャンネルに対する問合せに応答し、当該プログラムを返還すること。

get_Dataオペレーションの動作と関連して図２を参照すると、ＴＶ−Ａｎｙｔｉｍｅサービスにおいてクライアントは、インターネット網（IP Network）を通じて、get_DataオペレーションによるＳＯＡＰ要求メッセージ［get_Data() Request］をメタデータサービスサーバ（Metadata Service Server）に伝送する。このとき、get_Dataオペレーションは、原則として全ての問合せ類型を支援し、メタデータ制限条件に対して広範囲な問合せを提供する。続いて、メタデータサービスサーバは、ＳＯＡＰ応答メッセージ［get_Data() Request］によって、前記ＳＯＡＰ要求メッセージに対する問合せ結果値（すなわち検索結果）を返還する。

イ．要求フォーマット（Request Format）
図３に示すように、get_Dataオペレーションにおいて、要求フォーマットは、クライアントに３つの類型のパラメータを指定し、問合せ（検索）結果値として返還されるエレメント類型を要求テーブル（Requested Tables）類型に指定する。

図４は、問合せの結果、返還される要求テーブル類型を、ClassificationSchemeTable、ProgramInformationTable、GroupInformationTable、CreditsInformationTable、ProgramLocationTable、ServiceInformationTable、ProgramReviewTable、SegmentInformationTableなどと指定した例である。

ロ．応答フォーマット（Response Format）
get_Dataオペレーションの応答フォーマットは、図５に示すように、エレメント（TVAMain、ContentReferencingTable、InvalidFragments）に対して、０または１つ以上のＸＭＬインスタンスドキュメントを含み、要求フォーマットにおいて要請した要求テーブル類型に応じて問合せ結果値を返還する。

２．submit_Dataオペレーション
submit_Dataオペレーションによる伝送できるデータは、ＴＶ−ＡｎｙｔｉｍｅのＰｈａｓｅＩの技術標準では、使用（usage）サービスとコンテンツに基づいたインテリジェントエージェントまたは手動書込によって生成される匿名のプロファイルデータのセットで定義されたデータに制限している。ＴＶ−Ａｎｙｔｉｍｅフォーラムは、全てのユーザと提供者の基本権利を尊重して含み、これはコンテンツユーザのプライバシー基本権利と、コンテンツ制作者、プロバイダ、サービス提供者等のような全ての参加者の適法な権利とを含んでいる。

３．ユーザ情報を用いたget_Dataオペレーション
現在、ＴＶ−Ａｎｙｔｉｍｅでは、submit_Dataを通じて伝送されたユーザメタデータに基づいて、サービスエージェントでは、エージェント毎に特殊なアルゴリズムを通じてget_Dataオペレーションを行い、当該結果をユーザに伝送する。

上述のように、現在、ＴＶ−Ａｎｙｔｉｍｅで定義しているget_Dataオペレーションは、検索を通じて所望するテーブルまたはＴＶＡＭａｉｎなどの結果を返還する。すなわち、get_Dataオペレーションの検索結果は、‘TVAMain’または‘ProgramInformationTable’、‘GroupInformationTable’、‘ProgramLocationTable’、‘ServiceInformationTable’、‘CreditsInformationTable’、‘ProgramReviewTable’、‘SegmentInformatinTable’などのようなテーブル単位で伝送される。

一方、セットトップボックス（Set Top Box）は、双方向環境においてget_Dataオペレーションを通じてコンテンツを検索し、当該メタデータが提供される。しかし、セットトップボックスがホームサーバとして発達するに従い、セットトップボックスが家庭内においてメタデータサービスエージェント機能を行うことができ、ポータブルメディアプレーヤのように制限された資源を用いる端末では、既存のテーブル単位のメタデータの提供を受けることが相当の資源浪費をもたらす恐れがある。

例えば、ポータブルメディアプレーヤにおいてユーザ環境として提供するメタデータが、タイトル、ジャンル、ロケーション情報、レビュー情報であると仮定するとき、既存のget_Dataオペレーションを通じて問合せする場合は、要求テーブル値として、ProgramInformationTable、ProgramLocationTable、ProgramReviewTableを要請し、当該エレメント値または属性値をパーシング(parsing)してユーザインタフェース（ＵＩ）に表示する。従って、各テーブルの不要なメタデータにより、これを伝送するネットワーク資源の浪費と、ポータブルメディアプレーヤのパーシング作業による資源の浪費が誘発される。

また、従来のget_Dataオペレーションのテーブル単位の検索は、クライアントがテーブル全体のメタデータを必要としない場合、不要なメタデータの伝送及びクライアントの再パーシングにより、資源浪費を発生する問題がある。

本発明は、上述した問題点を解決するため、個人化サービスを提供しようと、修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にし、クライアントが所望するメタデータを選別的に返還できるようにすることを課題とする。

本発明の第１側面によると、ＳＯＡＰ問合せオペレーションを用いたＴＶ−Ａｎｙｔｉｍｅメタデータサービス方法が提供され、（ａ）前記ＳＯＡＰ問合せオペレーションにおいて、問合せ結果値の類型にメタデータテーブルのフィールドを指定することのできる要求フィールド類型（RequestedFieldsType）を追加するステップと、（ｂ）前記ＳＯＡＰ問合せオペレーションの要求メッセージを受信するステップと、（ｃ）前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型エレメントを含む場合、前記要求メッセージの要求フィールド類型エレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記ＳＯＡＰオペレーションの応答メッセージにより伝送するステップとを含む。

このとき、前記ＳＯＡＰオペレーションは、get_Dataオペレーションである場合もあり、前記ステップ（ａ）において追加される要求フィールド類型エレメントは、メタデータテーブルのフィールドＩＤ（ｆｉｅｌｄＩＤ）を指定する要求フィールドサブエレメントと、前記フィールドＩＤに対する経路（Ｘｐａｔｈ）を指定する要求経路サブエレメントとを含むこともできる。

また、前記ステップ（ｃ）は、前記問合せ結果値に同一のフィールドＩＤを有する重複データが存在する場合、前記問合せ結果値から重複データを排除することもでき、前記メタデータは、プログラム記述メタデータである場合もある。

また、本発明の第２側面によると、ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索のための方法が提供され、（ｄ）get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメントに、前記テーブルのフィールドを指定する要求フィールドエレメントをサブエレメントとして追加するステップと、（ｅ）前記get_Dataオペレーションの要求メッセージを受信するステップと、（ｆ）前記要求メッセージの受信に応え、前記要求テーブルエレメントで指定されたテーブルから、前記要求フィールドエレメントに指定されたフィールドを問合せ結果値として抽出するステップと、（ｇ）前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップとを含む。

本発明の第１側面によると、get_Dataオペレーションにおけるフィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる。すなわち、メタデータサービスのクライアントは、テーブル単位および／またはテーブルのフィールド単位でメタデータ問合せ結果を受信することができ、これによって、ユーザが所望のメタデータのみを選別的に受信することができるので、メタデータの伝送及びクライアントの再パーシング負荷を顕著に減少させることができる。また、本発明は、通常のセットトップボックス環境でも、上述した長所を具現することができ、ポータブルメディアプレーヤのようにプロセシング資源が限定されているクライアント環境においてさらに有利に用いられる。

一方、本発明の第１の側面において、クライアントが要求するフィールド単位でメタデータを加工するためには、サーバ側で追加的なプロセシングが必要な場合もあるが、サービスエージェントは、クライアント環境と比べて、大容量環境であることを鑑みると、本発明によってクライアントのプロセシング時間をより顕著に減少させることができる。

また、本発明の第２側面によると、要求テーブルのサブエレメントとして要求フィールド類型のエレメントが追加されることにより、get_Dataオペレーションを変更しなくても、特定のフィールドのＩＤを属性として有する単位要求フィールドエレメントを指定することができる。これによって、クライアントは、要求テーブルのフィールド単位で返還結果値を要求し、自身が所望するメタデータを選別的に返還することができるという長所がある。

以下、添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。

図６は、本発明の第１の実施形態として、修正された（modified）get_Dataオペレーションにおいて、特定のエレメントまたは属性単位の問合せ結果を要求するための要求フィールド類型を定義したものである。

図６において、要求フィールド類型は、要求フィールドエレメントと要求経路エレメント（RequestedXpath）の２つのエレメントを、サブエレメントとして追加することもでき、前記各エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’と指定され、０個以上無限大の要求フィールドエレメントと要求経路エレメントに対する問合せが可能である。

要求フィールドエレメントは、整列基準（Sort Criteria）をサブエレメントとして有する。整列基準は、問合せの結果に対する整列基準を示し、既存の整列方法に従い、フィールドＩＤを属性として有する。フィールドＩＤの値は、問合せ結果として受け取ろうとするフィールドＩＤとなり、現在、ＴＶ−Ａｎｙｔｉｍｅで定義したfield ID Typeを使用する。

要求フィールドエレメントを用いて問合せするときに、問題が発生することもあるが、これは一つのフィールドＩＤにいくつかの経路が存在することがありえるためである。上述の場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したりまたは重複を排除することができ、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドＩＤの伝送は、サービス提供者の方策に従うことになる。

前記サービス提供者の方策による曖昧さを防止するために、ユーザは、要求経路エレメントを用いて問合せを要求することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有するので、経路の属性値（類型）として問合せするための値を設定することができる。

図７は、上述した要求フィールド類型を用いるために修正されたget_Dataオペレーションの要求フォーマットを示している。

図７を参照すると、要求テーブルエレメントの次に要求フィールドエレメントが追加されている。要求フィールドエレメントは、図６の要求フィールド類型を用い、上述した要求フィールドエレメントと要求経路エレメントを用いることができる。

次に、上述したget_Dataオペレーションを用いて問合せを行うインスタンスの例について説明する。図８に示すように、ユーザ（またはクライアント）は、要求フィールドエレメントにおいて、フィールドＩＤが‘tvaf:ServiceURL’であり、その値は‘tv://7’または‘tv://9’である部分を要求（問合せ）している。また、問合せ結果値の類型として、要求テーブルエレメントを‘Program Location Table’と指定し、要求フィールドエレメントのフィールドＩＤを‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、‘tvaf:PublishedStart’、‘tvaf:PublishedDuration’と指定しており、要求経路エレメントを‘/TVAMain/ProgramDescription/ProgramReview Table/Review/FreeText Review/text()’と指定している。

図９は、図８の問合せインスタンスに対する応答インスタンスを例示しており、図８の検索条件によって、Program Information TableにおいてフィールドＩＤが‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、’tvaf:PublishedStart’、‘tvaf:PublishedDuration’であり、要求経路エレメントが‘/TVAMain/ProgramDescription/ProgramReviewTable/Review/FreeText Review/text()’である検索結果値を抽出して返還している。

get_Dataオペレーションの動作と関連して、図１０を参照すると、ＴＶ−Ａｎｙｔｉｍｅサービスにおいて、クライアントはインターネット網などを通じてget_DataオペレーションによるＳＯＡＰ要求メッセージ［get_Data() Request］をメタデータサービスサーバに伝送する。続いて、メタデータサービスサーバは、ＳＯＡＰ応答メッセージ［get_Data() Request］により前記ＳＯＡＰ要求メッセージに対する問合せ結果値を返還する。

図１１は、本発明の第２実施形態として、特定のエレメント及び属性値を指定するための要求フィールド類型の定義を示している。

図示のように、要求フィールド類型は、単位要求フィールドと要求経路からなる２つのエレメントを含み、このような要求フィールド類型が、要求テーブル類型のサブエレメントとして追加されることもある。

上述した単位要求フィールド及び要求経路エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’としておのおの設定されるので、０個以上無限大の単位要求フィールドと要求経路に対する問合せが可能である。

単位要求フィールドは、整列基準をサブエレメントとして有する。整列基準は、問合せ結果に対する整列基準を示し、これは、従来の整列方法による。また、単位要求フィールドは、フィールドＩＤを属性として指定し、このフィールドＩＤの値が、問合せの結果として受け取ろうとするフィールドＩＤになる。このようなフィールドＩＤは、現在、ＴＶ−Ａｎｙｔｉｍｅで定義したフィールドＩＤ類型を用いる。

一方、単位要求フィールドを用いて問合せする場合、１つのフィールドＩＤにいくつかの経路が存在する場合もあるので、問題が発生することもある。このような場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したり、または重複を排除することもでき、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドＩＤの伝送は、サービス提供者の方策による。

このとき、上述した要求経路を用いて問合せすると、サービス提供者の方策による曖昧さを防止することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有する。従って、経路の属性値（類型）で問合せするための値を設定することができる。

図１２は、上述した要求フィールド類型のエレメント、すなわち、要求フィールドエレメントがサブエレメントとして追加された要求テーブル類型の定義を図示したものであって、これによって、get_Dataオペレーションの問合せ結果として所望する要求テーブルのフィールド単位で返還値を要求することができる。

図示のように、要求フィールドエレメントは、要求テーブル類型のサブエレメントであって、１つの要求テーブルに対して０個以上無限大の要求フィールドエレメントに対する問合せが可能である。

図１３は、図１２によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。

図示のように、要求テーブルエレメントは、‘ProgramInformation Table’及び‘ProgramLocation Table’に対しておのおの要求フィールドエレメントを含んでいる。また、‘ProgramInformation Table’に対する要求フィールドエレメントは、フィールドＩＤが属性として与えられた２つの単位要求フィールドを含み、‘tvaf:CRID’及び‘tvaf:Genre’を返還値として要求している。また、‘ProgramLocation Table’の要求フィールドエレメントは、‘tvaf:ProgramURL’が属性として与えられた単位要求フィールドを含み、当該フィールドの返還を要求している。これによって、図１２の問合せを受信したサービスエージェントは、‘ProgramInformationTable’及び‘ProgramLocationTable’において、クライアントが要求したフィールドのみを選別的に検索してその結果を返還することができる。

図１４乃至図１６は、要求フィールド類型を変形したフィールドリスト類型（FieldList Type）と、これを用いる要求テーブル類型及びget_Dataオペレーションの変形例をそれぞれ示している。図示のように、要求フィールド類型は、フィールドリスト類型に当該エレメントの名称のみを変更して用いることができ、このとき、要求フィールド、要求経路エレメントは、IdentificationByFieldId、IdentificationByXPathに名称を変更して用いることができる。また、フィールドリスト類型として用いられる場合、要求フィールド類型の整列基準エレメントは不要である。

以上、本発明の望ましい実施形態について説明したが、これは例示のためのものであり、本発明の属する技術の分野における通常の知識を有する者であれば、本発明の思想を外れない範囲内で、種々の変形または修正が可能である。従って、本発明の保護範囲は、上述した実施形態に限定されるものではなく、特許請求の範囲によって定められるものである。

個人化サービスを提供しようと修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる方法に適用可能である。

ＴＶ−Ａｎｙｔｉｍｅメタデータの構成図である。 get_Dataオペレーションの一般的な動作概念図である。従来のget_Dataオペレーションの要求フォーマットを示す図である。従来のget_Dataオペレーションにおいて、問合せの結果返還される要求テーブル類型を指定した例示図である。従来のget_Dataオペレーションの応答フォーマットを示す図である。本発明の第１の実施形態によるget_Dataオペレーションにおいて、問合せ結果を要求するための要求フィールド類型を示す図である。本発明の第１の実施形態によるget_Dataオペレーションの要求フォーマットを示す図である。本発明の第１の実施形態によるget_Dataオペレーションの問合せインスタンスを示す図である。本発明の第１の実施形態によるget_Dataオペレーションの応答インスタンスの前段を示す図である。本発明の第１の実施形態によるget_Dataオペレーションの応答インスタンスの後段を示す図である。本発明の第１の実施形態によるget_Dataオペレーションの動作概念図である。本発明の第２の実施形態による要求フィールド類型を示す図である。本発明の第２の実施形態として、図１１の要求フィールド類型のエレメントが、サブエレメントとして追加された要求テーブル類型を示す図である。図１２によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。要求フィールド類型を変形したフィールドリスト類型の例示図である。図１４のフィールドリスト類型を用いる要求テーブル類型の例示図である。図１４のフィールドリスト類型を用いるget_Dataオペレーションの例示図である。

Claims

シンプル・オブジェクト・アクセス・プロトコル（以下、「ＳＯＡＰ」という。）問合せオペレーションを用いてＴＶ−Ａｎｙｔｉｍｅメタデータを提供する方法であって、
（ａ）前記ＳＯＡＰ問合せオペレーションにおいて、クライアントが、問合せ結果値の類型に、メタデータテーブルのフィールドＩＤを指定する要求フィールドサブエレメントと、前記フィールドＩＤに対する経路（Ｘｐａｔｈ）を指定する要求経路サブエレメントとを含む要求フィールド類型（RequestedFieldsType）を追加するステップと、
（ｂ）サービスエージェントが、前記ＳＯＡＰ問合せオペレーションの要求メッセージを受信するステップと、
（ｃ）前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型の前記各サブエレメントを含む場合において、前記サービスエージェントが、前記要求メッセージの要求フィールド類型の前記要求フィールドサブエレメント及び前記要求経路サブエレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記ＳＯＡＰオペレーションの応答メッセージにより伝送するステップと、
を含むことを特徴とする、ＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
前記ＳＯＡＰ問合せオペレーションは、get_Dataオペレーションであることを特徴とする、請求項１記載のＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
前記ステップ（ｃ）は、前記問合せ結果値に同一のフィールドＩＤを有する重複データが存在する場合、前記サービスエージェントが、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項１記載のＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
前記メタデータは、プログラム記述メタデータ（Program Description Metadata）であることを特徴とする、請求項１記載のＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
前記ステップ（ｃ）は、前記問合せ結果値に同一のフィールドＩＤを有する重複データが存在する場合、前記サービスエージェントが、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項４記載のＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索を提供する方法であって、
（ｄ）クライアントが、get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメント（RequestedTables）に、検索しようとするフィールドのフィールドＩＤを指定する単位要求フィールドエレメントと、検索しようとするフィールドに対する経路を指定する要求経路エレメント（RequestedXpath）とをサブエレメントとして含む要求フィールドエレメント（RequestedFields）をサブエレメントとして追加するステップと、
（ｅ）サービスエージェントが、前記get_Dataオペレーションの要求メッセージを受信するステップと、
（ｆ）前記サービスエージェントが、前記要求メッセージの受信に応えて、前記要求テーブルエレメントで指定されたテーブルから、前記単位要求フィールドエレメント及び前記要求経路エレメントで指定されたフィールドを問合せ結果値として抽出するステップと、
（ｇ）前記サービスエージェントが、前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップと、
を含むことを特徴とする、ＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。
前記ステップ（ｄ）は、前記クライアントが、検索しようとするフィールドのフィールドＩＤを、前記単位要求フィールドエレメントの属性として与えるものであることを特徴とする、請求項６記載のＴＶ−Ａｎｙｔｉｍｅメタデータの提供方法。