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 .
DETAILED ACTION
Claim Objections
1. Claims 17-19 are objected to because of the following informalities: Claims 17, 18 and 19 are not falling within one of the four statutory categories of invention. Supreme Court precedent and recent Federal Circuit decisions indicate that a statutory "process" under 35 U.S.C. 101 must (1) be tied to another statutory category (such as a particular apparatus), or (2) transform underlying subject matter (such as an article or material) to a different state or thing. While the instant claim(s) recite a series of steps or acts to be performed, the claim(s) neither transform underlying subject matter nor positively tie to another statutory category that accomplishes the claimed method steps, and therefore do not qualify as a statutory process. Appropriate correction is required. Failure to make appropriate correction(s) would lead to 35 U.S.C. 101 rejection(s).
Claim 1 recites “An audio decoder for providing a decode audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types,“ should be - An audio decoder for providing a decode audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types comprising: - . Appropriate correction(s) required.
Claim 17 recites “An apparatus for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types,“ should be - An apparatus for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types comprising: - . Appropriate correction(s) required.
Claim 18 recites “A method for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types,“ should be - A method for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types comprising: - . Appropriate correction(s) required.
Claim 19 recites “A method for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types,“ should be - A method for providing an encoded audio representation comprising: <new line> a plurality of packets of different packet types; - . Appropriate correction(s) required.
Claim Rejections - 35 USC § 103
2. 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.
3. Claims 1-4, 6-14, 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate et al. (WO 2021/186104 A1) in view of D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format).
As to claim 1, Mate teaches an audio decoder, for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - adaptation of audio content rendering. This may comprise, for example, six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fog. 2 and page 9, lines 16-18 – the EID 200 together with audio data processed by the audio encoder 202 to generate the bitstream 204);
wherein the audio decoder is configured to spatially render one or more audio signals (page 1, lines 13-15 – Bitstream content is data which has been created by encoding the 6DOF audio scene description, the raw audio signals and the MPEG-H encoded/decoded audio signals; page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream; Fig. 1 - auralization);
wherein the audio decoder is configured to receive the plurality of packets of different packet types (page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
the packets comprising one or more scene configuration packets providing a renderer configuration information (page 11, lines 10-16 - the MPEG-H 3D Audio configuration may include 6DOF metadata capable packets which may change at arbitrary positions of the stream);
the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering (Fig. 1, dynamic updates; page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update);
wherein the audio decoder is configured to evaluate whether one or more update conditions are fulfilled and to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if the one or more update conditions are fulfilled (page 5, line 19 – page 6, line 5; page 17, line 7 – page 19, line 25);
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
Mate does not explicitly teach the scene update packets define an update of scene metadata for the rendering and a representation of one or more updates conditions.
D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of D2 into the teachings of Mate and it would have been obvious to update in the same packets for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
As to claim 2, Mate teaches the audio decoder according claim 1, wherein the audio decoder is configured to evaluate a temporal condition, which is included in a scene update packet, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene updated packets (page 17, line 7 – page 19, line 25 – the update message as defined in EIF extended to allow updates via dynamic content in addition to the currently specified updates; the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached); and D2 teaches in (pages 7-9, 2.3 Scene updates – a timed update (L1) is executed by the renderer once at a fixed predefined time; the update is performed when the specified time is reached).
As to claim 3, Mate teaches the audio decoder according claim 2, wherein the temporal condition defines a start time instant or wherein the temporal condition defines a time interval (page 17, lines 7-22 - the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reaches); wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current playout time has reached the start time instant or lies after the start time instant, or wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current playout time lies within the time interval (page 17, lines 7-22 - the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached; page 18 and table; claim 4); and D2 teaches in (pages 7-9, 2.3 Scene updates – a timed update (L1) is executed by the renderer once at a fixed predefined time; the update is performed when the specified time is reached).
As to claim 4, Mate teaches the audio decoder according claim 1, wherein the audio decoder is configured to evaluate a spatial condition (page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream), which is included in a scene update packet, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene update packets (page 17, line 7 – page 19, line 25 – the update message as defined in EIF extended to allow updates via dynamic content in addition to the currently specified updates; the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached).
As to claim 6, D2 teaches the audio decoder according claim 1, wherein the audio decoder is configured to evaluate whether an interactive trigger condition is fulfilled, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene update packets (pages 6-9 – a triggered update (L2) is manually triggered from an external entity using an OSC message; the update is triggered by its ID or index. Different updates types can be mixed to control an entity. Scene creators are advised not to mix different update type for the same attribute of an entity. If an entities’ attribute is statistically animated it may not be updated with triggered updates).
As to claim 7, Mate and D2 do not explicitly teach the audio decoder according claim 1, wherein the audio decoder is configured to evaluate a combination of two or more update conditions and wherein the audio decoder is configured to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if a combined update condition is fulfilled. However, D2 teaches types of updates can be defined in a EIF file: a timed updated, a conditional update, a triggered update, and a dynamic update (page 7); and different updates types can be mixed to control an entity; however scene creators advised not to mix different update type for the same attribute of an entity which may result in an undesired behavior. If an entities’ attribute statically animated it may not be updated with conditional or triggered updates (page 9). It would have been obvious to update scene metadata in dependence on a content of scene updates packets when a combined updated condition is fulfilled in order to effectively mix the updates without undesired behavior result.
As to claim 8, D2 teaches the audio decoder according claim 1, wherein the audio decoder is configured to evaluate both a temporal update condition and a spatial update condition, or wherein the audio decoder is configured to evaluate both a temporal update condition and an interactive update condition (pages 7-9 – a timed update that executed by the renderer once at a fixed predefined time, a triggered update is manually triggered from an external entity and a dynamic update is an update from an external entity that includes the values of the attributes to be updated; the update is performed when the specified time is reaches or the condition changed its state to the logical value expressed, the update is triggered by its ID or index by an external entity; and different updates types can be mixed to control an entity; however scene creators advised not to mix different update type for the same attribute of an entity which may result in an undesired behavior. If an entities’ attribute statically animated it may not be updated with conditional or triggered updates (page 9)).
As to claim 9, Mate teaches the audio decoder according claim 1, wherein the audio decoder is configured to evaluate a delay information which is included in the scene update packet (Fig. 6 – shows MPEG-I audio dynamic scene updates for low delay audio). Mate does not explicitly discuss delay an update of one or more scene metadata in dependence on a content of the one or more scene update packets in accordance with the delay information in response to a detection that the one or more update condition are fulfilled. However, Mate teaches
«Update condition="cond:1istenerNearCar” delay =”0.1”> «Modify id=”engine" transition="continuous” duration-"0.05” active-”true” and
<Update condition~”cond:1istenerNearCar” delay =”0.2”> «Modify id=”radio” transition=”continuous” duration=”0.2” active-”true” (page 19). It would have been obvious to detect that the update condition are fulfilled to delay an update in order to render of such content may be adapted to the MPEG-I audio bitstream content to ensure a harmonious merge without introducing any distortion.
As to claim 10, Mate and D2 do not explicitly discuss the audio decoder according claim 1, wherein the audio decoder is configured to evaluate a flag within the scene update packet indicating whether a temporal update condition is defined in the scene update packet and/or wherein the audio decoder is configured to evaluate a flag within the scene update packet indication whether a spatial update condition is defined in the scene update packet. However, D2 teaches declaring one or more changes to the audio scene and the update is performed when the specified time is reaches, the condition changed its state to the logical value expressed by fireOn parameter determines whether the update firs when the condition changes from false-to-true or from true-to-false – see Modification Flags - (pages 6-9 section 2.3). It would have been obvious to evaluate a flag within the scene update packet indicating whether a temporal update condition is defined in order to have an updates modifies defined in the EIF file and known to the encoder.
As to claim 11, D2 teaches declaring one or more changes to the audio scene and the update is performed when the specified time is reaches, the condition changed its state to the logical value expressed by fireOn parameter determines whether the update firs when the condition changes from false-to-true or from true-to-false – see Modification Flags - (pages 6-9 section 2.3); and
Mate teaches «Update condition="cond:1istenerNearCar” delay =”0.1”> «Modify id=”engine" transition="continuous” duration-"0.05” active-”true” and
<Update condition~”cond:1istenerNearCar” delay =”0.2”> «Modify id=”radio” transition=”continuous” duration=”0.2” active-”true” (page 19). It would have been obvious to incorporate the delay information defined in the scene update packet into the teachings of D2 for the purpose of evaluating a flag that indicating a delay information in the scene update packet in accordance with the delay information in response to a detection that the one or more update conditions are fulfilled.
As to claim 12, Mate teaches the audio decoder according to claim 1 wherein the scene updated packet comprises a representation of a plurality of modifications of one or more parameters of one or more scene objects and/or of one or more scene characteristics (page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates and AR evaluation), wherein the audio decoder is configured to apply the modifications in response to a detection that the one or more update conditions are fulfilled (page 5, line 19 – page 6, line 5; page 17, line 7 – page 19, line 25).
As to claim 13, Mate teaches the audio decoder according to claim 1 wherein the scene updated packet comprises a trajectory information and wherein the audio decoder is configured to update a respective scene metadata, to which the trajectory information is associated, using a parameter variation following a trajectory defined by the trajectory information (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory
Update time=”0.2”>
<Modify id=”engine” position=”? .2 1.7 -1.25" />
<Modify id="tire1” position="? . 2 1.7 0.75" />
<Modify id=”tire2” position=”2 , 2 1.7 -0.95” />
<Update time-”0.4”>
<Modify id="engine” position="2 .4 1.7 -1.20” />
<Modify id="tire1” position="? .4 1.7 0.70" />
<Modify id=”tire2" position=”? .4 1.7 -0.95" />.
As to claim 14, Mate and D2 do not explicitly discuss the audio decoder according to claim 13, wherein the audio decoder is configured to evaluate an information indicating whether a trajectory based update of scene metadata is used, in order to activate or deactivate the trajectory based update of scene metadata. However, Mate teaches timed updates synchronously move three object sources of a vehicle in motion along a trajectory evaluating update time and modify ID engine positions and The following example turns on the sources of a car when the listener gets close.
<Box id="geo:region1" position=”5 0 -5” size="102 10"
<ListenerProximityCondition id=”cond:listenerNearCar" region=”geo:region1”
<!— Turn on the engine sound 100ms after the listener entered the region. Smoothly activate the source within 50ms (page18, line 6 – page 19, line 15). It would have been obvious to evaluate an information indicating whether a trajectory based update of scene metadata is used, in order to activate or deactivate the trajectory based update of scene metadata.
As to claim 16, Mate teaches the audio decoder according to claim 13, wherein the audio decoder is configured to evaluate a supporting point information describing the trajectory (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory, and it would have been obvious to evaluate the supporting point information describing the trajectory in order to update synchronously move along a trajectory effectively.
As to claim 17, Mate teaches an apparatus for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - adaptation of audio content rendering. This may comprise, for example, six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; Fig. 2 and page 9, lines 16-18 – The EID 200 together with the audio data (audio signals, SOFA files, etc.) may be processed by the audio encoder 202 to generate the bitstream 204; page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
wherein the apparatus is configured to provide an information for a spatially rendering one or more audio signals (page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream);
wherein the apparatus is configured to receive the plurality of packets of different packet types (page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
the packets comprising one or more scene configuration packets providing a renderer configuration information (page 11, lines 10-16 - the MPEG-H 3D Audio configuration may include 6DOF metadata capable packets which may change at arbitrary positions of the stream);
the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering (page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update);
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
Mate does not explicitly teach the scene update packets define an update of scene metadata for the rendering and a representation of one or more updates conditions.
D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of D2 into the teachings of Mate and it would have been obvious to update in the same packets for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Claims 18 and 20 are rejected for the same reasons discussed above with respect to claim 1. Furthermore, Mate teaches a non-transitory digital storage medium having stored there on a computer program (page 34, lines 8-11; page 35, lines 29-32; claims 11 and 14).
Claims 19 and 21 are rejected for the same reasons discussed above with respect to claim 17. Furthermore, Mate teaches a non-transitory digital storage medium having stored there on a computer program (page 34, lines 8-11; page 35, lines 29-32; claims 11 and 14).
4. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate and D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format) in view of Sen (2014/0086416).
As to claim 5, Mate and D2 do not explicitly discuss the audio decoder according to claim 4, wherein the spatial condition defines a geometry element and wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current position has reached the geometry element, or in response to a detection that a current position lies within the geometry element.
Sen teaches encoding and decoding process with a scene -based approach, scene-based encoder SE10 produces a description of the SHC that is transmitted (and/or stored) and decoded at the scene-based decoder SD10 to receive the SHC for rendering (e.g., by SH renderer SR10) ([0091]); providing an encoding of spatial audio information into a standardized bit stream and a subsequent decoding that is adaptable and agnostic to the speaker geometry and acoustic conditions at the location of the renderer ([0092]).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Sen into the teachings of Mate and D2 for the purpose of providing the goal of a uniform listening experience regardless of the particular setup that is ultimately used for reproduction.
5. Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate and D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format) in view of Swaminathan et al. (2021/0006922).
As to claim 15, Mate teaches evaluating a supporting point information describing the trajectory (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory, and it would have been obvious to evaluate the supporting point information describing the trajectory in order to update synchronously move along a trajectory effectively. Mate and D2 do not explicitly discuss the audio decoder according to claim 13, wherein the audio decoder is configured to evaluate an interpolation type information included in the scene update packet in order to determine a type of interpolation between two or more support points of the trajectory.
Swaminathan teaches certain individual streams or groups of streams may be enabled for better audio interpolation. The source device 12 may wish to make higher resolution rendering available for a temporary period of time, such as for an advertisement or a teaser for the higher resolution rendering; update duration as an effect of the interpolate attribute; the intermediate updates/interpolation between the update duration are applied as a part of the audio renderer and the different schemes of interpolation can be applied as a personal preference or can be situational ([0130-0136]).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Sen into the teachings of Mate and D2 for the purpose of enabling certain individual streams or groups of streams for better audio interpolation.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-21 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-44 of copending Application No. 18/659947 (reference application) in view of Mate et al. (WO 2021/186104 A1) and D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format). Although the claims at issue are not identical, they are not patentably distinct from each other because all the claimed limitations recited in the present application are broader and transparently found in the copending Application No. 18/659947 with obvious wording variations. . When claims in the pending application are broader than the ones in the patent, the broad claims in the pending application are rejected under obviousness type double patenting over previously patented narrow claims, In re Van Ornum and Stang, 214 USPQ 761. Also, omission of an element and its function in a combination is an obvious expedient if the remaining elements perform the same functions as before. In re KARLSON (CCPA) 136 USPA 184 (1963).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
U.S. Patent Application 18/659,927
U.S. Patent Application 18/659,947
1.An audio decoder, for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types,
1.An audio decoder, for providing a decoded audio representation on the basis of an encoded audio representation,
wherein the audio decoder is configured to spatially render one or more audio signals;
wherein the audio decoder is configured to spatially render one or more audio signals;
wherein the audio decoder is configured to receive the plurality of packets of different packet types,
wherein the audio decoder is configured to receive the plurality of packets of different packet types,
the packets comprising one or more scene configuration packets providing a renderer configuration information,
the packets comprising one or more scene configuration packets providing a renderer configuration information defining a usage of scene objects and/or a usage of scene characteristics,,
the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering and comprise a representation of one or more update conditions;
the packets comprising one or more scene update packets defining an update of scene metadata for the rendering,
the packets comprising one or more scene payload packets comprising definitions of one or more of the scene objects and/or definitions of one or more of the scene characteristic,
wherein the audio decoder is configured to evaluate whether the one or more update conditions are fulfilled and to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if the one or more update conditions are fulfilled;
wherein the audio decoder is configured to select definitions of one or more scene objects and/or definitions of one or more scene characteristics, which are included in the scene payload packets, for the rendering in dependence on the renderer configuration information; and
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
wherein the audio decoder is configured to update one or more scene metadata in dependence on a content of the one or more scene update packets.
17. An apparatus for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types,
wherein the apparatus is configured to provide an information for a spatial rendering of one or more audio signals;
wherein the apparatus is configured to provide the plurality of packets of different packet types,
the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering an comprises a representation of one or more update conditions;
wherein a content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
18. An apparatus for providing an encoded audio representation,
wherein the apparatus is configured to provide an information for a spatial rendering of one or more audio signals;
wherein the apparatus is configured to provide the plurality of packets of different packet types,
the packets comprising one or more scene configuration packets providing a renderer configuration information defining a usage of scene objects and/or a usage of scene characteristics,
the packets comprising one or more scene update packets defining a update of scene metadata for the rendering,
the packets comprising one or more scene payload packets comprising definitions of one or more of the scene objects and/or definitions of one or more of the scene characteristics.
18. A method for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream, the bitstream comprising a plurality of packets of different packet types,
wherein the method comprises spatially rendering one or more audio signals;
wherein the method comprises receiving the plurality of packets of different packet types;
the packets comprising one or more scene configuration packets providing a renderer configuration information,
the packets comprising one or more scene update packets, wherein the scene update packets defining an update of scene metadata for the rendering and comprises a representation of one or more update conditions;
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
41. A method for providing a decoded audio representation on the basis of an encoded audio representation,
wherein the method comprises spatially rendering one or more audio signals;
wherein the method comprises receiving the plurality of packets of different packet types;
the packets comprising one or more scene configuration packets providing a renderer configuration information defining a usage of scene objects and/or a usage of scene characteristics,
the packets comprising one or more scene update packets defining a update of scene metadata for the rendering,
the packets comprising one or more scene payload packets comprising definitions of one or more scene objects and/or definitions of one or more of the scene characteristics;
wherein the method comprises selecting definitions of one or more scene objects and/or definitions of one or more scene characteristics, which are included in the scene payload packets, for the rendering in dependence on the renderer configuration information; and
wherein the method comprises updating one or more scene metadata in dependence on a content of the one or more scene update packets.
19. A method for providing an encode audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types,
wherein the method comprises providing the plurality of packets of different packet types,
the packets comprising one or more scene configuration packets providing a renderer configuration information,
the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering and comprising a representation of one or more update conditions;
wherein a content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
42. A method for providing a encoded audio representation,
wherein the method comprises providing an information for a spatial rendering of one or more audio signal;
wherein the method comprises providing a plurality of packets of different packet types;
the packets comprising one or more scene configuration packets providing a renderer configuration information defining a usage of scene objects and/or a usage of scene characteristics,
the packets comprising one or more scene update packets defining a update of scene metadata for the rendering,
the packets comprising one or more scene payload packets comprising definitions of one or more of the scene objects and/or definitions of one or more of the scene characteristics.
20. A non-transitory digital storage medium having stored there on a computer program for performing the method for providing a decoded audio representation according to claim 18 when the computer program is run by a computer.
43. A non-transitory digital storage medium having stored there on a computer program for performing the method for providing a decoded audio representation according to claim 41 when the computer program is run by a computer.
21. A non-transitory digital storage medium having stored there on a computer program for performing the method for providing a encoded audio representation according to claim 19 when the computer program is run by a computer.
44. A non-transitory digital storage medium having stored there on a computer program for performing the method for providing a encoded audio representation according to claim 42 when the computer program is run by a computer.
Claim 1 of copending Application No. 18/659947 does not teach the bitstream comprising a plurality of packets of different packet types, wherein the audio decoder is configured to evaluate whether the one or more update conditions are fulfilled and to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if the one or more update conditions are fulfilled; wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
Mate teaches an audio decoder, for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types); the packets comprising one or more scene update packets, wherein the scene update packets define an update of scene metadata for the rendering (page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update); wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata). Mate does not explicitly teach the scene update packets define an update of scene metadata for the rendering and a representation of one or more updates conditions.
D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Mate and D2 into the teachings of Claim 1 of copending Application No. 18/659947 and it would have been obvious to update in the same packets for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Claim 18 of copending Application No. 18/659947 does not teach the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
Mate teaches the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Mate into the teachings of Claim 18 of copending Application No. 18/659947 for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Claim 41 of copending Application No. 18/659947 does not teach the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
Mate teaches the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Mate into the teachings of Claim 18 of copending Application No. 18/659947 for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Claim 42 of copending Application No. 18/659947 does not teach the content of the one or more scene update packets defines a change of one or more metadata values for the rendering.
Mate teaches the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Mate into the teachings of Claim 18 of copending Application No. 18/659947 for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Conclusion
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUYNH H NGUYEN whose telephone number is (571)272-7489. The examiner can normally be reached Monday-Thursday 7:30AM-5:30PM.
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, Ahmad Matar can be reached on 571-272-7488. 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.
/QUYNH H NGUYEN/Primary Examiner, Art Unit 2693