JP2005012777A - Digital item processing method and device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To impart maximum flexibility and interactive operation capability to MPEG-21 terminals of different applications and widely utilize the imparted properties by defining a general-purpose message structure having syntax and semantics for facilitating communication between various processing engines by a particular method. <P>SOLUTION: An MPEG-21 terminal or a MPEG-21 module having a defined message API is built, and different processing engines provided by different vendors are operated together by a particular method. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a method and apparatus for processing digital items, and more particularly, various types that exist in a universal multimedia access framework and are used internally to access multimedia resources of different formats. The present invention relates to a unified multimedia terminal that can perform module processing. In particular, it relates to internal communication mechanisms and formats between various processing modules.

  MPEG and other standards bodies can easily transfer and deliver content from one location to another in an efficient manner for video, audio, systems, communication protocols, content representation, content packaging, etc. In addition, many standards have been established in order to easily store a large amount of content in a limited space.

  A universal multimedia access framework needs to be built in an environment that can support the provision and use of all kinds of content by different categories of users in multiple application domains. Such a framework requires that the shared vision, or roadmap, be understood by the architect, ensuring that the systems providing the media resources are interoperable and transactions are easily performed. This also applies to infrastructure requirements for content provision, content security, rights management, secure payments, and the technologies that enable them. That is, all content owners, artists, end users, service providers, and CE manufacturers know that this framework supports their goals.

  A digital item (DI) is defined as a digital object composed of standard expressions, identifications and descriptions within the framework. This entity is also the basic unit of delivery and transactions within the MPEG-21 framework, and its purpose is to enable DI electronic commerce. Based on this framework, there are several key technologies that have already been carefully developed or are currently under development. For example, Digital Item Declaration (DID) is a standard for defining multimedia content from the viewpoint of its components and structure (ie, resources and metadata), and DID is described in XML Is done.

  In addition to DID, Digital Item Identification (DII), Digital Item Adaptation (DIA), Intellectual Property Management and Protection (IPMP), Rights Description Language R Language / Rights Data Dictionary (RDD) and Event Reporting (ER) are important technologies for forming MPEG-21.

  For any transaction, there is a need and means for identifying the subject of the transaction. DII uniquely identifies DI and plays the same role as ISBN does for books.

  In the past, content providers and service providers are familiar with their customers and also know or control the means for distributing their content. At the same time, consumers understood the meaning of clearly classified services such as television, movies and music. But today, our convictions are shaking. End users are more unpredictable than ever, and the same content can be delivered by a variety of delivery systems and enjoyed on a variety of different consumer devices. The DIA provides a means of describing how the DI should be adapted (transformed) to be optimal for the specific characteristics of user, network and device properties. The DIA specification defines basic usage environment description tools, DI resource adaptation tools, and DID adaptation tools.

  The IPMP architecture that manages and protects DI provides the description and enforcement of rights, conditions, results and responsibilities (REL / RDD information) related to the delivery, management, and use of DI by any member of the DI value chain. . Here, the means to describe the IPMP related to DI in as much detail as possible, the role of the trust with the architecture, and the ability to claim that DI management and availability meet specific criteria guaranteed by the entrusted entity And interoperability supported by terminal requirements for such functions.

  The purpose of the ER is to provide a metric and interface for the performance of any reportable event. The need to standardize this in a multimedia framework relates to DI and / or programs, devices, and terminal internal modules that operate at any given time between multiple terminals and users, or within a single terminal. Occurs from the need to monitor and communicate events.

  Prior art ISO / IEC21000-2: MPEG-21 DID is shown in FIG. 1 and describes the current state that DID (content component and its structure) can include static IPMP descriptor and DIA descriptor information . The DI declaration (module 1.1) consists of several basic transaction units DI (modules 1.2, 1.3, 1.4) and is provided from the provider to the user. Within the declaration, some important IPMP descriptor information (module 1.5) and DIA descriptor information (module 1.6) are also transmitted to support the multimedia framework for the protection and adaptation of DI transactions. Is done. The same situation applies to REL / RDD descriptor information and ER descriptor information.

  FIG. 2 shows another prior art ISO / IES JTC1 / SC29 / WG11 / N5621: MPEG-21 DIP. Here, the DID engine is shown in module 2.1, the DII engine in module 2.2, the IPMP engine in module 2.3, the REL engine in module 2.4, and the RDD engine in module 2.5. The DIA engine is shown in module 2.6 and the ER engine is shown in module 2.7. These processing engines that can be used to process different technical elements such as DID, DII, IPMP, REL / RDD, DIA, ER, etc. are defined with certain standard parts within the scope of MPEG-21.

  Relationship between processing engine and digital item method engine (DIME) in module 2.8, relationship between DIME and user in module 2.9, and DIME and digital item in module 2.10 The relationship between the basic operations (DIBO: Digital Item Base Operations) is merely a possibility. The actual communication between DIME and the sub-processing engine has not yet been defined for driving interoperable information transmission.

  Furthermore, the relationship between these processing engines has not yet been specified. However, for any application, communication from one processing engine to the other engine is necessary. For example, as shown in FIG. 1, the DID description includes an IPMP descriptor, but calling the IPMP engine from the DID engine is more appropriate and quicker than calling the IPMP engine after returning to the DIM engine. As another example, the DIA descriptor is included in the DID description, but calling the DIA engine from the DID engine is more appropriate and quicker than returning to the DIM engine and then calling the DIA engine. In another application, the IPMP description may include a REL descriptor, and the REL description may include an RDD descriptor. The DII description may include an ER descriptor. Therefore, all these engines need the ability to communicate with each other. This communication is also referred to as intra-terminal communication, and is particularly referred to in this way for event reporting processing in which any processing information processed by other engines must be transmitted to or from the ER engine.

  An object of the present invention is to solve the following problems.

  In other words, the system structure defined in MPEG-21 is intended to cover various applications in which the processing sequence does not take a fixed order and pattern and the next action cannot be predicted as shown in the prior art. Yes. However, the processing results must be transmitted from one engine to the other, and may vary depending on the user's online preferences at that time. Therefore, it is necessary to set up and define a general purpose communication mechanism so that these processing engines can transfer information to each other.

