DETAILED ACTION
This communication is in response to the Application filed on 20 June 2025. Claims 1-20 are pending and have been examined.
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 .
Priority
Receipt is acknowledged that application claims priority to foreign application with application number CN 202211644420.4 dated 20 December 2022. Copies of certified papers required by 37 CFR 1.55 have been received. Priority is acknowledged under 35 USC 119(e) and 37 CFR 1.78.
Information Disclosure Statement
The IDS dated 18 September 2025 has been considered and placed in the application file.
Claim Interpretation
Under MPEP 2143.03, "All words in a claim must be considered in judging the patentability of that claim against the prior art." In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). As a general matter, the grammar and ordinary meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298, 92 USPQ2d 1163, 1171 (Fed. Cir. 2009).
Claims 5 and 10 recite “at least one of” then listing “configuration information of the at least two audio encoded streams,” “configuration information of an in-band forward error correction coding (FEC),” and “configuration information of bandwidth extension data.” Since “at least one of” is disjunctive, any one of the elements found in the prior art is sufficient to reject the claim. While citations have been provided for completeness and rapid prosecution, only one element is required. Because, on balance, it appears the disjunctive interpretation enjoys the most specification support and for that reason the disjunctive interpretation (one of A, B OR C) is being adopted for the purposes of this Office Action. Applicant’s comments and/or amendments relating to this issue are invited to clarify the claim language and the prosecution history.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 8-11, and 13-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. All of the claims are method claims (1-4, 8-13), apparatus/machine claims (14-20) or manufacture claim under (Step 1), but under Step 2A all of these claims recite abstract ideas and specifically mental processes. These mental processes are more particularly recited in claims 1, 8, 14, 17, 19, and 20 as:
generating encoded data of the audio frame based on the at least two audio encoded streams and the extension bitstream…
decoding the at least two audio encoded streams and the extension bitstream to obtain the audio frame…
Under Step 2A Prong One, claims 1, 8, 14, 17, 19, and 20 are directed to an abstract idea and specifically a mental process. As detailed above, the steps of generating and decoding may be practically performed in the human mind with the use of a physical aid such as a pen and paper. For example, a human could receive two audio encoded streams and an extension bitstream, align all three streams, and denote the aligned streams as generated encoded data of the audio frame. Alternatively, to decode encoded streams and obtain an audio frame, the human could receive the two audio encoded streams and an extension bitstream, dequantize the encoded streams via a quantization matrix, and then convert the dequantized values into the time-domain using Inverse Fast Fourier Transform.
Under Step 2A Prong Two, this judicial exception is not integrated into a practical application because claims 1-4, 8-11, and 13-20 do not recite additional elements that integrate the exception into a practical application. In particular, claims 14, 17, 19, and 20 recite the additional elements of a processor (¶ [0158]) and memories (¶ [0158]). These additional elements are recited at a high level of generality and merely equate to “apply it” or otherwise merely uses a generic computer as a tool to perform an abstract which are not indicative of integration into a practical application as per MPEP 2106.05(f). Further, claims 1, 8, 14, 17, 19, and 20 recite the additional elements of “acquiring…” which amounts to insignificant extra-solution activities which are not indicative of integration into a practical application as per MPEP 2106.05(g). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Under Step 2B, the claims do not recite additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of using a computer is noted as a general computer {processor (¶ [0158]); memories (¶ [0158])}. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Further, the additional limitations in the claims noted above are directed towards insignificant extra-solution activities. The claims are not patent eligible.
With respect to claims 2, 9-11, 15, and 18, the claim relates to specifying coding properties of each of the audio encoded streams and extension bitstream. As noted above, the additional element of “acquiring…” amounts to insignificant extra-solution activities which are not indicative of integration into a practical application as per MPEP 2106.05(g). Further specifying aspects of these acquired elements does not detract from the abstract idea of a human merely aligning the bitstreams and denoting the aligned bitstream as the generated encoded data of the audio frame, or a human decoding the bitstreams by first dequantizing them and applying IFFT. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 3 and 16, the claim relates to determining the two audio encoded streams and the extension bitstream as the encoded data of the audio frame. This relates to a human denoting the two audio encoded streams and the extension bitstream as the encoded data of the audio frame. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 4 and 16, the claim relates to recombining the two audio encoded streams and extension bitstream. This relates to a human aligning the two audio encoded streams and the extension bitstream, and denoting the aligned bitstreams as the recombined encoded data of the audio frame. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
With respect to claims 13, the claim relates to acquiring target encoded data alongside a target extension bitstream, and decoding the target encoded data and target extension bitstream in order to recover a previously lost audio frame. This relates to a human receiving audio encoded data and an extension bitstream, aligning all three streams to a previously lost frame, and performing decoding by first dequantizing each stream and applying IFFT to recover the audio frame. No additional limitations are present. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
For all of the above reasons, taken alone or in combination, claims 1-4, 8-11, and 13-20 recite a non-statutory mental process.
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.
Claims 1-5, 8-10, and 13-20 are rejected under 35 U.S.C. 103 as obvious over “Packet loss protection for interactive audio object rendering: A multiple description approach” (Zheng et al.) in view of US Patent Publication 20070083363 A1 (Kim et al.).
Claim 1
Regarding claim 1, Zheng et al. disclose an audio processing method, comprising:
acquiring at least two audio encoded streams (Zheng et al. pg. 69, Section 3.1, Paragraph 1, "Multiple Description Coding (MDC) [5] is a joint source-channel coding technique that divides a source bitstream into two or more independent bitstreams (descriptions) that are then transmitted separately.") and an extension [bitstream] (Zheng et al. pg. 69, Section 2, Paragraph 1, "The input audio objects are firstly compressed by the Audio Mixture Generator to create the Primary and Secondary Audio Mixtures such that the encoded audio objects can be selectively recovered at the reproduction site." Secondary encodings are considered analogous to an extension) according to an audio frame (Zheng et al. pg. 69, Section 2.1, Paragraph 1, "Input audio objects from Source 1 to Source M (as shown in Fig.1), are firstly transformed into time-frequency domain using a Short Time Fourier Transform (STFT), denoted by
S
m
(
n
,
k
)
where 1≤
m
≤M and
n
and
k
are frame number and frequency index, respectively." pg. 69, Section 2.2, Paragraph 2, "In this work, two mixtures (primary and secondary i.e.
j
=
0
and
j
=
1
, respectively) are selected....
S
0
(
n
,
k
)
and
S
1
(
n
,
k
)
can be transferred back to time domain using an Inverse Short Time Fourier Transform (ISTFT) to create the mono mixtures." Secondary mixture
S
1
(
n
,
k
)
is considered analogous to an extension according to an audio frame); and
generating encoded data of the audio frame based on the at least two audio encoded streams and the extension [bitstream] (Zheng et al. pg. 69, Section 2, Paragraph 1, "The proposed framework is illustrated in Fig. 1. The input audio objects are firstly compressed by the Audio Mixture Generator to create the Primary and Secondary Audio Mixtures such that the encoded audio objects can be selectively recovered at the reproduction site." See Figure 1, which illustrates generating encoded data of the audio frame based on at least two audio encoded streams (e.g. "Description 1" and "Description 2") and the extension (e.g. "Secondary Mixture"). It is important to note that the extension (e.g. "Secondary Mixture") is separate from the two bitstreams generated via MDC encoding, as supported in pg. 70, Section 3.1, Paragraph 3-4, "In Forward Error Correction (FEC) [9], lost data in the current packet (Primary Encoding) can be recovered in the receiver end by transmitting a degraded yet still acceptable version of the primary encoding (Secondary Encoding) in other packets. ... The [primary encoding (PE)] sections could be regarded as the MDC descriptions with coding rate RPE from the two-description MDC model." See Figure 2 for direct examples of what encoded data may look like).
Zheng et al. do not explicitly disclose all of an extension bitstream.
However, Kim et al. disclose acquiring [at least two] audio encoded stream[s] (Kim et al. ¶ [0059], "When an audio data input to the audio data encoding unit 200 is a multi-channel signal, the audio data encoding unit 200 may select on the multi-channel signal to obtain a stereo signal, and encode the audio data.") and an extension bitstream (Kim et al. ¶ [0062], "The extension data encoding unit 230 may encode extension data of encoded audio data, e.g., as encoded by the audio data encoding unit 200. Here, the extension data refers to data used to process audio data so as to extend the available applications of the audio data.") [according to an audio frame]; and
generating encoded data of the audio frame based on the [at least two] audio encoded stream[s] and the extension bitstream (Kim et al. ¶ [0072], "the bitstream formatter 240 may generate a bitstream from the payload and the codes generated by the encoding in the audio data encoding unit 200, ... and the extension data encoding unit 230, for example, and output the bitstream through an output terminal OUT. The bitstream formatter 240 may generate the bitstream by sequentially multiplexing the payload of the audio data and the termination code, for example.").
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Zheng et al.’s multiple description coding to incorporate Kim et al.’s separate extension bitstream because such a modification is the result of simple substitution of one known element for another producing a predictable result. More specifically, Zheng et al.’s interleaved extension data and Kim et al.’s separate extension bitstream perform the same general and predictable function, the predictable function being transmitting additional data alongside primary audio data in order to enhance aspects of the primary audio data. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself - that is in the substitution of Zheng et al.’s interleaved extension data by replacing it with Kim et al.’s separate extension bitstream. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Claim 2
Regarding claim 2, the rejection of claim 1 is incorporated.
Zheng et al. further disclose wherein the at least two audio encoded streams are generated by multiple description coding according to the audio frame (Zheng et al. pg. 69, Section 3.1, Paragraph 1, "Multiple Description Coding (MDC) [5] is a joint source-channel coding technique that divides a source bitstream into two or more independent bitstreams (descriptions) that are then transmitted separately."), and the extension [bitstream] comprises audio encoded data of a previous Nth frame of the audio frame and/or bandwidth extension data of the audio frame, where N is an integer greater than 0 (Zheng et al. pg. 70, Section 3.1, Paragraph 5, "MDC-FEC Model 2 (MDC-FEC-2, as shown in Fig. 2(b)) extends MDC-FEC Model 1 by using two transmission channels to implement two [Secondary Encodings (SE)] with rate
R
i
S
E
f
and
R
i
S
E
b
to protect the primary encoding with rate
R
i
P
E
(
i
=
1
or
i
=
2
) in the following and previous packets, where
S
E
f
represents the SE of packet
n
that is transmitted alongside frame
n
-
1
(a forward error correction scheme)" See Figure 2B; given
P
E
1
n
and
P
E
2
n
are the primary encodings for current frame
n
,
S
E
f
1
n
-
1
and
S
E
f
2
n
-
1
are considered analogous to audio encoded data of a previous Nth frame, where N is an integer equal to 1.).
Kim et al. further disclose wherein [the at least two audio encoded streams are generated by multiple description coding according to the audio frame, and] the extension bitstream comprises audio encoded data of a previous Nth frame of the audio frame and/or bandwidth extension data of the audio frame (Kim et al. ¶ [0062], "The extension data encoding unit 230 may encode extension data of encoded audio data, e.g., as encoded by the audio data encoding unit 200. Here, the extension data refers to data used to process audio data so as to extend the available applications of the audio data. For example, the extension data may include at least one of data for extending the bandwidth of the audio data"), where N is an integer greater than 0.
Claim 3
Regarding claim 3, the rejection of claim 1 is incorporated.
Zheng et al. further disclose determining the at least two audio encoded streams and the extension [bitstream] as the encoded data of the audio frame (Zheng et al. pg. 69, Section 2, Paragraph 1, "The proposed framework is illustrated in Fig. 1. The input audio objects are firstly compressed by the Audio Mixture Generator to create the Primary and Secondary Audio Mixtures such that the encoded audio objects can be selectively recovered at the reproduction site." See Figure 1, which illustrates that encoded data of the audio frame is determined as the at least two audio encoded streams (e.g. "Description 1" and "Description 2") and the extension (e.g. "Secondary Mixture", which is independently interleaved into each respective description as per Figure 2)).
Kim et al. further disclose determining the [at least two] audio encoded stream[s] and the extension bitstream as the encoded data of the audio frame (Kim et al. ¶ [0072], "the bitstream formatter 240 may generate a bitstream from the payload and the codes generated by the encoding in the audio data encoding unit 200, ... and the extension data encoding unit 230, for example, and output the bitstream through an output terminal OUT. The bitstream formatter 240 may generate the bitstream by sequentially multiplexing the payload of the audio data and the termination code, for example.").
Claim 4
Regarding claim 4, the rejection of claim 1 is incorporated.
Zheng et al. further disclose recombining each of the at least two audio encoded streams and one extension [bitstream] corresponding to the each of the at least two audio encoded streams [into one bitstream] as the encoded data of the audio frame (Zheng et al. pg. 70-71, Section 4.1, Paragraph 1, "After applying the interleaving procedure described in Section 3.1 to the primary and secondary audio mixture signals generated in Section 2, 64 to 256 kbps total transmission bitrates are employed ... For instance, if the total rate available for transmission is
R
, the two balanced descriptions (each encoded using rate R/2) are transmitted ... via two channels for MDC, MDC-FEC-1 and MDC-FEC-2 models" Transmitting descriptions after interleaving them with FEC extension data is considered analogous to recombining each of the at least two audio encoded streams (e.g. Figure 2(b), "
P
E
1
n
" and "
P
E
2
n
") and one extension corresponding to each of the at least two audio encoded streams (e.g. Figure 2(b), "
S
E
f
1
n
" and "
S
E
f
2
n
")), in a case where the each of the at least two audio encoded streams corresponds to one extension [bitstream] (Zheng et al. pg. 70, Section 3.1, Paragraph 5, "MDC-FEC Model 2 (MDC-FEC-2, as shown in Fig. 2(b)) extends MDC-FEC Model 1 by using two transmission channels to implement two [Secondary Encodings (SE)] ... to protect the primary encoding ... in the following and previous packets, where
S
E
f
represents the SE of packet
n
that is transmitted alongside frame
n
-
1
(a forward error correction scheme)" See Figure 2B; given
P
E
1
n
and
P
E
2
n
are the primary encodings for current frame
n
,
S
E
f
1
n
and
S
E
f
2
n
are considered analogous to extension data that corresponds to the at least two audio encoded streams
P
E
1
n
and
P
E
2
n
); or
recombining each of part of the at least two audio encoded streams and one extension bitstream corresponding to the each of the part of the at least two audio encoded streams into one bitstream, and determining the recombined bitstream and an audio encoded stream except the part of the audio encoded streams as the encoded data of the audio frame, in a case where the each of the part of the at least two audio encoded streams corresponds to one extension bitstream.
Kim et al. further disclose recombining each of the [at least two] audio encoded stream[s] and one extension bitstream corresponding to the each of the [at least two] audio encoded stream[s] into one bitstream as the encoded data of the audio frame (Kim et al. ¶ [0085], "a bitstream may be generated, according to an embodiment, by sequentially multiplexing the payload of the encoded audio data and the termination code, in operation 570. When all the extension data are encoded, the bitstream may be generated by sequentially multiplexing the start code, ... an extension type code indicating the type of an
N
t
h
extension data, and a payload of the encoded
N
t
h
extension data, in addition to the above-described payload and the termination code, for example." Sequential multiplexing is considered analogous to recombining), in a case where the each of the [at least two] audio encoded stream[s] corresponds to one extension bitstream (Kim et al. ¶ [0073], "FIG. 4 illustrates an encoded audio data and extension data payload, according to an embodiment of the present invention. Here, an extension type code, indicating each extension data type, may exist before the payload of each extension data. Referring to FIG. 4, reference numeral 400 denotes encoded audio data of front left (FL) and front right (FR) channels, e.g., as encoded in the audio data encoding unit 200. Reference numeral 401 denotes `zero_code`, as a termination code, reference numeral 402 denotes `sync_word`, as a start code, and reference numeral 403 denotes code `0000`, as an extension type code indicating extension data for extending the bandwidth of the audio data." See Figure 4; appending extension data to its corresponding extension data payload is considered analogous to a case where the audio encoded stream corresponds to one extension bitstream); or
recombining each of part of the at least two audio encoded streams and one extension bitstream corresponding to the each of the part of the at least two audio encoded streams into one bitstream, and determining the recombined bitstream and an audio encoded stream except the part of the audio encoded streams as the encoded data of the audio frame, in a case where the each of the part of the at least two audio encoded streams corresponds to one extension bitstream.
Claim 5
Regarding claim 5, the rejection of claim 2 is incorporated.
Zheng et al. further disclose writing [the control byte] into the encoded data of the audio frame (Zheng et al. pg. 70, Section 3.1, Paragraph 2, "In this paper, two descriptions are used and each description is formed by interleaving the frequency components of the primary and secondary audio mixtures of Section 2. Specifically, the frequency components in the even frequency bins of the primary audio mixture are swapped with the corresponding frequency components in the secondary audio mixture" See Figure 2; interleaving audio mixtures for each frame
n
is considered analogous to writing into the encoded data of the audio frame).
Kim et al. further disclose wherein the generating encoded data of the audio frame based on the [at least two] audio encoded stream[s] and the extension bitstream comprises:
generating a control byte based on the at least two audio encoded streams and the extension bitstream (Kim et al. ¶ [0063], "The extension data encoding unit 230 may further include an extension type code generating portion 232, ... [and] an error check code generating portion 236." Codes are considered analogous to a control byte), wherein the control byte comprises at least one of configuration information of the at least two audio encoded streams, configuration information of an in-band forward error correction coding (FEC) or configuration information of bandwidth extension data (Kim et al. ¶ [0064]-[0065], "The extension type code generating portion 232 may generate an extension type code that corresponds to the type of the extension data and may be located before the payload of the extension data. ... As illustrated in FIG. 3, code `0000` is a code value of "extension type" and indicates extension data for extending the bandwidth of the audio data by encoding the audio data using an SBR tool. " Codes indicating the presence of data for extending the bandwidth of audio data is considered analogous to configuration information of bandwidth extension data); and
writing the control byte into the encoded data [of the audio frame] (Kim et al. ¶ [0072], "the bitstream formatter 240 may generate a bitstream from the payload and the codes generated by the encoding in the audio data encoding unit 200 ... and the extension data encoding unit 230, for example, and output the bitstream through an output terminal OUT. ... Here, when the extension data is encoded, in addition to the payload of the audio data..., a code indicating the type of an
N
t
h
extension data, and a payload of the encoded
N
t
h
extension data may be sequentially multiplexed to generate the bitsteam.").
Claim 8
Regarding claim 8, Zheng et al. disclose an audio processing method, comprising:
acquiring at least two audio encoded stream[s] (Zheng et al. pg. 69, Section 3.1, Paragraph 1, "Multiple Description Coding (MDC) [5] is a joint source-channel coding technique that divides a source bitstream into two or more independent bitstreams (descriptions) that are then transmitted separately.") and an extension [bitstream] (Zheng et al. pg. 69, Section 2, Paragraph 1, "The input audio objects are firstly compressed by the Audio Mixture Generator to create the Primary and Secondary Audio Mixtures such that the encoded audio objects can be selectively recovered at the reproduction site." Secondary encodings are considered analogous to an extension) according to an audio frame (Zheng et al. pg. 69, Section 2.1, Paragraph 1, "Input audio objects from Source 1 to Source M (as shown in Fig.1), are firstly transformed into time-frequency domain using a Short Time Fourier Transform (STFT), denoted by
S
m
(
n
,
k
)
where 1≤
m
≤M and
n
and
k
are frame number and frequency index, respectively." pg. 69, Section 2.2, Paragraph 2, "In this work, two mixtures (primary and secondary i.e.
j
=
0
and
j
=
1
, respectively) are selected....
S
0
(
n
,
k
)
and
S
1
(
n
,
k
)
can be transferred back to time domain using an Inverse Short Time Fourier Transform (ISTFT) to create the mono mixtures." Secondary mixture
S
1
(
n
,
k
)
is considered analogous to an extension according to an audio frame); and
decoding the at least two audio encoded streams and the extension [bitstream] to obtain the audio frame (Zheng et al. pg. 69, Section 2.1, Paragraph 1, "Input audio objects from Source 1 to Source M (as shown in Fig.1), are firstly transformed into time-frequency domain using a Short Time Fourier Transform (STFT), denoted by
S
m
(
n
,
k
)
where 1≤
m
≤M and
n
and
k
are frame number and frequency index, respectively." pg. 69, Section 2.2, Paragraph 2, "the
m
t
h
(
1
≤
m
≤
M
) reconstructed audio object
S
'
m
(
n
,
k
)
can be recovered from the received primary and secondary audio mixtures, which is given by:
S
'
m
n
,
k
=
S
m
,
0
n
,
k
+
S
m
,
1
n
,
k
∀
n
,
k
(5)." The frame associated with frame number
n
is considered analogous to the audio frame. See Figure 1 for an illustration of how two audio encoded streams (e.g. "Description 1" and "Description 2") eventually are decoded via the Channel Decoder and Audio Object Decoder).
Zheng et al. do not explicitly disclose all of an extension bitstream.
However, Kim et al. disclose acquiring [at least two] audio encoded stream[s] (Kim et al. ¶ [0059], "When an audio data input to the audio data encoding unit 200 is a multi-channel signal, the audio data encoding unit 200 may select on the multi-channel signal to obtain a stereo signal, and encode the audio data.") and an extension bitstream (Kim et al. ¶ [0062], "The extension data encoding unit 230 may encode extension data of encoded audio data, e.g., as encoded by the audio data encoding unit 200. Here, the extension data refers to data used to process audio data so as to extend the available applications of the audio data.") [according to an audio frame]; and
decoding the [at least two] audio encoded stream[s] and the extension bitstream (Kim et al. ¶ [0098], "FIG. 7 illustrates an apparatus for decoding audio data and extension data, according to an embodiment of the present invention.") [to obtain the audio frame].
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Zheng et al.’s multiple description coding to incorporate Kim et al.’s separate extension bitstream.
The suggestion/motivation for doing so is similar to the suggestion/motivation described above with respect to claim 1.
Claim 9
Regarding claim 9, the rejection of claim 8 is incorporated. The limitations of claim 9 are similar in scope to that of claim 2 and therefore are rejected for similar reasons as described above.
Claim 10
Regarding claim 10, the rejection of claim 8 is incorporated. The limitations of claim 10 are similar in scope to that of claim 5 and therefore are rejected for similar reasons as described above.
Claim 13
Regarding claim 13, the rejection of claim 8 is incorporated.
Zheng et al. further disclose acquiring target encoded data associated with an audio frame after the Nth frame of the audio frame (Zheng et al. pg. 70, Figure 2(b) illustrates acquiring target encoded data associated with an audio frame (e.g. the right-side packets of data comprising primary encodings
P
E
1
n
+
1
and
P
E
2
n
+
1
) after the Nth frame of the audio frame (e.g. the middle packets of data comprising primary encodings
P
E
1
n
and
P
E
2
n
)) in a case where the encoded data of the audio frame is not received (Zheng et al. pg. 70, Section 3.1, Paragraph 3, "In Forward Error Correction (FEC) [9], lost data in the current packet (Primary Encoding) can be recovered in the receiver end by transmitting a degraded yet still acceptable version of the primary encoding (Secondary Encoding) in other packets.");
acquiring a target extension bitstream from the target encoded data (Zheng et al. pg. 70, Section 3.1, Paragraph 3, "In Forward Error Correction (FEC) [9], lost data in the current packet (Primary Encoding) can be recovered in the receiver end by transmitting a degraded yet still acceptable version of the primary encoding (Secondary Encoding) in other packets." See Figure 2(b), which illustrates acquiring a target extension bitstream (e.g. Secondary encodings
S
E
f
1
n
and
S
E
f
2
n
) from the target encoded data (e.g. the right-side packets of data described above)); and
acquiring the audio encoded data of the audio frame from the target extension bitstream (Zheng et al. pg. 70, Section 3.1, Paragraph 3-4, "In Forward Error Correction (FEC) [9], lost data in the current packet (Primary Encoding) can be recovered in the receiver end by transmitting a degraded yet still acceptable version of the primary encoding (Secondary Encoding) in other packets. ... In hybrid MDC-FEC, two balanced descriptions are created using the interleaving approach described above. Each description is then further protected using FEC. MDC-FEC Model 1 (MDC-FEC-1, as shown in Fig. 2(a)) implements an FEC secondary encoding ... to protect the primary encoding (PE) ... in the following packet. ... For instance, in Fig.2(a), the right package contains the secondary encoding for the
n
-
1
t
h
primary encoding (
S
E
i
n
-
1
), and
n
t
h
primary encoding (
P
E
i
n
). The PE sections could be regarded as the MDC descriptions with coding rate RPE from the two-description MDC model." Utilizing subsequent FEC packets (e.g. Secondary encodings
S
E
f
1
n
and
S
E
f
2
n
from right-side packet of Figure 2(b)) to recover lost data in the current packet (e.g. Primary encodings
P
E
1
n
and
P
E
2
n
from middle packet of Figure 2(b)) is considered analogous to acquiring audio encoded data from the target extension bitstream), and decoding the audio encoded data of the audio frame (Zheng et al. pg. 69, Section 2.2, Paragraph 2, "the
m
t
h
(
1
≤
m
≤
M
) reconstructed audio object
S
'
m
(
n
,
k
)
can be recovered from the received primary and secondary audio mixtures, which is given by:
S
'
m
n
,
k
=
S
m
,
0
n
,
k
+
S
m
,
1
n
,
k
∀
n
,
k
(5)." See Figure 1, which illustrates decoding audio encoded data of an audio frame (e.g. "Description 1" and "Description 2") via the Channel Decoder and Audio Object Decoder).
Claim 14
Regarding claim 14, Kim et al. disclose an electronic device, comprising:
one or more processors and one or more memories, wherein:
the one or more memories are configured to store computer-executable instructions (Kim et al. ¶ [0144], "embodiments of the present invention can also be implemented through computer readable code/instructions in/on a medium, e.g., a computer readable medium, to control at least one processing element to implement any above described embodiment.")….
The remaining limitations of claim 14 are similar in scope to that of claim 1 and therefore are rejected for similar reasons as described above.
Claim 15
Regarding claim 15, the rejection of claim 14 is incorporated. The limitations of claim 15 are similar in scope to that of claim 2 and therefore are rejected for similar reasons as described above.
Claim 16
Regarding claim 16, the rejection of claim 14 is incorporated. The limitations of claim 16 are similar in scope to that of any one of claims 3 or 4 and therefore are rejected for similar reasons as described above.
Claim 17
Regarding claim 17, Kim et al. disclose an electronic device, comprising:
one or more processors and one or more memories, wherein:
the one or more memories are configured to store computer-executable instructions (Kim et al. ¶ [0144], "embodiments of the present invention can also be implemented through computer readable code/instructions in/on a medium, e.g., a computer readable medium, to control at least one processing element to implement any above described embodiment.")….
The remaining limitations of claim 17 are similar in scope to that of claim 8 and therefore are rejected for similar reasons as described above.
Claim 18
Regarding claim 18, the rejection of claim 17 is incorporated. The limitations of claim 18 are similar in scope to that of claim 2 and therefore are rejected for similar reasons as described above.
Claim 19
Regarding claim 19, Kim et al. disclose a non-transitory computer-readable storage medium having stored thereon computer-executable instructions (Kim et al. ¶ [0144], "embodiments of the present invention can also be implemented through computer readable code/instructions in/on a medium, e.g., a computer readable medium, to control at least one processing element to implement any above described embodiment.")….
The remaining limitations of claim 19 are similar in scope to that of claim 1 and therefore are rejected for similar reasons as described above.
Claim 20
Regarding claim 20, Kim et al. disclose a non-transitory computer-readable storage medium having stored thereon computer-executable instructions (Kim et al. ¶ [0144], "embodiments of the present invention can also be implemented through computer readable code/instructions in/on a medium, e.g., a computer readable medium, to control at least one processing element to implement any above described embodiment.")….
The remaining limitations of claim 20 are similar in scope to that of claim 8 and therefore are rejected for similar reasons as described above.
Claims 6-7 and 11-12 are rejected under 35 U.S.C. 103 as obvious over Zheng et al. in view of Kim et al. as applied to claims 5 and 10 above, and further in view of "Multiple Description Coding and Path Diversity for Voice Communication over MANETs" (Balam et al.) in view of “RFC 5109: RTP Payload Format for Generic Forward Error Correction." (Li).
Claim 6
Regarding claim 6, the rejection of claim 5 is incorporated.
Zheng et al. further disclose wherein the audio encoded data of the previous Nth frame is the in-band FEC data (Zheng et al. pg. 70, Section 3.1, Paragraph 3-4, "In Forward Error Correction (FEC) [9], lost data in the current packet (Primary Encoding) can be recovered in the receiver end by transmitting a degraded yet still acceptable version of the primary encoding (Secondary Encoding) in other packets. ... For instance, in Fig.2(a), the right package contains the secondary encoding for the
n
-
1
t
h
primary encoding (
S
E
i
n
-
1
), and
n
t
h
primary encoding (
P
E
i
n
). The PE sections could be regarded as the MDC descriptions with coding rate
R
P
E
from the two-description MDC model." See Figure 2(b); secondary encoding
S
E
i
n
is considered analogous to both audio encoded data of the previous Nth frame
P
E
i
n
and in-band FEC data).
Kim et al. further disclose wherein the configuration information of the bandwidth extension data comprises information indicating whether the bandwidth extension data is carried (Kim et al. ¶ [0065], "Referring to FIG. 3, code `1111`, which is a code value of "extension_type", indicates extension data for extending the channels of the audio data. ... code `0000` is a code value of "extension type" and indicates extension data for extending the bandwidth of the audio data by encoding the audio data using an SBR tool." A code that changes value based on the type of extension applied to audio data is considered analogous to configuration information comprising information indicating whether bandwidth extension data is carried).
Zheng et al. in view of Kim et al. do not explicitly disclose all of configuration information comprising one of a number or index of the at least two audio encoded streams.
However, Balam et al. disclose the configuration information of the at least two audio encoded streams comprises at least one of a number of the at least two audio encoded streams, or an index of each of the at least two audio encoded streams (Balam et al. pg. 3, Section II, Paragraph 4, "Two frame indicator bits are added to indicate the description to which the bitstream belongs and whether the frame is odd or even numbered. Bit pair ‘00’ indicates that the bitstream belongs to an odd numbered frame of description I, ‘01’ indicates description I and even frame, ‘10’ indicates description II and odd frame and ‘11’ indicates description II and even frame." See Tables I and II, which illustrate bit allocation for each description of a multiple description coding scheme. Frame indicator bits that help identify bitstreams in multiple description coding is considered analogous to an index of each of the at least two audio encoded streams)….
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Zheng et al. in view of Kim et al. to incorporate Balam et al.’s frame indicator bits because such a modification is the result of simple substitution of one known element for another producing a predictable result. More specifically, Kim et al.’s extension data codes and Balam et al.’s frame indicator bits perform the same general and predictable function, the predictable function being providing additional metadata to help contextualize payload data. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself - that is in the substitution of Kim et al.’s extension data codes by replacing it with Balam et al.’s frame indicator bits. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Zheng et al. in view of Kim et al. in view of Balam et al. do not explicitly disclose all of configuration information comprising whether in-band FEC data is carried.
However, Li discloses wherein configuration information of in-band FEC comprises information indicating whether in-band FEC data is carried (Li pg. 39, Section 14.2, Paragraph 2-4, "Because the FEC data (including the ULP header) is sent in the same packets as the protected payload, the FEC data is associated with the protected payload by being bundled in the same stream. When the FEC stream is sent as a secondary codec in the redundant encoding format, this can be signaled through [the Session Description Protocol (SDP)]. ... For example: m=audio 12345 RTP/AVP 121 0 5 100 ... This indicates that there is a single audio stream, which can consist of PCM (media format 0), DVI (media format 5), the redundant encodings (indicated by media format 121...), or FEC (media format 100...)." A Session Description Protocol is considered analogous to configuration information. The presence of "100" in the SDP is considered analogous to information indicating whether in-band FEC data is carried), wherein the audio encoded data of the previous Nth frame is the in-band FEC data (Li pg. 12, Section 7.4, Paragraph 3, "The mask field in the FEC level header indicates which packets are associated with the FEC packet at the current level.... If bit i in the mask is set to 1, then the media packet with sequence number N + i is associated with this FEC packet" An FEC packet i that is associated with packet N + i is considered analogous to audio encoding data of a previous Nth frame)….
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to modify Zheng et al. in view of Kim et al. in view of Balam et al. to incorporate Li’s FEC indication because such a modification is the result of simple substitution of one known element for another producing a predictable result. More specifically, Kim et al.’s extension data codes and Li et al.’s FEC indication perform the same general and predictable function, the predictable function being providing additional metadata to help contextualize payload data. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself - that is in the substitution of Kim et al.’s extension data codes by replacing it with Li’s FEC indication. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Claim 7
Regarding claim 7, the rejection of claim 6 is incorporated.
Kim et al. further disclose writing the control byte into the extension bitstream (Kim et al. ¶ [0072], "the bitstream formatter 240 may generate a bitstream from the payload and the codes generated by the encoding in the audio data encoding unit 200 ... and the extension data encoding unit 230, for example, and output the bitstream through an output terminal OUT."), wherein:
[the configuration information of the in-band FEC is configured for indicating that the in-band FEC data is carried, and] the configuration information of the bandwidth extension data is configured for indicating that the bandwidth extension data is carried (Kim et al. ¶ [0065], "As illustrated in FIG. 3, code `0000` is a code value of "extension type" and indicates extension data for extending the bandwidth of the audio data by encoding the audio data using an SBR tool."), in a case where the extension bitstream comprises [the in-band FEC data and] the bandwidth extension data (Kim et al. ¶ [0062], "the extension data may include at least one of data for extending the bandwidth of the audio data")….
Li further discloses writing the control byte into the extension bitstream (Li pg. 39, Section 14.2, Paragraph 3, "When the FEC stream is sent as a secondary codec in the redundant encoding format, this can be signaled through SDP. To do this, the procedures defined in RFC 2198 [7] are used to signal the use of redundant encoding."), wherein:
the configuration information of the in-band FEC is configured for indicating that the in-band FEC data is carried, [and the configuration information of the bandwidth extension data is configured for indicating that the bandwidth extension data is carried,] in a case where the extension bitstream comprises the in-band FEC data (Li pg. 39, Section 14.2, Paragraph 3-4, "When the FEC stream is sent as a secondary codec in the redundant encoding format, this can be signaled through [the Session Description Protocol (SDP)]. ... For example: m=audio 12345 RTP/AVP 121 0 5 100 ... This indicates that there is a single audio stream, which can consist of PCM (media format 0), DVI (media format 5), the redundant encodings (indicated by media format 121...), or FEC (media format 100...).") [and the bandwidth extension data]….
Claim 11
Regarding claim 11, the rejection of claim 10 is incorporated. The limitations of claim 11 are similar in scope to that of claim 6 and therefore are rejected for similar reasons as described above.
Claim 12
Regarding claim 12, the rejection of claim 11 is incorporated.
Zheng et al. further disclose wherein the decoding the at least two audio encoded streams and the extension bitstream comprises:
acquiring the [bandwidth] extension data from the extension [bitstream], and decoding the [bandwidth] extension data and the at least two audio encoded streams to obtain the audio frame (Zheng et al. pg. 69, Section 2.1, Paragraph 1, "Input audio objects from Source 1 to Source M (as shown in Fig.1), are firstly transformed into time-frequency domain using a Short Time Fourier Transform (STFT), denoted by
S
m
(
n
,
k
)
where 1≤
m
≤M and
n
and
k
are frame number and frequency index, respectively." pg. 69, Section 2.2, Paragraph 2, "the
m
t
h
(
1
≤
m
≤
M
) reconstructed audio object
S
'
m
(
n
,
k
)
can be recovered from the received primary and secondary audio mixtures, which is given by:
S
'
m
n
,
k
=
S
m
,
0
n
,
k
+
S
m
,
1
n
,
k
∀
n
,
k
(5)." The frame associated with frame number
n
is considered analogous to the audio frame. See Figure 1, which illustrates decoding extension data (e.g. "Secondary Mixture") and two audio encoded streams (e.g. "Description 1" and "Description 2") via the Channel Decoder and Audio Object Decoder), [in a case where the configuration information of the bandwidth extension data indicates that the bandwidth extension data is carried].
Kim et al. further disclose acquiring the bandwidth extension data from the extension bitstream (Kim et al. ¶ [0098]-[0099], "FIG. 7 illustrates an apparatus for decoding audio data and extension data, according to an embodiment of the present invention. ... The bitstream deformatter 700 may receive and deformat a bitstream, e.g., as transmitted from an encoding unit through an input terminal IN, and output a payload."), and decoding the bandwidth extension data (Kim et al. ¶ [0107]-[0113], "The extension data decoding unit 750 may decode extension data corresponding to the extension type code detected by the extension type code detecting unit 740. ... If the extension type code, e.g., detected by the extension type code detecting unit 740, is `0000`, an SBR data decoding portion 820 may decode extension data for extending the bandwidth of the audio data using an SBR tool, for example.") and the [at least two] audio encoded stream[s] (Kim et al. ¶ [0100], "The audio data decoding unit 710 may decode audio data in the payload output from the bitstream deformatter.") [to obtain the audio frame], in a case where the configuration information of the bandwidth extension data indicates that the bandwidth extension data is carried (Kim et al. ¶ [0065], "As illustrated in FIG. 3, code `0000` is a code value of "extension type" and indicates extension data for extending the bandwidth of the audio data by encoding the audio data using an SBR tool.").
Reference Cited
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
“Hybrid FEC and MDC Models for Low-Delay Packet-Loss Recovery” to Zheng et al. discloses a further in-depth explanation of the various MDC-FEC models described above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB B VOGT whose telephone number is (571)272-7028. The examiner can normally be reached Monday - Friday 9:30am - 7pm EST.
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, Paras D Shah can be reached at (571)270-1650. 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.
/JACOB B VOGT/Examiner, Art Unit 2653
/Paras D Shah/ Supervisory Patent Examiner, Art Unit 2653
09/28/2026
Prosecution Insights