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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 12 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “bulk” recited in claim 12 line 2, understood in view of the specification (e.g. ¶[0045], line 1) to mean “large-sized” is a relative term which renders the claim indefinite. The term “bulk” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. As such, the “bulk data”, recited in claim 12, line 2, is rendered indefinite.
For purposes of examination, “bulk data,” as recited in claim 12, line 2, will be read as “data.”
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 6-10, 14-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hatanaka et al, (hereinafter Hatanaka), US-PG-PUB No. 2020/0265853.
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 a bitstream (The output of the encoder is a 3D AAC Bit stream.....¶[0089], lines 5-6),
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 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).
Regarding claim 2, Hatanaka discloses, as explained above, the signaling method of claim 1, 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 discloses, as explained above, the signaling method of claim 1, 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 discloses, as explained above, the signaling method of claim 1, 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 8, Hatanaka discloses, as explained above, the signaling method of claim 1, wherein the SARC configuration table indicates a transmission path for the SARC payload (As the SARC configuration table and SARC payload and transmitted via the same transmission path (the one bitstream recited in the rejection of claim 1), the path from which the configuration table is received additionally indicates the path from which the payload is received).
Regarding claim 9, Hatanaka discloses, as explained above, the signaling method of claim 1, 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 discloses, as explained above, the signaling method of claim 1, 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 14, the functional limitations are the same as those cited in claim 1, and are disclosed by Hatanaka 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 discloses, as explained above, the system of claim 14, 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 discloses, as explained above, the system of claim 14, 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 discloses, as explained above, the system of claim 14, 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 discloses, as explained above, the system of claim 14, 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.
Claim Rejections - 35 USC § 103
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.
Claim(s) 3-5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Kim et al (hereinafter Kim), US-PG-PUB No. 2020/0105282.
Regarding claim 3, Hatanaka discloses, as explained above, the signaling method of claim 1, but fails to disclose 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 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 discloses, as explained above, the signaling method of claim 1, but fails 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 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 Sen et al (hereinafter Sen), US-PG-PUB No. 2014/0226823.
Regarding claim 4, Hatanaka discloses, as explained above, the signaling method of claim 1 but fails to disclose 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 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 Dressler et al (hereinafter Dressler), US-PG-PUB No. 2012/0232910.
Regarding claim 11, Hatanaka discloses, as explained above, the signaling method of claim 1, including wherein the one or more 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 fails to disclose 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 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 one or more 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 12 is rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka.
Regarding claim 12, as best understood in light of the current rejection under 112(b), Hatanaka discloses, as explained above, the signaling method of claim 1, but fails 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.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka in view of Peters et al, US-PG-PUB No 2015/0264484.
Regarding claim 13, Hatanaka discloses, as explained above, the signaling method of claim 1, 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, but fails to explicitly disclose 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 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.
Tsingos et al, US-PG-PUB No. 2021/0118452 teaches encoding of radiation patterns of audio objects.
Kim et al, US-PG-PUB No. 2015/0332683 teaches crossfading between audio rendering modes.
Munoz et al, US-PG-PUB No. 2024/0282320 teaches a signaling method comprised of assigning audio elements to groups, and audio groups to renderers.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SEAN M 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, Fan Tsang can be reached on (571) 272-7547. 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 M RINEHART/Examiner, Art Unit 2694
/FAN S TSANG/Supervisory Patent Examiner, Art Unit 2694
Prosecution Insights