Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
  • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
  • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
  • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
  • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
  • H04N21/64784—Data processing by the network
  • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/845—Structuring of content, e.g. decomposing content into time segments
  • H04N21/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/85—Assembly of content; Generation of multimedia applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/85—Assembly of content; Generation of multimedia applications
  • H04N21/854—Content authoring
  • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N7/00—Television systems
  • H04N7/24—Systems for the transmission of television signals using pulse code modulation

Definitions

• Patent Application Serial No. 61/354,422 entitled “Extension to the Extractor data structure of SVC/MVC file formats,” and filed on June 14, 2010, and U.S. Provisional Patent Application Serial No. 61/354,424, entitled “Some extensions for ISO Base Media File Format for HTTP streaming,” and filed on June 14, 2010.
• the teachings of the above- identified provisional patent applications are expressly incorporated herein by reference.
• the present invention relates generally to HTTP streaming. More specifically, the invention relates to encapsulating a media entity for coded multi-component video streams such as scalable video coding (SVC) steams and multi-view coding (MVC) streams for HTTP streaming.
• SVC scalable video coding
• MVC multi-view coding
• an encoded video is often encapsulated and stored at the server side as a file that is compliant with BMFF, such as an MP4 file.
• the file is usually divided into multiple movie fragments and these fragments are further grouped into segments, which are addressable by client URL requests.
• different encoded representations of the video content are stored in these segments, so that a client can dynamically choose the desired representation to download and playback during a session.
• Encoded layered video such as an SVC or MVC bitstream, provides natural support for such bitrate adaptation by enabling different operating points, i.e., representations, in terms of temporal / spatial resolutions, quality, views, etc., by decoding different subsets of the bitstream.
• BMFF ISO Base Media File Format
• MP4 file format the metadata for all the layers or representations for one media file are stored in the moov Movie Box, while the media content data for all the layers or representations are stored in the mdat Movie Box.
• HTTP streaming when the client requests one layer, the whole file has to be sent since all the layers or representations are mixed together and the client does not know where to find the required layer or representation.
• Extractor is an internal file data structure defined in the SVC / MVC Amendments to the AVC file format extension of BMFF: Information Technology - coding of audio-visual objects - Part 15: Advanced Video Coding (AVC) file format, Amendment 2: File format support for Scalable Video Coding, 2008, pages 15-17. Extractor is designed to enable extraction of NAL units from other tracks by reference, without copying.
• track is a timed sequence of related samples in an ISO base media file. For media data, a track corresponds to a sequence of images or sampled audio.
• the syntax of Extractor is shown below: class aligned(8) Extractor () ⁇
• NALUnitHeader The NAL unit structure as specified in ISO/IEC 14496-10 Annex G for NAL units of type 20:
• nal_unit_type shall be set to the extractor NAL unit type (type 31).
• forbidden_zero_bit, reserved_one_bit, and reserved_three_2bits shall be set as specified in ISO/IEC 14496-10 Annex G.
• Video Coding (AVC) file format Amendment 2: File format support for Scalable Video Coding, ISO/IEC 14496-15 : 2004/ Amd.2: 2008, page 17.
• AVC Video Coding
• track_ref_index specifies the index of the track reference of type 'seal' to use to find the track from which to extract data.
• the sample in that track from which data is extracted is temporally aligned or nearest preceding in the media decoding timeline, i.e. using the time- to-sample table only, adjusted by an offset specified by sample_offset with the sample containing the Extractor.
• the first track reference has the index value 1; the value 0 is reserved.
• sample_offset gives the relative index of the sample in the linked track that shall be used as the source of information.
• Sample 0 zero is the sample with the same, or the closest preceding, decoding time compared to the decoding time of the sample containing the extractor; sample 1 (one) is the next sample, sample -1 (minus 1) is the previous sample, and so on.
• data_offset The offset of the first byte within the reference sample to copy. If the extraction starts with the first byte of data in that sample, the offset takes the value 0. The offset shall reference the beginning of a NAL unit length field.
• data_length The number of bytes to copy. If this field takes the value 0, then the entire single referenced NAL unit is copied (i.e. the length to copy is taken from the length field referenced by the data offset, augmented by the additional_bytes field in the case of Aggregators). Further details can be found in Information technology - Coding of audio-visual objects - part 15: Advanced Video Coding (AVC) file format, Amendment 2: File format support for Scalable Video Coding, ISO/IEC 14496-15 :2004/Amd.2:2008.
• AVC Advanced Video Coding
• a client If a client has already downloaded one or more content component of a piece of media content from the server, and is in the process to download another content component, the client needs to know whether the previously downloaded content components are among the set of the dependent components of the new one, so that it can make other requests as necessary to download the complete component set.
• This use case also requires a mechanism to signal an external dependent content component and its location information.
• BMFF BMFF
• tref ' a box type used to provide a reference from the containing track to another track in the presentation. This box can be used to describe the dependencies among tracks, however, the dependency is limited to tracks within the same media file.
• One approach is to signal such information using some out-of-band mechanism.
• the server can send a manifest file to the client before a session starts.
• the manifest file is a file that contains dependency and location information of each content component of a requested media content. Then the client is able to request all the necessary component files.
• this out-of-band approach is not applicable for local file playback, where no manifest file is available.
• This invention directs to methods and apparatuses for encapsulating component files from a media entity containing more than one layer and for reading a component file.
• a method for encapsulating and creating component files from a media entity containing more than one layer extracts metadata and media data corresponding to the extracted metadata for each layer from the media entity.
• the extracted media data and metadata are associated to enable the creation, for each layer, of a component file containing the extracted metadata and the extracted media data.
• the file encapsulator includes an extractor for extracting metadata and media data corresponding to the extracted metadata for each layer from the media entity; and a correlator for associating the extracted media data with the extracted metadata to enable creation, for each layer, of a component file.
• Figure 1 shows an example MP4 file format.
• Figure 2 shows one embodiment of the current invention to encapsulate a media entity.
• Figure 3 shows the structure of an Encapsulator used to encapsulate or create component files from a media entity which contain multiple layers/representations
• Figure 4 shows an example of associating additional media data with component files based on dependency relationship.
• Figure 5 shows an example to extract an NAL unit, by reference, from a movie box/fragment that is different from the one that the extractor is within.
• Figure 6 shows the involved encapsulation operations for an SVC / MVC type video bitsteam into multiple component files using one of the invented new extractor data structures.
• Figure 7 shows the structure of a file reader used to read the component files.
• Figure 8 shows the process of reading an encapsulated component file for a video decoder involving one embodiment of the present invention.
• Figure 9 shows the encapsulation operations for an SVC / MVC type video bitstream into multiple movie fragments using another preferred new extractor data structures.
• Figure 10 shows the process of reading an encapsulated component file for a video decoder involving another embodiment of the present invention.
• a media entity such as a media file or a set of media files or a streaming media
• a component file is used in a broader sense that it represents a fragment, a segment, a file and other equivalent terms thereto.
• a media entity containing multiple representations or components is parsed to extract metadata and media data for each representation/component.
• the representation/component includes layers, such as layers with various temporal/spatial resolutions and quality in SVC, and views in MVC. In the following, layers are also used to refer to representations/components, and these terms are used interchangeably.
• the metadata describes, for example, what is contained in the media entity for each representation and how to use the media data contained therein.
• the media data contain media data samples required for serving the purpose of the media data, e.g. decoding of the content, or any necessary information on how to obtain the required data samples.
• the extracted metadata and media data for each representation or layer are associated/correlated and stored together for user access.
• a media entity contains three layers: base layer, enhancement layer 1 and enhancement layer 2.
• the media entity is parsed to extract the metadata and media data for each of the three layers, and those data are stored separately as component files with the metadata and corresponding media data associated together.
• Fig. 3 shows the structure of a preferred encapsulator 300 used to encapsulate and create component files from a media entity which contain multiple layers, such as SVC encoded videos.
• the inputs media entity 310 is passed to a metadata extractor 320 and a media data extractor 340.
• the metadata extractor 320 extracts the metadata 330 for each layer.
• the media data extractor 340 takes in the metadata 330 and extracts the corresponding media data 350.
• the metadata extractor 320 and the media data extractor 340 are implemented as one extractor. Both data, metadata 330 and media data 350, are feed into a correlator 380 which associates these two types of data and creates the output component files 390, one component file for each layer.
• a layered video such as a video encoded by AVC extensions of SVC or MVC, contains multiple media components (scalable layers or views).
• Such an encoded bitstream can provide different operating points, i.e., representations or layers, in terms of temporal / spatial resolutions, quality, views, etc., by decoding different subsets of the bitstream.
• there exist coding dependencies among the layers of the bitstream i.e., the decoding of a layer may depend on other layers. Therefore, to request one of such a bitstream' s representations may require retrieving and decoding one or more components or media data from the encapsulated video file.
• an encoded layered video is often encapsulated into an MP4 file in a way that each layer is stored separately in different segments or component files.
• certain media data samples, such as NAL units, of the bitstream are required by, or related to, multiple segments or component files, due to the decoding dependencies described above or other dependencies based on the application.
• FIG. 4 shows an example of this embodiment.
• an SVC bitstream has three spatial layers, HD1080p, SD and QVGA.
• Three movie fragments or component files are formed corresponding to the three operating points, and each is addressable by a different URL.
• all the media data samples, NAL units in this example, required for decoding are copied and stored as media samples contained in the "mdat" box. So, when a client requests a particular operating point or representation by using a proper URL, the server can retrieve the corresponding movie fragment or component file and forwarded to the client.
• the media data extractor 340 in Fig. 3 further extracts, for each layer, from the input media entity 310 additional media data related to the extracted media data for each of the layers.
• Correlator 380 further associates the additional extracted media data for each layer to create corresponding component files.
• BMFF Base Media File Format
• a reference is identified and built for those additional media data that are related to or required by the media data of a movie fragment or a component file.
• the reference rather than those additional media data, is associated with the component file along with the metadata and media data thereof.
• a Reference Identifier 360 is added to the structure of the Encapsulator 300.
• the Reference Identifier 360 identifies, from input media entity 310, references 370 to those additional media data that are related to extracted media data 350 for each layer.
• references 370 are associated, via correlator 380, with extracted metadata 330 and extracted media data 350 for each layer, e.g. by embedding said references into said extracted media data 350, for creating corresponding component files 390.
• the extension is added to provide the extractor data structure with the extra capability to reference to NAL units that reside in a different movie box/fragment or component file other than the one in which extractor resides.
• the extended Extractor is defined as the following:
• DataEntryBox (entry version, entry J ags) data_entry; //added extension unsigned int(8) track_ref_index;
• data_entry is a Uniform Resource Locator (URL) or Uniform Resource Name (URN) entry.
• Name is a URN, and is required in a URN entry.
• Location is a URL, and is required in a URL entry and optional in a URN entry, where it gives a location to find the resource with the given name.
• Each is a null-terminated string using UTF-8 characters. If the self- contained flag is set, the URL form is used and no string is present; the box terminated with the entry-flags field.
• the URL type should be of a service that delivers a file. Relative URLs are permissible and are relative to the file containing the Movie Box/Fragment that contains the track that the Extractor belongs to.
• FIG. 6 shows the involved encapsulation operations for an SVC / MVC type video bitsteam into multiple movie fragments or component files using the invented new extractor data structure.
• the process starts at step 601. Each NAL unit is read in one by one in step 610. If the end of the bitstream is reached in step 620, the process stops at 690; otherwise, the process proceeds to the next step 630. Decision step 630 determines if the current NAL unit depends on NAL units from other track for decoding. If the determination is that the current NAL unit does not depend on NAL units from other tracks for decoding, the control is then transferred to step 640, wherein a sample is formed using the current NAL unit and is placed in the current track.
• step 650 determines if the track from which NAL units are required by the current NAL unit resides within the same movie fragment. If the determination is that the track resides in the same movie fragment, step 670 is employed to fill in an extended Extractor to reference to the NAL unit from that other track. If the determination is that the track resides in a different movie fragment, the URL or URN of such a movie fragment is identified in step 660 and the process proceeds to step 670 with the identified URL and URN to be filled in an extended Extractor. After such an extended Extractor is filled in, it is embedded into the current track in step 680. Then, the process starts over with the next NAL unit in step 610.
• references 370 are embedded into extracted metadata 330 and indices to reference 370 are added to extracted media data 350 via correlator 380, which further associates the metadata and the media data for each layer for creating corresponding component files 390.
• a box called HTTP Streaming Information Box is disclosed. This box contains the information that can assist the HTTP streaming of the ISO file. It is preferred that the HTTP Streaming Information Box be placed as early as possible in the component files, e.g. at the beginning of the files. The box can also serve as a source by the server when forming a manifest file for the client.
• Another type of box called Media Reference Box which is contained in the HTTP Streaming Information Box is also disclosed. This box contains the information about the external dependent files. The extractor structure is further extended so that it can reference media samples across different component files. The information contained in Media Reference Box can be utilized by extractors to save signaling overhead.
• the HTTP Streaming Information Box aids the HTTP streaming operation of an ISO media file. It contains relevant information about HTTP streaming delivery of the file, including Media Reference Box as defined below, among other possible types of boxes.
• the HTTP Streaming Information Box is preferably placed as early as possible in files, for maximum utility.
• Media Reference Box is contained in HTTP Streaming Information Box, and it contains a table of the data references in the form of URL that declare the locations of the external files that each track included in the box is dependent on. By reading this box, the file reader is able to identify the external dependent file sources, such as external component files, of a track in the file, as well as means to retrieve them.
• entry _count is an integer that counts the actual entries
• track_ID is an integer that uniquely identifies the track in the file upon which the box is applied;
• dependent_source_count is an integer that counts the external media sources that the track in the file with track_ID that is dependent on; data_entry: is a URL entry that points to one external media source the designated track is dependent on. Each is a null-terminated string using UTF-8 characters.
• the URL type should be of a service that delivers a file. Relative URLs are permissible and are relative to the file that contains this media reference box.
• Media Reference Box is designed to facilitate, in a number of ways, HTTP streaming of a media entity containing more than one layer.
• the in-file information from the box can be easily extracted to be included in a manifest file.
• Such information in the manifest can help the client, before actual HTTP streaming, discover relevant service information and perform the corresponding service initialization, such as requesting all the associated component files, allocating necessary buffer resources, etc.
• the client when the client requests a different representation of some multi-component media content, which has another representation already been delivered as a component file, the client can check the corresponding Media Reference Box in the file to see if the file contains any of the dependent components of the new representation that can be reused.
• the box helps reduce the signaling overhead of the extended Extractor structure as defined below.
• Extractor is further proposed to extend its capability of referencing data from tracks of external media files.
• media_reference_index specifies an index of the entry to the reference table contained in the Media Reference Box that has the same associated track_ID value as the track that contains the extractor. If media_reference_index equals to 0, the extractor references to the data from another track but within the same file as the extractor. In this case, there shall not be a reference table in Media Reference Box that has the same track_ID value as the track. If media_reference_index is between 1 and the value of dependent_source_count from the reference table associated with the track from the Media Reference Box, the URL referenced by media_reference_index from the reference table points to an external file, which contains a track from which the extractor extracts data.
• extractors it is now possible to use extractors to link to and extract data from a track that belongs to an external component file. It is especially useful when content components from an encoded piece of multi-component media content, such as encoded by SVC or MVC, are encapsulated into different component files. With the extended extractors, extraction can take place across file boundaries. This avoids duplicating the same data in different component files.
• Figure 9 shows the involved encapsulation operations for an SVC / MVC type video bitsteam into multiple movie fragments or component files using the disclosed HTTP Streaming Information Box and Media Reference Box as well as the further extended extractor data structure.
• This process is similar to the process shown in Fig. 6 with a few modifications due to the above described boxes, and the further extension of the extractor.
• location information URL/URN is indentified in step 660
• the location information is used to fill in the reference table in the mref box (Media Reference Box) in step 965.
• Step 970 further fills in an Extractor with the indices to the location information of the reference table.
• the extractor is then embedded into the current track.
• mref box and its container hsin box (HTTP Streaming Information Box) are embedded into the metadata of the component file.
• a file reader 700 shown in Fig. 7 is employed.
• a parser 710 first parses the component file to get metadata and media data, and a reference if available. If, according to the decoded reference, the media data are related to media data of other component files such as through decoding dependency, a retriever 720 retrieves the related media data from other component files as indicated in the reference.
• a processor 730 further processes the metadata and media data obtained from the component file as well as the additional media data if available.
• the parsing operation by the parser 710 includes various necessary operations to obtain the metadata, the media data that are ready for the processor 730, and the reference ready for the retriever 720. It will include further parsing the metadata and/or the media data when necessary.
• the reference is embedded in the media data, and thus the reference is obtained by parsing the media data. If a reference is available, the parsing step further includes analyzing the syntax of the reference and decoding the reference.
• the processor 730 can contain a video decoder if the component file contains video content. In a different embodiment, the parser and the retriever can be incorporated in the processor.
• FIG. 8 shows the process of reading an SVC / MVC type video bitstream for a video decoder involving the present invention.
• Step 801 accesses a component video file whose metadata and media data for each layer are identified in step 805.
• the identified metadata and media data are parsed in step 810 and each NAL unit of the media data is read in one by one in step 815.
• a decision is first made at step 820 to determine if the end of the bitstream is reached, and the process ends at step 825 if the answer is "Yes". Otherwise, the process proceeds to decision step 830 to determine if the current NAL unit is an extractor.
• the NAL unit is sent to decoder at step 835. If the current NAL unit is an extractor, it is determined at step 840 that whether the current NAL unit depends on a NAL unit outside the same component file or not. If the required NAL unit is within the same component file, it is retrieved from the current file in step 845 and sent to the decoder at step 835. If the required NAL unit is from another component file, the NAL unit is located using the reference information Data_entry in the extractor in step 850, retrieved from the remote file in step 855 and then sent to the decoder in step 835.
• the reference is identified in the parser 710 by parsing the media data to get the embedded reference indices, and to obtain corresponding reference according to the reference indices.
• the corresponding process of reading an SVC / MVC type video bitstream for a video decoder is shown in Fig. 10, which is similar to the process of Fig. 8.
• the parsing of the metadata in step 810 enables the analysis of the reference contained therein in parallel with the parsing of the media data.
• other component files that are referenced to are identified in step 1014. Retrieving of those other component files are started in step 1012 in parallel with the remaining steps of the process.
• step 850 After accessing the location information of the component file that the current NAL unit depends on in step 850, local storage, such as media buffer, is checked for availability of such a component file. If the required component file is available locally, then the NAL unit of the local copy is retrieved; otherwise, the NAL unit from remote file is retrieved. Note that the local copy of the component file can be obtained by the parallel retrieving in step 1012, or it can be obtained from a previous request of such component file.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computer Security & Cryptography (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Compression Or Coding Systems Of Tv Signals (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=44454826

Family Applications (1)

Country Status (6)

Families Citing this family (11)

Family Cites Families (8)

• 2011
  • 2011-06-13 CN CN2011800293844A patent/CN103098484A/zh active Pending
  • 2011-06-13 WO PCT/US2011/040168 patent/WO2011159605A1/en active Application Filing
  • 2011-06-13 BR BR112012031874A patent/BR112012031874A2/pt not_active IP Right Cessation
  • 2011-06-13 JP JP2013515413A patent/JP2013532441A/ja active Pending
  • 2011-06-13 EP EP11727605.5A patent/EP2580920A1/de not_active Withdrawn
  • 2011-06-13 KR KR1020127032653A patent/KR20130088035A/ko not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events