AU2003244588B2 - Verification Apparatus, Verification Method, Verification System, and Storage Medium - Google Patents

Description

:Ti 1~ I_ j S&F Ref: 470498D1

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Hiroshi Inoue Toshiyuki Nakagawa Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Verification Apparatus, Verification Method, Verification System, and Storage Medium The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5845c TITLE OF THE INVENTION VERIFICATION APPARATUS, VERIFICATION

METHOD,

VERIFICATION SYSTEM, AND STORAGE MEDIUM BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates to a verification apparatus, verification method, verification system, and storage medium and, more particularly, to a verification apparatus, verification method, verification system, and storage medium, which are suitable when verification is necessary for the purpose of copyright protection associated with individual objects of a moving image to be played back.

DESCRIPTION OF THE RELATED ART Fig. 1 is a block diagram showing a conventional digital video data transmission/reception system. As shown in Fig. 1, a digital video data distribution server 10 downloads digital video data recorded in a digital video data storage device 12 such as a hard disk annexed to the distribution server 10 to a digital video data reception client 20 through a network 30 such as the Internet in response to a request from the reception client 20. The distribution server 10 has a conversion section 11 for coding digital video data. Digital video data is coded by the conversion section 11 to decrease the data amount, and distributed to the reception client 20 in accordance with a procedure such as the TCP/IP protocol. The reception client 20 has a conversion section 21 for decoding digital video data. A received digital video signal is played back by the conversion section 21 and displayed, recorded, or edited.

An example of a system which constructs one moving image scene from a plurality of objects, codes and compresses each object by the conversion section 11 of the distribution server 10, transfers the objects to the reception client 20, and decodes and reconstructs the objects in the reception client 20 to play back the moving image scene is an MPEG-4 player.

Fig. 2 is a block diagram of a conventional MPEG-4 player. Fig. 2 is based on "ISO/IEC FCD 14496-1 Fig. and this has been described in detail in "ISO/IEC FCD 14496-1". Only a schematic arrangement will be described below.

An MPEG-4 bit stream transmitted through a network or the like or MPEG-4 bit stream read out from a storage medium such as a DVD-RAM is received by "TransMux Layer" in accordance with a procedure corresponding to transmission/read (session establishment) and separated 2 into streams such as scene description information, object data, and object description data, decoded, and played back by a "FlexMux" section. On the basis of the scene description information, a scene is played back or graphically processed.

Fig. 3 is a schematic and simple block diagram of the player shown in Fig. 2. When verification is necessary for the purpose of copyright protection for individual objects, a bit stream containing a plurality of object data including the scene description information may contain "IP Data Set" (copyright information group).

However, even if the transmission bit stream contains "IP Data Set" (copyright information group), and "IP Data" is played back by "Object Descriptors" of the system shown in Fig. 2 or 3, "IP Data" is not processed in image playback processing. For this reason, "IP Protection" (copyright protection) processing is not executed.

In the system shown in Fig. 2 or 3, even when an "IP Data Set" (copyright information group) stream is contained in addition to the transmission bit stream, "IP Data" is not always played back by "Object Descriptors". Even if "IP Data" is played back by "Object Descriptors", "IP Data" is not processed in image playback processing. For this reason, "IP 3 Protection" (copyright protection) processing is not executed.

In this case, an application can receive decoded "IP Data Set" and execute "IP Protection" processing.

However, this processing is unique to the application and is not always executed by another player or a player of another type.

In the system shown in Fig. 2 or 3, an image is played back after verification processing is performed for individual objects. For this reason, when new objects appear one after another in playing back a moving image scene, production must be temporarily stopped to require verification.

When verification is performed without stopping playback, images to be played back are omitted corresponding to the time required for verification.

SUMMARY OF THE INVENTION The present invention has been made in consideration of the above situation, and has as its object to efficiently execute verification processing, effectively protect a copyright or the like, effectively use copyright works, and solve the problem that a played back image is omitted due to the delay time associated with verification processing.

According to the first aspect of the present 4 invention, there is provided an information processing method comprising the steps of: a) receiving an information data stream, generated by multiplexing a plurality of coded object data and associated intellectual property management data, from a contents distribution server, wherein said intellectual property management data includes source information representing a copyright holder of said object data; b) transmitting verification request data, based on said information included in the received intellectual property management data, to said copyright holder, via a different communication channel from that used for receiving said information data stream; c) receiving, from said copyright holder, verification result data relating to said object data; and d) controlling, based on said verification result data, a decoding process of said object data.

According to the second objection of the present invention, there is provided an information processing method comprising the steps of: a) transmitting an information data stream, generated by multiplexing a plurality of coded object data and associated intellectual property management data, to a client, wherein said intellectual property management data includes source information representing a copyright holder of said object data; b) receiving verification request data relating to said object data via a different communication channel from that used for transmitting said information data stream; and c) verifying the object data based on said verification request data.