As is well known, the systems shown in the prior art are comprised of various processing engines or modules, which may not be provided by the same vendor. However, information must be transferred and shared between these various modules. When a terminal conforming to the standard is constructed by integrating these various processing modules, it is necessary to set and define a general-purpose communication mechanism so that these processing engines can transfer information to each other.
That is, in the conventional processing method, data is sent radially to various engines around the DIM engine that is the central control engine, returned to the DIM engine, and then sent to another engine. It was processed only in the hub type control mode.

  Such a communication mechanism needs to have a general structure that indicates the destination or source of the information, the response to the message, and the information body in a particular format.

  By defining a series of messages with a generic message structure that can be used in various MPEG-21 modules, communication between these modules can be performed in a specific way within an MPEG-21 terminal.

  It can be easily extended with any type of message by using the basic message structure and describing the common infrastructure within the internal MPEG-21 module negotiation message.

  By constructing an identification system by assigning an ID to each transmission message, it is recognized that any response message is a response to a message having the same ID.

  By using the module name to indicate the sender or receiver of the message within the MPEG-21 terminal, the destination is clearly and directly indicated for either the transmission message or the response message.

  Different types of messages are used to indicate whether the current message is for sending, requesting or responding.

  By including the message information body in the extended message structure, the actual information that is supposed to be sent / requested / responseed from one module to the other is transmitted.

(Function)
MPEG-21 terminal includes DID module with parser, DII module with parser, DIA module with parser, REL / RDD module with parser, IPMP module with parser, ER module with parser, etc. It consists of various processing modules.

  The DID document is provided to the MPEG-21 terminal, and the DID module including a parser functions as a terminal entrance door, opens the DID document, and processes the DID document.

  The processing result may be provided directly to the user, or may be transmitted to the next module for the next processing. In the latter case, the message must be sent directly to the next module or via the control engine DIME. DIME is like a central router, which handles different methods / operations and is expected to receive input from the user. Such a message structure is composed of a message ID, a name of the sending module, a name of the receiving module, and a message information body. The message receiving module responds to the transmitting module with “GoNoGo” information, and stops the processing of the transmitting module or causes the transmitting module to perform the process.

  Some modules can operate to request information to be processed by another module. The receiving side of the message responds with the actual message requested by the transmitting side.

When processing is completed in one module, it may be necessary to send other information to the other module, and communication continues from one module to the other in the same way, according to the defined message structure. Is done.
A first aspect of the present invention is a method for receiving a signal based on a multimedia framework and processing a digital item included therein,
A DID processing step for processing a DID which is a digital item declaration indicating a content component and its structure;
A DIM processing step of interpreting basic operations included in the DID and processing by a DIM which is a digital item method;
At least one other processing step of the following processing steps: 1) DII processing step for processing by DII which is digital item identification;
2) REL processing step for processing by REL which is a rights description language;
3) RDD processing step for processing by RDD which is a rights data dictionary;
4) IPMP processing step for processing by IPMP which is intellectual property management protection;
5) DIA processing step for processing by DIA which is digital item adaptation;
6) ER processing step processed by ER as event report,
And
In this processing method, data is directly transmitted and received between any two of the DID processing step, the DIM processing step, and other processing steps.
According to a second aspect of the present invention, there is provided a processing method characterized in that, in each of the above processing steps, an internal message indicator that is a message for specifying a transmission source and a transmission destination is used.
A third aspect of the present invention is a processing method characterized in that the internal message label is divided into a transmit type for transmission, a request type for request, and a response type for response.
A fourth aspect of the present invention is the processing method characterized in that the InternalMessage label includes one message identifier, Msg_ID, for one theme.
A fifth aspect of the present invention is a processing method characterized in that an internal message mark of the transmission TransmitType includes an information class mark that specifies a type of information to be transmitted and exchanged.
A sixth aspect of the present invention is a processing method characterized in that an internal message mark of the request type for request includes an information class mark that specifies a type of information to be transmitted and exchanged.
A seventh aspect of the present invention is the processing method characterized in that the internal message label of the response type for response includes a GoNoGo label for stopping or executing the process.
An eighth aspect of the present invention is a processing method characterized in that an internal message label of the response type for response includes an info label for transmitting additional information.

