図面 (/)

技術 メタデータサーバシステム、メタデータ検索プログラムおよびそのプログラムを記録した記録媒体

出願人 日本電信電話株式会社
発明者 深津真二田中清
出願日 2009年8月13日 (10年10ヶ月経過) 出願番号 2009-187598
公開日 2011年2月24日 (9年4ヶ月経過) 公開番号 2011-039855
状態 特許登録済
技術分野 検索装置
主要キーワード 先頭順位 コア技術 メタデータスキーマ 運用ツール フラグメント単位 メタデータサービス メタサーバ 任意指定
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年2月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

TV−Anytimeメタデータサービスにおいて、受信端末200に大きな処理負荷をかけることなく、フリーワードによる人名一覧の検索を実現する。

解決手段

TV−Anytimeメタデータサービスにおいて、フリーワードによる人名検索を提供するシステムであって、クレジット情報管理部120が、メタデータ登録部110から受領したメタデータをパースし、クレジット情報をメタデータDB130のクレジット情報管理テーブル132に登録し、メタデータ検索部140が、受信端末200からの人名検索要求を受信時、クレジット情報管理テーブル132を参照し、人名一覧テーブル(CreditsInformationTable)を生成し、受信端末200へ返信する。

概要

背景

IPTVサービスコア技術として、多チャンネルビデオオンデマンドで提供されるコンテンツの情報(例えば、題名、内容、ジャンル出演者など)を記述検索するメタデータ技術がある。

一例として、民間国際標準規格であるTV−Anytime(非特許文献1参照)では、メタデータとして記載する内容や書式を規定するメタデータ・スキーマ標準化し、メタデータの共通データベース構築することで、利用者が所望のコンテンツを容易に検索・選択することを実現している。

日本国内でもTV−Anytime仕様をもとに、ARIBやIPTフォーラムがメタデータ標準仕様(ARIBSTD−B38(非特許文献2参照))、並びに、運用規定(ARIB TR−B27、IPTV規定 CDNスコープサービスアプローチ仕様)を各々で策定している。図2にTV−Anytimeメタデータの例を示す。

TV−Anytimeメタデータでは、コンテンツの情報(例えば、題名、内容、ジャンル、出演者など)はプログラム記述メタデータ(Program Description Metadata)で扱い、コンテンツの配信情報放送時間、チャンネル、コンテンツのURIなど)はインスタンスメタデータ(Instance Description)で扱う。この際、コンテンツに対するメタデータはCRID(Content Reference Identifier)と呼ぶコンテンツ参照識別子一意識別される。

また、TV−Anytimeでは、メタデータの双方向通信方式を規定しており、利用者は、メタデータを特定するための条件を含む検索要求を、メタデータサーバに送信することで、該当するメタデータ、該当するメタデータのCRID一覧、該当するメタデータの件数を取得できる。ここで、TV−Anytimeが規定する検索条件としては、タイトル検索、キーワード検索、出演者検索、CRID検索、ジャンル検索、Period検索などがある。なお、返却フォーマットとしてメタデータ本体を指定した場合、該当するメタデータのフラグメント(ProgramInformation、GroupInformation、BroadCastEventなど)がテーブル単位(ProgramInformationTable, GroupInformationTable, ProgramLocationTable, TVAMainなど)で返却される(図21参照)。

概要

TV−Anytimeメタデータサービスにおいて、受信端末200に大きな処理負荷をかけることなく、フリーワードによる人名一覧の検索を実現する。TV−Anytimeメタデータサービスにおいて、フリーワードによる人名検索を提供するシステムであって、クレジット情報管理部120が、メタデータ登録部110から受領したメタデータをパースし、クレジット情報をメタデータDB130のクレジット情報管理テーブル132に登録し、メタデータ検索部140が、受信端末200からの人名検索要求を受信時、クレジット情報管理テーブル132を参照し、人名一覧テーブル(CreditsInformationTable)を生成し、受信端末200へ返信する。

目的

また、上記のプログラムインターネット電子メールなど、ネットワークを通して提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

TV−Anytimeメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、前記メタデータサーバは、外部から投入されるメタデータを受信し、メタデータデータベースメタ情報管理テーブル登録するメタデータ登録手段と、前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、を備えることを特徴とするメタデータサーバシステム