According to the third aspect of the present invention, there is provided an information processing method comprising the steps of: [R:\LIBE]41 5 8.doc:nmxl -6a) receiving an information data stream, generated by multiplexing a plurality of coded object data and associated intellectual property management data, from a contents distribution server; b) verifying said object data based on said received intellectual property management data; c) transmitting verification result data and resend request data that requests a resend of said information data stream from the beginning, to said contents distribution server; d) receiving an information data stream resent from said contents distribution server; and e) reproducing said resent information data stream.

According to the fourth aspect of the present invention, there is provided an information processing method, executed in a contents distribution server, comprising the steps of: a) transmitting an information data stream, generated by multiplexing a plurality of coded object data and associated intellectual property management data, to a client; b) receiving verification result data and resend request data that requires a resent of said information data stream, from said client; and c) transmitting said information data stream from the beginning based on said verification result data and said resend request data, to the client.

Other features and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.

[R:ALIBE]41I 58.doc:mxl BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram showing a conventional digital video data transmission/reception system; Fig. 2 is a block diagram showing the arrangement of a conventional MPEG-4 player; [The next page is page 23] [R:\LBE]4158.doc:mxl Fig. 3 is a block diagram showing the schematic and simple arrangement of the player shown in Fig. 2; Fig. 4 is a block diagram showing the arrangement of an MPEG-4 player according to a preferred embodiment of the present invention; Fig. 5 is simple block diagram for explaining remote access; Fig. 6 is a view showing an example of a hierarchical structure when a URL destination further has a URL designation; Fig. 7 is a flow chart showing client operation associated with verification processing; Fig. 8 is a block diagram showing the arrangement shown in Fig. 3, to which an IPMP System processing section is further added; Fig. 9 is a view showing the internal functional block diagram and data flow of an MPEG-4 player; Fig. 10 is a view simply showing a data pro-essing process shown in Fig. Fig. 11 is a flow chart showing an example of time adjustment operation of an MPEG-4 object access data unit; Fig. 12 is a view showing data movement and timing of a Decoding Buffer and Composition Memory; Fig. 13 is a view showing a data processing process in the arrangement shown in Fig. 6, to which an 23

I

IPMP System processing section is added; and Fig. 14 is a flow chart showing an operation example of the IPMP System shown in Fig. 8.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below with reference to the accompanying drawings. The following embodiments are related to a system for efficiently executing verification processing using a so-called "back-channel" (First Embodiment) Fig. 4 is a block diagram showing the schematic arrangement of a system including an MPEG-4 player according to a preferred embodiment of the present invention. The system shown in Fig. 4 operates "IP Data" to realize "IP Protection". The system shown in Fig. 4 has an IPMPS (Intellectual Property Management and Protection System) 207 and is different from the system shown in Fig. 3 in that the copyright verification and protection function are realized by this IPMPS 207.

Fig. 7 is a flow chart showing client operation associated with verification processing. Operation of the system shown in Fig. 4 will be described below with reference to Fig. 7. On the server side, a multiplexer 201 receive individual objects from a plurality of network sites 202 to 204 having different URLs (Uniform 24 Resource Locators) such as URL1, URL2, and URL3, and generates moving image data constructed by the plurality of objects. This moving image data is transmitted to a client through the network in response to a request from the client as an MPEG-4 bit stream 205.

In step Si, the client receives the MPEG-4 bit stream 205 from the server. Each object constructing the MPEG-4 bit stream has information (URL information) representing the copyright holder. In step S2, the client separates the received MPEG-4 bit stream into a plurality of streams such as the plurality of objects and accompanying information (including URL information) by a demultiplexer 206. The URL information of each object is sent to the IPMPS 207 as part of "IPMP Stream" as a stream of "IP Data".

In step S3, one URL information is selected from one or a plurality of pieces of URL information sent to the IPMPS 207. To do this, the operator may designate the information, or the IPMPS 207 may select the information in accordance with a predetermined order.

In step S4, a verification request signal is transmitted to the server 201 with a corresponding

URL

in one or a plurality of servers connected to the network on the basis of the selected URL information. In this case, a back-channel 1 or back-channel 2 to be described later is used for transmission.

25 In step S5, the client waits for an access permission signal transmitted from the server 201 that has received the verification request signal. When the access permission signal is received, the flow advances to step S6. When no access permission signal is received in a predetermined time, the flow advances to step S7.

In step S6, when the access permission signal is received, an object for which access permission (verification) has been obtained can be accessed. More specifically, by enabling a control signal 212 for controlling an access control point, a corresponding stream the stream of an object for which access is permitted by the access permission signal) from the demultiplexer 206 can be accessed by a scene descriptor 208, audio visual decoder 209, and object descriptor 210.

In step S7, by disabling the control signal 212 for controlling an access control point, access to a correspond~.ng stream the stream of an object for which access permission has not been obtained regardless of the verification request) from the demultiplexer 206 by the scene descriptor 208, audio visual decoder 209, and object descriptor 210 is inhibited.

In step S8, it is confirmed whether URL information added to another object is present. If YES in step S7, the flow returns to step S3; otherwise, the series of processing operations is ended.