Since processing is performed without using the DIM that is the central control engine, the processing efficiency can be increased.
By defining a generic message structure that allows various standards-compliant terminals to cover a wide variety of applications that do not have a fixed sequence order and behavior cannot be predicted, communication between various processing engines Implemented in a mutually operable manner. The present invention increases the flexibility of MPEG-21 terminals and allows digital items to be processed in a simpler and faster way.

  The message structure of the present invention is simple and common for transmitting all kinds of information between a plurality of processing engines in a terminal, and solves the problem of defining a special API for each different processing engine. be able to.

  FIG. 3 is a diagram for explaining how the digital item (DI) is distributed from the server (provider) 10 to the user (consumer) 12 within the MPEG-21 framework. Here, the digital item includes a content part 14 including media contents such as audio, video, and IPMP data, and a header part 16 including addresses of the respective media contents. In the MPEG-21 framework, as shown in FIG. 3, the header part 16 of the digital item is normally distributed to the user 12 before the content part 14. The user 12 can receive the packaged content part 14 only when the header part 16 of the digital item is received first and the condition presented by the server is agreed.

  FIG. 5 is a diagram showing a DID document corresponding to the head part 16 of the digital item described in the DID format. The DID document includes a number of digital items 20, 22, 24. In addition, the resource 26 of each digital item 20, 22, 24 includes the address of the owner who owns the actual digital content. In addition, the DID document also includes some IPMP descriptor information (statements) 28 and DIA descriptor information (statements) 30. Further, the DID document may include REL (Rights Expression Language) / RDD (Rights Data Dictionary) descriptor information, ER (Event Report) descriptor information (not shown), and the like.

  Here, the DID document includes a description of a digital item method (DIM: Digital Item Method) as indicated by a dotted line A in FIG. This description of DIM designates basic processing (playback, duplication, printing, etc.) included in the basic content operations that the user can execute on the content. Specifically, the description of the DIM in FIG. 5 means that if the user pays 100 yen, the content can be reproduced twice. The user (MPEG-21 terminal) performs processing in accordance with descriptions such as the IPMP descriptor information 28 and the DIA descriptor information 30 in the DID document. That is, the user can reproduce the media content existing at the address described in the resource of FIG. 5 only when the user agrees to pay 100 yen.

  FIG. 4 is a flowchart showing the digital item transmission / reception processing described so far. First, the server 10 describes a digital item in a digital item declaration format (step S1). Next, the server 10 distributes (transmits) the digital item (header portion 16) described in the digital item declaration format to the user (MPEG-21 terminal) 12 (step S2). The user 12 receives the digital item (header portion 16) described in the digital item declaration format transmitted from the server 10 (step S3).

  Hereinafter, the process of the user 12 (MPEG-21 terminal) when the DID document shown in FIG. 5 is received will be described. FIG. 6 is a block diagram showing a system configuration of the MPEG-21 terminal 12. As shown in FIG. 6, the MPEG-21 terminal 12 includes a decoder 40, an output unit 42, and a user input unit 44. The decoder 40 includes a DID engine 50 including a DID parser 46, a DIM engine 48 including a DIM presenter 58, a DII engine 51, an IPMP engine 52, a REL engine 53, an RDD engine 54, a DIA engine 55, and an ER engine 56. The DID engine 50 is connected to the DIM engine 48 and is also connected to the DII engine 51, the IPMP engine 52, the REL engine 53, the RDD engine 54, the DIA engine 55, and the ER engine 56. Similarly, the DIM engine 48 is connected to the DII engine 51, the IPMP engine 52, the REL engine 53, the RDD engine 54, the DIA engine 55, and the ER engine 56. Further, the DII engine 51, the IPMP engine 52, the REL engine 53, the RDD engine 54, the DIA engine 55, and the ER engine 56 are connected to each other.

  FIG. 7 is a flowchart of processing performed by the MPEG-21 terminal 12 when a DID document is received. As shown in FIG. 7, first, the DID parser 46 of the decoder 40 analyzes the contents of the digital item described in the DID format (step S11). When the description of DIM appears in the digital item (when the description of <UsageRule> appears), the DID parser 46 sends the DID document to the DIM presenter 58 that is a subroutine. Next, the DIM presenter 58 interprets the description of the DIM (step S12). The DIM presenter 58 then requests the user for values or parameters necessary for executing the basic process according to the basic process semantics specified by the DIM, and presents the basic process to the user. Here, in accordance with the semantics of “obtaining information indicating whether or not to pay 100 yen from the user”, the output unit 42 is used to request a value or parameter to answer the question “whether or not to pay 100 yen”. (Step S13). For example, when the output unit 42 is a display, a message “Do you want to pay 100 yen and play it?” Is displayed on the display.

  The user uses the user input unit 44 to input a value or parameter indicating an answer to the question of whether or not to pay 100 yen. The DIM presenter 58 acquires the value or parameter (step S14). The DIM presenter 58 determines whether or not the user pays 100 yen based on the acquired value or parameter (step S15). When the DIM presenter 58 determines that the user pays 100 yen (for example, the acquired value or parameter is “TRUE”) (step S15), the DIM presenter 58 uses the acquired value or parameter as the DII engine 51, IPMP engine 52, REL. The data is transferred to the engine 54, the RDD engine 54, the DIA engine 55, and the ER engine 56, and the reproduction is continued (step S16). On the other hand, when the user determines not to pay 100 yen (for example, the acquired value or parameter is “FALSE”) (step S15), the DIM presenter 58 uses the acquired value or parameter as the DII engine 50, IPMP. The data is transferred to the engine 52, the REL engine 53, the RDD engine 54, the DIA engine 55, and the ER engine 56, and the reproduction is stopped (step S17). Here, when the DIM presenter 58 obtains a value or parameter from the user in step S4, the DIM presenter 58 converts the value or parameter input in a specific format from the user into the specified format required by the DIM. Can do. That is, it is possible to acquire a value or parameter indicating whether or not to pay 100 yen from the user, convert it into a specified format, and transfer it to the DII engine 50 or the like.

  As described above, by adding a digital item method for designating basic processing (for example, reproduction, copying, printing) of content to a digital item described in the DID format, the server side allows the user to distribute the distributed content. You can specify how to process. Therefore, the copyright of the content distributed to the user can be sufficiently protected.

  In the above description, the resource 26 of the digital items 20, 22, and 24 includes the address of the owner who owns the actual digital content. However, each digital item may include the actual digital content. .

  When the playback is continued, the DIM presenter 58 performs some preparation processing (accompanying processing accompanying the “playback” processing) for acquiring content from the server according to the description of the digital item. FIG. 8 is a flowchart showing a process when the DIM presenter 58 executes a plurality of preparation processes. As shown in FIG. 8, first, the DIM presenter 58 calls the DIA engine 55 to check the conformity between the DIA description of the digital item and the DIA description of the MPEG-21 terminal (DIA conforming process: step S21). Thereby, it is checked whether or not the decoder function of the MPEG-21 terminal is suitable for the content. FIG. 9 is a flowchart of the DIA conforming process performed by the DIM presenter 58. The DIM presenter 58 interprets the description of the DIM related to the DIA conforming process (step S32). The DIM presenter 58 then requests the user, the resource on the Internet, or the DID document for values or parameters necessary to execute the DIA conformance process according to the DIA description conformance semantics specified by the DIM ( Step S33). When the DIM presenter 58 obtains a necessary value or parameter from a user, a resource on the Internet, or a DID document (step S34), the DIM presenter 58 calls the DIA engine 55 and transfers the obtained value or parameter to the DIA engine 55. The DIA conforming process is executed (step S35). The DIA engine 55 performs the DIA conforming process using the value or parameter transferred from the DIM presenter 58. The DIM presenter 58 detects that the two DIA descriptions do not match from the signal output from the DIA engine 55 (acquires a signal indicating that the two DIA descriptions do not match from the DIA engine 55) (step S22). Then, the reproduction process is stopped (FIG. 8, step S23). On the other hand, it is detected from the signal output from the DIA engine 55 that the two DIA descriptions are compatible (a signal indicating that the two DIA descriptions are compatible is acquired from the DIA engine 55) (step S22). The DIM presenter 58 calls the IPMP engine 52 to execute IPMP processing (step S24). Here, the DIM presenter 58 may acquire values or parameters necessary for the IPMP processing from the user or the like and transfer them to the IPMP engine 52 in the same manner as the DIA adaptation processing. In this IPMP process, the IPMP engine 52 examines in what manner the content is protected and acquires a necessary IPMP tool. The DIM presenter 58 detects that the IPMP tool cannot be acquired from the signal output from the IPMP engine 52 (acquires a signal indicating that the IPMP tool cannot be acquired from the IPMP engine 52) (step S25), and reproduction processing. Is canceled (step S23). On the other hand, when the DIM presenter 58 detects that the IPMP tool can be acquired from the signal output from the IPMP engine 52 (acquires a signal indicating that the IPMP tool can be acquired from the IPMP engine 52), that is, when the protection can be canceled. Then, the DIM presenter 58 calls the REL engine 53 and checks whether or not the user has the right to play (REL processing: step S26). Here, the DIM presenter 58 may acquire values or parameters necessary for the REL processing from the user or the like and transfer them to the REL engine 53 in the same manner as the DIA adaptation processing. The DIM presenter 58 detects from the signal output from the REL engine 53 that the user does not have the right (qualification) to play (a signal indicating that the user does not have the right to play from the REL engine 53). (Obtain) (step S27), the reproduction process is stopped (step S23). On the other hand, the DIM presenter 58 detects that the user has the right to play based on the signal output from the REL engine 53 (acquires a signal indicating that the user has the right to play from the REL engine 53). (Step S27), the MPEG-21 terminal requests content from the server, and the content is provided from the server (Step S28). Note that the preparation processing for reproduction is not limited to the above-described one. If the digital item is not protected, the IPMP process can be omitted. Further, when the IPMP process includes a process for checking whether or not the user has the right to play, the REL process can be omitted.

  Furthermore, the order of each preparation process is not limited to the above. For example, REL processing, DIA adaptation, and IPMP processing may be performed in this order. This order is determined by the order in which the description of the DIM in the DID document, for example, the description regarding each preparation process exists. Therefore, the server side can freely determine the order of this preparation process.

  The DIM presenter 58 has an interactive relationship with the user. After the user chooses to pay 100 yen and play, the DIM presenter 58 further interprets the description of the MID described in the DIA descriptor information (statement) 30 and newly performs another process (“play”). Associated process associated with the process) can be performed. For example, when the content is a video, it may be a process of determining a display size. The DIM presenter 58 may request a value or parameter related to the display size from the user based on the semantics of “acquiring information indicating the display size from the user” of the display size determination process. This can be realized, for example, by presenting the user with a plurality of display size options. When the user selects one of the options, that is, when the DIM presenter 58 obtains a value or parameter relating to the display size from the user, the DIM presenter 58 transfers the obtained value or parameter to the DIA engine 50. To do. Alternatively, the DIM presenter 58 may write the acquired value or parameter in a predetermined position of the DIA descriptor information 30 in the DID document and transfer the DID document to the DIA engine 55.

