Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over HAMZA et al (20250173947) in view of BAI et al (CN 112700550).
As per claim 1, Hamza teaches the clamed “method for parsing a scene description document,” comprising: “obtaining the scene description document of a three-dimensional scene to be rendered, wherein the three-dimensional scene to be rendered comprises a target media file with type of G-PCC encoded point cloud” (Hamza, [0198] - With this approach, multiple objects which are coded using MPEG codec technologies can be referred to as an object item. To attach an MPEG_OBJECTS item to node, a node-level extension is introduced to refer to an object defined in the top-level MPEG_OBJECTS.objects array. Using such a mechanism is flexible to support other kind of MPEG coded content such as G-PCC. As described in the paragraph, any content coded using MPEG technologies can be referred as an object item in the MPEG_OBJECTS.objects array. A content may be coded using any MPEG technologies such as V-PCC, G-PCC or others); “obtaining a target media description module corresponding to the target media file from a media list of Moving Picture Expert Group (MPEG) media of the scene description document” (Hamza, [0079] - An Exploration Experiment (EE) has been initiated to support MPEG immersive codecs in MPEG scene description. The EE is to architect design principles and workflows for immersive media coded content using MPEG technologies, such as video-based point cloud compression (V-PCC), geometry-based point cloud compression (G-PCC), and MPEG immersive media (MIV)). It is noted that Hamza’s scene description suggests the claimed “obtaining description information of the target media file according to the target media description module” (Hamza, [0077] - MPEG has generally incorporated glTF as a scene graph format and extended glTF to support dynamic (timed) content such as 2D and 360-degree videos, dynamic volumetric visual media, and audio; [0086] - There are two main entities in the MPEG-I scene description architecture 200: the media access function (MAF) 210 and the presentation engine (PE) 250. The foundational consideration for the reference architecture 200 is to decouple the functionality of the MAF 210 from the rendering and presentation of PE 250. MAF 210 is responsible for requesting, fetching, decoding, and post-processing the media data required by the PE 250 to render the various media objects that are part of the scene. MAF 210 is expected to present the media data in appropriate buffer formats in accordance with the scene description document 270 such that they are readable by PE 250. The scene description document 270 is loaded by PE 250 and scene description document 270 identifies from the relevant buffers for each media object in the scene and their formats) (see also Bai, page 9 - In the embodiment of the invention, based on ISO (International Organization for Standardization, International Organization for Standardization) basic media file format the space position information of the 3D point cloud, the block division information is stored in the media file. The basic media file format can refer to MPEG-4 Part 12 ISO Base Media, which is made by the ISO/IEC JTC1/SC29/WG11Moving Picture Experts Group (MPEG). File Format operates, wherein the point cloud compressed data format can refer to ISO/IEC JTC1/SC29/WG11 Moving Picture Experts Group (MPEG) made MPEG-I Part 9: G-PCC based on geometric coding point cloud compression technology to operate; pages 12-13 - Embodiment 1 - In this embodiment, the main description is based on static spatial area division of the 3 D point cloud part access, and point cloud space area information in the description of the media file for supporting G-PCC point cloud compressed data based on space area part access, point cloud data corresponding to each space area supports independently decoding and rendering… the number of the space area is described by the point cloud space area information data box (GPCCSpatialRegionInfoBox); and the identifier and coordinate of each space area… step S804, the file analyzer traversing each point cloud block track sample inlet information respectively reading the space area identifier corresponding to each block track, space area coordinate information; the space area comprises a block identifier; determining the point cloud blocking track tile track1 of region1; step S805, the file analyzer obtains the point cloud block track tile track 1 comprises part of point cloud data, input to the decoder to finish decoding; step S806, the terminal rendering part point cloud data). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by using the target media description module to obtain description information of the target media file. The motivation is to improve the point cloud data decoding and transmission efficiency.
Claim 2 adds into claim 1 “wherein obtaining description information of the target media file according to the target media description module comprises at least one of the following: obtaining a name of the target media file according to a value of a media name syntax element in the target media description module; determining whether the target media file needs to be auto played based on a value of an autoplay syntax element in the target media description module; determining whether the target media file needs to be played in a loop based on a value of a loop syntax element in the target media description module; obtaining an encapsulation format of the target media file based on a value of a media type syntax element in alternatives of the target media description module; obtaining an access address of the target media file based on a value of a unique address identifier syntax element in alternatives of the target media description module; obtaining track information of the target media file according to a value of a first track index syntax element in a tracks array of alternatives of the target media description module; and determining a type and decoding parameters of a bitstream of the target media file according to values of the codecs syntax element in the tracks array of the alternatives of the target media description module and G-PCC data transport standard” (Hamza, [0171] - Another exemplary approach includes an array of atlases. Another approach to describe the support for multiple atlases is to define a new property under ‘MPEG_V3C’ extension named ‘atlases’. ‘atlases’ is an array of components corresponding to an atlas as shown in Table 13. The length of atlases array may be equal to number of atlases for a V3C object. The properties for an object in the atlases array describe the atlas data component and corresponding video-coded components such as attribute, occupancy, and geometry for a V3C object; [0089]-[0092] - In FIG. 3A, a pipeline #1 310.1 is illustrated. Pipeline #1 310.1 includes a single track 330 that supplies a demuxer 332… In FIG. 3, a pipeline #2a 310.2a is illustrated. Pipeline #2a 310.2a includes a geometry track 362, a texture track 364, an occupancy track 366, an atlas track 368, and a static metadata 370. These tracks are in place of the single track 330 that supplies a demuxer 332… Moreover, the processing steps may perform all the operations to represent the data in the well-defined buffer formats. A scene description document must therefore provide the information related to the buffers).
Claim 3 adds into claim 2 “wherein obtaining the track information of the target media file according to the value of the first track index syntax element in the tracks array of alternatives of the target media description module comprises: determining that the track information is single track based on that the value of the first track index syntax element is an index value of a bitstream track of the target media file; and determining that the track information is multi-track based on that the value of the first track index syntax element is an index value of a geometric bitstream track of the target media file” (Hamza, [0089]-[0092] - In FIG. 3A, a pipeline #1 310.1 is illustrated. Pipeline #1 310.1 includes a single track 330 that supplies a demuxer 332… In FIG. 3, a pipeline #2a 310.2a is illustrated. Pipeline #2a 310.2a includes a geometry track 362, a texture track 364, an occupancy track 366, an atlas track 368, and a static metadata 370. These tracks are in place of the single track 330 that supplies a demuxer 332… Moreover, the processing steps may perform all the operations to represent the data in the well-defined buffer formats. A scene description document must therefore provide the information related to the buffers).
Claim 4 adds into claim 1 “obtaining a target scene description module corresponding to the three-dimensional scene to be rendered from a scene list of the scene description module” (Bai, page 13, Embodiment 3 - In this embodiment, G-PCC point cloud compressed data comprises a plurality of space area, the partition of the spatial area is dynamically changed with time, block number and space position information of the block list (Tile Inventory) can be dynamically changed with time. Therefore, the whole division information of the point cloud space area is described by the sample in the point cloud space area metadata track; each sample in the metadata track describes the number of the space area of the time, and the identifier of each space area, coordinate, partition identifier and so on information. The cloud space area metadata track description space area division comprises the following three scenes: 1) the space area number or position information changes with time; the block list information does not change with time; 2) the space area number or position information is fixed; the block list information changes dynamically with time; 3) the space area number or position information changes dynamically with time; the block list information also changes dynamically with time); and “obtaining description information of the three-dimensional scene to be rendered based on the target scene description module” (Bai, page 14 - step S1105, the file analyzer traversing each point cloud block track sample entrance information respectively reading the space area identifier corresponding to each block track; determining the point cloud blocking track tile track2 of the region2; step S1106, the file analyzer obtains the point cloud block track tile track 2 in the current time sample contained in the point cloud data, input to the decoder to finish decoding; step S1107, terminal rendering the current time part point cloud data). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by using a scene list of the scene description module to obtain a target scene description module corresponding to the rendered three-dimensional scene. The motivation is to improve the point cloud data decoding and transmission efficiency.
Claim 5 adds into claim 4 “wherein obtaining the description information of the three- dimensional scene to be rendered based on the target scene description module comprises: determining an index value of a node description module corresponding to each node in the three- dimensional scene to be rendered according to an index value stated by a node index list of the target scene description module” (Bai, page 11 - region_id, representing the point cloud compressed data corresponding to the spatial area identifier included in the point cloud block track. when the space area is changeless, region_id represents space area identifier in point cloud space area information data box (GPCCSpatialRegionInfoBox); when the space area dynamically changes with time; region_id represents a spatial area index in the space area information metadata track sample). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by determining an index value of a node description module corresponding to each node in the rendered three-dimensional scene. The motivation is to improve the point cloud data decoding and transmission efficiency.
Claim 6 adds into claim 5 “obtaining the node description module corresponding to each node of the three-dimensional scene to be rendered from a node list of the scene description document according to an index value of the node description module corresponding to each node of the three-dimensional scene to be rendered” (Bai, page 10 - As shown in FIG. 6, in this embodiment, point cloud block basic track (G-PCC tile base track) as the point cloud data access point, comprising all common information needed by point cloud data decoding, comprising a sequence parameter set (SPS), geometric parameter set(GPS); attribute parameter set (APS), block list (Tile Inventory) and so on. Point cloud block basic track through type is the track reference information of the "gpct” quoting a plurality of point cloud block track (G-PCC tile track), a plurality of point cloud block track form the complete point cloud compressed data. The following description of the present embodiment of the 3 D point cloud block basic track point cloud block basic track is defined as follows: point cloud block basic track sample entrance type is gpeb 'gpcb' for storing point cloud parameter set, block list and other data unit. The data unit may be stored in the sample inlet or sample. When the point cloud block basic track reference point cloud block track comprises point cloud all element type (geometric data and all type attribute data), sample entrance type of the basic track is “gpeb”; when the point cloud block basic track reference point cloud block track comprises a single point cloud element type, that is, each block track only comprises geometric data or some attribute data; the sample entrance type of the basic track is "gpcb.” when the point cloud space area information does not change with time, point cloud block basic track sample inlet can contain point cloud space area information; when the point cloud space area information changes dynamically with time, the point cloud block basic track needs to reference space area timing metadata track);and “obtaining description information of each node of the three-dimensional scene to be rendered according to the node description module corresponding to each node of the three-dimensional scene to be rendered” (Bai, page 13 - step S804, the file analyzer traversing each point cloud block track sample inlet information respectively reading the space area identifier corresponding to each block track, space area coordinate information; the space area comprises a block identifier; determining the point cloud blocking track tile track1 of region1; step S805, the file analyzer obtains the point cloud block track tile track 1 comprises part of point cloud data, input to the decoder to finish decoding; step S806, the terminal rendering part point cloud data). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by obtaining the node description module corresponding to each node of the three-dimensional scene to be rendered from a node list of the scene description document. The motivation is to improve the point cloud data decoding and transmission efficiency.
Claim 7 adds into claim 6 “obtaining a name of each node in the three-dimensional scene to be rendered according to a value of a node name syntax element in the node description module corresponding to each node in the three- dimensional scene to be rendered” (Bai, page 13 - step S902, the file analyzer reads point cloud block basic track sample inlet in the point cloud configuration information and parameter information, comprising SPS, APS, GPS; Tile Inventory and so on; reading the space area information data box in the sample inlet; reading the space area number is 5; reading respectively position information of each space area and the block identifier corresponding to the space area; step S903, the terminal according to the user requirement and space region position information to calculate, determining one or more spatial regions to be decoded, such as region1; step S904, the file analyzer through region1 corresponding to the point cloud block track identifier determining point cloud block track, namely tile track1; step S905, the file analyzer obtains the point cloud block track tile track 1 comprises part of point cloud data, input to the decoder to finish decoding); and “determining an index value of a mesh description module corresponding to a three-dimensional mesh mounted on each node of the three-dimensional scene to be rendered according to an index value stated in a mesh index list of the node description module corresponding to each node in the three-dimensional scene to be rendered” (Bai, page 13 - step S906, the final rendering part point cloud data; Hamza, [0160] - The V3C syntax may be a mesh-level extension. As per the gITF specification, the accessors referred by the attributes in mesh.primitives store specified attribute data for vertices of the mesh. The accessors to each attribute in a mesh.primitive may store per-vertex data and therefore having the same value for the count property for each attribute’s accessors; Hamza, [0169] - One approach includes outer-inner array for each V3C component. To describe the support for multiple atlases, each property in the MPEG_V3C extension provides an outer array. The outer array length may be equal to number of atlases for a V3C object. The components with maps such as geometry, occupancy and attribute further refer to an array i.e., inner array with each array item referring to a specific map. The properties in the inner array correspond to component-specific data reference e.g., for video-coded data, the index of the corresponding video texture is referred. Similarly for atlas data in V3C_ATLAS, different accessors refer to their respective buffer which store the respective atlas data for an atlas item in the array. Each item in the outer array with index i of a component may have the corresponding component for the same atlas in other properties at index i. The index i may be the atlas ID. For example, an item with index i in V3C_ATLAS may correspond to the atlas data for an atlas at index i. The corresponding video-coded component for the same atlas such as attribute, is referred by the item at index i in V3C_ATTRIBUTE property. Additional to explicitly mentioned, the atlasID for each atlas in the MPEG_V3C extension, an additional property named ‘atlasID’ is introduced. atlasID is an array of integer values. Each integer value refers to the vpc_atlas_id as shown above for each atlas in a V3C bitstream). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by determining an index value of a mesh description module corresponding to a three-dimensional mesh mounted on each node of the three-dimensional scene. The motivation is to improve the point cloud data decoding and transmission efficiency.
Claim 8 adds into claim 7 “wherein after determining an index value of a mesh description module corresponding to a three-dimensional mesh mounted on each node of the three- dimensional scene to be rendered, the method further comprises: obtaining the mesh description module corresponding to the three-dimensional mesh mounted on each node in the three-dimensional scene to be rendered from a mesh list of the scene description document according to the index value of the mesh description module corresponding to the three- dimensional mesh mounted on each node in the three-dimensional scene to be rendered; and obtaining description information of the three-dimensional mesh mounted on each node in the three-dimensional scene to be rendered according to the mesh description module corresponding to the three-dimensional mesh mounted on each node in the three-dimensional scene to be rendered” (Hamza, [0160] - As per the glTF specification, the accessors referred by the attributes in mesh.primitives store specified attribute data for vertices of the mesh. The accessors to each attribute in a mesh.primitive may store per-vertex data and therefore having the same value for the count property for each attribute's accessors. For example, in the following pseudo glTF example, a triangle mesh is described having POSITION, and NORMAL attributes. Each attribute points to an accessor. The accessors provide the information on how to read the data for attributes. To describe a triangle, three vertices are needed. The accessor at index 1 stores POSITION data for the three vertices. The accessor at index 2 stores NORMAL data for the three vertices. The count property for both the accessor at index 1 and index 2 is same).
Claim 9 adds into claim 8 “wherein obtaining description information of the three- dimensional mesh mounted on each node in the three-dimensional scene to be rendered according to the mesh description module corresponding to the three-dimensional mesh mounted on each node in the three-dimensional scene to be rendered comprises at least one of following: obtaining a name of the three-dimensional mesh according to a mesh name syntax element in the mesh description module corresponding to the three-dimensional mesh; obtaining data types included in the three-dimensional mesh according to a data type syntax element in the mesh description module corresponding to the three-dimensional mesh; obtaining an index value of an accessor description module corresponding to an accessor for accessing the data types of data of the three-dimensional mesh according to the value of the data type syntax element; and obtaining a type of a topology of the three-dimensional mesh according to a value of a mode syntax element in the mesh description module corresponding to the three-dimensional mesh” (Hamza, [0171] - Another exemplary approach includes an array of atlases. Another approach to describe the support for multiple atlases is to define a new property under ‘MPEG_V3C’ extension named ‘atlases’. ‘atlases’ is an array of components corresponding to an atlas as shown in Table 13. The length of atlases array may be equal to number of atlases for a V3C object. The properties for an object in the atlases array describe the atlas data component and corresponding video-coded components such as attribute, occupancy, and geometry for a V3C object).
Claim 10 adds into claim 9 “wherein after obtaining the index value of the accessor description module corresponding to the accessor for accessing data with the data type of the three- dimensional mesh according to the value of the data type syntax element, the method further comprises: obtaining, from an accessor list of the scene description document, the accessor description module corresponding to the accessor for accessing the data types of data of the three-dimensional mesh according to the index of the accessor description module corresponding to the accessor for accessing the data type of the three-dimensional mesh; and obtaining, according to the accessor description module corresponding to the accessor for accessing the data types of data of the three-dimensional mesh, description information of the accessor for accessing the data types of data of the three-dimensional mesh” (Hamza, TABLE 17 Accessors for V3C atlas properties - Different embodiment of semantics for V3C_atlas are also contemplated. These semantics correspond to the syntax defined herein. V3C atlas information can be provided with lesser number of accessor units. Valid accessor type and component type for each property of a V3C atlas frame are defined in Table 17; [0161] - glTF specification allows to define new attribute types to store application-specific data for a mesh. However, such new attributes may obey the data representation rules of glTF, i.e. the accessors for application-specific attribute must define per-vertex data and each attribute's accessor must have the same count value. To represent a V3C as a mesh in glTF, the syntax elements used to describe V3C may not break the core data representation concepts of glTF meshes. For example, defining a mesh.primitive.attribute which does not store per-vertex data for the all the vertices of the mesh, such a glTF file should be considered invalid).
Claim 11 adds into claim 1 “obtaining each buffer description module in a buffer list of the scene description document; obtaining a value of a media index syntax element of each buffer description module; determining a buffer description module whose value of the media index syntax element is the same as the index value of the target media description module as the target buffer description module corresponding to the target buffer for buffering decoded data of the target media file; and obtaining description information of the target buffer according to the target buffer description module” (Hamza, [0169] - One approach includes outer-inner array for each V3C component. To describe the support for multiple atlases, each property in the MPEG_V3C extension provides an outer array. The outer array length may be equal to number of atlases for a V3C object. The components with maps such as geometry, occupancy and attribute further refer to an array i.e., inner array with each array item referring to a specific map. The properties in the inner array correspond to component-specific data reference e.g., for video-coded data, the index of the corresponding video texture is referred. Similarly for atlas data in V3C_ATLAS, different accessors refer to their respective buffer which store the respective atlas data for an atlas item in the array. Each item in the outer array with index i of a component may have the corresponding component for the same atlas in other properties at index i. The index i may be the atlas ID. For example, an item with index i in V3C_ATLAS may correspond to the atlas data for an atlas at index i. The corresponding video-coded component for the same atlas such as attribute, is referred by the item at index i in V3C_ATTRIBUTE property. Additional to explicitly mentioned, the atlasID for each atlas in the MPEG_V3C extension, an additional property named ‘atlasID’ is introduced. atlasID is an array of integer values. Each integer value refers to the vpc_atlas_id as shown above for each atlas in a V3C bitstream).
Claim 12 adds into claim 11 “wherein obtaining description information of the target buffer according to the target buffer description module comprises at least one of following: obtaining a capacity of the target buffer according to a value of the first byte length syntax element in the target buffer description module; determining whether the target buffer is a circular buffer extended and modified based on MPEG extension according to whether the target buffer description module includes an MPEG circular buffer; obtaining a count of storage links of the MPEG circular buffer according to a value of a link count syntax elements in the MPEG circular buffer of the target buffer description module; and obtaining a track index value of source data of the data buffered by the MPEG circular buffer according to a value of a second track index syntax elements in the MPEG circular buffer of the target buffer description module” (Hamza, [0093] - To support timed-data access, the buffer element in ISO/IEC DIS 12113:2021 is extended to provide the functionality of a circular buffer. The extension is named MPEG_buffer_circular and may be included as part of the “buffers” structures. Buffers that provide access to timed data may include the MPEG_buffer_circular extension; [0096]-[0098] - When present, both buffer views may point into the same circular buffer. Accessors that include the MPEG_accessor_timed extension may only point to buffers that include the MPEG_buffer_circular extension as described herein… The MPEG_texture_video extension includes an accessor property which provides a reference to the accessor, by specifying an index of a particular accessor object in an accessors array which describes the buffer where the decoded timed-texture may be made available. The MPEG_texture_video extension also provides information about the format of the video texture through a format property. The type, componentType, and count properties of the accessor depend on the width, height, and format properties).
Claim 13 adds into claim 11 “obtaining each bufferview description module in a bufferview list of the scene description document; obtaining each value of a buffer index syntax element in each bufferview description module; determining a bufferview description module whose value of the buffer index syntax element is the same as the index value of the target buffer description module as a bufferview description module corresponding to the bufferview of the target buffer; and obtaining description information of the bufferview of the target buffer according to the bufferview description module corresponding to the bufferview of the target buffer” (Hamza, [0095]-[0097] - An accessor as specified in ISO/IEC DIS 12113:2021 defines the types and layout of the data as stored in a buffer that is viewed through a bufferView object. When timed-media is read from a buffer, the data in the buffer may change dynamically with time… The accessor.bufferView field, in an accessor that has the MPEG_accessor_timed extension, as well as the timed-accessor information header fields apply to the data of each frame within the circular buffer).
Claim 14 adds into claim 13 “wherein obtaining description information of the bufferview of the target buffer according to the bufferview description module corresponding to the bufferview of the target buffer comprises: obtaining a capacity of the bufferview of the target buffer according to a value of a second byte length syntax element in the bufferview description module corresponding to the bufferview of the target buffer; and obtaining an offset of the bufferview of the target buffer according to a value of an offset syntax element in the bufferview description module corresponding to the bufferview of the target buffer” (Hamza, [0130]-[0137] - Specific information such as common atlas-level patch information and application atlas-level patch information and other relevant information presented herein can be retrieved by defining different accessors to the buffer. Each accessor points to the same binary buffer with a different bufferView. Each bufferView may have a different binary offset and different binary length to access each sub-block in the buffer data. Each sub-block in the binary block stores a definite length of scalar values… A single buffer may be referenced by a set of bufferViews and each bufferView may have its own glTF accessor element. The use of accessors enables PE 250 to access all the information associated with the patches contained in a decoded atlas frame).
Claim 15 adds into claim 13 “obtaining each accessor description module in an accessor list of the scene description document; obtaining each value of a bufferview index syntax element in each accessor description module; determining the accessor description module with a value of the bufferview index syntax element being the same as an index value of the bufferview description module corresponding to the bufferview of the target buffer as the accessor description module corresponding to an accessor for accessing the data in the bufferview of the target buffer; and obtaining description information of the accessor for accessing data in the bufferview of the target buffer according to the accessor description module corresponding to the accessor for accessing data in the bufferview of the target buffer” (Hamza, [0130] - Each accessor points to the same binary buffer with a different bufferView. Each bufferView may have a different binary offset and different binary length to access each sub-block in the buffer data. Each sub-block in the binary block stores a definite length of scalar values).
Claim 16 adds into claim 10 “determining a type of data accessed by the accessor according to the value of the data type syntax element in the accessor description module; determining a type of the accessor based on a value of an accessor type syntax element in the accessor description module; determining a count of data accessed by the accessor according to a value of a data count syntax element in the accessor description module; determining whether the accessor is a time-varying accessor modified based on an MPEG extension according to whether the accessor description module includes the MPEG time-varying accessor; determining an index value of the buffer view description module corresponding to the buffer view of the data accessed by the target accessor according to a value of a buffer view index syntax element in the MPEG time-varying accessor of the accessor description module; and determining whether a value of the syntax element in the accessor changes over time according to a value of the time-varying syntax element in the MPEG time-varying accessor of the accessor description module” (Hamza, [0142]-[0143] - A plurality of MPEG accessor timers (collectively MPEG accessor timers 820) including MPEG accessor timer 820.1 for accessor 1 810.1, MPEG accessor timer 820.2 for accessor 2 810.2, MPEG accessor timer 820.3 for accessor 3 810.3, MPEG accessor timer 820.4 for accessor 4 810.4. A plurality of buffers (collectively buffers 830) are then fed, including buffer 1 830.1 from MPEG accessor timer 820.1, buffer 2 830.2 from MPEG accessor timer 820.2, buffer 3 830.3 from MPEG accessor timer 820.3, and buffer 4 830.4 from MPEG accessor timer 820.4. Other buffers, such as buffer 835, may be fed directly by the accessors 810, MPEG accessor timers 820, for example).
Claim 17 claims an apparatus based on the method of claim 1; therefore, it is rejected under a similar rationale.
Claim 18 adds into claim 17 “wherein obtaining description information of the target media file according to the target media description module comprises at least one of the following: obtaining a name of the target media file according to a value of a media name syntax element in the target media description module; determining whether the target media file needs to be auto-played based on a value of an autoplay syntax element in the target media description module; determining whether the target media file needs to be played in a loop based on a value of a loop syntax element in the target media description module; obtaining an encapsulation format of the target media file based on a value of a media type syntax element in alternatives of the target media description module; obtaining an access address of the target media file based on a value of a unique address identifier syntax element in alternatives of the target media description module; obtaining track information of the target media file according to a value of a first track index syntax element in a tracks array of alternatives of the target media description module; and determining a type and decoding parameters of a bitstream of the target media file according to values of the codecs syntax element in the tracks array of the alternatives of the target media description module and G-PCC data transport standard” (Hamza, [0171] - Another exemplary approach includes an array of atlases. Another approach to describe the support for multiple atlases is to define a new property under ‘MPEG_V3C’ extension named ‘atlases’. ‘atlases’ is an array of components corresponding to an atlas as shown in Table 13. The length of atlases array may be equal to number of atlases for a V3C object. The properties for an object in the atlases array describe the atlas data component and corresponding video-coded components such as attribute, occupancy, and geometry for a V3C object; [0089]-[0092] - In FIG. 3A, a pipeline #1 310.1 is illustrated. Pipeline #1 310.1 includes a single track 330 that supplies a demuxer 332… In FIG. 3, a pipeline #2a 310.2a is illustrated. Pipeline #2a 310.2a includes a geometry track 362, a texture track 364, an occupancy track 366, an atlas track 368, and a static metadata 370. These tracks are in place of the single track 330 that supplies a demuxer 332… Moreover, the processing steps may perform all the operations to represent the data in the well-defined buffer formats. A scene description document must therefore provide the information related to the buffers).
Claim 19 adds into claim 18 “wherein obtaining the track information of the target media file according to the value of the first track index syntax element in the tracks array of alternatives of the target media description module comprises: determining that the track information is single track based on that the value of the first track index syntax element is an index value of a bitstream track of the target media file; and determining that the track information is multi-track based on that the value of the first track index syntax element is an index value of a geometric bitstream track of the target media file” (Hamza, [0089]-[0092] - In FIG. 3A, a pipeline #1 310.1 is illustrated. Pipeline #1 310.1 includes a single track 330 that supplies a demuxer 332… In FIG. 3, a pipeline #2a 310.2a is illustrated. Pipeline #2a 310.2a includes a geometry track 362, a texture track 364, an occupancy track 366, an atlas track 368, and a static metadata 370. These tracks are in place of the single track 330 that supplies a demuxer 332… Moreover, the processing steps may perform all the operations to represent the data in the well-defined buffer formats. A scene description document must therefore provide the information related to the buffers).
As per claim 20, Hamza teaches the claimed “method for generating scene description document,” comprising: “determining a type of a media file in a three-dimensional scene to be rendered; based on that a type of a target media file in the three-dimensional scene to be rendered is a Geometry-based Point Cloud Compression (G-PCC) encoded point cloud, generating a target media description module corresponding to the target media file based on description information of the target media file” (Hamza, [0198] - With this approach, multiple objects which are coded using MPEG codec technologies can be referred to as an object item. To attach an MPEG_OBJECTS item to node, a node-level extension is introduced to refer to an object defined in the top-level MPEG_OBJECTS.objects array. Using such a mechanism is flexible to support other kind of MPEG coded content such as G-PCC. As described in the paragraph, any content coded using MPEG technologies can be referred as an object item in the MPEG_OBJECTS.objects array. A content may be coded using any MPEG technologies such as V-PCC, G-PCC or others); and “adding the target media description module into a media list of MPEG media of the scene description document in the three-dimensional scene to be rendered” (Hamza, [0079] - An Exploration Experiment (EE) has been initiated to support MPEG immersive codecs in MPEG scene description. The EE is to architect design principles and workflows for immersive media coded content using MPEG technologies, such as video-based point cloud compression (V-PCC), geometry-based point cloud compression (G-PCC), and MPEG immersive media (MIV)); “wherein generating the target media description module corresponding to the target media file based on the description information of the target media file comprises: generating the target media description module by adding a first track index syntax element to a tracks array of alternatives of the target media description module; based on that the target media file is a single track encapsulation file, setting the value of the first track index syntax element to an index value of a bitstream track of the target media file; based on that the target media file is a multi-track encapsulation file, setting the value of the first track index syntax element to an index value of a geometric bitstream track of the target media file” (Hamza, [0089]-[0090] - Pipeline #1 310.1 includes a single track 330 that supplies a demuxer 332. Pipeline #1 310.1 then includes a series of HEVC decoders 334 and metadata 336. Pipeline #1 310.1 continues with a series of processing 338 that feeds 3D reconstruction 340. Pipeline #1 310.1 then is buffered 350 and provides signal to PE 250. In FIG. 3, a pipeline #2a 310.2a is illustrated. Pipeline #2a 310.2a includes a geometry track 362, a texture track 364, an occupancy track 366, an atlas track 368, and a static metadata 370. These tracks are in place of the single track 330 that supplies a demuxer 332 in pipeline #1 310.1). It is noted that Hamza’s scene description suggests the claimed “generating the scene description document in the three-dimensional scene to be rendered” (Hamza, [0077] - MPEG has generally incorporated glTF as a scene graph format and extended glTF to support dynamic (timed) content such as 2D and 360-degree videos, dynamic volumetric visual media, and audio; [0086] - There are two main entities in the MPEG-I scene description architecture 200: the media access function (MAF) 210 and the presentation engine (PE) 250. The foundational consideration for the reference architecture 200 is to decouple the functionality of the MAF 210 from the rendering and presentation of PE 250. MAF 210 is responsible for requesting, fetching, decoding, and post-processing the media data required by the PE 250 to render the various media objects that are part of the scene. MAF 210 is expected to present the media data in appropriate buffer formats in accordance with the scene description document 270 such that they are readable by PE 250. The scene description document 270 is loaded by PE 250 and scene description document 270 identifies from the relevant buffers for each media object in the scene and their formats) (see also Bai, page 9 - In the embodiment of the invention, based on ISO (International Organization for Standardization, International Organization for Standardization) basic media file format the space position information of the 3D point cloud, the block division information is stored in the media file. The basic media file format can refer to MPEG-4 Part 12 ISO Base Media, which is made by the ISO/IEC JTC1/SC29/WG11Moving Picture Experts Group (MPEG). File Format operates, wherein the point cloud compressed data format can refer to ISO/IEC JTC1/SC29/WG11 Moving Picture Experts Group (MPEG) made MPEG-I Part 9: G-PCC based on geometric coding point cloud compression technology to operate; pages 12-13 - Embodiment 1 - In this embodiment, the main description is based on static spatial area division of the 3 D point cloud part access, and point cloud space area information in the description of the media file for supporting G-PCC point cloud compressed data based on space area part access, point cloud data corresponding to each space area supports independently decoding and rendering… the number of the space area is described by the point cloud space area information data box (GPCCSpatialRegionInfoBox); and the identifier and coordinate of each space area… step S804, the file analyzer traversing each point cloud block track sample inlet information respectively reading the space area identifier corresponding to each block track, space area coordinate information; the space area comprises a block identifier; determining the point cloud blocking track tile track1 of region1; step S805, the file analyzer obtains the point cloud block track tile track 1 comprises part of point cloud data, input to the decoder to finish decoding; step S806, the terminal rendering part point cloud data). Thus, it would have been obvious, in view of Bai, to configure Hamza’s method as claimed by generating the scene description document in the three-dimensional scene to be rendered. The motivation is to improve the point cloud data decoding and transmission efficiency.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHU K NGUYEN whose telephone number is (571)272-7645. The examiner can normally be reached M-F 8-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel F. Hajnik can be reached at (571) 272-7642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PHU K NGUYEN/Primary Examiner, Art Unit 2616
Prosecution Insights