26 A scene/graphic processing section 211 performs scene synthesis and graphic processing on the basis of data supplied from the scene descriptor 208, audio visual decoder 209, and object descriptor 210. Only objects for which access permission has been obtained may be synthesized for playback. Alternatively, when an object for which access permission has not been obtained is present, playback may not be performed at all.

The above-described verification processing will be described below in more detail.

An MPEG-4 stream contains "ES_Descriptor" that describes the contents of "Elementary Stream" (ES) as a bit stream in units of objects and "OD_Descriptor" that describes the object itself. When URL information for designating a command and an access destination for remote access is obtained in "ESDescriptor" or "OD_Descriptor", remote access is executed in accordance with a procedure shown in Fig. Fig. 5 is a schematic block diagram for explaining remote access. Referring to Fig. 5, "DAI" is an interface layer between an MPEG-4 bit stream and network, which is called "DMIF Application Interface". Details have been described in the "ISO/IEC 14496-6 DMIF document DMIF Application Interface" and will be omitted herein.

The MPEG-4 bit stream also contains 27 "DecoderConfigDescriptor" representing information of a decoder type corresponding to "Elementary Stream" (ES).

This "DecoderConfigDescriptor" is a structure formed from some data elements. One of the elements is a 1-bit upStream parameter representing the stream type. Details have been described in the "ISO/IEC 14496-1 FCD 8. 3. 4.

DecoderConfigDescriptor" and will be omitted herein.

Expression 1 is an example of "DecoderConfigDescriptor".

[Expression 1: DecoderConfigDescriptor] aligned(8) class DecoderConfigDescriptor bit(8) tag=DecoderConfigDescrTag bit(8) length; bit(8) objectProfileIndication; bit(6) streamType; bit(l) upStream; const bit(l) reserved=l; bit(24) bufferSizeDB; bit(32) maxBitrate; bit(32) avgBitrate; DecoderSpecificInfo decSpecificInfo[]; The stream is identified on the basis of the value of "streamType" as a data element in the class declaration of "DecoderConfigDescriptor" of expression 1.

The value of "streamType" is defined as in Table 1.

28 Table 1 Stream Type Designation Value Stream Type Designation Stream Type Value Ox 00 reserved for ISO use 0x01 ObjectDescriptorStream 0x02 ClockReferenceStream 0x03 SceneDescriptionStream Ox04 VisualStream 0x05 AudioStream Ox06 MPEG7Stream 0x07-0x09 reserved for ISO use OxOA ObjectContentInfoStream OxOB IPMPStream Ox0C-0xlF reserved for ISO use 0x20-0x3F user private In Table 1, a value for identifying "IPMP Stream" unique to this embodiment is added to the "ISO/IEC 14496-1 FCD Table 0-1: streamType Values". Parameters or terms in Table 1 are the same as in the "ISO/IEC 14496-1 FCD", and a detailed description thereof will be omitted.

As described above, in Table 1, the value for identifying "IPMP Stream" unique to this embodiment is added. This "IPMP Stream" is originally contained in a source code for the multiplexer 201 for generating the MPEG-4 bit stream.

In this source code for the multiplexer 201, "IPMP 29 Stream" is defined by expression 2 ()below.

[Expression 2: Mux source] objectDescriptorID 0 es-descriptor esNumber 1 fileName Inline.od streamType BIFS t0 streamPriority decConfigDescr streamType 2//OD Stream bufferSizeDB 200 alConfigDescr useAccessUnitstartFlag

TRUE

useAccessUnitEndFlag

TRUE

useRandomAccessPointFlag TRUE userimeStampsFlag

TRUE

timeStarnpResolution 1000 timeStarnpLength 14 es-Number 2 streamType BIE'S 30 streamPriority fileName Inline.bif decConfigDescr streamType 4//BIFS Stream bufferSizeDB 1000 alConfigDescrI useAccessUnitStartrlag

TRUE

useAccessUnitEnd'lag

TRUE

useRandornAccessPointFlag

TRUE

useTimeStampsFlag

TRUE

timeStampResolution 100 timeStampLength 14 OCRESId 1 objectDescriptorlD 33 es-descriptor esNumber 1 fileName, t2 streamType G723 streamPriority 4 31 decConfigDescr streamType 6//AudioStream profileAndLevellndication~xcl//G7 23 bufferSizeDB 300 alConfigDescr timeStampResolution 1000 compositionUnitRate extensionDescriptor TPMPDescriptorPointer IPMPDescriptor_ID 69 es Number 2 fileName ti streamType H263 decConfigDescr streamType 8//IPMPStream() bufferSizeDB 1600 alConfigDescr useAccessUnitStartFlag TRUE useAccessUnitEndFlag TRUE useRandomAccessPointFlag TRUE useTimeStampsFlag TRUE 32 timeStampResolution 1000 timeStampLength PDUseqNumrLength 3 AUseqNumrLength 8 OCRESId 2113 objectDescriptorID 32 es-descriptor 1 fileName ti streamType H263 decConfigDescr streamType 5 //VisualSt ream profileAndLevellndicationOxC2/ /H263 bufferSizeDB 1600 alConfigDescrI useAccessUriitStartFlag

