Voice command recognition
The method and system for voice command filtering in voice command devices improve accuracy by blocking commands from specific directions and background noise sources, ensuring registered users can control devices effectively.
Patent Information
- Application Number
- JP2022501015
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-08-20
- Filing Date
- 2020-08-13
- Publication Date
- 2024-12-17
- Estimated Expiration
- 2040-08-13
AI Technical Summary
Voice command devices often incorrectly respond to background noise from audio sources like televisions and mobile devices, leading to unintended activations and inefficiencies.
Implement a method and system for voice command filtering that identifies and blocks commands from specific directions, using triangulation and audio analysis to distinguish between registered users and background noise sources, and updates based on environmental changes.
Enhances the accuracy of voice command recognition by reducing false activations, allowing registered users to control devices effectively while ignoring background noise and unregistered commands.
Smart Images

Figure 0007601514000001 
Figure 0007601514000002 
Figure 0007601514000003
Abstract
Description
[Technical field]
[0001] The present invention relates to voice command devices, and more particularly to filtering of voice commands. [Background technology]
[0002] A Voice Command Device (VCD) is a device controlled by human voice commands that eliminates the need to use hands to control the device, such as buttons, dials, switches, user interfaces, etc. This allows users to operate the device while they are occupied with other tasks or when they are not close enough to touch the device.
[0003] The VCD(s) can take a variety of forms, such as a home appliance, a controller for other devices, or a dedicated device such as a personal assistant. A VCD(s) in the form of a virtual personal assistant can be integrated into a computing device, such as a mobile phone. A virtual personal assistant includes voice-activated instructions to perform tasks or services in response to voice commands and inputs.
[0004] The VCD(s) can be activated by voice commands in the form of one or more trigger words. The VCD(s) can be programmed to respond only to the voices of registered individuals or groups of registered individuals. This prevents non-registered users from giving commands. Other types of VCDs are not adapted to register users and allow anyone to give commands in the form of designated command words and commands.
[0005] A Voice Command Device (VCD) is a device controlled by human voice commands that eliminates the need to use hands to control the device, such as buttons, dials, switches, user interfaces, etc. This allows users to operate the device while they are occupied with other tasks or when they are not close enough to touch the device.
[0006] Complications arise when a VCD is activated on command from a television, radio, computer, or other non-human device that emits audio near the VCD.
[0007] For example, a VCD in the form of a smart speaker embedded with a voice-controlled intelligent personal assistant can be provided in the living room. The smart speaker may mis-respond to sounds from the television. Sometimes this is a harmless sound that the smart speaker does not understand, but sometimes the sound is a valid command or trigger that causes an action by the intelligent personal assistant.
[0008] Therefore, there is a need in the art to address the above-mentioned problems. Summary of the Invention
[0009] Viewed from a first aspect, the present invention provides a computer-implemented method for filtering voice commands, the method including: establishing communication with a voice command device disposed at a location; receiving data from the voice command device indicating a blocking direction; determining that a voice command was received from the blocking direction indicated in the data; and ignoring the received voice command.
[0010] Viewed from a further aspect, the present invention provides a system for filtering voice commands, the system including a processor configured to execute program instructions to perform a method including establishing communication with a voice command device disposed in a memory and location storing program instructions; receiving data from the voice command device indicating a blocking direction; determining that a voice command was received from the blocking direction indicated in the data; and ignoring the received voice command.
[0011] Viewed from a further aspect, the present invention provides a program product for filtering voice commands, comprising a computer readable recording medium readable by a processing circuit and a computer program product recording thereon instructions executable by the processing circuit for performing a method for performing the above steps of the present invention.
[0012] Viewed from a further aspect, the present invention provides a computer program stored on a computer readable medium and capable of being placed in an internal memory of a digital computer, said computer program comprising software code portions when said program runs on a computer for performing the steps of the present invention.
[0013] Viewed from a further aspect, the present invention provides a computer program product including a computer readable recording medium having program instructions embedded therein, the computer readable recording medium being not itself a transitional signal, the program instructions being executed by a processor to cause the processor to perform a method including establishing communication with a voice command device located in a memory and location storing the program instructions; receiving data from the voice command device indicating a blocking direction; determining that a voice command was received from the blocking direction indicated in the data; and ignoring the received voice command.
[0014] Embodiments of the present disclosure include methods, computer program products, and systems for filtering voice commands. Communication can be established with a voice controlled device located at a location. Data indicating a blocking direction can be received from the voice controlled device. A voice command can be received. It can be determined that the voice was received from a blocking direction indicated in the data. The received voice command can then be ignored.
[0015] The above summary is not intended to describe every embodiment or implementation of the present disclosure.
[0016] The drawings included in this disclosure are incorporated in and constitute a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of typical embodiments and are not intended to limit the disclosure. [Brief description of the drawings]
[0017] [Figure 1] FIG. 1 is a schematic diagram illustrating an environment in which embodiments of the present disclosure may be implemented. [Figure 2A] FIG. 2A is a flow diagram illustrating an example method for filtering voice commands based on blocking direction according to an embodiment of the present disclosure. [Figure 2B] FIG. 2B is a flow diagram illustrating an example method for determining whether to execute a voice command according to an embodiment of the present disclosure. [Figure 2C] FIG. 2C is a flow diagram illustrating an example method for querying to determine whether an audio output device should ignore a voice command according to an embodiment of the present disclosure. [Diagram 3] FIG. 3 is a flow diagram illustrating an example method for communicating an audio file to a voice command device according to an embodiment of the present disclosure. [Figure 4] FIG. 4 is a block diagram of a voice command device according to an embodiment of the present disclosure. [Diagram 5]FIG. 5 is a block diagram of an acoustic output device according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a flow diagram illustrating an example method for filtering voice commands in a mobile device according to an embodiment of the present disclosure. [Figure 7] FIG. 7 is a flow diagram illustrating an example method for updating a voice command device with a blocking direction corresponding to a mobile device's location in accordance with an embodiment of the present disclosure. [Figure 8] FIG. 8 is a high-level block diagram illustrating an exemplary computer system that can be used to implement one or more of the methods, tools, and modules described herein, and any associated functionality. [Figure 9] FIG. 9 is a diagram illustrating a cloud computing environment according to an embodiment of the present disclosure. [Figure 10] FIG. 10 is a diagram illustrating a middle model layer according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0018] 0029 The embodiments described herein are susceptible to various modifications and alternative forms, details of which are shown by way of example in the drawings and will be described in detail. However, the specific embodiments are not to be construed in a limiting sense. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure.
[0019] Although features of the present disclosure relate generally to the field of voice command devices, and specifically to filtering of voice commands, the present disclosure is not necessarily limited to such applications, and various features of the present disclosure may be appreciated through various examples using this context.
[0020] A feature of the present disclosure is directed to distinguishing voice commands at a voice command device. If an audio output device (e.g., a television) generates background noise for an extended period of time, an audio output device can be added to the blocked direction so that the VCD is not triggered in response to audio output from the background noise. The voice command device is configured to recognize registered users from blocked directions so that the registered user's commands can be executed from the blocked direction. However, if an unregistered user attempts to issue a command from a blocked direction (e.g., from a television), the unregistered user is ignored as an error. Thus, a feature of the present disclosure overcomes the above-mentioned complications of querying the audio output device to determine whether it is emitting audio. If the audio output device is not outputting audio at the time the command is issued, the unregistered user's command is processed. If the audio output device is outputting audio at the time the command is issued, an audio file is collected from the audio output device and compared to the received voice command. If the voice command and audio file match, the command is ignored (e.g., as likely audio received from a television). If the voice command and the audio file do not substantially match, the voice command may be treated as not originating from the audio output device.
[0021] Further features recognize that a statically programmed blocking direction to the VCD(s) can be issued when a new mobile device enters the vicinity. Mobile devices can themselves be sources of background noise, which can also cause false triggering of voice commands in the VCD. Thus, features of the present disclosure are directed to updating the VCD when a new background source (e.g., a mobile device) enters the vicinity of the VCD.
[0022] 0032 Furthermore, mobile devices may themselves also have voice command capabilities. However, mobile devices are not updated with the current intercept direction, authenticated user voice, and other important considerations. Thus, a feature is provided to synchronize VCD data (e.g., intercept direction, authenticated user voice, and other considerations such as volume state of audio devices) between multiple VCDs (e.g., dedicated VCDs and mobile devices with VCD capabilities).
[0023] 1, a schematic diagram 100 shows an environment 110 (e.g., a room) in which a voice command device (VCD) 120 is suitably placed. For example, the VCD 120 may be in the form of a smart speaker including a voice-commanded intelligent personal assistant, located within the environment 110 on a table adjacent to a sofa 117.
[0024] The environment 110 includes a television 114 from which sound may be emitted from two speakers 115, 116 associated with the television 114. The environment 110 may also include a radio 112 with speakers.
[0025] The VCD 120 receives acoustic inputs at various times from the two television speakers 115, 116 and the radio 112. These acoustic inputs may include command words that inadvertently trigger or provide input to the VCD 120.
[0026] A feature of the present disclosure provides additional functionality for the VCD 120 to learn which directions (eg, relative angles) of acoustic input to ignore for a given position of the VCD 120.
[0027] Over time, the VCD 120 can learn to identify background noise sources within the environment 110 by the direction of their acoustic input to the VCD 120. In this example, the radio 112 is positioned at approximately 0° relative to the VCD 120, and hashed triangle 131 illustrates how the acoustic output of the radio 112 is received by the VCD 120. The two speakers 115, 116 of the television 114 can be determined to be positioned at approximately 15-20° and 40-45° directions, respectively, and hashed triangles 132, 133 illustrate how the acoustic output of the speakers 115, 116 is received by the VCD 120. Over time, these directions are learned by the VCD 120 as being block directions from which acoustic commands should be ignored.
[0028] In another embodiment, the VCD 120 may be fixed in use (eg, a washing machine) and the blocking direction is learned for an audio input source, such as a radio in the same room as the washing machine.
[0029] When VCD 120 receives commands from these blocked directions, it may ignore the commands until it is configured to allow commands from these directions from the voices of known registered users.
[0030] In an embodiment, the VCD 120 may be configured to distinguish commands from an unknown person 140 speaking from a blocked direction (e.g., from the direction of the audio speakers 115, 116 of the television 114 or the radio 112). As described further below, the VCD 120 may be configured to query an audio output device (e.g., the television 114 or the radio 112) to ascertain the status of the audio device (e.g., whether the audio device is outputting audio). If the status of the audio device indicates that the audio device is not outputting audio, the command from the unknown person 140 is executed even if the unknown person is speaking from a blocked direction.
[0031] An embodiment allows a VCD 120 positioned in a given orientation (eg, an orientation relative to the VCD 120) to ignore unwanted command sources without losing commands from users unknown to that orientation.
[0032] Furthermore, the feature illustrates a mobile device (MD) 150 that can enter the environment 110. The mobile device 150 is a smartphone that has local (such as Bluetooth) and wide area (4G) wireless capabilities, as well as processing and recording capabilities. The mobile device 150 can also include audio output (one or more speakers) and audio input (one or more microphones) technologies. The mobile device 150 can also have voice control / command software capabilities provided thereon that allow a user to control the mobile device by voice.
[0033] The dynamic intrusion of a mobile device 150 into the environment 110 has the potential to disrupt the operation of an existing static VCD 120 since the mobile device 150 can be thought of as an additional source of acoustic output (background) that introduces commands inadvertently received from the mobile device 150 and acts on the VCD 120. Similarly, existing background sources of acoustics (radio 112 and television 114) can disrupt the operation of voice-controlled functionality present in the mobile device 150 (assuming the mobile device 150 has such functionality). The intrusion of a new device such as the mobile device 150 is handled by the VCD 120 in a manner that minimizes the potential for disruption of voice-controlled operation of the VCD 120 and mobile device 150.
[0034] As further discussed below, the VCD 120 may record details of one or more blocked background audio noise sources. The details recorded by the VCD 120 may be structured in one or more ways, such as hierarchical information or even information identifying the device(s) providing the background audio noise, or characteristics (e.g., tone and pitch) of the background audio noise likely to be emitted by particular device(s) present that may inadvertently output audio commands, and combinations thereof. This information is retained by the VCD 120 for its own purpose of filtering out unwanted audio commands that come from background sources of audio noise other than the user.
[0035] A mobile device 150 entering the environment 110 in which a stationary VCD 120 is located causes the VCD 120 to acquire a series of activities to achieve better operation of both the VCD 120 and the mobile device 150. The VCD 120 can be considered as static (e.g., at a fixed position in the environment 110) and the mobile device 150 as dynamic (e.g., mobile in the environment 110). Ultimately, both devices can function as VCDs, but one is static and the other is dynamic. The devices 120 and 150 are operated such that each time the mobile device 150 is triggered by an acoustic command, the mobile device 150 communicates with the static VCD 120 to utilize the information about background noise sources that the VCD 120 has acquired. This allows the mobile device 150 to prevent undesired commands from being executed by background noise sources when the mobile device 150 subsequently moves to a new environment. Additionally, devices 120 and 150 may be operated to allow static VCD 120 to gain knowledge of mobile device 150 as a source of transient background noise, allowing static VCD 120 to block unwanted commands coming from the mobile device's speaker, for example, even when mobile device 150 is playing a video, TV show stream, movie, sound track, etc. Cooperation between VCD 120 and mobile device 150 improves the operation of both devices.
[0036] This improved operation of the VCD 120 and mobile device 150 can be implemented as a software update to the current VCD(s) and personal assistant devices such as mobile phones. This process can be triggered when the mobile device 150 enters a new environment in which the VCD 120 is present. The mobile device 150 communicates with the VCD 120 located in the environment 110 through Bluetooth, Wi-Fi, or other local communication technologies to set up pairing. As part of this initial handshake, the mobile device 150 can send appropriate trigger words or phrases that are used to activate the mobile device's personal assistant. The VCD 120 can then store these trigger words in storage. The VCD 120 can also record details of previously paired mobile devices 150 to eliminate the need to send trigger words each time the same mobile device 150 enters the environment 110.
[0037] VCD 120 then listens for all occurrences of the recorded mobile device trigger words / phrases, and whenever VCD 120 detects any trigger word / phrase, VCD 120 stores an instance in temporary storage detailing the phrase used, the time / date the phrase was received, and whether the phrase came from the direction of a known background noise source. Similarly, if mobile device 150 detects a trigger word / phrase, before processing the command, mobile device 150 sends a query to VCD 120 to determine whether the command came from one of VCD 120's known background noise sources. If the trigger word / phrase comes from a known background noise source in the environment (relative to VCD 120), mobile device 150 can ignore the command. If not, mobile device 150 can execute the command as normal.
[0038] Periodically, the VCD 120 can receive a signal (e.g., a high frequency acoustic signal emitted by the mobile device 150) to determine if the mobile device 150 is still within the environment 110. If the mobile device 150 leaves the environment 110, the VCD 120 can clear its temporary storage of observed trigger words / phrases and stop storing any future commands. In this embodiment, the mobile device 150 uses the signal to update the VCD 120 with its location so that the VCD 120 can update its blocking direction with the location of the mobile device 150.
[0039] FIG. 2A is a flow diagram illustrating an example method 200 for filtering voice commands based on blocking direction according to an embodiment of the present disclosure.
[0040] Method 200 begins by determining one or more background noises. This is described in step 201. The VCD 120 learns their orientation with respect to location by receiving background acoustic inputs and analyzing the relative directions from which the acoustic inputs were received (which may include speech and non-speech background noises). In some embodiments, determining one or more directions of the background noises is accomplished by triangulation (e.g., by measuring acoustic inputs at two or more known locations (microphones mounted on the VCD 120) and determining the direction or location or both of the acoustic inputs by measuring angles from known points). Triangulation includes two or more microphones on the VCD 120 and is accomplished by cross-referencing acoustic data received at the two or more microphones. In some embodiments, one or more obstruction directions can be determined by time difference of arrival (TDOA). This method can use two or more microphones as well. Data received at the two or more microphones is analyzed to determine the location of the received acoustic input based on the time difference of arrival of the acoustic inputs. In some embodiments, one or more directions of obstruction can be determined by associating a sensor (e.g., an optical sensor, a GPS sensor, an RFID tag, etc.) with a speaker in the room (e.g., radio 112, speakers 115 and 116 of FIG. 1) and using the sensor to determine the direction of obstruction. For example, an optical sensor can be associated with VCD 120 and one or more speakers in the room. The direction of obstruction is then determined by the optical sensor associated with VCD 120. Alternatively, the direction of the background audio noise can be configured by a user. In an embodiment, the direction of obstruction can be determined based on the location of one or more mobile devices (e.g., mobile device 150 of FIG. 1).
[0041] The one or more shutoff directions are then stored. This is described in step 202. The one or more shutoff directions may be stored in a suitable memory (e.g., flash memory, RAM, hard disk memory, etc.). In some embodiments, the one or more shutoff directions are stored in local memory on the VCD 120. In some embodiments, the one or more shutoff directions may be stored on another machine and communicated over a network.
[0042] In addition, the VCD 120 determines the recognized voice biometric features. This is shown in step 203. Determining the recognized voice biometric features may be accomplished, for example, by applying voice recognition to one or more enrolled voices. Voice recognition may use characteristics of the voice such as pitch and tone. The recognized voice biometric features are stored in the VCD 120 to determine whether the incoming voice is enrolled in the VCD 120. This may be accomplished by comparing the incoming voice with the recognized voice biometric features to determine whether the incoming voice is a recognized voice.
[0043] Audio input is then received. This is shown in step 204. Audio input can be received from a human or non-human entity. Thus, the term "audio input" does not have to be speech, but can include background noise (e.g., a washing machine running, music from a speaker, etc.).
[0044] A determination is then made as to whether the audio input came from a blocking direction. This is shown in step 205. The determination as to whether the audio input came from a blocking direction is made by comparing the stored blocking direction with the direction in which the audio input was received to determine whether the received audio input is associated with the stored blocking direction. If the audio input came from a direction other than the stored blocking direction, then a determination is made that the audio input did not come from a blocking direction.
[0045] If it is determined that the voice input is not coming from the shutoff direction, then the voice input is processed. This is shown at step 206. In some embodiments, the processing includes identifying a command and executing the received command. In some embodiments, the processing may compare the received voice input to stored command data (e.g., data identifying command words and command initiation protocols) to determine whether the received voice input corresponds to (e.g., matches) a command in the stored command data. For example, if the voice input includes "power off" and "power off" is a command initiation phrase in the stored command data, then the voice input is determined to be a command and the command may be executed (e.g., turn off the power).
[0046] If the audio input is determined to be received from the blocked direction, an audio device associated with the blocked direction may be interrogated to verify the audio input. This is shown in step 207. For example, with reference to FIG. 1, if the audio input is received from speaker 116, television 114 may be interrogated to determine if the television is off or muted. If the television is determined to be off or muted (not emitting sound), the audio input may be processed (e.g., a voice command may be executed) as being audio input received from an unknown person 140.
[0047] The operations described above may be accomplished in any order and are not limited to those described above. Additionally, some, all, or none of the operations described above may be performed while still remaining within the scope of the present disclosure.
[0048] 2B-2C are flow diagrams collectively illustrating a method for filtering acoustic voice data received by a voice command device (e.g., VCD 120) according to an embodiment of the present disclosure. FIG. 2B is a flow diagram illustrating an example method for determining whether to execute a voice command based on direction and recognized voice biometrics according to an embodiment of the present disclosure. FIG. 2C is a flow diagram illustrating an example method for querying an audio output device to determine whether a voice command should be ignored according to an embodiment of the present disclosure.
[0049] Method 250 begins with one or more recognized voices enrolled in the VCD. This is shown at step 252. For example, the VCD can be configured to enroll the primary user of the VCD to ensure that the voice characteristics of the voice are easily recognized. Voice enrollment can be accomplished by analyzing various voice inputs from the primary user. The analyzed voice inputs can then be used to distinguish tones and pitches for the primary user. Alternatively, the voices normally received can be automatically learned and enrolled by recording the pitches and tones received while using the device. Having voice recognition capabilities does not preclude commands or inputs from other non-enrolled voices accepted by the VCD. In some embodiments, no voices are enrolled and the method can block all voice inputs.
[0050] Audio input is then received, as shown in step 253. In some embodiments, non-audio input is automatically filtered, which may be an inherent feature of the VCD. In some embodiments, the audio input may include background noise voices or strings (e.g., non-human audio input).
[0051] A determination is then made as to whether the voice input is associated with the recognized voice, as shown in step 254. Determining whether the voice input is associated with the recognized voice may be accomplished by analyzing voice biometrics of the received voice input (e.g., by comparing the tone and pitch of the received voice input) and comparing the voice input with the enrolled voice biometrics.
[0052] If the voice input is associated with a recognized voice, then the voice input is a command and the command is executed. This is shown at step 255. This allows the VCD to respond to voice input from registered users regardless of the direction from which the voice input was received, including when it was received from a blocked direction. The method optionally includes storing the time and direction from which the voice command was received, and can store data points of legitimate commands for learning purposes. For example, this can be used to allow the VCD to learn common directions of legitimate commands, such as from preferred positions in association with encouraging more sensitive command recognition.
[0053] If the audio input is not from a recognized voice, it may be determined whether the audio input originates from an obstruction direction. This is described in step 256. Determining the direction of the audio input may include measuring the angle of the incoming audio input. The VCD(s) may have known functionality for assessing the direction of the incoming sound. For example, multiple microphones may be arranged on the device, and the direction of the sound across the multiple microphones may allow a location to be determined (e.g., trigonometry or time difference of arrival). The obstruction direction may be stored as a range of angles of origin of the incoming sound relative to the receiver. In the case of multiple microphones, the obstruction direction may be determined corresponding to the audio input received primarily or more strongly at one or more of the multiple microphones. The direction of the incoming sound may be determined in a three-dimensional arrangement with input directions determined from above and below in addition to the vertical direction of the VCD.
[0054] If the voice input is not from an interrupted direction, it is determined whether the voice input is a command. This is shown in step 257. If it is determined that the voice input is a command, then the command can be executed in step 255. This allows commands to be executed from non-enrolled voices, i.e., new or guest users, and does not restrict users of the VCD to registered users. In some embodiments, the command can be stored as a data point of the command including the direction in which the command was received. This can be further analyzed for voice enrollment or to determine whether the command has been overwritten by a subsequent user input. The method then ends, awaiting further voice input (e.g., step 253).
[0055] If the audio input is determined to be not from an obstructed direction and is not a command, the audio input is determined to be a background noise source. Background noise data is then stored with the time, date, and direction (e.g., angle of arrival) that the background noise was received. This is shown in step 259. This direction is then added to the obstructed directions so that audio inputs can be obstructed if they are repeatedly received from this direction. A threshold can be implemented to determine when audio inputs that do not identify commands received from a non-obstructed direction are determined to be background noise.
[0056] For example, a plurality of audio inputs may be received from a particular direction. The plurality of audio inputs may each be received at a different time. The plurality of received audio inputs may be compared to stored command data to determine whether the plurality of received audio inputs correspond to the stored command data. A number of the plurality of audio inputs that do not correspond to the stored command data may be compared to a non-command audio input threshold (e.g., a threshold that identifies the number of non-command audio inputs that may be received from a given direction before storing the given direction as one or more blocked directions). In response to the number of audio inputs that do not correspond to the stored command data exceeding the non-command audio input threshold, the particular direction may be stored as one or more blocked directions. In some embodiments, the background noise threshold includes acoustic characteristics such as frequency and amplitude.
[0057] If it is determined that the audio input is from an obstructed direction, it is determined whether the audio input is a command, as shown in step 258. If the audio input is from an obstructed direction and is not a command, then the audio input is stored as being a background noise source, as shown in step 259.
[0058] If the audio input coming from the blocking direction is determined to be a command, then method 250 proceeds to FIG. 2C where one or more audio input devices in the blocking direction are identified. This is shown in step 271. A data store may be maintained by the VCD to store the blocking directions and the audio output devices in each blocking direction along with communications or addresses for interrogating each audio device. In some embodiments, the method may identify all audio output devices near the VCD and may use blanket communications to communicate with all audio output devices.
[0059] One or more audio devices are queried. This is shown at step 272. In embodiments where there are multiple audio output devices in the blocking direction, multiple queries can be sent simultaneously to two or more audio output devices. Querying the audio output device(s) can include communicating a request signal to the device to collect audio data related to the device. The audio output device(s) can be queried about the volume state (e.g., whether the device(s) is muted or the current volume level) and power state (e.g., the device(s) is powered on). The status request can be communicated using any suitable connection (e.g., an intranet, the Internet, Bluetooth, etc.).
[0060] It is determined whether the queried audio device is emitting sound. This is shown in step 273. The determination of whether the audio output device is emitting sound is accomplished based on the audio output device's response to the query request. For example, if the response to the query request indicates that the audio output device is muted, then in step 273 it is determined that the audio output device is not emitting sound. Similarly, if the response (or lack thereof) to the query request indicates that the audio output device is off, then it is determined that the audio output device is not emitting sound. In some embodiments, this can be accomplished based on a volume level threshold. For example, if the volume level threshold is set to 50% of volume and the response to the query request indicates that the audio output device is at 40% volume, then it is determined that the audio output device is not emitting sound loud enough to trigger the VCD.
[0061] If it is determined that the audio output device is not emitting sound (or the sound is too quiet to trigger the VCD based on the volume threshold), then the command is executed. This is shown in step 274. If it is determined that the audio output device is outputting sound (or the sound is loud enough to trigger the VCD based on the volume threshold), then an audio sample is requested from the audio output device. This is shown in step 275. In some embodiments, the audio sample (e.g., an audio file, an audio snippet, etc.) corresponds to the point in time at which the VCD was triggered. For example, a 2-10 second audio sample spanning the point in time at which the VCD was triggered may be requested. However, any suitable audio sample length may be requested (e.g., the past hour, day, or VCD power session).
[0062] The requested audio file is then received by the VCD, as shown in step 276. Additionally, the audio files detected by the microphones by the VCD may also be obtained, as shown in step 277. The audio files are then processed in step 278 for comparison. In some embodiments, the processing may include cleaning up the audio files (e.g., removing static background noise from the audio files). In some embodiments, the processing may include shortening the audio files (e.g., audio files from the audio output device and audio files obtained from the microphones of the VCD) to a uniform length. In some embodiments, the processing may include amplifying the audio files. In some embodiments, the processing may dynamically adjust the timing of the audio files to properly align words present in the audio files for comparison. However, in step 278 the audio files may be processed in any other suitable manner. For example, in some embodiments, the audio files may be converted to text (e.g., using conventional speech-to-text conversion) and the text (e.g., transcripts) between the audio files may be compared.
[0063] The audio files obtained from the audio output device and the audio files obtained from the VCD microphone are then compared. This is described in step 279. In some embodiments, the audio files are compared using a Fast Fourier Transform (FFT). In embodiments where the audio files are converted to text, the comparison can be done by comparing transcripts of each audio file to determine if strings in each transcript match. In some embodiments, the text transcripts may be converted to a phonetic representation to avoid false matches where words sound like commands but are not. Minor differences in detection can be addressed using known string similarity and text comparison methods.
[0064] Thereafter, a match confidence threshold of the audio file received from the audio output device and the audio file received by the VCD microphone is determined to determine whether there is a match between the files. This is shown in step 280. In an embodiment, the match confidence threshold may be accomplished based on one or more thresholds. For example, if the audio files are compared via FFT, a match confidence threshold exists to determine whether the audio files substantially match. For example, if the match confidence threshold is set to 70%, the audio files may be determined to substantially not match if the FFT comparison indicates 60% similarity. As another example, the audio files may be determined to substantially match if the comparison indicates 75% similarity.
[0065] In embodiments where the audio files are converted to text and compared, the match confidence threshold can be based on the number of matched characters / words in the audio file transcripts. For example, the match confidence threshold can specify the first number of characters in each transcript that must match for the audio files to be a substantial match (e.g., 20 characters must match for the voice command and audio output device to be considered a substantial match). As another example, the match confidence threshold can specify the number of words in each transcript that must match for the audio files to be a substantial match (e.g., 5 words must match for the voice command and audio output device to be considered a substantial match).
[0066] If there is a match, the command originated from the audio device and is ignored, as shown in step 281. If there is no match, the command is processed and executed as if the audio originated from a source other than the audio output device, as shown in step 274.
[0067] If the command is ignored in step 281, the command is stored as an ignore command data point including a time and date time stamp along with the direction the voice input was received. This data can be used to analyze the blocking direction. This data is further used to analyze whether the device is still positioned in the blocking direction by referencing the time and date of the stored background noise data point. A threshold number of non-identified voice commands from a given direction can be stored before adding them to the blocking direction.
[0068] Analysis of the stored data points registered with the incoming directions of legitimate voice commands, background noise inputs and ignored or erroneous commands can be performed to learn blocking directions and optionally common directions of legitimate commands. Periodic data cleanup (e.g., formatting and filtering) is performed as background processing of the stored data points.
[0069] The data points are stored, allowing the method and system to identify more precise directions from which noise should be ignored. Any noise that is not from a recognized voice coming from a known blocked direction can be ignored, whether on command or not.
[0070] Storing data points of different noises allows further analysis of the background noise and therefore provides a more detailed identification of the direction to be protected. For example, an oven beep may be received by the VCD from the direction of the oven. The background noise data over time is analyzed and it may be identified that the background noise data points in this direction have not previously contained commands, i.e. the background noise data points from a given direction are very similar in terms of acoustic content. In this case commands are allowed from this direction.
[0071] The VCD may include a user input mechanism for overriding a defended direction or overriding execution of a command, and the method may also learn from such overriding input from the user to improve performance.
[0072] The method assumes that the VCD is in the same location in the same room, which is often the case. If the VCD is moved to a new location, it re-learns its new environment to identify directions for blocking non-human sources associated with the VCD in the new location. The method can store the blocking directions associated with a given location of the VCD so that when the VCD is moved back to its original location, it can be reconfigured without having to re-learn its environment.
[0073] In some embodiments, the method allows for configuration of known directions to be blocked, which can eliminate the need for or additional learning of blocking methods over time, and allows the user to preset blocking directions from the user's knowledge of the directions from which interfering sounds are received.
[0074] A user can place the VCD at a location and the VCD can allow for the configuration of the protection location to be entered, such as through a graphical user interface or through a remote programming service. In one embodiment, configuration of the blocking direction is performed by the user standing at the angle desired for protection and using voice commands to issue the command in the direction desired for protection (e.g., in front of a television). In another embodiment, a pre-configuration of the room is loaded and stored for use when the VCD is moved.
[0075] Using the embodiment shown in Figure 1, the VCD 120 can begin to extract commands from the television 114 and store the direction of these incoming commands. The method can then filter out commands and background noise that always come from the same direction. Commands from directions that are not in line with the voice that normally gives commands from other directions are ignored.
[0076] An advantage of the described method is that the VCD can include an additional level of normalization in the form of direction, rather than as a device that blocks all commands that are not from known users: if a new user arrives near the VCD and issues a command, the VCD can still execute the command because it is coming from a direction that is static and does not block the command due to association with an object that emits sound.
[0077] The technical problem solved is to enable a device to identify that sounds come from other devices as opposed to a human user. Additionally, the present disclosure provides a technical advantage in determining whether a command coming from an obstruction direction is due to an audio output device or a human by querying the device for recent audio samples.
[0078] The operations described above may be completed in any order and are not limited to those described. Additionally, some, all, or none of the operations described above may be completed while still remaining within the scope of the present disclosure.
[0079] 3 is a flow diagram illustrating an example method for communicating an audio file to a voice command device according to an embodiment of the present disclosure. Audio output devices that output sound, such as televisions, radios, or mobile devices, can include software components that allow them to communicate with the VCD upon request (e.g., smart speakers or smart televisions with network interface controllers (NICs)). The audio output devices will require a software update to include this functionality, and the audio output devices will also need to be connected to the same network as the VCD, such as a home WiFi network.
[0080] Method 300 begins with an audio device monitoring the audio output. This is shown in step 301. The audio output may be buffered for a predefined or configured period of time. This is shown in step 302. For example, the audio output device may store the last 10 seconds, 1 minute, 5 minutes, etc. of the audio output.
[0081] The audio output device may receive a status request from the VCD. This is shown in step 303. The request may be the same as or substantially similar to the request described with reference to step 275 of FIG. 2C. In an embodiment, the request may inquire about a volume state or a power state, or both. The audio output device may respond to the request with a status response. This is shown in step 304. The status response may include a volume state or a power state, or both. If the VCD determines that the audio output device is outputting audio based on the status response, a request for an audio output sample may be received from the VCD. This is shown in step 305. In some embodiments, if the audio output device is emitting audio, it automatically communicates to the VCD its most recently buffered audio output in the form of an audio file. This is shown in step 306. In some embodiments, the audio output device may wait to receive a request for an audio sample from the VCD before communicating the buffered audio file to the VCD.
[0082] The operations described above may be completed in any order and are not limited to those described. Additionally, some, all, or none of the operations described above may be completed while still remaining within the scope of the present disclosure.
[0083] Referring to Figure 4, a block diagram of a VCD 420 according to an embodiment of the present disclosure is shown. The VCD 420 may be the same as or substantially similar to the VCD 120 described in Figure 1. In an embodiment, the components illustrated in the VCD 420 may be explicitly configured processor-executable instructions to be executed by a processor.
[0084] The VCD 420 may be a dedicated or multi-purpose computing device that includes at least a processor 401 and includes hardware modules or circuits that perform the functions of the described components, which are software units executing on at least the processor 401. Multiple processors operating parallel processing threads may be provided to enable parallel processing of some or all of the functions of the components. The memory 402 may be configured to provide computer instructions 403 to the at least one processor 401.
[0085] VCD 420 may include various components of known VCD functionality depending on the type of device and known processes. In an embodiment, VCD 420 includes an audio input receiver 404 that includes multiple (e.g., two or more) microphones configured as an array for receiving audio input from different directions relative to VCD 420. This sound received by the multiple microphones of audio input receiver 404 can be used to determine the location (e.g., direction) of the incoming noise.
[0086] The VCD 420 may include a command processing system 406 in the form of existing software on the VCD for receiving and processing voice commands. In addition, a voice command identification system 410 is provided for determining direction, intercepting and identifying commands from a blocked direction. The VCD 420 may further include a voice command discrimination system 440 configured to distinguish voice input from known audio output devices from blocked directions and from true voice input commands, which may be from unknown or unregistered users.
[0087] The VCD software includes voice command recognition processing and may be provided locally to the VCD 420 or on a computing device, or as a remote service over a network, e.g., a cloud-based service. The voice command identification system 410 and the voice command discrimination system 440 may be provided as a downloadable update to the VCD software, or may be provided as a separate add-on remote service over a network, e.g., as a cloud-based service. The remote service may also be provided as an application or application update for the audio output device to provide the above functionality to the audio output device.
[0088] The voice command discrimination system 440 includes a blocking direction component 421 for accessing one or more blocking directions for background audio noise for a position of the VCD 420 provided by the voice command discrimination system 410. A data store 430 of blocking directions associated with audio output devices including stored communication channels for the audio output devices is maintained by the voice command discrimination system 410.
[0089] The audio input receiver 404 can be configured to receive audio input at the VCD 420 at its location and determine that the audio input is received from the blocked direction.
[0090] The voice command discrimination system 440 can include an identification component 423 for identifying an audio output device associated with the block direction by referencing the data store 430. The identification component 423 can determine devices located in the block direction via triangulation or time difference of arrival.
[0091] The voice command discrimination system 440 may include a query component 424 configured to query the status of a sound-identified audio output device if it is currently emitting audio output and if it is currently emitting audio output to obtain a file of the most recent audio output output from the audio output device. The query component 424 includes a status request component 425 configured to request one or more statuses (e.g., volume or power state) from one or more devices. The query component 424 further includes an audio determination component 426 for determining whether the queried audio device is emitting audio (e.g., volume / power state). In some embodiments, the query component 424 includes a threshold component 427 that implements one or more thresholds for determining whether the audio output device is emitting audio. For example, the threshold component 427 may be configured to set a volume threshold for determining whether the device is emitting audio. The query component may include a status receive component 431 for receiving a status from the audio output device.
[0092] The query component 424 queries the status of all audio devices within range of the voice command device to determine which of them are currently emitting audio output. The query component 424 can obtain buffered audio files of the audio output devices.
[0093] The voice command discrimination system 440 may include an audio file acquisition component 432 for receiving an audio file from the queried audio output device. The acquired audio file is compared to the audio input received at the audio input receiver 404.
[0094] 0105 The voice command discrimination system 440 may include a comparison component 428 for comparing the acquired audio file with the received voice input. The comparison component 428 may include a processing component 429 for processing the acquired audio file and the received voice input to convert the audio file and the voice input to text and to represent the text as a phonetic string for comparison. However, the processing component 429 may process the audio file in any other manner (e.g., modulating the audio file's amplitude, duration, etc.).
[0095] The voice command discrimination system 440 can include a voice input ignoring component 433 for ignoring the received voice input if there is a substantial match with the retrieved audio file.
[0096] The voice command discrimination system 440 may also include a mobile device communication component 460. The mobile device communication component 460 may be configured to synchronize with nearby mobile devices with the blocking directions stored in the data store 430. Additionally, the mobile device communication component 460 may also be configured to receive signals from the mobile devices, and the VCD 420 may store updated locations of the respective mobile devices. In an embodiment, the mobile device communication component 460 may communicate VCD data, such as voice recognition data (e.g., voiceprints of registered users), background noise data (e.g., characteristics of background noise), and acoustic condition data (e.g., received by the query component 424) stored in the data store 430 to nearby mobile devices.
[0097] 0108 5, a block diagram of an example audio output device 550 is shown in accordance with an embodiment of the present disclosure. In an embodiment, audio output device 550 may be any suitable audio output device. For example, audio output device 550 may be television 114, radio 112, or mobile device 150 shown in FIG. 1. However, audio output device 550 may be a smart watch, a mobile device, a speaker, a voice command device, a computer system (e.g., laptop, desktop, etc.), or any other suitable audio output device.
[0098] The audio output device 550 may be in any form having an audio output and at least one processor 551 including circuitry for performing the functions of the components described above, which may be hardware modules or software units executing on the at least one processor 551. Multiple processors operating parallel processing threads may be provided to allow parallel processing of some or all of the functions of the components. The memory 552 may be configured to provide computer instructions 553 to the at least one processor 551.
[0099] The audio output device 550 includes software components that enable it to communicate with a VCD (e.g., VCD 120 or VCD 420) in the form of an audio output providing system 560. The audio output device 550 may require a software update to include this functionality, and the audio output device 550 is also required to be connected to the same network as the VCD, such as the user's home WiFi network.
[0100] 0111 The audio output providing system 560 may include a monitoring component 561 for monitoring the audio output of the audio output device 550 and a buffering component 562 for buffering the most recent audio output in a buffer 563 for a predetermined period of time.
[0101] The audio output providing system 560 includes a status component 564 for sending a status response to the querying VCD to determine whether the audio output device 550 is currently emitting audio output.
[0102] The audio output providing system 560 may include an audio file component 565 for sending an audio file to the VCD when the audio output device 550 is currently emitting audio output. The sent audio file may be the most recently buffered audio output from the buffer 563 of the audio output device 550.
[0103] Referring to FIG. 6, a flow diagram illustrating an example method 600 for filtering voice commands on a mobile device in proximity to a VCD (e.g., mobile device 150 of FIG. 1) in accordance with an embodiment of the present disclosure.
[0104] Method 600 begins at step 605 with establishing communication with a VCD (e.g., VCD 120 of FIG. 1 or a VCD of FIG. 4), as shown at step 605. Communication may be established with the VCD in any suitable manner, including wired or wireless network communication.
[0105] VCD data is then received from the VCD, as shown in step 610. The VCD data may include any data held in the VCD memory, including stored block direction, voice recognition data, trigger word data, acoustic characteristics of the background noise (e.g., amplitude, pitch, etc. of the background noise), contextual information associated with the background noise (e.g., metadata associated with the background noise), and audio output state data (e.g., volume / power data for nearby output devices).
[0106] 0117 The command is then received at the mobile device. This is shown in step 615. The command may be received in response to vocalization of a trigger word. It is then determined whether the mobile device has directional analysis capabilities. This is shown in step 620. If the mobile device has directional analysis capabilities (e.g., the mobile device is configured to perform trigonometry), then a determination is made whether the command was received from an obstructed direction. This is shown in step 625. This may be accomplished substantially similar to step 256 of FIG. 2. If the command was not received from an obstructed direction, then the command is executed in step 650. If the command was received from an obstructed direction, then a determination is made whether the command is within a recognized voice. This is shown in step 645. The determination of whether the command is within a recognized voice may be accomplished substantially similar to step 254 of FIG. 2B. If the command is a recognized voice, then the command is executed in step 650. If the command is not a recognized voice, then the command is ignored. This is shown in step 640.
[0107] If it is determined that the mobile device does not have directional analysis capabilities, then the sound is analyzed and compared to the details of the background noise source. This is shown in step 630. The VCD data received in step 610 may include acoustic characteristics of background noise that a VCD would normally receive. The acoustic characteristics of the background noise are compared to the currently received acoustic data to determine if there is a match. A determination that the background noise is similar is completed based on the comparison in step 630. This is shown in step 635. For example, if the frequency, amplitude, tone, etc. of the acoustic characteristics match the frequency, amplitude, tone, etc. of the currently received sound, then the sound may be determined to be similar to the background noise.
[0108] In some embodiments, contextual information (e.g., time of day) is considered when determining whether the background noises are similar. For example, metadata associated with the background noise received in step 610 is compared to the acoustic metadata currently received at the mobile device to determine whether the background noises are similar. In some embodiments, the contextual information, in addition to the acoustic data, may be collectively considered in determining whether the background noises are similar.
[0109] If a determination is made that the background noise is similar (e.g., there is a substantial match, which can be based on a threshold), then the command is ignored at step 640. If it is determined that the background noise is not similar, then it is determined at step 645 whether the command was received in recognized speech. If the command is recognized speech, then the command is executed at step 650. If the command is not recognized speech, then the command is ignored at step 640.
[0110] The operations described above may be accomplished in any order and are not limited to those described above. Additionally, some, all, or none of the operations described above may be performed while still remaining within the scope of the present disclosure.
[0111] FIG. 7 is a flow diagram of an example embodiment that allows updating a VCD with a mobile device's location and adding it to a blocking direction, according to an embodiment of the present disclosure.
[0112] 0123 Method 700 begins at step 705, where communication is established with the VCD. An acoustic tone is then transmitted from the mobile device to indicate the source of the background noise. This is shown at operation 710. The tone can be of any amplitude of frequency. The VCD then performs a directional analysis and the location of the mobile device is stored as the intercept direction. This is shown at operation 715. The directional analysis can be performed as described above in FIGS. 1-6. The mobile device then changes location. This is shown at operation 720. The acoustic tone is then emitted again to indicate the new location as a potential background noise source. This is shown at operation 725. A determination is made whether a command has been received from the mobile device at that location (e.g., operation 720).
[0113] If a command is received from the location, then the command is ignored. This is shown at operation 735. If a command is not received from the location, then a determination is made whether the mobile device has left the vicinity. This is shown at operation 740. The determination whether the mobile device has left the vicinity can be accomplished based on a provided communication link between the VCD and the mobile device. In some embodiments, the determination that the mobile device has left the vicinity can be accomplished based on location data (e.g., Global Positioning System (GPS) data of the mobile device. If a determination is made that the device has left the vicinity, then the blocking direction is deleted from storage of the VCD. This is shown at operation 745. If it is determined that the device has not left the vicinity of the VCD, method 700 returns to operation 730 and commands are continuously monitored at the VCD.
[0114] The operations described above may be completed in any order and are not limited to those described above. Additionally, some, all, or none of the operations described above may be performed while still remaining within the scope of the present disclosure.
[0115] 8, there is shown a high level block diagram of an embodiment of a computer system 801 (e.g., VCD 120 of FIG. 1, VCD 420 of FIG. 4, audio output device 550 of FIG. 5) that may include one or more methods, tools, and modules disclosed herein, and any associated functionality, in accordance with an embodiment of the present disclosure (e.g., using one or more processor circuits of a computer or computer processor). In some embodiments, the main components of computer system 801 may include one or more CPU(s) 802, a memory subsystem 804, a terminal interface 812, a storage interface 814, an I / O (input / output) device interface 816, and a network interface 818, all of which are communicatively coupled, directly or indirectly, via a memory bus 803, an I / O bus 808, and an I / O bus interface unit 810 for inter-component communication.
[0116] 0127 Computer system 801 may include one or more general purpose programmable central processing units (CPUs) 802A, 802B, 802C, and 802D, generally referred to as CPUs 802. In some embodiments, computer system 801 may include multiple processors, as is typical in larger systems, but in other embodiments may alternatively be a single CPU system. Each CPU 802 may execute instructions stored in memory subsystem 804 and may include one or more on-board caches.
[0117] The system memory 804 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 822 or cache memory 824. The computer system 801 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 826 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium, such as a "hard drive." Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk drive (e.g., a "USB thumb drive" or a "floppy disk"), or an optical disk drive may be provided for reading from and writing to a CD-ROM, DVD-ROM, or other optical medium. In addition, the memory 804 may include flash memory, such as, for example, a flash memory stick drive or a flash drive. Memory devices may be connected to the memory bus 803 by one or more data media interfaces. The memory 804 may include at least one program product including a set (eg, at least one) of program modules configured to perform the functions of the various embodiments.
[0118] The one or more programs / utilities 828 each have at least one program module 830 stored in memory 804. The programs / utilities 828 may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. The operating system, one or more application programs, other program modules, and program data, or some combination thereof, may each include an implementation of a network environment. The programs 828 or program modules 830, or both, generally perform the functions or methodologies of the various embodiments.
[0119] In some embodiments, the program modules 830 of the computer system 801 include a voice command discrimination module. The voice command discrimination module can be configured to access one or more blocking directions of background noise from one or more audio output devices. The voice command discrimination module can be further configured to receive audio input and determine whether it is received from a blocking direction. The voice command discrimination module can be configured to query the state of the audio device to determine whether it is generating audio. The voice discrimination module can then be configured to compare the audio sample to the voice command and ignore the voice command if the audio sample substantially matches the voice command.
[0120] In an embodiment, the program modules 830 of the computer system 801 include a voice command filtering module. The voice command filtering module can be configured to receive VCD data from a VCD. The voice command module can be configured to determine whether a voice command is received from a blocking direction described in the VCD data. If a voice command is received from a blocking direction described in the VCD data, then the voice command is ignored.
[0121] 8 provides a single bus structure providing a direct communication path between the CPUs 802, memory subsystem 804, and I / O bus interface 810, memory bus 803 in some embodiments may include multiple different buses or communication paths arranged in any of a variety of configurations, such as hierarchical point-to-point, star, or web configurations, multiple hierarchical buses, parallel and redundant buses, or any other suitable type of configuration linking. Additionally, while I / O bus interface 810 and I / O bus 808 are each shown as single units, computer system 801 in some embodiments may include multiple I / O bus interface units 810, multiple I / O buses 808, or both. Additionally, although multiple I / O interface units are shown with I / O bus 808 branching off from various communication paths running to various I / O devices, in other embodiments some or all of the I / O devices may be connected to one or more system I / O buses.
[0122] In some embodiments, computer system 801 may be a multi-user computer system, a single-user computer system, or a server computer or similar device that has little or no user interface but receives requests from other computer systems (multiple clients). Further, in some embodiments, computer system 801 may be implemented as a desktop computer, a portable computer, a laptop computer, a tablet computer, a pocket computer, a telephone, a smart phone, a network switch or router, or any other type of electronic device.
[0123] Figure 8 is intended to illustrate each of the exemplary major components of an exemplary computer system 801. In some embodiments, however, individual components may be larger or smaller than those shown in Figure 8, components other than or in addition to those shown in Figure 8 may be present, and the number, type, and arrangement of such components may vary.
[0124] Although this disclosure includes details about cloud computing, the teachings referenced herein are not limited to a cloud computing environment, but rather the disclosed environment can be implemented in combination with any other type of computing environment now known or developed in the future.
[0125] Cloud computing is a service delivery model for on-demand network access with the convenience of accessing a shared pool of rapidly provisioned and open configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) with minimal administrative effort or interaction with a service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.
[0126] Its features are as follows: On-Demand Self-Service: Cloud consumers are automatically provisioned with computing capacity - server time and network storage - on an as-needed basis without the need for human interaction with the service provider. Pervasive Network Access: Capabilities are available over the network and accessed through standard mechanisms facilitating use by different thin- and thick-client platforms (eg, mobile phones, laptops, and PDAs). Resource Sharing: Using a multi-tenant model, a provider's computing resources are shared to serve multiple consumers, with different physical and virtualized resources dynamically allocated and reallocated as needed. A sense of location independence exists, such that consumers generally have no control or knowledge of the exact location (e.g., country, state, or data center) of the resources provided, but can specify the location at a higher layer of abstraction. Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, to quickly scale out and quickly release to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased in any quantity at any time. Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services being used.
[0127] The service model is as follows: Software as a Service (SaaS): The functionality provided to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for limited user-specific application configuration settings. Platform as a Service (PaaS): The capability offered to a consumer is to deploy applications that the consumer has created or acquired, written using programming languages and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and, potentially, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The functionality provided to the consumer is the provision of processing, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over select networking components (e.g., host firewalls).
[0128] The layout model is as follows: Private Cloud: The cloud infrastructure operates solely for one organization. It can be managed by that organization or a third party and can exist on-premises or off-premises. Community Cloud: The cloud infrastructure is shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by those organizations or by a third party and can exist on-premises or off-premises. Public Cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by organizations that sell cloud services. Hybrid Cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound to each other by standardized or proprietary technologies that allow portability of data and applications (e.g., cloud bursting for load balancing between clouds).
[0129] Cloud computing environments are service-oriented with a focus on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which contains multiple interconnected nodes.
[0130] FIG. 9 illustrates an exemplary cloud computing environment 50. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) (e.g., VCD 120 or VCD 420) or a cellular phone 54A (e.g., mobile device 150), a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, communicate. The nodes 10 can communicate with each other. They can be physically or virtually grouped in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof (not shown). This allows the cloud computing environment 50 to provide an infrastructure, platform, or software-as-a-service for cloud consumers to eliminate the need to maintain resources on local computing devices. The types of computing devices 54A-N shown in FIG. 9 are for illustrative purposes only, and it will be understood that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device through any type of network or addressable network connection (e.g., a web browser), or both.
[0131]
[0046] Referring now to Figure 10, there is shown a set of functional abstraction layers provided by the cloud computing environment 50 of Figure 9. It should be understood that the components, layers, and functions shown in Figure 10 are intended to be illustrative only, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:
[0132] The hardware and software layer 60 includes hardware and software components. Examples of the hardware components may include a mainframe 61, a plurality of servers based on a RISC (reduced instruction set computer) architecture 62, a plurality of servers 63, a plurality of blade servers 64, a plurality of storage devices 65, and a network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.
[0133] The visualization layer 70 provides an abstraction layer from which embodiments of virtual entities, described below; virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.
[0134] In one embodiment, the management layer 80 may provide the following functions: A resource provisioning unit 81 provides dynamic acquisition of computing resources and other resources used to execute tasks within the cloud computing environment. A metering and pricing unit 82 provides cost tracking as resources are used within the cloud computing environment and provides billing or charging for the consumption of these resources. In one embodiment, these resources may include application software licenses. A security unit provides identification and authentication of cloud consumers and tasks as well as protection of data and other resources. A user portal unit 83 provides accessibility to the cloud computing environment and system administrators for consumers. A service level management unit 84 provides allocation and management of cloud computing resources to meet required service levels. A service level agreement (SLA) planning and fulfillment unit 85 provides pre-provisioning and acquisition of cloud computing resources as future requests are required according to SLAs.
[0135] The workload layer 90 provides examples of functionality for utilizing a cloud computing environment. Examples of workloads and functionality provided by this layer may include mapping and navigation 91; software development and lifetime management 92; virtual classroom instructional delivery 93; data analytics processing 94; transaction processing 95; and voice command processing 96.
[0136] As discussed in more detail herein, some or all of the operations of some of the method embodiments described herein may be performed in an alternating order, or not all may be performed, and further, many operations may occur simultaneously or as part of a larger process.
[0137] The present disclosure may be a system, method, or computer program product, or a combination thereof, including a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform features of the present disclosure.
[0138] A computer readable recording medium may be a tangible device capable of holding and storing a plurality of instructions for use by an instruction execution device. A computer readable medium may be, for example, but not limited to, an electrical recording device, a magnetic recording device, an optical recording device, an electro-magnetic recording device, a semiconductor recording device, or any suitable combination thereof. More specific examples of computer readable recording media include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a punch card, or a mechanically encoded device having protruding structures within a groove having instructions recorded therein, and any suitable combination thereof. As used herein, a computer-readable recording medium is not to be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves such as wave guides or other communications media (e.g., light pulses passing through fiber optic cable), or electrical signals communicated through wires.
[0139] The computer programs described herein can be downloaded from a computer readable recording medium into each computing / processing device, or can be downloaded to an external computer or external recording device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, and combinations thereof. The network can include copper communication cables, fiber optic communication, wireless communication routers, firewalls, switches, gateway computers, and edge servers, and combinations thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions into a computer readable recording medium in each computing / processing device for storage.
[0140] The computer readable program instructions for carrying out the operations of the present invention can be either source code or object code written in any combination of programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or one or more procedural programming languages, such as Smalltalk®, object oriented programming languages such as C++, the “C” programming language, or similar programming languages. The computer readable program instructions can be executed entirely on the user computer, partially on the user computer as a stand-alone software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user computer through any type of network, including a local area network (LAN), a wide area network (WAN), or the connection can be to an external computer (e.g., through an Internet service provider). In some embodiments, computer readable program instructions may be executed by electrical circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), and state information of the computer readable program instructions may be used to personalize the electrical circuitry to perform features of the present invention.
[0141] Features of the invention described herein have been described with reference to flowchart instructions and / or block diagrams of methods, apparatus (systems), and computer-readable recording media and computer program products according to embodiments of the invention. It will be understood that any combination of flowchart illustrations and / or block diagrams and / or blocks in flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.
[0142] The computer-readable program instructions can be provided to a general purpose computer, a special purpose computer, or other processor or other programmable data processing device to produce a machine, which when executed by the processor of the computer or other programmable data processing device produces means for implementing the functions / operations specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof. These computer-readable program instructions that direct a computer, programmable data processing device, and other device, or a combination thereof, to function in a particular manner can also be stored on a computer-readable recording medium, and the computer-readable recording medium having instructions stored therein constitutes an article of manufacture containing instructions that implement the functional / operational features specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof.
[0143] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause a computer implemented process to perform a series of operational steps on the computer, other programmable apparatus, or other device to implement the functions / acts specified in the blocks of the flowcharts and block diagrams or in a combination thereof.
[0144] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and possible implementation operations of systems, methods, and computer programs according to various embodiments of the present invention. In this respect, the flowcharts or block diagrams may represent modules, segments, or portions of instructions, which include one or more executable instructions for implementing a particular logical function(s) (or functions). In some alternative implementations, the functions described in the blocks may be performed other than as illustrated. For example, two blocks shown in succession may be actually performed as one step, may be performed simultaneously, substantially simultaneously, partially or completely overlapped in time, or the blocks may be sometimes performed in reverse order, depending on the functionality involved. It is also noted that the illustration of the blocks in the block diagrams and / or the illustration of the flowcharts or combinations thereof may be implemented by a system based on special purpose hardware that performs a particular function or operation or executes specific purpose hardware and computer instructions.
[0145] The terms used herein are for the purpose of describing particular embodiments and are not intended to limit the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, the terms "includes", "including", and "including" as used herein are to be understood as specifying the presence of a declared feature, integer, step, operation, element, or component, or combination thereof, but not excluding the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups, or combinations thereof. In the above detailed description of exemplary embodiments of various embodiments, reference has been made to the drawings, in which like elements have like reference numerals, which form a part hereof, and in which the reference numerals are shown for the purpose of illustrating specific exemplary embodiments in which the various embodiments may be practiced. These embodiments are described in sufficient detail to enable one skilled in the art to practice the embodiments, but other embodiments may be made in which logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the above description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. However, various embodiments may be practiced without these specific details. Other examples, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the embodiments.
[0146] Different examples of the term "embodiment" within this specification may, but do not necessarily, refer to the same embodiment. Any data and data structures shown or described herein are exemplary only, and other embodiments, different amounts of data, types of data, fields, numbers and types of fields, field names, columns, rows, numbers and types of entries, or organization of data may be used. In addition, separate data structures are not required, as any data may be combined with logic. The above detailed description is therefore not to be taken in a limiting sense.
[0147] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exclusive or limited to the disclosed embodiments. Many modifications or variations will be obvious to those skilled in the art without departing from the scope and spirit of the present disclosure. The terms used in this specification are selected to best explain the principles of the present embodiments, practical applications, or technical improvements beyond the technology found in the market, or to allow others skilled in the art to understand the embodiments disclosed herein.
[0148] While the present disclosure has been described in terms of specific embodiments, alterations and modifications thereof will be apparent to those skilled in the art, and it is therefore intended that the following claims be interpreted to cover such alterations and modifications that fall within the scope of the present disclosure.
Claims
1. 1. A computer-implemented method for filtering voice commands executed by a computing device, the method comprising: Establishing communication with a voice command device located at a location; receiving data from the voice command device indicative of a direction of interruption; receiving a voice command; if the computing device has a directional analysis capability, determining through the directional analysis capability that the voice command was received from an obstructed direction indicated in the data; ignoring the received voice command in response to determining that the voice command was received from a blocked direction indicated in the data; receiving a set of data from the voice command device indicative of a characteristic of background noise; comparing the voice command to the set of data indicative of characteristics of background noise if the computing device does not have directional analysis capabilities; determining, based on the comparison, that the voice command matches a characteristic of the background noise; and in response to determining that the voice command matches a characteristic of the background noise, ignoring the voice command.
23. A computer-implemented method comprising:
2. moreover, determining that the voice command is in a recognized voice; and executing said voice command; The method of claim 1 , comprising:
3. The method of claim 1 or 2, wherein determining that the voice command was received from the blocked direction is determined by a time difference of arrival.
4. moreover, 4. The method of claim 1, further comprising emitting an acoustic tone to notify the voice command device of a second blocking direction, the voice command device locating the acoustic tone and storing it in the data indicating the blocking direction.
5. further querying a status of a plurality of audio output devices to determine which of the plurality of audio output devices is currently emitting audio output; obtaining an audio file from each of the audio output devices determined to be emitting an audio output; comparing the audio file with the received voice command; ignoring the received voice command if there is at least one substantial match of the retrieved audio file; The method according to any one of claims 1 to 4, comprising:
6. moreover, receiving a set of data indicative of contextual data of background noise received at the voice command device; if the computing device does not have directional analysis capabilities, comparing a context of the voice command to the context data of background noise received at the voice command device; determining, based on the comparison, that a context of the voice command matches the background noise received at the voice command device; and ignoring the voice command in response to determining that a context of the voice command matches the background noise received at the voice command device; The method according to any one of claims 1 to 5, comprising:
7. 1. A system for filtering voice commands, the system comprising: A computing device including a memory storing program instructions and a processor configured to execute the program instructions to perform a method; The method comprises: Establishing communication with a voice command device located at a location; receiving data from the voice command device indicative of a direction of interruption; receiving a voice command; if the computing device has a directional analysis capability, determining through the directional analysis capability that the voice command was received from an obstructed direction indicated in the data; ignoring the received voice command in response to determining that the voice command was received from a blocked direction indicated in the data; receiving a set of data from the voice command device indicative of a characteristic of background noise; comparing the voice command to the set of data indicative of characteristics of background noise if the computing device does not have directional analysis capabilities; determining, based on the comparison, that the voice command matches a characteristic of the background noise; and in response to determining that the voice command matches a characteristic of the background noise, ignoring the voice command. Including, the system.
8. The method executed by the processor further comprises: determining that the voice command is in a recognized voice; and executing said voice command; The system of claim 7 , comprising:
9. 9. The system of claim 7 or 8, wherein determining that the voice command was received from the blocked direction indicated in the data is determined by time difference of arrival.
10. The method executed by the processor further comprises: The system of any one of claims 7 to 9, further comprising emitting an acoustic tone to notify the voice command device of a second blocking direction, the voice command device locating the acoustic tone and storing it within the data indicating the blocking direction.
11. The method executed by the processor further comprises: querying a status of a plurality of audio output devices to determine which of the plurality of audio output devices is currently emitting audio output; obtaining an audio file from each of the audio output devices determined to be emitting an audio output; comparing the audio file with the received voice command; ignoring the received voice command if there is at least one substantial match of the retrieved audio file; The system according to any one of claims 7 to 10, comprising:
12. The method executed by the processor further comprises: receiving a set of data indicative of contextual data of background noise received at the voice command device; if the computing device does not have directional analysis capabilities, comparing a context of the voice command to the context data of background noise received at the voice command device; determining, based on the comparison, that a context of the voice command matches the background noise received at the voice command device; and ignoring the voice command in response to determining that a context of the voice command matches the background noise received at the voice command device; The system according to any one of claims 7 to 11, comprising:
13. 1. A computer program for filtering voice commands, recorded on a computer readable medium and locatable in an internal memory of a digital computer, the computer program comprising: A computer program readable by a processing circuit and comprising software code portions for carrying out the method according to any one of claims 1 to 6.
Citation Information
Patent Citations
Electronic device microphone listening modes
US20190132694A1
