JP2011039855A - Metadata server system, metadata retrieval program and recording medium with the program recorded thereon - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To retrieve a person name list by the use of a free word without imposing a heavy processing load on a receiving terminal 200 in a TV-Anytime metadata service. <P>SOLUTION: In the TV-Anytime metadata service, a system provides a person name retrieval by the use of the free word. A credit information management part 120 parses metadata received from a metadata registration part 110 and registers credit information in a credit information management table 132 of a metadata DB 130. When receiving a person name retrieval request from the receiving terminal 200, a metadata retrieval part 140 refers to the credit information management table 132 and generates a person name list table (CreditsInformationTable) to return the same to the receiving terminal 200. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a TV-Anytime service, and more particularly, to a system and program for realizing a search for a personal name list using free words.

  As a core technology of the IPTV service, there is a metadata technology for describing / searching information (for example, title, content, genre, performer, etc.) of content provided on multiple channels or video on demand.

  As an example, TV-Anytime (see Non-Patent Document 1), a private international standard, standardizes a metadata schema that defines the content and format described as metadata, and builds a common database for metadata. The user can easily search and select desired content.

  Based on the TV-Anytime specification in Japan, ARIB and IPTV Forum have metadata standard specifications (ARIB STD-B38 (see Non-Patent Document 2)) and operation rules (ARIB TR-B27, IPTV rules, CDN scope service) Approach specifications) are formulated for each. FIG. 2 shows an example of TV-Anytime metadata.

  In TV-Anytime metadata, content information (eg, title, content, genre, performer, etc.) is handled by program description metadata (Program Description Metadata), and content distribution information (broadcast time, channel, content URI, etc.) ) Is handled by instance metadata (Instance Description). At this time, the metadata for the content is uniquely identified by a content reference identifier called CRID (Content Reference Identifier).

  In addition, in TV-Anytime, a two-way communication method for metadata is defined, and a user transmits a search request including a condition for specifying metadata to the metadata server, thereby corresponding metadata. Data, CRID list of corresponding metadata, and number of corresponding metadata can be acquired. Here, search conditions defined by TV-Anytime include title search, keyword search, performer search, CRID search, genre search, period search, and the like. When the metadata body is specified as a return format, the corresponding metadata fragment (ProgramInformation, GroupInformation, BroadcastCastEvent, etc.) is returned in table units (ProgramInformationTable, GroupInformationTable, ProgramTable, Table A, 21).

"Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems (" TV-Anytime "); Part 3: TV-A TS; 4.1 (2007-11), 6.7.2 TV-Anytime meta data data document pp. 84-88 "Encoding, transmission and storage control method in server type broadcasting", ARIB STD-B38 1.3 edition, March 14, 2006 3.2.7.2 ARIB server type broadcasting program information document pp. 69-73

  In TV-Anytime, metadata search and processing are handled in units of fragments. Therefore, for example, in the case of realizing a person name search such as searching a list of person names starting with “Yamada”, first, a search (performer search) of works in which a person beginning with “YA” appears is performed. After that, the obtained metadata (ProgramInformationTable, see FIG. 2) is parsed, and the performer name starting with “Yamada” (CreditsItem / PersonName / mpeg7: GivenName [@ type = “main”], Taro Yamada in FIG. 2, Tanaka Jiro etc.) will be extracted. At this time, a plurality of ProgramInformation is described in the search result, and further, when a plurality of the same performer names are extracted, a process of integrating them is necessary (in FIG. 2, Taro Yamada is described in the two ProgramInformation). The search results are integrated and displayed as shown in FIG. 10, for example).

  In TV-Anytime, the search result return format is a return format based on works such as the metadata main body, CRID list, and number of cases. The mechanism for returning a list of person names is not specified.

  The present invention has been made in view of such a situation, and enables a person name search to be realized in a TV-Anytime metadata service without imposing a large processing load on a receiving terminal.

  The metadata server system according to claim 1 for solving the above problem is a metadata server system that manages and provides TV-Anytime metadata by the metadata server, and the metadata server is input from the outside. Metadata registration means for receiving metadata and registering it in the metadata information management table of the metadata database, and extracting credit information from the metadata received by the metadata registration means, and storing it in the credit information management table of the metadata database Credit information management means for registration, and metadata search means for generating a personal name list table and referring back to the receiving terminal by referring to the credit information management table when receiving a personal name search request from the receiving terminal It is characterized by that.