請求項2

前記クレジット情報管理テーブルは、コンテンツ識別子であるCRIDを主キーに、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項1記載のメタデータサーバシステム。

請求項3

前記人名一覧テーブルは、TV−AnytimeのCreditsInformationTableTypeに対するスキーマ拡張の実施により、役柄情報が記載されていることを特徴とする請求項1記載のメタデータサーバシステム。

請求項4

前記メタデータ検索手段は、前記クレジット情報管理テーブルに対する照合結果リストを格納する照合結果リスト格納手段と、前記受信端末からの人名検索要求からフリーワードを取得する手段と、前記取得したフリーワードと前記クレジット情報管理テーブルの出演者名と出演者名ルビを照合し、合致する第1のレコード導出する手段と、前記人名検索要求に役柄指定がある場合、前記手段で導出された第1のレコードの役柄情報と照合し、合致する第2のレコードを導出する手段と、前記導出された第2のレコードと既に前記照合結果リスト格納手段に格納済みのレコードを照合し、照合結果リストへの追記を実施する手段と、前記照合結果リストの最終的な照合結果から、前記受信端末へ返信する人名一覧テーブルを生成する手段と、を備えることを特徴とする請求項1記載のメタデータサーバシステム。

請求項5

前記照合結果リストは、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項4記載のメタデータサーバシステム。

請求項6

前記照合結果リストは、CRID、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項4記載のメタデータサーバシステム。

請求項7

前記メタデータ検索手段は、前記受信端末からの人名検索要求に加え、コンテンツに対するオプション検索要求を受信する手段と、前記クレジット情報管理テーブルとの照合時、クレジット情報管理テーブルのCRIDをキーに、対応するメタ情報を前記メタ情報管理テーブルから取得する手段と、前記取得したメタ情報とオプション検索要求とを照合する手段と、を更に備えることを特徴とする請求項1記載のメタデータサーバシステム。

請求項8

前記メタデータ検索手段は、前記クレジット情報管理テーブルのCRIDをキーに、対応するメタデータの有効期限を前記メタ情報管理テーブルから取得する手段と、前記取得した有効期限をもとに、期限切れしたメタデータに記載されていたクレジット情報を前記クレジット情報管理テーブルから削除する手段と、を更に備えることを特徴とする請求項1記載のメタデータサーバシステム。

請求項9

コンピュータを請求項1記載の各手段として機能させるメタデータ検索プログラム

請求項10

請求項9に記載のメタデータ検索プログラムを記録したコンピュータ読み取り可能な記録媒体

技術分野

0001

本発明は、TV−Anytimeサービスに関するものであり、特に、フリーワードによる人名一覧の検索を実現するシステムおよびプログラムに関する。

背景技術

0002

IPTVサービスコア技術として、多チャンネルビデオオンデマンドで提供されるコンテンツの情報(例えば、題名、内容、ジャンル出演者など)を記述・検索するメタデータ技術がある。

0003

一例として、民間国際標準規格であるTV−Anytime(非特許文献1参照)では、メタデータとして記載する内容や書式を規定するメタデータ・スキーマ標準化し、メタデータの共通データベース構築することで、利用者が所望のコンテンツを容易に検索・選択することを実現している。

0004

日本国内でもTV−Anytime仕様をもとに、ARIBやIPTフォーラムがメタデータ標準仕様(ARIBSTD−B38(非特許文献2参照))、並びに、運用規定(ARIB TR−B27、IPTV規定 CDNスコープサービスアプローチ仕様)を各々で策定している。図2にTV−Anytimeメタデータの例を示す。

0005

TV−Anytimeメタデータでは、コンテンツの情報(例えば、題名、内容、ジャンル、出演者など)はプログラム記述メタデータ(Program Description Metadata)で扱い、コンテンツの配信情報放送時間、チャンネル、コンテンツのURIなど)はインスタンスメタデータ(Instance Description)で扱う。この際、コンテンツに対するメタデータはCRID(Content Reference Identifier)と呼ぶコンテンツ参照識別子一意識別される。

0006