The accompanying process described above is included in the basic operation and is not limited to the process of determining the display size. For example, processing for determining resolution may be performed.
In the decoder apparatus and method of the present invention, a hub type control mode in which data is transmitted / received radially around the DIM engine 48, and peripheral engines 50-56 connected to the DIM engine 48 without returning to the DIM engine 48. Can be operated in any of the lateral control modes in which data is directly transmitted and received between the two.
In the hub type control mode, data to be processed is sent from the DIM engine 48 to a peripheral engine, for example, the DII engine 51, processed by the DII engine 51, and the processed data is returned to the DIM engine 48 again. It is. If further processing is required, the data is sent from the DIM engine 48 to the next processing engine such as the IPMP engine 52. The data processed by the IPMP engine 52 is returned to the DIM engine 48 again. In this manner, data is transmitted radially from the DIM engine 48 to any one of the various engines 50-56 and returned from the target engine to the DIM engine 48.
In the case of the lateral control mode, data to be processed is transmitted and received between any two engines among the engines 48 and 50-56. In this case, the burden on the DIM engine 48 can be reduced and the efficiency of data processing can be increased. As will be described below, when data is processed in the lateral control mode, a predetermined message is used in the descriptor statement.

  The lateral type control mode will be further described.

(Send messages between different modules)
The DIM engine 48 needs to interact with all parts (modules) of the ISO / IEC 21000 terminal / framework. Information exchange with another part of the ISO / IEC 21000 terminal can be defined as a general-purpose API in MPEG-21. The only way to exchange information is to send messages to the terminal part (module) of ISO / IEC 21000.

  Different processing engines require different information. Information can be transmitted directly within the DID module or can be transmitted separately between different modules. For example, the IPMP system module requests IPMP information, the REL module requests usage rule information, and the DIA module requests DIA description information.

  As shown in FIG. 10, there is a useful scenario in which information exchange is required between different modules, and examples thereof include the following. The DID module 50 needs to transfer the usage right information (3.1) specifying the content to the REL module 53, and the REL module 53 analyzes and processes the usage right. The DIA description information is requested to be transferred from the DID module 50 to the DIA module 55, and this information is used to compare the actually input DIA description in the DID with the actual DIA description between terminals. And / or media resource adaptation is performed. If the DIA module 55 does not match the result of the DIA matching, the DIA module 55 transmits a response message including the “GoNoGo” information (3.2) via the DIM engine 48, and stops the DID module 50. The DII identification information (3.3) inside the DII may be transmitted to the REL module 53 in order to make a persistent association of the identification of the usage rights that specify the content.

  In the above case, DIA description regarding terminal, network and user preferences, IPMP information for IPMP tool description, REL information including usage rights and usage conditions specifying content, and DII information for specific items must be exchanged. I must. If necessary, negotiation is performed based on the information. Therefore, in order to transmit such information, it is necessary to define interoperable negotiation mechanisms and messages to facilitate communication between different processing engines such as DID engine 50, IPMP engine 52, DIA engine 55, etc. . As shown in FIG. 11, a universal multimedia access terminal can be constructed by following the negotiation mechanism having the message structure defined here.

  As shown in FIG. 11, a message-based general purpose API is placed around various processing modules / engines. All communication between different modules in the terminal is performed using the Msg-API in module 4.1.

  As shown in FIG. 11, first, the message (M1) is transmitted from the DID engine 50 to the REL engine 53, the message (M2) is transmitted to the DIA engine 55, the message (M3) is transmitted to the ER engine 56, etc. The

  Upon receipt of the message (M1) from the DID engine 50, the REL engine 53 processes it and transmits it to the IPMP engine 52, and transmits the message (M2) to the ER engine 56.

  Upon receiving the message (M1) from the REL engine 53, the IPMP engine 52 processes this and transmits it to the ER engine 56.

  The ER engine 56 receives all messages from various processing engines and writes events or processing results to a log file. It may also be necessary to send a message to another processing engine.