(1) According to the first to tenth aspects of the present invention, the personal name search in the TV-Anytime metadata service can be realized without imposing a large processing load on the receiving device.
(2) According to the inventions described in claims 2 and 6, it is possible to return not only the list of names but also the number of works in which each person appears, and the expression as a search result can be enhanced. .
(3) According to the invention described in claim 7, various person name searches can be realized by referring not only to the credit information but also to the information related to the content.
(4) According to the invention described in claim 8, the management of the content information and the credit information in the meta server, in particular, the deletion of the expired information can be linked, and the appropriate management of the meta server can be realized.

It is a block diagram which shows the structure of one embodiment of this invention. It is a figure which shows the example of TV-Anytime metadata. It is a figure explaining the component of the credit information management table in one embodiment of this invention. It is a figure explaining CreditsInformationTable (person name list table) which is a search response in the present invention. It is a figure explaining the metadata schema in TV-Anytime, and schema extension in the present invention. It is a sequence diagram explaining the process between the receiving terminal and metaserver at the time of person search in one embodiment of this invention. It is a figure explaining the example of a search request screen. It is a flowchart explaining the process of a personal name list production | generation in the metadata search part in one embodiment of this invention. It is a figure explaining the component of the collation result list | wrist in one embodiment of this invention. It is a figure explaining the example of a search result screen. It is a figure explaining the search result screen of the performer search in one embodiment of this invention. It is a figure explaining the example of a search response at the time of searching with another query in one embodiment of the present invention. It is a figure explaining the example of a collation result list at the time of searching by "no role designation | designated" in one embodiment of this invention. It is a figure explaining the search response corresponding to the collation result list | wrist of FIG. It is a figure explaining the search result screen at the time of the search response reception of FIG. It is a figure explaining the collation result list by Example 1 of this invention. It is a figure explaining the search response corresponding to the collation result list | wrist of FIG. It is a figure explaining the search result screen at the time of the search response reception of FIG. It is a figure explaining the component of a meta information management table. It is a figure explaining the collation result list by Example 2 of this invention. It is a figure explaining the return format of the search result in TV-Anytime.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings, but the present invention is not limited to the following embodiments.

  FIG. 1 is a block diagram showing a configuration of an embodiment of a system using the present invention. This system includes a metadata server 100 that performs management, search, and transmission of metadata, and a receiving terminal 200 that performs a metadata search request and reception of metadata to the metadata server 100 via the network 300. Has been.

  Although only one receiving terminal 200 is shown in FIG. 1, a plurality of receiving terminals are actually connected to the metadata server 100 via the network 300.

  The metadata server 100 includes a metadata registration unit 110 as a metadata registration unit, a credit information management unit 120 as a credit information management unit, a metadata DB (database) 130, and a metadata search unit 140 as a metadata search unit. The metadata DB 130 has a functional configuration of a meta information management table 131 and a credit information management table 132.

  Note that the function of each unit in the metadata server 100 is achieved by, for example, a computer.

  The receiving terminal 200 has a functional configuration of an input unit 210, a metadata request unit 220, and a presentation unit 230.

  The metadata registration unit 110 of the metadata server 100 receives metadata (TV-Anytime XML data, see FIG. 2) input from an external metadata operation tool, and stores it in the metadata information management table 131 of the metadata DB 130. sign up. At this time, in order to cope with various searches in addition to the XML main body, Attribute expansion is appropriately performed and registered. Further, the received metadata is transmitted to the credit information management unit 120.

  In the credit information management unit 120, the metadata received from the metadata registration unit 110 is parsed, the credit information is extracted for the person name search, and is registered in the credit information management table 132 of the metadata DB 130 (see FIG. 3).

  As shown in FIG. 3, the credit information management table 132 includes TVAMain / ProgramDescription / ProgramInformation (hereinafter abbreviated as PI) / @ programId, TVAMain / ProgramDescription / GroupInformation (hereinafter abbreviated as “GI” / ID as “ID”). ”.

  Next, PI or GI BasicDescription / CreditsList / CreditsItem / @ role, which is the role information, is described in “Role”.

  Furthermore, each CreditItem's PersonName [@ type = “main”] / mpeg7: GiveName is “NameMain”, and the performer name Ruby is PersonName [@ type = “variant”] / mpeg7: iVenMe7 “, PersonName [@ type =“ former ”] / mpeg7: GiveName is described in“ NameFormer1 ”. At this time, a plurality of PersonName [@ type = “former”] / mpeg7: GiveName may be described. In this case, the name is added after “NameFormer2”.

  Here, NameVariant and NameFormer are described in the credit information management table 132 in order to include the performer ruby in the search target and to distinguish between different readings of the same surname. The same name and the same name are not distinguished at present, but an operational countermeasure such as adding a character string other than ruby such as “** _ A” at the end of NameFormer can be considered, but is not particularly mentioned in this specification. And

  In the metadata search unit 140, when a search request transmitted from the receiving terminal 200 is received and the search request is a person name search, the credit information management table 132 is referred to, and a person name list table to be returned (CreditsInformationTable, see FIG. 4). ) And transmitted to the receiving terminal 200. On the other hand, when the search request is an existing search request such as a title search or performer search, the meta information management table 131 is referred to, a fragment to be returned is generated, and transmitted to the receiving terminal 200.

  Note that the metadata search unit 140 includes a verification result list storage unit (a verification result list storage unit) that stores a verification result list for the credit information management table 132.

  Here, in the metadata schema of TV-Anytime, as shown in FIG. 5A, CreditsInformationTableType simply lists performer names (PersonName) and cannot describe role information. Therefore, in the present invention, the schema of CreditsInformationTableType is extended so that each performer name can be managed in units of role information (CreditsItem) as shown in FIG. 5B, and furthermore, role information (CreditsItem / @ role). ).

  Next, with reference to the sequence diagram of FIG. 6, a process for transmitting a personal name search request (metadata search request) from the receiving terminal 200 to the metadata server 100 and receiving and presenting a personal name list table as a search result will be described. To do.

  First, the presentation unit 230 presents a search screen as shown in FIG. 7 to the user (step S100). Thereafter, the user inputs a free word or role (not specified, starring, director, etc.) that the user wants to search (step S101) and executes the search (step S102).

