DETAILED ACTION
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 .
Response to Amendment
The Office Action is responsive to amendments filed for 18/777,318 filed on 08/04/2026.
Please note claims 1-7 and 9-21 remain in the application.
In response to the amendment filed to claims 12, the previous rejection(s) under 35 U.S.C 112(b) has been withdrawn.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-2, 6-7, 9-10, 12, 14-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka et al, (hereinafter Hatanaka), US-PG-PUB No. 2020/0265853 (previously cited) in view of Yamada et al (hereinafter Yamada), US-PG-PUB No. 2025/0039629.
Regarding claim 1, Hatanaka discloses a signaling method (Shown in Figs. 3 and 4, encoding device (11) signals decoding device (51) using a 3D AAC bit stream, employing a method disclosed in the rejection of this claim for creating said signal.....¶[0095], lines 1-3) for utilizing supplemental audio rendering configuration (SARC) data (The bitstream contains 3D Audio data and metadata, used by the decoder to configure playback of audio data, supplementing it.....¶[0096], lines 1-5) by a player (Decoding device (51) provides rendered audio data to speakers, thus serving as a player.....¶[0104], lines 1-4) comprising:
Packaging (Shown in Fig. 3, encoding device (11) encodes (packages) data inputs (left column).....¶[0089], lines 1-5), in bitstreams (The primary output of the encoder is a 3D AAC bitstream, with provisions for an alternative or redundant bitstream containing a 3D audio metadata payload.....¶[0089], lines 5-6, ¶[0148], lines 1-8),
i) audio content (Shown in Fig. 3, inputs include PCM audio data (content).....¶[0090], line 1) generated by a content creation tool (As PCM digital audio cannot form spontaneously, the content is inherently created by one or both of a hardware tool (e.g. a digital recorder) or software tool (e.g. a digital audio workstation)) for input to an audio renderer (Shown in Fig. 4, the audio data from the primary bitstream is supplied to 3D audio renderer (64).....¶[0097], lines 1-2),
ii) SARC configuration data (Shown in Fig. 5, frames of the bit stream contain a program configuration element (PCE) containing 3D audio component information (SARC configuration data).....¶[0108], lines 1-5) corresponding to the audio content (Shown in Fig. 5, the PCE is transmitted in a frame with corresponding audio content elements.....¶[0108], lines 3-4), the SARC configuration data including
a SARC configuration table (The 3D audio component information included in the bitstream includes the number (a configuration) of channel-based, object-based, and ambisonics-based audio elements required to be rendered, grouped together (i.e. a table).....¶[0075], lines 4-10) and
a SARC mapping table (The 3D audio component information additionally identifies the types of audio represented in each single channel element and channel pair element is channel-based, object based, or ambisonic based audio data, allowing them to be mapped into the channel, object, and ambisonics audio elements (and therefor the channel, object, and ambisonics renderers) as shown in Fig. 5. This information is also grouped together for transport (i.e. a table).....¶[0150], lines 2-10, ¶[0151], lines 1-6) to initialize the audio renderer (The renderer is initialized on the basis of the 3D audio component information read from the PCE.....¶[0142], lines 2-4), and
iii) a SARC payload (Shown in Fig. 5, a payload of 3D audio metadata is received subsequent to the PCE configuration data in a data stream element (DSE).....¶[0108], lines 5-6) to be used by the audio renderer (Shown in Fig. 4, 3D Audio renderer receives and uses 3D audio metadata (62).....¶[0102], lines 1-2) to enhance immersive audio rendering (The 3D audio metadata contains height and position information for objects (¶[0156], lines 1-5), and order information for ambisonics (¶[0080]), thus enhancing these immersive audio rendering technologies, as without it, object-based audio will only be rendered in a 2D plane.....¶[0167], lines 1-4); and
providing the bitstream to be transmitted (The 3D bitstream output by the encoding device in Fig. 3 is transmitted and received to a decoding device in Fig. 4.....¶[0095], lines 1-3) to a player (As previously stated, decoding device (51) decodes the 3D AAC bit stream to provide rendered audio data to speakers, thus serving as a player.....¶[0104], lines 1-4), wherein
the bitstream configures the player to (As previously stated, the bitstream includes configuration data to be utilized by the player.....¶[0108], lines 1-5) utilize the SARC configuration data and the SARC payload (The player utilizes all data previously mentioned at the decoder level at least) for playback of the audio content (Decoding device (51) provides rendered audio data to speakers as 3D audio reproduction (playback) data.....¶[0104], lines 1-4) in a playback environment (The aforementioned speakers create a playback environment).
Hatanaka fails to explicitly disclose wherein the SARC configuration table indicates a transmission path indicating a bitstream for transmission of the SARC payload.
Yamada teaches a signaling method wherein configuration information (A control file which describes/indicates the configuration of bitstreams containing audio data files and metadata payloads.....¶[0131], lines 17-21) indicates a transmission path indicating a bitstream for transmission of a SARC payload (The control file may describe (indicate) bitstreams (and therefore transmission paths) containing metadata used to enhance rendering of audio playback (Analogous to the metadata payload of Hatanaka).....¶[0130], lines 1-5, with metadata described in further detail in ¶[0125] and ¶[0126]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka by Yamada to provide the benefit of a system wherein payloads need not be redundantly sent to parallel processors (audio processors, renderers, controllers, etc.), thus improving operational efficiency (Yamada, ¶[0133]). Such modification would make obvious the feature(s) wherein the SARC configuration table indicates a transmission path indicating a bitstream for transmission of the SARC payload.
Regarding claim 2, Hatanaka in view of Yamada teaches the signaling method of claim 1.
Hatanaka further discloses wherein the SARC configuration data is available to be used by the audio renderer before the SARC payload is available to the audio renderer (Shown in Fig. 5, the PCE containing the SARC configuration data is supplied at the top of the frame, before the DSE containing the payload.....¶[0108], lines 2-5).
Regarding claim 6, Hatanaka in view of Yamada teaches the signaling method of claim 1.
Hatanaka further discloses wherein the SARC payload is packaged in a supplemental bitstream (Shown in Fig. 4, the 3D audio metadata payload may be received from outside (63) via a different (supplemental) bitstream instead of from the decoder (62).....¶[0148], lines 3-6) transmitted to the audio renderer (The payload may be received (transmitted) from a server, or from the encoding device.....¶[0148], lines 6-8) without using a decoder of the player (The payload is received outside of the AAC bitstream, thus not needing decoding.....¶[0148], lines 6-8).
Regarding claim 7, Hatanaka in view of Yamada teaches the signaling method of claim 1.
Hatanaka further discloses wherein the SARC configuration table includes one or more SARC identifiers (The configuration table identifies rendering configurations for channel, object, and ambisonics based audio elements.....¶[0151], lines 1-6), wherein each SARC identifier is linked to one or more data identifiers specifying one or more sets of audio rendering data in the SARC payload (The configuration table corresponds to and therefore identifies which 3D audio metadata (rendering data identifiers) stored in the payload to be utilized for the different types of identifier (via SARC identifiers) rendering modes (The 3D audio metadata contains height and position information for objects (¶[0156], lines 1-5), and order information for ambisonics (¶[0080]), thus enhancing these immersive audio rendering technologies, as without it, object-based audio will only be rendered in a 2D plane.....¶[0167], lines 1-4).
Regarding claim 9, Hatanaka in view of Yamada teaches the signaling method of claim 1.
Hatanaka further discloses wherein the SARC configuration table indicates a fallback identifier to enable the player to utilize a fallback solution (The PCE may also contain, and thus identify information for two-dimensional audio object locations, allowing for 2D rendering of audio objects as a fallback option when the 3D payload is unavailable.....¶[0167], lines 1-7, with fallback methods described in detail with respect to Fig. 11 in ¶[0226]-¶[0228]).
Regarding claim 10, Hatanaka in view of Yamada teaches the signaling method of claim 1.
Hatanaka further discloses wherein the SARC mapping table links one or more SARC identifiers and one or more data identifiers in the SARC configuration table to an audio scene component (ASC) identifier associated with a set of audio channels (The mapping table identifies the number of channel, object-based, and ambisonics-based audio data (Depicted in Fig. 5 (and described in ¶[0109]-¶[0111] as SCE, CPE, and LFE audio channels), allowing them to be linked to the channel, object, and ambisonics audio elements defined by the configuration table.....¶[0150], lines 2-10, ¶[0151], lines 1-6).
Regarding claim 12, Hatanaka and Yamada teach the signaling method of claim 1, but fail to explicitly disclose, wherein the SARC configuration data (noted by the examiner as being a component of the SARC data other than the SARC payload) includes data of 265 Mbytes or more.
However, Hatanaka teaches wherein SARC configuration data is included in every frame of the bitstream transmitted to the decoding device (¶[0108], lines 3-5, ¶[0377], lines 4-8). As such, it would have been obvious to someone obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention that the total size of configuration data corresponds to the number of frames being transmitted, and that an audio file of sufficient length would result in the feature(s) wherein the SARC configuration data includes data of 265 Mbytes or more.
Regarding claim 14, the functional limitations are the same as those cited in claim 1, and are taught by the combination of Hatanaka and Yamada as explained in the rejection of claim 1.
Regarding the additional limitations, Hatanaka additionally discloses wherein the encoding device is a computer system comprised of a memory and a processor (¶[0432]) configured to execute instructions stored in the memory to perform the method of claim 1 (¶[0435]). Lastly, as the input audio is disclosed as potentially being in at least a 5.1 channel configuration, and based on the circumstantial evidence of the prior art, this input audio is clearly guided towards that which is generated in a recording environment (e.g. for music or film).
Regarding claim 15, Hatanaka in view of Yamada teaches the system of claim 14.
Hatanaka further discloses wherein the SARC configuration data is transmitted in its entirety before the SARC payload is transmitted in its entirety (Shown in Fig. 5, the PCE containing the configuration is supplied before the DSE containing the payload.....¶[0108], lines 2-5).
Regarding claim 16, Hatanaka in view of Yamada teaches the system of claim 14.
Hatanaka further discloses wherein the SARC payload is transmitted in a one-time pulse (The 3D audio metadata payload may be externally obtained from the decoding device and implemented as a default metadata value.....¶[0136], lines 1-6, ¶[0148], lines 3-6) before transmitting the audio content (Shown in Fig. 7, in the event the audio content bitstream has no 3D audio metadata payload when the first frame of audio content is received, the renderer utilizes the externally obtained metadata receiver prior to the first frame.....¶[0135], lines 1-6).
Regarding claim 17, Hatanaka in view of Yamada teaches the system of claim 14.
Hatanaka further discloses wherein the SARC payload is transmitted in a build-up while transmitting frames of the audio content (Shown in Fig. 14, the 3D audio metadata (payload) may be divided and transmitted over multiple frames, the frames, per Fig. 5, including audio content. Once the final frame with divided 3d audio metadata is received the decoder combines the pieces, building them into the single payload.....¶[0285], lines 1-8).
Regarding claim 18, Hatanaka in view of Yamada teaches the system of claim 14.
Hatanaka further discloses wherein the SARC payload is transmitted in-band with the audio content in a same bitstream (Shown in Fig. 5, the 3D audio metadata payload is transmitted in the same frame-based bitstream as the audio content (SCEs, CPEs, LFEs)).
Claim 19 is rejected under the same grounds as claim 6.
Regarding claim 21, Hatanaka in view of Yamada teaches the system of claim 1.
Yamada further teaches wherein the SARC configuration table indicates one of at least three possible bitstreams for transmission of the SARC payload (Information may be transmitted via two or more (i.e. three) bistreams, each of which may contain the metadata payload.....¶[0131], lines 3-10).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada further by Yamada to provide the benefit of a system wherein payloads need not be redundantly sent to parallel processors (audio processors, renderers, controllers, etc), thus improving operational efficiency (Yamada, ¶[0133]). Such modification would make obvious the feature(s) wherein the SARC configuration table indicates a transmission path indicating a bitstream for transmission of the SARC payload.
Claim(s) 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Yamada in further view of Kim et al (hereinafter Kim), US-PG-PUB No. 2020/0105282 (previously cited).
Regarding claim 3, Hatanaka and Yamada teach the signaling method of claim 1, but fail to teach wherein the SARC configuration and SARC payload data are packaged in a separate bitstream from the audio content.
Kim teaches a method of audio encoding wherein configuration data (Renderer selection information, analogous to the SARC configuration data of Hatanaka.....¶[0097], lines 1-8) and the SARC payload (Specific renderer instructions, analogous to the 3D audio metadata of Hatanaka.....¶[0097], lines 8-10) are packaged in an audio-coding configuration bitstream (This data used to configure audio playback constitutes side channel information, which may be included in side channel bitstreams (audio-coding configuration bitstreams) separate from a primary bitstream.....¶[0095], lines 11-13, ¶[0097], lines 8-10) and the audio content is packaged in a frame-by-frame data bitstream (The audio content, distinct from the side data, is included in a primary bitstream, transmitted in frames.....¶[0041], lines 15-22, ¶[0083], lines 8-9).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada by Kim to provide the benefit of reducing manufacturing costs of audio decoders (Kim, ¶[0062], lines 1-2. Such modification would make obvious the feature(s) wherein the SARC configuration data and the SARC payload are packaged in an audio-coding configuration bitstream and the audio content is packaged in a frame-by-frame data bitstream.
Regarding claim 5, Hatanaka and Yamada teach the signaling method of claim 1, but fail to teach wherein the SARC configuration data is packaged in an audio-coding configuration bitstream, the audio content is packaged in a frame-by-frame data bitstream, and the SARC payload is packaged in a supplemental bitstream.
Kim teaches a method of audio encoding wherein configuration data (Renderer selection information, analogous to the SARC configuration data of Hatanaka.....¶[0097], lines 1-8) is packaged in an audio-coding configuration bitstream (This data used to configure audio playback constitutes side channel information, which may be included in side channel bitstreams separate from a primary bitstream.....¶[0095], lines 11-13, ¶[0097], lines 8-10), the audio content is packaged in a frame-by-frame data bitstream (The audio content, distinct from the side data, is included in a primary data bitstream, transmitted in frames.....¶[0041], lines 15-22, ¶[0083], lines 8-9), and the SARC payload (Specific renderer instructions, analogous to the 3D audio metadata of Hatanaka.....¶[0097], lines 8-10) is packaged in a supplemental bitstream (The different types of side data may be communicated via individual side channel bitstreams, thus forming a supplemental bitstream as well as a configuration bitstream.....¶[0095], lines 11-13).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada by Kim to provide the benefit of reducing manufacturing costs of audio decoders (Kim, ¶[0062], lines 1-2. Such modification would make obvious the feature(s) wherein the SARC configuration data is packaged in an audio-coding configuration bitstream, the audio content is packaged in a frame-by-frame data bitstream, and the SARC payload is packaged in a supplemental bitstream.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Yamada in further view of Sen et al (hereinafter Sen), US-PG-PUB No. 2014/0226823 (previously cited).
Regarding claim 4, Hatanaka and Yamada teach the signaling method of claim 1, but fail to teach wherein the SARC configuration data is packaged in a separate bitstream from the audio content and the SARC payload.
Sen teaches a method of audio encoding wherein configuration data (Matrix selection information, analogous to the SARC configuration data of Hatanaka.....¶[0052], lines 9-11) is packaged in an audio-coding configuration bitstream (This data used to configure audio playback metadata, which may be provided separate from a primary bitstream (i.e. in an audio-coding configuration bitstream).....¶[0052], lines 9-11) and the audio content (Multi-channel audio content.....¶[0034], lines 18-19) and the SARC payload (Specific renderer matrices, analogous to the 3D audio metadata of Hatanaka.....¶[0052], lines 7-9) are packaged in a frame-by-frame data bitstream (The matrices and audio data are packaged together in a primary bitstream (31), constituting frame-by-frame information.....¶[0052], lines 7-9, ¶[0034], lines 18-22).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada by Sen to provide the benefit of reducing manufacturing costs of audio decoders (Sen, ¶[0059], lines 1-2. Such modification would make obvious the feature(s) wherein the SARC configuration data is packaged in an audio-coding configuration bitstream and the audio content and the SARC payload are packaged in a frame-by-frame data bitstream.
Claim(s) 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Yamada in further view of Dressler et al (hereinafter Dressler), US-PG-PUB No. 2012/0232910 (previously cited).
Regarding claim 11, Hatanaka and Yamada teach the signaling method of claim 1.
Hatanaka additionally discloses wherein the bitstreams enable the audio renderer to change between audio generated by a fallback solution and audio generated by the SARC payload (The PCE may also contain, and thus identify information for two-dimensional audio object locations, allowing for 2D rendering of audio objects as a fallback option when the 3D payload is unavailable.....¶[0167], lines 1-7, with fallback methods described in detail with respect to Fig. 11 in ¶[0226]-¶[0228]).
Hatanaka and Yamada fail to teach wherein said change is a crossfade.
Dressler teaches a method of audio rendering wherein when audio playback is changed from a parametric rendering to object-based rendering upon the availability of extension objects (analogous to the SARC payload of Hatanaka), the change is a crossfade (¶[0027], lines 1-8).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada by Dressler to provide the benefit of transitions that are less perceptible to a user (Dressler, ¶[0027], lines 11-13). Such modification would make obvious the feature(s) wherein the bitstreams enable the audio renderer to crossfade between audio generated by a fallback solution and audio generated by the SARC payload.
Claim 20 is rejected under the same grounds as claim 11.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Yamada in further view of Peters et al, US-PG-PUB No 2015/0264484 (previously cited).
Regarding claim 13, Hatanaka and Yamada teach the signaling method of claim 1.
Hatanaka additionally teaches wherein the SARC configuration data and the SARC payload enable configuring a higher order ambisonics (HOA) rendering order and mode (¶[0080], lines 1-3) in the playback environment.
Hatanaka and Yamada fail to teach enabling configuring a rendering matrix.
Peters teaches an audio encoder and decoder wherein a transmitted identifier (analogous to the SARC configuration of Hatanaka) may indicate a transmitted HOA rendering matrix (analogous to the SARC payload of Hatanaka), thus enabling configuring of a higher order ambisonics (HOA) rendering matrix in the playback environment (¶[0113], lines 3-6).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hatanaka and Yamada by Peters to provide the benefit of reducing manufacturing costs of audio decoders (Peters, ¶[0065], lines 1-2. Such modification would make obvious the feature(s) wherein the SARC configuration data and the SARC payload enable configuring a higher order ambisonics (HOA) rendering matrix in the playback environment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Oh et al, US-PG-PUB No. 2009/0265176 teaches a backwards compatible audio processing and rendering method wherein SAOC bitstream data (and where it may be located by the processing unit) is indicated by transmitted configuration information.
Wuebbolt et al, US-PG-PUB No. 2009/0240506 teaches an audio packaging method where enhancement information may be provided in a supplementary bitstream.
Robinson et al, US-PG-PUB No. 2014/0133683 teaches an audio packaging method where each audio stream in a main bitstream packaged in an individual sub-bitstream along with its configuration data.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SEAN RINEHART whose telephone number is (571)272-2778. The examiner can normally be reached M-F 10:00 AM - 6:00 PM ET.
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.
/SEAN RINEHART/Examiner, Art Unit 2694
/AHMAD F. MATAR/Supervisory Patent Examiner, Art Unit 2693