TRUE

useAccessUnitEndFlag

TRUE

useRandomAccessPointFlag

TRUE

useTimeStampsFlag

TRUE

timeStampResolution 1000 33 timeStampLength PDU_seqNumLength 3 AU_seqNumLength 8 OCR ES Id 2113 In expression 2, when "objectDescriptorID" is "33", "IPMP Stream" is defined. This means that a portion representing the stream of an object protected by "IPMP Stream" is contained in "objectDescriptorID 33".

The stream type of "IPMP Stream" is defined as "streamType8". This meaning is the same as that of "OxOb" defined as the stream type designation value of "IPMP Stream" in Table 1.

In this embodiment, the multiplexer 201 collects such source codes and adds "IPMP Stream" to the stream of a plurality of objects, thereby generating an MPEG-4 bit stream coded into one stream.

When the stream is identified by the above-described "DecoderConfigDescriptor", not only "IPMP Stream" but also the streams of objects can be separated from one stream.

As shown in Fig. 4, when "DecoderConfigDescriptor.

upStream" as a flag representing the direction of a stream is set at the system is set in the 34 "upstream" state to transmit a stream from the client side to the server side. In this case, a transmission function using the state of the "upstream" state will be referred to as back-channel 1".

In normal playback, "DecoderConfigDescriptor.

upStream" is at so a "downstream" state in which a stream is transmitted from the server side to the client side is set. When permission for access to an object is wanted, "DecoderConfigDescriptor. upStream" is set at and so-called "back-channel 1" for "upstreaming" necessary data to the URL destination is used to send "IPMP Management Data" (copyright management information) to the server side as "IPMP Stream", so response data is transmitted from the URL destination by remote access.

"IPMP Stream" shown in Table 1 has "IPMP ES" and "IPMPD". Each "IPMP_ES" is formed from a series of "IPMP_Messages". Expression 3 is an example of description of "IPMP_Messages".