Next, the metadata request unit 220 generates a search request to the metadata server 100 based on the information input on the search screen (step S103). At this time, a search request for a person name search may have the following format.
gettortor = credit ((<name_value> [, <role_value>]), ...) &<range>&<type>
Name_value: The input arbitrary character string.
• role_value: ARIB RoleCS termID corresponding to the specified role.
role_value is arbitrarily specified, and if given, AND condition with name_value.
(<Name_value> [, <role_value>]) is an OR condition.
Range = <from> [, <count>] | unlimit
from: top order of search results to be returned count: number of search results to be returned from top order unlimit: return all search results from the top of the search results type = namelist | countly
namelist: returns a list of person names county: returns the number of person names For example, as shown in FIG. 7, when searching for “Yamada” and “starring”, the search request is as follows.
* Getactor = credit (Yamada *, ARIBRoleCS: 1.1) & unlimit & namelist * indicates forward matching.

  The metadata search unit 140 of the metadata server 100 analyzes the received search request (step S104), and when the search request format is the above-described person name search (getactor), refer to the credit information management table 132 of the metadata DB 130. Then, a person name matching the condition is searched (step S105). Then, the search result is converted into a personal name list (CreditsInformationTable) and transmitted to the receiving terminal 200 (step S106).

  In the receiving terminal 200, the metadata request unit 220 receives the search result (step S107), and the presentation unit 230 presents the search result screen to the user (step S108).

  Next, a process in which the metadata search unit 140 searches the credit information management table 132 for a list of person names that meet the conditions will be described with reference to the flowchart of FIG.

  First, a “(name_value, role_value)” pair is acquired from the received search request (step S201). Here, “name_value” is essential, but “role_value” is optional and may not be described. When a plurality of “(name_value, role_value)” are described in credit (), each pair is acquired in order and the subsequent processing is performed.

  First, the credit information management table 132 is referenced to search for a record in which the acquired “name_value” character string is described in any of “NameMain”, “NameVariant”, “NameFormer1”, and “NameFormer2” (step S202). ). In this case, the matching method includes forward match, partial match, complete match, and backward match. The format of the “name_value” portion is “Yamada *”, “* Yamada *”, “Yamada”, “* Yamada”, respectively. It can be considered.

  Next, when a matching record is found (Yes in step S203), it is confirmed whether “role_value” is described in the received search request pair. If “role_value” is described, the value described in the “role_value” is collated with the Role of the acquired record (step S205), and if they match (Yes in step S206), the “ Role, NameMain, NameVariant, NameFormer, NameFormer2 "are acquired (step S207).

  Subsequently, it is confirmed whether or not the acquired record information is already in the matching result list. If the information is not in the matching result (No in step S208), the acquired record information is added to the matching result list (step S209, FIG. 9), the process proceeds to step S210.

  Here, when a record that matches the name_value obtained in the process of step S203 is not found (No in step S203), or a record that matches the role_value obtained in the process of step S206 is not found (No in step S206). If there is a record already acquired in the collation result list in the process of step S208 (Yes in step S208), the special process is not performed and the process proceeds to step S210.

  In the process of step S210, it is determined whether the pair of “(name_value, role_value)” acquired in step S201 has been searched to the end of the credit information management table 132, and if the end has not been reached yet (No in step S210), Returning to step S202, the remaining tables are searched. On the other hand, if the end of the credit information management table 132 has been reached (Yes in step S210), it is checked whether the received search request has the next “(name_value, role_value)” pair (step S211). Then, when there is a next “(name_value, role_value)” pair (Yes in step S211), the processing from step S201 is performed on the pair.

  On the other hand, if there is no next “(name_value, role_value)” pair in the search request (No in step S211), the process proceeds to a process of generating a return response of the search result.

  First, the type designation of the search request is confirmed (step S212). When the type designation is “count” (count in step S212), the number of records described in the collation result list is counted, and the number of cases is received by the receiving terminal 200. (Step S214). On the other hand, when the type designation is “namelist” (namelist in step S212), the collation result list is sorted in the order of, for example, NameVariant in the order of 50 sounds (step S213).

  Next, the range specification of the search request is confirmed (step S215). If the range specification is in the form of “from (count)” (from (count) in step S215), records from the first place in the matching result list are counted. Is extracted (step S216), and the extracted person name list is returned in the format of CreditsInformationTable (step S217; step S106 in FIG. 6). On the other hand, when the range designation is “unlimit”, all the records described in the collation result list are acquired, and the acquired person name list is returned in the format of CreditsInformationTable (step S217; step S106 in FIG. 6).

  For example, as shown in FIG. 7, when searching for “Yamada” and “starring”, CreditsItem / @ role is the starring (ARIBRoleCS: 1.1), and the performer name (CreditsItem / PersonName [@ type = “main”] / Mpeg7: GivenName) or performer name Ruby (CreditsItem / PersonName [@ type = “variant”] / mpeg7: GivenName) with a list of names (CreditsInformation4, with a list of creditsItems with CreditsItem4 starting with “Yamada”) Returned. Therefore, the receiving terminal 200 extracts the performer name (CreditsItem / PersonName [@ type = “main”]) from the received list of person names (CreditsInformationTable) and generates a search result screen (see FIG. 10).

  After that, if the name of the search result (“Taro Yamada” in FIG. 10) is selected, search for works whose “starring” is “Taro Yamada” (performer search, predicate = credit (Taro Yamada, ARIB RoleCS). : 1.1)) may be implemented, and the user is presented with a search result screen displaying a list of corresponding contents as shown in FIG. 11 (crid: //arib.or in FIG. 3). .Jp / vod / 001, crid: //arib.or.jp/vod/002 is returned).

  In addition, for example, when searching with “* mountain *” or “no role designation”, the search request is as follows.

  gettortor = credit (* mountain *) & unlimit & namelist * XX designates partial match at X.

  In this case, under the condition of name_value (role_value is not required), Taro Yamada (CRID: arib.or.jp/vod/0011, Role: ARIBRoleCS: 1) from the credit information management table 132 shown in FIG. 1), Taro Yamada of item number 2-1 (CRID: arib.or.jp/vod/002, Role: ARIBRoleCS: 1.1), Taro Yamamoto of item number 2-3 (CRID: arib.or.jp) / Vod / 002, Role: ARIBRoleCS: 1.1) is extracted. Among these, the item number 1-1 and the item number 2-1 are merged, and the personal name list (CreditsInformationTable) shown in FIG.

  Furthermore, for example, when a search is performed with “Tanaka” or “no role designation”, the search request is as follows.

  getactor = credit (tanaka *) & unlimit & namelist * * designates forward matching.

  In this case, under the condition of name_value (role_value is not required), Jiro Tanaka (CRID: arib.or.jp/vod/0011, Role: ARIBoleCS: 1) from the credit information management table 132 shown in FIG. 1), Jiro Tanaka (CRID: arib.or.jp/vod/001, Role: ARIBRoleCS: 3.1), Jiro Tanaka (CRID: arib.or. jp / vod / 002, Role: ARIBRoleCS: 4.3) is extracted. At this time, the items 1-2, 1-3, and 2-2 have the same performer name “Jiro Tanaka”, but since the role information is different, the collation result list is as shown in FIG. As shown in FIG. 14, a list of names (CreditsInformationTable) in which the names of performers are the same but the CreditsItem / @ role is different is returned to the terminal 200. Here, the receiving terminal 200 does not simply describe the performer name “Jiro Tanaka” as the search result screen, but it is described in the role information (CreditsItem / @ role) after the performer name as shown in FIG. It is conceivable to describe the role name corresponding to ARIB RoleCS).

  After that, if the role of the search result ("starring" in FIG. 15) is selected, the search for works whose "starring" is "Joji Tanaka" (predictate = credit (Jiro Tanaka, ARIBoleCS: 1.1) , Content 1 is returned), and when the search result person name (“Jiro Tanaka” in FIG. 15) is selected, “Jiro Tanaka” is one of “starring”, “director”, or “singer” It is conceivable to search for works (predicate = credit ((Jiro Tanaka, 1.1), (Jiro Tanaka, 3.1), (Jiro Tanaka, 4.1), content 1 and content 2 are returned)) .

  In the example described in the embodiment, it is considered that a list of performer names is presented as a search result screen as shown in FIG. Here, as a search result of the person name search, as shown in FIG. 18, it may be possible to present the number of works in which the person appears (CRID number) beside each performer name (for example, type in the search request). The designation is “namelist2”).

  Hereinafter, with reference to FIG. 8, an extended portion of the processing of the metadata search unit 140 in the present embodiment will be described.

  In this embodiment, when acquiring a record that matches the condition from the credit management information table 132 (step S207), the CRID is also acquired, and managed in the collation result list including the CRID as shown in FIG.

  By doing in this way, when confirming whether the acquired record information is already in the matching result list (step S208), even if the role information, performer name, and performer ruby are the same, the CRIDs are different. It will be handled as separate information.

  As a result, as shown in FIG. 17, a list of names (CreditsInformationTable) in which CreditsItems having the same role information, performer name, and performer ruby are described for the number of CRIDs is returned to the receiving terminal 200. Therefore, the receiving terminal 200 counts information having the same contents of CreditsItem and presents it as the number of works corresponding to the CreditsItem as shown in FIG.

  Here, if there is no role designation in the search request from the receiving terminal 200 and the difference in the role information of CreditsItem is ignored, the total number of works for that person can be counted, and if the difference is distinguished, the work of each role Will count the number.

  In the example described in the embodiment, the credit information management table 132 does not describe the period information of the content in which the credit is described, the parental rating, or the like. Therefore, for example, even when the content is outside the display period (Period [@ type = “display”]), the name of the person who appears in the content is displayed in the result of the person name search.

  However, when performing a performer search with the person name from the search result screen, the content is not searched because the corresponding content is outside the display period. In addition, for example, if the content is an adult work, the name of the person who appears in the content is displayed in the result of the person name search. It is also conceivable that content is not presented because the content to be parented is a parental target.

  Therefore, in the present embodiment, it is considered that search conditions (Period search, parental rating search, genre search, etc.) defined by TV-Anytime are also given as an option for person name search.

  Hereinafter, with reference to FIG. 8, an extended portion of the processing of the metadata search unit 140 in the present embodiment will be described. For example, when a person name search starting with “Tanaka” is performed on content included in the display period 2009/4/1 00:00:00 to 2009/05/31 23:59:59, the search request is as follows: become that way.

