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 .
DETAILED ACTION
Claims 1-8, 10-14 and 16-22 are pending. Claims 1, 12 and 16 are independent and have been amended. Claim 22 is new and depends from 1.
This Application was published as U.S. 20240046923.
Apparent priority: 2 August 2022.
Applicant’s amendments and arguments are considered but are either unpersuasive or moot in view of the new grounds of rejection that were necessitated by the amendments.
This action is Final.
Response to Amendments and Arguments
Parts of the Applicant’s arguments are not supported by the language of the Claim. Please first rely on the Language Inside the Claim for the arguments and then use the supporting Specification for interpretation purposes.
Claim 1 is amended as follows:
1. A computer-implemented method of query processing comprising:
receiving, from a user, a setting expression including a query representing information to be provided or an action to be performed, and a condition specifying a situation for triggering the query;
extracting, by natural language interpretation, the query and the condition;
determining a query domain that identifies a domain to which the query belongs;
determining whether the query domain is included in a list of domains applicable to the user;
storing the query and the condition as registration information in association with the user, in response to determining that the query domain is included in the list of domains applicable to the user;
monitoring, by obtaining data corresponding to a trigger type defined in the registration information, for occurrence of the situation specified by the condition; and
in response to determining that the situation has occurred, initiating a proactive interaction with the user by outputting an inquiry expression that is generated from the query in the stored registration information and that includes a question that requests an answer meaning affirmative or negative from the user; and
in response to receiving an affirmative answer to the inquiry expression from the user, generating and providing the information to be provided or performing an action to be performed within the query domain.
Claim 16 is a system counterpart of method Claim 1 and Claim 12 is another method claim like 1 but broader by missing the limitation “extracting, by natural language interpretation, the query and the condition.”
12. A computer-implemented method of query processing comprising:
receiving, from a user, a setting expression including a query and a condition specifying a situation for triggering the query;
determining a query domain that identifies a domain to which the query belongs;
determining whether the query domain is included in a list of domains applicable to the user;
storing the query and the condition as registration information in association with the user, in response to determining that the query domain is included in the list of domains applicable to the user;
monitoring, by obtaining data corresponding to a trigger type defined in the registration information, for occurrence of the situation specified by the condition; and
in response to determining that the situation has occurred, initiating a proactive interaction with the user by outputting an inquiry expression that is generated from the query in the stored registration information and that includes a question that requests an answer meaning affirmative or negative from the user; and
in response to receiving an affirmative answer to the inquiry expression from the user, generating and providing the information to be provided or performing an action to be performed within the query domain.
Applicant has referred to [0129]-0130] of the Specification as filed and Figures 18-19 as support. Paragraph 129-130 correspond to the following paragraphs of the published Application:
[0115] Referring to FIG. 18, in step S120, main server 100 determines whether or not the domain specified in step S118 is included in a list. The list means a list of domains applicable to user 300. In one implementation, the list is stored in storage 103. When main server 100 determines that the domain is included in the list (YES in step S120), control proceeds to step S122. When main server 100 determines that the domain is not included in the list (NO in step S120), control proceeds to step S140.
[0116] Referring to FIG. 19, in step S140, main server 100 instructs user terminal 200 to give a notification about failure of setting. Thereafter, main server 100 ends the process.
New Claim 22 pertains to frame and slot filling which is well-known. Claim 22 is supported by the following Figures 8-14 and their description.
“
PNG
media_image1.png
263
359
media_image1.png
Greyscale
PNG
media_image2.png
155
354
media_image2.png
Greyscale
PNG
media_image3.png
164
343
media_image3.png
Greyscale
PNG
media_image4.png
162
378
media_image4.png
Greyscale
PNG
media_image5.png
168
375
media_image5.png
Greyscale
PNG
media_image6.png
157
358
media_image6.png
Greyscale
PNG
media_image7.png
166
341
media_image7.png
Greyscale
Yao:
Applicant argues:
PNG
media_image8.png
84
651
media_image8.png
Greyscale
PNG
media_image9.png
67
648
media_image9.png
Greyscale
Response 11-12.
In Reply: An API is an interface to an application that executes a command and performs a function. The API does not take away from the command/query and control/response characteristics of the application that it interfaces; it merely provides an interface to it.
As indicated by the Applicant, Yao teaches the command and condition/trigger of the Claim. See Figure 6 of Yao below.
PNG
media_image10.png
441
654
media_image10.png
Greyscale
Applicant next argues the “determining whether the query domain is included in a list of domains applicable to the user;”:
PNG
media_image11.png
126
659
media_image11.png
Greyscale
PNG
media_image12.png
116
654
media_image12.png
Greyscale
Response 12-13.
In Reply: This concept is not developed in the instant Application and the Specification merely provides:
“[0115] Referring to FIG. 18, in step S120, main server 100 determines whether or not the domain specified in step S118 is included in a list. The list means a list of domains applicable to user 300. In one implementation, the list is stored in storage 103. When main server 100 determines that the domain is included in the list (YES in step S120), control proceeds to step S122. When main server 100 determines that the domain is not included in the list (NO in step S120), control proceeds to step S140.”
Yao has a list of actions corresponding to a trigger condition which can be construed as applicable to the user at the time and considering the context/conditions. References that search through the actions/domains/functions according to context abound. This limitation, despite the dearth of explanation in the Specification, is narrowly interpreted to mean a list of domains that are applicable to the user irrespective of the surrounding context (satisfaction of the trigger condition is a type of context).
Yao teaches does ““determining whether the query domain is included in a list of domains applicable to the user;” which is claimed but does not teach a list of domains applicable to the user irrespective of the context and the Specification appears to have intended such a list.
Accordingly, Neff was added while Yao is sufficient for the current Claim language.
Applicant next argues the “a question that requests an answer meaning affirmative or negative from the user;” feature:
PNG
media_image13.png
126
671
media_image13.png
Greyscale
PNG
media_image14.png
149
665
media_image14.png
Greyscale
Response 14.
In Reply, Neff is cited for this feature.
However, Yao teaches user confirmations in Figures 2 and 8 both.
Figure 8 that is provided below included “provide audio/visual feedback/confirmation 808” which expressly includes “confirmation” by the user and the description also includes the options to cancel or modify by the user.
PNG
media_image15.png
545
679
media_image15.png
Greyscale
Yao: “[0040] …In addition, to confirm with user, the system can provide a voice feedback via voice output 205 if a speaker is present, and/or a visual feedback via visual output 206 if a display is present. The feedback includes enough details to notify the user with what the system has understood and options to cancel/modify API calls should the user desires.”
Yao as shown in the mapping below does teach the storing of the query. “[0041] The task configuration and their APIs are then stored in task configuration database 230. An example of task configuration database 230 is shown in FIG. 6 according to one embodiment….”
Other examples of back and forth between the user and the system are present in Yao such as those shown in Figure 2 below.
PNG
media_image16.png
483
702
media_image16.png
Greyscale
Li and Badr
Li and Badr are replaced with Neff that teaches both function list and confirmation as well as vehicle dependence. Applicant’s arguments are moot in view of the new grounds of rejection necessitated by the amendments.
Neff is used because it has all the confirmation feature, function/domain list of a user, and in the context of a vehicle and is justified by the amendments to the Claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-8, 10, 12-14, 16, 18-19 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Yao (U.S. 20190129938) in view of Neff (U.S. 20170169823).
Regarding Claim 1, Yao teaches:
1. A computer-implemented method of query processing comprising: [Yao, Figure 1, input of “voice input 203” or “text input 204” at the “input interface 201” and receiving “voice output 205, “text output 206” or “network command output 208” at the “output interface 202.” Figure 9, shows the hardware including processing modules 1528, processors 1501, memory 1503, storage device 1508 and other peripherals. “Embodiments of the invention provide a natural language understanding (NLU) system that performs relatively complex task automations via verbal or voice instructions. Normally, task automations have a trigger condition, and a series of one or more actions that would require a user's selection of an option via manual input. This is because the underlying machine logic requires knowledge and classification capabilities from multiple domains that conventional personal assistants are not capable of. Embodiments of the inventive system and methods provide a solution to this complex task by analyzing trigger and action domains, pinpointing appropriate APIs, extracting corresponding API parameters, and automatically fulfilling API calls for the user. The system is configured to parse natural language commands into API calls. It analyzes both the trigger and action APIs and prompts a user for any missing information if necessary.” Abstract.]
receiving, from a user, a setting expression including a query representing information to be provided or an action to be performed, and a condition specifying a situation for triggering the query; [Yao, Figure 7, “receive an input text originated from a user to perform an action in response to a condition 701.” The action teaches the query and the condition teaches the condition of the Claim. Figure 6: “When I get home, turn on my lights.”]
extracting, by natural language interpretation, the query and the condition; [Yao, Figure 7, 702 performs NLP on the input: “[0052] …In operation 702, processing logic performs an NLP operation on the input text to determine a first domain associated with the condition and a second domain associated with the action….” See also Figure 8, 802. Note that “query” of the Claim is taught by “action” of Yao and “condition” of the Claim is taught by the “trigger condition” of Yao. “[0018] Accordingly, embodiments of the invention provide a natural language understanding (NLU) system that performs relatively complex task automations via verbal or voice instructions. Normally, task automations have a trigger condition, and a series of one or more actions that would require a user's selection of an option via manual input…”]
determining a query domain that identifies a domain to which the query belongs; [Yao, the challenge that Yao sets out to resolve is identifying the domain of the command/query/task stated by the user: “[0003] … Challenges arise when a system needs to identify multiple intentions from various domains in a single complex sentence. ….” Figure 6 shows a mapping of the Domains to Tasks and Actions associated with the tasks. Figure 7, 702, the domains pertaining to the input command/query are determined by performing NLP on the input. Figure 8, 802 also includes determining the domain/API from the voice input at 801. “[0023] Based on the NLP operation, a first domain associated with the condition and a second domain associated with the task are determined. A domain may simply be a name or term mentioned in the input text. Alternatively, a domain may be determined based on the NLP operation that understands the user's intent.”]
determining whether the query domain is included in a list of domains applicable to the user; [Yao does not teach a list of domains applicable to the user. Rather, Yao refers to a list of domains that satisfy a trigger condition that is present at the time of the command. Figure 7, 704 and 705.]
storing the query and the condition as registration information in association with the user, in response to determining that the query domain is included in the list of domains applicable to the user; [Yao, Figure 7, the remaining steps require that the input (including the command/action/query and the condition) to be stored on the memory first. See also Figure 6 and “[0041] The task configuration and their APIs are then stored in task configuration database 230. An example of task configuration database 230 is shown in FIG. 6 according to one embodiment….” Figure 6 includes the Task 601 including the Trigger 602 and the Action/Command/Query 603. This step can also be mapped to “task configuration database 230” of Figure 3 shown in Figure 6, “[0041] The task configuration and their APIs are then stored in task configuration database 230. An example of task configuration database 230 is shown in FIG. 6 according to one embodiment….”]
monitoring, by obtaining data corresponding to a trigger type defined in the registration information, for occurrence of the situation specified by the condition; and [Yao: “[0048] For example, extended from the above example, a user may say “when I get home, turn on my lights and send a text to my wife that I arrived home.” In this particular example, there is one trigger API for location services, a first action API to turn on the smart lights, and a second action API to send a text to user's wife…” “[0049] One or more actions can also be performed in response to multiple trigger API calls. For example, a user can say “when I get home and at sunset, turn on my lights and turn my thermostat to 70 degrees.” In this situation, there will be at least two trigger API calls: 1) location service, 2) weather service, and/or 3) time service. There will be at least two action API calls: 1) smart lights and 2) thermostat.” The conditions of getting home and sunset have to be satisfied before the command/action is carried out. “[0024] The first API is referred to as a trigger API and the second API is referred to as an action API. Task manager 120 is configured to monitor the trigger API to detect any notification or event, for example, in a form of a message or signal, received from a first application via the first API. In response to a notification or event received from the trigger API, task manager 120 and/or NLU system 110 examines the notification or event to determine whether the condition specified in the input text has been satisfied. If it is determined that the condition has been satisfied, task manager 120 transmits a control command, for example, in a form of a request, to a second application via the second API. The control command includes information or parameter(s) to request the second application to perform the task specified by the input text.” “[0041] The task configuration and their APIs are then stored in task configuration database 230. An example of task configuration database 230 is shown in FIG. 6 according to one embodiment. Task manager 120 then monitors the API events and sends control commands to proper APIs to perform the requested tasks in response to the proper API events.”]
in response to determining that the situation has occurred, initiating a proactive interaction with the user by outputting an inquiry expression that is generated from the query in the stored registration information and that includes a question that requests an answer meaning affirmative or negative from the user; and [Yao, Figure 8, 808: “Provide voice/visual Feedback/Confirmation.” According to the examples provided by the instant Application (and Figure 15 of the instant Application) the intent from “inquiry expression” is a “confirmation question” which is also taught by Yao: “[0040] …In addition, to confirm with user, the system can provide a voice feedback via voice output 205 if a speaker is present, and/or a visual feedback via visual output 206 if a display is present. The feedback includes enough details to notify the user with what the system has understood and options to cancel/modify API calls should the user desires.” Figure 8, “[0054] In operation 803, processing logic determine whether there is any ambiguity regarding the domains associated with the input. If so, in operation 804, processing logic prompts the user to clarify and resolve the ambiguity. Otherwise in operation 805, processing logic determines API parameters for the domain APIs. In operation 806, processing logic determines whether there is any parameter missing. If so, in operation 807, processing logic may prompt the user for missing parameter. Alternatively, processing logic invokes an external information provider or third-party vendor to obtain the missing parameters. Otherwise in operation 808, processing logic optionally provides audio and/or visual feedback to the user to confirm what the system understands and the actions will be performed. In operation 809, processing logic monitor a trigger API and in response to a trigger event, performs the configured action via an action API.”]
in response to receiving an affirmative answer to the inquiry expression from the user, generating and providing the information to be provided or performing an action to be performed within the query domain. [Yao performs the task once the condition is satisfied or the ambiguities are resolved by answers from the user. Figures 7 and 8 or Yao. “[0024] The first API is referred to as a trigger API and the second API is referred to as an action API. Task manager 120 is configured to monitor the trigger API to detect any notification or event, for example, in a form of a message or signal, received from a first application via the first API. In response to a notification or event received from the trigger API, task manager 120 and/or NLU system 110 examines the notification or event to determine whether the condition specified in the input text has been satisfied. If it is determined that the condition has been satisfied, task manager 120 transmits a control command, for example, in a form of a request, to a second application via the second API. The control command includes information or parameter(s) to request the second application to perform the task specified by the input text.”]
Yao has a list of actions corresponding to a trigger condition which can be construed as applicable to the user at that time. Yao is sufficient for the Claim language. Yao does not expressly teach a list of domains applicable to the user irrespective of the context and the Specification appears to have intended such a list and to expedite prosecution a reference is added that fits a narrow interpretation of the limitation.
A confirmation is often in the shape of a question: You asked for the lights to be turned on; right? However, Yao does not expressly teach question-format confirmations and a reference is added which teaches this feature expressly.
Neff teaches:
determining whether the query domain is included in a list of domains applicable to the user; [Neff teaches a list that can be provided by the user and thus teaches the “list of domains applicable to the user” of the Claim and is a list of those functions/domains that may be carried out if they are found in the NL command: “[0083] Preferred embodiments can provide that before a control command and/or a test specification is carried out, a check is performed as to whether the control command and/or the test specification is permissible. This check can preferably be carried out by the data acquisition unit (for example a central control device of the vehicle). For this purpose, it can particularly be provided that acquisition of the vehicle-specific data by the data acquisition unit comprises acquisition of those vehicle functions to which access by means of voice control is permitted. For safety reasons, it can be advantageous to draw up a positive list of all the vehicle functions that are accessible by voice control. Vehicle functions that are not included in the positive list are then not carried out. For these cases, a standardized message to the user can be provided, for example: “Sorry, this function cannot be operated by a voice command.” It can be provided that the vehicle user can adapt the positive list manually. In particular, the user can be given the possibility of prohibiting specific functions and/or data for the method according to the invention. In this way, a user's need for data privacy, for example, can be taken into account.”]
…
in response to determining that the situation has occurred, initiating a proactive interaction with the user by outputting an inquiry expression that is generated from the query in the stored registration information and that includes a question that requests an answer meaning affirmative or negative from the user; and [Neff, “[0084] Particularly preferably, it can also be provided that specific vehicle functions can be accessed only after repeat confirmation by the user. For example, the server could transmit “Open all the windows” in response to the voice command “Open all the windows.” However, it can be provided that this control command is only output if the user confirms it (by means of voice control or by means of other operating elements) after the spoken request “Do you really want to open all the windows?” This additional checking step can be carried out locally in the vehicle. Alternatively, it can be provided by the server. In this case, it is transmitted as a test specification, as part of the response message.”]
in response to receiving an affirmative answer to the inquiry expression from the user, generating and providing the information to be provided or performing an action to be performed within the query domain. [Neff, only if the user confirms then the windows are opened/ action is performed.]
Yao and Neff pertain to query and response or task assignment dialog systems and it would have been obvious to combine the expressly shown question-type confirmation and access control list of Neff with the system of Yao which teaches confirmation feedback but does not expressly include that the confirmation is in the form of question for completeness and to have an access list for the user for added security so unwanted or unauthorized functions are not activated. A confirmation must almost always (inherently) be in the form of a question but a feedback may be a mere announcement. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Regarding Claim 2, Yao teaches:
2. The computer-implemented method according to claim 1, wherein the inquiry expression further comprises added content based on a type of the query. [Yao, Figure 3, “API Parameter Determination Module 214” collects data/parameters/content to be added to the Query/Command/Domain API.]
Regarding Claim 3, Yao teaches:
3. The computer-implemented method according to claim 1,
wherein the setting expression is received as voice input and converted into text using speech recognition. [Yao, Figure 8, 801: “receive a voice/text input.” See also Figures 2 and 3 and “voice input 203.” “[0047] … The user can directly speak to its mobile phone and transcribed text can be captured by NLU system 110 and processed by task manager 120 as described above….” Transcription teaches speech recognition. See also: “[0053] … Referring to FIG. 8, in operation 801, processing logic receives a text input. The text input may be converted from a voice phrase or sentence spoken by a user or a recorded audio stream using speech recognition….”]
Regarding Claim 4, Yao teaches:
4. The computer-implemented method according to claim 1, further comprising
obtaining an input of a specific message, wherein accepting the setting expression is performed in response to obtaining the specific message. [Yao, Figure 8, if the trigger and the action are considered ambiguous at 803, the system goes to “Prompt user to clarify 804” the response to which at “receive a voice/text input 801” teaches “obtaining an input of a specific message” of the Claim.] (The “specific message” requires to be defined with further particularity in the Claim. The specification appears to be looking for pre-stored formats. Figure 16, S102, and [0102] and [0143]. “[0102] …An exemplary registration message is “set a query and condition.”….”)
Regarding Claim 5, Yao teaches:
5. The computer-implemented method according to claim 1, further comprising:
identifying grammar with which the query matches by natural language interpretation of the query; [Yao, Figure 3 shows the flow of information in an “NLU system 110” which receives the input from the user (204 or 207). “[0029] …In one embodiment, domain determination module 211 determines one or more domains using a domain predictive model 221, which is configured to predict a domain based on a phrase, term, or sentence of the input text….” Predicting/determining a domain based on “sentence” teaches “identifying grammar” of the Claim.] (Note the definition in the instant Application which refers to a sentence structure. [0047].)
identifying a domain to which the grammar belongs; [Yao, Figure 3, “Domain Determination Module 211.” “[0029] In response to a text input, domain determination module 211 is configured to determine one or more domains associated with the input text using an NLP process. …”]
determining whether the domain is registered in a list stored in the memory; and [Yao, Figure 5 showing a correspondence between a Domain 501 and or more APIs 502. “[0031] API determination module 212 may perform a search in an API database based on a domain to obtain an API corresponding to the domain. Specifically, according to one embodiment, API determination module 212 performs a lookup operation in domain/API mapping table 222 based on a domain identifier (ID) determined by domain determination module 211. An example of domain/API mapping table 222 is shown in FIG. 5 according to one embodiment. Referring to FIG. 5, domain/API mapping table 500 may represent domain/API mapping table 222 of FIGS. 2 and 3. Domain/API mapping table 500 contains a number of mapping entries.….”]
avoiding registration of the query and the condition in the memory in response to the domain not being registered in the list. [Yao, Figure 3, this limitation is the inevitable result of not finding the corresponding API for a domain from the table of Figure 5. In Figure 3, if the process goes well and the Domain and its corresponding APIs are determined, the process moves to “Task Manager 120” and “[0041] The task configuration and their APIs are then stored in task configuration database 230. …” However, in Figure 3, there has to be an “API Determination 212” as a result of “Domain/API mapping tables 222” in order for the process to move forward to collecting parameters and then to the execution of the API. When no API is determined at 212, the process cannot progress; no alternative path is provided. Accordingly, no storing of the task configuration 230 / “registration of the query and condition” can take place.]
Regarding Claim 7, Yao teaches:
7. The computer-implemented method according to claim 1, further comprising:
specifying a type of the query based on the setting expression; and [Yao, Figure 3, Domain Determination at 211 and 221. See [0048]-[0049] for examples of Domain/Query Type determination for “when I get home, turn on my lights and send a text to my wife that I arrived home,” “when I get home, turn on my lights and turn my thermostat to 70 degrees,” “when I get home and at sunset, turn on my lights and turn my thermostat to 70 degrees.”]
generating the inquiry expression based on the type. [Yao, Figure 3, the API calls by the “Task Manager 120” are generated in response to the Domain/Query type that is determined at 211 and 212 and the API parameters that are collected by the NLU system 110.]
Regarding Claim 8, Yao teaches:
8. The computer-implemented method according to claim 7, wherein the type identifies contents to be added to the query in the inquiry expression. [Yao, Figure 3, “API Parameter Determination Module 214” collects data/parameters/content to be added to the Query/Command/Domain API.]
Regarding Claim 10, Yao, Figure 5, “location services” are included in the domains 501. “A location service (e.g., GPS application)” ([0030]) generally pertains to driving but not necessarily.
Neff teaches:
10. The computer-implemented method according to claim 1,
wherein the situation includes a situation relating to a vehicle. [Neff is directed to voice control of a motor vehicle. Thus the condition/situation of the task relates to the operating data of the vehicle.]
Yao and Neff pertain to conditional performance of tasks and functions and it would have been obvious to combine the data from the vehicle as the condition for the task from Neff with the system of Yao which hints at a user in transit to his home. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Regarding Claim 12, Yao teaches:
12. A computer-implemented method of query processing comprising:
receiving, from a user, a setting expression including a query and a condition specifying a situation for triggering the query; [Yao, refer to the rejection of Claim 1.]
determining a query domain that identifies a domain to which the query belongs; [Yao, refer to the rejection of Claim 1.]
determining whether the query domain is included in a list of domains applicable to the user; [Yao and Neff, refer to the rejection of Claim 1.]
storing the query and the condition as registration information in association with the user, in response to determining that the query domain is included in the list of domains applicable to the user; [Yao and Neff, refer to mapping of Claim 1.]
monitoring, by obtaining data corresponding to a trigger type defined in the registration information, for occurrence of the situation specified by the condition; and [Yao, refer to the rejection of Claim 1.]
in response to determining that the situation has occurred, initiating a proactive interaction with the user by outputting an inquiry expression that is generated from the query in the stored registration information and that includes a question that requests an answer meaning affirmative or negative from the user; and [Yao and Neff, refer to the rejection of Claim 1.]
in response to receiving an affirmative answer to the inquiry expression from the user, generating and providing the information to be provided or performing an action to be performed within the query domain. [Yao and Neff, refer to the rejection of Claim 1.]
Claim 12 is like Claim 1 except that it has been broadened to exclude the “extracting, by natural language interpretation, the query and the condition” which is part of Claim 1.
Regarding Claim 13, Yao teaches:
13. The computer-implemented method according to claim 12, further comprising:
receiving, by a terminal, the setting expression via voice; and [Yao, Figures 2 and 3, “Voice Input 203.”]
transmitting, by the terminal, the setting expression to a server. [Yao, Figure 1, “Servers 103” and “Information Sources 104” and “IoT devices 102” all of which can be servers ([0021]) in communication with “other devices (e.g., smart phones) 105.” Figure 4 shows the communication with “External Information Sources 104” which are servers and [0021] teaches that commands to household items are transmitted to “IoT device 102” which can be servers. “[0021] … IoT devices can be any device that is accessible via the Internet, such as, for example, smart lights, thermostats)…..”]
Regarding Claim 14, Yao teaches:
14. The computer-implemented method according to claim 13, further comprising
transmitting, by the terminal to the server, data for determination as to whether the situation specified by the condition has occurred. [Yao, Figure 3, “external information sources 104” which can be servers may perform some determinations on the input command that is outside the capabilities of the NLU System 110 such as image identification. “[0050] According to one embodiment, in some situations, if there is an API parameter that cannot be determined, the system may invoke an external help by accessing an external information provider to obtain the information that is helpful to determine the missing API parameter. For example, a user may say “if I add a photo to Instagram, change my room lights to match its theme or subject matter.” In this example, there is a trigger API of Instagram to determine a new photo has been added and an action API to configure smart lights. However, one of the parameters associated with the smart lights in this example will be: 1) color and/or 2) emitting or flashing patterns. In order to determine the parameters of the smart lights, the theme or subject matter of the photo has to be determined. The system may or may not be equipped with such a capability to determine the theme or subject matter of a photo (e.g., indoor vs. outdoor, city vs. rural area, or sunny day vs. raining day). Accordingly, the system can invoke an external or third-party service provider (e.g., information provider system 104) to perform an image analysis on the photo via a separate API communication protocol.”]
Claim 16 is a system claim with limitations corresponding to the limitations of Claim 1 and is rejected under similar rationale. Additionally:
Yao teaches:
16. A system comprising:
memory storing instructions that are executable; and [Ya, Figure 9, “storage devices 1508.”]
one or more processing devices to execute the instructions to perform operations comprising: [Yao, Figure 9, “processors 1501.”]
…
Regarding Claim 18, Yao teaches:
18. The system of claim 16, wherein the operations further comprise:
identifying one or more of a query type, a query domain, a trigger type, a trigger value, a trigger repeat, and a trigger rule of the query. [Yao, Figure 8, “determine trigger/action domains/APIS 802.” And “Determine API parameters 805” which are domain parameters for both actions/commands/queries and triggers.]
Claim 19 is a system claim with limitations corresponding to the limitations of Claim 2 and is rejected under similar rationale.
19. The system of claim 18, wherein trigger type is extracted via natural language interpretation. [Yao, Figure 7, 702 performs NLP on the input: “[0052] …In operation 702, processing logic performs an NLP operation on the input text to determine a first domain associated with the condition and a second domain associated with the action….” See also Figure 8, 802. Note that action is query/command and condition is condition/trigger.]
Claim 21 is a system claim with limitations corresponding to the limitations of Claim 3 and is rejected under similar rationale.
Regarding Claim 22, Yao teaches:
22. The computer-implemented method according to claim 1, wherein the monitoring comprises:
generating, from the trigger type defined in the registration information, a frame of a polling query, the frame including a placeholder for data to be collected; [Yao, each application has a frame including slots/parameters/”placeholder for data that needs to be collected” that need to be filled in order for the task to be performed. “[0024] The first API is referred to as a trigger API and the second API is referred to as an action API. … If it is determined that the condition has been satisfied, task manager 120 transmits a control command, for example, in a form of a request, to a second application via the second API. The control command includes information or parameter(s) to request the second application to perform the task specified by the input text.” “[0038] In the above example when the user says “when I get home turn on my lights,” at least one of the parameters will be the address of user's home. In this example, parameter determination module 214 parses the input text in view of the rules or grammars 224 to determine that a home address of the user is needed as a parameter. Typically, the home address should have been previously registered and stored either under the user contact, address book, or user profile. ….”]
transmitting the frame of the polling query to a user terminal; [Yao, user may be asked to provide the parameters/data either directly or through disambiguation: “[0028] In one embodiment, NLU system 110 includes, but is not limited to, domain determination module or detector 211, API determination module or detector 212, API disambiguation module 213, API parameter determination module 214, and user interactive module 215. ….” “[0036] Once the APIs have been determined, the parameters of the APIs need to be determined in order to invoke the corresponding applications via the APIs. According to one embodiment, API parameter determination module 214 is invoked to determine the parameters for each of the APIs determined by API determination module 213. API parameter determination module 214 parses the input text into a structured format that can be understandable by computers….” “[0038] … Parameter determination module 214 may communicate with proper components to obtain the home address of the user, for example, via a corresponding API. For example, parameter determination module 214 may access the address book or contacts of the user to obtain the home address of the user via a particular API that can be utilized to access the address book or contacts.”]
receiving, from the user terminal on a recurring basis, a polling query in which the placeholder of the frame has been filled with data that is collected by the user terminal and that corresponds to the trigger type; and [Yao, see [0038] above and Figure 2, 213, 215 and 223 and Figure 8, 807. The parameters/data that are needed to perform the task are requested by the system and either extracted from previous information on file or asked from the user by the User Interface. “[0039] If it is determined that the home address of the user cannot be obtained, API parameter determination module 214 may invoke user interactive module 215 to prompt the user to provide the home address. Once the user provides the missing parameter, in this example, the home address, the related information store or database will be updated based on the parameter provided by the user. In this example, API parameter determination module 214 may communicate with the address book or contacts via the corresponding API to update the home address of the user. Alternatively, user preferences 223 may be updated to store the home address of the user.”]
determining whether the situation specified by the condition has occurred using the data in the received polling query. [Yao, “[0038] In the above example when the user says “when I get home turn on my lights,” at least one of the parameters will be the address of user's home. …” “[0040] When API information (e.g., an API and the corresponding API parameter(s)) is successfully determined based on input, the API information is sent to corresponding device or service, in this example, task manager 120….”]
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yao and Neff in view of Badr (U.S. 20200184156).
Regarding Claim 6, Yao teaches:
6. The computer-implemented method according to claim 5,
wherein the obtaining a setting expression includes receiving information that specifies a user corresponding to the setting expression among at least two users, the list is associated with information that specifies at least one user among the at least two users, and the determining whether the domain is registered in a list includes: specifying a user corresponding to the setting expression on which the domain is based, and specifying the list associated with the user. [Yao disambiguates the command according to the user because if the user asks the directions home, the system had to know who the user is before it can determine where the home would be. Figure 3, “User preferences 223.” Thus, user profile or user preferences, are consulted which indicates more than one user. Additionally, some commands such as “call Jeff” require access to contacts which includes a list of second users. “[0038] In the above example when the user says “when I get home turn on my lights,” at least one of the parameters will be the address of user's home. In this example, parameter determination module 214 parses the input text in view of the rules or grammars 224 to determine that a home address of the user is needed as a parameter. Typically, the home address should have been previously registered and stored either under the user contact, address book, or user profile. Parameter determination module 214 may communicate with proper components to obtain the home address of the user, for example, via a corresponding API. For example, parameter determination module 214 may access the address book or contacts of the user to obtain the home address of the user via a particular API that can be utilized to access the address book or contacts.”]
Yao, however, does not expressly mention two or more users.
Neither does Neff.
Badr teaches:
wherein the obtaining a setting expression includes receiving information that specifies a user corresponding to the setting expression among at least two users, the list is associated with information that specifies at least one user among the at least two users, and the determining whether the domain is registered in a list includes: specifying a user corresponding to the setting expression on which the domain is based, and specifying the list associated with the user. [Badr teaches that the automated assistant distinguishes between users and each user is authorized to dictate a particular set of tasks such that the automated assistant rejects a user’s command depending on the identity of the user. Figure 1 shows users 140A and 140B one being a man and another a woman (ie two distinct users). See Figure 6 where the user issues a command and the device responds with “Unfortunately I don’t have permission to do that….” Figure 9, shows the flow chart: 908: “Determine that task request relates to second user and check access control list to determine whether first user has appropriate access rights regarding second user.”]
Yao/Neff and Badr pertain to voice commands and to conditional voice commands and it would have been obvious to combine the features of Badr which demonstrate one type of interaction between two different users when a device is used by both with the system of the combination to include user restrictions as one of the conditions of the command. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Claim 17 is a system claim with limitations corresponding to the limitations of Claim 5 and is rejected under similar rationale.
Claims 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yao and Neff and further in view of Novitchenko (U.S. 20220284901).
Regarding Claim 11, Yao’s examples of conditional commands include satisfaction of a time (at sunset) or location (when I get home) conditions or performing a first act as a condition for a second command (if I add a photo … change my room lights …”) The conditions of Yao are not evaluated based on the frequency of occurrence of a situation.
Neff does not teach this feature either.
Novitchenko teaches:
11. The computer-implemented method according to claim 1,
wherein the condition defines a frequency of occurrence of the situation. [Novitchenko, Figure 8, 808 “In accordance with a determination that the suggestion criteria are satisfied, providing a suggestion indicating that the determined task may be performed using the digital assistant …” indicates that the performance of the task is conditioned on context which is input at 802: “receive context data associated with the electronic device.” The context data is dependent on the number of times/ frequency of occurrence of certain events. “[0250] In some examples, context data indicates a number of times that the electronic device has provided a suggestion indicating that a particular task may be performed by a digital assistant of the electronic device to the user. In some examples, the context data further indicates a number of times the electronic device has provided a suggestion for the task in a particular period of time (e.g., a week, a month, etc.). For example, the context data can indicate a number of times in the past month that the electronic device has provided a suggestion indicating that the task of sending a text message (e.g., via a messaging application stored on the electronic device) can be performed using a digital assistant of the electronic device. ….” “[0252] In some examples, the context data indicates a frequency of one or more user behaviors. For example, the context data can indicate the frequency at which the user sets an alarm in a clock application (as well as values for the alarm time parameter of the set alarms), the frequency at which the electronic device communicates with each user-specific contact stored on the electronic device (e.g., via text message and/or phone call), the frequency at which certain websites are visited in a browser application (e.g., browser module 247), the frequency at which the user visits certain locations with the electronic device, the frequency at which the user interacts with software applications stored on the electronic device (e.g., opens a software application, uses a feature within a software application, etc.), and so forth.”]
Yao/Neff and Novitchenko are directed to conditional commands and it would have been obvious to include the frequency of occurrence of a certain event from Novitchenko as a type of condition prerequisite of performance of a command in order to either make the more frequent events a precondition to perform the command or prevent the command from being performed depending on policy. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Claim 20 is a system claim with limitations corresponding to the limitations of Claim 11 and is rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rajan (U.S. 2017/0098283).
Kennewick (U.S. 20090150156).
Kumar (U.S. 20180268456).
PNG
media_image17.png
483
363
media_image17.png
Greyscale
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 FARIBA SIRJANI whose telephone number is (571)270-1499. The examiner can normally be reached on 9 to 5, M-F.
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, Pierre Desir can be reached on 571-272-7799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Fariba Sirjani/
Primary Examiner, Art Unit 2659
Prosecution Insights