また、TV−Anytimeでは、メタデータの双方向通信方式を規定しており、利用者は、メタデータを特定するための条件を含む検索要求を、メタデータサーバに送信することで、該当するメタデータ、該当するメタデータのCRID一覧、該当するメタデータの件数を取得できる。ここで、TV−Anytimeが規定する検索条件としては、タイトル検索、キーワード検索、出演者検索、CRID検索、ジャンル検索、Period検索などがある。なお、返却フォーマットとしてメタデータ本体を指定した場合、該当するメタデータのフラグメント(ProgramInformation、GroupInformation、BroadCastEventなど)がテーブル単位(ProgramInformationTable, GroupInformationTable, ProgramLocationTable, TVAMainなど)で返却される(図21参照)。

先行技術

0007

「Broadcast and On−line Services: Search, select, and rightful use of content on personal storage systems(″TV−Anytime″);Part3: Metadata;」、TV−Anytime Forum、ETSI TS102822−3−1 Vl.4.1(2007−11)、6.7.2TV−Anytime meta data documet pp.84−88
サーバー型放送における符号化、伝送及び蓄積制御方式」、ARIBSTD−B38 1.3版、平成18年3月14日、3.2.7.2ARIBサーバー型放送番組情報文書pp.69−73

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

0008

TV−Anytimeでは、メタデータの検索や処理はフラグメント単位で扱われる。そこで、例えば、“ヤマダ”で始まる人名の一覧を検索するといった人名検索を実現する場合、まず、“ヤ”で始まる人物出演している作品の検索(出演者検索)を実施する。その後、取得されたメタデータ(ProgramInformationTable、図2参照)をパースし、“ヤマダ”で始まる出演者名(CreditsItem/PersonName/mpeg7:GivenName[@type=“main”]、図2の山田太郎、田中次郎など)を抽出することになる。この際、検索結果に複数のProgramInformationが記載され、さらには、同じ出演者名が複数抽出された場合、それらを統合する処理などが必要になる(図2では、山田太郎は2つのProgramInformationに記載されており、検索結果としては、それらを統合し、例えば図10のように表示する)。

0009

また、TV−Anytimeでは、検索結果の返却フォーマットは、メタデータ本体、CRID一覧、件数といった作品をベースとした返却フォーマットになっており、人名検索結果として想定される複数の作品情報を横通しし、人物名一覧として返却する仕組みは規定されてない。

0010

本発明は、このような状況を鑑みてなされたものであり、TV−Anytimeのメタデータサービスにおいて、受信端末に大きな処理負荷をかけることなく、人名検索を実現できるようにするものである。

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

0011

上記課題を解決するための請求項1記載のメタデータサーバシステムは、TV−Anytimeメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、前記メタデータサーバは、外部から投入されるメタデータを受信し、メタデータデータベースメタ情報管理テーブル登録するメタデータ登録手段と、前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、を備えることを特徴としている。

発明の効果

0012

(1)請求項1〜10に記載の発明によれば、TV−Anytimeメタデータサービスにおける人名検索を、受信装置に大きな処理負荷をかけることなく実現できる。
(2)請求項2、6に記載の発明によれば、人名一覧だけでなく、各人物が出演する作品数を返却することが可能になり、検索結果としての表現を高めることが可能になる。
(3)請求項7に記載の発明によれば、クレジット情報だけでなく、コンテンツに関する情報も参照することで、多種多様な人名検索が実現できる。
(4)請求項8に記載の発明によれば、メタサーバにおけるコンテンツ情報とクレジット情報の管理、特に、期限切れ情報の削除を連携でき、メタサーバの適切な管理が実現できる。

図面の簡単な説明

0013