getactor = credit (tanaka *), period (display, 20090401000000000, 20090515235959) & unlimited & namelist * period search format: period (<period-type> [, <end>], [<end>]
In this embodiment, when collating the acquired name_value with the credit information management table 132 (step S202), a CRID is separately acquired from the credit information management table 132, and the meta information management table 132 (see FIG. 19) using the CRID as a key. ) Get the corresponding metadata record from) and match the search condition specified by the option. In the above case, from the credit information management table 132 shown in FIG. 3, Jiro Tanaka (CRID: arib.or.jp/vod/001) and item number: 2-2 of item number 1-2 and item number 1-3 Jiro Tanaka (CRID: arib.or.jp/vod/002) is extracted. Then, by referring to the meta information management table 131 (FIG. 19), the Period [@ type = “display”] / Start, Period [@ type = “display”] / End information of each CRID is acquired and collated with the search condition. To do.

  As a result of the collation, the content of “CRID: arib.or.jp/vod/002” has a display period of 2009-08-01T00: 00: 00-2009-08-31T23: 59: 59 and the period indicated by the search request Since it is not included, Jiro Tanaka of item number 2-2 shown in FIG. 3 is excluded from the candidates for the matching result (No in step S203). On the other hand, because the content of “CRID: arib.or.jp/vod/001” is included in the period indicated by the search request, the display period is 2009-04-01T00: 00: 00 to 2009-12-31T00: 00: 00. The records of item numbers 1-2 and 1-3 shown in FIG. 3 are advanced to the next processing (Yes in step S203), and the collation result list is as shown in FIG.

  When a parental rating is given as an option of a search request (ParentalRating (ARIBParentalRatingCS: R-20)), it is compared with ParentRating in the meta information management table 131 (FIG. 19).

  In the example described in the embodiment, the record information is added to the credit information management table 132, but the management of the credit information management table 132 and the deletion of the record information are not described. Here, in TV-Anytime, an expiration date (FragmentExpirationDate) is described in content, and management and deletion of metadata are defined based on the expiration date. Therefore, in this embodiment, it is considered to manage and delete the credit information described in the corresponding content in cooperation with the expiration date of this metadata. Thereby, it is possible to prevent the name of the expired content from being presented in the name search result.

  In this embodiment, at the time of a periodic expiration metadata deletion operation for the meta information management table 132, the credit information for the corresponding CRID in the credit information management table 132 is deleted using the CRID described in the meta information management table 131 as a key. To do.

  It goes without saying that some or all of the functions of each means in the metadata server system of the present embodiment are configured by a computer program, and that the present invention can be realized by executing the program using the computer. A program for realizing the function by a computer is recorded on a computer-readable recording medium such as FD (Floppy (registered trademark) Disk), MO (Magneto-Optical disk), ROM (Read Only Memory), memory card. , CD (Compact Disk) -ROM, DVD (Digital Versatile Disk) -ROM, CD-R, CD-RW, HDD, removable disk, etc. can be stored and distributed It is. It is also possible to provide the above program through a network such as the Internet or electronic mail.

