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 .
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.
Claim(s) 1-5,13-18,20 is/are rejected under 35 U.S.C. 102s1 as being anticipated by Healey et al (US 20140294210 A1).
As per claim 1, Healey discloses 1. A method for controlling sound playing, comprising:
receiving tuning configuration information performed by a user for different channels (the settings received by a user to configure the system in fig. 5, also the information received by block 514 and 516 in fig. 5), wherein the different channels correspond to different areas inside a first device where the user is located (the channels are positioned in a vehicle receiving different sounds per the system of fig. 5 and as shown in fig. 2);
updating target sound effect parameters based on the tuning configuration information to obtain personalized sound effect parameters (the adaptation and processing of 518); and
performing tuning processing on a media stream based on the personalized sound effect parameters (parts of 518 and 520),
wherein a tuned media stream is used for sound playing (the output via 532).
As per claim 2, the method according to claim 1, before receiving the tuning configuration information performed by the user for different channels, the method further comprises:
receiving a crossover point setting instruction, and setting one or more crossover points for each area inside the first device based on the crossover point setting instruction (per the crossover function in para 33),
wherein the one or more crossover points comprise at least one of a crossover point between a bass and a midrange or a crossover point between the midrange and a treble (per the frequency based crossover in para 33).
As per claim 3, the method according to claim 1, wherein receiving the tuning configuration information performed by the user for different channels comprises:
receiving a channel merging instruction, wherein the channel merging instruction is configured to merge a plurality of channels in a same area inside the first device into one channel (the instructions for the audio that is rendered out to the speakers, which are a plurality of channels which are merges into a single channel/location in the vehicle); and
receiving tuning configuration information performed by the user for one or more channels obtained after merging (the inputs to 514 and 516 continuously obtain information and the system continuously adapts and renders audio).
As per claim 4, the method according to claim 3, wherein receiving the tuning configuration information performed by the user for the one or more channels obtained after merging comprises:
receiving a channel grouping instruction, wherein the channel grouping instruction is configured to perform left-right symmetrical grouping on the one or more channels obtained after merging (the rendering to the speakers in fig 5 must be done symmetrically so that multiple speakers can direct the audio to the specific zones/channels ) speakers ; and
receiving tuning configuration information performed by the user for one or more channel groups in a plurality of channel groups obtained after performing left-right symmetrical grouping (the inputs to 514 and 516 continuously obtain information and the system continuously adapts and renders audio).
As per claim 5, the method according to claim 1, wherein receiving the tuning configuration information performed by the user for different channels comprises:
receiving a channel grouping instruction, wherein the channel grouping instruction is configured to perform left-right symmetrical grouping on the channels corresponding to different areas inside the first device (the rendering to the speakers in fig 5 must be done symmetrically so that multiple speakers can direct the audio to the specific zones/channels ); and
receiving tuning configuration information performed by the user for one or more channel groups in a plurality of channel groups obtained after performing left-right symmetrical grouping (the inputs to 514 and 516 continuously obtain information and the system continuously adapts and renders audio).
As per claim 13, Healey discloses a method for processing sound data, comprising: receiving tuning configuration information performed by a user for different channels, wherein the different channels correspond to different areas inside a first device where the user is located (per the claim 1 rejection); and
performing authentication on the tuning configuration information, and storing tuning configuration information that has passed the authentication (para 29: the tracking module 516 may be set up so that the sound cones (or predominant direction of the sound) may be initially setup then fixed; where the initial setup is the authentication used to verify the tuning information can identify when the user moves into or out of a previously defined zone),
or
pushing tuning configuration information that has passed the authentication to a second device.
As per claim 14, the method according to claim 13, wherein performing authentication on the tuning configuration information comprises:
scoring the tuning configuration information based on an evaluation dimension to obtain scoring information, wherein the evaluation dimension comprises at least one of sound quality dimension, sound field dimension, sound image dimension, overall listening dimension, ambisonic dimension or vibration dimension; and determining whether the tuning configuration information has passed the authentication based on the scoring information (the dimensions defining whether the user has moved out of the current cone/position of sound in the car).
As per claim 15, the method according to claim 14, wherein scoring the tuning configuration information based on the evaluation dimension to obtain the scoring information comprises:
playing a test song based on the tuning configuration information (the user listening to music in the vehicle based on a current set of prefereces per para 31); and
determining a scoring score of the tuning configuration information based on a playing effect of the test song (the user can change their preferences at any time including after hearing a song/test song as is inherent to user preferences in a system, where a user changing their preferences comprises determination of a scoring score by the system that a particular user has changed their preferences and is authenticated as pbeing the current set of preferences for a particular user);
wherein determining whether the tuning configuration information has passed the authentication based on the scoring information comprises:
determining that the tuning configuration information has passed the authentication in response to the scoring score being greater than or equal to a target score threshold (the target score threshold being the user’s identity to the system as the user changes their preferences, where the system must authenticate/identify a particular user ID in the system in order to change the preferences for said user).
As per claim 16, The method according to claim 15, further comprising:
receiving a target song corresponding to the tuning configuration information;
wherein playing the test song based on the tuning configuration information comprises:
playing the target song based on the tuning configuration information; wherein determining the scoring score of the tuning configuration information based on the playing effect of the test song comprises: determining the scoring score of the tuning configuration information based on the playing effect of the target song. (the user listening to a song and then changing their preferences).
As per claim 17, the method according to claim 16, further comprising: in response to the tuning configuration information having passed the authentication, generating binding recommendation information based on the tuning configuration information and the target song (the stored user preferences after a user has set them after listening to a song that has the current set of tuning parameters applied).
As per claim 18, the method according to claim 13, wherein performing authentication on the tuning configuration information comprises: performing frequency response test and phase test on the tuning configuration information; and in response to frequency response information and phase information corresponding to the tuning configuration information conforming to a target change rule, determining that the tuning configuration information has passed the authentication.(changing the user preferences of the tuning where the tuning comprises phase and frequency modifications per para 33).
As per claim 20, the claim 1 rejection discloses An electronic device, comprising
a storage medium, a processor and a computer program stored on the storage medium and executable on the processor, wherein the processor, when executing the computer program, implements the method according to claim 1. (the system of the claim 1 rejection requires software, memory and processor in order to be implemented).
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) 6-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Healey (US 20140294210 A1).
As per claim 6, Healey discloses the method according to claim 1 and further discloses a connection to a server for support of the audio and video system of the car per para 36, but does not specify:
receiving a configuration sharing instruction, and uploading the tuning configuration information to a server
or
directly pushing the tuning configuration information to a second device based on the configuration sharing instruction.
The examiner takes official notice it was well known in the art at the time of filing to implement distributed processing via a central server and a fleet of cars, to implement the cited functions with a server for the purpose of improved processing architecture.
As per claim 7, method of claim 6, wherein after uploading the tuning configuration information to the server, the method further comprises:
performing authentication on the tuning configuration information, and storing tuning configuration information that has passed the authentication,
or
pushing tuning configuration information that has passed the authentication to the second device.
(the server connection cited in the claim 6 rejection requires authentication/handshaking for each identified client/car as part of a network protocol for the purpose of routing the data to the cited server or client/car).
As per claim 8, the method according to claim 7, wherein storing the tuning configuration information that has passed the authentication, or pushing the tuning configuration information that has passed the authentication to the second device comprises:
generating a first tuning configuration sharing code based on the tuning configuration information that has passed the authentication, wherein the first tuning configuration sharing code carries personalized sound effect parameters corresponding to the tuning configuration information that has passed the authentication (the cited server of the claim 6 rejection requires generation of a configuration sharing code/network address so that the server and car can communicate with each other, where the network addresses are typically resolved during or directly after the handshaking phase of a network connection to a server ); and
storing the first tuning configuration sharing code (the addresses and network protocol information must be stored at both the client and server in order for communication over a network to occur),
or
pushing the first tuning configuration sharing code to the second device, so as to enable a user of the second device to obtain the personalized sound effect parameters based on the first tuning configuration sharing code (alternative not mapped).
Claim(s) 9,10,11,12,19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Healey (US 20140294210 A1) as applied to claim 1,13 and further in view of Laaksonen (US 20230028238 A1).
As per claim 9, Healey discloses the method according to claim 1, but does not specify further comprising:
receiving a configuration obtaining instruction, and obtaining a second tuning configuration sharing code;
obtaining personalized sound effect parameters corresponding to tuning configuration information that has passed authentication carried in the second tuning configuration sharing code; and
displaying the personalized sound effect parameters on a user tuning interface of the first device, and
updating the target sound effect parameters based on the personalized sound effect parameters to obtain updated sound effect parameters.
Laaksonen teaches that audio devices can implement and interface where a user audio device can receive configuration information from another networked client device with an indication of available audio modes via received data per para 64. It would have been obvious to one skilled in the art at the time of filing to implement the claimed communication system into the vehicle of Healey for the purpose of improved user experience per para 64.
As such the combined system comprises:
receiving a configuration obtaining instruction, and obtaining a second tuning configuration sharing code (the network signaling between the audio system of the car and a server in order to implement the communication taught by Laaksonen) ;
obtaining personalized sound effect parameters corresponding to tuning configuration information that has passed authentication carried in the second tuning configuration sharing code (the parameters per para 64 Laak); and
displaying the personalized sound effect parameters on a user tuning interface of the first device (Laak Fig. 5), and
updating the target sound effect parameters based on the personalized sound effect parameters to obtain updated sound effect parameters (based on the user selection per the gui in Laak Fig. 5).
As per claim 10, the method according to claim 9, wherein the first device stores at least one of the target sound effect parameters, the personalized sound effect parameters or the updated sound effect parameters, and the first device supports a plurality of sound effect modes, wherein the plurality of sound effect modes comprises at least one of a mono mode, a stereo mode or an ambisonic mode (per fig. 5 Laak, also ambisonics per para 129).
As per claim 11, the method according to claim 1, wherein the first device is a first vehicle, and receiving the tuning configuration information performed by the user for different channels comprises:
obtaining current driving characteristics of the first vehicle, wherein the current driving characteristics comprise at least one of time information, driving information, vehicle state information, vehicle location information or vehicle environment information (via the sensors 514 516);
obtaining historical configuration information for different channels selected in a historical driving scenario similar to the current driving characteristics (para 65 of Laak teaches to use: based on the receiving device's network capability and/or receiving user's preference; where user preferences are historical config information);
recommending the historical configuration information to the user (the interface of Laak based on the user preferences), and
displaying the historical configuration information on a user tuning interface of the first vehicle, so as to enable the user to set parameters for different channels based on the historical configuration information (the Gui of Laak based on the user preferences); and
obtaining tuning configuration information performed by the user for different channels based on the historical configuration information (the user being located in different locations and the system obtains the tuning configuration based on the detected position and also based on the user preferences).
As per claim 12, the method according to claim 11, wherein obtaining the historical configuration information for different channels selected in the historical driving scenario similar to the current driving characteristics comprises:
calculating a similarity between the current driving characteristics with sample driving characteristics when historically selecting a channel configuration, wherein the sample driving characteristics comprise at least one of time information, driving information, vehicle state information, vehicle location information or vehicle environment information during historical driving processes (the system monitors and responds dynamically based on the sensors, as such it uses historical information, ie. The current settings, to decide what to do, ie. To adapt or not to adapt, based on the historical/current settings and parameters being applied) (additionally, each of the processes cited above in the claim 1 rejection require clocking information/time information for the purpose of being synchronized in a digital processor based system) ; and
obtaining the historical configuration information for different channels corresponding to sample driving characteristics with similarity greater than a target threshold (the preferences received as taught by Laak para 65 have a indication of a particular user, which is based on the indication of a user being greater than a threshold required to identify said user to the system).
As per claim 19, the method according to claim 13, wherein storing the tuning configuration information that has passed the authentication, or pushing the tuning configuration information that has passed the authentication to the second device comprises:
generating a first tuning configuration sharing code based on the tuning configuration information that has passed the authentication, wherein the first tuning configuration sharing code carries personalized sound effect parameters corresponding to the tuning configuration information that has passed the authentication; and
storing the first tuning configuration sharing code, or pushing the first tuning configuration sharing code to the second device to, so as enable a user of the second device to obtain the personalized sound effect parameters based on the first tuning configuration sharing code.
(per the claim 9 rejection as taught by Laak, the parameters to implement the communications function in said rejection).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEXANDER KRZYSTAN whose telephone number is 571-272-7498, and whose email address is alexander.krzystan@uspto.gov
The examiner can usually be reached on m-f 7:30-4:00 est.
If attempts to reach the examiner by telephone or email are unsuccessful, the examiner’s supervisor, Carolyn Edwards can be reached on (571) 270-7136.
The fax phone numbers for the organization where this application or proceeding is assigned are 571-273-8300 for regular communications and 571-273-8300 for After Final communications.
/ALEXANDER KRZYSTAN/Primary Examiner, Art Unit 2653
Examiner Alexander Krzystan
September 9, 2026
Prosecution Insights