本発明の一実施の形態の構成を示すブロック図である。
TV−Anytimeメタデータの例を示す図である。
本発明の一実施の形態におけるクレジット情報管理テーブルの構成要素を説明する図である。
本発明での検索応答であるCreditsInformationTable(人名一覧テーブル)を説明する図である。
TV−Anytimeでのメタデータスキーマ、並びに、本発明でのスキーマ拡張を説明する図である。
本発明の一実施の形態における人物検索時の受信端末−メタサーバ間の処理を説明するシーケンス図である。
検索要求画面の例を説明する図である。
本発明の一実施の形態におけるメタデータ検索部での人名一覧生成の処理を説明するフローチャートである。
本発明の一実施の形態における照合結果リストの構成要素を説明する図である。
検索結果画面の例を説明する図である。
本発明の一実施の形態における出演者検索の検索結果画面を説明する図である。
本発明の一実施の形態における別クエリで検索した場合の検索応答例を説明する図である。
本発明の一実施の形態における“役柄指定なし”で検索した場合の照合結果リスト例を説明する図である。
図13の照合結果リストに対応する検索応答を説明する図である。
図14の検索応答受領時の検索結果画面を説明する図である。
本発明の実施例1による照合結果リストを説明する図である。
図16の照合結果リストに対応する検索応答を説明する図である。
図17の検索応答受領時の検索結果画面を説明する図である。
メタ情報管理テーブルの構成要素を説明する図である。
本発明の実施例2による照合結果リストを説明する図である。
TV−Anytimeでの検索結果の返却フォーマットを説明する図である。

0014

以下、添付図面を参照しながら、本発明の好適な実施形態について詳細に説明するが、本発明は下記の実施形態例に限定されるものではない。

0015

図1は本発明を用いたシステムの一実施の形態の構成を示すブロック図である。このシステムは、メタデータの管理・検索・伝送を実施するメタデータサーバ100と、ネットワーク300を介してメタデータサーバ100へメタデータの検索要求・メタデータの受信を実施する受信端末200とから構成されている。

0016

なお、図1には、受信端末200が1台のみ示されているが、実際には複数の受信端末がネットワーク300を介してメタデータサーバ100に接続されている。

0017

メタデータサーバ100は、メタデータ登録手段としてのメタデータ登録部110、クレジット情報管理手段としてのクレジット情報管理部120、メタデータDB(データベース)130、メタデータ検索手段としてのメタデータ検索部140の機能的構成を有しており、メタデータDB130は、メタ情報管理テーブル131とクレジット情報管理テーブル132の機能的構成を有している。

0018

尚、前記メタデータサーバ100内の各部の機能は例えばコンピュータによって達成される。

0019

また、受信端末200は入力部210、メタデータ要求部220、提示部230の機能的構成を有している。

0020

メタデータサーバ100のメタデータ登録部110においては、外部のメタデータ運用ツールから投入されるメタデータ(TV−AnytimeXMLデータ図2参照)を受信し、メタデータDB130のメタ情報管理テーブル131に登録する。この際、XML本体だけでなく、各種検索に対応するために、適宜、Attribute展開して登録する。また、受信したメタデータをクレジット情報管理部120に伝送する。

0021

クレジット情報管理部120においては、メタデータ登録部110から受領したメタデータをパースし、人名検索用にクレジット情報を抽出し、メタデータDB130のクレジット情報管理テーブル132に登録する(図3参照)。

0022

クレジット情報管理テーブル132は、図3に示すように、TVAMain/ProgramDescription/ProgramInformation(以下、PIと略記する)/@programId、TVAMain/ProgramDescription/GroupInformation(以下、GIと略記する)/@groupIdを“CRID”に記載する。

0023

次に、役柄情報にあたる、PIまたはGIのBasicDescription/CreditsList/CreditsItem/@roleを“Role”に記載する。

0024

更に、出演者名にあたる、各CreditsItemのPersonName[@type=“main”]/mpeg7:GivenNameを“NameMain”、出演者名ルビにあたる、PersonName[@type=“variant”]/mpeg7:GivenNameを“NameVariant”、PersonName[@type=“former”]/mpeg7:GivenNameを“NameFormer1”に記載する。この際、PersonName[@type=“former”]/mpeg7:GivenNameは複数記載される場合があり、この場合には、“NameFormer2”以降に追記する。

0025

ここで、NameVariantやNameFormerは検索対象に出演者ルビを含めるため、並びに、同姓異読みを区別するために、クレジット情報管理テーブル132に記載する。なお、同姓同名については、現状では区別されないが、NameFormerの末尾に“**_A”などルビ以外の文字列を付与するといった運用面での対処が考えられるが、本明細書では特に言及しないこととする。

0026