These processing engines or modules include a DID engine 50, a DII engine 51, an IPMP engine 52, a REL engine 53, an RDD engine 54, a DIA engine 55, and an ER engine 56, as shown in FIGS. However, the present invention is not limited to this, and other engines can be included. .

  The above design is data-driven, that is, lateral processing, and there is no router-like main engine that helps message transmission. Each processing engine is called by the data itself to be processed.

  In contrast, a hub-type design is shown in FIG. In this design, all messages are forwarded from or to various processing engines via the central processing engine DIM module 48.

  The DIM engine shown here has two main functions in this case.

1) DID Engine ⇔ DIM Engine ⇔ User's Basic Options in User Processes all defined basic operations or methods contained in the DID document, presents them to the user according to the defined basic operations or methods, and the user's choices entered by the user / Transfer selection / preference to other processing engines.

2) Processing engine ⇔ DIM engine ⇔ Processing engine As a message center, it supports message transfer from one processing engine to the other processing engine, controls messages sent to or received from the processing engine, and each processing engine If the basic operation or method is not defined, the information exchange between the processing engine and the user is supported.

  FIG. 13 shows a case where a DID document 16 in DID format (same as shown in FIG. 5) is provided to an MPEG-21 terminal configured with the message API of module 6.1. The DID engine 50 receives the DID document 16 and processes the DI based on various basic operation messages included therein.

  The DIM engine 48 serves as the main engine. First, the basic operation is received and interpreted (a), presented to the user as needed (b), input from the user is collected (c), and transmitted to the other processing engine, for example, the DII engine 51 (D1), transmission to REL engine 53 (d2), transmission to IPMP engine 52 (d3), transmission to DIA engine 55 (d4), transmission to ER engine 56 (d5), or other player, Transmission (d6) to a non-standard processing engine 6.4 such as a transcoder is performed. Although not shown in FIG. 13, it may be configured to include an RDD engine.

  The information may be in a lateral control mode that is transmitted directly from one processing engine to the other processing engine using the message API defined in the present invention, and using the message API defined in the present invention. It is also possible to use a hub type control mode in which data is transmitted from one processing engine to the other processing engine via the DIM engine. In the latter case, the burden on the DIM engine 48 increases, but the advantage of central control can be obtained.

  The processing engine of module 6.4 may be a non-standard module such as a video player, media format transcoder, etc. Extensibility to cover non-standard processing parts is supported by the current design of the generic message API.

(General internal message)
The generic internal message defined in the present invention can transfer useful information from module to module (engine to engine) to allow a lateral control mode. A DIM (Digital Item Method) processing engine 48 is also considered to be a special processing engine and can process methods / operations as a central processing unit. Here, it is assumed that a series of defined methods or operations are defined and exist that allow connected modules to communicate at the current terminal. Other processing engines such as DID engine, DII engine, DIA engine, IPMP engine, REL / RDD engine, and ER engine can each process related information transmitted from DIM engine, but it is quick and efficient For processing, direct information communication between these engines may be required.

  The syntax and semantics of general-purpose InternalMessageType are shown below, and the structure is shown in FIG.