[Expression 3: IPMP_Message] class IPMP_Message unsigned int(8) IPMPS_TypeCount; bit(1) hasURL; int i; for (i 0; i IPMPS_TypeCount; unsigned int(16) IPMPType[[i]]; 35 unsigned int(32) offset[[i]]; unsigned int(16) length[[i]]; if (hasURL){ unsigned int(5) lengthOfURLbits; bit(3) reserved=0blll; unsigned int(lengthOfURLbits) lengthOfURL; char(8) URLString[lengthOfURL]; for (i 0; i IPMPS TypeCount; char(8) IPMPdata[length[i]]; In expression 3, "IPMPS TypeCount" represents the number of different "IPMP types". Since different IPMPSs can exist, "IPMP_Messages" can correspond to a plurality of IPMPSs.

When a URL is designated, "IPMPSTypeCount" has a value Otherwise, "IPMPS_TypeCount" has as a minimum value. In this case, "IPMPMessage" stored in an external device is referred to and used in place of internal "IPMPMessage".

"IPMPSD" is formed from "IPMP Descriptor". This "IPMP Descriptor" is a data structure for performing specific IPMP control for each "elementary streams".

"IPMP Descriptor Updates" is executed as part of an 36 object descriptor stream. Expression 4 is an example of description of "IPMP Descriptor Updates".

[Expression 4: IPMP_DescriptorUpdate] aligned(8) class IPMPDescriptorUpdate: unit(8) IPMP_DescriptorUpdateTag unsigned int(8) descriptorCount; int i; for (i 0; i descriptorCount; IPMP_Descriptor In expression 4, "descriptorCount" represents the number of "IPMP_Descriptors" to be updated, and d[i] represents a certain "IPMP_Descriptor".

Expression 5 is an example of description of "IPMPDescriptor".

[Expression 5: IPMP_Descriptor] class IPMP Descriptor bit(8) IPMP_Descriptor_ID; unsigned int(8) IPMPS_TypeCount; bit(l) hasURL; int i; for (i 0; i IPMPS_TypeCount; unsigned int(16) IPMPS_Type[[i]]; unsigned int(32) offset[[i]]; unsigned int(16) length[[i]]; 37 if (hasURL) unsigned int(5) lengthOfURLbits; bit(3) reserved=0blll; unsigned int(lengthOfURLbits) lengthOfURL; char(8) URLString[lengthOfURL]; for (i 0; i IPMPS_TypeCount; char(8) IPMP_data[length[i]]; In expression 5, "IPMP Descriptor_ID" is a number unique to each "IPMP_Descriptor". "ES_Descriptors" refer to "IPMP_Descriptors" using the "IPMP_Descriptor

ID".

"IPMPSTypeCount" represents the number of different IPMPSs designated by "IPMP_message".

Fig. 6 is a view showing an example of a hierarchical structure when a URL destination further has a URL designation. Fig. 6 shows a two-layer structure. If still another URL designation is present, a three- or four-layer structure may be formed.

Referring to Fig. 6, although "IPMPStream" is not clearly illustrated, "IPMPES" or "IPMP D" associated with an object to be remote-designated is decoded and remote-accessed in correspondence with "SceneDescriptionStream" or "ObjectDescriptionStream", 38 as needed, as in the above-described Fig. Verification processing using the "upstream" state of the MPEG-4 bit stream, using the back-channel 1 has been described above. This verification processing using the "back-channel 1" is "upstream" processing in real-time bit stream playback and therefore assumes high-speed processing with a relatively small data amount and short processing time. In a real-type playback system, delay due to remote access and verification using the "back-channel 1" is preferably as small as possible.

However, even when the data amount is small, verification may require a considerable time. This poses a problem of delay in the "back-channel From the viewpoint of the allowable delay time and necessity of interactive operability, a second "back-channel" is preferably prepared.

For this purpose, in this embodiment, an I/O (interdevice Input/Output) interface different from that for transmitting the MPEG-4 bit stream is used. This will be called a "back-channel 2".

Before a description of verification processing using the "back-channel the relationship between the data amount and delay time in the "back-channel 1" and "back-channel 2" will be considered. In the report of "MPEG-4 Requirement Group", the allowable delay time of 39 "back-channel 1" that does not impede real-time playback is 1 frame time. On the basis of this, the relationships between the assumed data amount and bit rate in the "back-channel 1" and "back-channel 2" are shown in Table 2.

Table 2 Delay Times and Data Amounts of back-channels 1 and 2 Notation Use Purpose Data Amount Delay Time back-channel 1 high-speed 3000 5000 100 300 ms IPMP remote bits/s access for verification back-channel 2 low-speed 500 ms

IPMP

input/output access for verification In high-speed IPMP remote access for verification, the delay time is limited in processing a data amount within 100 to 500 bits/frame through a transmission line with a bit rate of 3K to 5K/sec. The relationship between "IPMP_Message" data or "IPMP_Description" data and delay-bandwidth as a result of "remote content access" by "back-channel" can be regarded as Table 2, so the data amount for actual verification is limited.

Verification often requires time asynchronously with stream processing.

Verification of a plurality of objects may be 40 executed not in one site but in a plurality of sites. In this case, the conditions in Table 2 become stricter and are not suitable for practical use. Hence, for a verification procedure which allows low-speed processing asynchronously with stream processing, the "back-channel 2" is preferably used.

Processing using the "back-channel 2" will be described below. The "back-channel 2" for low-speed IPMP input/output access for verification is used as an I/O (interdevice Input/Output) interface different from that for transmitting the MPEG-4 bit stream, as shown in Fig. 4.

A computer terminal 214 having a keyboard, display, and modem is prepared next to the "back-channel 2" and connected to the telephone line and IPMPS 207. In this arrangement, the computer terminal 214 receives an object in a stream, which requires verification, and information of the verification destination from the IPMPS 207 and displays the information on the display.

The operator selects an object in the stream, which requires verification, by referring to the display. The computer terminal 214 calls the verification destination, receives the verification method or access code from the verification destination, and displays the contents on the display. When the operator inputs the received information using the keyboard, the IPMPS 207 is 41 notified of the input information and enables access to the necessary object.

Use of a telephone line has been exemplified above.

Instead, a cable of CATV or radio communication channel may be used.

Alternatively, a PC card storing information necessary for access verification, which has been acquired by a contract with the verification destination in advance, is inserted into the PCMCIA interface in the computer terminal 214 to notify the IPMPS 207 of information necessary for verification and enable access to the object, as needed.

For verification processing for which the operation time or verification time becomes relatively long, this method is effective for processing other than real-time processing, at the time of starting stream playback or scene change.

As described above, according to the first embodiment, the "back-channel 1" or "back-channel 2" can be selected and used in accordance with the application purpose. This selection may be performed by the operator, or the optimum back-channel may be selected in the system in consideration of the delay time limit or the like.

When two different "back-channels" are prepared, flexible verification processing can be realized.

42 (Second Embodiment) As described above, in the first embodiment, an IPMP Stream containing URL information is added to the streams of a plurality of objects, and these streams are coded into one stream to generate an MPEG-4 bit stream.

In addition, a stream containing IPMP Stream is identified from this MPEG bit stream, and a "back-channel" is used when the MPEG-4 player transmits the verification request signal to a server having a corresponding URL in one or a plurality of servers connected on the network. In the second embodiment, another method of using the "back-channel" will be described.

Fig. 8 is a block diagram showing the schematic arrangement of an MPEG-4 player having the arrangement shown in Figs. 2 and 3, to which a copyright protection system (IPMP System 86) and object data processing flow control section (IPMP Stream Flow Control 83) are added.

Fig. 8 shows the contents of stream control at the "access control point" in Fig. 4 in more detail.

Referring to Fig. 8, an MPEG-4 bit stream containing coded image object data requiring copyright protection is divided into object data by a Demux Layer 81 and converted/synchronized to the time in the player by a Sync Layer 82 in accordance with time stamp information added in coding or bit stream generation.

43 On the other hand, the IPMP System 86 performs verification processing for object data requiring copyright protection, which are separated into individual data, on the basis of copyright protection information separated by the Demux Layer 81 and transmits a permission signal to the IPMP Stream Flow Control 83 to perform object data processing flow control. In a Compression Layer 84, each object data is decoded by a decoder in units of object data. In a Composition Layer 85, a scene is synthesized in accordance with the decoded scene description, and displayed.

Especially, there are some object data processing flow control methods. In this embodiment, the problem to be solved will be described by exemplifying Test Conditions #1 and #2.

Table 3 shows four test plans as examples of the relationship between-the IPMP System (IPMPS) and Stream Flow Control.

44 Table 3 IPMP Test Plan In Table 3, test 1 shows a case wherein no IPMP systems are present; test 2, a case wherein only the IPMPS1 is present; test 3, a case wherein only IPMPS2 is present; and test 4, a case wherein both the IPMPS1 and SIPMPS2 are present.

Input/output signals in the respective tests and the difference in role between the IPMPS1 and IPMPS2 will be described next.

In Table 3, Unprotected Text Object Stream is expressed by Protected Audio Stream is expressed by and Protected Video Stream is expressed by "S2(Cv) Sl(Ca) IPMP System is expressed by "IPMPS1", and 45 the XOR result (logical exclusive OR) between original coded data and ASCII code is expressed by "Sl(Ca)".

hence, the interpretation key is ASCII code and the output is the "XOR" between the original coded data and "x" S2(Cv) IPMP System is expressed by "IPMPS2", and the XOR result between original coded data and ASCII code is expressed by hence, the interpretation key is ASCII code and the output is the "XOR" between the original coded data and "Graceful Error" means an error on the output side of the decoder, which occurs when the protected object stream cannot be normally interpreted by the key.

"Graceful Error" that may occur in, a Protected Video Stream is error such as "no display" or "display of distorted image". In only test 4, no "Graceful Error" occurs.

Table 4 shows the conditions and parameters of IPMP Verification test.

Table 4 IPMP Verification Test Condition and Parameters Condition Test 1 Test 2 Test 3 Test 4 46

C

0 n t e n t

S

I

P

M

p

C

0 n d ir t i 0 1 Si (Ca) S2 (Cv) Unprotected Text Protected Audio Protected Video 4-I _T IPMP-ES and IPMP-D yes yes f yes yes 4. i I_ __I IP Identification Data Set yes yes yes -t 1 IPMP-S1 IPMP-52 none none XOR for S I (Ca) none none XOR for S2 (Cv) XOR for Si (Ca) XOR for 52 Cv)1 4 1 1 none Embedded "key" constant delay #2 none User -4interaction non-fixed delay Synchronization yes ye yes yes Expected result aX;pass pass ct;pass a;pass Sl(Ca) ;error Si (Ca) ;pass Si.(Ca) ;error Sl(Ca) ;pass S2 (Cv) ;error I 2 (Cv) ;error S2(Cv) ;pass 52 (Cv) ;pass In Table 4, when test 2 is to be executed, under 47 Test Condition a normal key for each object stream is present in the IPMP system (IPMPS1 and IPMPS2) in advance so that an incoming object stream is immediately (or with a predetermined delay time) "interpreted" and output to each decoder.

When test 2 is to be executed, under Test Condition a normal key for each object stream is not present in the IPMP system (IPMPS1 and IPMPS2) in advance. The normal key is input from external keys or by a user interactive method such as smart card insertion, and an incoming object stream is "interpreted" and output to each decoder. For this reason, the delay time is not constant.

Fig. 9 shows the internal functional block diagram and data flow of an MPEG-4 player.

Fig. 9 shows a simple arrangement of an actual system for a description of a synchronization mechanism, and the IPMP system and object data processing flow are not illustrated.

First, an entry function Execute() of the MPEG-4 System Player started from an application starts functional modules, ensures a data area buffer, allocates the memory to each functional function, and prepares for data processing.

MPEG-4 bit streams input by a FlexDemux 91 as a Service module function of the DMIF layer, packet 48 data or data files from the network are received as a series of data groups and transferred to an ALManager 92.

In the ALManager 92, object data such as video data, audio data, and scene description information are separated from the data group. The scene description information or object-associated information data are transferred to a BIFS Decoder 93, and video and audio data are transferred to a Decoder 94 as data channels.

In accordance with the scene description information decoded by the BIFS Decoder 93 and Decoder 94 and time stamp information added in bit stream generation, a Presenter 95 or Media Stream data processing section (not shown) adjusts the time relationship between the decoded Media Object data (Video and Audio data), synchronizes them, and synthesizes a scene.

Fig. 10 simply shows the above series of data processing processes.

Referring to Fig. 10, the FlexDemux 91 receives an MPEG-4 bit stream and separates it into elementary streams (ES) in units of object data. The ALManager 92 divides the ES of each object data in units of decoding units. The BIFS Decoder 93 and Decoder 94 decode each object data. A data group Media Stream of the decoded object data is generated. The Presenter 95 executes time adjustment between the individual object data using the 49- "MediaStreamImp::Fetch()" function for processing Media Stream data, synthesizes the object data into one scene, and displays the scene.

Fig. 11 is a flow chart showing a data processing example of time adjustment. Time adjustment processing by the Presenter 95 will be described in detail with reference to Fig. 11.

In step S1101, an allowance value is added to the current time of the System Player (-+dwCurrentTime). On the basis of this value, the stamp time (TimeStamp) of data to be processed (AU) is converted into the System Player time in step S1102 (-4dwTime). In step S1104, the current time (dwCurrentTime) is compared with the stamp time (dwTime) of the data to be processed When the stamp time (dwTime) of the data to be processed (AU) is later than the current time (dwCurrentTime), the flow advances to step S1106 to synthesize an actual scene. If the stamp time (dwTime) of the data to be processed

(AU)

is earlier than the current time (dwCurrentTime), it is determined that the data is unsuitable for scene synthesis (it is determined that the data is not in good time for scene synthesis), and the flow advances to step S1105 to process the next data processing block (AU).

Fig. 12 is a timing chart showing time adjustment processing shown in Fig. 11 in time series.

Referring to Fig. 12, an Object stream (AUO) 50 arrives at a Decoding Buffer 1201 of the BIFS Decoder. 93 or Decoder 94 at time Arrival (AUO), is decoded, and sent to a Composition Memory 1202 of the Presenter 95 at stamp time DTS (AUO) added upon encoding. A scene is synthesized from scene synthesis time CTS (CUO). The next Object stream (AU1) is also transferred from the Decoding Buffer 1201 to the Composition Memory 1202 at time DTS (AU1), and a scene is synthesized from time CTS (CU1).

As is apparent from Fig. 12, in Fig. 11, the time DTS in the Decoding Buffer 1201 is adjusted to the actual scene synthesis time CTS in the Composition Memory 1202, that is later than the actual current time dwCurrentTime.

In Fig. 13, processing in the IPMP system is added to the processing flow shown in Fig. 10. More specifically, the following processing is performed.

The process in which the FlexDemux 91 receives an MPEG-4 bit stream and separates it into elementary streams (ES) in units of object data, and the ALManager 92 divides the ES of each object data in units of decoding units is the same as in Fig. 10. Next, a protected stream is specified from the object data divided by the ALManager 92, especially on the basis of IPMP-associated information, and IPMP System processing such as normal key input and verification is performed.

51 The BIFS Decoder 93 and Decoder 94 decode the Media Stream as a data group to be decoded in units of object data. The Presenter 95 adjusts time of each object, synthesizes a scene, and displays it.

Object data processing flow control under Test Conditions #1 and #2 in executing test 2 shown in Table 4 will be described below. First, under Test Condition the key interpretation time is transmitted to the decoder as a predetermined delay in units of IPMP Systems. For this reason, when the entire delay is set to be within the range where it can be absorbed by the Compression Layer 84 in Fig. 8 or Presenter 95 in Fig. 9, no problem of synchronization occurs.

Under Test Condition the following processing is performed.

Fig. 14 is a flow chart for explaining processing of the IPMP system in executing test 2 under Test Condition #2.

In step S1401, the stream of each object divided by the ALManager 92 is obtained. In step S1402, it is determined whether valid key input is present. If NO in step S1402, the flow advances to step S1403 to HOLD processing without interpreting the protected stream. If YES in step S1402, the flow advances to step .S1404 to interpret the protected stream. Then, the flow advances to the next processing.

52 When flow control shown in Fig. 14 is performed in executing test 2 under Test Condition streams until the normal key input are suspended. On the other hand, non-protected streams or streams which have already been verified and interpreted by normal key input are transferred to the subsequent time synchronization processing for decoder processing and scene synthesis.

The elapse time until the previous suspended streams are verified and interpreted by normal key input and transferred to the next processing is not constant because of the user interactive operation for each protected stream. In addition, at the processing resumption time, the dwTime may already pass the dwCurrentTime.

In this case, as is apparent from Figs. 11 and 12, the streams for which processing has been resumed are not decoded until the dwTime after resumption becomes later than the dwCurrentTime. Processing skips to the next data to be processed (AU) the data is thinned). Skipped portions are not synthesized into a scene.

As described above, under Test Condition the data is partially thinned, so continuous contents cannot be obtained from the first time.

In "push"-type data distribution such as pay TV, one-directional data distribution is basically performed 53 in accordance with the time zone, and data is received by an image reception system with verification function, a set top box. Since this system can be sufficiently coped with by Test Condition no problem is posed.

However, for example, assume that a viewer sees a commercial demonstration contents group of the first several minutes of, a movie and selects one content. If he/she will acquire and enjoy the video data after charging and verification, this case cannot be coped with by Text Condition Under Test Condition #2, since playback is resumed after selection/verification, the viewer cannot obtain some contents, that have already been broadcasted.

The MPEG-4 allows selection/playback in units of video objects. For this reason, in the above commercial demonstration contents, even when verification processing is not performed, some objects such as persons or background can be kept played back as protected streams and graceful error. In this case as well, since playback is resumed after selection/verification under Test Condition the viewer cannot obtain normal and full contents that have already been broadcasted.

When the viewer will enjoy full contents from the beginning, he/she must instruct the server on the 54 contents distribution side to resend the video data from the beginning.

As a general solution, the client (user) side requests the server (contents distribution) side to resend the full contents at the time of resuming video playback after selection/verification. Normally, to issue this request, the server side need provide an application to the client side in advance to receive the request from the client side.

However, when a scene is to be synthesized by obtaining a plurality of video object contents or audio object contents from different URL destinations (Uniform Resource Locator), as in the MPEG-4, applications and verification/resending methods for the plurality of contents distribution servers are necessary. This makes program management complex and is not practical.

In the second embodiment, such a signal for instructing to resend video data from the beginning is transmitted to the server as the contents distribution source using the back-channel" ("back-channel 1" or "back-channel 2" described in the first embodiment, together with URL information of the request destination server and information representing the verification result.

More specifically, in the second embodiment, from the player side which receives an MPEG-4 bit stream and 55 plays back a scene (downstream processing) in normal use, information is distributed to the server side using the back-channel function of the MPEG-4 verification/resending information is upstream-processed using Upchannel information as shown in Fig. In this method, each contents distribution source server and IPMP System Interface share sections associated with verification/resending information communication, so the cumbersomeness of program management can be decreased.

As described above, according to the second embodiment, since copyright work resending request can be easily transmitted through the network after verification processing, video data to be played back can be prevented from being omitted due to the delay time associated with verification processing.

In the second embodiment, the verification processing method is not particularly specified. More specifically, as in the first embodiment,.a verification request signal is sent to each contents distribution server through the network to receive access permission from the contents distribution server. Alternatively, a valid key is stored in the MPEG-4 player in advance, and the viewer locally makes verification.

The present invention may be applied to a system constituted by a plurality of devices or an apparatus comprising a single device.

56 In addition, an apparatus or method comprising some of all constituent elements of the apparatus or method of the above embodiments also constitutes the invention intended by the present inventor of this application.

The function of the apparatus according to the above embodiments is realized even by permanently or temporarily incorporating a storage medium storing program codes in a system or apparatus and causing the computer (or a CPU or an MPU) of the system or apparatus to read out and execute the program codes stored in the storage medium. In this case, the program codes read out from the storage medium or the storage medium constitutes the invention by itself.

As a storage medium for supplying the program codes, a floppy disk, a hard disk, an optical disk, a magnetooptical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, or the like can be used, though another device may be used.

Not only a case wherein the functions unique to the present invention are realized by executing the program codes read out from the storage medium by the :computer but also embodiments in which an OS (Operating System) running on the computer performs part or all of actual processing on the basis of the instructions of the program codes also belongs to the technical range of the present invention.

57 Embodiments in which after the program codes read out from the storage medium are written in the memory of a function expansion board inserted into the computer or a function expansion unit connected to the computer, the CPU of the function expansion board or function expansion unit performs part or all of actual processing on the basis of the instructions of the program codes also belongs to the technical range of the present invention.

As has been described above, according to the present invention, a plurality of object streams and a stream associated with copyright information are transmitted as one stream, and the stream associated with copyright information is separated and extracted on the reception side. With this arrangement, verification processing can be efficiency executed to effectively protect copyrights and effectively use copyright works.

In addition, according to the present invention, verification processing can be efficiently executed to effectively protect copyrights and effectively use copyright works.

Furthermore, according to the present invention, after verification processing, a copyright resending request is transmitted through the network. With this arrangement, omission of a played back image due to the delay time associated with verification processing can be prevented, and therefore, many verification 58 processing methods become possible.

As many apparently widely different embodiments of the present invention can be made without departing from the spirit and scope thereof, it is to be understood that the invention is not limited to the specific embodiments thereof except as defined in the appended claims.

59

Claims (8)

1. 2. The method according to claim 1, wherein each of said plurality of coded object data is image data.
2. 3. The method according to claim 2, wherein each of said plurality of coded object data comprises one moving image scene.
3. 4. The method according to claim 3, wherein each of said plurality of coded object data is bit stream data conforming to an MPEG4 coding scheme.
4. 5. The method according to claim 4, wherein said transmitting step uses an upstream of an MPEG4 bit stream.
5. 6. A computer readable medium on which is stored a computer program that, when executed, enables a computer apparatus to perform an information processing method according to claim 1.
6. 7. A computer program product stored on a computer readable medium which, when executed, enables a computer apparatus to perform an information processing method according to claim 1. 60 [R \.IBCC]05083 docgmm
7. 8. The method according to claim 1, wherein said controlling step controls the O decoding process of each of said plurality of coded object data to decode any object data CN for which access permission has been verified.
8. 9. The computer program product according to claim 7, wherein said controlling ostep controls the decoding process of each of said plurality of coded object data to decode any object data for which access permission has been verified. 00 00 DATED this fifth Day of June, 2006 C 0 Canon Kabushiki Kaisha Patent Attorneys for the Applicant SPRUSON FERGUSON -61 SR:\LIBCC]05083 doc gmm