メタデータ検索部140においては、受信端末200から送信される検索要求を受信し、その検索要求が人名検索の場合、クレジット情報管理テーブル132を参照し、返却する人名一覧テーブル(CreditsInformationTable、図4参照)を生成し、受信端末200へ送信する。一方、検索要求がタイトル検索や出演者検索など、既存の検索要求の場合、メタ情報管理テーブル131を参照し、返却するフラグメントを生成し、受信端末200へ送信する。

0027

尚、メタデータ検索部140は、クレジット情報管理テーブル132に対する照合結果リストを格納する照合結果リスト格納部(照合結果リスト格納手段)を有している。

0028

ここで、TV−Anytimeのメタデータスキーマでは、図5(a)に示すように、CreditsInforamtionTableTypeは単に出演者名(PersonName)をリスト化するのみで、役柄情報が記載できない。そこで、本発明では、CreditsInformationTableTypeのスキーマを拡張し、図5(b)に示すように、各出演者名を役柄情報(CreditsItem)単位で管理できるようにし、さらには、役柄情報(CreditsItem/@role)を記載できるようにする。

0029

次に図6のシーケンス図を参照して、受信端末200から人名検索要求(メタデータ検索要求)をメタデータサーバ100に送信し、検索結果である人名一覧テーブルを受信し、提示する処理について説明する。

0030

まず、提示部230が利用者に図7に示すような検索画面を提示する(ステップS100)。その後、利用者が検索したいフリーワードや役柄(指定なし、主演、監督など)を入力し(ステップS101)、検索を実行する(ステップS102)。

0031

次に、メタデータ要求部220が検索画面に入力された情報をもとにメタデータサーバ100への検索要求を生成する(ステップS103)。この際、人名検索の検索要求は、以下に示すような書式が考えられる。
getactor=credit((<name_value>[,<role_value>]),…)&<range>&<type>
・name_value:入力された任意文字列
・role_value:指定された役柄に対応するARIBRoleCSのtermID。
role_valueは任意指定、付与された場合はname_valueとのAND条件。
(<name_value>[,<role_value>])の複数記載はOR条件。
・range=<from>[,<count>]|unlimit
from:返却する検索結果の先頭順位
count:先頭順位から返却する検索結果件数
unlimit:検索結果の先頭からすべての検索結果を返却
・type=namelist|countonly
namelist:人名一覧を返却
countonly:人名の数を返却
例えば、図7に示すように“ヤマダ”、“主演”で検索した場合、検索要求は以下になる。
・getactor=credit(ヤマダ*,ARIBRoleCS:1.1)&unlimit&namelist ※ *は前方一致を指定。

0032

メタデータサーバ100のメタデータ検索部140は、受信した検索要求を解析し(ステップS104)、検索要求の書式が上記した人名検索(getactor)の場合、メタデータDB130のクレジット情報管理テーブル132を参照し、条件に合致する人名を検索する(ステップS105)。そして、検索結果を人名一覧(CreditsInformationTable)の形式にし、受信端末200へ送信する(ステップS106)。

0033

受信端末200は、メタデータ要求部220で検索結果を受信し(ステップS107)、提示部230で検索結果画面を利用者に提示する(ステップS108)。

0034

次に図8のフローチャートを参照して、メタデータ検索部140がクレジット情報管理テーブル132から条件に合致する人名一覧を検索する処理について説明する。

0035

はじめに、受信した検索要求から“(name_value,role_value)”のペアを取得する(ステップS201)。ここで、“name_value”は必須だが、“role_value”は任意であるため、記載されていない場合もある。また、credit()内に“(name_value,role_value)”が複数記載されている場合、各ペアを順番に取得し、以降の処理を実施する。

0036

まず、クレジット情報管理テーブル132を参照し、取得した“name_value”の文字列が“NameMain”、“NameVariant”、“NameFormer1”、“NameFormer2”のいずれかに記載されているレコードを検索する(ステップS202)。この際、照合方法としては、前方一致、部分一致完全一致後方一致があり、それぞれ、“name_value”部分の書式を“ヤマダ*”、“*ヤマダ*”、“ヤマダ”、“*ヤマダ”とすることが考えられる。

0037

次に、合致するレコードが見つかった場合(ステップS203のYes)、受信した検索要求のペアに“role_value”が記載されているかを確認する。そして、“role_value”が記載されている場合、その“role_value”に記載された値と取得したレコードのRoleを照合し(ステップS205)、合致する場合(ステップS206のYes)、合致したレコードの“Role, NameMain, NameVariant, NameFormer, NameFormer2”を取得する(ステップS207)。

