Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . See 35 U.S.C. § 100 (note).
The double-patenting rejections based on US 18/754,850 and US 18/754,407 have been withdrawn in light of amendments made in the applications. Since the ‘850 Application and the ‘407 Application and this Application are still pending, the withdrawal of the rejections does not constitute a waiver of any future double patenting rejections.
Art Rejections
Anticipation
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1–4, 6–9 and 11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Keyboard Maestro Wiki, https://web.archive.org/web/20191020144930/https://wiki.keyboardmaestro.com/Home_Page (archived 18-23 October 2019) (last accessed 26 June 2026) (“Maestro”).1
Claim 1 is drawn to “a sound apparatus.” The following table illustrates the correspondence between the claimed sound apparatus and the Maestro reference.
Claim 1
The Maestro Reference
“1. A[n] audio mixer comprising:
“an acoustic device; and
“a controller that is configured to
The Maestro reference describes a program executed by a personal computer, like a Mac-branded computer. Maestro at pp. 1, 5. A personal computer is a type of controller. For example, Maestro describes the computer as able to play sound, adjust volumes and provide MIDI controls, which also makes the computer a sound apparatus that also includes an acoustic device. Id. at pp. 16, 17, 19, 20, 22. It is able to take actions that control various states of the computer, including the volume settings of an iTunes music player, a Quicktime video player and overall system volume. Id. at pp. 30–35. By controlling individual applications volumes and system volume, the computer acts as an audio mixer.
“receive a trigger requirement;
“receive a condition requirement;
“receive an action corresponding to the trigger requirement;
The Maestro reference enables users to define and execute macros to control operations of a personal computer. Id. at pp. 5–8. Macro definition includes defining triggers, conditions and actions. Id. The triggers and conditions include things like keyboard inputs and things that must be true when a trigger is received, such as a condition of the computer. Id. at pp. 1, 2, 5–8, 10, 26. And actions include actions for a computer to execute, like playing a sound and adjusting a volume. Id. at pp. 1, 14–23, 30–35.
“associate the trigger requirement with the action and associate a macro main showing the associated trigger requirement and action with the condition requirement; and
Maestro’s program similarly displays an association among a trigger, condition and action. Id. at pp. 3, 26.
“determine that the condition requirement is satisfied and
“execute the action, in a case in which the trigger requirement is satisfied,
When a user triggers a macro, the Maestro program checks if all conditions are satisfied. Id. at pp. 7, 8, 10, 26. If the check is true, an associated action is executed. Id.
“wherein at least one of the trigger requirement, the condition requirement, and the action relates to a state of the audio mixer.”
Similarly, Keyboard Maestro operates on a computer running MacOS operating system that provides audio mixing through the volume adjustment of multiple apps and a system volume. Id. at pp. 30–35. The actions of adjusting volume based on button presses and conditions, such as whether an app is open, all relate to conditions of the computer, which acts as an audio mixer. Id. at pp. 30–35.
Table 1
For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 2 depends on claim 1, and further requires the following:
“wherein the controller is also configured to receive a reverse action that is performed in a case in which the trigger requirement is not satisfied;
“associate the trigger requirement with the reverse action; and
“check that the condition requirement is satisfied and then executes the reverse action, in the case in which the trigger requirement is not satisfied.”
The Maestro program similarly includes reverse actions associated with triggers. In particular, Maestro’s macro definitions include a section for actions to take in the event all conditions are not met. Maestro at p. 26. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 3 depends on claim 1, and further requires the following:
“wherein the trigger requirement corresponds to a state of a physical controller of the audio mixer configured to designate sound processing to an input, mixture, or output of an audio signal.”
Similarly, the Maestro reference describes receiving a trigger, such as a button press, that causes a change in audio volume. Maestro at pp. 5, 8, 16, 17, 19, 21, 22. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 4 depends on claim 1, and further requires the following:
“wherein the controller is also configured to receive the trigger requirement, the action, and the condition requirement from a user.”
The Maestro program likewise includes user-defined macros created by a user through a computer GUI. Maestro at pp. 5–7, 26. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 6 is drawn to “an acoustic device setting method.” The following table illustrates the correspondence between the claimed method and the Maestro reference.
Claim 6
The Maestro Reference
“6. An acoustic device setting method comprising:
The Maestro reference describes a program executed by a personal computer, like a Mac-branded computer, to implement a method. Maestro at pp. 1, 5. A personal computer is a type of controller. For example, Maestro describes the computer as able to play sound, adjust volumes and provide MIDI controls, which also makes the computer a sound apparatus that also includes an acoustic device. Id. at pp. 16, 17, 19, 20, 22.
“receiving a trigger requirement;
“receiving a condition requirement;
“receiving an action corresponding to the trigger requirement;
The Maestro reference enables users to define and execute macros to control operations of a personal computer. Id. at pp. 5–8. Macro definition includes defining triggers, conditions and actions. Id. The triggers and conditions include things like keyboard inputs and things that must be true when a trigger is received, such as a condition of the computer. Id. at pp. 1, 2, 5–8, 10, 26. And actions include actions for a computer to execute, like playing a sound and adjusting a volume. Id. at pp. 1, 14–23, 30–35.
“associating the trigger requirement with the action and associating a macro main showing the associated trigger requirement and action with the condition requirement; and
Maestro’s program similarly displays an association among a trigger, condition and action. Id. at pp. 3, 26.
“determining that the condition requirement is satisfied and
“executing the action, in a case in which the trigger requirement is satisfied,
When a user triggers a macro, the Maestro program checks if all conditions are satisfied. Id. at pp. 7, 8, 10, 26. If the check is true, an associated action is executed. Id.
“wherein at least one of the trigger requirement, the condition requirement, and the action relates to a state of the audio mixer.”
Similarly, Keyboard Maestro operates on a computer running MacOS operating system that provides audio mixing through the volume adjustment of multiple apps and a system volume. Id. at pp. 30–35. The actions of adjusting volume based on button presses and conditions, such as whether an app is open, all relate to conditions of the computer, which acts as an audio mixer. Id. at pp. 30–35.
Table 2
For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 7 depends on claim 6, and further requires the following:
“further comprising: receiving a reverse action to be performed in a case in which the trigger requirement is not satisfied;
“associating the trigger requirement with the reverse action and associating a macro main showing the associated trigger requirement and reverse action with the condition requirement; and
“checking that the condition requirement is satisfied and then executing the reverse action, in the case in which the trigger requirement is not satisfied.”
The Maestro program similarly includes reverse actions associated with triggers. In particular, Maestro’s macro definitions include a section for actions to take in the event all conditions are not met. Maestro at p. 26. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 8 depends on claim 6, and further requires the following:
“wherein the trigger requirement corresponds to a state of a physical controller of the audio mixer configured to designate sound processing to an input, mixture, or output of an audio signal.”
Similarly, the Maestro reference describes receiving a trigger, such as a button press, that causes a change in audio volume. Maestro at pp. 5, 8, 16, 17, 19, 21, 22. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 9 depends on claim 6, and further requires the following:
“wherein the trigger requirement, the action, and the condition requirement are received from a user.”
The Maestro program likewise includes user-defined macros created by a user through a computer GUI. Maestro at pp. 5–7, 26. For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Claim 11 is drawn to “a non-transitory computer-readable storage medium.” The following table illustrates the correspondence between the claimed medium and the Maestro reference.
Claim 11
The Maestro Reference
“11. A non-transitory computer-readable storage medium storing a program, which when executed causes an acoustic device setting apparatus to:
The Maestro reference describes a program stored on a non-transitory computer-readable storage medium so that it can be executed by a personal computer, like a Mac-branded computer. Maestro at pp. 1, 5. A personal computer is a type of controller. For example, Maestro describes the computer as able to play sound, adjust volumes and provide MIDI controls, which also makes the computer a sound apparatus that also includes an acoustic device. Id. at pp. 16, 17, 19, 20, 22.
“receive a trigger requirement;
“receive a condition requirement;
“receive an action corresponding to the trigger requirement;
The Maestro reference enables users to define and execute macros to control operations of a personal computer. Id. at pp. 5–8. Macro definition includes defining triggers, conditions and actions. Id. The triggers and conditions include things like keyboard inputs and things that must be true when a trigger is received, such as a condition of the computer. Id. at pp. 1, 2, 5–8, 10, 26. And actions include actions for a computer to execute, like playing a sound and adjusting a volume. Id. at pp. 1, 14–23, 30–35.
“associate the trigger requirement with the action and associating a macro main showing the associated trigger requirement and action with the condition requirement; and
Maestro’s program similarly displays an association among a trigger, condition and action. Id. at pp. 3, 26.
“determine that the condition requirement is satisfied and
“execute the action, in a case in which the trigger requirement is satisfied,
When a user triggers a macro, the Maestro program checks if all conditions are satisfied. Id. at pp. 7, 8, 10, 26. If the check is true, an associated action is executed. Id.
“wherein at least one of the trigger requirement, the condition requirement, and the action relates to a state of the audio mixer.”
Similarly, Keyboard Maestro operates on a computer running MacOS operating system that provides audio mixing through the volume adjustment of multiple apps and a system volume. Id. at pp. 30–35. The actions of adjusting volume based on button presses and conditions, such as whether an app is open, all relate to conditions of the computer, which acts as an audio mixer. Id. at pp. 30–35.
Table 3
For the foregoing reasons, the Maestro reference anticipates all limitations of the claim.
Obviousness
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 5 and 10 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Maestro and US Patent Application Publication 2010/0034400 (published 11 February 2010) (“Aiso”).
Claims 12–17 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Maestro and Jay Cruz, Short Circuit Evaluation, Dev Community, https://dev.to/coderjay06/short-circuit-evaluation-3jb1 (published 27 October 2021) (archived 07 December 2022) (last accessed 26 June 2026) (“Cruz”).
Claim 5 depends on claim 1, and further requires the following:
“wherein the controller is also configured to receive an operation to enable a movement that executes the action in the case in which the trigger requirement is satisfied; and
“receive a selection of ON/OFF of auto sync that matches the action executed by the trigger requirement with a state of an acoustic device, before receiving the operation to enable the movement.”
Claim 10 depends on claim 6, and further requires the following:
“further comprising: receiving an operation to enable a movement that executes the action in the case in which the trigger requirement is satisfied; and
“receiving a selection of ON/OFF of auto sync that matches the action executed by the trigger requirement with a state of an acoustic device, before receiving the operation to enable the movement.”
Claims 5 and 10 are treated together. The Maestro reference describes a macro program capable of executing a wide variety of actions in response to a trigger under certain conditions. Some example actions include setting the volume of a sound output and providing external control through MIDI channels. Maestro at pp. 20. The Aiso reference describes an audio fader capable of being operated manually and automatically. Aiso at ¶¶ 1, 26, FIG.1. In the automatic mode, the fader is controlled by another device, like a CPU 101, by providing a target position. Id. Read together, Maestro reasonably suggests automating the control of Aiso’s fader with the Maestro program so that one or more faders of a mixer may be automatically controlled through a simple trigger, like a button press under certain conditions. In that case, a user would define a macro with an auto sync selection to automatically control the fader with the Maestro computer. The computer would then receive from the macro program an operation to move the fader when the trigger requirement is satisfied. For the foregoing reasons, the combination of the Maestro and the Aiso references makes obvious all limitations of the claims.
Claim 12 depends on claim 1, and further requires the following:
“wherein the controller is configured to determine whether the trigger requirement is satisfied after determining that the condition requirement is satisfied.”
Maestro describes an if-then-else functionality that allows for nesting requirements. For example, a user may specify a first requirement and a second requirement, where both requirements must be true (i.e., an AND function) or at least one requirement must be true (i.e., an OR function). See Maestro at pp. 26–27. In other words, a user may create a Boolean function with at least two Boolean operators, or requirements. It is common practice in computer programming to short-circuit evaluation of Boolean functions once the value of the function is known. See, e.g., Cruz at p.1. For example, if there is a Boolean function
B
=
x
A
N
D
y
, a computer will typically short-circuit evaluation of
B
when
x
is false since
B
must be false also. Id. at pp.1–2. This technique avoids redundant processing. Id. at p.3.
Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Claim 13 depends on claim 1, and further requires the following:
“wherein the controller is configured not to determine whether the trigger requirement is satisfied when it is determined that the condition requirement is not satisfied.”
As shown in the obviousness rejection of claim 12, incorporated herein, Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. If the condition requirement evaluates false, the program would not evaluate the trigger requirement to avoid redundant processing. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Claim 14 depends on claim 6, and further requires the following:
“further comprising: determining whether the trigger requirement is satisfied after determining that the condition requirement is satisfied.”
Maestro describes an if-then-else functionality that allows for nesting requirements. For example, a user may specify a first requirement and a second requirement, where both requirements must be true (i.e., an AND function) or at least one requirement must be true (i.e., an OR function). See Maestro at pp. 26–27. In other words, a user may create a Boolean function with at least two Boolean operators, or requirements. It is common practice in computer programming to short-circuit evaluation of Boolean functions once the value of the function is known. See, e.g., Cruz at p.1. For example, if there is a Boolean function
B
=
x
A
N
D
y
, a computer will typically short-circuit evaluation of
B
when
x
is false since
B
must be false also. Id. at pp.1–2. This technique avoids redundant processing. Id. at p.3.
Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Claim 15 depends on claim 6, and further requires the following:
“further comprising: determining whether the trigger requirement is satisfied when it is determined that the condition requirement is not satisfied.”
As shown in the obviousness rejection of claim 12, incorporated herein, Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. If the condition requirement evaluates false, the program would not evaluate the trigger requirement to avoid redundant processing. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Claim 16 depends on claim 11, and further requires the following:
“wherein the program also causes the acoustic device setting apparatus to determine whether the trigger requirement is satisfied after determining that the condition requirement is satisfied.”
Maestro describes an if-then-else functionality that allows for nesting requirements. For example, a user may specify a first requirement and a second requirement, where both requirements must be true (i.e., an AND function) or at least one requirement must be true (i.e., an OR function). See Maestro at pp. 26–27. In other words, a user may create a Boolean function with at least two Boolean operators, or requirements. It is common practice in computer programming to short-circuit evaluation of Boolean functions once the value of the function is known. See, e.g., Cruz at p.1. For example, if there is a Boolean function
B
=
x
A
N
D
y
, a computer will typically short-circuit evaluation of
B
when
x
is false since
B
must be false also. Id. at pp.1–2. This technique avoids redundant processing. Id. at p.3.
Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Claim 17 depends on claim 11, and further requires the following:
“wherein the program also causes the acoustic device setting apparatus to determine whether the trigger requirement is satisfied when it is determined that the condition requirement is not satisfied.”
As shown in the obviousness rejection of claim 12, incorporated herein, Cruz’s teachings reasonably suggest modifying Maestro’s if-then-else functionality to similarly perform short-circuit evaluation in order to avoid redundant evaluations. Applied to Maestro, a Boolean function that requires multiple requirements to evaluate true (i.e., an AND function) would only evaluate a second requirement if the first requirement evaluates true. See Maestro at pp. 26–27. In that case, the first requirement would correspond to a condition requirement and the second requirement would correspond to a trigger requirement as claimed. The trigger requirement would only be evaluated if the condition requirement evaluates true. If the condition requirement evaluates false, the program would not evaluate the trigger requirement to avoid redundant processing. For the foregoing reasons, the combination of the Maestro and the Cruz references makes obvious all limitations of the claim.
Summary
Claims 1–17 are rejected under at least one of 35 U.S.C. §§ 102 and 103 as being unpatentable over the cited prior art. 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.
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 C.F.R. § 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.
Rejections Under 35 U.S.C. § 112
Indefiniteness
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.
Claims 6–11 and 14–17 are rejected under 35 U.S.C. § 112(b) 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.
Claim 6 recites the limitation "the audio mixer" in line 9 and claim 11 recites the same limitation in line 11. There is insufficient antecedent basis for this limitation in the claim. For the foregoing reasons, one of ordinary skill would not have been able to be reasonably certain as to the scope of the claims.
Claims 7–10 and 14–17 depend on one of claims 6 and 11, and include the same indefiniteness issue. For the foregoing reasons, one of ordinary skill would not have been able to be reasonably certain as to the scope of the claims.
Response to Applicant’s Arguments
Applicant’s Reply (08 May 2026) has substantively amended all the claims. This Office action has updated the rejections accordingly.
Applicant’s Reply at 7–14 presents comments pertaining to the Non-Final Rejection (09 February 2026) and that are relevant to the rejections included in this Office action.
Applicant comments that the Maestro reference is drawn to a general-purpose macro automation tool for MacOS-branded operating systems, and is not directed to macro functions for an audio mixer. The rejection has been updated to detail audio mixing functions of MacOS-branded operating systems that are directly controllable by the Maestro macro tool. Without more limitations defining the metes and bounds of an audio mixer, there is no patentable difference between the audio mixer functions (i.e., separately controlling application volumes and a system volume) described in the Maestro reference and the claimed audio mixer.
Applicant comments that Maestro’s description of setting volumes and controlling a MIDI device is not the same as audio mixing. Setting that contention aside, the updated rejection describes mixing functions that Applicant’s current comments do not address.
Applicant comments that the claimed audio mixer triggers, conditions and actions relate to specific states, such as power consumption and CPU resource usage. To the extent these features are not found in the Maestro reference, they are also not recited in the claims.
Applicant comments that the Maestro reference describes triggers, conditions and actions pertaining to the state of a computer, not an audio mixer. As shown in the updated rejection, the Maestro reference’s computer acts as an audio mixer by separately controlling the volumes of multiple applications and an overall system volume. Thus, the states of the computer correspond to the state of an audio mixer since the underlying general-purpose computer has been programmed to become a special-purpose audio mixer. For example, Maestro describes the action of setting volumes of separate applications and the system overall. The volume of each of those entities corresponds to various states of an audio mixer.
Applicant comments that Maestro’s macro groups are not claimed condition requirements relating to a state of an audio mixer. This comment is moot because it does not form part of the rejection.
Applicant comments that Maestro’s macro groups are not claimed condition requirements relating to a state of an audio mixer. This comment is moot because it does not form part of the rejection.
Applicant comments that Maestro’s detection of a button press is not the same as the state of a physical controller of an audio mixer. This comment again presumes that Maestro’s computer is simply a generic-purpose computer without considering that the computer is programmed to act as an audio mixer.
Applicant comments that Maestro does not anticipate the limitations of new claims 12–17. This comment is moot since the new grounds of rejection presented herein are premised on a combination of teachings from Maestro and Cruz.
Applicant comments that the rejection erroneously pieces together distinct disclosures in the Maestro reference to show audio mixing functionality. This comment is moot because it does not address the updated rejection and the additional pages of the Maestro reference provided with this Office action.
Applicant comments that the combination of Maestro and Aiso do not make obvious claims 5 and 10. Applicant first notes that Aiso does not describe the claimed macro system. This comment is irrelevant since the rejection does not rely on Aiso to teach any type of macro system.
Applicant comments that the rejection is applying improper hindsight in combining Maestro and Aiso because it does not identify any reason to combine their teachings to render the claimed invention. Applicant points to Maestro being a general-purpose macro program for automating workflows while Aiso is drawn to an automatic fader. Applicant’s admission, however, cuts against its position. The fact Maestro describes a general-purpose macro program for automating workflows suggests automating any type of workflow capable of being automated. Further, Aiso’s fader is an automatic fader designed for control by a computer. The idea of using a macro program designed to automate a workflow to automate an automatic fader is immediately apparent on its face. See MPEP § 2143(I)(D) (applying a known technique (e.g., macros for automating workflows) to a known device ready for improvement (e.g., an automatic fader used in an audio mixing workflow) to yield predictable results (e.g., a macro controlled automatic fader)).
Applicant comments that the claims are not limited to automatically moving a fader. This comment misses the thrust of the rejection which establishes the obviousness of using Maestro’s macros to automatically control Aiso’s audio-mixing faders based on Maestro’s user-established triggers and conditions.
For the foregoing reasons, Applicant has not persuasively established any error in the Office action, and all the rejections will be maintained.
Conclusion
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 C.F.R. § 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 C.F.R. § 1.17(a)) pursuant to 37 C.F.R. § 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 WALTER F BRINEY III whose telephone number is (571)272-7513. The examiner can normally be reached M-F 8 am-4:30 pm.
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, Carolyn Edwards can be reached at 571-270-7136. 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.
/Walter F Briney III/
Walter F Briney IIIPrimary ExaminerArt Unit 2692
6/26/2026
1 N.B.: the Examiner has provided a new copy of the Maestro reference including additional pages 30–35.
Prosecution Insights