DESCRIPTION OF SYMBOLS 100 ... Metadata server 110 ... Metadata registration part 120 ... Credit information management part 130 ... Metadata DB
131 ... Meta information management table 132 ... Credit information management table 140 ... Metadata search unit 200 ... Receiving terminal 210 ... Input unit 220 ... Metadata request unit 230 ... Presentation unit 300 ... Network

Claims (10)

In a metadata server system that manages and provides TV-Anytime metadata by a metadata server,
The metadata server
Metadata registration means for receiving metadata input from the outside and registering it in the metadata information management table of the metadata database;
Credit information management means for extracting credit information from the metadata received by the metadata registration means and registering it in a credit information management table of the metadata database;
When a personal name search request from a receiving terminal is received, a metadata search unit that refers to the credit information management table and generates a personal name list table and sends it back to the receiving terminal;
A metadata server system comprising: 2. The metadata server system according to claim 1, wherein the credit information management table manages combinations of role information, performer name, and performer name ruby using CRID as a content identifier as a main key. 2. The metadata server system according to claim 1, wherein in the personal name list table, role information is described by performing a schema extension to the CreditsInformationTableType of TV-Anytime. The metadata search means includes:
Verification result list storage means for storing a verification result list for the credit information management table;
Means for obtaining a free word from a person name search request from the receiving terminal;
Means for deriving a matching first record by comparing the obtained free word with the performer name and performer name ruby in the credit information management table;
Means for deriving a matching second record by collating with the role information of the first record derived by the means when there is a role designation in the person name search request;
Means for collating the derived second record with a record already stored in the collation result list storage means, and performing addition to the collation result list;
Means for generating a person list table to be returned to the receiving terminal from the final matching result of the matching result list;
The metadata server system according to claim 1, further comprising: 5. The metadata server system according to claim 4, wherein the collation result list manages combinations of role information, performer name, and performer name ruby. 5. The metadata server system according to claim 4, wherein the collation result list manages combinations of CRID, role information, performer name, and performer name ruby. The metadata search means includes:
Means for receiving an option search request for content in addition to a person name search request from the receiving terminal;
Means for acquiring corresponding meta information from the meta information management table using the CRID of the credit information management table as a key when collating with the credit information management table;
Means for collating the acquired meta information with an option search request;
The metadata server system according to claim 1, further comprising: The metadata search means includes:
Means for acquiring from the meta information management table the expiration date of the corresponding metadata using the CRID of the credit information management table as a key;
Means for deleting the credit information described in the expired metadata from the credit information management table based on the acquired expiration date;
The metadata server system according to claim 1, further comprising: A metadata search program for causing a computer to function as each means according to claim 1. A computer-readable recording medium on which the metadata search program according to claim 9 is recorded.

Images