DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-6, 8-13, 15-19, and 21-23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-3, 5-6, 8-10, 12-13, 15-17, 19, and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muench et al. (US 2014/0029771 A1, previously cited and hereafter Muench) in view of Akama et al. (US 2016/0212254 A1, previously cited and hereafter Akama), and further in view of Mathur (US 2018/0088897 A1, previously cited).
Regarding claim 1, Muench discloses a system and method for switching between multiple audio input signals, where prior to switching the first audio input signal is muted, the output is switched to the second audio signal, and then the second audio signal is unmuted after switching (see Muench, abstract).
Muench teaches:
“A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to performs operations” (see Muench, ¶ 0026) “comprising:
receiving, while a speaker outputs audio from a first application, an instruction to output audio from a second application” because an input select signal (iss) is received while the system outputs the ‘undesired signal’ (see Muench, ¶ 0014-0015 and 0018, figure 1, units 1-2, 4, 10, and ‘iss’, and figure 2, ‘undesired signal’); [and]
“muting audio output from the speaker in response to receiving the instruction” because the change detector and mute control attenuates the ‘undesired signal’ in response to the iss instruction (see Muench, ¶ 0016 and 0018, figure 1, units 2, 6-7, and ‘iss’, and figure 2, ‘mute’).
However, Muench does not appear to teach the features for:
“instructing the first application to deactivate audio transmission” and “instructing the second application to activate audio transmission”.
Akama teaches a control program for a mobile terminal to communicate with an onboard device mounted in a vehicle (see Akama, abstract, ¶ 0014, 0032-0033, and 0036 and figure 1). Herein, Akama teaches control of applications on the mobile terminal (e.g., smartphone) from a vehicle mounted switch such that an application executed on the smartphone that provides audio is smoothly switched to another audio providing application (see Akama, ¶ 0018, 0033, and 0036). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to modify the teachings of Muench with the teachings of Akama for smoothly switching audio sources provided from a wirelessly connected smartphone (see Muench, ¶ 0019 and figure 3, units 13-16, in view of Akama, ¶ 0034-0036 and figure 1).
Therefore, the combination of Muench and Akima makes obvious the features for:
“instructing an amplifier in communication with the speaker to associate a second channel with the second application” by making obvious a wireless communication with another device, such as a smartphone that provides an audio signal for output in the vehicle (see Muench, ¶ 0019 and figure 3, units 13-16, in view of Akama, ¶ 0034-0036, 0038-0040, and 0055-0056 and figure 2); and
“instructing the first application to deactivate audio transmission” by making it obvious to stop, or pause, the playback of the first application before switching the audio (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 336).
The combination makes obvious the features for “instructing the amplifier to switch a speaker input from a first channel associated with the first application to the second channel”, where Akama teaches that the switch takes place after stopping the audio from the first application (see Akama, ¶ 0092-0093). However, the combination of Muench and Akama does not appear to teach the features for “instructing the amplifier to switch a speaker input from a first channel associated with the first application to the second channel after instructing the first application to deactivate audio transmission”.
Mathur discloses a multi source wireless headphone and audio switching device (see Mathur, abstract and figures 1-6). Herein, Mathur teaches alternative methods of switching different audio sources for the wireless headphone output using an audio switching device (see Mathur, ¶ 0003-0004). Mathur illustrates the method of switching where the headphone is receiving audio from a first device when the instruction to switch is received (see Mathur, figure 4, steps 102 and 104, and ¶ 0037-0038). The method of switching instructs the first device to disable audio playback before switching to the second device for playback (see Mathur, figure 4, steps 104, 106, and 108, and ¶ 0038-0040). It would have been obvious to one of ordinary skill in the art (OOSITA) at the time of the effective filing date to modify the combination of Muench and Akama with the teachings of Mathur where OOSITA would expect similar results with a change in the order of operations, such that the playback would switch from the first application to the second application as the user desired (see Muench, ¶ 0019 and figure 3, units 13-16, in view of Akama, ¶ 0034-0036 and figure 1, and further in view of Mathur, ¶ 0004).
Therefore, the combination of Muench, Akima, and Mathur makes obvious the features for:
“instructing the amplifier to switch a speaker input from a first channel associated with the first application to the second channel after instructing the first application to deactivate audio transmission” because the switch unit receives a delay instruction, such as the switch control signal (scs) derived from the iss instruction, and the input is switched from the source providing the ‘undesired signal’ to another source providing the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 1-2 and ‘scs’, and figure 2, ‘switching’; and see Akama, ¶ 0033 and figure 1, unit 100), and further makes obvious that the first application is instructed to deactivate transmission before switching to the second channel for the second application (see Mathur, figure 4, steps 104, 106, and 108, and ¶ 0038-0040);
“instructing the second application to activate audio transmission” by making obvious the instruction to start playback of the second application (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 338); and
“unmuting the audio output from the speaker” because the mute control signal (mcs), which was also derived from the iss instruction, unmutes the ‘desired signal’ after the switch from the ‘undesired signal’ to the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 2, 7, and ‘mcs’, and figure 2, ‘hard unmute’, ‘soft unmute’, and ‘desired signal’).
Regarding claim 2, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the muting the audio output from the speaker includes at least one of suppressing audio transmission from the first application, suppressing audio transmission to the amplifier, or instructing the amplifier to set a speaker volume to zero” by teaching that the volume is set to zero (see Muench, ¶ 0018).
Regarding claim 3, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the instructing the first application to deactivate audio transmission is performed after the instructing the amplifier to associate the second channel with the second application” where it is obvious to switch to the second audio source when the second audio is available to be heard, and in turn makes it obvious to stop the first application after the second application audio is available (see Muench, ¶ 0018 and 0020, in view of Akama, ¶ 0014 and 0092-0093 and figure 5).
Regarding claim 5, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the first application and the second application are any combination of flutter applications and non-flutter applications” by teaching non-flutter applications (i.e., applications that produce constant audio streams), such as radio, CD, etc. (see Muench, ¶ 0014 and figure 1), and making obvious flutter applications (i.e., applications that produce intermittent audio), such as a car navigation application (see Akama, ¶ 0036).
Regarding claim 6, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the amplifier receives instructions and audio transmissions through a digital interface” by making obvious digital wired and wireless communication (see Akama, ¶ 0038-0040 and 0055-0056 and figure 2, units 210, 220, 310, and 320).
Regarding claim 8, see the preceding rejection with respect to claim 1 above. The combination of Muench, Akama, and Mathur makes obvious the non-transitory computer-readable medium of claim 1, and for the same reasons makes obvious:
“A method comprising:
receiving, while a speaker outputs audio from a first application, an instruction to output audio from a second application” because an input select signal (iss) is received while the system outputs the ‘undesired signal’ (see Muench, ¶ 0014-0015 and 0018, figure 1, units 1-2, 4, 10, and ‘iss’, and figure 2, ‘undesired signal’);
“muting audio output from the speaker in response to receiving the instruction” because the change detector and mute control attenuates the ‘undesired signal’ in response to the iss instruction (see Muench, ¶ 0016 and 0018, figure 1, units 2, 6-7, and ‘iss’, and figure 2, ‘mute’);
“instructing an amplifier in communication with the speaker to associate a second channel with the second application” by making obvious a wireless communication with another device, such as a smartphone that provides an audio signal for output in the vehicle (see Muench, ¶ 0019 and figure 3, units 13-16, in view of Akama, ¶ 0034-0036, 0038-0040, and 0055-0056 and figure 2);
“instructing the first application to deactivate audio transmission” by making it obvious to stop, or pause, the playback of the first application before switching the audio (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 336);
“instructing the amplifier to switch a speaker input from a first channel associated with the first application to the second channel after instructing the first application to deactivate audio transmission” because the switch unit receives a delay instruction, such as the switch control signal (scs) derived from the iss instruction, and the input is switched from the source providing the ‘undesired signal’ to another source providing the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 1-2 and ‘scs’, and figure 2, ‘switching’; and see Akama, ¶ 0033 and figure 1, unit 100), and further makes obvious that the first application is instructed to deactivate transmission before switching to the second channel for the second application (see Mathur, figure 4, steps 104, 106, and 108, and ¶ 0038-0040);
“instructing the second application to activate audio transmission” by making obvious the instruction to start playback of the second application (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 338); and
“unmuting the audio output from the speaker” because the mute control signal (mcs), which was also derived from the iss instruction, unmutes the ‘desired signal’ after the switch from the ‘undesired signal’ to the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 2, 7, and ‘mcs’, and figure 2, ‘hard unmute’, ‘soft unmute’, and ‘desired signal’).
Regarding claim 9, see the preceding rejection with respect to claim 8 above. The combination makes obvious the “method of claim 8, wherein the muting the audio output from the speaker includes at least one of suppressing audio transmission from the first application, suppressing audio transmission to the amplifier, or instructing the amplifier to set a speaker volume to zero” by teaching that the volume is set to zero (see Muench, ¶ 0018).
Regarding claim 10, see the preceding rejection with respect to claim 8 above. The combination makes obvious the “method of claim 8, wherein the instructing the first application to deactivate audio transmission is performed after the instructing the amplifier to associate the second channel with the second application” where it is obvious to switch to the second audio source when the second audio is available to be heard, and in turn makes it obvious to stop the first application after the second application audio is available (see Muench, ¶ 0018 and 0020, in view of Akama, ¶ 0014 and 0092-0093 and figure 5).
Regarding claim 12, see the preceding rejection with respect to claim 8 above. The combination makes obvious the “method of claim 8, wherein the first application and the second application are any combination of flutter applications and non-flutter applications” by teaching non-flutter applications (i.e., applications that produce constant audio streams), such as radio, CD, etc. (see Muench, ¶ 0014 and figure 1), and making obvious flutter applications (i.e., applications that produce intermittent audio), such as a car navigation application (see Akama, ¶ 0036).
Regarding claim 13, see the preceding rejection with respect to claim 8 above. The combination makes obvious the “method of claim 8, wherein the amplifier receives instructions and audio transmissions through a digital interface” by making obvious digital wired and wireless communication (see Akama, ¶ 0038-0040 and 0055-0056 and figure 2, units 210, 220, 310, and 320).
Regarding claim 15, see the preceding rejection with respect to claim 1 above. The combination of Muench and Akama makes obvious the non-transitory computer-readable medium of claim 1, and for the same reasons makes obvious:
“A device comprising:
a controller including circuitry configured to perform operations including” (see Muench, ¶ 0026; and see Akama, figure 2):
“receiving, while a speaker outputs audio from a first application, an instruction to output audio from a second application” because an input select signal (iss) is received while the system outputs the ‘undesired signal’ (see Muench, ¶ 0014-0015 and 0018, figure 1, units 1-2, 4, 10, and ‘iss’, and figure 2, ‘undesired signal’);
“muting audio output from the speaker in response to receiving the instruction” because the change detector and mute control attenuates the ‘undesired signal’ in response to the iss instruction (see Muench, ¶ 0016 and 0018, figure 1, units 2, 6-7, and ‘iss’, and figure 2, ‘mute’);
“instructing an amplifier in communication with the speaker to associate a second channel with the second application” by making obvious a wireless communication with another device, such as a smartphone that provides an audio signal for output in the vehicle (see Muench, ¶ 0019 and figure 3, units 13-16, in view of Akama, ¶ 0034-0036, 0038-0040, and 0055-0056 and figure 2);
“instructing the first application to deactivate audio transmission” by making it obvious to stop, or pause, the playback of the first application before switching the audio (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 336);
“instructing the amplifier to switch a speaker input from a first channel associated with the first application to the second channel after instructing the first application to deactivate audio transmission” because the switch unit receives a delay instruction, such as the switch control signal (scs) derived from the iss instruction, and the input is switched from the source providing the ‘undesired signal’ to another source providing the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 1-2 and ‘scs’, and figure 2, ‘switching’; and see Akama, ¶ 0033 and figure 1, unit 100), and further makes obvious that the first application is instructed to deactivate transmission before switching to the second channel for the second application (see Mathur, figure 4, steps 104, 106, and 108, and ¶ 0038-0040);
“instructing the second application to activate audio transmission” by making obvious the instruction to start playback of the second application (see Muench, ¶ 0018 and figure 2, in view of Akama, ¶ 0014 and 0078-0079 and figure 4, units 338); and
“unmuting the audio output from the speaker” because the mute control signal (mcs), which was also derived from the iss instruction, unmutes the ‘desired signal’ after the switch from the ‘undesired signal’ to the ‘desired signal’ (see Muench, ¶ 0014-0015 and 0017-0018, figure 1, units 2, 7, and ‘mcs’, and figure 2, ‘hard unmute’, ‘soft unmute’, and ‘desired signal’).
Regarding claim 16, see the preceding rejection with respect to claim 15 above. The combination makes obvious the “device of claim 15, wherein the muting the audio output from the speaker includes at least one of suppressing audio transmission from the first application, suppressing audio transmission to the amplifier, or instructing the amplifier to set a speaker volume to zero” by teaching that the volume is set to zero (see Muench, ¶ 0018).
Regarding claim 17, see the preceding rejection with respect to claim 15 above. The combination makes obvious the “device of claim 15, wherein the instructing the first application to deactivate audio transmission is performed after the instructing the amplifier to associate the second channel with the second application” where it is obvious to switch to the second audio source when the second audio is available to be heard, and in turn makes it obvious to stop the first application after the second application audio is available (see Muench, ¶ 0018 and 0020, in view of Akama, ¶ 0014 and 0092-0093 and figure 5).
Regarding claim 19, see the preceding rejection with respect to claim 15 above. The combination makes obvious the “device of claim 15, wherein the amplifier is configured to receive instructions and audio transmissions through a digital interface” by making obvious digital wired and wireless communication (see Akama, ¶ 0038-0040 and 0055-0056 and figure 2, units 210, 220, 310, and 320).
Regarding claim 21, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the instruction to output audio from the second application is received from an arbitration manager in response to the arbitration manager determining that the second application has priority over the first application” where Akama makes obvious that the system responds to switching applications based on priorities of the sound output of the applications (see Akama, ¶ 0067-0068, 0076, 0112, and 0121).
Regarding claim 22, see the preceding rejection with respect to claim 1 above. The combination makes obvious the “computer-readable medium of claim 1, wherein the second channel differs from the first channel in at least one of an audio bitrate, sampling rate, or buffer size” by making obvious digital audio formats, such as mp3 and/or well-known audio formats, are played from the smartphone applications through the onboard device in the vehicle, and this makes obvious that the second channel has at least an audio bitrate and sampling rate that is different from the first channel at least when different audio formats are reproduced on the different channels, and the digital communication standards imply a buffer size for well-known decoding and transmitting features (see Muench, ¶ 0020 and see Akama, ¶ 0036 and 0069).
Allowable Subject Matter
Claims 4, 11, 18, and 23 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Heddle et al. (US 5,703,794 A, previously cited, and hereafter Heddle) discloses a method and system for mixing audio streams in a computing system (see Heddle, abstract), and teaches an audio mixer that mutes audio streams from an application that has lost a ‘sound focus’ and sends audio streams from a new application to the sound card for output (see Heddle, column 2, lines 32-47);
Bhattacharya et al. (US 6,983,464 B1, previously cited, and hereafter Bhattacharya) discloses a dynamic reconfiguration of multimedia stream processing modules (see Bhattacharya, abstract and figures 1-7);
Kimura (US 2005/0080500 A1, previously cited) discloses an audio device and playback method in an audio device for muting an output of an audio amplifier when a change of an audio attribute is detected (see Kimura, abstract and figures 1-6); and
Kindo (US 2012/0196583 A1) discloses a vehicle-mounted device, such as a navigation device, with wireless connectivity with a mobile phone (see Kindo, abstract, ¶ 0001 and 0053 and figure 1), and Kindo discloses the steps of a signaling method between the devices when new mail is received and read out loud, where the devices provide responses to commands to pause or stop an audio stream (see Kindo, ¶ 0382-0401 and figure 17).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Daniel R Sellers whose telephone number is (571)272-7528. The examiner can normally be reached Mon - Fri 10:00-4:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fan S Tsang can be reached at (571)272-7547. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Daniel R Sellers/Primary Examiner, Art Unit 2694