0038

続いて、取得したレコードの情報が既に照合結果リストにあるかを確認し、照合結果にない場合(ステップS208のNo)、その取得したレコードの情報を照合結果リストに追記し(ステップS209、図9参照)、ステップS210の処理へ移る。

0039

ここで、ステップS203の処理で取得したname_valueに合致するレコードが見つからなかった場合(ステップS203のNo)、ステップS206の処理で取得したrole_valueと合致するレコードが見つからなかった場合(ステップS206のNo)、ステップS208の処理で照合結果リストに既に取得したレコードがあった場合(ステップS208のYes)、それぞれ、特別な処理は実施せず、ステップS210の処理へ移る。

0040

ステップS210の処理では、ステップS201で取得した“(name_value,role_value)”のペアで、クレジット情報管理テーブル132の最後まで検索したかを判定し、まだ最後まで至っていない場合(ステップS210のNo)、ステップS202へ戻り、残りのテーブルを検索する。一方、クレジット情報管理テーブル132の最後まで至っていた場合(ステップS210のYes)、受信した検索要求に次の“(name_value,role_value)”のペアがあるかを確認する(ステップS211)。そして、次の“(name_value,role_value)”のペアがある場合(ステップS211のYes)、そのペアでステップS201からの処理を実施する。

0041

一方、検索要求に次の“(name_value,role_value)”のペアがない場合(ステップS211のNo)、検索結果の返却応答を生成する処理に移る。

0042

まず、検索要求のtype指定を確認し(ステップS212)、type指定が“count”の場合(ステップS212のcount)、照合結果リストに記載されたレコードの件数をカウントし、その件数を受信端末200へ返信する(ステップS214)。一方、type指定が“namelist”(ステップS212のnamelist)の場合、照合結果リストを、例えば、NameVariantの50音順にソートする(ステップS213)。

0043

次に、検索要求のrange指定を確認し(ステップS215)、range指定が“from(count)”の形式の場合(ステップS215のfrom(count))、照合結果リストのfrom番目からcount分のレコードを抽出し(ステップS216)、抽出した人名一覧をCreditsInformationTableの形式で返却する(ステップS217;図6のステップS106)。一方、range指定が“unlimit”の場合、照合結果リストに記載された全てのレコードを取得し、取得した人名一覧をCreditsInformationTableの形式で返却する(ステップS217;図6のステップS106)。

0044

例えば、図7に示すように“ヤマダ”、“主演”で検索した場合、CreditsItem/@roleが主演(ARIBRoleCS:1.1)で、出演者名(CreditsItem/PersonName[@type=“main”]/mpeg7:GivenName)、または、出演者名ルビ(CreditsItem/PersonName[@type=“variant”]/mpeg7:GivenName)が“ヤマダ”で始まるCreditsItemが記載された人名一覧(CreditsInformationTable、図4参照)が返却される。そこで、受信端末200では、受信した人名一覧(CreditsInformationTable)から出演者名(CreditsItem/PersonName[@type=”main”])を抜き出し、検索結果画面を生成する(図10参照)。

0045