<xs: schema xmlns: xs = "http://www.w3.org/2001/XMLSchema" elementFormDefault = "qualified" attributeFormDefault = "unqualified">
<xs: element name = "InternalMessage" type = "BasicInternalMessageType">
<xs: annotation>
<xs: documentation> messages for information exchanging among modules </ xs: documentation>
</ xs: annotation>
</ xs: element>
<!-#######################################->
<!-Definition of Basic Internal Message->
<!-#######################################->
<xs: complexType name = "BasicInternalMessageType">
<xs: sequence>
<xs: element name = "Msg_ID" type = "xs: nonNegativeInteger"/>
<xs: element name = "SenderModule" type = "xs: nonNegativeInteger"/>
<xs: element name = "RecipientModule" type = "xs: nonNegativeInteger"/>
</ xs: sequence>
</ xs: complexType>
<!-#######################################->
<!-Definition of Internal Transmit->
<!-#######################################->
<xs: complexType name = "TransmitType">
<xs: complexContent>
<xs: extension base = "BasicInternalMessageType">
<xs: sequence>
<xs: element name = "MessageInformation" type = "MessageInformationType"/>
</ xs: sequence>
</ xs: extension>
</ xs: complexContent>
</ xs: complexType>
<!-#######################################->
<!-Definition of Internal Request->
<!-#######################################->
<xs: complexType name = "RequestType">
<xs: complexContent>
<xs: extension base = "BasicInternalMessageType">
<xs: sequence>
<xs: element name = "InformationClass">
<xs: simpleType>
<xs: restriction base = "xs: string">
<xs: enumeration value = "IPMPInformation"/>
<xs: enumeration value = "DIAInformation"/>
<xs: enumeration value = "DIIInformation"/>
<xs: enumeration value = "RightsInformation"/>
<xs: enumeration value = "OtherInformation"/>
</ xs: restriction>
</ xs: simpleType>
</ xs: element>
</ xs: sequence>
</ xs: extension>
</ xs: complexContent>
</ xs: complexType>
<!-##########################################->
<!-Definition of Internal Response->
<!-##########################################->
<xs: complexType name = "ResponseType">
<xs: complexContent>
<xs: extension base = "BasicInternalMessageType">
<xs: choice>
<xs: element name = "GoNoGo" type = "GoNoGoType"/>
<xs: element name = "MessageInformation" type = "MessageInformationType"/>
</ xs: choice>
</ xs: extension>
</ xs: complexContent>
</ xs: complexType>
<!-###################################->
<!-Definition of MessageDescription->
<!-###################################->
<xs: complexType name = "MessageInformationType">
<xs: sequence>
<xs: element name = "InformationClass">
<xs: simpleType>
<xs: restriction base = "xs: string">
<xs: enumeration value = "IPMPInformation"/>
<xs: enumeration value = "DIAInformation"/>
<xs: enumeration value = "DIIInformation"/>
<xs: enumeration value = "RightsInformation"/>
<xs: enumeration value = "OtherInformation"/>
</ xs: restriction>
</ xs: simpleType>
</ xs: element>
<xs: element name = "InformationData" type = "InformationDataType"/>
</ xs: sequence>
</ xs: complexType>
<!-##########################################->
<!-Definition of Inner Module Information Data->
<!-##########################################->
<xs: complexType name = "InformationDataType" mixed = "true">
<xs: sequence>
<xs: any namespace = "## any" processContents = "lax" minOccurs = "0"/>
</ xs: sequence>
<xs: attribute name = "mimeType" type = "xs: string"/>
</ xs: complexType>
<!-##########################################->
<!-Definition of GoNoGo->
<!-##########################################->
<xs: complexType name = "GoNoGoType">
<xs: simpleContent>
<xs: extension base = "xs: boolean">
<xs: attribute name = "Info" type = "xs: string" use = "optional"/>
</ xs: extension>
</ xs: simpleContent>
</ xs: complexType>
</ xs: schema>

