TV−Anytimeメタデータサービスにおいてget_Dataオペレーションを用いた要求フィールドの提供方法
【課題】 本発明は、個人化サービスを提供するために修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にして、クライアントが所望のメタデータを選別的に返還することができる方法を提供する。
【解決手段】 TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルフィールドエレメントを提供する方法であって、(a)get_Dataオペレーションにおいて、問合せ結果値の類型に、メタデータテーブルのフィールドを指定可能な要求フィールド類型を追加するステップと、(b)get_Dataオペレーションの要求メッセージを受信するステップと、(c)前期要求メッセージが前記要求フィールド類型を含む場合、前記要求フィールド類型で指定されたテーブルフィールドに該当する問合せ結果値を抽出し、get_Dataオペレーションの応答メッセージにより伝送するステップとを含む。
【解決手段】 TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルフィールドエレメントを提供する方法であって、(a)get_Dataオペレーションにおいて、問合せ結果値の類型に、メタデータテーブルのフィールドを指定可能な要求フィールド類型を追加するステップと、(b)get_Dataオペレーションの要求メッセージを受信するステップと、(c)前期要求メッセージが前記要求フィールド類型を含む場合、前記要求フィールド類型で指定されたテーブルフィールドに該当する問合せ結果値を抽出し、get_Dataオペレーションの応答メッセージにより伝送するステップとを含む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、TV−Anytimeサービスに関するものであって、特にTV−Anytimeメタデータサービスにおいてget_Dataオペレーションを用いた要求フィールドの提供方法に関するものである。
【背景技術】
【0002】
最近、デジタル放送サービスの本格化にしたがって、多チャンネル・多媒体環境において、注文型放送サービスを提供するための技術に関する研究が盛んに進められている。一例として、民間国際標準であるTV−Anytimeは、コンテンツの記述(description)情報を表現するメタデータに基づいて、ユーザが自身の嗜好(preference)情報と前記メタデータとをマッチングすることにより、所望するコンテンツを格納して、自由な時間に視聴可能にするエニタイム(anytime)サービスを提供するための標準規格である。
【0003】
メタデータは、上述のようにコンテンツに関する記述情報として、TV−Anytimeでは、MPEG−7で規定された内容に基づく(content−based)記述及びEPG(電子プログラムガイド)情報を含み、ユーザが所望するコンテンツを容易に探索・選択可能にする。メタデータ標準は、2つのパートから構成され、パートAは、メタデータを記述するためのフォーマット、すなわち、スキーマを定義したものであって、XML(eXtensible Markup Language)基盤のMPEG−7 DDL(Description Definition Language)(ISO/IEC 15938−2)を活用する。また、パートBは、メタデータの伝送に関するものであって、二進フォーマット[MPEG−7BiM(Binary Format for MPEG-7)](ISO/IEC 15938-1)、断片化(fragmentation)、カプセル化(encapsulation)、及び索引(indexing)技法を含んでいる。
【0004】
図1は、TV−Anytimeメタデータの構成を示すものであって、プログラム記述メタデータ(Program description Metadata)及びユーザ記述メタデータ(User description Metadata)を含み、プログラム記述メタデータは、コンテンツ記述メタデータ及びインスタンス(instance)記述メタデータから構成されている。一つのプログラムに対するメタデータは、CRID(Content Reference Identifier)と呼ばれるコンテンツ参照識別子で相互に連関付けられる。
【0005】
コンテンツ記述メタデータは、コンテンツ制作者によって生成され、プログラムタイトル、ジャンル、要約、批評家レビューなどを含む。インスタンス記述メタデータは、コンテンツ・プロバイダによって生成され、ロケーション(放送時間、チャンネル、URLなど)、使用規則(usage rule)、伝送パラメータ(delivery parameter)などを含む。最後に、ユーザ記述メタデータは、ユーザ嗜好(User preference)、使用履歴(usage history)、個人ブックマーク(personal bookmark)などを含み、ユーザによって生成される。
【0006】
TV−Anytime標準は、リターンパスを通じた双方向メタデータサービスのために、2つの類型のメタデータウェブサービスを定義しており、これは、well-defined behaviorと入出力セットに対するリモートプロシージャ(remote procedure)である。XML基盤のWSDL(Web Service description Language,ウェブサービス記述言語)標準において、上述のリモートプロシージャは、SOAP(Simple Object Access Protocol)オペレーションの形態で定義されており、メタデータ検索のための‘get_Data’オペレーションと、ユーザ記述提出(User description submission)のための‘submit_Data’オペレーションとがある。なお、上述のSOAPプロトコルは、分散環境においてオブジェクトにアクセス可能とするXML通信プロトコルである。
【0007】
TV−Anytimeメタデータサービスにおいて用いられる要求(Request)/応答(Response)の類型は、‘urn:tva:transport:2002’のネームスペースに定義され、前記ネームスペースは、種々のメッセージに対する検証のためのツールとして提供される。メタデータ仕様とコンテンツ参照(Content referencing)標準で定義される類型(タイプ)は、伝送(transport)ネームスペースにおいて参照される。スキーマ断片(Schema fragment)は、上述のネームスペースで定義され、ネームスペース提供者は、スキーマ断片において’tns:’と定義される。完全なXMLスキーマファイルは、tva_transport_types_v10.xsdである。
【0008】
1.get_Dataオペレーション
get_Dataオペレーションは、クライアントがプログラムまたはプログラムグループに対して、TV−Anytimeデータをサーバから検索する機能を提供する。TV−Anytimeメタデータ提供者が、get_Dataオペレーションを用いて提供可能な機能を例示すると、以下のとおりである。
−CRIDリストを用いてCRIDに対するコンテンツ参照データを返還すること。
−CRIDリストを用いてCRIDに対するTV−Anytimeメタデータを返還すること。
−特定のメタデータ属性(Attribute)(例えば、ジャンル、俳優など)に対する問合せを受信し、これに該当するプログラムを返還すること。
−特定の時間または特定のチャンネルに対する問合せに応答し、当該プログラムを返還すること。
【0009】
get_Dataオペレーションの動作と関連して図2を参照すると、TV−Anytimeサービスにおいてクライアントは、インターネット網(IP Network)を通じて、get_DataオペレーションによるSOAP要求メッセージ[get_Data() Request]をメタデータサービスサーバ(Metadata Service Server)に伝送する。このとき、get_Dataオペレーションは、原則として全ての問合せ類型を支援し、メタデータ制限条件に対して広範囲な問合せを提供する。続いて、メタデータサービスサーバは、SOAP応答メッセージ[get_Data() Request]によって、前記SOAP要求メッセージに対する問合せ結果値(すなわち検索結果)を返還する。
【0010】
イ.要求フォーマット(Request Format)
図3に示すように、get_Dataオペレーションにおいて、要求フォーマットは、クライアントに3つの類型のパラメータを指定し、問合せ(検索)結果値として返還されるエレメント類型を要求テーブル(Requested Tables)類型に指定する。
【0011】
図4は、問合せの結果、返還される要求テーブル類型を、ClassificationSchemeTable、ProgramInformationTable、GroupInformationTable、CreditsInformationTable、ProgramLocationTable、ServiceInformationTable、ProgramReviewTable、SegmentInformationTableなどと指定した例である。
【0012】
ロ.応答フォーマット(Response Format)
get_Dataオペレーションの応答フォーマットは、図5に示すように、エレメント(TVAMain、ContentReferencingTable、InvalidFragments)に対して、0または1つ以上のXMLインスタンスドキュメントを含み、要求フォーマットにおいて要請した要求テーブル類型に応じて問合せ結果値を返還する。
【0013】
2.submit_Dataオペレーション
submit_Dataオペレーションによる伝送できるデータは、TV−AnytimeのPhaseIの技術標準では、使用(usage)サービスとコンテンツに基づいたインテリジェントエージェントまたは手動書込によって生成される匿名のプロファイルデータのセットで定義されたデータに制限している。TV−Anytimeフォーラムは、全てのユーザと提供者の基本権利を尊重して含み、これはコンテンツユーザのプライバシー基本権利と、コンテンツ制作者、プロバイダ、サービス提供者等のような全ての参加者の適法な権利とを含んでいる。
【0014】
3.ユーザ情報を用いたget_Dataオペレーション
現在、TV−Anytimeでは、submit_Dataを通じて伝送されたユーザメタデータに基づいて、サービスエージェントでは、エージェント毎に特殊なアルゴリズムを通じてget_Dataオペレーションを行い、当該結果をユーザに伝送する。
【0015】
上述のように、現在、TV−Anytimeで定義しているget_Dataオペレーションは、検索を通じて所望するテーブルまたはTVAMainなどの結果を返還する。すなわち、get_Dataオペレーションの検索結果は、‘TVAMain’または‘ProgramInformationTable’、‘GroupInformationTable’、‘ProgramLocationTable’、‘ServiceInformationTable’、‘CreditsInformationTable’、‘ProgramReviewTable’、‘SegmentInformatinTable’などのようなテーブル単位で伝送される。
【0016】
一方、セットトップボックス(Set Top Box)は、双方向環境においてget_Dataオペレーションを通じてコンテンツを検索し、当該メタデータが提供される。しかし、セットトップボックスがホームサーバとして発達するに従い、セットトップボックスが家庭内においてメタデータサービスエージェント機能を行うことができ、ポータブルメディアプレーヤのように制限された資源を用いる端末では、既存のテーブル単位のメタデータの提供を受けることが相当の資源浪費をもたらす恐れがある。
【0017】
例えば、ポータブルメディアプレーヤにおいてユーザ環境として提供するメタデータが、タイトル、ジャンル、ロケーション情報、レビュー情報であると仮定するとき、既存のget_Dataオペレーションを通じて問合せする場合は、要求テーブル値として、ProgramInformationTable、ProgramLocationTable、ProgramReviewTableを要請し、当該エレメント値または属性値をパーシング(parsing)してユーザインタフェース(UI)に表示する。従って、各テーブルの不要なメタデータにより、これを伝送するネットワーク資源の浪費と、ポータブルメディアプレーヤのパーシング作業による資源の浪費が誘発される。
【0018】
また、従来のget_Dataオペレーションのテーブル単位の検索は、クライアントがテーブル全体のメタデータを必要としない場合、不要なメタデータの伝送及びクライアントの再パーシングにより、資源浪費を発生する問題がある。
【発明の開示】
【発明が解決しようとする課題】
【0019】
本発明は、上述した問題点を解決するため、個人化サービスを提供しようと、修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にし、クライアントが所望するメタデータを選別的に返還できるようにすることを課題とする。
【課題を解決するための手段】
【0020】
本発明の第1側面によると、SOAP問合せオペレーションを用いたTV−Anytimeメタデータサービス方法が提供され、(a)前記SOAP問合せオペレーションにおいて、問合せ結果値の類型にメタデータテーブルのフィールドを指定することのできる要求フィールド類型(RequestedFieldsType)を追加するステップと、(b)前記SOAP問合せオペレーションの要求メッセージを受信するステップと、(c)前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型エレメントを含む場合、前記要求メッセージの要求フィールド類型エレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記SOAPオペレーションの応答メッセージにより伝送するステップとを含む。
【0021】
このとき、前記SOAPオペレーションは、get_Dataオペレーションである場合もあり、前記ステップ(a)において追加される要求フィールド類型エレメントは、メタデータテーブルのフィールドID(fieldID)を指定する要求フィールドサブエレメントと、前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントとを含むこともできる。
【0022】
また、前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除することもでき、前記メタデータは、プログラム記述メタデータである場合もある。
【0023】
また、本発明の第2側面によると、TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索のための方法が提供され、(d)get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメントに、前記テーブルのフィールドを指定する要求フィールドエレメントをサブエレメントとして追加するステップと、(e)前記get_Dataオペレーションの要求メッセージを受信するステップと、(f)前記要求メッセージの受信に応え、前記要求テーブルエレメントで指定されたテーブルから、前記要求フィールドエレメントに指定されたフィールドを問合せ結果値として抽出するステップと、(g)前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップとを含む。
【発明の効果】
【0024】
本発明の第1側面によると、get_Dataオペレーションにおけるフィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる。すなわち、メタデータサービスのクライアントは、テーブル単位および/またはテーブルのフィールド単位でメタデータ問合せ結果を受信することができ、これによって、ユーザが所望のメタデータのみを選別的に受信することができるので、メタデータの伝送及びクライアントの再パーシング負荷を顕著に減少させることができる。また、本発明は、通常のセットトップボックス環境でも、上述した長所を具現することができ、ポータブルメディアプレーヤのようにプロセシング資源が限定されているクライアント環境においてさらに有利に用いられる。
【0025】
一方、本発明の第1の側面において、クライアントが要求するフィールド単位でメタデータを加工するためには、サーバ側で追加的なプロセシングが必要な場合もあるが、サービスエージェントは、クライアント環境と比べて、大容量環境であることを鑑みると、本発明によってクライアントのプロセシング時間をより顕著に減少させることができる。
【0026】
また、本発明の第2側面によると、要求テーブルのサブエレメントとして要求フィールド類型のエレメントが追加されることにより、get_Dataオペレーションを変更しなくても、特定のフィールドのIDを属性として有する単位要求フィールドエレメントを指定することができる。これによって、クライアントは、要求テーブルのフィールド単位で返還結果値を要求し、自身が所望するメタデータを選別的に返還することができるという長所がある。
【発明を実施するための最良の形態】
【0027】
以下、添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。
【0028】
図6は、本発明の第1の実施形態として、修正された(modified)get_Dataオペレーションにおいて、特定のエレメントまたは属性単位の問合せ結果を要求するための要求フィールド類型を定義したものである。
【0029】
図6において、要求フィールド類型は、要求フィールドエレメントと要求経路エレメント(RequestedXpath)の2つのエレメントを、サブエレメントとして追加することもでき、前記各エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’と指定され、0個以上無限大の要求フィールドエレメントと要求経路エレメントに対する問合せが可能である。
【0030】
要求フィールドエレメントは、整列基準(Sort Criteria)をサブエレメントとして有する。整列基準は、問合せの結果に対する整列基準を示し、既存の整列方法に従い、フィールドIDを属性として有する。フィールドIDの値は、問合せ結果として受け取ろうとするフィールドIDとなり、現在、TV−Anytimeで定義したfield ID Typeを使用する。
【0031】
要求フィールドエレメントを用いて問合せするときに、問題が発生することもあるが、これは一つのフィールドIDにいくつかの経路が存在することがありえるためである。上述の場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したりまたは重複を排除することができ、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドIDの伝送は、サービス提供者の方策に従うことになる。
【0032】
前記サービス提供者の方策による曖昧さを防止するために、ユーザは、要求経路エレメントを用いて問合せを要求することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有するので、経路の属性値(類型)として問合せするための値を設定することができる。
【0033】
図7は、上述した要求フィールド類型を用いるために修正されたget_Dataオペレーションの要求フォーマットを示している。
【0034】
図7を参照すると、要求テーブルエレメントの次に要求フィールドエレメントが追加されている。要求フィールドエレメントは、図6の要求フィールド類型を用い、上述した要求フィールドエレメントと要求経路エレメントを用いることができる。
【0035】
次に、上述したget_Dataオペレーションを用いて問合せを行うインスタンスの例について説明する。図8に示すように、ユーザ(またはクライアント)は、要求フィールドエレメントにおいて、フィールドIDが‘tvaf:ServiceURL’であり、その値は‘tv://7’または‘tv://9’である部分を要求(問合せ)している。また、問合せ結果値の類型として、要求テーブルエレメントを‘Program Location Table’と指定し、要求フィールドエレメントのフィールドIDを‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、‘tvaf:PublishedStart’、‘tvaf:PublishedDuration’と指定しており、要求経路エレメントを‘/TVAMain/ProgramDescription/ProgramReview Table/Review/FreeText Review/text()’と指定している。
【0036】
図9は、図8の問合せインスタンスに対する応答インスタンスを例示しており、図8の検索条件によって、Program Information TableにおいてフィールドIDが‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、’tvaf:PublishedStart’、‘tvaf:PublishedDuration’であり、要求経路エレメントが‘/TVAMain/ProgramDescription/ProgramReviewTable/Review/FreeText Review/text()’である検索結果値を抽出して返還している。
【0037】
get_Dataオペレーションの動作と関連して、図10を参照すると、TV−Anytimeサービスにおいて、クライアントはインターネット網などを通じてget_DataオペレーションによるSOAP要求メッセージ[get_Data() Request]をメタデータサービスサーバに伝送する。続いて、メタデータサービスサーバは、SOAP応答メッセージ[get_Data() Request]により前記SOAP要求メッセージに対する問合せ結果値を返還する。
【0038】
図11は、本発明の第2実施形態として、特定のエレメント及び属性値を指定するための要求フィールド類型の定義を示している。
【0039】
図示のように、要求フィールド類型は、単位要求フィールドと要求経路からなる2つのエレメントを含み、このような要求フィールド類型が、要求テーブル類型のサブエレメントとして追加されることもある。
【0040】
上述した単位要求フィールド及び要求経路エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’としておのおの設定されるので、0個以上無限大の単位要求フィールドと要求経路に対する問合せが可能である。
【0041】
単位要求フィールドは、整列基準をサブエレメントとして有する。整列基準は、問合せ結果に対する整列基準を示し、これは、従来の整列方法による。また、単位要求フィールドは、フィールドIDを属性として指定し、このフィールドIDの値が、問合せの結果として受け取ろうとするフィールドIDになる。このようなフィールドIDは、現在、TV−Anytimeで定義したフィールドID類型を用いる。
【0042】
一方、単位要求フィールドを用いて問合せする場合、1つのフィールドIDにいくつかの経路が存在する場合もあるので、問題が発生することもある。このような場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したり、または重複を排除することもでき、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドIDの伝送は、サービス提供者の方策による。
【0043】
このとき、上述した要求経路を用いて問合せすると、サービス提供者の方策による曖昧さを防止することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有する。従って、経路の属性値(類型)で問合せするための値を設定することができる。
【0044】
図12は、上述した要求フィールド類型のエレメント、すなわち、要求フィールドエレメントがサブエレメントとして追加された要求テーブル類型の定義を図示したものであって、これによって、get_Dataオペレーションの問合せ結果として所望する要求テーブルのフィールド単位で返還値を要求することができる。
【0045】
図示のように、要求フィールドエレメントは、要求テーブル類型のサブエレメントであって、1つの要求テーブルに対して0個以上無限大の要求フィールドエレメントに対する問合せが可能である。
【0046】
図13は、図12によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。
【0047】
図示のように、要求テーブルエレメントは、‘ProgramInformation Table’及び‘ProgramLocation Table’に対しておのおの要求フィールドエレメントを含んでいる。また、‘ProgramInformation Table’に対する要求フィールドエレメントは、フィールドIDが属性として与えられた2つの単位要求フィールドを含み、‘tvaf:CRID’及び‘tvaf:Genre’を返還値として要求している。また、‘ProgramLocation Table’の要求フィールドエレメントは、‘tvaf:ProgramURL’が属性として与えられた単位要求フィールドを含み、当該フィールドの返還を要求している。これによって、図12の問合せを受信したサービスエージェントは、‘ProgramInformationTable’及び‘ProgramLocationTable’において、クライアントが要求したフィールドのみを選別的に検索してその結果を返還することができる。
【0048】
図14乃至図16は、要求フィールド類型を変形したフィールドリスト類型(FieldList Type)と、これを用いる要求テーブル類型及びget_Dataオペレーションの変形例をそれぞれ示している。図示のように、要求フィールド類型は、フィールドリスト類型に当該エレメントの名称のみを変更して用いることができ、このとき、要求フィールド、要求経路エレメントは、IdentificationByFieldId、IdentificationByXPathに名称を変更して用いることができる。また、フィールドリスト類型として用いられる場合、要求フィールド類型の整列基準エレメントは不要である。
【0049】
以上、本発明の望ましい実施形態について説明したが、これは例示のためのものであり、本発明の属する技術の分野における通常の知識を有する者であれば、本発明の思想を外れない範囲内で、種々の変形または修正が可能である。従って、本発明の保護範囲は、上述した実施形態に限定されるものではなく、特許請求の範囲によって定められるものである。
【産業上の利用可能性】
【0050】
個人化サービスを提供しようと修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる方法に適用可能である。
【図面の簡単な説明】
【0051】
【図1】TV−Anytimeメタデータの構成図である。
【図2】get_Dataオペレーションの一般的な動作概念図である。
【図3】従来のget_Dataオペレーションの要求フォーマットを示す図である。
【図4】従来のget_Dataオペレーションにおいて、問合せの結果返還される要求テーブル類型を指定した例示図である。
【図5】従来のget_Dataオペレーションの応答フォーマットを示す図である。
【図6】本発明の第1の実施形態によるget_Dataオペレーションにおいて、問合せ結果を要求するための要求フィールド類型を示す図である。
【図7】本発明の第1の実施形態によるget_Dataオペレーションの要求フォーマットを示す図である。
【図8】本発明の第1の実施形態によるget_Dataオペレーションの問合せインスタンスを示す図である。
【図9a】本発明の第1の実施形態によるget_Dataオペレーションの応答インスタンスの前段を示す図である。
【図9b】本発明の第1の実施形態によるget_Dataオペレーションの応答インスタンスの後段を示す図である。
【図10】本発明の第1の実施形態によるget_Dataオペレーションの動作概念図である。
【図11】本発明の第2の実施形態による要求フィールド類型を示す図である。
【図12】本発明の第2の実施形態として、図11の要求フィールド類型のエレメントが、サブエレメントとして追加された要求テーブル類型を示す図である。
【図13】図12によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。
【図14】要求フィールド類型を変形したフィールドリスト類型の例示図である。
【図15】図14のフィールドリスト類型を用いる要求テーブル類型の例示図である。
【図16】図14のフィールドリスト類型を用いるget_Dataオペレーションの例示図である。
【技術分野】
【0001】
本発明は、TV−Anytimeサービスに関するものであって、特にTV−Anytimeメタデータサービスにおいてget_Dataオペレーションを用いた要求フィールドの提供方法に関するものである。
【背景技術】
【0002】
最近、デジタル放送サービスの本格化にしたがって、多チャンネル・多媒体環境において、注文型放送サービスを提供するための技術に関する研究が盛んに進められている。一例として、民間国際標準であるTV−Anytimeは、コンテンツの記述(description)情報を表現するメタデータに基づいて、ユーザが自身の嗜好(preference)情報と前記メタデータとをマッチングすることにより、所望するコンテンツを格納して、自由な時間に視聴可能にするエニタイム(anytime)サービスを提供するための標準規格である。
【0003】
メタデータは、上述のようにコンテンツに関する記述情報として、TV−Anytimeでは、MPEG−7で規定された内容に基づく(content−based)記述及びEPG(電子プログラムガイド)情報を含み、ユーザが所望するコンテンツを容易に探索・選択可能にする。メタデータ標準は、2つのパートから構成され、パートAは、メタデータを記述するためのフォーマット、すなわち、スキーマを定義したものであって、XML(eXtensible Markup Language)基盤のMPEG−7 DDL(Description Definition Language)(ISO/IEC 15938−2)を活用する。また、パートBは、メタデータの伝送に関するものであって、二進フォーマット[MPEG−7BiM(Binary Format for MPEG-7)](ISO/IEC 15938-1)、断片化(fragmentation)、カプセル化(encapsulation)、及び索引(indexing)技法を含んでいる。
【0004】
図1は、TV−Anytimeメタデータの構成を示すものであって、プログラム記述メタデータ(Program description Metadata)及びユーザ記述メタデータ(User description Metadata)を含み、プログラム記述メタデータは、コンテンツ記述メタデータ及びインスタンス(instance)記述メタデータから構成されている。一つのプログラムに対するメタデータは、CRID(Content Reference Identifier)と呼ばれるコンテンツ参照識別子で相互に連関付けられる。
【0005】
コンテンツ記述メタデータは、コンテンツ制作者によって生成され、プログラムタイトル、ジャンル、要約、批評家レビューなどを含む。インスタンス記述メタデータは、コンテンツ・プロバイダによって生成され、ロケーション(放送時間、チャンネル、URLなど)、使用規則(usage rule)、伝送パラメータ(delivery parameter)などを含む。最後に、ユーザ記述メタデータは、ユーザ嗜好(User preference)、使用履歴(usage history)、個人ブックマーク(personal bookmark)などを含み、ユーザによって生成される。
【0006】
TV−Anytime標準は、リターンパスを通じた双方向メタデータサービスのために、2つの類型のメタデータウェブサービスを定義しており、これは、well-defined behaviorと入出力セットに対するリモートプロシージャ(remote procedure)である。XML基盤のWSDL(Web Service description Language,ウェブサービス記述言語)標準において、上述のリモートプロシージャは、SOAP(Simple Object Access Protocol)オペレーションの形態で定義されており、メタデータ検索のための‘get_Data’オペレーションと、ユーザ記述提出(User description submission)のための‘submit_Data’オペレーションとがある。なお、上述のSOAPプロトコルは、分散環境においてオブジェクトにアクセス可能とするXML通信プロトコルである。
【0007】
TV−Anytimeメタデータサービスにおいて用いられる要求(Request)/応答(Response)の類型は、‘urn:tva:transport:2002’のネームスペースに定義され、前記ネームスペースは、種々のメッセージに対する検証のためのツールとして提供される。メタデータ仕様とコンテンツ参照(Content referencing)標準で定義される類型(タイプ)は、伝送(transport)ネームスペースにおいて参照される。スキーマ断片(Schema fragment)は、上述のネームスペースで定義され、ネームスペース提供者は、スキーマ断片において’tns:’と定義される。完全なXMLスキーマファイルは、tva_transport_types_v10.xsdである。
【0008】
1.get_Dataオペレーション
get_Dataオペレーションは、クライアントがプログラムまたはプログラムグループに対して、TV−Anytimeデータをサーバから検索する機能を提供する。TV−Anytimeメタデータ提供者が、get_Dataオペレーションを用いて提供可能な機能を例示すると、以下のとおりである。
−CRIDリストを用いてCRIDに対するコンテンツ参照データを返還すること。
−CRIDリストを用いてCRIDに対するTV−Anytimeメタデータを返還すること。
−特定のメタデータ属性(Attribute)(例えば、ジャンル、俳優など)に対する問合せを受信し、これに該当するプログラムを返還すること。
−特定の時間または特定のチャンネルに対する問合せに応答し、当該プログラムを返還すること。
【0009】
get_Dataオペレーションの動作と関連して図2を参照すると、TV−Anytimeサービスにおいてクライアントは、インターネット網(IP Network)を通じて、get_DataオペレーションによるSOAP要求メッセージ[get_Data() Request]をメタデータサービスサーバ(Metadata Service Server)に伝送する。このとき、get_Dataオペレーションは、原則として全ての問合せ類型を支援し、メタデータ制限条件に対して広範囲な問合せを提供する。続いて、メタデータサービスサーバは、SOAP応答メッセージ[get_Data() Request]によって、前記SOAP要求メッセージに対する問合せ結果値(すなわち検索結果)を返還する。
【0010】
イ.要求フォーマット(Request Format)
図3に示すように、get_Dataオペレーションにおいて、要求フォーマットは、クライアントに3つの類型のパラメータを指定し、問合せ(検索)結果値として返還されるエレメント類型を要求テーブル(Requested Tables)類型に指定する。
【0011】
図4は、問合せの結果、返還される要求テーブル類型を、ClassificationSchemeTable、ProgramInformationTable、GroupInformationTable、CreditsInformationTable、ProgramLocationTable、ServiceInformationTable、ProgramReviewTable、SegmentInformationTableなどと指定した例である。
【0012】
ロ.応答フォーマット(Response Format)
get_Dataオペレーションの応答フォーマットは、図5に示すように、エレメント(TVAMain、ContentReferencingTable、InvalidFragments)に対して、0または1つ以上のXMLインスタンスドキュメントを含み、要求フォーマットにおいて要請した要求テーブル類型に応じて問合せ結果値を返還する。
【0013】
2.submit_Dataオペレーション
submit_Dataオペレーションによる伝送できるデータは、TV−AnytimeのPhaseIの技術標準では、使用(usage)サービスとコンテンツに基づいたインテリジェントエージェントまたは手動書込によって生成される匿名のプロファイルデータのセットで定義されたデータに制限している。TV−Anytimeフォーラムは、全てのユーザと提供者の基本権利を尊重して含み、これはコンテンツユーザのプライバシー基本権利と、コンテンツ制作者、プロバイダ、サービス提供者等のような全ての参加者の適法な権利とを含んでいる。
【0014】
3.ユーザ情報を用いたget_Dataオペレーション
現在、TV−Anytimeでは、submit_Dataを通じて伝送されたユーザメタデータに基づいて、サービスエージェントでは、エージェント毎に特殊なアルゴリズムを通じてget_Dataオペレーションを行い、当該結果をユーザに伝送する。
【0015】
上述のように、現在、TV−Anytimeで定義しているget_Dataオペレーションは、検索を通じて所望するテーブルまたはTVAMainなどの結果を返還する。すなわち、get_Dataオペレーションの検索結果は、‘TVAMain’または‘ProgramInformationTable’、‘GroupInformationTable’、‘ProgramLocationTable’、‘ServiceInformationTable’、‘CreditsInformationTable’、‘ProgramReviewTable’、‘SegmentInformatinTable’などのようなテーブル単位で伝送される。
【0016】
一方、セットトップボックス(Set Top Box)は、双方向環境においてget_Dataオペレーションを通じてコンテンツを検索し、当該メタデータが提供される。しかし、セットトップボックスがホームサーバとして発達するに従い、セットトップボックスが家庭内においてメタデータサービスエージェント機能を行うことができ、ポータブルメディアプレーヤのように制限された資源を用いる端末では、既存のテーブル単位のメタデータの提供を受けることが相当の資源浪費をもたらす恐れがある。
【0017】
例えば、ポータブルメディアプレーヤにおいてユーザ環境として提供するメタデータが、タイトル、ジャンル、ロケーション情報、レビュー情報であると仮定するとき、既存のget_Dataオペレーションを通じて問合せする場合は、要求テーブル値として、ProgramInformationTable、ProgramLocationTable、ProgramReviewTableを要請し、当該エレメント値または属性値をパーシング(parsing)してユーザインタフェース(UI)に表示する。従って、各テーブルの不要なメタデータにより、これを伝送するネットワーク資源の浪費と、ポータブルメディアプレーヤのパーシング作業による資源の浪費が誘発される。
【0018】
また、従来のget_Dataオペレーションのテーブル単位の検索は、クライアントがテーブル全体のメタデータを必要としない場合、不要なメタデータの伝送及びクライアントの再パーシングにより、資源浪費を発生する問題がある。
【発明の開示】
【発明が解決しようとする課題】
【0019】
本発明は、上述した問題点を解決するため、個人化サービスを提供しようと、修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にし、クライアントが所望するメタデータを選別的に返還できるようにすることを課題とする。
【課題を解決するための手段】
【0020】
本発明の第1側面によると、SOAP問合せオペレーションを用いたTV−Anytimeメタデータサービス方法が提供され、(a)前記SOAP問合せオペレーションにおいて、問合せ結果値の類型にメタデータテーブルのフィールドを指定することのできる要求フィールド類型(RequestedFieldsType)を追加するステップと、(b)前記SOAP問合せオペレーションの要求メッセージを受信するステップと、(c)前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型エレメントを含む場合、前記要求メッセージの要求フィールド類型エレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記SOAPオペレーションの応答メッセージにより伝送するステップとを含む。
【0021】
このとき、前記SOAPオペレーションは、get_Dataオペレーションである場合もあり、前記ステップ(a)において追加される要求フィールド類型エレメントは、メタデータテーブルのフィールドID(fieldID)を指定する要求フィールドサブエレメントと、前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントとを含むこともできる。
【0022】
また、前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除することもでき、前記メタデータは、プログラム記述メタデータである場合もある。
【0023】
また、本発明の第2側面によると、TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索のための方法が提供され、(d)get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメントに、前記テーブルのフィールドを指定する要求フィールドエレメントをサブエレメントとして追加するステップと、(e)前記get_Dataオペレーションの要求メッセージを受信するステップと、(f)前記要求メッセージの受信に応え、前記要求テーブルエレメントで指定されたテーブルから、前記要求フィールドエレメントに指定されたフィールドを問合せ結果値として抽出するステップと、(g)前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップとを含む。
【発明の効果】
【0024】
本発明の第1側面によると、get_Dataオペレーションにおけるフィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる。すなわち、メタデータサービスのクライアントは、テーブル単位および/またはテーブルのフィールド単位でメタデータ問合せ結果を受信することができ、これによって、ユーザが所望のメタデータのみを選別的に受信することができるので、メタデータの伝送及びクライアントの再パーシング負荷を顕著に減少させることができる。また、本発明は、通常のセットトップボックス環境でも、上述した長所を具現することができ、ポータブルメディアプレーヤのようにプロセシング資源が限定されているクライアント環境においてさらに有利に用いられる。
【0025】
一方、本発明の第1の側面において、クライアントが要求するフィールド単位でメタデータを加工するためには、サーバ側で追加的なプロセシングが必要な場合もあるが、サービスエージェントは、クライアント環境と比べて、大容量環境であることを鑑みると、本発明によってクライアントのプロセシング時間をより顕著に減少させることができる。
【0026】
また、本発明の第2側面によると、要求テーブルのサブエレメントとして要求フィールド類型のエレメントが追加されることにより、get_Dataオペレーションを変更しなくても、特定のフィールドのIDを属性として有する単位要求フィールドエレメントを指定することができる。これによって、クライアントは、要求テーブルのフィールド単位で返還結果値を要求し、自身が所望するメタデータを選別的に返還することができるという長所がある。
【発明を実施するための最良の形態】
【0027】
以下、添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。
【0028】
図6は、本発明の第1の実施形態として、修正された(modified)get_Dataオペレーションにおいて、特定のエレメントまたは属性単位の問合せ結果を要求するための要求フィールド類型を定義したものである。
【0029】
図6において、要求フィールド類型は、要求フィールドエレメントと要求経路エレメント(RequestedXpath)の2つのエレメントを、サブエレメントとして追加することもでき、前記各エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’と指定され、0個以上無限大の要求フィールドエレメントと要求経路エレメントに対する問合せが可能である。
【0030】
要求フィールドエレメントは、整列基準(Sort Criteria)をサブエレメントとして有する。整列基準は、問合せの結果に対する整列基準を示し、既存の整列方法に従い、フィールドIDを属性として有する。フィールドIDの値は、問合せ結果として受け取ろうとするフィールドIDとなり、現在、TV−Anytimeで定義したfield ID Typeを使用する。
【0031】
要求フィールドエレメントを用いて問合せするときに、問題が発生することもあるが、これは一つのフィールドIDにいくつかの経路が存在することがありえるためである。上述の場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したりまたは重複を排除することができ、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドIDの伝送は、サービス提供者の方策に従うことになる。
【0032】
前記サービス提供者の方策による曖昧さを防止するために、ユーザは、要求経路エレメントを用いて問合せを要求することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有するので、経路の属性値(類型)として問合せするための値を設定することができる。
【0033】
図7は、上述した要求フィールド類型を用いるために修正されたget_Dataオペレーションの要求フォーマットを示している。
【0034】
図7を参照すると、要求テーブルエレメントの次に要求フィールドエレメントが追加されている。要求フィールドエレメントは、図6の要求フィールド類型を用い、上述した要求フィールドエレメントと要求経路エレメントを用いることができる。
【0035】
次に、上述したget_Dataオペレーションを用いて問合せを行うインスタンスの例について説明する。図8に示すように、ユーザ(またはクライアント)は、要求フィールドエレメントにおいて、フィールドIDが‘tvaf:ServiceURL’であり、その値は‘tv://7’または‘tv://9’である部分を要求(問合せ)している。また、問合せ結果値の類型として、要求テーブルエレメントを‘Program Location Table’と指定し、要求フィールドエレメントのフィールドIDを‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、‘tvaf:PublishedStart’、‘tvaf:PublishedDuration’と指定しており、要求経路エレメントを‘/TVAMain/ProgramDescription/ProgramReview Table/Review/FreeText Review/text()’と指定している。
【0036】
図9は、図8の問合せインスタンスに対する応答インスタンスを例示しており、図8の検索条件によって、Program Information TableにおいてフィールドIDが‘tvaf:CRID’、‘tvaf:Genre’、‘tvaf:Title’、‘tvaf:ProgramURL’、’tvaf:PublishedStart’、‘tvaf:PublishedDuration’であり、要求経路エレメントが‘/TVAMain/ProgramDescription/ProgramReviewTable/Review/FreeText Review/text()’である検索結果値を抽出して返還している。
【0037】
get_Dataオペレーションの動作と関連して、図10を参照すると、TV−Anytimeサービスにおいて、クライアントはインターネット網などを通じてget_DataオペレーションによるSOAP要求メッセージ[get_Data() Request]をメタデータサービスサーバに伝送する。続いて、メタデータサービスサーバは、SOAP応答メッセージ[get_Data() Request]により前記SOAP要求メッセージに対する問合せ結果値を返還する。
【0038】
図11は、本発明の第2実施形態として、特定のエレメント及び属性値を指定するための要求フィールド類型の定義を示している。
【0039】
図示のように、要求フィールド類型は、単位要求フィールドと要求経路からなる2つのエレメントを含み、このような要求フィールド類型が、要求テーブル類型のサブエレメントとして追加されることもある。
【0040】
上述した単位要求フィールド及び要求経路エレメントは、minOccurs=‘0’、maxOccurs=‘unbounded’としておのおの設定されるので、0個以上無限大の単位要求フィールドと要求経路に対する問合せが可能である。
【0041】
単位要求フィールドは、整列基準をサブエレメントとして有する。整列基準は、問合せ結果に対する整列基準を示し、これは、従来の整列方法による。また、単位要求フィールドは、フィールドIDを属性として指定し、このフィールドIDの値が、問合せの結果として受け取ろうとするフィールドIDになる。このようなフィールドIDは、現在、TV−Anytimeで定義したフィールドID類型を用いる。
【0042】
一方、単位要求フィールドを用いて問合せする場合、1つのフィールドIDにいくつかの経路が存在する場合もあるので、問題が発生することもある。このような場合、メタデータサーバのサービスエージェントは、重複するデータを全て伝送したり、または重複を排除することもでき、同一のTVAMainインスタンスの場合、自体的な方策によって選択的に伝送することができる。このような重複フィールドIDの伝送は、サービス提供者の方策による。
【0043】
このとき、上述した要求経路を用いて問合せすると、サービス提供者の方策による曖昧さを防止することができる。すなわち、要求経路エレメントは、経路の文法により要求しようとするフィールドの明確な経路を指定することができる。要求経路エレメントは、上述の要求フィールドエレメントと同様に、整列基準をサブエレメントとして有し、経路を属性として有する。従って、経路の属性値(類型)で問合せするための値を設定することができる。
【0044】
図12は、上述した要求フィールド類型のエレメント、すなわち、要求フィールドエレメントがサブエレメントとして追加された要求テーブル類型の定義を図示したものであって、これによって、get_Dataオペレーションの問合せ結果として所望する要求テーブルのフィールド単位で返還値を要求することができる。
【0045】
図示のように、要求フィールドエレメントは、要求テーブル類型のサブエレメントであって、1つの要求テーブルに対して0個以上無限大の要求フィールドエレメントに対する問合せが可能である。
【0046】
図13は、図12によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。
【0047】
図示のように、要求テーブルエレメントは、‘ProgramInformation Table’及び‘ProgramLocation Table’に対しておのおの要求フィールドエレメントを含んでいる。また、‘ProgramInformation Table’に対する要求フィールドエレメントは、フィールドIDが属性として与えられた2つの単位要求フィールドを含み、‘tvaf:CRID’及び‘tvaf:Genre’を返還値として要求している。また、‘ProgramLocation Table’の要求フィールドエレメントは、‘tvaf:ProgramURL’が属性として与えられた単位要求フィールドを含み、当該フィールドの返還を要求している。これによって、図12の問合せを受信したサービスエージェントは、‘ProgramInformationTable’及び‘ProgramLocationTable’において、クライアントが要求したフィールドのみを選別的に検索してその結果を返還することができる。
【0048】
図14乃至図16は、要求フィールド類型を変形したフィールドリスト類型(FieldList Type)と、これを用いる要求テーブル類型及びget_Dataオペレーションの変形例をそれぞれ示している。図示のように、要求フィールド類型は、フィールドリスト類型に当該エレメントの名称のみを変更して用いることができ、このとき、要求フィールド、要求経路エレメントは、IdentificationByFieldId、IdentificationByXPathに名称を変更して用いることができる。また、フィールドリスト類型として用いられる場合、要求フィールド類型の整列基準エレメントは不要である。
【0049】
以上、本発明の望ましい実施形態について説明したが、これは例示のためのものであり、本発明の属する技術の分野における通常の知識を有する者であれば、本発明の思想を外れない範囲内で、種々の変形または修正が可能である。従って、本発明の保護範囲は、上述した実施形態に限定されるものではなく、特許請求の範囲によって定められるものである。
【産業上の利用可能性】
【0050】
個人化サービスを提供しようと修正されたget_Dataオペレーションにおいて、フィールド単位の返還結果値を要求可能にして、クライアントが所望するメタデータを選別的に返還することができる方法に適用可能である。
【図面の簡単な説明】
【0051】
【図1】TV−Anytimeメタデータの構成図である。
【図2】get_Dataオペレーションの一般的な動作概念図である。
【図3】従来のget_Dataオペレーションの要求フォーマットを示す図である。
【図4】従来のget_Dataオペレーションにおいて、問合せの結果返還される要求テーブル類型を指定した例示図である。
【図5】従来のget_Dataオペレーションの応答フォーマットを示す図である。
【図6】本発明の第1の実施形態によるget_Dataオペレーションにおいて、問合せ結果を要求するための要求フィールド類型を示す図である。
【図7】本発明の第1の実施形態によるget_Dataオペレーションの要求フォーマットを示す図である。
【図8】本発明の第1の実施形態によるget_Dataオペレーションの問合せインスタンスを示す図である。
【図9a】本発明の第1の実施形態によるget_Dataオペレーションの応答インスタンスの前段を示す図である。
【図9b】本発明の第1の実施形態によるget_Dataオペレーションの応答インスタンスの後段を示す図である。
【図10】本発明の第1の実施形態によるget_Dataオペレーションの動作概念図である。
【図11】本発明の第2の実施形態による要求フィールド類型を示す図である。
【図12】本発明の第2の実施形態として、図11の要求フィールド類型のエレメントが、サブエレメントとして追加された要求テーブル類型を示す図である。
【図13】図12によって定義された要求テーブル類型の要求テーブルエレメントを返還値として要求するget_Dataオペレーションのインスタンスの例示図である。
【図14】要求フィールド類型を変形したフィールドリスト類型の例示図である。
【図15】図14のフィールドリスト類型を用いる要求テーブル類型の例示図である。
【図16】図14のフィールドリスト類型を用いるget_Dataオペレーションの例示図である。
【特許請求の範囲】
【請求項1】
シンプル・オブジェクト・アクセス・プロトコル(以下、「SOAP」という。)問合せオペレーションを用いてTV−Anytimeメタデータを提供する方法であって、
(a)前記SOAP問合せオペレーションにおいて、問合せ結果値の類型に、メタデータテーブルのフィールドを指定可能な要求フィールド類型(RequestedFieldsType)を追加するステップと、
(b)前記SOAP問合せオペレーションの要求メッセージを受信するステップと、
(c)前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型のエレメントを含む場合において、前記要求メッセージの要求フィールド類型のエレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記SOAPオペレーションの応答メッセージにより伝送するステップと、
を含むことを特徴とする、TV−Anytimeメタデータの提供方法。
【請求項2】
前記SOAP問合せオペレーションは、get_Dataオペレーションであることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項3】
前記ステップ(a)において追加される要求フィールド類型のエレメントは、
メタデータテーブルのフィールドIDを指定する要求フィールドサブエレメントと、
前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントと、
を含むことを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項4】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項5】
前記メタデータは、プログラム記述メタデータ(Program Description Metadata)であることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項6】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項5記載のTV−Anytimeメタデータの提供方法。
【請求項7】
前記ステップ(a)において追加される要求フィールド類型のエレメントは、
メタデータテーブルのフィールドIDを指定する要求フィールドサブエレメントと、
前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントと、を含むことを特徴とする、請求項5記載のTV−Anytimeメタデータの提供方法。
【請求項8】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項7記載のTV−Anytimeメタデータの提供方法。
【請求項9】
前記要求フィールド類型(RequestFieldsType)エレメントは、次のように定義されることを特徴とする、請求項7記載のTV−Anytimeメタデータの提供方法。
<complexType name=‘RequestedFieldsType’>
<sequence>
<element name=‘RequestedField’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’ maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘fieldID’ type=‘tns:fieldIDType’ use=‘required’/>
</complexType>
</element>
<element name=‘RequestedXPath’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘XPath’ type=‘string’ use=‘required’/>
</complexType>
</element>
</sequence>
</complexType>
【請求項10】
TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索を提供する方法であって、
(d)get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメント(RequestedTables)に、前記テーブルのフィールドを指定する要求フィールドエレメント(RequestedFields)をサブエレメントとして追加するステップと、
(e)前記get_Dataオペレーションの要求メッセージを受信するステップと、
(f)前記要求メッセージの受信に応えて、前記要求テーブルエレメントで指定されたテーブルから、前記要求フィールドエレメントに指定されたフィールドを問合せ結果値として抽出するステップと、
(g)前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップと、
を含むことを特徴とする、TV−Anytimeメタデータの提供方法。
【請求項11】
前記ステップ(d)において、追加される要求フィールドエレメントは、検索しようとするフィールドのフィールドIDを指定する単位要求フィールドエレメントをサブエレメントとして含むものであることを特徴とする、請求項10記載のTV−Anytimeメタデータの提供方法。
【請求項12】
前記ステップ(d)は、 検索しようとするフィールドのフィールドIDを、前記単位要求フィールドエレメントの属性として与えるものであることを特徴とする、請求項11記載のTV−Anytimeメタデータの提供方法。
【請求項13】
前記ステップ(d)において追加される要求フィールドエレメントは、
検索しようとするフィールドの経路を指定する要求経路エレメント(RequestedXpath)をサブエレメントとして含むものであることを特徴とする、請求項12記載のTV−Anytimeメタデータの提供方法。
【請求項14】
前記要求フィールドエレメントの類型は、次のように定義されるものであることを特徴とする、請求項13記載のTV−Anytimeメタデータの提供方法。
<complexType name=‘RequestedFieldsType’>
<sequence>
<element name=‘RequestedField’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’ maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘fieldID’ type=‘tns:fieldIDType’ use=‘required’/>
</complexType>
</element>
<element name=‘RequestedXPath’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘XPath’ type=‘string’ use=‘required’/>
</complexType>
</element>
</sequence>
</complexType>
【請求項1】
シンプル・オブジェクト・アクセス・プロトコル(以下、「SOAP」という。)問合せオペレーションを用いてTV−Anytimeメタデータを提供する方法であって、
(a)前記SOAP問合せオペレーションにおいて、問合せ結果値の類型に、メタデータテーブルのフィールドを指定可能な要求フィールド類型(RequestedFieldsType)を追加するステップと、
(b)前記SOAP問合せオペレーションの要求メッセージを受信するステップと、
(c)前記要求メッセージが問合せ結果値を指定する前記要求フィールド類型のエレメントを含む場合において、前記要求メッセージの要求フィールド類型のエレメントで指定されたテーブルフィールドに該当する問合せ結果値を抽出し、その問合せ結果値を、前記SOAPオペレーションの応答メッセージにより伝送するステップと、
を含むことを特徴とする、TV−Anytimeメタデータの提供方法。
【請求項2】
前記SOAP問合せオペレーションは、get_Dataオペレーションであることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項3】
前記ステップ(a)において追加される要求フィールド類型のエレメントは、
メタデータテーブルのフィールドIDを指定する要求フィールドサブエレメントと、
前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントと、
を含むことを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項4】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項5】
前記メタデータは、プログラム記述メタデータ(Program Description Metadata)であることを特徴とする、請求項1記載のTV−Anytimeメタデータの提供方法。
【請求項6】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項5記載のTV−Anytimeメタデータの提供方法。
【請求項7】
前記ステップ(a)において追加される要求フィールド類型のエレメントは、
メタデータテーブルのフィールドIDを指定する要求フィールドサブエレメントと、
前記フィールドIDに対する経路(Xpath)を指定する要求経路サブエレメントと、を含むことを特徴とする、請求項5記載のTV−Anytimeメタデータの提供方法。
【請求項8】
前記ステップ(c)は、前記問合せ結果値に同一のフィールドIDを有する重複データが存在する場合、前記問合せ結果値から重複データを排除するものであることを特徴とする、請求項7記載のTV−Anytimeメタデータの提供方法。
【請求項9】
前記要求フィールド類型(RequestFieldsType)エレメントは、次のように定義されることを特徴とする、請求項7記載のTV−Anytimeメタデータの提供方法。
<complexType name=‘RequestedFieldsType’>
<sequence>
<element name=‘RequestedField’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’ maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘fieldID’ type=‘tns:fieldIDType’ use=‘required’/>
</complexType>
</element>
<element name=‘RequestedXPath’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘XPath’ type=‘string’ use=‘required’/>
</complexType>
</element>
</sequence>
</complexType>
【請求項10】
TV−Anytimeメタデータサービスにおいて、get_Dataオペレーションを用いてテーブルのフィールド単位検索を提供する方法であって、
(d)get_Dataオペレーションの問合せ結果値としてテーブルを指定する要求テーブルエレメント(RequestedTables)に、前記テーブルのフィールドを指定する要求フィールドエレメント(RequestedFields)をサブエレメントとして追加するステップと、
(e)前記get_Dataオペレーションの要求メッセージを受信するステップと、
(f)前記要求メッセージの受信に応えて、前記要求テーブルエレメントで指定されたテーブルから、前記要求フィールドエレメントに指定されたフィールドを問合せ結果値として抽出するステップと、
(g)前記抽出された問合せ結果値をget_Dataオペレーションの応答メッセージによって伝送するステップと、
を含むことを特徴とする、TV−Anytimeメタデータの提供方法。
【請求項11】
前記ステップ(d)において、追加される要求フィールドエレメントは、検索しようとするフィールドのフィールドIDを指定する単位要求フィールドエレメントをサブエレメントとして含むものであることを特徴とする、請求項10記載のTV−Anytimeメタデータの提供方法。
【請求項12】
前記ステップ(d)は、 検索しようとするフィールドのフィールドIDを、前記単位要求フィールドエレメントの属性として与えるものであることを特徴とする、請求項11記載のTV−Anytimeメタデータの提供方法。
【請求項13】
前記ステップ(d)において追加される要求フィールドエレメントは、
検索しようとするフィールドの経路を指定する要求経路エレメント(RequestedXpath)をサブエレメントとして含むものであることを特徴とする、請求項12記載のTV−Anytimeメタデータの提供方法。
【請求項14】
前記要求フィールドエレメントの類型は、次のように定義されるものであることを特徴とする、請求項13記載のTV−Anytimeメタデータの提供方法。
<complexType name=‘RequestedFieldsType’>
<sequence>
<element name=‘RequestedField’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’ maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘fieldID’ type=‘tns:fieldIDType’ use=‘required’/>
</complexType>
</element>
<element name=‘RequestedXPath’ minOccurs=‘0’ maxOccurs=‘unbounded’>
<complexType>
<sequence>
<element name=‘SortCriteria’ type=‘tns:SortCriteriaType’ minOccurs=‘0’maxOccurs=‘unbounded’/>
</sequence>
<attribute name=‘XPath’ type=‘string’ use=‘required’/>
</complexType>
</element>
</sequence>
</complexType>
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9a】
【図9b】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9a】
【図9b】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2006−85698(P2006−85698A)
【公開日】平成18年3月30日(2006.3.30)
【国際特許分類】
【出願番号】特願2005−259706(P2005−259706)
【出願日】平成17年9月7日(2005.9.7)
【出願人】(599028364)電子部品研究院 (28)
【Fターム(参考)】
【公開日】平成18年3月30日(2006.3.30)
【国際特許分類】
【出願日】平成17年9月7日(2005.9.7)
【出願人】(599028364)電子部品研究院 (28)
【Fターム(参考)】
[ Back to top ]