なお、この後、検索結果の人名(図10中の“山田太郎”)を選択した場合、“山田太郎”が“主演”である作品の検索(出演者検索、predicate=credit(山田太郎,ARIBRoleCS:1.1))を実施することが考えられ、利用者には図11に示すような該当するコンテンツの一覧を表示した検索結果画面が提示される(図3のcrid://arib.or.jp/vod/001, crid://arib.or.jp/vod/002が返却)。

0046

他にも、例えば、“*山*”、“役柄指定なし”で検索した場合、検索要求は以下になる。

0047

getactor=credit(*山*)&unlimit&namelist ※ *X*はXでの部分一致を指定。

0048

この場合、name_valueの条件(role_valueは不問)で、図3に示すクレジット情報管理テーブル132から、項番1−1の山田太郎(CRID:arib.or.jp/vod/001, Role:ARIBRoleCS:1.1)、項番2−1の山田太郎(CRID:arib.or.jp/vod/002, Role:ARIBRoleCS:1.1)、項番2−3の山本太郎(CRID:arib.or.jp/vod/002, Role:ARIBRoleCS:1.1)が抽出される。このうち、項番1−1と項番2−1はマージされ、受信端末200には図12に示す人名一覧(CreditsInformationTable)が返却される。

0049

更には、例えば、“タナカ”、“役柄指定なし”で検索した場合、検索要求は以下になる。

0050

getactor=credit(タナカ*)&unlimit&namelist ※ *は前方一致を指定。

0051

この場合、name_valueの条件(role_valueは不問)で、図3に示すクレジット情報管理テーブル132から、項番1−2の田中次郎(CRID:arib.or.jp/vod/001, Role:ARIBRoleCS:1.1)、項番1−3の田中次郎(CRID:arib.or.jp/vod/001, Role:ARIBRoleCS:3.1)、項番2−2のの田中次郎(CRID:arib.or.jp/vod/002, Role:ARIBRoleCS:4.3)が抽出される。この際、項番1−2、1−3、2−2は“田中次郎”という出演者名は同じであるが、役柄情報が異なることから、照合結果リストは図13のようになり、受信端末200には図14に示すように出演者名が同じだが、CreditsItem/@roleが異なる記載になった人名一覧(CreditsInformationTable)が返却される。ここで、受信端末200は検索結果画面として、単に“田中次郎”という出演者名を記載する形でなく、図15に示すように出演者名の後ろに役柄情報(CreditsItem/@roleに記載されたARIBRoleCSに対応する役柄名)を記載することが考えられる。

0052

なお、この後、検索結果の役柄(図15中の“主演”)を選択した場合、“田中次郎”が“主演”である作品の検索(predicate=credit(田中次郎,ARIBRoleCS:1.1)、コンテンツ1が返却)を実施し、検索結果の人名(図15中の“田中次郎”)を選択した場合、“田中次郎”が“主演”、“監督”、“歌手”のいずれかである作品の検索(predicate=credit((田中次郎,1.1),(田中次郎,3.1),(田中次郎,4.1)、コンテンツ1とコンテンツ2が返却)を実施することが考えられる。

0053

前記実施形態で述べた例では、図10に示すように出演者名の一覧を検索結果画面として提示することを考えた。ここで、人名検索の検索結果として、図18に示すように、各出演者名の横にその人物が出演する作品数(CRID数)を提示することが考えられる(例えば、検索要求でのtype指定を“namelist2”とする)。

0054

以下、図8を参照して、本実施例におけるメタデータ検索部140の処理の拡張部分について説明する。

0055

本実施例では、クレジット管理情報テーブル132から条件に合致したレコードを取得する際(ステップS207)、CRIDも取得し、図16に示すように、照合結果リストではCRIDを含めて管理する。

0056

このようにすることで、取得したレコードの情報が既に照合結果リストに有るかの確認時(ステップS208)、役柄情報、出演者名、出演者ルビが同じであっても、CRIDが異なるものは別情報として扱われる形になる。

0057

その結果、受信端末200へは、図17に示すように、同じ役柄情報、出演者名、出演者ルビを持つCreditsItemがCRIDの個数分記載された人名一覧(CreditsInformationTable)が返却される。そこで、受信端末200はCreditsItemの内容が同じ情報をカウントし、そのCreditsItemに対する作品数として図18のように提示する。

0058

ここで、受信端末200からの検索要求に役柄指定がない場合で、CreditsItemの役柄情報の差異を無視した場合はその人物に対する全作品数がカウントでき、差異を区別した場合は各役柄での作品数をカウントすることになる。

0059

前記実施形態で述べた例では、クレジット情報管理テーブル132にはそのクレジットが記載されているコンテンツの期間情報パレンタルレーティングなどは記載されていない。そのため、例えば、コンテンツが表示期間(Period[@type=“display”])外であった場合でも、人名検索の結果には、そのコンテンツに出演している人物名が表示される。

0060

しかしながら、検索結果画面から、その人物名で出演者検索を実施した場合、該当するコンテンツが表示期間外のため、コンテンツが検索されないといったことが発生する。他にも、例えば、コンテンツが成人作品であった場合、人名検索の結果には、そのコンテンツに出演している人物名が表示されるが、その人物名で出演者検索を実施した場合、該当するコンテンツがパレンタル対象のため、コンテンツが提示されないといったことも考えられる。

0061

そこで、本実施例では、TV−Anytimeが規定する検索条件(Period検索、パレンタルレーティング検索、ジャンル検索など)を、人名検索についてもオプションとして付与することを考える。

0062

以下、図8を参照して、本実施例におけるメタデータ検索部140の処理の拡張部分について説明する。例えば、表示期間が2009/4/1 00:00:00〜2009/05/31 23:59:59に含まれるコンテンツを対象に、“タナカ”で始まる人名検索を実施する場合、検索要求は以下のようになる。

0063

getactor= credit(タナカ*),period(display,20090401000000,20090531235959)&unlimit&namelist ※ period検索の書式:period(<period−type>[,<start>],[<end>] )
本実施例では、取得したname_valueとクレジット情報管理テーブル132との照合を行う際(ステップS202)、クレジット情報管理テーブル132から別途CRIDを取得し、CRIDをキーにメタ情報管理テーブル132(図19参照)から対応するメタデータのレコードを取得し、オプション指定された検索条件を照合する。上記の場合、図3に示すクレジット情報管理テーブル132から、項番:1−2と項番1−3の田中次郎(CRID:arib.or.jp/vod/001)と項番:2−2の田中次郎(CRID:arib.or.jp/vod/002)が抽出される。そして、メタ情報管理テーブル131(図19)を参照し、各CRIDのPeriod[@type=“display”]/Start, Period[@type=“display”]/End情報を取得し、検索条件と照合する。

0064

照合の結果、“CRID:arib.or.jp/vod/002”のコンテンツは表示期間が2009−08−01T00:00:00〜2009−08−31T23:59:59と検索要求が示す期間には含まれないため、図3に示す項番:2−2の田中次郎は、照合結果の候補からは除外される(ステップS203のNo)。一方、“CRID:arib.or.jp/vod/001”のコンテンツは表示期間が2009−04−01T00:00:00〜2009−12−31T00:00:00と検索要求が示す期間に含まれるため、図3に示す項番:1−2と項番1−3のレコードは次の処理へ進められ(ステップS203のYes)、照合結果リストとしては、図20のようになる。

0065

なお、検索要求のオプションとして、パレンタルレーティングが付与された場合(ParentalRating(ARIBParentalRatingCS:R−20))、メタ情報管理テーブル131(図19)のParentalRatingと照合される。

0066

前記実施形態で述べた例では、クレジット情報管理テーブル132へのレコード情報の追記は述べているが、クレジット情報管理テーブル132の管理、レコード情報の削除は述べていない。ここで、TV−Anytimeでは、コンテンツに有効期限(FragmentExpirationDate)を記載し、この有効期限をもとにメタデータの管理、削除を実施することを規定している。そこで、本実施例では、このメタデータの有効期限と連携し、対応するコンテンツに記載されていたクレジット情報を管理、削除することを考える。これにより、人名検索結果に期限切れになったコンテンツの人名が提示されることを防止できる。

0067

本実施例では、メタ情報管理テーブル132に対する定期的な期限切れメタデータの削除操作時、メタ情報管理テーブル131に記載されたCRIDをキーに、クレジット情報管理テーブル132の該当するCRIDに対するクレジット情報を削除する。

実施例

0068

また、本実施形態のメタデータサーバシステムにおける各手段の一部もしくは全部の機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができることは言うまでもなく、コンピュータでその機能を実現するためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えばFD(Floppy(登録商標) Disk)や、MO(Magneto−Optical disk)、ROM(Read Only Memory)、メモリカード、CD(Compact Disk)−ROM、DVD(Digital Versatile Disk)−ROM、CD−R、CD−RW、HDDリムーバブルディスクなどに記録して、保存したり、配布したりすることが可能である。また、上記のプログラムをインターネット電子メールなど、ネットワークを通して提供することも可能である。

0069

100…メタデータサーバ
110…メタデータ登録部
120…クレジット情報管理部
130…メタデータDB
131…メタ情報管理テーブル
132…クレジット情報管理テーブル
140…メタデータ検索部
200…受信端末
210…入力部
220…メタデータ要求部
230…提示部
300…ネットワーク

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