FIG. 7 shows the types of message indicators required for the lateral control mode.
(Semantics of InternalMessage schema element)
7.1 indicates the InternalMessage label. This message indicator is a message indicator for sending information between different modules. The basic form of the InternalMessage label 7.1 is Basic InternalMessageType 7.2. The InternalMessage indicator can be divided into a message indicator for transmission (TransmitType), a request (RequestType), and a response (ResponseType).

  The indicator of Basic Internal Message Type 7.2 describes basic / common information in the negotiation message of the internal module, and includes elements of Msg_ID, SenderModule, and RecipientModule.

  The Msg_ID indicator is specified by a message source (one module), and one message identifier is generated and described for one theme. All messages sent in response to messages with a certain theme have the same message identifier.

  The SenderModule indicator describes the module identifier of the message source.

  The RecipientModule indicator describes the module identifier that is the recipient of the message.

  The TransmitType 7.3 indicator describes an internal negotiation message to be transmitted, and is obtained by adding MessageInformation7.4 to BasicInternalMessageType.

  The MessageInformation 7.4 indicator is for carrying information transmitted and exchanged between modules, and includes InformationClass and InformationData.

  The InformationClass indicator describes the type of information transmitted in the internal negotiation message, that is, the kind. This “Class” can specify any one of RightsInformation, IPMPInformation, DIAInformation, DIIIInformation, and OtherInformation. They are used for the transmission of various information processed by different internal modules.

  The InformationData indicator describes the actual information data as a message payload that directly contains an appropriately created XML fragment. The schema of such a fragment contained within the InformationData is identified by the fragment's namespace.

  The RequestType 7.5 indicator describes a requested internal negotiation message, and is obtained by adding an InformationClass indicator to BasicInternalMessageType. InformationClass has the same semantics as defined in MessageInformationType.

  The ResponseType 7.6 indicator describes the internal negotiation message to be responded to, and includes two elements “GoNoGo” and “MessageInformation” in the BasicInternalMessageType. The “GoNoGo” element is used to respond to the sent “Transmit” message, and the “MessageInformation” element is used to respond to the sent “Request” message.

  The GoNoGo 7.7 indicator is used when one module causes another module to stop processing or cause another module to perform processing. “True (true)” indicates that the message transmission side permits “execution (go)” to the message reception side, and “False (false)” indicates “disallow” (disallow) or “no execution (no-go)”. Is shown.

  The Info indicator is an attribute of the “GoNoGo” element for transmitting additional information.

  An example of how to use the defined internal message in inter-module communication is shown below. In the following example, different integers are assigned to different processing engines in the MPEG-21 terminal to simply represent the identification between limited modules. For example, an identification number of 1 is assigned to the DIM engine, 2 to the DID engine, 3 to the REL engine, 4 to the IPMP engine, 5 to the ER engine, and 6 to the DIA engine.

  First, an example of transmission / reception of rights information is shown. The right information is directly transmitted from the DID module 50 to the REL module 53, and the REL module 53 returns the information after processing, and the DID module 50 proceeds to the next step.

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "TransmitType">
<Msg_ID> 001 </ Msg_ID>
<SenderModule> 2 </ SenderModule>
<RecipientModule> 3 </ RecipientModule>
<MessageInformation>
<InformationClass> RightsInformation </ InformationClass>
<InformationData>
<PlayTimes> 1 </ PlayTimes>
</ InformationData>
</ MessageInformation>
</ InternalMessage>

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "ResponseType">
<Msg_ID> 001 </ Msg_ID>
<SenderModule> 3 </ SenderModule>
<RecipientModule> 2 </ RecipientModule>
<GoNoGo> true </ GoNoGo>
</ InternalMessage>

  Next, an example of transmission / reception of IPMP tool information is shown. The IPMP tool information is directly requested from the IPMP engine 52 to the ER module 56, and the ER module 56 returns the information to the IPMP engine 52, and the IPMP engine 52 performs further processing.

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "RequestType">
<Msg_ID> 002 </ Msg_ID>
<SenderModule> 4 </ SenderModule>
<RecipientModule> 5 </ RecipientModule>
<InformationClass> IPMPInformation </ InformationClass>
</ InternalMessage>

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "ResponseType">
<Msg_ID> 002 </ Msg_ID>
<SenderModule> 5 </ SenderModule>
<RecipientModule> 4 </ RecipientModule>
<MessageInformation>
<InformationClass> IPMPInformation </ InformationClass>
<InformationData>
<IPMPToolList>
<ToolID> 11 </ ToolID>
<ToolID> 12 </ ToolID>
</ IPMPToolList>
</ InformationData>
</ MessageInformation>
</ InternalMessage>

  Next, an example of transmission / reception of a user feature description received from a user is shown. The user feature description is transmitted from the DIM engine 48 to the DIA module 55. After processing, the DIA module 55 returns DIA match information and the DIM engine 48 proceeds to the next step. For example, it subsequently sends IPMP information to the IPMP engine 52, receives a response message, and notifies the DIM engine to stop the “player” module.

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "TransmitType">
<Msg_ID> 003 </ Msg_ID>
<SenderModule> 1 </ SenderModule>
<RecipientModule> 6 </ RecipientModule>
<MessageInformation>
<InformationClass> DIAInformation </ InformationClass>
<InformationData>
<DisplaySize> QCIF </ DisplaySize>
</ InformationData>
</ MessageInformation>
</ InternalMessage>

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "ResponseType">
<Msg_ID> 003 </ Msg_ID>
<SenderModule> 6 </ SenderModule>
<RecipientModule> 1 </ RecipientModule>
<GoNoGo> true </ GoNoGo>
</ InternalMessage>

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "TransmitType">
<Msg_ID> 004 </ Msg_ID>
<SenderModule> 1 </ SenderModule>
<RecipientModule> 4 </ RecipientModule>
<MessageInformation>
<InformationClass> IPMPInformation </ InformationClass>
<InformationData>
<IPMPDescriptor>
<ToolID> 13 </ ToolID>
<ControlPoint> Before </ ControlPoint>
</ IPMPDescriptor>
</ InformationData>
</ MessageInformation>
</ InternalMessage>

<InternalMessage xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "InternalMessage.xsd" xsi: type = "ResponseType">
<Msg_ID> 004 </ Msg_ID>
<SenderModule> 4 </ SenderModule>
<RecipientModule> 1 </ RecipientModule>
<GoNoGo> false </ GoNoGo>
</ InternalMessage>

The present invention is considered to have the following configurations from various aspects. According to a first configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, comprising:
Building a terminal with a general message API having a message structure;
Integrating a digital item declaration (DID) engine and another processing engine to construct the terminal, wherein the other processing engines include a digital item method (DIM) engine, a digital item identification (DII) engine, Rights description language (REL) engine, rights data dictionary (RDD) engine, intellectual property management protection (IPMP) engine, digital item adaptation (DIA) engine, event reporting (ER) engine, and engine not specified as any player, etc. Including, but not limited to, steps,
Processing the DID input with the DID engine with a DID parser;
Interpreting each element of the DID input and basic operations included in the DID input;
Based on the basic operation, using the DIM engine to present options or selections to the user as needed;
Retrieving a value or parameter from a user or a designated point from a DID document;
Transmitting the value or parameter from a processing engine directly or via a central control DIM engine to the specific processing engine using the message structure;
Calling a specific processing engine to perform processing based on the value or parameter;
Transmitting the processing result to the next processing engine for further processing using the message structure;
And a step of completing content consumption after various processes.

According to a second configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework,
Forming a terminal with various modules that may be provided by different vendors;
Building each of the modules with a general message API having a message structure so that the module can understand the communications performed based on the message API;
Transmitting information such as values, parameters or status from one module to the other using the message API;
Returning a processing result or related information to the transmission and completing the communication.

According to a third configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework,
Forming a terminal with various modules that may be provided by different vendors;
Building each of the modules with a general message API having a message structure so that the module can understand the communications performed based on the message API;
Requesting information such as values, parameters or status from one module to the other using the message API;
Returning the requested actual information in response to the request message, and completing the communication.

According to a fourth configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the message structure according to claim 1, 2 and 3 comprises:
Including a generic message structure that can be extended by various types of messages, such as transmissions, requests, responses, and / or other message types defined by the third part;
Including a message information transmitted by various types of messages.

According to a fifth configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the general message structure according to claim 4 comprises:
Assigning a message ID to each message in the message structure, and enabling a response message to respond to the message using the same ID;
In the message structure, the method further includes the step of indicating the module of the message source or destination by using the name of the processing module or the assigned internal module number as the sender or receiver.

