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 Amendment
In response to the Non-final Office Action from 9/15/2025, Applicant has filed an amendment on 11/14/2025. In this reply, Applicant has amended independent claims 1 and 24-25 to further recite that the callback mechanism is implemented by the program to receive asynchronous events from the framework, that the event registration mechanism is registered by the program to receive real-time event notifications from the framework, that processing VoiceFlows causes the processor to generate speech-enabled conversational interactions between the program and a user of the program, that the runtime interface object communicates with a media framework that executes lower-level audio and media functions on the device including audio recording, playback, and echo cancellation, and that an event-registration mechanism receives real-time media-event notifications from the media framework indicating audio-session state permissions, and availability.
Applicant has also argued that the prior art of record fails to teach the limitations added via the instant amendment (Remarks, Pages 31-32).
These arguments have been fully considered, however, are moot with respect to the new grounds of rejection necessitated by the amended claims.
In response to the expansion or removal of the acronyms recited in claims 8, 11, 14, 15, and 24 (Remarks, Pages 28-29), the claim objections directed towards minor informalities have been resolved and withdrawn.
In regards to the rejections under 35 U.S.C. 112(b), Applicant argues that the amendments to claims 1-25 "resolve every instance" of indefiniteness (Remarks, Pages 28-29).
In response while the previously noted indefiniteness issues related to inconsistent capitalization between term instances, antecedent basis issues, and incomplete limitations have been resolved, the instant amendment contains significant amendments to all claims and has caused to a number of additional indefiniteness issues that have been set forth in the proceeding 35 U.S.C. 112(b) rejections.
In response to the rejection of Claims 1-25 under 35 U.S.C. 101, Applicant argues that the claimed invention is directed towards a practical application of computing technology not to a disembodied abstract idea (Remarks, Page 30).
In response, it is noted that the Applicant's remarks mischaracterize the grounds of the 35 U.S.C. 101 rejection. The claims were not found to be patent ineligible under 35 U.S.C. 101 because they are directed towards a judicial exception in the form of an abstract idea. Instead, the claims were rejected under Step 1 of the 2019 Patent Subject Matter Eligibility Guidelines (2019 PEG) for being directed towards a program per se under the broadest reasonable interpretation (BRI) in the form of data per se or software per se that does not fall within the four statutory categories of invention.
Although not argued by Applicant, the claims have been amended to add computer hardware in the form of a processor and memory storing instructions that exclude purely data/software embodiments from the claims as a whole. For this reason, the 35 U.S.C. 101 rejection is now moot and has been withdrawn. Similarly, due to the removal of claim language characterizing claim 25 as a program under the BRI and directed the claimed invention to at least the method statutory category, the 35 U.S.C. 101 rejection of this claim is also moot and has been withdrawn.
Response to Arguments
In response to the 35 U.S.C. 112(a) rejection of original claim 25 for failing to comply with the written description requirement regarding the lack of an underlying software algorithm or steps/procedures taken to perform the allocation of an audio session with audio session property descriptors, Applicant argues that these descriptors are "used by those skilled in the art to refer to standard data attributes." Applicant also defines those attributes, adds the attributes to Claim 25, and states that such features were inherent to the original disclosure (Remarks, Page 29).
In response, it is noted that the original 35 U.S.C. 112(a) rejection was due to a lack of an underlying algorithm for how the allocation is being performed. Per MPEP 2161.01- "original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed."
The claimed invention is in the software arts and Applicant's position still does not explain how resources are specifically being allocated- the specification still lacks any detail regarding the process as the term is only mentioned once in original claim 25. Moreover, the Examiner has searched for evidence that the term is well known and must/is required to contain the various attributes identified by Applicant and added to claim 25. The only instance of this term is found in the pre-grant publication of Applicant's own specification (see attached PE2E Search results having 1 hit for "audio session property descriptors"). Thus, the term is not known/standard in the art and does not inherently include the attributes Applicant contends that are necessarily included by mere mention of the term and have added to claim 25. Consequently, this rejection has not been overcome and the addition of the different types of descriptors to claim 25 has compounded the prior written description issue.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 24-25 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Amended Claim 24 newly recites "instantiate an audio recorder to read raw audio from device microphones, local or remote Uniform Resource Locator (URL) sources, and multiple local or remote speech-synthesis engines." While the specification at Paragraph 0068 does describe that such an audio recorder "performs recording of raw audio data from a plurality of sources to a plurality of destinations" and Paragraph 0107 defines recording on an active device microphone, the specification is silent as to the other "plurality of destinations including "local or remote Uniform Resource Locator (URL) sources, and multiple local or remote speech-synthesis engines." Claim 24 has also been amended to recite "instantiate an audio player to write raw audio to device speakers, local or remote URL destinations, voice-activity-detection modules, acoustic-echo-cancellation modules, and multiple local or remote speech recognition engines." Paragraph 0068 of the specification notes that such an audio player "performs audio playback of raw audio data from a plurality of sources to a plurality of destinations." Paragraph 0071 describes that the audio player instantiates a number of other modules having to do with the claimed elements, but not that the audio player serves to "write audio" to these destinations. Thus, at best the original specification only supports the instantiation of other modules, but not the writing of raw audio as claimed. Accordingly, claim 24 fails to comply with the written description requirement.
Per MPEP 2161.01- "original claims may lack written description when the claims define the
invention in functional language specifying a desired result but the specification does not sufficiently
describe how the function is performed or the result is achieved. For software, this can occur when the
algorithm or steps/procedure for performing the computer function are not explained at all or are not
explained in sufficient detail (simply restating the function recited in the claim is not necessarily
sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be
described with sufficient detail so that one of ordinary skill in the art would understand how the
inventor intended the function to be performed." Claim 25 recites "allocating an audio session having audio-session property descriptors." The originally filed specification fails to even use the term "audio session property descriptors" let alone provide examples of such descriptors or how specific instances thereof can be allocated. Thus, although this language is recited in original claim 25, the specification fails to adequately describe how the claimed function is performed resulting in a written description issue under 35 U.S.C. 112(a).
Amended Claim 25 further adds a limitation regarding "allocating an audio session having audio-session property descriptors including at least one of sampling rate, channel count, latency mode, device selection, buffer size, or routing policy." The specification as originally filed makes no mention of property descriptors including at least one of the recited alternatives. The only mention of audio-session property descriptors was in original claim 25 and while it is appreciated that original claims are a part of the disclosure, original claim 25 made no mention of the property descriptors specifically being described in the alternative in amended claim 25. Accordingly, claim 25 fails to comply with the written description requirement and has been rejected under 35 U.S.C. 112(a).
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-25 are 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.
In Claim 1, line 10, "the program" is referenced. This term does not appear earlier in claim 1 so it is unclear what term is being referenced by "the program" or if this term is referring back to "a program application" on line 9. For the purposes of claim interpretation in the interest of compact prosecution, "the program" in line 10 will be construed as "the program application." In other words, these limitations are construed to be referring to the same program so alternatively Applicant could amend "program application" of line 9 to read --program-- (i.e., deleting application) to resolve this antecedent basis issue as well as other instances of “the program” (see claims 3, 4, 7; note that some dependent claims, however, such as 8-10 reference “the program application” so Applicant should be aware of consistency between terms when considering future amendments).
Claim 2, Line 5 recites "the modules." Claim 2 line 2 recites "multiple configured modules" while parent claim 1 recites "a plurality of modules" so it is unclear which of the modules are being referenced by this instance of the term. For claim interpretation, "the modules" in claim 2, line 5 will be construed as --the multiple configured modules--. Claim 2, Lines 9 and 27 recite "VoiceFlow processing" without a referential modifier when the term appears earlier in claim 2, line 7 so it is unclear whether this later instance should refer back to the earlier instance or is attempting to introduce a secondary instance of the term. For claim interpretation, "VoiceFlow processing" will be construed as --the VoiceFlow processing--. Claim 2, Line 20 recites "a user" when the term was previously introduced in parent claim 1. It is thus unclear whether this limitation should refer back to the term introduced in claim 1 or a separate user. For claim interpretation "a user" will be construed as --the user--.
In Claim 3, "the execution state of the framework" lacks antecedent basis and it is unclear what limitation is being referenced. For claim interpretation, "the execution state..." will be construed as --an execution state...--.
In amended Claim 5, while the instant amendment corrects the antecedent basis with the "next Voice Flow Module" in later in the claim by adding the definite article "the", the amendment has caused an antecedent basis issue in the initial instance of the term found in line 5 where there is no previous instance of "next Voice Flow Module." For claim interpretation, "the" will be construed as being deleted from this limitation. Further, in amended Claim 5 although not properly marked with an underline indication, the modifier "the" was added before the first instance of user-provided speech utterance and the later instance of the term that did contain an antecedent basis issue was deleted. Accordingly, the instant amendment introduces an antecedent basis issue for "the user provided speech utterance" in the evaluation process of a partial or complete speech recognition hypothesis. For claim interpretation, "the" will be construed as being deleted. In Claim 5, Line 7, "the next audio-playback modules" lack antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--. In Claim 5, Line 14, it is unclear what is meant by the pronoun "it" since the term could be referring to a number of different aspects (e.g., the utterance, either hypothesis) that are being evaluated. For claim term interpretation, "it" will be construed as --the user-provided speech utterance--. A similar issue is present in line 18 where "it" is being construed as "the speech recognition hypothesis" for claim interpretation purposes.
In Claim 8, Line 7, "the framework API" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In Claim 9, Line 7, "the framework application-programming interface" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--. Also claim 9 features two additional instances of "VoiceFlow processing" in line 4 that should be introduced with a definite article "the" since it is currently clear whether these additional instances find antecedence in the initial term found in line 3 or represent separate instances.
In Claim 10, lines 5-6, "the program application's continuously changing state" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In Claim 11, Lines 2-3, "the framework application-programming interface" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In Claim 17, both "the current module" and "the current Voice Flow Module" have antecedent basis issues and it is unclear what terms are being referenced by these limitations. For claim interpretation, "the current module" will be construed as --a current VoiceFlow module" which will also resolve the antecedent basis issue with "the current Voice Flow Module" later in the claim.
In Claim 19, Line 2 "the program's intent classification" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, this limitation will be construed as –an intent classification--. Also in claim 19, both "the current module" and "the current Voice Flow Module" have antecedent basis issues and it is unclear what terms are being referenced by these limitations. For claim interpretation, "the current module" will be construed as --a current VoiceFlow module" which will also resolve the antecedent basis issue with "the current Voice Flow Module" later in the claim.
In Claim 20, Lines 8-9, “the beginning” lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In Claim 22, Lines 4-5, “the start” lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--. Also, it is unclear whether "the hypotheses" (plural) refers back to "hypothesis" (singular) in the immediately prior line due to the singular/plural disagreement and lack of antecedent basis for "the hypotheses." For claim term interpretation, "the hypotheses" with be construed as --the hypothesis--. Lastly, both "the configured audio segments" and "the program's classified intent" lack antecedent basis and it is unclear what limitation is being referenced by these terms. For claim interpretation, the former will be construed as --configured audio segments-- and the latter limitation will be construed as --classified intent--.
In amended Claim 23, although not properly marked with an underline indication, the modifier "the" was added before “program state changes” leading to an antecedent basis issue. For claim interpretation, “the” will be construed as being deleted.
In Claim 24, line 5, "the client" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In Claim 25, line 17, "the framework" lacks antecedent basis and it is unclear what term is being referenced by this limitation. For claim interpretation, "the" will be construed as being deleted and replaced with –a--.
In addition to any further indefiniteness issues noted with respect to the dependent claims above, the dependent claims also inherit the indefinite limitations of their respective parent claims, and thus, are also rejected under 35 U.S.C. 112(b) by virtue of their dependency.
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.
Claims 1-7 and 9-24 are rejected under 35 U.S.C. 103 as being unpatentable over Ryabov, et al. (U.S. Patent: 11,798,542) in view of Wright, et al. (U.S. PG Publication: 2024/0251128 A1).
With respect to Claim 1, Ryabov discloses:
A computer-implemented system comprising a processor (processor, Col. 21, Line 59- Col. 22, Line 5) and a memory storing instructions that, when executed by the processor on a device (memory storing program instructions, Col. 22, Lines 28-36), instantiate a speech- enabling conversational interaction framework (Voice Flow Framework) for processing application-programming-interface (API) requests from a program application executing on the device, the system comprising (enable a voice-supporting software module framework for processing API requests from an application running on a client device, Col. 8, Line 53- Col. 9, Line 18):
a runtime object instantiated by the program (the application instantiates various runtime objects (e.g., interface elements), Col. 8, Lines 25-42 and see Fig. 7 as an example);
a callback mechanism implemented by the program to receive asynchronous events from the framework (callback functionality that receives events that trigger various actions in the application program, Col. 33, Lines 26-42; Col. 43, Lines 31-63; Col. 44, Lines 15-34);
an event-registration mechanism by which the program registers to receive real-time event notifications from the framework (event registration within the application program responsive to a voice framework input (e.g., a real-time notification of a visual event or instruction based upon voice), Col. 6, Lines 21-34; Col. 8, Lines 3-24; Col. 8, Line 53- Col. 9, Line 8; Col. 12, Lines 3-23; and Col. 29, Lines 29-39);
a plurality of modules executed by the framework to interpret and process configured data structures (VoiceFlows) provided by the program, wherein processing the VoiceFlows causes the processor to generate speech-enabled conversational interactions between the program and a user of the program (assistive voice control software modules that process data structures (e.g., interface elements, program operations, etc.) of an application program to understand user speech and carry out responses or actions within the application, Col. 4, Lines 4-25; Col. 5, Lines 33-52; Col. 8, Lines 3-24; Col. 10, Lines 11-28; and Col. 17, Lines 18-41);
a runtime interface object that communicates with a media framework executing lower-level audio and media functions on the device including audio recording, playback, and
an event-registration mechanism for the framework to receive real-time media- event notifications from the media framework indicating audio-session state, permissions, and availability (module registering/receiving real-time event notifications including visual/dialog states, entity/media availability, and restrictions or permission to user voice models based on identity, Col. 5, Lines 18-32, Col. 17, Lines 6-41; Col. 9, Lines 19-40; Col. 14, Line 54-Col. 15, Line 3, Col. 20, Lines 1-24; Col. 21, Lines 38-58; Col. 25, Lines 40-55; Col. 28, Line 53- Col. 29, Line 8).
Although Ryabov further teaches the elimination of audio data corresponding to background noise (Col. 14, Line 54- Col. 15, Line 4), Ryabov does not specifically teach the elimination of echoes or echo cancellation. Wright, however, discloses this well-known form of audio pre-processing (Paragraph 0108).
Ryabov and Wright are analogous art because they are from a similar field of endeavor in human-machine speech interfaces. Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the teachings of Ryabov with the echo cancellation taught by Wright to provide a predictable result of eliminating another type of audio that might have been captured by accident and does not correspond to a user's intended speech input (Ryabov, Col. 14, Line 54- Col. 15, Line 4).
With respect to Claim 2, Ryabov further discloses:
The system of claim 1, wherein the processor (processor execution as noted in the claim 1 rejection) executing the framework interprets and processes multiple configured modules (Voice Flow Modules) within each VoiceFlow, the modules comprising: an entry module that initiates VoiceFlow processing ("begin" or wake module to start a voice dialog scenario, Col. 24, Lines 25-45 and Col. 43, Lines 40-63);
an exit module that terminates VoiceFlow processing (turning off software module for the voice processing, Col. 24, Lines 46-52);
process modules that manage data stores and VoiceFlow state (software-based management of voice dialog state and data storage for retrieval, Col. 5, Lines 18-42; Col. 11, Lines 35-51; Col. 12, Lines 3-35; and Col. 28, Line 53- Col. 29, Line 8);
play-audio modules that control audio playback through device outputs (software module for playback of audible media, Col. 7, Lines 19-34; Col. 11, Lines 52-64; Col. 12, Line 58- Col. 13, Line 13; Col. 16, Lines 35-48; and Col. 24, Line 64-Col. 25, Line 14);
record-audio modules that control audio recording from device inputs (Col. 7, Lines 7-18; Col. 8, Line 43- Col. 9, Line 8; and Col. 18, Lines 38-46);
audio-dialog modules that generate speech-enabled conversations between the program and a user (dialog management/processing modules that enable human-machine conversation within an application, Col. 5, Lines 18-42; Col. 23, Lines 51-58; Col. 25, Lines 15-29; and Col. 57, Lines 51-56);
audio-listener modules that enable listening interactions between the program and the user (software modules that enable a listening mode for audio playback, Col. 11, Lines 52-64; Col. 12, Lines 26-40; Col. 12, Line 58- Col. 13, Line 13; and Col. 16, Lines 35-67); and
pause-resume modules that pause and resume VoiceFlow processing based on program instructions (application program instructions that enable activation/deactivation of the voice interaction processing, Col. 24, Lines 25-52).
With respect to Claim 3, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework performs callback invocations to the program before the framework begins processing each Voice Flow Module, during processing of the module, and after completion of the module, thereby enabling the program to synchronize its operations with the execution state of the framework (callback functions are performed through voice interaction processing (beginning to have an updated UI, during to continually synchronize the application interface, and after to reflect executed commands invoked by a command handler) to continually update and synchronize user interface elements, Col. 33, Lines 16-42 and Col. 34, Lines 5-32).
With respect to Claim 4, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework creates, retrieves, updates, and deletes dynamic runtime parameters configured in VoiceFlows and stored in memory while the framework is processing a VoiceFlow and its Voice Flow Modules, and wherein the program accesses and processes the dynamic runtime parameters through callbacks invoked by the framework during such processing (callback functions/event handlers such as a command handler create runtime parameters (e.g., UI object information), retrieve parameters, updates parameters, and replaces/deletes parameters responsive to dialog processing/interface commands, Col. 9, Lines 41-51; Col. 12, Lines 3-40; Col. 12, Line 58- Col. 13, Line 13; Col. 33, Lines 16-42; Col. 34, Lines 5-32; and Col. 43 Line 64- Col. 44, Line 54).
With respect to Claim 5, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework performs
create-retrieve-update-delete (CRUD) operations on dynamic runtime parameters
configured in the VoiceFlows to (create and control runtime parameters (e.g., UI object information), retrieve parameters, updates parameters, and replaces/deletes parameters responsive to dialog processing/interface commands, Col. 8, Line 53- Col. 9, Line 8; Col. 9, Lines 41-51; Col. 12, Lines 3-40; Col. 12, Line 58- Col. 13, Line 13; Col. 33, Lines 16-42; Col. 34, Lines 5-32; and Col. 43 Line 64- Col. 44, Line 54):
identify the next Voice Flow Module to process after completion of a current
module (“changing” to a next dialog context/state having various dialog modules responsive to a user input, Col. 4, Lines 26-36; Col. 5, Lines 33-42; Col. 44, Lines 1-44);
determine the next audio-playback modules and their playback parameters (changing dialog state involves visual state parameters and corresponding voice response, Col. 4, Lines 26-36; Col. 5, Lines 33-42; Col. 34, Lines 5-32; Col. 44, Lines 1-44);
determine voice-activity-detection (V AD) (voice activity detection/background noise identification on captured audio, Col. 14, Line 54- Col. 15, Line 4) and acoustic-echo-cancellation (AEC) (AEC taught by Mitchell as applied to Claim 1) parameters for audio recording and speech recognition (ASR and audio capture, Col. 4, Lines 37-55 and Col. 14, Lines 33-53);
evaluate a partial or complete speech-recognition hypothesis from the user-provided
speech utterance to determine whether it matches pre-configured valid user inputs (various processes for validating a speech recognition hypothesis to make sure the ASR result is what the user has most likely said wherein as the model has pre-set results with respect to dialog state or context, the inputs are pre-configured, Col. 4, Lines 37-55 and Col. 40, Line 36- Col. 41, Line 3);
evaluate the speech-recognition hypothesis to determine whether it is classified to
a user intent that matches pre-configured valid user intents (classification via matching of a recognized utterance hypothesis to a valid user intent pre-configured in the application context, Col. 2, Lines 22-36; Col. 10, Lines 28-46; Col. 15, Lines 44-53; Col. 29, Lines 49-60; and Col. 33, Lines 16-42);
interrupt processing of a Voice Flow Module and start another Voice Flow Module (activation of intents linked to application actions "at any time," Col. 5, Lines 18-32, which for example, activate that particular intent and cause re-arrangement of a dialog stack, Col. 44, Line 55- Col. 45, Line 2);
stop processing of the Voice Flow Module and wait for a program request identifying the next Voice Flow Module to process (activation of intents linked to application actions "at any time," Col. 5, Lines 18-32, which for example, activate that particular intent and cause abandonment of a current module until the system selects a new module in a stack, Col. 44, Line 55- Col. 45, Line 2); or
end VoiceFlow processing (turn off voice processing, Col. 24, Lines 46-52).
With respect to Claim 6, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework detects or receives a notification of an audio-session-begin interruption event from the device or from another program executing on the device and, in response, stops VoiceFlow processing until the interruption event ends (interruption event such as deactivation can be based upon a button application on the device or a voice activity detection duration programming until reactivation (e.g., via the button press or speaking a wake word, Col. 24, Lines 13-52).
With respect to Claim 7, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework detects or receives a notification of an audio-session-end interruption event from the device or from another program executing on the device and, in response, resumes VoiceFlow processing at a Voice Flow Module that is (a) identified through configuration within the VoiceFlow, (b) determined during runtime by the processor from dynamic runtime parameters modified by the program, or ( c) set by the program through a request to the framework API (program-based dynamic parameters relating to a dialog stack that allow a intent context to be activated at a lower level but still keep context higher than the activated contexts so that they may be spoken and activated/returned to "at any time," Col. 44, Line 55- Col. 45, Line 2).
With respect to Claim 9, Ryabov further discloses:
The system of claim 1, wherein the program application transmits a request through the framework application-programming interface (API) to the processor executing the framework to interrupt VoiceFlow processing, end VoiceFlow processing, move VoiceFlow processing to another Voice Flow Module, or initiate processing of another VoiceFlow (API is accessed between the application program and voice framework to create and control operations including moving to a different active dialog, ending a dialog within a stack, or exit voice processing, Col. 5, Lines 18-42; Col. 24, Lines 46-52; and Col. 44, Line 55- Col. 45, Line 2).
With respect to Claim 10, Ryabov further discloses:
The system of claim 1, wherein the program application submits, during runtime, multiple VoiceFlows to the processor executing the framework for concurrent or sequential processing in support of the program application's continuously changing state while the user is interfacing and interacting with the program application (multiple dialog contexts may be running concurrently in an active stack as the dialog proceeds with respect to changing a dialog application state, Col. 5, Lines 18-42; Col. 15, Lines 5-19 (describing sequential voice commands; Col. 28, Lines 53-63; Col. 34, Lines 5-32; Col. 44, Line 55- Col. 45, Line 2; and Col. 48, Lines 48-57).
With respect to Claim 11, Ryabov further discloses:
The system of claim 1, wherein the program application requests, through the framework application-programming interface (API), the processor executing the framework to customize VoiceFlow processing and produce dynamic interaction changes with the user during runtime by creating, retrieving, updating, or deleting dynamic runtime parameters configured in the VoiceFlows (API is accessed between the application program and voice framework to create and control runtime parameters (e.g., UI object information), retrieve parameters, updates parameters, and replaces/deletes parameters responsive to dialog processing/interface commands, Col. 8, Line 53- Col. 9, Line 8; Col. 9, Lines 41-51; Col. 12, Lines 3-40; Col. 12, Line 58- Col. 13, Line 13; Col. 33, Lines 16-42; Col. 34, Lines 5-32; and Col. 43 Line 64- Col. 44, Line 54).
With respect to Claim 12, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes a "play audio" Voice Flow Module configured within the VoiceFlow outputs (software module for playback of audible media or voice responses within a dialog script, Col. 6, Lines 14-34; Col. 7, Lines 19-34; Col. 11, Lines 52-64; Col. 12, Line 58- Col. 13, Line 13; Col. 16, Lines 35-48; Col. 24, Line 64-Col. 25, Line 14; Col. 32, Lines 4-17; Col. 34, Lines 5-32; and Col. 45, Lines 28-33), the Voice Flow Module including references to a group of configured Audio Prompt Modules for audio playback, each Audio Prompt Module references either a single audio segment with first audio-playback parameters or a group of other Audio Prompt Modules that collectively reference a plurality of audio segments, each with second audio-playback parameters, that the processor manages and queues for audio playback during processing of the "play audio" Voice Flow Module (dialog script defining different audio prompts having various parameters (e.g., variables) in the form of a single prompt that are queued to be played in a dialog script (e.g., "I'm ok"), Col. 34, Lines 5-32 Col. 43, Lines 24-30; and Col. 45, Lines 28-33).
With respect to Claim 13, Ryabov discloses:
The system of claim 12, wherein the processor executing the framework processes each Audio prompt Module or audio segment for audio playback according to its configured audio-playback style (different scenarios for playback as detailed in the below citations depending on application context), comprising: a single style that plays only a first configured audio segment and terminates after completion (playback of only a first generated voice reply responsive to a user input, Col. 6, Lines 14-20; Col. 33, Lines 36-37; and Col. 34, Lines 5-32);
a serial style that plays each next configured Audio Prompt Module sequentially after reentry within a single execution thread of the Voice Flow Module (responding with a plurality of voice responses in the order user inputs were received, Col. 15, Lines 5-19 and Col. 34, Lines 5-32);
a select style that randomly selects one Audio Prompt Module or audio segment from a group for audio playback based on runtime criteria (selecting a response within a business logic and/or dialog scripts based from a group based upon an intent of an utterance that is generated into speech tied into a visual element, Col. 31, Lines 25-60; Col. 44, Lines 1-54); and
a combo style that combines two or more of the foregoing playback styles within the same Audio Prompt Module to produce a hybrid sequence of audio segments for continuous playback (see the discussion at Col. 34, Lines 5-32 where multiple voice and visual prompts can be prepared dependent on a multitude of parsed user commands as discussed at Col 15, Lines 5-19, thus it is within the scope of these teachings that Ryabov provides a sequence that involves a combination of the above depending on the command sequence- e.g., a voice response to a question (Col. 4, Lines 4-36) and an audio segment selected based upon a visual identifier command operation context in a script (Col. 44, Lines 1-54)).
With respect to Claim 14, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes a "record audio" Voice Flow Module configured within the VoiceFlow, the Voice Flow Module causing the processor to record audio while audio playback is occurring and to apply voice activity detection (VAD) and acoustic echo cancellation (AEC) during the recording operation (voice recording module that causes the capture of input audio at any point (including playback) and involves voice activity detection/background noise identification along with AEC (per the teachings of Wright as applied to claim 1), Col. 7, Lines 7-18; Col. 8, Line 43- Col. 9, Line 8; Col. 14, Line 54- Col. 15, Line 4; and Col. 18, Lines 38-46).
With respect to Claim 15, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes a "record audio" Voice Flow Module configured within the VoiceFlow, the Voice Flow Module causing the processor to record audio with configurable options that enable the processor to:
apply voice activity detection (VAD) to the recorded audio; remove non-speech energy data from the recorded audio; stop the audio recording when a maximum non-speech energy duration threshold is reached; stop the audio recording when a maximum total audio recording duration threshold is reached; or stop the audio recording when a maximum detected speech energy duration threshold is reached (voice activity detection/background noise identification on captured audio, Col. 14, Line 54- Col. 15, Line 4).
With respect to Claim 16, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes a "record audio" Voice Flow Module configured within the VoiceFlow, the Voice Flow Module causing the processor to record audio directly from a configured Audio Prompt Module used as a source of raw audio data and to store the recorded audio in device memory (audio recording/capture from a microphone where a user input may be responsive to a system dialog and where the recording/capture necessarily requires at least temporary storage in memory for recognition/natural language understanding, Col. 1, Lines 46-56; Col. 7, Lines 7-18; Col. 8, Line 43- Col. 9, Line 8; Col. 18, Lines 38-46; and Col. 44, Lines 15-44).
With respect to Claim 17, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework compares a partial or a complete speech recognition hypothesis to a list of partial and complete user utterance inputs configured in an "audio dialog" or "audio listener" Voice Flow Module, and continues processing the current module or transitions to another module based on static or dynamic transition parameters defined for the current Voice Flow Module and stored within the VoiceFlow (matching a speech recognition hypothesis to various intents corresponding to an action in an audio dialog that operates according to various static and dynamic parameters (e.g., a script and entities mentioned in a user utterance) and a stored script having dialog states with corresponding intents, Col. 1, Line 57- Col. 2, Line 36; Col. 5, Lines 18-52 (describing moving between dialog states and active states), Col. 9, Lines 52-60; Col. 10, Lines 28-46; Col. 15, Lines 44-53; Col. 29, Lines 49-60; Col. 44, Line 55- Col. 45, Line 2; Col. 48, Lines 48-66 (describing activation of different dialog states)).
With respect to Claim 18, Ryabov further discloses:
The system of claim 1, wherein during a callback from the framework, the processor executing the framework provides to the program a partial or complete speech recognition hypothesis, and the program classifies the hypothesis as a valid user intent, an incomplete user utterance, or an unrecognized user utterance, and may request the processor executing the framework to handle an unrecognized or rejected hypothesis according to predefined VoiceFlow logic (during callbacks and command handling- classification via matching of a recognized utterance hypothesis to a valid user intent in the application context, Col. 2, Lines 22-36; Col. 10, Lines 28-46; Col. 15, Lines 44-53; Col. 29, Lines 49-60; and Col. 33, Lines 16-42; note that although optional and not required in the claim, correction or modification of a hypothesis is discloses, Col. 4, Lines 37-55).
With respect to Claim 19, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework compares the program's intent classification of a partial or complete speech-recognition hypothesis to a list of valid user intents configured in an "audio dialog" or "audio listener" Voice Flow Module, and continues processing the current module or transitions to another module based on static or dynamic transition parameters defined for the current Voice Flow Module and stored within the VoiceFlow (matching various intents corresponding to an action in an audio dialog that operates according to various static and dynamic parameters (e.g., a script and entities mentioned in a user utterance) and a stored script having dialog states with corresponding intents, Col. 1, Line 57- Col. 2, Line 36; Col. 5, Lines 18-52 (describing moving between dialog states and active states), Col. 9, Lines 52-60; Col. 10, Lines 28-46; Col. 15, Lines 44-53; Col. 29, Lines 49-60; Col. 44, Line 55- Col. 45, Line 2; Col. 48, Lines 48-66 (describing activation of different dialog states)).
With respect to Claim 20, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes an "audio listener" Voice Flow Module configured within the VoiceFlow (software modules that enable a listening mode for audio playback, Col. 11, Lines 52-64; Col. 12, Lines 26-40; Col. 12, Line 58- Col. 13, Line 13; and Col. 16, Lines 35-67), the Voice Flow Module causing the processor to play audio from an Audio Prompt Module that references either statically configured audio segments or audio segments that the program configures dynamically during a callback from the framework at the beginning of processing the "audio listener" Voice Flow Module (audio segments played back are statistically related to the user utterance/intent, Col. 11, Lines 23-51; Col. 12, Lines 3-40; Col. 15, Line 44- Col. 16, Line 47).
With respect to Claim 21, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes an "audio listener" Voice Flow Module configured within the VoiceFlow, the processor initiates a callback to the program upon completion of audio playback of an audio segment, during which the program may reconfigure another audio segment or a plurality of audio segments for subsequent playback, and the processor continues this cycle after each playback event until the program does not provide additional audio segments, at which time the processor ends execution of the "audio listener" Voice Flow Module (callback and event handling that involves the update of an interface object and the playback of an ordered sequence of "audio...responses" (i.e., after playback of one is completed, the next is played back), Col. 33, Lines 1-42 and Col. 34, Lines 5-32; note on claim interpretation under the BRI- the limitations following "may" and thus are only optional. Accordingly, the prior art need not teach these limitations to anticipate or render obvious the claim optional language).
With respect to Claim 22, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework interprets and processes an "audio listener" Voice Flow Module configured within the VoiceFlow, the processor performs consecutive speech recognition tasks that are not synchronized with the start or end of audio segment playbacks, captures from the user partial or complete speech recognition hypotheses, passes the hypotheses to the program through a callback interface during playback of the configured audio segments, and processes the program's classified intent to determine a next system action (listened to/heard voice commands can be received before playback of audio and captured audio data may include a sequence of more than one voice command (see "at least one") that are matched with intent patterns to determine a system action wherein a callback/event handling for the user command sequence occurs that leads to generation of a playback response sequence in the order of receipt/processing, Col. 8, Line 53- Col. 9, Line 8; Col. 9, Lines 52-60; Col. 10, Lines 11-27; Col. 15, Lines 5-19 (describing the parsing a sequential voice commands); Col. 33, Lines 1-42; and Col. 34, Lines 5-32 (describing ordered responses)).
With respect to Claim 23, Ryabov further discloses:
The system of claim 1, wherein the processor executing the framework monitors VoiceFlow processing and notifies the program through a registered event-listener interface or a callback interface with real-time events and corresponding data generated by Voice Flow Module execution (callbacks/event handlers that monitors and updates the application program within a dialog session, Col. 33, Lines 16-42 and Col. 34, Lines 5-32), Audio Prompt Module processing, audio segment playback, audio recording, speech recognition, program state changes, audio session interruptions, and updates to media availability and permissions, enabling the program to adapt its execution while the user is interacting with the program (other events covered include audio prompting (system voice response that initiates another user command with a dialog flow, Col. 44, Lines 1-34), audio segment playback (e.g., a voice response, Col. 33, Lines 36-37), audio recording (capture of audio data, Col. 8, Line 53-Col. 9, Line 8), speech recognition (Col. 4, Lines 37-55 and Col. 29, Lines 9-44), program GUI visual state (Col. 4, Line 60- Col. 5, Line 17), interruptions to the functioning of the audio session (e.g., via turning off or deactivation, Col. 24, Lines 46-52), and media availability and permissions based upon state (Col. 5, Lines 18-32, Col. 17, Lines 6-41; Col. 9, Lines 19-40; Col. 14, Line 54-Col. 15, Line 3, Col. 20, Lines 1-24; Col. 21, Lines 38-58; Col. 25, Lines 40-55; Col. 28, Line 53- Col. 29, Line 8); note that these steps meet the claimed intended result of dynamically adjusting the user voice interface during interaction within a dialog).
With respect to Claim 24, Ryabov further discloses:
A media-processing framework implemented on a computing device, comprising a processor (processor, Col. 21, Line 59- Col. 22, Line 5) and memory (memory storing program instructions, Col. 22, Lines 28-36) storing instructions that:
instantiate a runtime object for a client application (the application instantiates various runtime objects (e.g., interface elements), Col. 8, Lines 25-42 and see Fig. 7 as an example);
register the client to receive real-time media event notifications (module registering/receiving real-time event notifications including visual/dialog states, entity/media availability, and restrictions or permission to user voice models based on identity, Col. 5, Lines 18-32, Col. 17, Lines 6-41; Col. 9, Lines 19-40; Col. 14, Line 54-Col. 15, Line 3, Col. 20, Lines 1-24; Col. 21, Lines 38-58; Col. 25, Lines 40-55; Col. 28, Line 53- Col. 29, Line 8);
execute a media-event notifier to transmit structured media-event data to the client (event registration within the application program responsive to a voice framework input (e.g., a real-time notification of a visual event or instruction based upon voice), Col. 6, Lines 21-34; Col. 8, Lines 3-24; Col. 8, Line 53- Col. 9, Line 8; Col. 12, Lines 3-23; and Col. 29, Lines 29-39);
allocate an audio session controlling device audio hardware (provided audio hardware such as a microphone for voice capture, display for a GUI, and a speaker for playback, Col. 7, Lines 5-18);
instantiate an audio recorder to read raw audio from device microphones, local or
remote Uniform Resource Locator (URL) sources, and multiple local or remote speech-synthesis engines (run-time/execution object that performs media functions on the device including voice recording and audio capture/receiving for playback (e.g., remote text-to-speech synthesis engine, via access of a remote URL that is inherent within the discussion of a web page application), Col. 7, Lines 19-34; Col. 8, Lines 3-24; Col. 24, Line 64-Col. 25, Line 14; Col. 17, Lines 17-28; Col. 31, Lines 54-60; Col. 34, Lines 5-32);
instantiate an audio player (various forms of audio capture for input from a user or output for response in the citations that follow) to write raw audio to device speakers (Col. 7, Lines 5-18), local or remote URL destinations (web page application as an URL destination, Col. 8, Lines 3-24), voice-activity-detection modules (Col. 28, Lines 39-46), (ASR and NLU modules, Col. 4, Lines 34-59 and Col. 40, Lines 26-39);
execute real-time streaming processes to transmit the raw audio and associated metadata among sources and destinations (voice interface interactions between user and application are performed in real-time via streaming including "raw encoded voice data" and "metadata", Col. 14, Lines 33-53; Col. 17, Lines 18-21; Col. 27, Line 66- Col. 28, Line 10; and Col. 33, Lines 43-62); and
detect and report, to the client, real-time media-event updates comprising audio
session, media availability, and media permission changes (module registering/receiving real-time event notifications including visual/dialog states, entity/media availability, and restrictions or permission to user voice models based on identity, Col. 5, Lines 18-32, Col. 17, Lines 6-41; Col. 9, Lines 19-40; Col. 14, Line 54-Col. 15, Line 3, Col. 20, Lines 1-24; Col. 21, Lines 38-58; Col. 25, Lines 40-55; Col. 28, Line 53- Col. 29, Line 8).
Although Ryabov further teaches the elimination of audio data corresponding to background noise (Col. 14, Line 54- Col. 15, Line 4), Ryabov does not specifically teach the elimination of echoes or echo cancellation. Wright, however, discloses this well-known form of audio pre-processing (Paragraph 0108).
Ryabov and Wright are analogous art because they are from a similar field of endeavor in human-machine speech interfaces. Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the teachings of Ryabov with the echo cancellation taught by Wright to provide a predictable result of eliminating another type of audio that might have been captured by accident and does not correspond to a user's intended speech input (Ryabov, Col. 14, Line 54- Col. 15, Line 4).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Ryabov, et al. in view of Wright, et al. and further in view of Vishnoi, et al. (U.S. PG Publication: 2020/0342850 A1).
With respect to Claim 8, Ryabov in view of Wright discloses the voice framework for voice dialog interactions within a client application as applied to Claim 1. Although Ryabov uses callbacks (Col. 33, Lines 16-42) and an application API (Col. 8, Line 53- Col. 9, Line 18) to carry out operations via voice in a program application, Ryabov in view of Wright does not teach the resumption of audio playback after an audio-session-end interruption at a specific time position within a specific audio segment whose playback state was previously created, retrieved, updated, or deleted.
Vishnoi, however, discloses the resumption of audio playback after an audio-session-end interruption at a specific time position within a specific audio segment whose playback state was previously created, retrieved, updated as a current state, and then deleted as a current state upon an interruption (Paragraphs 0165-0174- in particular see the replay of the "How old are you?" prompt when the user switches to a finance dialog).
Ryabov, Wright, and Vishnoi are analogous art because they are from a similar field of endeavor in human-machine speech interfaces. Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify the teachings of Ryabov in view of Wright with the ability to pick up a past prompt after an interruption taught by Vishnoi to predictably allow a user to seamlessly switch between dialogs and better recall the past step of the resumed dialog.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 25 is rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ryabov, et al.
With respect to Claim 25, Ryabov discloses:
A computer-implemented method executed by a processor in a computing device for
allocating and operating a Voice Flow Framework interface instance, comprising:
instantiating the Voice Flow Framework interface instance for a program (enable a voice-supporting software module framework for processing API requests from an application running on a client device, Col. 8, Line 53- Col. 9, Line 18);
allocating an audio session having audio-session property descriptors including at
least one of sampling rate, channel count, latency mode, device selection, buffer
size, or routing policy (device-based selection of a particular application that allocates specific resources to allow different functionality, Col. 9, Lines 9-40; dialog scripts relating to/associated with the specific application, Col. 4, Line 60- Col. 5, Line 42);
assigning media resources including an audio player (software module for playback of audible media, Col. 7, Lines 19-34; Col. 11, Lines 52-64; Col. 12, Line 58- Col. 13, Line 13; Col. 16, Lines 35-48; and Col. 24, Line 64-Col. 25, Line 14), audio recorder (Col. 7, Lines 7-18; Col. 8, Line 43- Col. 9, Line 8; and Col. 18, Lines 38-46), speech recognizer ASR and NLU modules, Col. 4, Lines 34-59 and Col. 40, Lines 26-39), and speech synthesizer (text-to-speech generation engine, Col. 31, Lines 54-57; Col. 34, Lines 5-32);
providing a callback function enabling the program to receive and process real-time
events from the framework (callback functionality that receives events that trigger various actions in the application program in real-time, Col. 33, Lines 26-61; Col. 43, Lines 31-63; Col. 44, Lines 15-34);
registering an event listener to receive real-time event notifications from the framework (event registration within the application program responsive to a voice framework input (e.g., a real-time notification of a visual event, voice response, or instruction based upon voice), Col. 6, Lines 21-34; Col. 8, Lines 3-24; Col. 8, Line 53- Col. 9, Line 8; Col. 12, Lines 3-23; Col. 29, Lines 29-39; and Col. 34, Lines 5-32); and
loading and processing groups of configured data structures comprising VoiceFlows and Audio Prompt Modules to perform speech-enabled conversational interactions between the program and a user (assistive voice control software modules loaded for an application that process data structures (e.g., interface elements, program operations, etc.) of an application program to understand user speech and carry out voice responses or actions within the application, Col. 4, Lines 4-25; Col. 5, Lines 33-52; Col. 8, Lines 3-24; Col. 10, Lines 11-28; Col. 17, Lines 18-41; and Col. 44, Lines 1-44).
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 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 JAMES S WOZNIAK whose telephone number is (571)272-7632. The examiner can normally be reached 7-3, off alternate Fridays.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant may 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, Andrew Flanders can be reached at (571)272-7516. 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.
JAMES S. WOZNIAK
Primary Examiner
Art Unit 2655
/JAMES S WOZNIAK/Primary Examiner, Art Unit 2655