DETAILED ACTION
This action is in response to the application filed on June 28th, 2024. 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 .
Specification
The use of the term "Bluetooth", which is a trade name or a mark used in commerce, has been noted in this application in the abstract, drawings, and specification. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
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.
Claims 1-20 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.
Regarding claims 1, 4, 9, 11, 15, and 18, the claims contain the trademark/trade name Bluetooth. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a specific wireless communication technology and, accordingly, the identification/description is indefinite.
Regarding claims 2-3, 5-8, 10, 12-14, 16-17, and 19-20, each of these claims depend on one of the independent claims 1, 9, or 15 either directly or indirectly, and therefore incorporate all limitations therefrom. As such, claims 2-3, 5-8, 10, 12-14, 16-17, and 19-20 are rejected for the same reasons as stated above with regards to claims 1, 4, 9, 11, 15, and 18.
Further regarding claims 5 and 19, the claims are generally narrative and indefinite, failing to conform with current U.S. practice. They appear to be a literal translation into English from a foreign document and are replete with grammatical and idiomatic errors. In particular, it is unclear what the language “wherein each fourth codec format in the codec format set is of a third media file” is meant to describe. For the purposes of examination, the limitation will be interpreted as determining a set of codec formats that are supported by both the transmitter and the receiver.
Further regarding claims 6, 12, and 20, based on the language “the at least one first codec format comprises”, it appears that these claims should present an “or” list of potential codec formats, rather than an “and” list of required codec formats. For examination purposes, these claims will be interpreted as “or” lists.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Liang (US Pat. Pub. No. 2022/0148608 A1 hereinafter Wang), in view of Muthiah, Ramanathan (US Pat. Pub. No. 2022/0182694 A1 hereinafter Muthiah.
Regarding claim 1, Wang discloses a method implemented by a transmitter, wherein the method comprises: performing a BLUETOOTH capability negotiation with a receiver to determine that the transmitter and the receiver support an adaptive coding protocol, wherein the adaptive coding protocol enables the transmitter to send first media files in different codec formats to the receiver via BLUETOOTH (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); determining at least one first codec format that is supported by the receiver (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits."); establishing an Advanced Audio Distribution Profile (A2DP) BLUETOOTH connection to the receiver (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology."). However, Wang fails to expressly recite determining a second codec format of a second media file; and sending the second media file to the receiver when the at least one first codec format comprises the second codec format, wherein first media data in the second media file comprises a first indication indicating the second codec format.
Muthiah teaches determining a second codec format of a second media file; and sending the second media file to the receiver when the at least one first codec format comprises the second codec format, wherein first media data in the second media file comprises a first indication indicating the second codec format (Muthiah, fig. 5, 520 and 522; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522.").
Wang and Muthiah are analogous arts because they both belong to the same field of endeavor of media transmission. 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 the audio coding scheme switching method of Wang to incorporate the teachings of Muthiah to determine a codec format of a file and if the file needs to be transcoded prior to transmission. Variably transcoding a media file allows the file to be transferred to various different devices (Muthiah, [0011]). This ensures that media files can be accessed by users of many different systems, which improves the user’s experience interacting with the media.
PNG
media_image1.png
727
593
media_image1.png
Greyscale
Wang, Fig. 7, for reference
PNG
media_image2.png
867
554
media_image2.png
Greyscale
Muthiah, Fig. 5, for reference
Regarding claim 2, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches determining a third codec format of a third media file; and sending the third media file to the receiver when the at least one first codec format comprises the third codec format, wherein second media data in the third media file comprises a second indication indicating the third codec format, and wherein the third codec format is different from the second codec format (Muthiah, fig. 5, 520 and 522; [0061]: "At block 515, responsive to determining that the request includes codec preferences, the storage device determines if it is capable of transcoding the media file using one or more of the specified codecs in the codec preferences. In some embodiments, the codec preferences include a single codec rather than a list of codecs. In such embodiments, the storage device is configured to determine whether it is capable of transcoding the media file using the specified codec. In some embodiments, the codec preferences include a prioritized list of codecs. In such embodiments, the storage device is configured to select from the prioritized list a codec."; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522."). The same motivation for claim 1 applies equally to claim 2.
Regarding claim 3, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches identifying that the at least one first codec format does not comprise the second codec format; transcoding the second media file in the second codec format to obtain a third media file in a third codec format in response to identifying that the at least one first codec format does not comprise the second codec format, wherein the at least one first codec format comprises the third codec format (Muthiah, fig. 5, 520 and 545; [0062]: "As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522. Otherwise, the storage device is configured to transcode the media file based on the parameters determined at block 510 and at block 515."); and sending the third media file to the receiver, wherein second media data in the third media file comprises a second indication indicating the third codec format (Muthiah, fig. 5, 525-545; [0063]: "At block 525, the storage device determines what to do with the transcoded file. The storage device can be configured to replace the original media file with the transcoded file at block 530. The storage device can be configured to store the transcoded file alongside the original media file at block 535. The storage device can be configured to add the transcoded data to the original media data in a single file at block 540. The storage device can be configured to discard the transcoded data after transferring to the client device at block 545."). The same motivation for claim 1 applies equally to claim 3.
Regarding claim 4, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses establishing a BLUETOOTH connection to the receiver; sending a request to the receiver, wherein the request queries whether the receiver supports the adaptive coding protocol (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); and receiving a response from the receiver, wherein the response comprises a second indication indicating that the receiver supports the adaptive coding protocol and further comprises the at least one first codec format (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits.").
Regarding class 5, the rejection of claim 4 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses determining at least one third codec format locally supported by the transmitter (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits."); and determining a codec format set, wherein each fourth codec format in the codec format set is of a third media file and is supported by both the transmitter and the receiver (Wang, fig. 7; [0137]: "In an implementation, the source side may select a parameter supported by both the source side and the playback side as the configuration parameter. For example, the source side determines that the configuration parameter is as follows: a Bluetooth audio codec type is HWA, an audio sampling rate is 44.1 kHz. and an audio bit width is 16 bits.").
Regarding claim 6, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the at least one first codec format comprises sub-band coding (SBC), Moving Picture Experts Group (MPEG)-1,2 Audio, MPEG-2,4 Advanced Audio Coding (AAC), Adaptive Transform Acoustic Coding (ATRAC) family, Free Lossless Audio Codec (FLAC), Opus, Vorbis, and Monkey's Audio (Wang, [0007]: "With reference to the first aspect, in a possible design manner, the Bluetooth coding scheme includes a high sound quality mode, a standard mode, or a low latency mode. The high sound quality mode includes at least one of LDAC, aptX HD, and HWA. The standard mode includes at least one of sub-band coding SBC, advanced audio coding AAC, and aptX. The low latency mode includes at least one of HWA LL and aptX LL.").
Regarding claim 7, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the second media file is an audio file (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology.").
Regarding claim 8, the rejection of claim 1 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches wherein the second media file is a video file (Muthiah, [0062]: "As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522.").
Regarding claim 9, Wang discloses a method implemented by a receiver, wherein the method comprises: performing a BLUETOOTH capability negotiation with a transmitter to determine that the receiver and the transmitter support an adaptive coding protocol, wherein the adaptive coding protocol enables the transmitter to send first media files in different codec formats to the receiver via BLUETOOTH (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); sending to the transmitter at least one first codec format supported by the receiver (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits."); establishing an Advanced Audio Distribution Profile (A2DP) BLUETOOTH connection to the transmitter (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology."). However, Wang fails to expressly recite receiving a second media file from the transmitter, wherein first media data in the second media file comprises a first indication indicating a second codec format, and wherein the at least one first codec format comprises the second codec format.
Muthiah teaches receiving a second media file from the transmitter, wherein first media data in the second media file comprises a first indication indicating a second codec format, and wherein the at least one first codec format comprises the second codec format (Muthiah, fig. 5, 520 and 522; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522.").
Wang and Muthiah are analogous arts because they both belong to the same field of endeavor of media transmission. 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 the audio coding scheme switching method of Wang to incorporate the teachings of Muthiah to determine a codec format of a file and if the file needs to be transcoded prior to transmission. Variably transcoding a media file allows the file to be transferred to various different devices (Muthiah, [0011]). This ensures that media files can be accessed by users of many different systems, which improves the user’s experience interacting with the media.
Regarding claim 10, the rejection of claim 9 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches receiving a third media file, wherein second media data in the third media file comprises a second indication indicating a third codec format of the third media file, wherein the third codec format is different from the second codec format, and wherein the at least one first codec format comprises the third codec format (Muthiah, fig. 5, 520 and 522; [0061]: "At block 515, responsive to determining that the request includes codec preferences, the storage device determines if it is capable of transcoding the media file using one or more of the specified codecs in the codec preferences. In some embodiments, the codec preferences include a single codec rather than a list of codecs. In such embodiments, the storage device is configured to determine whether it is capable of transcoding the media file using the specified codec. In some embodiments, the codec preferences include a prioritized list of codecs. In such embodiments, the storage device is configured to select from the prioritized list a codec."; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522."). The same motivation for claim 9 applies equally to claim 10.
Regarding claim 11, the rejection of claim 9 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses establishing a BLUETOOTH connection to the transmitter; receiving a request from the transmitter, wherein the request queries whether the receiver supports the adaptive coding protocol (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); and sending a response to the transmitter, wherein the response comprises a second indication indicating that the receiver supports the adaptive coding protocol and further comprises the at least one first codec format (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits.").
Regarding claim 12, the rejection of claim 9 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the at least one first codec format comprises sub-band coding (SBC), Moving Picture Experts Group (MPEG)-1,2 Audio, MPEG-2,4 Advanced Audio Coding (AAC), Adaptive Transform Acoustic Coding (ATRAC) family, Free Lossless Audio Codec (FLAC), Opus, Vorbis, and high-quality music converter (Monkey's Audio(.ape)) (Wang, [0007]: "With reference to the first aspect, in a possible design manner, the Bluetooth coding scheme includes a high sound quality mode, a standard mode, or a low latency mode. The high sound quality mode includes at least one of LDAC, aptX HD, and HWA. The standard mode includes at least one of sub-band coding SBC, advanced audio coding AAC, and aptX. The low latency mode includes at least one of HWA LL and aptX LL.").
Regarding claim 13, the rejection of claim 9 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the second media file is an audio file (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology.").
Regarding claim 14, the rejection of claim 9 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches wherein the second media file is a video file (Muthiah, [0062]: "As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522."). The same motivation for claim 9 applies equally to claim 14.
Regarding claim 15, Wang discloses a transmitter comprising: a memory configured to store instructions; and at least one processor coupled to the memory and configured to execute the instructions to cause the transmitter to: perform a BLUETOOTH capability negotiation with a receiver to determine that the transmitter and the receiver support an adaptive coding protocol, wherein the adaptive coding protocol enables the transmitter to send first media files in different codec formats to the receiver via BLUETOOTH (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); determine at least one first codec format that is supported by the receiver (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits."); establish an Advanced Audio Distribution Profile (A2DP) BLUETOOTH connection between the transmitter and the receiver (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology."). However, Wang fails to expressly recite determine a second codec format of a second media file; and send the second media file to the receiver when the at least one first codec format comprises the second codec format, wherein first media data in the second media file comprises a first indication indicating the second codec format.
Muthiah teaches determine a second codec format of a second media file; and send the second media file to the receiver when the at least one first codec format comprises the second codec format, wherein first media data in the second media file comprises a first indication indicating the second codec format (Muthiah, fig. 5, 520 and 522; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522.").
Wang and Muthiah are analogous arts because they both belong to the same field of endeavor of media transmission. 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 the audio coding scheme switching method of Wang to incorporate the teachings of Muthiah to determine a codec format of a file and if the file needs to be transcoded prior to transmission. Variably transcoding a media file allows the file to be transferred to various different devices (Muthiah, [0011]). This ensures that media files can be accessed by users of many different systems, which improves the user’s experience interacting with the media.
Regarding claim 16, the rejection of claim 15 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches wherein the at least one processor is further configured to execute the instructions to cause the transmitter to: determine a third codec format of a third media file; and send the third media file to the receiver when the at least one first codec format comprises the third codec format, wherein second media data in the third media file comprises a second indication indicating the third codec format, and wherein the third codec format is different from the second codec format (Muthiah, fig. 5, 520 and 522; [0061]: "At block 515, responsive to determining that the request includes codec preferences, the storage device determines if it is capable of transcoding the media file using one or more of the specified codecs in the codec preferences. In some embodiments, the codec preferences include a single codec rather than a list of codecs. In such embodiments, the storage device is configured to determine whether it is capable of transcoding the media file using the specified codec. In some embodiments, the codec preferences include a prioritized list of codecs. In such embodiments, the storage device is configured to select from the prioritized list a codec."; [0062]: "At block 520, the storage device determines the necessity of generating a transcoded file based on the results of the analysis at block 510 or at block 515. If, for example, the media file is compatible with the parameters in the client request, then the storage device is configured to not transcode the file. As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522."). The same motivation for claim 15 applies equally to claim 16.
Regarding claim 17, the rejection of claim 15 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Muthiah further teaches wherein the at least one processor is further configured to execute the instructions to cause the transmitter to: identify that the at least one first codec format does not comprise the second codec format; transcode the second media file in the second codec format to obtain a third media file in a third codec format in response to identifying that the at least one first codec format does not comprise the second codec format, wherein the at least one first codec format comprises the third codec format (Muthiah, fig. 5, 520 and 545; [0062]: "As another example, if the media file includes an audio and video codec from the list of preferred codecs than the storage device is configured to not transcode the file. In such instances, the storage device transfers the original media file at block 522. Otherwise, the storage device is configured to transcode the media file based on the parameters determined at block 510 and at block 515."); and send the third media file to the receiver, wherein second media data in the third media file comprises a second indication indicating the third codec format (Muthiah, fig. 5, 525-545; [0063]: "At block 525, the storage device determines what to do with the transcoded file. The storage device can be configured to replace the original media file with the transcoded file at block 530. The storage device can be configured to store the transcoded file alongside the original media file at block 535. The storage device can be configured to add the transcoded data to the original media data in a single file at block 540. The storage device can be configured to discard the transcoded data after transferring to the client device at block 545."). The same motivation for claim 15 applies equally to claim 17.
Regarding claim 18, the rejection of claim 15 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the at least one processor is further configured to execute the instructions to cause the transmitter to: establish a BLUETOOTH connection to the receiver; send a request to the receiver, wherein the request queries whether the receiver supports the adaptive coding protocol (Wang, fig. 7; [0135]: "For example, the audio coding module sends a capability obtaining request to the playback side by using the Bluetooth unit, to request to obtain capability information of the playback side. For example, the capability information may include a supported Bluetooth audio codec type (or a bit rate of the Bluetooth audio codec), an audio sampling rate, an audio bit width, and the like."); and receive a response from the receiver, wherein the response comprises a second indication indicating that the receiver supports the adaptive coding protocol and further comprises the at least one first codec format (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits.").
Regarding claim 19, the rejection of claim 18 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the at least one processor is further configured to execute the instructions to cause the transmitter to: determine at least one third codec format locally supported by the transmitter (Wang, fig. 7; [0137]: "The source side determines a configuration parameter based on the capability information of the playback side. For example, the capability information of the playback side is: supported Bluetooth audio codec types including HWA, aptX, aptX HD, aptX LL, and AAC; supported audio sampling rates including 48 kHz, 44.1 kHz, 32 kHz, 24 kHz, and 16 kHz; and supported audio bit widths including 8 bits and 16 bits."); and determine a codec format set, wherein each fourth codec format in the codec format set is of a third media file and is supported by both the transmitter and the receiver (Wang, fig. 7; [0137]: "In an implementation, the source side may select a parameter supported by both the source side and the playback side as the configuration parameter. For example, the source side determines that the configuration parameter is as follows: a Bluetooth audio codec type is HWA, an audio sampling rate is 44.1 kHz. and an audio bit width is 16 bits.").
Regarding claim 20, the rejection of claim 15 is incorporated. Wang, in view of Muthiah, discloses all of the elements of the current invention as stated above. Wang further discloses wherein the at least one first codec format comprises sub-band coding (SBC), Moving Picture Experts Group (MPEG)-1,2 Audio, MPEG-2,4 Advanced Audio Coding (AAC), Adaptive Transform Acoustic Coding (ATRAC) family, Free Lossless Audio Codec (FLAC), Opus, Vorbis, and Monkey's Audio (Wang, [0007]: "With reference to the first aspect, in a possible design manner, the Bluetooth coding scheme includes a high sound quality mode, a standard mode, or a low latency mode. The high sound quality mode includes at least one of LDAC, aptX HD, and HWA. The standard mode includes at least one of sub-band coding SBC, advanced audio coding AAC, and aptX. The low latency mode includes at least one of HWA LL and aptX LL."), and wherein the second media file is an audio file or a video file (Wang, fig. 7; [0132]: "FIG. 7 shows a method procedure in which audio on the source side is played by the playback side by using an A2DP playback technology.").
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Leung et al. (US Pat. Pub. No. 2017/0006078 A1) discloses methods for codec negotiation in decentralized multimedia conferences.
Swaminathan, Arvind (US Pat. No. 12,022,057 B1) discloses systems for dynamically selecting codecs.
Ryu, Kyu Sang (US Pat. Pub. No. 2017/0026780 A1), Park et al. (US Pat. Pub. No. 2016/0142865 A1), Plisson, Damien (US Pat. Pub. No. 2019/0174154 A1), and Girardier et al. (US Pat. Pub. No. 2021/0160673 A1) each disclose one or multiple of the codec formats described in claims 6, 12, and 20.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TYLER J BECKER whose telephone number is (703)756-1271. The examiner can normally be reached M-Th, 7:15am-5:45pm PT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel Washburn can be reached at (571) 272-5551. 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.
/TYLER BECKER/ Examiner, Art Unit 2657
/DANIEL C WASHBURN/ Supervisory Patent Examiner, Art Unit 2657
Prosecution Insights