According to a sixth configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the message information body according to claim 4 uses a transmission message. In a situation where the information is communicated to a specific processing engine or the information is transmitted from one module to the other,
A step including an InformationClass that describes the type of information in an enumeration of RightsInformation, IPMPInformation, DIAInformation, DIIIInformation, and OtherInformation;
And including information data that describes actual information data such as values, parameters, or status as message payloads that directly contain appropriately created XML fragments.

According to a seventh configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the message information body according to claim 4 is the message information body according to claim 6. In a situation where a reply message is used to respond to a transmission message,
Including the processing result for causing the other module to stop processing using the “GoNoGo” element or causing the other module to perform processing;
Including a “Info” element that conveys some additional result information.

  According to an eighth configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the message information body according to claim 4 is the other using a request message. In the situation where the information is obtained from the module or the processing engine, the requested information type further includes InformationClass described in the enumeration of RightsInformation, IPMPInformation, DIAInformation, DIInformation, and OtherInformation.

According to a ninth configuration, the present invention is a communication method between various processing modules in a universal multimedia access framework, wherein the message information body according to claim 4 is charged using a response message. In the situation of responding to the request message according to paragraph 8,
A step including InformationClass that describes the type of requested information in an enumeration of RightsInformation, IPMPInformation, DIAInformation, DIIIInformation, and OtherInformation;
And a step of including InformationData that describes the requested actual information data such as the value, parameter, or status as a message payload that directly includes an appropriately generated XML fragment.

  The present invention is applicable to a digital item processing method and apparatus.

It is a figure which shows the hierarchy of the DID document containing an IPMP protection descriptor and a DIA descriptor. It is a figure which shows operation | movement description of the decoder which has only hub type control modes. It is a figure explaining a mode that a digital item (DI) is delivered to a user from a server. It is a flowchart which shows the transmission / reception process of a digital item. It is a figure which shows the DID document corresponding to the head part of the digital item described in the DID format. It is a block diagram which shows the structure of the system of an MPEG-21 terminal. It is a flowchart of the process which an MPEG-21 terminal performs when a DID document is received. It is a flowchart which shows a process when a DIM presenter performs several preparation processes. It is a flowchart of the DIA adaptation process which a DIM presenter performs. It is a figure which shows the message transfer between the modules in an MPEG-21 terminal. It is a figure which shows the message as a general purpose API constructed | assembled in the MPEG-21 terminal in order to perform the direct message transfer between processing engines. It is a figure which shows the message transfer through a DIM engine in an MPEG-21 terminal. It is a figure which shows the detail of the DIM engine function which has a processing engine in the MPEG-21 terminal provided with message API. FIG. 2 shows a messaging infrastructure transmitted between different modules in an MPEG-21 terminal.

Claims (16)

A method for receiving a signal based on a multimedia framework and processing a digital item contained therein,
A DID processing step for processing a DID which is a digital item declaration indicating a content component and its structure;
A DIM processing step of interpreting basic operations included in the DID and processing by a DIM which is a digital item method;
At least one other processing step of the following processing steps: 1) DII processing step for processing by DII which is digital item identification;
2) REL processing step for processing by REL which is a rights description language;
3) RDD processing step for processing by RDD which is a rights data dictionary;
4) IPMP processing step for processing by IPMP which is intellectual property management protection;
5) DIA processing step for processing by DIA which is digital item adaptation;
6) ER processing step processed by ER as event report,
And
A processing method characterized in that data is directly transmitted and received between any two processing steps of a DID processing step, a DIM processing step, and other processing steps.   2. The processing method according to claim 1, wherein an internal message label that is a message for specifying a transmission source and a transmission destination is used in each of the processing steps.   3. The processing method according to claim 2, wherein the internal message label is divided into a transmission type for transmission, a request type for request, and a response type for response.   The processing method according to claim 2, wherein the InternalMessage label includes one message identifier, Msg_ID, for one theme.   4. The processing method according to claim 3, wherein the InternalMessage tag of the TransmitType for transmission includes an InformationClass tag that identifies a type of information to be transmitted and exchanged.   The processing method according to claim 3, wherein the internal message label of the request type for request type includes an information class mark that identifies a type of information to be transmitted and exchanged.   The processing method according to claim 3, wherein the InternalMessage label of the ResponseType for response includes a GoNoGo label for stopping or executing the process.   The processing method according to claim 3, wherein an internal message label of the response type for response includes an info label for transmitting additional information. A device for receiving a signal based on a multimedia framework and processing a digital item contained therein,
A DID engine that processes DIDs, which are digital item declarations showing content components and their structure;
A DIM engine that interprets the basic operations contained in the DID and processes them with a DIM that is a digital item method;
At least one other engine of the following engines: 1) DII engine for processing by DII which is digital item identification;
2) REL engine for processing by REL which is a rights description language,
3) RDD engine for processing by RDD which is a rights data dictionary,
4) IPMP engine for processing by IPMP which is intellectual property management protection;
5) DIA engine to process by DIA which is digital item adaptation,
6) ER engine to process by ER which is event report,
And
A processing apparatus in which data is directly transmitted and received between any two of a DID engine, a DIM engine, and another engine.   The processing apparatus according to claim 9, wherein an internal message label that is a message for specifying a transmission source and a transmission destination is used in each engine.   11. The processing apparatus according to claim 10, wherein the internal message label is divided into a transmission type for transmission, a request type for request, and a response type for response.   11. The processing apparatus according to claim 10, wherein the internal message label includes one message identifier, Msg_ID, for one theme.   The processing apparatus according to claim 11, wherein the internal message label of the transmission TransmitType includes an information class mark that identifies a type of information to be transmitted and exchanged.   The processing apparatus according to claim 11, wherein an internal message tag of the request type for request type includes an information class tag that identifies a type of information to be transmitted and exchanged.   The processing apparatus according to claim 11, wherein the InternalMessage label of the ResponseType for response includes a GoNoGo label for stopping or executing the process. The processing apparatus according to claim 11, wherein an internal message label of the response type for response includes an info label for transmitting additional information.

Images