Patent Application
20140171133
Mobile device users receive large numbers of repeated queries for simple information via chat services or SMS (Short Message Service). Such messages may ask for a current location of a receiving user, whether the receiving user has been to a certain location, whether the receiving user has placed a specific phone call, whether the receiving user is currently at a given location, etc.
With current mobile devices, users are required to divert their attention to respond to these simple, often repeated queries. The adverse impact of such continued diversions can be compounded against a user's productivity. This unfortunate side effect is magnified when a user is handling otherwise time sensitive and critical tasks.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such approaches with some aspects of the present method and apparatus set forth in the remainder of this disclosure with reference to the drawings.
A system and/or method is provided for automated response to personal queries, with optional machine learning to establish privacy norms, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
In accordance with an example embodiment of the disclosure, a non-transitory, machine-readable storage medium may have stored thereon a computer program having at least one code section. The at least one code section may be executable by a first electronic processing device for causing the first electronic processing device to execute context pertinent responses based on at least one status query electronically communicated to the first electronic processing device from a second electronic processing device. The at least one code section may control the first device to perform examining the query to determine a pertinent context. A query processing device may be queried via the first device. Responsive to the querying, context pertinent information may be received based on at least one database of stored context pertinent information. A context pertinent response may be executed based on the obtained context pertinent information.
These and other advantages, aspects and features of the present disclosure, as well as details of illustrated implementation(s) thereof, will be more fully understood from the following description and drawings.
As utilized herein the terms “circuits” and “circuitry” refer to physical electronic components (i.e. hardware) and any software and/or firmware (“code”) which may configure the hardware, be executed by the hardware, and or otherwise be associated with the hardware. As utilized herein, “and/or” means any one or more of the items in the list joined by “and/or”. As an example, “x and/or y” means any element of the three-element set {(x), (y), (x, y)}. As another example, “x, y, and/or z” means any element of the seven-element set {(x), (y), (z), (x, y), (x, z), (y, z), (x, y, z)}. As utilized herein, the term “e.g.,” introduces a list of one or more non-limiting examples, instances, or illustrations.
The present disclosure relates to a method and system for automated response to personal queries, with optional machine learning to establish privacy norms. In various implementations, the disclosed embodiments relate to a first mobile or stationary device executing a “client” or “cloud”-based application that derives context pertinent responses to communications received by the first device from a second mobile or stationary device, that is, an original sender, and automatically (and essentially immediately) executing the context pertinent responses. For example, received communications may include queries, such as (but not limited to):
“Where are you?”
“Have you been to _ yet?”
“Are you busy now?”
“Do you have a meeting tonight?”
“Are you on the train yet?”
“When will you be home?”
“Have you called doctor yet?”
With such queries, a context pertinent response may include sending a context pertinent answer to the second device. Respective context pertinent answers to the above queries may include:
“In a meeting.”
“No.”
“Yes.”
“Yes.”
“No.”
“10:00 PM”
“No.”
Such information may be obtained by accessing data on the first device (or a remote server, such as a corporate email/calendar server, via the first device), including one or more of a call list, a calendar database, global positioning data, etc.
Other received query communications may include task reminders, such as “remind him he needs to call the dentist.” With such task reminders, a context pertinent response may include querying the first (mobile) device call list, both outgoing and incoming, for a time frame that is predetermined or identified in the originating query, and automatically (e.g., without user intervention) setting a calendar reminder alert for the first device user, if such a call is not listed in the user calendar.
In addition, context pertinent responses may include applying appropriate privacy levels (norms). For example, return texts, emails and calendar reminders in response to a query may be subject to a higher privacy level depending on the context, or the identity of the sender.
Periodically or optionally, so as to check the system's correctness, and/or during training periods, the system executing the “client” or “cloud”-based application may request authorizations (e.g., authorization to proceed sending a suggested response) to proposed context pertinent responses to received communications. From the authorizations, the system may track and record correct context pertinent responses, and may also execute context pertinent response to communications received thereafter from a given user. In this regard, online learning may be used to create and store a query response template based on user input, in instances when there is no previously memorized (stored) template to address a received query. Additionally, a user profile associated with the sender of a query may also be stored based on receiving user input, where the stored user profile may specify various privacy norms for responding to specific queries from the user.
The NLU 106 may comprise suitable circuitry, logic and/or code and may be operable to apply natural language understanding functionalities to queries (e.g., query 114) received from the sending user 102 via the second device 104, and generate a query interpretation 116. The query interpretation 116 may comprise an indication of the type of query characterizing query 114. Natural language processing functionalities of the NLU module 106 may be based on handwritten rules/grammars or may be learned from training corpora or users' behavior over time (i.e., the responses that are given to frequent queries). Additionally, standard/common responses may be learned from user behavior in relation to received queries, or adapted/selected from a canonical set stored in the cloud.
Referring to
“Still at work.”
However, instead of one possible answer, the first device 110 may present a palette/list of possible canned or previously learned responses (templates) for authorization by the user 108. To obtain authorization, the first device 110 may provides the following authorization query to user 108 as part of the template 118:
“OK TO SEND: no/yes? EDIT Response: no/yes?”
Based on the response by user 108, such as “OK TO SEND—yes”, the first device 110 may respond as proposed and may communicate the response to the second device 104. The user 108 may then be presented with template 120 where privacy settings for communications with the sending user (“Ed”) may be selected (e.g., when, if it all, is it ok to share location with the particular user). After the privacy norms for communication with user “Ed” are established, an auto-response feature 122 may be activated for this user. The established privacy norms for user “Ed” may be stored by the first device 110, the NLU 106 and/or by an online learning module (illustrated in
Alternatively, the first device 110 may be operable to track user's context pertinent responses and update one or more databases (maintained by, for example, the first device 110 and/or the NLU 106) for future context pertinent responses. In addition, the first device 110 and/or the NLU 106 may be operable to obtain context pertinent responses to communications via standard or common responses adapted or selected from a canonical set of context pertinent responses. It may be appreciated that such responses could be stored locally by the first device 110 or in an information depository “cloud.”
In this regard, the system architecture 100 may be operable to enable users to selectively identify all or a portion of contacts, in a contact list, for which certain status updates are visible or returnable in a context pertinent response to a received query communication. Such queries could include status queries (e.g., “where are you now?”), as well as historic information (e.g., identity of past locations at which the user has recently visited, future locations where the user intends to go). The granularity of the set of responsive information can be controllable by the user 108 and may include responsive answers, such as “busy/not-busy” and/or more detailed information.
At 206, one or both of a device application (app) on the first device 110 and a server associated with the first device (e.g., mail and calendar server), may be queried for a query response, based on the determined query type. At 208, the first device 110 may retrieve and populate a response template 118 for a query response, based on the determined query type. Such template may be maintained by the device 110 or the NLU module 106. At 210, it may be determined whether to send or edit the populated response template 118.
If the user 108 decides to send the response, at 212, the response stated in the response template 118 may be sent to the first device 104. Alternatively, the user 108 may edit the response at 214. At 216, the user 108 may be queried regarding auto-response options, if the same or similar query is received from the second device 104. At 218, auto-response may be enabled with the requested auto-response option (e.g., auto-respond only during a certain time of day, etc.). The auto-response option may be enabled for all sending users, for certain sending users, and/or for certain types of messages (e.g., for queries of certain type).
The OLL module 302 may comprise suitable circuitry, logic and/or code and may be operable to store privacy profiles (e.g., profile 304) associated with one or more users (e.g., users profiled in a contact list stored by device 110). The privacy profiles may specify the query sender (contact) name, user group the sender is associated with, time of day when the privacy profile is active, query type (e.g., the type of queries the profile actions apply to), and response action (e.g., specifies what action may be automatically taken, if any, if a query from the sender is received).
Additionally, the OLL module 302 may communicate a probability of response value 308 to the first device 108 after the query interpretation 116 is generated by the NLU module 106. The probability of response value may range, for example, from 0 to 1. A value of 0 may indicate to the first device 110 that a response is not recommended. A value of 1 may indicate to the first device that an auto-response is recommended. A value of 0.5 may indicate that the first device 110 may first present the query interpretation 116 to the user 108 prior to sending a query response to user 102. The probability of response values 308 may be calculated based on privacy profiles (e.g., profile 304) of senders, as well as historic query response data based on responses provided by user 108 to received queries.
Even though the OLL module 302 and the NLU module 106 are shown as separate modules, the present disclosure may not be limited in this regard, and the two modules may be co-located in (or implemented as) a single module. For example, the OLL module 302 may be implemented as a part of the NLU 106. In the alternative, the NLU module 106 and/or the OLL module 302 may be implemented within the first device 110.
At 406, one or both of a device application (app) on the first device 110 and a server associated with the first device (e.g., mail and calendar server), may be queried for a query response, based on the determined query type. At 408, the first device 110 may retrieve and populate a response template 118 for a query response, based on the determined query type. Such template may be maintained by the device 110 or the NLU module 106.
At 410, it may be determined whether auto-complete (of a response template) and/or auto-response is enabled for the sending user 102 of the second device 104. For example, a privacy profile for user 102 may be stored by the OLL module 302, and the profile may b used to indicate whether or not auto-complete and/or auto-respond are enabled for user 102. If such privacy settings are enabled, at 412, the response in the response template 118 may be automatically sent to the user 102.
If auto-complete/auto-respond is not enabled for user 102 sending query 114, at 414, it may be determined whether to send or edit the populated response template 118.
If the user 108 decides to send the response, at 416, the response stated in the response template 118 may be sent to the first device 104. Alternatively, the user 108 may edit the response at 418. At 420, user 108 may be queried on auto-response options if the same or similar query is received from the second device 104 (i.e., from the sending user 102). The first device 110 may then set privacy norms for the requesting user 102 of the second device 104 (e.g., how to respond to any query from the requesting user 102 in the future, or how to respond to a particular query from the requesting user 102).
At 422, auto-response with the requested auto-response option may be enabled (e.g., auto-respond only during a certain time of day, etc.). In this regard, the first device 110 may update the privacy profile 304 stored by the OLL module 302 (on-line learning module 302 is updated with the set privacy norms for the sending user 102) (illustrated as 306 in
In this instance, the first device 110 may display a blank template 502, with the received query 114 posted in the template (e.g., “What's your address? Dave”). Upon entering the answer, user 108 may send the response to the user 102. Additionally, the first device 110 may perform template update 504 and may store the newly completed template with the answer from user 108 into the NLU module 106. The first device 108 may also present the user 108 with a privacy profile 508 for the sending user 102 (e.g., “Dave”). Upon completion of the privacy profile 508, an update 506 of privacy profiles may be performed and the newly completed profile 508 may be stored within the OLL module 302.
The main processor 602 may comprise suitable logic, circuitry, interfaces, and/or code that may be operable to process data, and/or control and/or manage operations of the mobile device 110, and/or tasks and/or applications performed therein in connection with providing automated response to personal queries, with optional machine learning to establish privacy norms. In this regard, the main processor 602 may be operable to configure and/or control operations of various components and/or subsystems of the mobile device 110, by utilizing, for example, one or more control signals. The main processor 602 enables running and/or execution of applications, programs and/or code (e.g., the program functionalities described in the claims as well as functionalities described herein above in reference to
In some instances, one or more of the applications running and/or executing on the mobile device 110 may generate and/or update video content that may be rendered via the display 112. In other instances, one or more of the applications running and/or executing on the mobile device 110 may be used to perform functionalities explained herein in reference to the architectures of
The system memory 604 may comprise suitable logic, circuitry, interfaces, and/or code that may enable permanent and/or non-permanent storage, buffering, and/or fetching of data, code and/or other information (e.g., query response templates and/or privacy profiles specifying privacy norms when communicating with users), which may be used, consumed, and/or processed. In this regard, the system memory 604 may comprise different memory technologies, including, for example, read-only memory (ROM), random access memory (RAM), Flash memory, solid-state drive (SSD), and/or field-programmable gate array (FPGA). The system memory 604 may store, for example, configuration data, which may comprise parameters and/or code, comprising software and/or firmware.
The communication subsystem 606 may comprise suitable logic, circuitry, interfaces, and/or code operable to communicate data from and/or to the mobile device, such as via one or more wired and/or wireless connections. The communication subsystem 606 may be configured to support one or more wired protocols (e.g., Ethernet standards, MOCA, etc.) and/or wireless protocols or interfaces (e.g., Bluetooth, WiFi, cellular, WiMAX, and/or any other available wireless protocol/interface), facilitating transmission and/or reception of signals to and/or from the mobile device 110, and/or processing of transmitted or received signals in accordance with applicable wired or wireless protocols. In this regard, signal processing operations may comprise filtering, amplification, analog-to-digital conversion and/or digital-to-analog conversion, up-conversion/down-conversion of baseband signals, encoding/decoding, encryption/decryption, and/or modulation/demodulation. In accordance with an embodiment of the disclosure, the communication subsystem 606 may provide wired and/or wireless connections to, for example, the first device 104, the NLU 106 and/or the OLL 302.
The sensory subsystem 608 may comprise suitable logic, circuitry, interfaces, and/or code for obtaining and/or generating sensory information, which may relate to the mobile device 110, its user(s), and/or its environment. For example, the sensory and I/O subsystem 608 may comprise positional or locational sensors (e.g., GPS or other GNSS based sensors 611), ambient conditions (e.g., temperature, humidity, or light) sensors, and/or motion related sensors (e.g., accelerometer, gyroscope, pedometers, and/or altimeters).
The I/O subsystem 610 may comprise suitable logic, circuitry, interfaces, and/or code for enabling user interactions with the mobile device 110, enabling obtaining input from user(s) and/or to providing output to the user(s). The I/O subsystem 610 may support various types of inputs and/or outputs, including, for example, video, audio, and/or textual. In this regard, dedicated I/O devices and/or components, external to or integrated within the mobile device 110, may be utilized for inputting and/or outputting data during operations of the I/O subsystem 610. Example I/O devices may comprise displays, mice, keyboards, touchscreens, voice input interfaces, and other input/output interfaces or devices. With respect to video outputs, the I/O subsystem 610 may be operable to generate and/or process video content, graphics, and/or textual data, and/or generate video frames based thereon for display, via the display 112 for example.
The display 112 may comprise suitable logic, circuitry, interfaces and/or code that may enable displaying of video content (e.g., response templates), which may be handled and/or processed via the I/O subsystem 610. The display 112 may be used in outputting video data, which may comprise contacts lists, response templates, and privacy profiles, as explained herein above.
Other implementations may provide a non-transitory computer readable medium and/or storage medium, and/or a non-transitory machine readable medium and/or storage medium, having stored thereon, a machine code and/or a computer program having at least one code section executable by a machine and/or a computer, thereby causing the machine and/or computer to perform the steps as described herein for executing context pertinent responses.
Accordingly, the present method and/or system may be realized in hardware, software, or a combination of hardware and software. The present method and/or system may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other system adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
The present method and/or system may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
While the present method and/or apparatus has been described with reference to certain implementations, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present method and/or apparatus. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present disclosure without departing from its scope. Therefore, it is intended that the present method and/or apparatus not be limited to the particular implementations disclosed, but that the present method and/or apparatus will include all implementations falling within the scope of the appended claims.
