メタデータサーバシステム、メタデータ検索プログラムおよびそのプログラムを記録した記録媒体
【課題】ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて、受信端末２００に大きな処理負荷をかけることなく、フリーワードによる人名一覧の検索を実現する。
【解決手段】ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて、フリーワードによる人名検索を提供するシステムであって、クレジット情報管理部１２０が、メタデータ登録部１１０から受領したメタデータをパースし、クレジット情報をメタデータＤＢ１３０のクレジット情報管理テーブル１３２に登録し、メタデータ検索部１４０が、受信端末２００からの人名検索要求を受信時、クレジット情報管理テーブル１３２を参照し、人名一覧テーブル（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）を生成し、受信端末２００へ返信する。
【解決手段】ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおいて、フリーワードによる人名検索を提供するシステムであって、クレジット情報管理部１２０が、メタデータ登録部１１０から受領したメタデータをパースし、クレジット情報をメタデータＤＢ１３０のクレジット情報管理テーブル１３２に登録し、メタデータ検索部１４０が、受信端末２００からの人名検索要求を受信時、クレジット情報管理テーブル１３２を参照し、人名一覧テーブル（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）を生成し、受信端末２００へ返信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＶ−Ａｎｙｔｉｍｅサービスに関するものであり、特に、フリーワードによる人名一覧の検索を実現するシステムおよびプログラムに関する。
【背景技術】
【０００２】
ＩＰＴＶサービスのコア技術として、多チャンネルやビデオオンデマンドで提供されるコンテンツの情報（例えば、題名、内容、ジャンル、出演者など）を記述・検索するメタデータ技術がある。
【０００３】
一例として、民間国際標準規格であるＴＶ−Ａｎｙｔｉｍｅ（非特許文献１参照）では、メタデータとして記載する内容や書式を規定するメタデータ・スキーマを標準化し、メタデータの共通データベースを構築することで、利用者が所望のコンテンツを容易に検索・選択することを実現している。
【０００４】
日本国内でもＴＶ−Ａｎｙｔｉｍｅ仕様をもとに、ＡＲＩＢやＩＰＴＶフォーラムがメタデータ標準仕様（ＡＲＩＢ ＳＴＤ−Ｂ３８（非特許文献２参照））、並びに、運用規定（ＡＲＩＢ ＴＲ−Ｂ２７、ＩＰＴＶ規定 ＣＤＮスコープサービスアプローチ仕様）を各々で策定している。図２にＴＶ−Ａｎｙｔｉｍｅメタデータの例を示す。
【０００５】
ＴＶ−Ａｎｙｔｉｍｅメタデータでは、コンテンツの情報（例えば、題名、内容、ジャンル、出演者など）はプログラム記述メタデータ（Ｐｒｏｇｒａｍ Ｄｅｓｃｒｉｐｔｉｏｎ Ｍｅｔａｄａｔａ）で扱い、コンテンツの配信情報（放送時間、チャンネル、コンテンツのＵＲＩなど）はインスタンスメタデータ（Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）で扱う。この際、コンテンツに対するメタデータはＣＲＩＤ（Ｃｏｎｔｅｎｔ Ｒｅｆｅｒｅｎｃｅ Ｉｄｅｎｔｉｆｉｅｒ）と呼ぶコンテンツ参照識別子で一意に識別される。
【０００６】
また、ＴＶ−Ａｎｙｔｉｍｅでは、メタデータの双方向通信方式を規定しており、利用者は、メタデータを特定するための条件を含む検索要求を、メタデータサーバに送信することで、該当するメタデータ、該当するメタデータのＣＲＩＤ一覧、該当するメタデータの件数を取得できる。ここで、ＴＶ−Ａｎｙｔｉｍｅが規定する検索条件としては、タイトル検索、キーワード検索、出演者検索、ＣＲＩＤ検索、ジャンル検索、Ｐｅｒｉｏｄ検索などがある。なお、返却フォーマットとしてメタデータ本体を指定した場合、該当するメタデータのフラグメント（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ、ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎ、ＢｒｏａｄＣａｓｔＥｖｅｎｔなど）がテーブル単位（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ， ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ， ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ， ＴＶＡＭａｉｎなど）で返却される（図２１参照）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Ｂｒｏａｄｃａｓｔ ａｎｄ Ｏｎ−ｌｉｎｅ Ｓｅｒｖｉｃｅｓ： Ｓｅａｒｃｈ， ｓｅｌｅｃｔ， ａｎｄ ｒｉｇｈｔｆｕｌ ｕｓｅ ｏｆ ｃｏｎｔｅｎｔ ｏｎ ｐｅｒｓｏｎａｌ ｓｔｏｒａｇｅ ｓｙｓｔｅｍｓ（″ＴＶ−Ａｎｙｔｉｍｅ″）；Ｐａｒｔ３： Ｍｅｔａｄａｔａ；」、ＴＶ−Ａｎｙｔｉｍｅ Ｆｏｒｕｍ、ＥＴＳＩ ＴＳ１０２８２２−３−１ Ｖｌ．４．１（２００７−１１）、６．７．２ＴＶ−Ａｎｙｔｉｍｅ ｍｅｔａ ｄａｔａ ｄｏｃｕｍｅｔ ｐｐ．８４−８８
【非特許文献２】「サーバー型放送における符号化、伝送及び蓄積制御方式」、ＡＲＩＢ ＳＴＤ−Ｂ３８ １．３版、平成１８年３月１４日、３．２．７．２ＡＲＩＢサーバー型放送番組情報文書 ｐｐ．６９−７３
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＴＶ−Ａｎｙｔｉｍｅでは、メタデータの検索や処理はフラグメント単位で扱われる。そこで、例えば、“ヤマダ”で始まる人名の一覧を検索するといった人名検索を実現する場合、まず、“ヤ”で始まる人物が出演している作品の検索（出演者検索）を実施する。その後、取得されたメタデータ（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図２参照）をパースし、“ヤマダ”で始まる出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］、図２の山田太郎、田中次郎など）を抽出することになる。この際、検索結果に複数のＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎが記載され、さらには、同じ出演者名が複数抽出された場合、それらを統合する処理などが必要になる（図２では、山田太郎は２つのＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎに記載されており、検索結果としては、それらを統合し、例えば図１０のように表示する）。
【０００９】
また、ＴＶ−Ａｎｙｔｉｍｅでは、検索結果の返却フォーマットは、メタデータ本体、ＣＲＩＤ一覧、件数といった作品をベースとした返却フォーマットになっており、人名検索結果として想定される複数の作品情報を横通しし、人物名一覧として返却する仕組みは規定されてない。
【００１０】
本発明は、このような状況を鑑みてなされたものであり、ＴＶ−Ａｎｙｔｉｍｅのメタデータサービスにおいて、受信端末に大きな処理負荷をかけることなく、人名検索を実現できるようにするものである。
【課題を解決するための手段】
【００１１】
上記課題を解決するための請求項１記載のメタデータサーバシステムは、ＴＶ−Ａｎｙｔｉｍｅメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、前記メタデータサーバは、外部から投入されるメタデータを受信し、メタデータデータベースのメタ情報管理テーブルに登録するメタデータ登録手段と、前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、を備えることを特徴としている。
【発明の効果】
【００１２】
（１）請求項１〜１０に記載の発明によれば、ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおける人名検索を、受信装置に大きな処理負荷をかけることなく実現できる。
（２）請求項２、６に記載の発明によれば、人名一覧だけでなく、各人物が出演する作品数を返却することが可能になり、検索結果としての表現を高めることが可能になる。
（３）請求項７に記載の発明によれば、クレジット情報だけでなく、コンテンツに関する情報も参照することで、多種多様な人名検索が実現できる。
（４）請求項８に記載の発明によれば、メタサーバにおけるコンテンツ情報とクレジット情報の管理、特に、期限切れ情報の削除を連携でき、メタサーバの適切な管理が実現できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施の形態の構成を示すブロック図である。
【図２】ＴＶ−Ａｎｙｔｉｍｅメタデータの例を示す図である。
【図３】本発明の一実施の形態におけるクレジット情報管理テーブルの構成要素を説明する図である。
【図４】本発明での検索応答であるＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ（人名一覧テーブル）を説明する図である。
【図５】ＴＶ−Ａｎｙｔｉｍｅでのメタデータスキーマ、並びに、本発明でのスキーマ拡張を説明する図である。
【図６】本発明の一実施の形態における人物検索時の受信端末−メタサーバ間の処理を説明するシーケンス図である。
【図７】検索要求画面の例を説明する図である。
【図８】本発明の一実施の形態におけるメタデータ検索部での人名一覧生成の処理を説明するフローチャートである。
【図９】本発明の一実施の形態における照合結果リストの構成要素を説明する図である。
【図１０】検索結果画面の例を説明する図である。
【図１１】本発明の一実施の形態における出演者検索の検索結果画面を説明する図である。
【図１２】本発明の一実施の形態における別クエリで検索した場合の検索応答例を説明する図である。
【図１３】本発明の一実施の形態における“役柄指定なし”で検索した場合の照合結果リスト例を説明する図である。
【図１４】図１３の照合結果リストに対応する検索応答を説明する図である。
【図１５】図１４の検索応答受領時の検索結果画面を説明する図である。
【図１６】本発明の実施例１による照合結果リストを説明する図である。
【図１７】図１６の照合結果リストに対応する検索応答を説明する図である。
【図１８】図１７の検索応答受領時の検索結果画面を説明する図である。
【図１９】メタ情報管理テーブルの構成要素を説明する図である。
【図２０】本発明の実施例２による照合結果リストを説明する図である。
【図２１】ＴＶ−Ａｎｙｔｉｍｅでの検索結果の返却フォーマットを説明する図である。
【発明を実施するための形態】
【００１４】
以下、添付図面を参照しながら、本発明の好適な実施形態について詳細に説明するが、本発明は下記の実施形態例に限定されるものではない。
【００１５】
図１は本発明を用いたシステムの一実施の形態の構成を示すブロック図である。このシステムは、メタデータの管理・検索・伝送を実施するメタデータサーバ１００と、ネットワーク３００を介してメタデータサーバ１００へメタデータの検索要求・メタデータの受信を実施する受信端末２００とから構成されている。
【００１６】
なお、図１には、受信端末２００が１台のみ示されているが、実際には複数の受信端末がネットワーク３００を介してメタデータサーバ１００に接続されている。
【００１７】
メタデータサーバ１００は、メタデータ登録手段としてのメタデータ登録部１１０、クレジット情報管理手段としてのクレジット情報管理部１２０、メタデータＤＢ（データベース）１３０、メタデータ検索手段としてのメタデータ検索部１４０の機能的構成を有しており、メタデータＤＢ１３０は、メタ情報管理テーブル１３１とクレジット情報管理テーブル１３２の機能的構成を有している。
【００１８】
尚、前記メタデータサーバ１００内の各部の機能は例えばコンピュータによって達成される。
【００１９】
また、受信端末２００は入力部２１０、メタデータ要求部２２０、提示部２３０の機能的構成を有している。
【００２０】
メタデータサーバ１００のメタデータ登録部１１０においては、外部のメタデータ運用ツールから投入されるメタデータ（ＴＶ−Ａｎｙｔｉｍｅ ＸＭＬデータ、図２参照）を受信し、メタデータＤＢ１３０のメタ情報管理テーブル１３１に登録する。この際、ＸＭＬ本体だけでなく、各種検索に対応するために、適宜、Ａｔｔｒｉｂｕｔｅ展開して登録する。また、受信したメタデータをクレジット情報管理部１２０に伝送する。
【００２１】
クレジット情報管理部１２０においては、メタデータ登録部１１０から受領したメタデータをパースし、人名検索用にクレジット情報を抽出し、メタデータＤＢ１３０のクレジット情報管理テーブル１３２に登録する（図３参照）。
【００２２】
クレジット情報管理テーブル１３２は、図３に示すように、ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ（以下、ＰＩと略記する）／＠ｐｒｏｇｒａｍＩｄ、ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎ（以下、ＧＩと略記する）／＠ｇｒｏｕｐＩｄを“ＣＲＩＤ”に記載する。
【００２３】
次に、役柄情報にあたる、ＰＩまたはＧＩのＢａｓｉｃＤｅｓｃｒｉｐｔｉｏｎ／ＣｒｅｄｉｔｓＬｉｓｔ／ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅを“Ｒｏｌｅ”に記載する。
【００２４】
更に、出演者名にあたる、各ＣｒｅｄｉｔｓＩｔｅｍのＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＭａｉｎ”、出演者名ルビにあたる、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｖａｒｉａｎｔ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＶａｒｉａｎｔ”、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｆｏｒｍｅｒ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＦｏｒｍｅｒ１”に記載する。この際、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｆｏｒｍｅｒ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅは複数記載される場合があり、この場合には、“ＮａｍｅＦｏｒｍｅｒ２”以降に追記する。
【００２５】
ここで、ＮａｍｅＶａｒｉａｎｔやＮａｍｅＦｏｒｍｅｒは検索対象に出演者ルビを含めるため、並びに、同姓異読みを区別するために、クレジット情報管理テーブル１３２に記載する。なお、同姓同名については、現状では区別されないが、ＮａｍｅＦｏｒｍｅｒの末尾に“＊＊＿Ａ”などルビ以外の文字列を付与するといった運用面での対処が考えられるが、本明細書では特に言及しないこととする。
【００２６】
メタデータ検索部１４０においては、受信端末２００から送信される検索要求を受信し、その検索要求が人名検索の場合、クレジット情報管理テーブル１３２を参照し、返却する人名一覧テーブル（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図４参照）を生成し、受信端末２００へ送信する。一方、検索要求がタイトル検索や出演者検索など、既存の検索要求の場合、メタ情報管理テーブル１３１を参照し、返却するフラグメントを生成し、受信端末２００へ送信する。
【００２７】
尚、メタデータ検索部１４０は、クレジット情報管理テーブル１３２に対する照合結果リストを格納する照合結果リスト格納部（照合結果リスト格納手段）を有している。
【００２８】
ここで、ＴＶ−Ａｎｙｔｉｍｅのメタデータスキーマでは、図５（ａ）に示すように、ＣｒｅｄｉｔｓＩｎｆｏｒａｍｔｉｏｎＴａｂｌｅＴｙｐｅは単に出演者名（ＰｅｒｓｏｎＮａｍｅ）をリスト化するのみで、役柄情報が記載できない。そこで、本発明では、ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅＴｙｐｅのスキーマを拡張し、図５（ｂ）に示すように、各出演者名を役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ）単位で管理できるようにし、さらには、役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅ）を記載できるようにする。
【００２９】
次に図６のシーケンス図を参照して、受信端末２００から人名検索要求（メタデータ検索要求）をメタデータサーバ１００に送信し、検索結果である人名一覧テーブルを受信し、提示する処理について説明する。
【００３０】
まず、提示部２３０が利用者に図７に示すような検索画面を提示する（ステップＳ１００）。その後、利用者が検索したいフリーワードや役柄（指定なし、主演、監督など）を入力し（ステップＳ１０１）、検索を実行する（ステップＳ１０２）。
【００３１】
次に、メタデータ要求部２２０が検索画面に入力された情報をもとにメタデータサーバ１００への検索要求を生成する（ステップＳ１０３）。この際、人名検索の検索要求は、以下に示すような書式が考えられる。
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（（＜ｎａｍｅ＿ｖａｌｕｅ＞［，＜ｒｏｌｅ＿ｖａｌｕｅ＞］），…）＆＜ｒａｎｇｅ＞＆＜ｔｙｐｅ＞
・ｎａｍｅ＿ｖａｌｕｅ：入力された任意文字列。
・ｒｏｌｅ＿ｖａｌｕｅ：指定された役柄に対応するＡＲＩＢＲｏｌｅＣＳのｔｅｒｍＩＤ。
ｒｏｌｅ＿ｖａｌｕｅは任意指定、付与された場合はｎａｍｅ＿ｖａｌｕｅとのＡＮＤ条件。
（＜ｎａｍｅ＿ｖａｌｕｅ＞［，＜ｒｏｌｅ＿ｖａｌｕｅ＞］）の複数記載はＯＲ条件。
・ｒａｎｇｅ＝＜ｆｒｏｍ＞［，＜ｃｏｕｎｔ＞］｜ｕｎｌｉｍｉｔ
ｆｒｏｍ：返却する検索結果の先頭順位
ｃｏｕｎｔ：先頭順位から返却する検索結果件数
ｕｎｌｉｍｉｔ：検索結果の先頭からすべての検索結果を返却
・ｔｙｐｅ＝ｎａｍｅｌｉｓｔ｜ｃｏｕｎｔｏｎｌｙ
ｎａｍｅｌｉｓｔ：人名一覧を返却
ｃｏｕｎｔｏｎｌｙ：人名の数を返却
例えば、図７に示すように“ヤマダ”、“主演”で検索した場合、検索要求は以下になる。
・ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（ヤマダ＊，ＡＲＩＢＲｏｌｅＣＳ：１．１）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊は前方一致を指定。
【００３２】
メタデータサーバ１００のメタデータ検索部１４０は、受信した検索要求を解析し（ステップＳ１０４）、検索要求の書式が上記した人名検索（ｇｅｔａｃｔｏｒ）の場合、メタデータＤＢ１３０のクレジット情報管理テーブル１３２を参照し、条件に合致する人名を検索する（ステップＳ１０５）。そして、検索結果を人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）の形式にし、受信端末２００へ送信する（ステップＳ１０６）。
【００３３】
受信端末２００は、メタデータ要求部２２０で検索結果を受信し（ステップＳ１０７）、提示部２３０で検索結果画面を利用者に提示する（ステップＳ１０８）。
【００３４】
次に図８のフローチャートを参照して、メタデータ検索部１４０がクレジット情報管理テーブル１３２から条件に合致する人名一覧を検索する処理について説明する。
【００３５】
はじめに、受信した検索要求から“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアを取得する（ステップＳ２０１）。ここで、“ｎａｍｅ＿ｖａｌｕｅ”は必須だが、“ｒｏｌｅ＿ｖａｌｕｅ”は任意であるため、記載されていない場合もある。また、ｃｒｅｄｉｔ（）内に“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”が複数記載されている場合、各ペアを順番に取得し、以降の処理を実施する。
【００３６】
まず、クレジット情報管理テーブル１３２を参照し、取得した“ｎａｍｅ＿ｖａｌｕｅ”の文字列が“ＮａｍｅＭａｉｎ”、“ＮａｍｅＶａｒｉａｎｔ”、“ＮａｍｅＦｏｒｍｅｒ１”、“ＮａｍｅＦｏｒｍｅｒ２”のいずれかに記載されているレコードを検索する（ステップＳ２０２）。この際、照合方法としては、前方一致、部分一致、完全一致、後方一致があり、それぞれ、“ｎａｍｅ＿ｖａｌｕｅ”部分の書式を“ヤマダ＊”、“＊ヤマダ＊”、“ヤマダ”、“＊ヤマダ”とすることが考えられる。
【００３７】
次に、合致するレコードが見つかった場合（ステップＳ２０３のＹｅｓ）、受信した検索要求のペアに“ｒｏｌｅ＿ｖａｌｕｅ”が記載されているかを確認する。そして、“ｒｏｌｅ＿ｖａｌｕｅ”が記載されている場合、その“ｒｏｌｅ＿ｖａｌｕｅ”に記載された値と取得したレコードのＲｏｌｅを照合し（ステップＳ２０５）、合致する場合（ステップＳ２０６のＹｅｓ）、合致したレコードの“Ｒｏｌｅ， ＮａｍｅＭａｉｎ， ＮａｍｅＶａｒｉａｎｔ， ＮａｍｅＦｏｒｍｅｒ， ＮａｍｅＦｏｒｍｅｒ２”を取得する（ステップＳ２０７）。
【００３８】
続いて、取得したレコードの情報が既に照合結果リストにあるかを確認し、照合結果にない場合（ステップＳ２０８のＮｏ）、その取得したレコードの情報を照合結果リストに追記し（ステップＳ２０９、図９参照）、ステップＳ２１０の処理へ移る。
【００３９】
ここで、ステップＳ２０３の処理で取得したｎａｍｅ＿ｖａｌｕｅに合致するレコードが見つからなかった場合（ステップＳ２０３のＮｏ）、ステップＳ２０６の処理で取得したｒｏｌｅ＿ｖａｌｕｅと合致するレコードが見つからなかった場合（ステップＳ２０６のＮｏ）、ステップＳ２０８の処理で照合結果リストに既に取得したレコードがあった場合（ステップＳ２０８のＹｅｓ）、それぞれ、特別な処理は実施せず、ステップＳ２１０の処理へ移る。
【００４０】
ステップＳ２１０の処理では、ステップＳ２０１で取得した“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアで、クレジット情報管理テーブル１３２の最後まで検索したかを判定し、まだ最後まで至っていない場合（ステップＳ２１０のＮｏ）、ステップＳ２０２へ戻り、残りのテーブルを検索する。一方、クレジット情報管理テーブル１３２の最後まで至っていた場合（ステップＳ２１０のＹｅｓ）、受信した検索要求に次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがあるかを確認する（ステップＳ２１１）。そして、次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがある場合（ステップＳ２１１のＹｅｓ）、そのペアでステップＳ２０１からの処理を実施する。
【００４１】
一方、検索要求に次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがない場合（ステップＳ２１１のＮｏ）、検索結果の返却応答を生成する処理に移る。
【００４２】
まず、検索要求のｔｙｐｅ指定を確認し（ステップＳ２１２）、ｔｙｐｅ指定が“ｃｏｕｎｔ”の場合（ステップＳ２１２のｃｏｕｎｔ）、照合結果リストに記載されたレコードの件数をカウントし、その件数を受信端末２００へ返信する（ステップＳ２１４）。一方、ｔｙｐｅ指定が“ｎａｍｅｌｉｓｔ”（ステップＳ２１２のｎａｍｅｌｉｓｔ）の場合、照合結果リストを、例えば、ＮａｍｅＶａｒｉａｎｔの５０音順にソートする（ステップＳ２１３）。
【００４３】
次に、検索要求のｒａｎｇｅ指定を確認し（ステップＳ２１５）、ｒａｎｇｅ指定が“ｆｒｏｍ（ｃｏｕｎｔ）”の形式の場合（ステップＳ２１５のｆｒｏｍ（ｃｏｕｎｔ））、照合結果リストのｆｒｏｍ番目からｃｏｕｎｔ分のレコードを抽出し（ステップＳ２１６）、抽出した人名一覧をＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅの形式で返却する（ステップＳ２１７；図６のステップＳ１０６）。一方、ｒａｎｇｅ指定が“ｕｎｌｉｍｉｔ”の場合、照合結果リストに記載された全てのレコードを取得し、取得した人名一覧をＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅの形式で返却する（ステップＳ２１７；図６のステップＳ１０６）。
【００４４】
例えば、図７に示すように“ヤマダ”、“主演”で検索した場合、ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅが主演（ＡＲＩＢＲｏｌｅＣＳ：１．１）で、出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ）、または、出演者名ルビ（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｖａｒｉａｎｔ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ）が“ヤマダ”で始まるＣｒｅｄｉｔｓＩｔｅｍが記載された人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図４参照）が返却される。そこで、受信端末２００では、受信した人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）から出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝”ｍａｉｎ”］）を抜き出し、検索結果画面を生成する（図１０参照）。
【００４５】
なお、この後、検索結果の人名（図１０中の“山田太郎”）を選択した場合、“山田太郎”が“主演”である作品の検索（出演者検索、ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（山田太郎，ＡＲＩＢＲｏｌｅＣＳ：１．１））を実施することが考えられ、利用者には図１１に示すような該当するコンテンツの一覧を表示した検索結果画面が提示される（図３のｃｒｉｄ：／／ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， ｃｒｉｄ：／／ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２が返却）。
【００４６】
他にも、例えば、“＊山＊”、“役柄指定なし”で検索した場合、検索要求は以下になる。
【００４７】
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（＊山＊）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊Ｘ＊はＸでの部分一致を指定。
【００４８】
この場合、ｎａｍｅ＿ｖａｌｕｅの条件（ｒｏｌｅ＿ｖａｌｕｅは不問）で、図３に示すクレジット情報管理テーブル１３２から、項番１−１の山田太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番２−１の山田太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番２−３の山本太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）が抽出される。このうち、項番１−１と項番２−１はマージされ、受信端末２００には図１２に示す人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。
【００４９】
更には、例えば、“タナカ”、“役柄指定なし”で検索した場合、検索要求は以下になる。
【００５０】
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（タナカ＊）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊は前方一致を指定。
【００５１】
この場合、ｎａｍｅ＿ｖａｌｕｅの条件（ｒｏｌｅ＿ｖａｌｕｅは不問）で、図３に示すクレジット情報管理テーブル１３２から、項番１−２の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番１−３の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：３．１）、項番２−２のの田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：４．３）が抽出される。この際、項番１−２、１−３、２−２は“田中次郎”という出演者名は同じであるが、役柄情報が異なることから、照合結果リストは図１３のようになり、受信端末２００には図１４に示すように出演者名が同じだが、ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅが異なる記載になった人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。ここで、受信端末２００は検索結果画面として、単に“田中次郎”という出演者名を記載する形でなく、図１５に示すように出演者名の後ろに役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅに記載されたＡＲＩＢＲｏｌｅＣＳに対応する役柄名）を記載することが考えられる。
【００５２】
なお、この後、検索結果の役柄（図１５中の“主演”）を選択した場合、“田中次郎”が“主演”である作品の検索（ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（田中次郎，ＡＲＩＢＲｏｌｅＣＳ：１．１）、コンテンツ１が返却）を実施し、検索結果の人名（図１５中の“田中次郎”）を選択した場合、“田中次郎”が“主演”、“監督”、“歌手”のいずれかである作品の検索（ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（（田中次郎，１．１），（田中次郎，３．１），（田中次郎，４．１）、コンテンツ１とコンテンツ２が返却）を実施することが考えられる。
【実施例１】
【００５３】
前記実施形態で述べた例では、図１０に示すように出演者名の一覧を検索結果画面として提示することを考えた。ここで、人名検索の検索結果として、図１８に示すように、各出演者名の横にその人物が出演する作品数（ＣＲＩＤ数）を提示することが考えられる（例えば、検索要求でのｔｙｐｅ指定を“ｎａｍｅｌｉｓｔ２”とする）。
【００５４】
以下、図８を参照して、本実施例におけるメタデータ検索部１４０の処理の拡張部分について説明する。
【００５５】
本実施例では、クレジット管理情報テーブル１３２から条件に合致したレコードを取得する際（ステップＳ２０７）、ＣＲＩＤも取得し、図１６に示すように、照合結果リストではＣＲＩＤを含めて管理する。
【００５６】
このようにすることで、取得したレコードの情報が既に照合結果リストに有るかの確認時（ステップＳ２０８）、役柄情報、出演者名、出演者ルビが同じであっても、ＣＲＩＤが異なるものは別情報として扱われる形になる。
【００５７】
その結果、受信端末２００へは、図１７に示すように、同じ役柄情報、出演者名、出演者ルビを持つＣｒｅｄｉｔｓＩｔｅｍがＣＲＩＤの個数分記載された人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。そこで、受信端末２００はＣｒｅｄｉｔｓＩｔｅｍの内容が同じ情報をカウントし、そのＣｒｅｄｉｔｓＩｔｅｍに対する作品数として図１８のように提示する。
【００５８】
ここで、受信端末２００からの検索要求に役柄指定がない場合で、ＣｒｅｄｉｔｓＩｔｅｍの役柄情報の差異を無視した場合はその人物に対する全作品数がカウントでき、差異を区別した場合は各役柄での作品数をカウントすることになる。
【実施例２】
【００５９】
前記実施形態で述べた例では、クレジット情報管理テーブル１３２にはそのクレジットが記載されているコンテンツの期間情報、パレンタルレーティングなどは記載されていない。そのため、例えば、コンテンツが表示期間（Ｐｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］）外であった場合でも、人名検索の結果には、そのコンテンツに出演している人物名が表示される。
【００６０】
しかしながら、検索結果画面から、その人物名で出演者検索を実施した場合、該当するコンテンツが表示期間外のため、コンテンツが検索されないといったことが発生する。他にも、例えば、コンテンツが成人作品であった場合、人名検索の結果には、そのコンテンツに出演している人物名が表示されるが、その人物名で出演者検索を実施した場合、該当するコンテンツがパレンタル対象のため、コンテンツが提示されないといったことも考えられる。
【００６１】
そこで、本実施例では、ＴＶ−Ａｎｙｔｉｍｅが規定する検索条件（Ｐｅｒｉｏｄ検索、パレンタルレーティング検索、ジャンル検索など）を、人名検索についてもオプションとして付与することを考える。
【００６２】
以下、図８を参照して、本実施例におけるメタデータ検索部１４０の処理の拡張部分について説明する。例えば、表示期間が２００９／４／１ ００：００：００〜２００９／０５／３１ ２３：５９：５９に含まれるコンテンツを対象に、“タナカ”で始まる人名検索を実施する場合、検索要求は以下のようになる。
【００６３】
ｇｅｔａｃｔｏｒ＝ ｃｒｅｄｉｔ（タナカ＊），ｐｅｒｉｏｄ（ｄｉｓｐｌａｙ，２００９０４０１００００００，２００９０５３１２３５９５９）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ｐｅｒｉｏｄ検索の書式：ｐｅｒｉｏｄ（＜ｐｅｒｉｏｄ−ｔｙｐｅ＞［，＜ｓｔａｒｔ＞］，［＜ｅｎｄ＞］ ）
本実施例では、取得したｎａｍｅ＿ｖａｌｕｅとクレジット情報管理テーブル１３２との照合を行う際（ステップＳ２０２）、クレジット情報管理テーブル１３２から別途ＣＲＩＤを取得し、ＣＲＩＤをキーにメタ情報管理テーブル１３２（図１９参照）から対応するメタデータのレコードを取得し、オプション指定された検索条件を照合する。上記の場合、図３に示すクレジット情報管理テーブル１３２から、項番：１−２と項番１−３の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１）と項番：２−２の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２）が抽出される。そして、メタ情報管理テーブル１３１（図１９）を参照し、各ＣＲＩＤのＰｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］／Ｓｔａｒｔ， Ｐｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］／Ｅｎｄ情報を取得し、検索条件と照合する。
【００６４】
照合の結果、“ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２”のコンテンツは表示期間が２００９−０８−０１Ｔ００：００：００〜２００９−０８−３１Ｔ２３：５９：５９と検索要求が示す期間には含まれないため、図３に示す項番：２−２の田中次郎は、照合結果の候補からは除外される（ステップＳ２０３のＮｏ）。一方、“ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１”のコンテンツは表示期間が２００９−０４−０１Ｔ００：００：００〜２００９−１２−３１Ｔ００：００：００と検索要求が示す期間に含まれるため、図３に示す項番：１−２と項番１−３のレコードは次の処理へ進められ（ステップＳ２０３のＹｅｓ）、照合結果リストとしては、図２０のようになる。
【００６５】
なお、検索要求のオプションとして、パレンタルレーティングが付与された場合（ＰａｒｅｎｔａｌＲａｔｉｎｇ（ＡＲＩＢＰａｒｅｎｔａｌＲａｔｉｎｇＣＳ：Ｒ−２０））、メタ情報管理テーブル１３１（図１９）のＰａｒｅｎｔａｌＲａｔｉｎｇと照合される。
【実施例３】
【００６６】
前記実施形態で述べた例では、クレジット情報管理テーブル１３２へのレコード情報の追記は述べているが、クレジット情報管理テーブル１３２の管理、レコード情報の削除は述べていない。ここで、ＴＶ−Ａｎｙｔｉｍｅでは、コンテンツに有効期限（ＦｒａｇｍｅｎｔＥｘｐｉｒａｔｉｏｎＤａｔｅ）を記載し、この有効期限をもとにメタデータの管理、削除を実施することを規定している。そこで、本実施例では、このメタデータの有効期限と連携し、対応するコンテンツに記載されていたクレジット情報を管理、削除することを考える。これにより、人名検索結果に期限切れになったコンテンツの人名が提示されることを防止できる。
【００６７】
本実施例では、メタ情報管理テーブル１３２に対する定期的な期限切れメタデータの削除操作時、メタ情報管理テーブル１３１に記載されたＣＲＩＤをキーに、クレジット情報管理テーブル１３２の該当するＣＲＩＤに対するクレジット情報を削除する。
【００６８】
また、本実施形態のメタデータサーバシステムにおける各手段の一部もしくは全部の機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができることは言うまでもなく、コンピュータでその機能を実現するためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えばＦＤ（Ｆｌｏｐｐｙ（登録商標） Ｄｉｓｋ）や、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、メモリカード、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）−ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＨＤＤ、リムーバブルディスクなどに記録して、保存したり、配布したりすることが可能である。また、上記のプログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【符号の説明】
【００６９】
１００…メタデータサーバ
１１０…メタデータ登録部
１２０…クレジット情報管理部
１３０…メタデータＤＢ
１３１…メタ情報管理テーブル
１３２…クレジット情報管理テーブル
１４０…メタデータ検索部
２００…受信端末
２１０…入力部
２２０…メタデータ要求部
２３０…提示部
３００…ネットワーク
【技術分野】
【０００１】
本発明は、ＴＶ−Ａｎｙｔｉｍｅサービスに関するものであり、特に、フリーワードによる人名一覧の検索を実現するシステムおよびプログラムに関する。
【背景技術】
【０００２】
ＩＰＴＶサービスのコア技術として、多チャンネルやビデオオンデマンドで提供されるコンテンツの情報（例えば、題名、内容、ジャンル、出演者など）を記述・検索するメタデータ技術がある。
【０００３】
一例として、民間国際標準規格であるＴＶ−Ａｎｙｔｉｍｅ（非特許文献１参照）では、メタデータとして記載する内容や書式を規定するメタデータ・スキーマを標準化し、メタデータの共通データベースを構築することで、利用者が所望のコンテンツを容易に検索・選択することを実現している。
【０００４】
日本国内でもＴＶ−Ａｎｙｔｉｍｅ仕様をもとに、ＡＲＩＢやＩＰＴＶフォーラムがメタデータ標準仕様（ＡＲＩＢ ＳＴＤ−Ｂ３８（非特許文献２参照））、並びに、運用規定（ＡＲＩＢ ＴＲ−Ｂ２７、ＩＰＴＶ規定 ＣＤＮスコープサービスアプローチ仕様）を各々で策定している。図２にＴＶ−Ａｎｙｔｉｍｅメタデータの例を示す。
【０００５】
ＴＶ−Ａｎｙｔｉｍｅメタデータでは、コンテンツの情報（例えば、題名、内容、ジャンル、出演者など）はプログラム記述メタデータ（Ｐｒｏｇｒａｍ Ｄｅｓｃｒｉｐｔｉｏｎ Ｍｅｔａｄａｔａ）で扱い、コンテンツの配信情報（放送時間、チャンネル、コンテンツのＵＲＩなど）はインスタンスメタデータ（Ｉｎｓｔａｎｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）で扱う。この際、コンテンツに対するメタデータはＣＲＩＤ（Ｃｏｎｔｅｎｔ Ｒｅｆｅｒｅｎｃｅ Ｉｄｅｎｔｉｆｉｅｒ）と呼ぶコンテンツ参照識別子で一意に識別される。
【０００６】
また、ＴＶ−Ａｎｙｔｉｍｅでは、メタデータの双方向通信方式を規定しており、利用者は、メタデータを特定するための条件を含む検索要求を、メタデータサーバに送信することで、該当するメタデータ、該当するメタデータのＣＲＩＤ一覧、該当するメタデータの件数を取得できる。ここで、ＴＶ−Ａｎｙｔｉｍｅが規定する検索条件としては、タイトル検索、キーワード検索、出演者検索、ＣＲＩＤ検索、ジャンル検索、Ｐｅｒｉｏｄ検索などがある。なお、返却フォーマットとしてメタデータ本体を指定した場合、該当するメタデータのフラグメント（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ、ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎ、ＢｒｏａｄＣａｓｔＥｖｅｎｔなど）がテーブル単位（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ， ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ， ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ， ＴＶＡＭａｉｎなど）で返却される（図２１参照）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Ｂｒｏａｄｃａｓｔ ａｎｄ Ｏｎ−ｌｉｎｅ Ｓｅｒｖｉｃｅｓ： Ｓｅａｒｃｈ， ｓｅｌｅｃｔ， ａｎｄ ｒｉｇｈｔｆｕｌ ｕｓｅ ｏｆ ｃｏｎｔｅｎｔ ｏｎ ｐｅｒｓｏｎａｌ ｓｔｏｒａｇｅ ｓｙｓｔｅｍｓ（″ＴＶ−Ａｎｙｔｉｍｅ″）；Ｐａｒｔ３： Ｍｅｔａｄａｔａ；」、ＴＶ−Ａｎｙｔｉｍｅ Ｆｏｒｕｍ、ＥＴＳＩ ＴＳ１０２８２２−３−１ Ｖｌ．４．１（２００７−１１）、６．７．２ＴＶ−Ａｎｙｔｉｍｅ ｍｅｔａ ｄａｔａ ｄｏｃｕｍｅｔ ｐｐ．８４−８８
【非特許文献２】「サーバー型放送における符号化、伝送及び蓄積制御方式」、ＡＲＩＢ ＳＴＤ−Ｂ３８ １．３版、平成１８年３月１４日、３．２．７．２ＡＲＩＢサーバー型放送番組情報文書 ｐｐ．６９−７３
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＴＶ−Ａｎｙｔｉｍｅでは、メタデータの検索や処理はフラグメント単位で扱われる。そこで、例えば、“ヤマダ”で始まる人名の一覧を検索するといった人名検索を実現する場合、まず、“ヤ”で始まる人物が出演している作品の検索（出演者検索）を実施する。その後、取得されたメタデータ（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図２参照）をパースし、“ヤマダ”で始まる出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］、図２の山田太郎、田中次郎など）を抽出することになる。この際、検索結果に複数のＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎが記載され、さらには、同じ出演者名が複数抽出された場合、それらを統合する処理などが必要になる（図２では、山田太郎は２つのＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎに記載されており、検索結果としては、それらを統合し、例えば図１０のように表示する）。
【０００９】
また、ＴＶ−Ａｎｙｔｉｍｅでは、検索結果の返却フォーマットは、メタデータ本体、ＣＲＩＤ一覧、件数といった作品をベースとした返却フォーマットになっており、人名検索結果として想定される複数の作品情報を横通しし、人物名一覧として返却する仕組みは規定されてない。
【００１０】
本発明は、このような状況を鑑みてなされたものであり、ＴＶ−Ａｎｙｔｉｍｅのメタデータサービスにおいて、受信端末に大きな処理負荷をかけることなく、人名検索を実現できるようにするものである。
【課題を解決するための手段】
【００１１】
上記課題を解決するための請求項１記載のメタデータサーバシステムは、ＴＶ−Ａｎｙｔｉｍｅメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、前記メタデータサーバは、外部から投入されるメタデータを受信し、メタデータデータベースのメタ情報管理テーブルに登録するメタデータ登録手段と、前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、を備えることを特徴としている。
【発明の効果】
【００１２】
（１）請求項１〜１０に記載の発明によれば、ＴＶ−Ａｎｙｔｉｍｅメタデータサービスにおける人名検索を、受信装置に大きな処理負荷をかけることなく実現できる。
（２）請求項２、６に記載の発明によれば、人名一覧だけでなく、各人物が出演する作品数を返却することが可能になり、検索結果としての表現を高めることが可能になる。
（３）請求項７に記載の発明によれば、クレジット情報だけでなく、コンテンツに関する情報も参照することで、多種多様な人名検索が実現できる。
（４）請求項８に記載の発明によれば、メタサーバにおけるコンテンツ情報とクレジット情報の管理、特に、期限切れ情報の削除を連携でき、メタサーバの適切な管理が実現できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施の形態の構成を示すブロック図である。
【図２】ＴＶ−Ａｎｙｔｉｍｅメタデータの例を示す図である。
【図３】本発明の一実施の形態におけるクレジット情報管理テーブルの構成要素を説明する図である。
【図４】本発明での検索応答であるＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ（人名一覧テーブル）を説明する図である。
【図５】ＴＶ−Ａｎｙｔｉｍｅでのメタデータスキーマ、並びに、本発明でのスキーマ拡張を説明する図である。
【図６】本発明の一実施の形態における人物検索時の受信端末−メタサーバ間の処理を説明するシーケンス図である。
【図７】検索要求画面の例を説明する図である。
【図８】本発明の一実施の形態におけるメタデータ検索部での人名一覧生成の処理を説明するフローチャートである。
【図９】本発明の一実施の形態における照合結果リストの構成要素を説明する図である。
【図１０】検索結果画面の例を説明する図である。
【図１１】本発明の一実施の形態における出演者検索の検索結果画面を説明する図である。
【図１２】本発明の一実施の形態における別クエリで検索した場合の検索応答例を説明する図である。
【図１３】本発明の一実施の形態における“役柄指定なし”で検索した場合の照合結果リスト例を説明する図である。
【図１４】図１３の照合結果リストに対応する検索応答を説明する図である。
【図１５】図１４の検索応答受領時の検索結果画面を説明する図である。
【図１６】本発明の実施例１による照合結果リストを説明する図である。
【図１７】図１６の照合結果リストに対応する検索応答を説明する図である。
【図１８】図１７の検索応答受領時の検索結果画面を説明する図である。
【図１９】メタ情報管理テーブルの構成要素を説明する図である。
【図２０】本発明の実施例２による照合結果リストを説明する図である。
【図２１】ＴＶ−Ａｎｙｔｉｍｅでの検索結果の返却フォーマットを説明する図である。
【発明を実施するための形態】
【００１４】
以下、添付図面を参照しながら、本発明の好適な実施形態について詳細に説明するが、本発明は下記の実施形態例に限定されるものではない。
【００１５】
図１は本発明を用いたシステムの一実施の形態の構成を示すブロック図である。このシステムは、メタデータの管理・検索・伝送を実施するメタデータサーバ１００と、ネットワーク３００を介してメタデータサーバ１００へメタデータの検索要求・メタデータの受信を実施する受信端末２００とから構成されている。
【００１６】
なお、図１には、受信端末２００が１台のみ示されているが、実際には複数の受信端末がネットワーク３００を介してメタデータサーバ１００に接続されている。
【００１７】
メタデータサーバ１００は、メタデータ登録手段としてのメタデータ登録部１１０、クレジット情報管理手段としてのクレジット情報管理部１２０、メタデータＤＢ（データベース）１３０、メタデータ検索手段としてのメタデータ検索部１４０の機能的構成を有しており、メタデータＤＢ１３０は、メタ情報管理テーブル１３１とクレジット情報管理テーブル１３２の機能的構成を有している。
【００１８】
尚、前記メタデータサーバ１００内の各部の機能は例えばコンピュータによって達成される。
【００１９】
また、受信端末２００は入力部２１０、メタデータ要求部２２０、提示部２３０の機能的構成を有している。
【００２０】
メタデータサーバ１００のメタデータ登録部１１０においては、外部のメタデータ運用ツールから投入されるメタデータ（ＴＶ−Ａｎｙｔｉｍｅ ＸＭＬデータ、図２参照）を受信し、メタデータＤＢ１３０のメタ情報管理テーブル１３１に登録する。この際、ＸＭＬ本体だけでなく、各種検索に対応するために、適宜、Ａｔｔｒｉｂｕｔｅ展開して登録する。また、受信したメタデータをクレジット情報管理部１２０に伝送する。
【００２１】
クレジット情報管理部１２０においては、メタデータ登録部１１０から受領したメタデータをパースし、人名検索用にクレジット情報を抽出し、メタデータＤＢ１３０のクレジット情報管理テーブル１３２に登録する（図３参照）。
【００２２】
クレジット情報管理テーブル１３２は、図３に示すように、ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ（以下、ＰＩと略記する）／＠ｐｒｏｇｒａｍＩｄ、ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＧｒｏｕｐＩｎｆｏｒｍａｔｉｏｎ（以下、ＧＩと略記する）／＠ｇｒｏｕｐＩｄを“ＣＲＩＤ”に記載する。
【００２３】
次に、役柄情報にあたる、ＰＩまたはＧＩのＢａｓｉｃＤｅｓｃｒｉｐｔｉｏｎ／ＣｒｅｄｉｔｓＬｉｓｔ／ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅを“Ｒｏｌｅ”に記載する。
【００２４】
更に、出演者名にあたる、各ＣｒｅｄｉｔｓＩｔｅｍのＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＭａｉｎ”、出演者名ルビにあたる、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｖａｒｉａｎｔ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＶａｒｉａｎｔ”、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｆｏｒｍｅｒ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅを“ＮａｍｅＦｏｒｍｅｒ１”に記載する。この際、ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｆｏｒｍｅｒ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅは複数記載される場合があり、この場合には、“ＮａｍｅＦｏｒｍｅｒ２”以降に追記する。
【００２５】
ここで、ＮａｍｅＶａｒｉａｎｔやＮａｍｅＦｏｒｍｅｒは検索対象に出演者ルビを含めるため、並びに、同姓異読みを区別するために、クレジット情報管理テーブル１３２に記載する。なお、同姓同名については、現状では区別されないが、ＮａｍｅＦｏｒｍｅｒの末尾に“＊＊＿Ａ”などルビ以外の文字列を付与するといった運用面での対処が考えられるが、本明細書では特に言及しないこととする。
【００２６】
メタデータ検索部１４０においては、受信端末２００から送信される検索要求を受信し、その検索要求が人名検索の場合、クレジット情報管理テーブル１３２を参照し、返却する人名一覧テーブル（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図４参照）を生成し、受信端末２００へ送信する。一方、検索要求がタイトル検索や出演者検索など、既存の検索要求の場合、メタ情報管理テーブル１３１を参照し、返却するフラグメントを生成し、受信端末２００へ送信する。
【００２７】
尚、メタデータ検索部１４０は、クレジット情報管理テーブル１３２に対する照合結果リストを格納する照合結果リスト格納部（照合結果リスト格納手段）を有している。
【００２８】
ここで、ＴＶ−Ａｎｙｔｉｍｅのメタデータスキーマでは、図５（ａ）に示すように、ＣｒｅｄｉｔｓＩｎｆｏｒａｍｔｉｏｎＴａｂｌｅＴｙｐｅは単に出演者名（ＰｅｒｓｏｎＮａｍｅ）をリスト化するのみで、役柄情報が記載できない。そこで、本発明では、ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅＴｙｐｅのスキーマを拡張し、図５（ｂ）に示すように、各出演者名を役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ）単位で管理できるようにし、さらには、役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅ）を記載できるようにする。
【００２９】
次に図６のシーケンス図を参照して、受信端末２００から人名検索要求（メタデータ検索要求）をメタデータサーバ１００に送信し、検索結果である人名一覧テーブルを受信し、提示する処理について説明する。
【００３０】
まず、提示部２３０が利用者に図７に示すような検索画面を提示する（ステップＳ１００）。その後、利用者が検索したいフリーワードや役柄（指定なし、主演、監督など）を入力し（ステップＳ１０１）、検索を実行する（ステップＳ１０２）。
【００３１】
次に、メタデータ要求部２２０が検索画面に入力された情報をもとにメタデータサーバ１００への検索要求を生成する（ステップＳ１０３）。この際、人名検索の検索要求は、以下に示すような書式が考えられる。
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（（＜ｎａｍｅ＿ｖａｌｕｅ＞［，＜ｒｏｌｅ＿ｖａｌｕｅ＞］），…）＆＜ｒａｎｇｅ＞＆＜ｔｙｐｅ＞
・ｎａｍｅ＿ｖａｌｕｅ：入力された任意文字列。
・ｒｏｌｅ＿ｖａｌｕｅ：指定された役柄に対応するＡＲＩＢＲｏｌｅＣＳのｔｅｒｍＩＤ。
ｒｏｌｅ＿ｖａｌｕｅは任意指定、付与された場合はｎａｍｅ＿ｖａｌｕｅとのＡＮＤ条件。
（＜ｎａｍｅ＿ｖａｌｕｅ＞［，＜ｒｏｌｅ＿ｖａｌｕｅ＞］）の複数記載はＯＲ条件。
・ｒａｎｇｅ＝＜ｆｒｏｍ＞［，＜ｃｏｕｎｔ＞］｜ｕｎｌｉｍｉｔ
ｆｒｏｍ：返却する検索結果の先頭順位
ｃｏｕｎｔ：先頭順位から返却する検索結果件数
ｕｎｌｉｍｉｔ：検索結果の先頭からすべての検索結果を返却
・ｔｙｐｅ＝ｎａｍｅｌｉｓｔ｜ｃｏｕｎｔｏｎｌｙ
ｎａｍｅｌｉｓｔ：人名一覧を返却
ｃｏｕｎｔｏｎｌｙ：人名の数を返却
例えば、図７に示すように“ヤマダ”、“主演”で検索した場合、検索要求は以下になる。
・ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（ヤマダ＊，ＡＲＩＢＲｏｌｅＣＳ：１．１）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊は前方一致を指定。
【００３２】
メタデータサーバ１００のメタデータ検索部１４０は、受信した検索要求を解析し（ステップＳ１０４）、検索要求の書式が上記した人名検索（ｇｅｔａｃｔｏｒ）の場合、メタデータＤＢ１３０のクレジット情報管理テーブル１３２を参照し、条件に合致する人名を検索する（ステップＳ１０５）。そして、検索結果を人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）の形式にし、受信端末２００へ送信する（ステップＳ１０６）。
【００３３】
受信端末２００は、メタデータ要求部２２０で検索結果を受信し（ステップＳ１０７）、提示部２３０で検索結果画面を利用者に提示する（ステップＳ１０８）。
【００３４】
次に図８のフローチャートを参照して、メタデータ検索部１４０がクレジット情報管理テーブル１３２から条件に合致する人名一覧を検索する処理について説明する。
【００３５】
はじめに、受信した検索要求から“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアを取得する（ステップＳ２０１）。ここで、“ｎａｍｅ＿ｖａｌｕｅ”は必須だが、“ｒｏｌｅ＿ｖａｌｕｅ”は任意であるため、記載されていない場合もある。また、ｃｒｅｄｉｔ（）内に“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”が複数記載されている場合、各ペアを順番に取得し、以降の処理を実施する。
【００３６】
まず、クレジット情報管理テーブル１３２を参照し、取得した“ｎａｍｅ＿ｖａｌｕｅ”の文字列が“ＮａｍｅＭａｉｎ”、“ＮａｍｅＶａｒｉａｎｔ”、“ＮａｍｅＦｏｒｍｅｒ１”、“ＮａｍｅＦｏｒｍｅｒ２”のいずれかに記載されているレコードを検索する（ステップＳ２０２）。この際、照合方法としては、前方一致、部分一致、完全一致、後方一致があり、それぞれ、“ｎａｍｅ＿ｖａｌｕｅ”部分の書式を“ヤマダ＊”、“＊ヤマダ＊”、“ヤマダ”、“＊ヤマダ”とすることが考えられる。
【００３７】
次に、合致するレコードが見つかった場合（ステップＳ２０３のＹｅｓ）、受信した検索要求のペアに“ｒｏｌｅ＿ｖａｌｕｅ”が記載されているかを確認する。そして、“ｒｏｌｅ＿ｖａｌｕｅ”が記載されている場合、その“ｒｏｌｅ＿ｖａｌｕｅ”に記載された値と取得したレコードのＲｏｌｅを照合し（ステップＳ２０５）、合致する場合（ステップＳ２０６のＹｅｓ）、合致したレコードの“Ｒｏｌｅ， ＮａｍｅＭａｉｎ， ＮａｍｅＶａｒｉａｎｔ， ＮａｍｅＦｏｒｍｅｒ， ＮａｍｅＦｏｒｍｅｒ２”を取得する（ステップＳ２０７）。
【００３８】
続いて、取得したレコードの情報が既に照合結果リストにあるかを確認し、照合結果にない場合（ステップＳ２０８のＮｏ）、その取得したレコードの情報を照合結果リストに追記し（ステップＳ２０９、図９参照）、ステップＳ２１０の処理へ移る。
【００３９】
ここで、ステップＳ２０３の処理で取得したｎａｍｅ＿ｖａｌｕｅに合致するレコードが見つからなかった場合（ステップＳ２０３のＮｏ）、ステップＳ２０６の処理で取得したｒｏｌｅ＿ｖａｌｕｅと合致するレコードが見つからなかった場合（ステップＳ２０６のＮｏ）、ステップＳ２０８の処理で照合結果リストに既に取得したレコードがあった場合（ステップＳ２０８のＹｅｓ）、それぞれ、特別な処理は実施せず、ステップＳ２１０の処理へ移る。
【００４０】
ステップＳ２１０の処理では、ステップＳ２０１で取得した“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアで、クレジット情報管理テーブル１３２の最後まで検索したかを判定し、まだ最後まで至っていない場合（ステップＳ２１０のＮｏ）、ステップＳ２０２へ戻り、残りのテーブルを検索する。一方、クレジット情報管理テーブル１３２の最後まで至っていた場合（ステップＳ２１０のＹｅｓ）、受信した検索要求に次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがあるかを確認する（ステップＳ２１１）。そして、次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがある場合（ステップＳ２１１のＹｅｓ）、そのペアでステップＳ２０１からの処理を実施する。
【００４１】
一方、検索要求に次の“（ｎａｍｅ＿ｖａｌｕｅ，ｒｏｌｅ＿ｖａｌｕｅ）”のペアがない場合（ステップＳ２１１のＮｏ）、検索結果の返却応答を生成する処理に移る。
【００４２】
まず、検索要求のｔｙｐｅ指定を確認し（ステップＳ２１２）、ｔｙｐｅ指定が“ｃｏｕｎｔ”の場合（ステップＳ２１２のｃｏｕｎｔ）、照合結果リストに記載されたレコードの件数をカウントし、その件数を受信端末２００へ返信する（ステップＳ２１４）。一方、ｔｙｐｅ指定が“ｎａｍｅｌｉｓｔ”（ステップＳ２１２のｎａｍｅｌｉｓｔ）の場合、照合結果リストを、例えば、ＮａｍｅＶａｒｉａｎｔの５０音順にソートする（ステップＳ２１３）。
【００４３】
次に、検索要求のｒａｎｇｅ指定を確認し（ステップＳ２１５）、ｒａｎｇｅ指定が“ｆｒｏｍ（ｃｏｕｎｔ）”の形式の場合（ステップＳ２１５のｆｒｏｍ（ｃｏｕｎｔ））、照合結果リストのｆｒｏｍ番目からｃｏｕｎｔ分のレコードを抽出し（ステップＳ２１６）、抽出した人名一覧をＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅの形式で返却する（ステップＳ２１７；図６のステップＳ１０６）。一方、ｒａｎｇｅ指定が“ｕｎｌｉｍｉｔ”の場合、照合結果リストに記載された全てのレコードを取得し、取得した人名一覧をＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅの形式で返却する（ステップＳ２１７；図６のステップＳ１０６）。
【００４４】
例えば、図７に示すように“ヤマダ”、“主演”で検索した場合、ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅが主演（ＡＲＩＢＲｏｌｅＣＳ：１．１）で、出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｍａｉｎ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ）、または、出演者名ルビ（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝“ｖａｒｉａｎｔ”］／ｍｐｅｇ７：ＧｉｖｅｎＮａｍｅ）が“ヤマダ”で始まるＣｒｅｄｉｔｓＩｔｅｍが記載された人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ、図４参照）が返却される。そこで、受信端末２００では、受信した人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）から出演者名（ＣｒｅｄｉｔｓＩｔｅｍ／ＰｅｒｓｏｎＮａｍｅ［＠ｔｙｐｅ＝”ｍａｉｎ”］）を抜き出し、検索結果画面を生成する（図１０参照）。
【００４５】
なお、この後、検索結果の人名（図１０中の“山田太郎”）を選択した場合、“山田太郎”が“主演”である作品の検索（出演者検索、ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（山田太郎，ＡＲＩＢＲｏｌｅＣＳ：１．１））を実施することが考えられ、利用者には図１１に示すような該当するコンテンツの一覧を表示した検索結果画面が提示される（図３のｃｒｉｄ：／／ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， ｃｒｉｄ：／／ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２が返却）。
【００４６】
他にも、例えば、“＊山＊”、“役柄指定なし”で検索した場合、検索要求は以下になる。
【００４７】
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（＊山＊）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊Ｘ＊はＸでの部分一致を指定。
【００４８】
この場合、ｎａｍｅ＿ｖａｌｕｅの条件（ｒｏｌｅ＿ｖａｌｕｅは不問）で、図３に示すクレジット情報管理テーブル１３２から、項番１−１の山田太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番２−１の山田太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番２−３の山本太郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）が抽出される。このうち、項番１−１と項番２−１はマージされ、受信端末２００には図１２に示す人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。
【００４９】
更には、例えば、“タナカ”、“役柄指定なし”で検索した場合、検索要求は以下になる。
【００５０】
ｇｅｔａｃｔｏｒ＝ｃｒｅｄｉｔ（タナカ＊）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ＊は前方一致を指定。
【００５１】
この場合、ｎａｍｅ＿ｖａｌｕｅの条件（ｒｏｌｅ＿ｖａｌｕｅは不問）で、図３に示すクレジット情報管理テーブル１３２から、項番１−２の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：１．１）、項番１−３の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：３．１）、項番２−２のの田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２， Ｒｏｌｅ：ＡＲＩＢＲｏｌｅＣＳ：４．３）が抽出される。この際、項番１−２、１−３、２−２は“田中次郎”という出演者名は同じであるが、役柄情報が異なることから、照合結果リストは図１３のようになり、受信端末２００には図１４に示すように出演者名が同じだが、ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅが異なる記載になった人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。ここで、受信端末２００は検索結果画面として、単に“田中次郎”という出演者名を記載する形でなく、図１５に示すように出演者名の後ろに役柄情報（ＣｒｅｄｉｔｓＩｔｅｍ／＠ｒｏｌｅに記載されたＡＲＩＢＲｏｌｅＣＳに対応する役柄名）を記載することが考えられる。
【００５２】
なお、この後、検索結果の役柄（図１５中の“主演”）を選択した場合、“田中次郎”が“主演”である作品の検索（ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（田中次郎，ＡＲＩＢＲｏｌｅＣＳ：１．１）、コンテンツ１が返却）を実施し、検索結果の人名（図１５中の“田中次郎”）を選択した場合、“田中次郎”が“主演”、“監督”、“歌手”のいずれかである作品の検索（ｐｒｅｄｉｃａｔｅ＝ｃｒｅｄｉｔ（（田中次郎，１．１），（田中次郎，３．１），（田中次郎，４．１）、コンテンツ１とコンテンツ２が返却）を実施することが考えられる。
【実施例１】
【００５３】
前記実施形態で述べた例では、図１０に示すように出演者名の一覧を検索結果画面として提示することを考えた。ここで、人名検索の検索結果として、図１８に示すように、各出演者名の横にその人物が出演する作品数（ＣＲＩＤ数）を提示することが考えられる（例えば、検索要求でのｔｙｐｅ指定を“ｎａｍｅｌｉｓｔ２”とする）。
【００５４】
以下、図８を参照して、本実施例におけるメタデータ検索部１４０の処理の拡張部分について説明する。
【００５５】
本実施例では、クレジット管理情報テーブル１３２から条件に合致したレコードを取得する際（ステップＳ２０７）、ＣＲＩＤも取得し、図１６に示すように、照合結果リストではＣＲＩＤを含めて管理する。
【００５６】
このようにすることで、取得したレコードの情報が既に照合結果リストに有るかの確認時（ステップＳ２０８）、役柄情報、出演者名、出演者ルビが同じであっても、ＣＲＩＤが異なるものは別情報として扱われる形になる。
【００５７】
その結果、受信端末２００へは、図１７に示すように、同じ役柄情報、出演者名、出演者ルビを持つＣｒｅｄｉｔｓＩｔｅｍがＣＲＩＤの個数分記載された人名一覧（ＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）が返却される。そこで、受信端末２００はＣｒｅｄｉｔｓＩｔｅｍの内容が同じ情報をカウントし、そのＣｒｅｄｉｔｓＩｔｅｍに対する作品数として図１８のように提示する。
【００５８】
ここで、受信端末２００からの検索要求に役柄指定がない場合で、ＣｒｅｄｉｔｓＩｔｅｍの役柄情報の差異を無視した場合はその人物に対する全作品数がカウントでき、差異を区別した場合は各役柄での作品数をカウントすることになる。
【実施例２】
【００５９】
前記実施形態で述べた例では、クレジット情報管理テーブル１３２にはそのクレジットが記載されているコンテンツの期間情報、パレンタルレーティングなどは記載されていない。そのため、例えば、コンテンツが表示期間（Ｐｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］）外であった場合でも、人名検索の結果には、そのコンテンツに出演している人物名が表示される。
【００６０】
しかしながら、検索結果画面から、その人物名で出演者検索を実施した場合、該当するコンテンツが表示期間外のため、コンテンツが検索されないといったことが発生する。他にも、例えば、コンテンツが成人作品であった場合、人名検索の結果には、そのコンテンツに出演している人物名が表示されるが、その人物名で出演者検索を実施した場合、該当するコンテンツがパレンタル対象のため、コンテンツが提示されないといったことも考えられる。
【００６１】
そこで、本実施例では、ＴＶ−Ａｎｙｔｉｍｅが規定する検索条件（Ｐｅｒｉｏｄ検索、パレンタルレーティング検索、ジャンル検索など）を、人名検索についてもオプションとして付与することを考える。
【００６２】
以下、図８を参照して、本実施例におけるメタデータ検索部１４０の処理の拡張部分について説明する。例えば、表示期間が２００９／４／１ ００：００：００〜２００９／０５／３１ ２３：５９：５９に含まれるコンテンツを対象に、“タナカ”で始まる人名検索を実施する場合、検索要求は以下のようになる。
【００６３】
ｇｅｔａｃｔｏｒ＝ ｃｒｅｄｉｔ（タナカ＊），ｐｅｒｉｏｄ（ｄｉｓｐｌａｙ，２００９０４０１００００００，２００９０５３１２３５９５９）＆ｕｎｌｉｍｉｔ＆ｎａｍｅｌｉｓｔ ※ ｐｅｒｉｏｄ検索の書式：ｐｅｒｉｏｄ（＜ｐｅｒｉｏｄ−ｔｙｐｅ＞［，＜ｓｔａｒｔ＞］，［＜ｅｎｄ＞］ ）
本実施例では、取得したｎａｍｅ＿ｖａｌｕｅとクレジット情報管理テーブル１３２との照合を行う際（ステップＳ２０２）、クレジット情報管理テーブル１３２から別途ＣＲＩＤを取得し、ＣＲＩＤをキーにメタ情報管理テーブル１３２（図１９参照）から対応するメタデータのレコードを取得し、オプション指定された検索条件を照合する。上記の場合、図３に示すクレジット情報管理テーブル１３２から、項番：１−２と項番１−３の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１）と項番：２−２の田中次郎（ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２）が抽出される。そして、メタ情報管理テーブル１３１（図１９）を参照し、各ＣＲＩＤのＰｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］／Ｓｔａｒｔ， Ｐｅｒｉｏｄ［＠ｔｙｐｅ＝“ｄｉｓｐｌａｙ”］／Ｅｎｄ情報を取得し、検索条件と照合する。
【００６４】
照合の結果、“ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００２”のコンテンツは表示期間が２００９−０８−０１Ｔ００：００：００〜２００９−０８−３１Ｔ２３：５９：５９と検索要求が示す期間には含まれないため、図３に示す項番：２−２の田中次郎は、照合結果の候補からは除外される（ステップＳ２０３のＮｏ）。一方、“ＣＲＩＤ：ａｒｉｂ．ｏｒ．ｊｐ／ｖｏｄ／００１”のコンテンツは表示期間が２００９−０４−０１Ｔ００：００：００〜２００９−１２−３１Ｔ００：００：００と検索要求が示す期間に含まれるため、図３に示す項番：１−２と項番１−３のレコードは次の処理へ進められ（ステップＳ２０３のＹｅｓ）、照合結果リストとしては、図２０のようになる。
【００６５】
なお、検索要求のオプションとして、パレンタルレーティングが付与された場合（ＰａｒｅｎｔａｌＲａｔｉｎｇ（ＡＲＩＢＰａｒｅｎｔａｌＲａｔｉｎｇＣＳ：Ｒ−２０））、メタ情報管理テーブル１３１（図１９）のＰａｒｅｎｔａｌＲａｔｉｎｇと照合される。
【実施例３】
【００６６】
前記実施形態で述べた例では、クレジット情報管理テーブル１３２へのレコード情報の追記は述べているが、クレジット情報管理テーブル１３２の管理、レコード情報の削除は述べていない。ここで、ＴＶ−Ａｎｙｔｉｍｅでは、コンテンツに有効期限（ＦｒａｇｍｅｎｔＥｘｐｉｒａｔｉｏｎＤａｔｅ）を記載し、この有効期限をもとにメタデータの管理、削除を実施することを規定している。そこで、本実施例では、このメタデータの有効期限と連携し、対応するコンテンツに記載されていたクレジット情報を管理、削除することを考える。これにより、人名検索結果に期限切れになったコンテンツの人名が提示されることを防止できる。
【００６７】
本実施例では、メタ情報管理テーブル１３２に対する定期的な期限切れメタデータの削除操作時、メタ情報管理テーブル１３１に記載されたＣＲＩＤをキーに、クレジット情報管理テーブル１３２の該当するＣＲＩＤに対するクレジット情報を削除する。
【００６８】
また、本実施形態のメタデータサーバシステムにおける各手段の一部もしくは全部の機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができることは言うまでもなく、コンピュータでその機能を実現するためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えばＦＤ（Ｆｌｏｐｐｙ（登録商標） Ｄｉｓｋ）や、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、メモリカード、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）−ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＨＤＤ、リムーバブルディスクなどに記録して、保存したり、配布したりすることが可能である。また、上記のプログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【符号の説明】
【００６９】
１００…メタデータサーバ
１１０…メタデータ登録部
１２０…クレジット情報管理部
１３０…メタデータＤＢ
１３１…メタ情報管理テーブル
１３２…クレジット情報管理テーブル
１４０…メタデータ検索部
２００…受信端末
２１０…入力部
２２０…メタデータ要求部
２３０…提示部
３００…ネットワーク
【特許請求の範囲】
【請求項１】
ＴＶ−Ａｎｙｔｉｍｅメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、
前記メタデータサーバは、
外部から投入されるメタデータを受信し、メタデータデータベースのメタ情報管理テーブルに登録するメタデータ登録手段と、
前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、
受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、
を備えることを特徴とするメタデータサーバシステム
【請求項２】
前記クレジット情報管理テーブルは、コンテンツ識別子であるＣＲＩＤを主キーに、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項１記載のメタデータサーバシステム。
【請求項３】
前記人名一覧テーブルは、ＴＶ−ＡｎｙｔｉｍｅのＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅＴｙｐｅに対するスキーマ拡張の実施により、役柄情報が記載されていることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項４】
前記メタデータ検索手段は、
前記クレジット情報管理テーブルに対する照合結果リストを格納する照合結果リスト格納手段と、
前記受信端末からの人名検索要求からフリーワードを取得する手段と、
前記取得したフリーワードと前記クレジット情報管理テーブルの出演者名と出演者名ルビを照合し、合致する第１のレコードを導出する手段と、
前記人名検索要求に役柄指定がある場合、前記手段で導出された第１のレコードの役柄情報と照合し、合致する第２のレコードを導出する手段と、
前記導出された第２のレコードと既に前記照合結果リスト格納手段に格納済みのレコードを照合し、照合結果リストへの追記を実施する手段と、
前記照合結果リストの最終的な照合結果から、前記受信端末へ返信する人名一覧テーブルを生成する手段と、
を備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項５】
前記照合結果リストは、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項４記載のメタデータサーバシステム。
【請求項６】
前記照合結果リストは、ＣＲＩＤ、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項４記載のメタデータサーバシステム。
【請求項７】
前記メタデータ検索手段は、
前記受信端末からの人名検索要求に加え、コンテンツに対するオプション検索要求を受信する手段と、
前記クレジット情報管理テーブルとの照合時、クレジット情報管理テーブルのＣＲＩＤをキーに、対応するメタ情報を前記メタ情報管理テーブルから取得する手段と、
前記取得したメタ情報とオプション検索要求とを照合する手段と、
を更に備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項８】
前記メタデータ検索手段は、
前記クレジット情報管理テーブルのＣＲＩＤをキーに、対応するメタデータの有効期限を前記メタ情報管理テーブルから取得する手段と、
前記取得した有効期限をもとに、期限切れしたメタデータに記載されていたクレジット情報を前記クレジット情報管理テーブルから削除する手段と、
を更に備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項９】
コンピュータを請求項１記載の各手段として機能させるメタデータ検索プログラム。
【請求項１０】
請求項９に記載のメタデータ検索プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
ＴＶ−Ａｎｙｔｉｍｅメタデータの管理・提供をメタデータサーバによって行うメタデータサーバシステムにおいて、
前記メタデータサーバは、
外部から投入されるメタデータを受信し、メタデータデータベースのメタ情報管理テーブルに登録するメタデータ登録手段と、
前記メタデータ登録手段が受信したメタデータからクレジット情報を抽出し、前記メタデータデータベースのクレジット情報管理テーブルに登録するクレジット情報管理手段と、
受信端末からの人名検索要求を受信したとき、前記クレジット情報管理テーブルを参照し、人名一覧テーブルを生成して前記受信端末へ返信するメタデータ検索手段と、
を備えることを特徴とするメタデータサーバシステム
【請求項２】
前記クレジット情報管理テーブルは、コンテンツ識別子であるＣＲＩＤを主キーに、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項１記載のメタデータサーバシステム。
【請求項３】
前記人名一覧テーブルは、ＴＶ−ＡｎｙｔｉｍｅのＣｒｅｄｉｔｓＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅＴｙｐｅに対するスキーマ拡張の実施により、役柄情報が記載されていることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項４】
前記メタデータ検索手段は、
前記クレジット情報管理テーブルに対する照合結果リストを格納する照合結果リスト格納手段と、
前記受信端末からの人名検索要求からフリーワードを取得する手段と、
前記取得したフリーワードと前記クレジット情報管理テーブルの出演者名と出演者名ルビを照合し、合致する第１のレコードを導出する手段と、
前記人名検索要求に役柄指定がある場合、前記手段で導出された第１のレコードの役柄情報と照合し、合致する第２のレコードを導出する手段と、
前記導出された第２のレコードと既に前記照合結果リスト格納手段に格納済みのレコードを照合し、照合結果リストへの追記を実施する手段と、
前記照合結果リストの最終的な照合結果から、前記受信端末へ返信する人名一覧テーブルを生成する手段と、
を備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項５】
前記照合結果リストは、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項４記載のメタデータサーバシステム。
【請求項６】
前記照合結果リストは、ＣＲＩＤ、役柄情報、出演者名、出演者名ルビの組みを管理することを特徴とする請求項４記載のメタデータサーバシステム。
【請求項７】
前記メタデータ検索手段は、
前記受信端末からの人名検索要求に加え、コンテンツに対するオプション検索要求を受信する手段と、
前記クレジット情報管理テーブルとの照合時、クレジット情報管理テーブルのＣＲＩＤをキーに、対応するメタ情報を前記メタ情報管理テーブルから取得する手段と、
前記取得したメタ情報とオプション検索要求とを照合する手段と、
を更に備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項８】
前記メタデータ検索手段は、
前記クレジット情報管理テーブルのＣＲＩＤをキーに、対応するメタデータの有効期限を前記メタ情報管理テーブルから取得する手段と、
前記取得した有効期限をもとに、期限切れしたメタデータに記載されていたクレジット情報を前記クレジット情報管理テーブルから削除する手段と、
を更に備えることを特徴とする請求項１記載のメタデータサーバシステム。
【請求項９】
コンピュータを請求項１記載の各手段として機能させるメタデータ検索プログラム。
【請求項１０】
請求項９に記載のメタデータ検索プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１１−３９８５５（Ｐ２０１１−３９８５５Ａ）
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２００９−１８７５９８（Ｐ２００９−１８７５９８）
【出願日】平成２１年８月１３日（２００９．８．１３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２１年８月１３日（２００９．８．１３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]