US20170236515A1 - Model for Enabling Service Providers to Address Voice-Activated Commands - Google Patents
Model for Enabling Service Providers to Address Voice-Activated Commands Download PDFInfo
- Publication number
- US20170236515A1 US20170236515A1 US15/582,759 US201715582759A US2017236515A1 US 20170236515 A1 US20170236515 A1 US 20170236515A1 US 201715582759 A US201715582759 A US 201715582759A US 2017236515 A1 US2017236515 A1 US 2017236515A1
- Authority
- US
- United States
- Prior art keywords
- service
- service provider
- action
- party
- commands
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000009471 action Effects 0.000 claims abstract description 107
- 238000000034 method Methods 0.000 claims abstract description 70
- 238000013507 mapping Methods 0.000 claims description 4
- 239000011521 glass Substances 0.000 description 20
- 235000013550 pizza Nutrition 0.000 description 18
- 238000004891 communication Methods 0.000 description 16
- 238000012545 processing Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 10
- 230000008569 process Effects 0.000 description 8
- 230000000007 visual effect Effects 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 7
- 238000009428 plumbing Methods 0.000 description 7
- 210000000988 bone and bone Anatomy 0.000 description 6
- 210000003128 head Anatomy 0.000 description 6
- 230000004886 head movement Effects 0.000 description 6
- 235000004789 Rosa xanthina Nutrition 0.000 description 5
- 241000109329 Rosa xanthina Species 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 230000005587 bubbling Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 239000000463 material Substances 0.000 description 5
- 230000004044 response Effects 0.000 description 5
- 230000004424 eye movement Effects 0.000 description 4
- 230000003190 augmentative effect Effects 0.000 description 3
- 235000021152 breakfast Nutrition 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 239000011248 coating agent Substances 0.000 description 2
- 238000000576 coating method Methods 0.000 description 2
- 210000005069 ears Anatomy 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 235000015241 bacon Nutrition 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 210000000959 ear middle Anatomy 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 235000013601 eggs Nutrition 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000005043 peripheral vision Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 210000001525 retina Anatomy 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000010897 surface acoustic wave method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
- G10L15/00—Speech recognition
- G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue
-
- G—PHYSICS
- G02—OPTICS
- G02B—OPTICAL ELEMENTS, SYSTEMS OR APPARATUS
- G02B27/00—Optical systems or apparatus not provided for by any of the groups G02B1/00 - G02B26/00, G02B30/00
- G02B27/01—Head-up displays
- G02B27/017—Head mounted
- G02B27/0172—Head mounted characterised by optical features
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/011—Arrangements for interaction with the human body, e.g. for user immersion in virtual reality
- G06F3/013—Eye tracking input arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
- G06F3/0482—Interaction with lists of selectable items, e.g. menus
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
- G06F3/04842—Selection of displayed objects or displayed text elements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/16—Sound input; Sound output
- G06F3/167—Audio in a user interface, e.g. using voice commands for navigating, audio feedback
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0251—Targeted advertisements
- G06Q30/0269—Targeted advertisements based on user profile or attribute
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0273—Determination of fees for advertising
- G06Q30/0275—Auctions
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
- G10L15/00—Speech recognition
- G10L15/02—Feature extraction for speech recognition; Selection of recognition unit
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
- G10L15/00—Speech recognition
- G10L15/26—Speech to text systems
-
- G—PHYSICS
- G02—OPTICS
- G02B—OPTICAL ELEMENTS, SYSTEMS OR APPARATUS
- G02B27/00—Optical systems or apparatus not provided for by any of the groups G02B1/00 - G02B26/00, G02B30/00
- G02B27/01—Head-up displays
- G02B27/0101—Head-up displays characterised by optical features
- G02B2027/0138—Head-up displays characterised by optical features comprising image capture systems, e.g. camera
-
- G—PHYSICS
- G02—OPTICS
- G02B—OPTICAL ELEMENTS, SYSTEMS OR APPARATUS
- G02B27/00—Optical systems or apparatus not provided for by any of the groups G02B1/00 - G02B26/00, G02B30/00
- G02B27/01—Head-up displays
- G02B27/0101—Head-up displays characterised by optical features
- G02B2027/014—Head-up displays characterised by optical features comprising information/image processing systems
-
- G—PHYSICS
- G02—OPTICS
- G02B—OPTICAL ELEMENTS, SYSTEMS OR APPARATUS
- G02B27/00—Optical systems or apparatus not provided for by any of the groups G02B1/00 - G02B26/00, G02B30/00
- G02B27/01—Head-up displays
- G02B27/017—Head mounted
- G02B2027/0178—Eyeglass type
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
- G10L15/00—Speech recognition
- G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue
- G10L2015/223—Execution procedure of a spoken command
Definitions
- Computing devices such as personal computers, laptop computers, tablet computers, cellular phones, and countless types of Internet-capable devices are increasingly prevalent in numerous aspects of modern life. Over time, the manner in which these devices are providing information to users is becoming more intelligent, more efficient, more intuitive, and/or less obtrusive.
- wearable computing The trend toward miniaturization of computing hardware, peripherals, as well as of sensors, detectors, and image and audio processors, among other technologies, has helped open up a field sometimes referred to as “wearable computing.”
- wearable displays In the area of image and visual processing and production, in particular, it has become possible to consider wearable displays that place a graphic display close enough to a wearer's (or user's) eye(s) such that the displayed image appears as a normal-sized image, such as might be displayed on a traditional image display device.
- the relevant technology may be referred to as “near-eye displays.”
- Wearable computing devices with near-eye displays may also be referred to as “head-mountable displays” (HMDs), “head-mounted displays,” “head-mounted devices,” or “head-mountable devices.”
- a head-mountable display places a graphic display or displays close to one or both eyes of a wearer.
- a computer processing system may be used to generate the images on a display.
- Such displays may occupy a wearer's entire field of view, or only occupy part of wearer's field of view.
- head-mounted displays may vary in size, taking a smaller form such as a glasses-style display or a larger form such as a helmet, for example.
- Emerging and anticipated uses of wearable displays include applications in which users interact in real time with an augmented or virtual reality.
- Such applications can be mission-critical or safety-critical, such as in a public safety or aviation setting.
- the applications can also be recreational, such as interactive gaming.
- An utterance may be received on a computing device, which may include a command.
- a service action associated with the command may then be selected.
- a selected service provider may then be determined for the selected service action, where the selected service provider is selected from a plurality of service providers.
- a service fulfillment request may then be sent to the selected service provider to execute the selected service action.
- a method may include: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and sending a service fulfillment request to the selected service provider to execute the selected service action.
- a method may include: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining one or more selected service providers for the selected service action, where the one or more selected service providers are selected from a plurality of service providers; and displaying on the computing device one or more advertisements corresponding to the selected service action from the one or more selected service providers.
- a non-transitory computer-readable medium configured to store program instructions that, when executed by a processor, cause the processor to carry out functions comprising: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and sending a service fulfillment request to the selected service provider to execute the selected service action.
- Further example embodiments may include: means for receiving a first utterance on a computing device, where the first utterance includes a first command; means for selecting a service action that corresponds to the first command; means for determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and means for sending a service fulfillment request to the selected service provider to execute the selected service action.
- FIG. 1A illustrates a wearable computing system according to an example embodiment.
- FIG. 1B illustrates an alternate view of the wearable computing device illustrated in FIG. 1A .
- FIG. 1C illustrates another wearable computing system according to an example embodiment.
- FIG. 1D illustrates another wearable computing system according to an example embodiment.
- FIGS. 1E to 1G are simplified illustrations of the wearable computing system shown in FIG. 1D , being worn by a wearer.
- FIG. 2A is a simplified block diagram of a computing device according to an example embodiment.
- FIG. 2B shows a projection of an image by a head-mountable device, according to an example embodiment.
- FIG. 3A shows an example voice navigable menu, according to an example embodiment.
- FIG. 3B shows an example voice navigable menu, according to an example embodiment.
- FIG. 4 shows an example visible menu, according to an example embodiment.
- FIG. 5 shows an example visible menu, according to an example embodiment.
- FIG. 6 shows an example visible menu, according to an example embodiment.
- FIG. 7 shows an example visible menu, according to an example embodiment.
- FIG. 8A shows an example visible menu, according to an example embodiment.
- FIG. 8B shows an example visible menu, according to an example embodiment.
- FIG. 9A shows an example visible menu, according to an example embodiment.
- FIG. 9B shows an example visible menu, according to an example embodiment.
- FIG. 9C shows an example visible menu, according to an example embodiment.
- FIG. 10 is a flow chart illustrating a method, according to an example embodiment.
- FIG. 11A shows an example list of commands, according to an example embodiment.
- FIG. 11B shows an example command-service mapping, according to an example embodiment.
- FIG. 12A shows an example determination of a service provider, according to an example embodiment.
- FIG. 12B shows an example service request, according to an example embodiment.
- FIG. 13 is a flow chart illustrating another method, according to an example embodiment.
- FIG. 14A shows an example determination of multiple service providers, according to an example embodiment.
- FIG. 14B shows an example display showing ads from multiple service providers, according to an example embodiment.
- FIG. 14C shows an example service request to a selected service provider, according to an example embodiment.
- Example methods and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.” Any embodiment or feature described herein as being an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features.
- Head-mounted displays and other computing devices may use a voice-based user interface to capture audible input from the user of the HMD. Upon receiving audible input, the HMD may attempt to recognize the input as a speech command and process the command accordingly.
- the speech input can represent commands to the HMD, such as commands to search, navigate, take photos, record videos, etc. Some commands may require fulfillment by a third party service provider, such as “order a pizza,” “call a plumber,” or “buy a movie ticket.”
- Example systems may allow multiple service providers to address a given voice command.
- a voice command may first be mapped to a selected service action.
- a third party service provider may be selected from a number of different service providers in order to fulfill the requested service action. For example, if the user commands the device to “order a dozen roses,” a service provider may be automatically selected, and the order may be filled. In some examples, the process may be streamlined so that the user may not see which service provider is filling the order.
- the selected service provider that will fulfill the service request may be chosen based at least in part on an auction. Multiple third party service providers may be given the opportunity to bid on the right to fulfill the service. The highest bidding third party service provider may be selected to fulfill the service request. Further, such an auction could take place prior to the service request or could take place in real time based on bidding criteria provided by the service providers.
- the HMD user or a system manager may be able to specify that certain service providers are preferred.
- the distance between the computing device and various service providers may be computed, and preference may be given to a closer third party service provider.
- third party service providers may be able to buy the right to present advertisements related to specific voice commands. For example, if the user commands the device to “order a dozen roses,” the user may then be presented with advertisements to buy roses from several different sellers. A service request to provide the dozen roses may then be sent to the service provider whose advertisement is chosen by the user.
- the third party service providers that get to display their advertisements may be based at least in part on an auction in which the providers bid on the right to have their ad displayed. Other criteria such as user preference or location may be factored in as well.
- the space of possible voice commands may be predetermined.
- the set of commands may be all of the commands accessible to the user by a voice-navigable user interface (VNUI).
- VNUI voice-navigable user interface
- certain commands may be included within menus reachable by the VNUI by default and other commands may later be added to one of the menus by the user.
- the selected service provider(s) for a certain voice command may be predetermined. For instance, if an auction is used to determine the selected service provider(s), the results of the auction may be pre-computed. In some examples, the HMD may recognize the voice command immediately without access to the network. The selected service provider(s) may then be pre-computed and pre-cached so that a third party service request may immediately be sent or the ads of selected service provider(s) may be immediately displayed to the user without network access. Further, the selected service provider(s) for a given command may later be refreshed after the command has issued.
- the selected service provider(s) may be determined in real time after the voice command has been received. For example, if an auction will be used to determine the selected service provider(s), the third party service providers may be able to specify certain parameters beforehand that will be used to determine the winners of the auction. These parameters may include the provider's total budget for advertising, the bid price, and a timeout period, for example. In further examples, the parameters may also be made to depend on other factors, such as the location of the HMD user or the time of day.
- the HMD user may be able to preconfigure which third party service provider will handle a given command.
- the user may be presented with a list of service providers. These service providers may be determined based on the results of an auction, based on preferences assigned by a system manager, and/or based on location, for example. The user may then choose a service provider from the list. Whenever the user issues the same voice command in the future, the same service provider may automatically be contacted. Accordingly, the user experience may be improved by not requiring the user to select a service provider multiple times for the same type of service request.
- an example system may be implemented in or may take the form of a wearable computer (also referred to as a wearable computing device).
- a wearable computer takes the form of or includes a head-mountable device (HMD).
- HMD head-mountable device
- An example system may also be implemented in or take the form of other devices, such as a mobile phone, among other possibilities. Further, an example system may take the form of non-transitory computer readable medium, which has program instructions stored thereon that are executable by at a processor to provide the functionality described herein. An example system may also take the form of a device such as a wearable computer or mobile phone, or a subsystem of such a device, which includes such a non-transitory computer readable medium having such program instructions stored thereon.
- An HMD may generally be any display device that is capable of being worn on the head and places a display in front of one or both eyes of the wearer.
- An HMD may take various forms such as a helmet or eyeglasses.
- references to “eyeglasses” or a “glasses-style” HMD should be understood to refer to an HMD that has a glasses-like frame so that it can be worn on the head.
- example embodiments may be implemented by or in association with an HMD with a single display or with two displays, which may be referred to as a “monocular” HMD or a “binocular” HMD, respectively.
- FIG. 1A illustrates a wearable computing system according to an example embodiment.
- the wearable computing system takes the form of a head-mountable device (HMD) 102 (which may also be referred to as a head-mounted display).
- HMD head-mountable device
- the HMD 102 includes frame elements including lens-frames 104 , 106 and a center frame support 108 , lens elements 110 , 112 , and extending side-arms 114 , 116 .
- the center frame support 108 and the extending side-arms 114 , 116 are configured to secure the HMD 102 to a user's face via a user's nose and ears, respectively.
- Each of the frame elements 104 , 106 , and 108 and the extending side-arms 114 , 116 may be formed of a solid structure of plastic and/or metal, or may be formed of a hollow structure of similar material so as to allow wiring and component interconnects to be internally routed through the HMD 102 . Other materials may be possible as well.
- each of the lens elements 110 , 112 may be formed of any material that can suitably display a projected image or graphic.
- Each of the lens elements 110 , 112 may also be sufficiently transparent to allow a user to see through the lens element. Combining these two features of the lens elements may facilitate an augmented reality or heads-up display where the projected image or graphic is superimposed over a real-world view as perceived by the user through the lens elements.
- the extending side-arms 114 , 116 may each be projections that extend away from the lens-frames 104 , 106 , respectively, and may be positioned behind a user's ears to secure the HMD 102 to the user.
- the extending side-arms 114 , 116 may further secure the HMD 102 to the user by extending around a rear portion of the user's head. Additionally or alternatively, for example, the HMD 102 may connect to or be affixed within a head-mounted helmet structure. Other configurations for an HMD are also possible.
- the HMD 102 may also include an on-board computing system 118 , an image capture device 120 , a sensor 122 , and a finger-operable touch pad 124 .
- the on-board computing system 118 is shown to be positioned on the extending side-arm 114 of the HMD 102 ; however, the on-board computing system 118 may be provided on other parts of the HMD 102 or may be positioned remote from the HMD 102 (e.g., the on-board computing system 118 could be wire- or wirelessly-connected to the HMD 102 ).
- the on-board computing system 118 may include a processor and memory, for example.
- the on-board computing system 118 may be configured to receive and analyze data from the image capture device 120 and the finger-operable touch pad 124 (and possibly from other sensory devices, user interfaces, or both) and generate images for output by the lens elements 110 and 112 .
- the image capture device 120 may be, for example, a camera that is configured to capture still images and/or to capture video. In the illustrated configuration, image capture device 120 is positioned on the extending side-arm 114 of the HMD 102 ; however, the image capture device 120 may be provided on other parts of the HMD 102 .
- the image capture device 120 may be configured to capture images at various resolutions or at different frame rates. Many image capture devices with a small form-factor, such as the cameras used in mobile phones or webcams, for example, may be incorporated into an example of the HMD 102 .
- FIG. 1A illustrates one image capture device 120
- more image capture device may be used, and each may be configured to capture the same view, or to capture different views.
- the image capture device 120 may be forward facing to capture at least a portion of the real-world view perceived by the user. This forward facing image captured by the image capture device 120 may then be used to generate an augmented reality where computer generated images appear to interact with or overlay the real-world view perceived by the user.
- the sensor 122 is shown on the extending side-arm 116 of the HMD 102 ; however, the sensor 122 may be positioned on other parts of the HMD 102 .
- the HMD 102 may include multiple sensors.
- an HMD 102 may include sensors 102 such as one or more gyroscopes, one or more accelerometers, one or more magnetometers, one or more light sensors, one or more infrared sensors, and/or one or more microphones.
- Other sensing devices may be included in addition or in the alternative to the sensors that are specifically identified herein.
- the finger-operable touch pad 124 is shown on the extending side-arm 114 of the HMD 102 . However, the finger-operable touch pad 124 may be positioned on other parts of the HMD 102 . Also, more than one finger-operable touch pad may be present on the HMD 102 .
- the finger-operable touch pad 124 may be used by a user to input commands.
- the finger-operable touch pad 124 may sense at least one of a pressure, position and/or a movement of one or more fingers via capacitive sensing, resistance sensing, or a surface acoustic wave process, among other possibilities.
- the finger-operable touch pad 124 may be capable of sensing movement of one or more fingers simultaneously, in addition to sensing movement in a direction parallel or planar to the pad surface, in a direction normal to the pad surface, or both, and may also be capable of sensing a level of pressure applied to the touch pad surface.
- the finger-operable touch pad 124 may be formed of one or more translucent or transparent insulating layers and one or more translucent or transparent conducting layers. Edges of the finger-operable touch pad 124 may be formed to have a raised, indented, or roughened surface, so as to provide tactile feedback to a user when the user's finger reaches the edge, or other area, of the finger-operable touch pad 124 . If more than one finger-operable touch pad is present, each finger-operable touch pad may be operated independently, and may provide a different function.
- HMD 102 may be configured to receive user input in various ways, in addition or in the alternative to user input received via finger-operable touch pad 124 .
- on-board computing system 118 may implement a speech-to-text process and utilize a syntax that maps certain spoken commands to certain actions.
- HMD 102 may include one or more microphones via which a wearer's speech may be captured. Configured as such, HMD 102 may be operable to detect spoken commands and carry out various computing functions that correspond to the spoken commands.
- HMD 102 may interpret certain head-movements as user input. For example, when HMD 102 is worn, HMD 102 may use one or more gyroscopes and/or one or more accelerometers to detect head movement. The HMD 102 may then interpret certain head-movements as being user input, such as nodding, or looking up, down, left, or right. An HMD 102 could also pan or scroll through graphics in a display according to movement. Other types of actions may also be mapped to head movement.
- HMD 102 may interpret certain gestures (e.g., by a wearer's hand or hands) as user input. For example, HMD 102 may capture hand movements by analyzing image data from image capture device 120 , and initiate actions that are defined as corresponding to certain hand movements.
- certain gestures e.g., by a wearer's hand or hands
- HMD 102 may capture hand movements by analyzing image data from image capture device 120 , and initiate actions that are defined as corresponding to certain hand movements.
- HMD 102 may interpret eye movement as user input.
- HMD 102 may include one or more inward-facing image capture devices and/or one or more other inward-facing sensors (not shown) that may be used to track eye movements and/or determine the direction of a wearer's gaze.
- certain eye movements may be mapped to certain actions.
- certain actions may be defined as corresponding to movement of the eye in a certain direction, a blink, and/or a wink, among other possibilities.
- HMD 102 also includes a speaker 125 for generating audio output.
- the speaker could be in the form of a bone conduction speaker, also referred to as a bone conduction transducer (BCT).
- Speaker 125 may be, for example, a vibration transducer or an electroacoustic transducer that produces sound in response to an electrical audio signal input.
- the frame of HMD 102 may be designed such that when a user wears HMD 102 , the speaker 125 contacts the wearer.
- speaker 125 may be embedded within the frame of HMD 102 and positioned such that, when the HMD 102 is worn, speaker 125 vibrates a portion of the frame that contacts the wearer.
- HMD 102 may be configured to send an audio signal to speaker 125 , so that vibration of the speaker may be directly or indirectly transferred to the bone structure of the wearer.
- the wearer can interpret the vibrations provided by BCT 125 as sounds.
- bone-conduction transducers may be implemented, depending upon the particular implementation.
- any component that is arranged to vibrate the HMD 102 may be incorporated as a vibration transducer.
- an HMD 102 may include a single speaker 125 or multiple speakers.
- the location(s) of speaker(s) on the HMD may vary, depending upon the implementation. For example, a speaker may be located proximate to a wearer's temple (as shown), behind the wearer's ear, proximate to the wearer's nose, and/or at any other location where the speaker 125 can vibrate the wearer's bone structure.
- FIG. 1B illustrates an alternate view of the wearable computing device illustrated in FIG. 1A .
- the lens elements 110 , 112 may act as display elements.
- the HMD 102 may include a first projector 128 coupled to an inside surface of the extending side-arm 116 and configured to project a display 130 onto an inside surface of the lens element 112 .
- a second projector 132 may be coupled to an inside surface of the extending side-arm 114 and configured to project a display 134 onto an inside surface of the lens element 110 .
- the lens elements 110 , 112 may act as a combiner in a light projection system and may include a coating that reflects the light projected onto them from the projectors 128 , 132 . In some embodiments, a reflective coating may not be used (e.g., when the projectors 128 , 132 are scanning laser devices).
- the lens elements 110 , 112 themselves may include: a transparent or semi-transparent matrix display, such as an electroluminescent display or a liquid crystal display, one or more waveguides for delivering an image to the user's eyes, or other optical elements capable of delivering an in focus near-to-eye image to the user.
- a corresponding display driver may be disposed within the frame elements 104 , 106 for driving such a matrix display.
- a laser or LED source and scanning system could be used to draw a raster display directly onto the retina of one or more of the user's eyes. Other possibilities exist as well.
- FIG. 1C illustrates another wearable computing system according to an example embodiment, which takes the form of an HMD 152 .
- the HMD 152 may include frame elements and side-arms such as those described with respect to FIGS. 1A and 1B .
- the HMD 152 may additionally include an on-board computing system 154 and an image capture device 156 , such as those described with respect to FIGS. 1A and 1B .
- the image capture device 156 is shown mounted on a frame of the HMD 152 . However, the image capture device 156 may be mounted at other positions as well.
- the HMD 152 may include a single display 158 which may be coupled to the device.
- the display 158 may be formed on one of the lens elements of the HMD 152 , such as a lens element described with respect to FIGS. 1A and 1B , and may be configured to overlay computer-generated graphics in the user's view of the physical world.
- the display 158 is shown to be provided in a center of a lens of the HMD 152 , however, the display 158 may be provided in other positions, such as for example towards either the upper or lower portions of the wearer's field of view.
- the display 158 is controllable via the computing system 154 that is coupled to the display 158 via an optical waveguide 160 .
- FIG. 1D illustrates another wearable computing system according to an example embodiment, which takes the form of a monocular HMD 172 .
- the HMD 172 may include side-arms 173 , a center frame support 174 , and a bridge portion with nosepiece 175 . In the example shown in FIG. 1D , the center frame support 174 connects the side-arms 173 .
- the HMD 172 does not include lens-frames containing lens elements.
- the HMD 172 may additionally include a component housing 176 , which may include an on-board computing system (not shown), an image capture device 178 , and a button 179 for operating the image capture device 178 (and/or usable for other purposes).
- Component housing 176 may also include other electrical components and/or may be electrically connected to electrical components at other locations within or on the HMD.
- HMD 172 also includes a BCT 186 .
- the HMD 172 may include a single display 180 , which may be coupled to one of the side-arms 173 via the component housing 176 .
- the display 180 may be a see-through display, which is made of glass and/or another transparent or translucent material, such that the wearer can see their environment through the display 180 .
- the component housing 176 may include the light sources (not shown) for the display 180 and/or optical elements (not shown) to direct light from the light sources to the display 180 .
- display 180 may include optical features that direct light that is generated by such light sources towards the wearer's eye, when HMD 172 is being worn.
- HMD 172 may include a sliding feature 184 , which may be used to adjust the length of the side-arms 173 .
- sliding feature 184 may be used to adjust the fit of HMD 172 .
- an HMD may include other features that allow a wearer to adjust the fit of the HMD, without departing from the scope of the invention.
- FIGS. 1E to 1G are simplified illustrations of the HMD 172 shown in FIG. 1D , being worn by a wearer 190 .
- BCT 186 is arranged such that when HMD 172 is worn, BCT 186 is located behind the wearer's ear. As such, BCT 186 is not visible from the perspective shown in FIG. 1E .
- the display 180 may be arranged such that when HMD 172 is worn, display 180 is positioned in front of or proximate to a user's eye when the HMD 172 is worn by a user.
- display 180 may be positioned below the center frame support and above the center of the wearer's eye, as shown in FIG. 1E .
- display 180 may be offset from the center of the wearer's eye (e.g., so that the center of display 180 is positioned to the right and above of the center of the wearer's eye, from the wearer's perspective).
- display 180 may be located in the periphery of the field of view of the wearer 190 , when HMD 172 is worn.
- FIG. 1F when the wearer 190 looks forward, the wearer 190 may see the display 180 with their peripheral vision.
- display 180 may be outside the central portion of the wearer's field of view when their eye is facing forward, as it commonly is for many day-to-day activities. Such positioning can facilitate unobstructed eye-to-eye conversations with others, as well as generally providing unobstructed viewing and perception of the world within the central portion of the wearer's field of view.
- the wearer 190 may view the display 180 by, e.g., looking up with their eyes only (possibly without moving their head). This is illustrated as shown in FIG. 1G , where the wearer has moved their eyes to look up and align their line of sight with display 180 . A wearer might also use the display by tilting their head down and aligning their eye with the display 180 .
- FIG. 2A is a simplified block diagram of a computing device 210 according to an example embodiment.
- device 210 communicates using a communication link 230 (e.g., a wired or wireless connection) to a remote device 240 .
- the device 210 may be any type of device that can receive data and display information corresponding to or associated with the data.
- the device 210 may be a heads-up display system, such as the head-mounted devices (HMDs) 102 , 152 , 172 , or 252 described with reference to FIGS. 1A-1G and 2B .
- HMDs head-mounted devices
- the device 210 may include a display system 212 comprising a processor 214 and a display 216 .
- the display 210 may be, for example, an optical see-through display, an optical see-around display, or a video see-through display.
- the processor 214 may receive data from the remote device 240 , and configure the data for display on the display 216 .
- the processor 214 may be any type of processor, such as a micro-processor or a digital signal processor, for example.
- the device 210 may further include on-board data storage, such as memory 218 coupled to the processor 214 .
- the memory 218 may store software that can be accessed and executed by the processor 214 , for example.
- the remote device 240 may be any type of computing device or transmitter including a laptop computer, a mobile telephone, or tablet computing device, etc., that is configured to transmit data to the device 210 .
- the remote device 240 and the device 210 may contain hardware to enable the communication link 230 , such as processors, transmitters, receivers, antennas, etc.
- remote device 240 may take the form of or be implemented in a computing system that is in communication with and configured to perform functions on behalf of client device, such as computing device 210 .
- client device such as computing device 210 .
- Such a remote device 240 may receive data from another computing device 210 (e.g., an HMD 102 , 152 , or 172 or a mobile phone), perform certain processing functions on behalf of the device 210 , and then send the resulting data back to device 210 .
- This functionality may be referred to as “cloud” computing.
- the communication link 230 is illustrated as a wireless connection; however, wired connections may also be used.
- the communication link 230 may be a wired serial bus such as a universal serial bus or a parallel bus.
- a wired connection may be a proprietary connection as well.
- the communication link 230 may also be a wireless connection using, e.g., Bluetooth® radio technology, communication protocols described in IEEE 802.11 (including any IEEE 802.11 revisions), Cellular technology (such as GSM, CDMA, UMTS, EV-DO, WiMAX, or LTE), or Zigbee® technology, among other possibilities.
- the remote device 240 may be accessible via the Internet and may include a computing cluster associated with a particular web service (e.g., social-networking, photo sharing, address book, etc.).
- FIG. 2B shows an example projection of UI elements described herein via an image 280 by an example head-mountable device (HMD) 252 , according to an example embodiment.
- HMD head-mountable device
- Other configurations of an HMD may be also be used to present the UI described herein via image 280 .
- FIG. 2B shows wearer 254 of HMD 252 looking at an eye of person 256 . As such, wearer 254 's gaze, or direction of viewing, is along gaze vector 260 .
- a horizontal plane, such as horizontal gaze plane 264 can then be used to divide space into three portions: space above horizontal gaze plane 264 , space in horizontal gaze plane 264 , and space below horizontal gaze plane 264 .
- horizontal gaze plane 260 appears as a line that divides projection plane into a subplane above the line of horizontal gaze plane 260 , a subplane a subspace below the line of horizontal gaze plane 260 , and the line where horizontal gaze plane 260 intersects projection plane 276 .
- horizontal gaze plane 264 is shown using dotted lines.
- a dividing plane indicated using dividing line 274 can be drawn to separate space into three other portions: space to the left of the dividing plane, space on the dividing plane, and space to right of the dividing plane.
- the dividing plane intersects projection plane 276 at dividing line 274 .
- the dividing plane divides projection plane into: a subplane to the left of dividing line 274 , a subplane to the right of dividing line 274 , and dividing line 274 .
- dividing line 274 is shown as a solid line.
- FIG. 2B shows the upper visual plane 270 as the uppermost plane that wearer 254 can see while gazing along gaze vector 260 , and shows lower visual plane 272 as the lowermost plane that wearer 254 can see while gazing along gaze vector 260 .
- upper visual plane 270 and lower visual plane 272 are shown using dashed lines.
- the HMD can project an image for view by wearer 254 at some apparent distance 262 along display line 282 , which is shown as a dotted and dashed line in FIG. 2B .
- apparent distance 262 can be 1 meter, four feet, infinity, or some other distance.
- HMD 252 can generate a display, such as image 280 , which appears to be at the apparent distance 262 from the eye of wearer 254 and in projection plane 276 .
- image 280 is shown between horizontal gaze plane 264 and upper visual plane 270 ; that is image 280 is projected above gaze vector 260 .
- image 280 is also projected to the right of dividing line 274 .
- wearer 254 can look at person 256 without image 280 obscuring their general view.
- the display element of the HMD 252 is translucent when not active (i.e. when image 280 is not being displayed), and so the wearer 254 can perceive objects in the real world along the vector of display line 282 .
- image 280 can be projected above horizontal gaze plane 264 near and/or just above upper visual plane 270 to keep image 280 from obscuring most of wearer 254 ′s view. Then, when wearer 254 wants to view image 280 , wearer 254 can move their eyes such that their gaze is directly toward image 280 .
- the display 216 of device 210 may be available as part of a user interface for an HMD, such as one of example HMDs 102 , 152 , 172 , and 252 , as discussed above in more detail in the context of at least FIG. 2A .
- the display 216 of device 210 can be used to display portions of a VNUI (voice-navigable user interface) 220 , which can include display 216 , input device(s) 222 , such as microphone(s), to receive speech input, and output device(s) 224 such as the display, speaker(s), and/or BCT(s) for audio and/or video output.
- a user or wearer of an HMD may utter words or phrases displayed on a voice navigable menu to interact with the VNUI 220 .
- FIGS. 3A and 3B show an example voice navigable menu 300 , which VNUI 220 can present on the display 216 .
- the voice navigable menu 300 can include one or more categories 301 ; e.g., “Category 1 ,” “Category 2 ,” “Category 3 ,” and “Category 4 ” as shown in FIG. 3A .
- a “category,” for example is a menu item that can describe or can be associated with one or more sub-items. For instance, a restaurant menu category “Breakfast” may describe a number of restaurant menu items for breakfast, such as eggs, toast, oatmeal, bacon, etc.
- the voice navigable menu 300 can include menu items, such as categories 301 and commands 302 in FIGS. 3A and 3B .
- the menu items may be organized into “top-level” menu items and “sub-level” menu items.
- a top-level menu item is, generally, a menu item with which other menu items are associated.
- a top-level menu item is a menu item that can be expanded to reveal lower level menu items, such as sub-level menu items.
- a sub-level menu item is, generally, a menu item that is associated with another menu item, such as a top-level menu item.
- the voice navigable menu 300 can have a parent-child hierarchy, in which top-level menu items correspond to a parent menu item and sub-level menu items correspond to a child menu item. In some cases, top-level menu items are displayed on one physical level of the menu, such as a root or base level, while sub-level menu items are displayed on a second physical level of the menu. In some embodiments, the voice navigable menu 300 displays top-level menu items as the left-most items in a display.
- the categories 301 comprise top-level menu items, as shown in FIGS. 3A and 3B .
- Each category can include or be associated with one or more commands 302 , and each command 302 can be associated with one or more of the categories 301 .
- the commands 302 can be sub-level menu items, as shown in FIG. 3B . As shown in FIG. 3B , the commands 302 —sub-level menu items—can be displayed further to the right (or further indented) as compared to the top-level menu items.
- the categories 301 and commands 302 can be some or all of the menu items in the voice navigable menu 300 .
- other menu items can include identifications of files. Other examples are possible as well.
- Some or all of the menu items of the voice navigable menu 300 can be displayed to a wearer on the display 216 .
- an HMD may interpret certain head-movements as being wearer input, such as nodding, or looking up, down, left, or right.
- VNUI 220 may, in turn, interpret such movements as wearer input directing the voice navigable menu 300 to scroll, such that menu items previously not visible on display 216 become visible.
- displayed menu items can also serve as cues to a wearer, by providing the wearer with a word or phrase that the wearer can utter to navigate the menu or invoke a command.
- Such utterances by wearer(s) can include the categories 301 and the commands 302 .
- VNUI 220 may display, on the display 216 , the command or commands 302 associated with the uttered category.
- VNUI 220 may invoke the uttered command.
- FIG. 4 shows an example display 216 .
- the example display 216 can include a visible menu 305 .
- the visible menu 305 can include all or a part of the voice navigable menu 300 .
- all of voice navigable menu 300 can be visible on the display 216 as visible menu 305 .
- only a portion of the voice navigable menu 300 may be visible on the display 216 as the visible menu 305 .
- space limitations on the display 216 and/or the length of the voice navigable menu 300 can limit visible menu 305 to displaying only a portion of voice navigable menu 300 .
- the visible menu 305 can include one or more menu items.
- the visible menu 305 can display menu items from the voice navigable menu 300 in a modified or rearranged order.
- the visible menu can display sub-level menu items above and/or as top-level menu items.
- the visible menu 305 of FIG. 4 depicts, in this example, three example categories displayed as top-level menu items: Camera 310 , Communication 320 , and Information Retrieval 330 . Other categories are possible as well.
- the visible menu 305 may include other menu items, such as commands, for example.
- a wearer can interact with the VNUI 220 by uttering a menu item, such as an identification of a category.
- a wearer may utter a phrase such as “ok glass, open camera” to address the HMD by saying “ok glass” and then requesting the HMD access a camera by saying “open camera.”
- VNUI 220 may then display in the visible menu 305 the available commands associated with the uttered category.
- example commands associated with the Camera category 310 may include “take a photo” 410 and “record a video” 420 .
- Other commands are possible as well.
- VNUI 220 can show the commands associated with the category as sub-level menu items in-line with the top-level menu items, as shown in FIG. 5 .
- FIG. 5 shows the “take a photo” 410 and “record a video” 420 sub-level commands in-line with the Camera 310 and Communication 320 top-level categories in the visible menu 305 .
- the VNUI associates a set of commands with a category by showing the commands below the associated category and slightly indented.
- the visible menu 305 also includes another category, Communication 320 , which is not associated with the displayed commands and which is displayed below the commands.
- VNUI 220 when a wearer opens a category, VNUI 220 can show the commands as a stand-alone submenu on the display 216 , as shown in FIG. 6 .
- the visible menu 305 includes commands associated with a particular category, but no categories or other menu items.
- Minimizing the number of menu items in the visible menu 305 can increase focus on commands likely to be invoked and so allow more efficient invocation of those commands.
- the two commands “take a photo” 410 and “record a video” 420 presented in the visible menu 305 of FIG. 6 may be the two commands a wearer is most likely to want to invoke (based on, for example, the wearer uttering an identification of the Camera 310 category).
- VNUI 220 may make navigating the menu more efficient. For example, a minimal or reduced number of menu items may keep a wearer from reading or mentally processing additional and potentially unneeded menu items.
- VNUI 220 can highlight or more prominently display certain menu items. To do so, VNUI 220 can, for example, display the menu item at the top of the visible menu 305 . In other embodiments, VNUI 220 can emphasize the menu item compared to one or more other menu items, without necessarily displaying the menu item at the top of the visible menu 305 .
- VNUI 220 can “bubble-up” the command to the top of the visible menu 305 or to a position above another command or a category.
- VNUI 220 can present, for example, a most recently used and/or a most frequently used command above other menu items. In some cases, VNUI 220 can present the command at or near the top of the visible menu 305 .
- FIG. 7 shows an example menu in which the visible menu 305 includes the command “take a photo” 410 above the categories Camera 310 , Communication 320 , and Information retrieval 330 .
- VNUI 220 has bubbled-up the command “take a photo” 410 to a position above the displayed categories.
- FIG. 8A shows an example menu in which the visible menu 305 includes the commands “take a photo” 410 and “send a message” 430 above the categories Camera 310 and Communication 320 .
- VNUI 220 has bubbled-up the commands “take a photo” 410 and “send a message” 430 to a position above the displayed categories.
- the visible menu 305 can include both available categories and commands.
- the visible menu can display both available categories and commands as top-level menu items, as in FIGS. 7 and 8A .
- VNUI 220 can present the one or more menu items in a manner that attempts to predict a wearer's intent when using the VNUI.
- the VNUI can determine a command likely to be used, and the VNUI can display the command to appear more prominently than other menu items.
- VNUI 220 can use any number of various criteria to determine which command or commands a wearer is likely to invoke. As one example, the VNUI can determine a command likely to be used based on how frequently commands are used by the wearer. In particular, the VNUI may bubble up the command or commands used most frequently by a wearer, such that a more frequently invoked command appears at the top of the menu.
- the VNUI can determine a command likely to be used based on how recently a wearer has used the command.
- the VNUI may bubble up the command or commands used most recently by a wearer, such that a more recently invoked command appears at the top of the menu.
- VNUI 220 can bubble up the commands based on some combination of criteria. For instance, the VNUI can bubble up commands based on a first criteria of how recently a wearer has used the command, and then, for those commands with similar frequencies of use, based on a second criteria of how recently a wearer has used the command or commands.
- VNUI 220 may have determined that a wearer is more likely to use the “take a photo” 410 command than other menu items. Accordingly, the VNUI can, in this example, display the “take a photo” 410 command above the other menu items in the visible menu 305 .
- VNUI 220 may have determined that a wearer is more likely to use the “take a photo” 410 and “send a message” 430 commands than other menu items (such as other commands). Accordingly, VNUI 220 can, in this example, display the “take a photo” 410 and “send a message” 430 commands above the other menu items in the visible menu 305 .
- VNUI 220 may also have determined that a wearer is more likely to use the “take a photo” 410 command than the “send a message” 430 command. Accordingly, the VNUI can, in this example, display the command “take a photo” 410 above the command “send a message” 430 in the visible menu 305 .
- commands or menu items bubble up
- other commands or menu items can “bubble down.”
- commands that have previously been bubbled up can be displaced by newly bubbled up commands.
- a displaced command can be displayed below a newly bubbled up command.
- the displaced command can be displayed only once a wearer utters the name of a category with which the displaced command is associated. Other examples are possible as well.
- bubbling up commands the VNUI also encourages a wearer to speak the command directly from the top-level menu. If a wearer sees the command in a visible menu with top-level menu items, the wearer should not need to navigate to a submenu to view commands associated with a category before invoking the command. Accordingly, bubbling up commands may make the VNUI more efficient for a wearer.
- a wearer can directly invoke a command that has been bubbled up to the top-level menu.
- FIG. 7 shows the command “take a photo” 410 bubbled up in the visible menu 305 .
- a wearer can directly invoke this command via VNUI 220 by uttering a sequence such as “ok glass, take a photo,” instead of having to navigate to the command by uttering the sequence “ok glass, open camera, take a photo.”
- wearers of some embodiments can invoke a command directly from the top-level menu—without needing to navigate to a category.
- Some embodiments of the VNUI can incorporate a “hotword” approach to voice recognition. Each command can be treated as a hotword, and the VNUI can recognize and carry out the command, even if the command is not displayed on the visible menu 305 .
- VNUI 220 may include the command “record a video,” which VNUI 220 may not display in the visible menu 305 .
- a wearer can also directly invoke this command via VNUI 220 by uttering a sequence such as “ok glass, record a video,” instead of having to navigate to the command by uttering a sequence such as “ok glass, open camera, record a video.” Accordingly, the system allows a wearer to utter a command directly, without the command being visible on the menu.
- the system also allows for a wearer to be able to invoke commands from one category while viewing commands from another category.
- the visible menus 305 of FIG. 5 and FIG. 6 display commands in the category “Camera” 310 .
- a wearer can also directly invoke, via VNUI 220 , a command from another category, such as the command “send a message” 430 from the category Communication 320 .
- a wearer can utter a sequence such as “ok glass, send a message” to directly invoke the “send a message” command, even if that command is not displayed on the visible menu 305 .
- a wearer may also use VNUI 220 to navigate to a category that is not in the visible display.
- the visible menu 305 of FIG. 5 shows the category Camera 310 and the category Communication 320 , but not the category Information Retrieval 330 (as shown in FIG. 4 ).
- a wearer can utter a sequence such as “ok glass, open information retrieval” to view available commands in that category.
- Associating commands with categories, bubbling up the command(s) most likely to be used, and allowing commands to be invoked from anywhere within the available menu can help the scalability of voice navigable menus.
- Such a system can allow for more voice commands to be added with minimal impact on the ability of the VNUI and visible display to efficiently guide a wearer through the menu.
- the menu items in the visible menu 305 can act as cues for a wearer of the voice navigable menu 300 .
- the items in the visible menu 305 can tell a wearer what to say to invoke a command or to navigate the menu. For example, by speaking a command, a wearer can invoke the command. And by speaking a category, a wearer can navigate to the available commands in that category.
- the ability to efficiently guide a wearer through the voice navigable menu may be an especially important consideration for new or infrequent wearers. Likewise, even experienced wearers may be unfamiliar with available menu items such as commands or categories (such as, for example, if commands or categories are added to the voice navigable menu).
- associating commands with categories can reduce the number of items displayed in, for example, a top-level menu. For instance, multiple commands can be associated with each category, and commands may be added to each category as the system develops. The number of categories will likely be less than the number of commands.
- a menu that displays some or all available categories may have fewer menu items than a menu that displays, for example, all available commands.
- a menu with fewer menu items may be easier to navigate, especially on a smaller display of an HMD.
- an HMD may have a smaller display than other mobile computing devices.
- an HMD may have a significantly smaller display than other computing devices. Accordingly, the display 216 and visible menu 305 of an HMD may also be smaller or significantly smaller than other computer devices.
- the voice navigable menu 300 Because of the smaller display 216 , fewer menu items may be able to be presented to a wearer on the visible menu 305 . Accordingly, the fewer menu items in the voice navigable menu 300 , the better chance that the visible menu 305 can include the entire voice navigable menu. Alternatively, if the visible menu 305 only includes a portion of the entire voice navigable menu 300 , minimizing the number of menu items in the voice navigable menu 300 should help increase the amount of the voice navigable menu 300 included in the visible menu 305 .
- a wearer's efficiency in navigating a voice navigable menu should increase with a wearer's ability to see more of the voice navigable menu in the display 216 .
- the time spent by a wearer navigating the voice navigable menu should be less if the visible menu 305 includes more of the available categories and commands.
- Bubbling up the command or commands most likely to be used can also help a wearer efficiently navigate a voice navigable menu.
- the bubbled up commands may be the commands a wearer is most likely to want to invoke.
- a wearer may be able to more quickly recall or invoke a command if the command is visually presented to the wearer—or visually presented to the wearer in a prominent way, such as at the top of a visible menu.
- a wearer seeking a particular command may avoid having to navigate to that command. Instead, if that command is displayed in the top-level menu (at the top or in some other, prominent way), a wearer can immediately receive the visual cue for the command without having to navigate to the category.
- allowing commands to be invoked from anywhere within the available menu can also reduce the need for a wearer to navigate to a particular category (or top-level visible menu) before invoking the command.
- Some embodiments also allow for the addition of applications or features, in some cases from third-parties.
- the added applications can result in added commands.
- the added commands can be associated with an added command menu item, which can comprise an added command category in the voice navigable menu.
- an added command can be distinguished from an original command.
- An original command can refer to a command that may have been originally provided in or, in some cases, previously added to a voice navigable menu.
- an added command menu item can be distinguished from an original menu item.
- An original menu item can refer to a menu item, such as a category, that may have been originally provided in or, in some cases, previously added to a voice navigable menu.
- the added applications can be treated collectively as a category in the voice-navigable menu (such as a “Glass Apps” category or an “Added Command” category, for example).
- a third-party application or one or more added commands may be treated as its own category (such as a “Facebook” category, for example).
- a category for added applications can be Glass Apps 340 , and commands within that category may be, for example, (i) “post a tweet” 440 and (ii) “call an Uber car” 450 —commands associated with two different third-party features.
- added commands can be invoked via VNUI 220 by uttering a sequence such as “ok glass, open Glass Apps, post a tweet.”
- added commands such as “post a tweet” 440 and “call an Uber car” 450 can be bubbled up in the top-level menu.
- added commands can be directly invoked via VNUI 220 by uttering a sequence such as “ok glass, post a tweet,” instead of having to navigate to the added command by uttering the sequence “ok glass, open Glass Apps, post a tweet.”
- a menu item for an added command can be the command itself, instead of an ambiguous menu item that merely opens an app or leads to further menu items.
- a menu item such as the command “post a tweet” provides more guidance to a wearer than a menu item such as “open Twitter.”
- a wearer may choose which additional or third-party applications or features to install or enable in a set-up portal for the HMD device.
- the set up portal may be part of the HMD or the VNUI 220 itself, or it may be accessed through interfaces of other devices (such as an Internet browser on a computing device). Additional or third-party applications may also be added to the VNUI automatically by a computing device executing suitable software.
- uttered commands e.g., “post a tweet”
- set-up flow uses the English imperative verb form
- each verb form is orthographically/lexicographically identical in English.
- a wearer can use the same verb form of “post a tweet” both during a set-up sequence (“I'd like to use Glass to post a tweet”) and when invoking the command (“ok glass, post a tweet”).
- FIGS. 9A-9C depict an example set-up sequence that can be presented on the display 216 of VNUI 220 .
- FIG. 9A shows a menu item Add Glass Apps 332 in the visible menu 305 .
- Add Glass Apps 332 menu item a wearer can utter “ok glass, add glass apps.”
- VNUI 220 may then present to the wearer the visible menu 305 of FIG. 9B , which displays two available commands for selection: enable “post a tweet” 334 and enable “call an Uber car” 336 . To enable one of the available commands, a wearer can utter “ok glass, enable ‘post a tweet.’”
- VNUI 220 may then present to the wearer the visible menu 305 of FIG. 9C , which displays the “post a tweet” 440 command as a menu item.
- the “post a tweet” command may also be added or associated with a category of added commands, such as the Glass Apps 340 category of FIG. 8B .
- Added commands may be merged into an existing library of voice commands. Because of the potentially large number of added or third-party commands, potential added commands can be selected and approved to maintain distinctiveness from other commands. One consideration may be selecting potential added commands that are long enough to provide phonetic distinctiveness from other commands (for example, “post a tweet” instead of “tweet”).
- a computer executing suitable software can determine a phonetic distance between a potential added command set and existing commands, perhaps in an existing command set. If the smallest phonetic distance between commands in the potential added command set and an existing command set is greater than a threshold, the computer can determine that the potential added command set may be acceptable for addition in the command set. If the smallest phonetic distance is less than the threshold, however, then the computer can determine that the potential added command set may not be distinguishable from the existing command set by the speech recognition system. In some embodiments, the computer can identify command(s) in the potential added command set whose phonetic distance is within the threshold, and suggest those commands be modified or rejected for inclusion of the potential added command set into the existing command set.
- the VNUI can be periodically updated with added commands as needed.
- an HMD or other computing device may be able to give voice commands to the device. These commands may be accessible on voice-navigable menus as part of a VNUI, for example. Certain voice commands may require fulfillment by a third party service provider. For instance, an HMD user may give a command to buy a dozen roses, order a pizza, buy a particular widget, request a plumber, request emergency assistance, and so on.
- FIG. 10 is a flow chart illustrating a method 1000 , according to an example embodiment.
- method 1000 is described by way of example as being carried out by a wearable computer and possibly a wearable computer that includes a head-mounted display (HMD).
- HMD head-mounted display
- example methods such as method 1000 , may be carried out by a wearable computer without wearing the computer.
- such methods may be carried out by simply holding the wearable computer using the wearer's hands.
- Other possibilities may also exist.
- example methods such as method 1000 may be carried out by devices other than a wearable computer, and/or may be carried out by sub-systems in a wearable computer or in other devices.
- an example method may alternatively be carried out by a device such as a mobile phone or laptop computer.
- Other examples are also possible.
- a remote server may help reduce the HMD's processing load.
- the HMD may send certain data about a service request to a remote, cloud-based server system, which may perform some or all of the necessary data processing (e.g., determining a selected service provider) in order to reduce the load on the HMD.
- the HMD may communicate with the server through a wireless connection, through a wired connection, or through a network of wireless and/or wired connections.
- the server may also communicate with third party service providers through a wired connection, or through a network of wireless and/or wired connections.
- method 1000 begins at block 1010 , where a computing device such as an HMD may receive a first utterance, which includes a first command.
- a computing device such as an HMD may receive a first utterance, which includes a first command.
- an utterance may be one or more words, one or more phrases, a sentence, or a series of sentences spoken by a user of an HMD.
- the HMD may process a user's speech and determine that a certain command has been issued by the user.
- the command may be selected by the user from a menu within a VNUI.
- a command could be any number of a wide variety of requests from the user to the device. A certain subset of those commands may require fulfillment by a third party service provider.
- FIG. 11A shows an example list of commands, according to an example embodiment. Each of the commands may be accessible to the user, for example by including the commands in one or menus of a VNUI. Each command (“order a pizza” 1110 , “call a plumber” 1120 , “buy a movie ticket” 1130 ) may require fulfillment by a third party service provider (e.g., a pizza restaurant, a plumber, a movie theater). It should be understood that these commands are meant only as examples. Any command to order a product or request a different type of service from a service provider may be used as well.
- the space of possible voice commands that require the assistance of a third party may be predetermined.
- the voice commands that can be recognized at block 1010 of the method 1000 may be taken from a predetermined set of voice commands that may include 500 commands or 5,000 commands or 50,000 commands, for example.
- the set of possible voice commands may be all of the commands that are included within menus of a VNUI, or that can be added to one of the menus as described above.
- the step of identifying a command from a voice utterance may be simplified. There may be less chance of error when the space of possible commands is limited because there may be fewer similar sounding commands. Additionally, there may also be less risk of ambiguity about the intent of an HMD user when the user issues a command. For example, if the user could issue any possible command such as “pizza,” the user's intent may not be easily identified. For instance, the user may wish to order a pizza, may wish to run a search engine search for pizza, may wish to find local pizza restaurants, may wish to find pizza recipes, and so on. In some examples, the user may be limited to giving only certain voice commands that are unlikely to create ambiguous intent. For instance, the user may be limited to using the command “order a pizza,” in order to unambiguously demonstrate an intent to purchase a pizza. Other possible constructions for defining the scope of possible voice commands exist as well.
- the HMD may select a service action corresponding to the first command.
- certain commands within the space of commands may require fulfillment by a third party service provider.
- a user may be communicating a specific intent to receive a certain selected service.
- a selected service may be identified.
- FIG. 11B shows an example command-service mapping, according to an example embodiment.
- Each voice command that may require fulfillment by a third party service provider may be mapped to a specific service action. For instance, “order a pizza” 1110 may be mapped to a pizza delivery service action 1150 , “call a plumber” 1120 may be mapped to a plumbing service action 1160 , “buy a movie ticket” 1130 may be mapped to a ticket selling service action 1170 , and so on.
- a service action may incorporate input from users and/or third parties that is needed to fulfill a service request. For instance, instead of just issuing a command to “order a pizza,” a user may be able to issue a command to “order a pepperoni pizza.” The type of pizza topping may then be included within the selected service action. Additionally, a user may be able to issue a command to “order a large, pepperoni pizza” so that the size of the pizza may also be included within the selected service action, and so on. In further examples, information needed to fulfill the service request may be included within the selected service action, such as billing information or the delivery address of the HMD user.
- the HMD can determine a selected service provider for the selected service action.
- the selected service provider may be selected from a number of different service providers that are each capable of fulfilling the requested service.
- FIG. 12A shows an example determination of a selected service provider, according to an example embodiment.
- multiple service providers may be capable of fulfilling the requested plumbing service 1210 .
- Each service provider may indicate in advance which services it is capable and willing to fulfill.
- a selected service provider may then be chosen to complete the selected service action from those service providers willing to fulfill the selected service.
- plumber # 2 1230 may be the selected service provider from among the available plumbers.
- determining the selected service provider may involve the use of an auction.
- Each service provider may indicate which services it would like to fulfill.
- Each service provider may then provide a bid for the right to fulfill the requested service.
- Limiting the set of possible service requests to a predetermined set where each service request corresponds to a voice command with a specific user intent may facilitate the bidding process because only a certain number of possible requests must be considered by the bidders.
- the service provider with the highest bid may then be chosen as the selected service provider to fulfill the requested service.
- the data processing for the auction may be carried out on the HMD's or remotely on a cloud-based server system.
- the auction may be carried out in real time.
- the service providers may each provide parameters that may be used to determine their bids when a certain service is requested.
- the service providers may first provide a bid price for each service it wishes to fulfill.
- the bid price may then be modified according to various parameters, such as the location of the HMD user or the time of day.
- the service providers may also input a budget that indicates the total amount they are willing to bid in a certain period of time.
- bids from a number of different providers may be determined, and a winning service provider may be determined based on the bids.
- bids from different service providers may be periodically refreshed using a timeout period.
- the auction results may be predetermined. For instance, a winning service provider may be pre-computed for each possible service request. Accordingly, when a service request is received, a selected service provider may immediately be determined without accessing the network. For instance, a cloud-based server system may pre-compute auction results and send those results to local HMD's. Then, when an HMD receives a service request, it may use the pre-computed auction results to determine the selected service provider.
- the auction results may be periodically updated, for instance, after receiving each service request or after receiving a certain number of service requests.
- a preference metric may be determined for each service provider.
- the preference metric may be based on the total number of service requests fulfilled by each of the service providers in a certain period time, the prices charged by each of the service providers, or the overall satisfaction of users making the requests from each of the service providers, for instance.
- the preference metric may also be preset by individual HMD users. A service provider with a higher preference metric may be chosen to fulfill a service over a service provider with a lower preference metric.
- the distance of the HMD from each of the service providers may also be factored into the determination of a selected service provider. For instance, a threshold distance could be set, and only selected service providers closer to the HMD than the threshold distance may be eligible to become the selected service provider. In another example, the distance of each service provider from the HMD may be factored into the determination of a preference metric. Other examples for determining a selected service provider exist as well.
- the HMD may send a service fulfillment request to the selected service provider to execute the selected service action.
- the service fulfillment request may contain enough information such that the third party service provider can fulfill the request.
- the request may include the requested service, the location of the HMD user, the mailing address of the intended recipient, price information, timeline for filling the request, and so on.
- FIG. 12B shows an example service request, according to an example embodiment.
- a selected service provider e.g., plumber # 2 1230
- a plumbing service request 1250 may be sent to the selected plumber.
- the request may include information about where the plumbing service is needed, by what day or time the service is needed, what time of day the plumber should come to provide the service, and so on.
- the HMD user may not see which service provider was selected to fulfill the user's service request. For example, the user may order the device to “purchase widget 18573.” A selected service provider may be determined by using an auction and/or one or more of the other methods described above. The widget may then be received at the user's door a few days later. Accordingly, the process may be streamlined to present a better overall user experience.
- FIG. 13 is a flow chart illustrating a method 1300 , according to an example embodiment.
- method 1300 is described by way of example as being carried out by a wearable computer and possibly a wearable computer that includes a head-mounted display (HMD).
- HMD head-mounted display
- example methods, such as method 1300 may be carried out by a wearable computer without wearing the computer. For example, such methods may be carried out by simply holding the wearable computer using the wearer's hands. Other possibilities may also exist.
- example methods such as method 1300 may be carried out by devices other than a wearable computer, and/or may be carried out by sub-systems in a wearable computer or in other devices.
- an example method may alternatively be carried out by a device such as a mobile phone or laptop computer.
- the method 1300 may be carried out by a remote server system as described above as well.
- method 1300 begins at block 1310 , where a computing device such as an HMD may receive a first utterance, which includes a first command.
- the first command may be a command that requires fulfillment by a third party service provider.
- Each command may be accessible to the user, for example by including the commands in one or menus of VNUI.
- the command may be selected from a predetermined space of possible voice commands that require the assistance of a third party.
- the HMD may select a service action associated with the first command.
- Each command may be associated with a specific service action that the HMD user is indicating a desire to have fulfilled.
- a framework, or mapping may be used to select a service action for a given voice command.
- the selected service action may incorporate information needed to complete the requested service.
- the HMD may determine one or more selected service providers for the selected service action.
- the selected service providers may be selected from a number of different service providers that are each capable of fulfilling the requested service.
- FIG. 14A shows an example determination of multiple selected service providers, according to an example embodiment.
- multiple service providers may each be capable of fulfilling the requested plumbing service action 1410 .
- Each service provider may indicate in advance which services it is capable and willing to fulfill.
- the selected service providers may then be chosen from those service providers willing to fulfill the selected service action.
- plumber # 1 1420 , plumber # 3 1440 , and plumber # 4 1450 may be the selected service providers from among the available plumbers. Three selected service providers are shown in this example, but any number could be used. Furthermore, a set number of selected service providers could always be chosen or the number of selected service providers could vary depending on various factors such as how many service providers in total are capable and willing to fulfill the requested service.
- determining the selected service providers may involve the use of an auction.
- Each service provider may indicate which services it would like to fulfill.
- Each service provider may then provide a bid for the right to fulfill the requested service.
- Limiting the set of possible service requests to a predetermined set where each service request corresponds to a voice command with a specific user intent may facilitate the bidding process because only a certain number of possible requests must be considered by the bidders.
- a certain number of service providers with the highest bids may then be chosen as the selected service providers.
- the data processing for the auction may be carried out on the HMD's or remotely on a cloud-based server system.
- the auction may be carried out in real time or the auction results may be predetermined. Additionally, other factors may be used in addition to or instead of an auction to determine the selected service providers as well. For example, a preference metric may be determined for each service provider, and may then be used to help determine the selected service providers. Additionally, the distance from the HMD to each of the service providers may also be factored into the determination of the selected service providers. Other factors may be used for determining the selected service providers as well.
- the HMD may display advertisements corresponding to the selected service action from the selected service providers. For instance, if three selected service providers were determined, then a user of the HMD may be presented with an advertisement from each of the three selected service providers to fulfill the service request.
- FIG. 14B shows an example display showing ads from multiple service providers, according to an example embodiment.
- the three selected service providers may each display an advertisement within a view 1470 of a display of the HMD.
- the ads may be created separately by each of the service providers and then transmitted to the HMD to display them.
- a uniform format may be used for each of the ads along with some identifying information from each of the service providers.
- service providers may be able to provide different advertisements depending on the requested service or on other factors. Other methods of presenting advertisements from the service providers to the user may be used as well.
- method 1400 may further involve the HMD receiving a selected advertisement from the one or more displayed advertisements, and sending a service fulfillment request to the service provider corresponding to the selected advertisement to execute the selected service action.
- the HMD user may select which service provider she would like to fulfill her service request by selecting one of the displayed advertisements using a voice command, a physical or virtual button, a head or eye movement, or a different type of user input.
- FIG. 14C shows an example service request to a selected service provider, according to an example embodiment.
- the HMD may have received a selection of the advertisement from plumber # 3 from the HMD user, as shown in 1470 .
- a plumbing service request 1480 may then be issued to plumber # 3 1440 .
- the request may include information about where the plumbing service is needed, by what day or time the service is needed, what time of day the plumber should come to provide the service, and so on.
- method 1400 may additionally include the HMD receiving one or more additional utterances on the computing device, where each of the one or more additional utterances includes the first command. Furthermore, the method 1400 may also include the HMD sending a service fulfillment request to the service provider corresponding to the selected advertisement to execute the selected service action for each of the one or more additional utterances.
- a user may only need to select an advertisement from the list of advertisements 1470 the first time the service is requested. Afterwards, when the user requests the same service again, a service request may automatically be sent to the same selected service provider that the user already chose in order to again service the request. The user experience may therefore be improved by not requiring the user to choose a service provider each time she issues the same service request.
- the user may select an advertisement from the list of advertisements 1470 when the first command is first added to a menu, or at some other time before the service is ever requested by the user. Accordingly, the user may be able to pre-program which service provider will handle one or more different service requests before issuing the requests. Then, when the user does issue a service request, a service fulfillment request may immediately be sent to the chosen service provider to handle the request. The user may therefore be able to request services from third parties without any wait time after initially configuring which service providers will handle the requests.
- each block and/or communication may represent a processing of information and/or a transmission of information in accordance with example embodiments.
- Alternative embodiments are included within the scope of these example embodiments.
- functions described as blocks, transmissions, communications, requests, responses, and/or messages may be executed out of order from that shown or discussed, including substantially concurrent or in reverse order, depending on the functionality involved.
- more or fewer blocks and/or functions may be used with any of the ladder diagrams, scenarios, and flow charts discussed herein, and these ladder diagrams, scenarios, and flow charts may be combined with one another, in part or in whole.
- a block that represents a processing of information may correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique.
- a block that represents a processing of information may correspond to a module, a segment, or a portion of program code (including related data).
- the program code may include one or more instructions executable by a processor for implementing specific logical functions or actions in the method or technique.
- the program code and/or related data may be stored on any type of computer readable medium such as a storage device including a disk or hard drive or other storage medium.
- the computer readable medium may also include non-transitory computer readable media such as computer-readable media that stores data for short periods of time like register memory, processor cache, and random access memory (RAM).
- the computer readable media may also include non-transitory computer readable media that stores program code and/or data for longer periods of time, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example.
- the computer readable media may also be any other volatile or non-volatile storage systems.
- a computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device.
- a block that represents one or more information transmissions may correspond to information transmissions between software and/or hardware modules in the same physical device. However, other information transmissions may be between software modules and/or hardware modules in different physical devices.
Abstract
Methods and systems are described herein related to enabling service providers to address voice-activated commands. An example method may involve: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action corresponding to the first command; determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and sending a service fulfillment request to the selected service provider to execute the selected service action.
Description
- The present application claims priority to U.S. patent application Ser. No. 13/950,503 filed on Jul. 25, 2013 and entitled “Model for Enabling Service Providers to Address Voice-Activated Commands,” which is herein incorporated by reference as if fully set forth in this description.
- Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
- Computing devices such as personal computers, laptop computers, tablet computers, cellular phones, and countless types of Internet-capable devices are increasingly prevalent in numerous aspects of modern life. Over time, the manner in which these devices are providing information to users is becoming more intelligent, more efficient, more intuitive, and/or less obtrusive.
- The trend toward miniaturization of computing hardware, peripherals, as well as of sensors, detectors, and image and audio processors, among other technologies, has helped open up a field sometimes referred to as “wearable computing.” In the area of image and visual processing and production, in particular, it has become possible to consider wearable displays that place a graphic display close enough to a wearer's (or user's) eye(s) such that the displayed image appears as a normal-sized image, such as might be displayed on a traditional image display device. The relevant technology may be referred to as “near-eye displays.”
- Wearable computing devices with near-eye displays may also be referred to as “head-mountable displays” (HMDs), “head-mounted displays,” “head-mounted devices,” or “head-mountable devices.” A head-mountable display places a graphic display or displays close to one or both eyes of a wearer. To generate the images on a display, a computer processing system may be used. Such displays may occupy a wearer's entire field of view, or only occupy part of wearer's field of view. Further, head-mounted displays may vary in size, taking a smaller form such as a glasses-style display or a larger form such as a helmet, for example.
- Emerging and anticipated uses of wearable displays include applications in which users interact in real time with an augmented or virtual reality. Such applications can be mission-critical or safety-critical, such as in a public safety or aviation setting. The applications can also be recreational, such as interactive gaming.
- Methods and systems are described herein related to enabling service providers to address voice-activated commands. An utterance may be received on a computing device, which may include a command. A service action associated with the command may then be selected. A selected service provider may then be determined for the selected service action, where the selected service provider is selected from a plurality of service providers. A service fulfillment request may then be sent to the selected service provider to execute the selected service action.
- In one aspect, a method is provided. The method may include: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and sending a service fulfillment request to the selected service provider to execute the selected service action.
- In another aspect, a method is provided that may include: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining one or more selected service providers for the selected service action, where the one or more selected service providers are selected from a plurality of service providers; and displaying on the computing device one or more advertisements corresponding to the selected service action from the one or more selected service providers.
- In yet another aspect, a non-transitory computer-readable medium is provided. The non-transitory computer readable medium is configured to store program instructions that, when executed by a processor, cause the processor to carry out functions comprising: receiving a first utterance on a computing device, where the first utterance includes a first command; selecting a service action that corresponds to the first command; determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and sending a service fulfillment request to the selected service provider to execute the selected service action.
- Further example embodiments may include: means for receiving a first utterance on a computing device, where the first utterance includes a first command; means for selecting a service action that corresponds to the first command; means for determining a selected service provider for the selected service action, where the selected service provider is selected from a plurality of service providers; and means for sending a service fulfillment request to the selected service provider to execute the selected service action.
- These as well as other aspects, advantages, and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it should be understood that this summary and other descriptions and figures provided herein are intended to illustrative embodiments by way of example only and, as such, that numerous variations are possible. For instance, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise changed, while remaining within the scope of the embodiments as claimed.
-
FIG. 1A illustrates a wearable computing system according to an example embodiment. -
FIG. 1B illustrates an alternate view of the wearable computing device illustrated inFIG. 1A . -
FIG. 1C illustrates another wearable computing system according to an example embodiment. -
FIG. 1D illustrates another wearable computing system according to an example embodiment. -
FIGS. 1E to 1G are simplified illustrations of the wearable computing system shown inFIG. 1D , being worn by a wearer. -
FIG. 2A is a simplified block diagram of a computing device according to an example embodiment. -
FIG. 2B shows a projection of an image by a head-mountable device, according to an example embodiment. -
FIG. 3A shows an example voice navigable menu, according to an example embodiment. -
FIG. 3B shows an example voice navigable menu, according to an example embodiment. -
FIG. 4 shows an example visible menu, according to an example embodiment. -
FIG. 5 shows an example visible menu, according to an example embodiment. -
FIG. 6 shows an example visible menu, according to an example embodiment. -
FIG. 7 shows an example visible menu, according to an example embodiment. -
FIG. 8A shows an example visible menu, according to an example embodiment. -
FIG. 8B shows an example visible menu, according to an example embodiment. -
FIG. 9A shows an example visible menu, according to an example embodiment. -
FIG. 9B shows an example visible menu, according to an example embodiment. -
FIG. 9C shows an example visible menu, according to an example embodiment. -
FIG. 10 is a flow chart illustrating a method, according to an example embodiment. -
FIG. 11A shows an example list of commands, according to an example embodiment. -
FIG. 11B shows an example command-service mapping, according to an example embodiment. -
FIG. 12A shows an example determination of a service provider, according to an example embodiment. -
FIG. 12B shows an example service request, according to an example embodiment. -
FIG. 13 is a flow chart illustrating another method, according to an example embodiment. -
FIG. 14A shows an example determination of multiple service providers, according to an example embodiment. -
FIG. 14B shows an example display showing ads from multiple service providers, according to an example embodiment. -
FIG. 14C shows an example service request to a selected service provider, according to an example embodiment. - Example methods and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.” Any embodiment or feature described herein as being an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features. In the following detailed description, reference is made to the accompanying figures, which form a part thereof. In the figures, similar symbols typically identify similar components, unless context dictates otherwise. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented herein.
- The example embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.
- A. Overview
- Head-mounted displays (“HMDs”) and other computing devices may use a voice-based user interface to capture audible input from the user of the HMD. Upon receiving audible input, the HMD may attempt to recognize the input as a speech command and process the command accordingly. The speech input can represent commands to the HMD, such as commands to search, navigate, take photos, record videos, etc. Some commands may require fulfillment by a third party service provider, such as “order a pizza,” “call a plumber,” or “buy a movie ticket.”
- Example systems may allow multiple service providers to address a given voice command. In some examples, a voice command may first be mapped to a selected service action. Then, a third party service provider may be selected from a number of different service providers in order to fulfill the requested service action. For example, if the user commands the device to “order a dozen roses,” a service provider may be automatically selected, and the order may be filled. In some examples, the process may be streamlined so that the user may not see which service provider is filling the order.
- In further examples, the selected service provider that will fulfill the service request may be chosen based at least in part on an auction. Multiple third party service providers may be given the opportunity to bid on the right to fulfill the service. The highest bidding third party service provider may be selected to fulfill the service request. Further, such an auction could take place prior to the service request or could take place in real time based on bidding criteria provided by the service providers.
- Other factors may also be used to determine the selected service provider as well. For example, the HMD user or a system manager may be able to specify that certain service providers are preferred. Additionally, the distance between the computing device and various service providers may be computed, and preference may be given to a closer third party service provider.
- In other examples, third party service providers may be able to buy the right to present advertisements related to specific voice commands. For example, if the user commands the device to “order a dozen roses,” the user may then be presented with advertisements to buy roses from several different sellers. A service request to provide the dozen roses may then be sent to the service provider whose advertisement is chosen by the user. In one example, the third party service providers that get to display their advertisements may be based at least in part on an auction in which the providers bid on the right to have their ad displayed. Other criteria such as user preference or location may be factored in as well.
- In some examples, the space of possible voice commands may be predetermined. The set of commands may be all of the commands accessible to the user by a voice-navigable user interface (VNUI). In additional examples, certain commands may be included within menus reachable by the VNUI by default and other commands may later be added to one of the menus by the user. By selecting commands from a predetermined set of possible commands, HMD users may be able to direct their specific intent to third party service providers without any ambiguity. Further, the third party service providers may only provide bids on the possible voice commands that are relevant to them within the predetermined universe.
- In one implementation, the selected service provider(s) for a certain voice command may be predetermined. For instance, if an auction is used to determine the selected service provider(s), the results of the auction may be pre-computed. In some examples, the HMD may recognize the voice command immediately without access to the network. The selected service provider(s) may then be pre-computed and pre-cached so that a third party service request may immediately be sent or the ads of selected service provider(s) may be immediately displayed to the user without network access. Further, the selected service provider(s) for a given command may later be refreshed after the command has issued.
- In an alternative example, the selected service provider(s) may be determined in real time after the voice command has been received. For example, if an auction will be used to determine the selected service provider(s), the third party service providers may be able to specify certain parameters beforehand that will be used to determine the winners of the auction. These parameters may include the provider's total budget for advertising, the bid price, and a timeout period, for example. In further examples, the parameters may also be made to depend on other factors, such as the location of the HMD user or the time of day.
- In an additional example, the HMD user may be able to preconfigure which third party service provider will handle a given command. When the user first executes a command or when the user adds the command to a menu within the VNUI, the user may be presented with a list of service providers. These service providers may be determined based on the results of an auction, based on preferences assigned by a system manager, and/or based on location, for example. The user may then choose a service provider from the list. Whenever the user issues the same voice command in the future, the same service provider may automatically be contacted. Accordingly, the user experience may be improved by not requiring the user to select a service provider multiple times for the same type of service request.
- B. Example Wearable Computing Devices
- Systems and devices in which example embodiments may be implemented will now be described in greater detail. In general, an example system may be implemented in or may take the form of a wearable computer (also referred to as a wearable computing device). In an example embodiment, a wearable computer takes the form of or includes a head-mountable device (HMD).
- An example system may also be implemented in or take the form of other devices, such as a mobile phone, among other possibilities. Further, an example system may take the form of non-transitory computer readable medium, which has program instructions stored thereon that are executable by at a processor to provide the functionality described herein. An example system may also take the form of a device such as a wearable computer or mobile phone, or a subsystem of such a device, which includes such a non-transitory computer readable medium having such program instructions stored thereon.
- An HMD may generally be any display device that is capable of being worn on the head and places a display in front of one or both eyes of the wearer. An HMD may take various forms such as a helmet or eyeglasses. As such, references to “eyeglasses” or a “glasses-style” HMD should be understood to refer to an HMD that has a glasses-like frame so that it can be worn on the head. Further, example embodiments may be implemented by or in association with an HMD with a single display or with two displays, which may be referred to as a “monocular” HMD or a “binocular” HMD, respectively.
-
FIG. 1A illustrates a wearable computing system according to an example embodiment. InFIG. 1A , the wearable computing system takes the form of a head-mountable device (HMD) 102 (which may also be referred to as a head-mounted display). It should be understood, however, that example systems and devices may take the form of or be implemented within or in association with other types of devices, without departing from the scope of the invention. As illustrated inFIG. 1A , theHMD 102 includes frame elements including lens-frames center frame support 108,lens elements arms center frame support 108 and the extending side-arms HMD 102 to a user's face via a user's nose and ears, respectively. - Each of the
frame elements arms HMD 102. Other materials may be possible as well. - One or more of each of the
lens elements lens elements - The extending side-
arms frames HMD 102 to the user. The extending side-arms HMD 102 to the user by extending around a rear portion of the user's head. Additionally or alternatively, for example, theHMD 102 may connect to or be affixed within a head-mounted helmet structure. Other configurations for an HMD are also possible. - The
HMD 102 may also include an on-board computing system 118, animage capture device 120, asensor 122, and a finger-operable touch pad 124. The on-board computing system 118 is shown to be positioned on the extending side-arm 114 of theHMD 102; however, the on-board computing system 118 may be provided on other parts of theHMD 102 or may be positioned remote from the HMD 102 (e.g., the on-board computing system 118 could be wire- or wirelessly-connected to the HMD 102). The on-board computing system 118 may include a processor and memory, for example. The on-board computing system 118 may be configured to receive and analyze data from theimage capture device 120 and the finger-operable touch pad 124 (and possibly from other sensory devices, user interfaces, or both) and generate images for output by thelens elements - The
image capture device 120 may be, for example, a camera that is configured to capture still images and/or to capture video. In the illustrated configuration,image capture device 120 is positioned on the extending side-arm 114 of theHMD 102; however, theimage capture device 120 may be provided on other parts of theHMD 102. Theimage capture device 120 may be configured to capture images at various resolutions or at different frame rates. Many image capture devices with a small form-factor, such as the cameras used in mobile phones or webcams, for example, may be incorporated into an example of theHMD 102. - Further, although
FIG. 1A illustrates oneimage capture device 120, more image capture device may be used, and each may be configured to capture the same view, or to capture different views. For example, theimage capture device 120 may be forward facing to capture at least a portion of the real-world view perceived by the user. This forward facing image captured by theimage capture device 120 may then be used to generate an augmented reality where computer generated images appear to interact with or overlay the real-world view perceived by the user. - The
sensor 122 is shown on the extending side-arm 116 of theHMD 102; however, thesensor 122 may be positioned on other parts of theHMD 102. For illustrative purposes, only onesensor 122 is shown. However, in an example embodiment, theHMD 102 may include multiple sensors. For example, anHMD 102 may includesensors 102 such as one or more gyroscopes, one or more accelerometers, one or more magnetometers, one or more light sensors, one or more infrared sensors, and/or one or more microphones. Other sensing devices may be included in addition or in the alternative to the sensors that are specifically identified herein. - The finger-
operable touch pad 124 is shown on the extending side-arm 114 of theHMD 102. However, the finger-operable touch pad 124 may be positioned on other parts of theHMD 102. Also, more than one finger-operable touch pad may be present on theHMD 102. The finger-operable touch pad 124 may be used by a user to input commands. The finger-operable touch pad 124 may sense at least one of a pressure, position and/or a movement of one or more fingers via capacitive sensing, resistance sensing, or a surface acoustic wave process, among other possibilities. The finger-operable touch pad 124 may be capable of sensing movement of one or more fingers simultaneously, in addition to sensing movement in a direction parallel or planar to the pad surface, in a direction normal to the pad surface, or both, and may also be capable of sensing a level of pressure applied to the touch pad surface. In some embodiments, the finger-operable touch pad 124 may be formed of one or more translucent or transparent insulating layers and one or more translucent or transparent conducting layers. Edges of the finger-operable touch pad 124 may be formed to have a raised, indented, or roughened surface, so as to provide tactile feedback to a user when the user's finger reaches the edge, or other area, of the finger-operable touch pad 124. If more than one finger-operable touch pad is present, each finger-operable touch pad may be operated independently, and may provide a different function. - In a further aspect,
HMD 102 may be configured to receive user input in various ways, in addition or in the alternative to user input received via finger-operable touch pad 124. For example, on-board computing system 118 may implement a speech-to-text process and utilize a syntax that maps certain spoken commands to certain actions. In addition,HMD 102 may include one or more microphones via which a wearer's speech may be captured. Configured as such,HMD 102 may be operable to detect spoken commands and carry out various computing functions that correspond to the spoken commands. - As another example,
HMD 102 may interpret certain head-movements as user input. For example, whenHMD 102 is worn,HMD 102 may use one or more gyroscopes and/or one or more accelerometers to detect head movement. TheHMD 102 may then interpret certain head-movements as being user input, such as nodding, or looking up, down, left, or right. AnHMD 102 could also pan or scroll through graphics in a display according to movement. Other types of actions may also be mapped to head movement. - As yet another example,
HMD 102 may interpret certain gestures (e.g., by a wearer's hand or hands) as user input. For example,HMD 102 may capture hand movements by analyzing image data fromimage capture device 120, and initiate actions that are defined as corresponding to certain hand movements. - As a further example,
HMD 102 may interpret eye movement as user input. In particular,HMD 102 may include one or more inward-facing image capture devices and/or one or more other inward-facing sensors (not shown) that may be used to track eye movements and/or determine the direction of a wearer's gaze. As such, certain eye movements may be mapped to certain actions. For example, certain actions may be defined as corresponding to movement of the eye in a certain direction, a blink, and/or a wink, among other possibilities. -
HMD 102 also includes aspeaker 125 for generating audio output. In one example, the speaker could be in the form of a bone conduction speaker, also referred to as a bone conduction transducer (BCT).Speaker 125 may be, for example, a vibration transducer or an electroacoustic transducer that produces sound in response to an electrical audio signal input. The frame ofHMD 102 may be designed such that when a user wearsHMD 102, thespeaker 125 contacts the wearer. Alternatively,speaker 125 may be embedded within the frame ofHMD 102 and positioned such that, when theHMD 102 is worn,speaker 125 vibrates a portion of the frame that contacts the wearer. In either case,HMD 102 may be configured to send an audio signal tospeaker 125, so that vibration of the speaker may be directly or indirectly transferred to the bone structure of the wearer. When the vibrations travel through the bone structure to the bones in the middle ear of the wearer, the wearer can interpret the vibrations provided byBCT 125 as sounds. - Various types of bone-conduction transducers (BCTs) may be implemented, depending upon the particular implementation. Generally, any component that is arranged to vibrate the
HMD 102 may be incorporated as a vibration transducer. Yet further it should be understood that anHMD 102 may include asingle speaker 125 or multiple speakers. In addition, the location(s) of speaker(s) on the HMD may vary, depending upon the implementation. For example, a speaker may be located proximate to a wearer's temple (as shown), behind the wearer's ear, proximate to the wearer's nose, and/or at any other location where thespeaker 125 can vibrate the wearer's bone structure. -
FIG. 1B illustrates an alternate view of the wearable computing device illustrated inFIG. 1A . As shown inFIG. 1B , thelens elements HMD 102 may include afirst projector 128 coupled to an inside surface of the extending side-arm 116 and configured to project adisplay 130 onto an inside surface of thelens element 112. Additionally or alternatively, asecond projector 132 may be coupled to an inside surface of the extending side-arm 114 and configured to project adisplay 134 onto an inside surface of thelens element 110. - The
lens elements projectors projectors - In alternative embodiments, other types of display elements may also be used. For example, the
lens elements frame elements -
FIG. 1C illustrates another wearable computing system according to an example embodiment, which takes the form of anHMD 152. TheHMD 152 may include frame elements and side-arms such as those described with respect toFIGS. 1A and 1B . TheHMD 152 may additionally include an on-board computing system 154 and animage capture device 156, such as those described with respect toFIGS. 1A and 1B . Theimage capture device 156 is shown mounted on a frame of theHMD 152. However, theimage capture device 156 may be mounted at other positions as well. - As shown in
FIG. 1C , theHMD 152 may include asingle display 158 which may be coupled to the device. Thedisplay 158 may be formed on one of the lens elements of theHMD 152, such as a lens element described with respect toFIGS. 1A and 1B , and may be configured to overlay computer-generated graphics in the user's view of the physical world. Thedisplay 158 is shown to be provided in a center of a lens of theHMD 152, however, thedisplay 158 may be provided in other positions, such as for example towards either the upper or lower portions of the wearer's field of view. Thedisplay 158 is controllable via thecomputing system 154 that is coupled to thedisplay 158 via anoptical waveguide 160. -
FIG. 1D illustrates another wearable computing system according to an example embodiment, which takes the form of amonocular HMD 172. TheHMD 172 may include side-arms 173, acenter frame support 174, and a bridge portion withnosepiece 175. In the example shown inFIG. 1D , thecenter frame support 174 connects the side-arms 173. TheHMD 172 does not include lens-frames containing lens elements. TheHMD 172 may additionally include acomponent housing 176, which may include an on-board computing system (not shown), animage capture device 178, and abutton 179 for operating the image capture device 178 (and/or usable for other purposes).Component housing 176 may also include other electrical components and/or may be electrically connected to electrical components at other locations within or on the HMD.HMD 172 also includes aBCT 186. - The
HMD 172 may include asingle display 180, which may be coupled to one of the side-arms 173 via thecomponent housing 176. In an example embodiment, thedisplay 180 may be a see-through display, which is made of glass and/or another transparent or translucent material, such that the wearer can see their environment through thedisplay 180. Further, thecomponent housing 176 may include the light sources (not shown) for thedisplay 180 and/or optical elements (not shown) to direct light from the light sources to thedisplay 180. As such,display 180 may include optical features that direct light that is generated by such light sources towards the wearer's eye, whenHMD 172 is being worn. - In a further aspect,
HMD 172 may include a slidingfeature 184, which may be used to adjust the length of the side-arms 173. Thus, slidingfeature 184 may be used to adjust the fit ofHMD 172. Further, an HMD may include other features that allow a wearer to adjust the fit of the HMD, without departing from the scope of the invention. -
FIGS. 1E to 1G are simplified illustrations of theHMD 172 shown inFIG. 1D , being worn by awearer 190. As shown inFIG. 1F , whenHMD 172 is worn,BCT 186 is arranged such that whenHMD 172 is worn,BCT 186 is located behind the wearer's ear. As such,BCT 186 is not visible from the perspective shown inFIG. 1E . - In the illustrated example, the
display 180 may be arranged such that whenHMD 172 is worn,display 180 is positioned in front of or proximate to a user's eye when theHMD 172 is worn by a user. For example,display 180 may be positioned below the center frame support and above the center of the wearer's eye, as shown inFIG. 1E . Further, in the illustrated configuration,display 180 may be offset from the center of the wearer's eye (e.g., so that the center ofdisplay 180 is positioned to the right and above of the center of the wearer's eye, from the wearer's perspective). - Configured as shown in
FIGS. 1E to 1G ,display 180 may be located in the periphery of the field of view of thewearer 190, whenHMD 172 is worn. Thus, as shown byFIG. 1F , when thewearer 190 looks forward, thewearer 190 may see thedisplay 180 with their peripheral vision. As a result,display 180 may be outside the central portion of the wearer's field of view when their eye is facing forward, as it commonly is for many day-to-day activities. Such positioning can facilitate unobstructed eye-to-eye conversations with others, as well as generally providing unobstructed viewing and perception of the world within the central portion of the wearer's field of view. Further, when thedisplay 180 is located as shown, thewearer 190 may view thedisplay 180 by, e.g., looking up with their eyes only (possibly without moving their head). This is illustrated as shown inFIG. 1G , where the wearer has moved their eyes to look up and align their line of sight withdisplay 180. A wearer might also use the display by tilting their head down and aligning their eye with thedisplay 180. -
FIG. 2A is a simplified block diagram of acomputing device 210 according to an example embodiment. In an example embodiment,device 210 communicates using a communication link 230 (e.g., a wired or wireless connection) to aremote device 240. Thedevice 210 may be any type of device that can receive data and display information corresponding to or associated with the data. For example, thedevice 210 may be a heads-up display system, such as the head-mounted devices (HMDs) 102, 152, 172, or 252 described with reference toFIGS. 1A-1G and 2B . - Thus, the
device 210 may include adisplay system 212 comprising aprocessor 214 and adisplay 216. Thedisplay 210 may be, for example, an optical see-through display, an optical see-around display, or a video see-through display. Theprocessor 214 may receive data from theremote device 240, and configure the data for display on thedisplay 216. Theprocessor 214 may be any type of processor, such as a micro-processor or a digital signal processor, for example. - The
device 210 may further include on-board data storage, such asmemory 218 coupled to theprocessor 214. Thememory 218 may store software that can be accessed and executed by theprocessor 214, for example. - The
remote device 240 may be any type of computing device or transmitter including a laptop computer, a mobile telephone, or tablet computing device, etc., that is configured to transmit data to thedevice 210. Theremote device 240 and thedevice 210 may contain hardware to enable thecommunication link 230, such as processors, transmitters, receivers, antennas, etc. - Further,
remote device 240 may take the form of or be implemented in a computing system that is in communication with and configured to perform functions on behalf of client device, such ascomputing device 210. Such aremote device 240 may receive data from another computing device 210 (e.g., anHMD device 210, and then send the resulting data back todevice 210. This functionality may be referred to as “cloud” computing. - In
FIG. 2A , thecommunication link 230 is illustrated as a wireless connection; however, wired connections may also be used. For example, thecommunication link 230 may be a wired serial bus such as a universal serial bus or a parallel bus. A wired connection may be a proprietary connection as well. Thecommunication link 230 may also be a wireless connection using, e.g., Bluetooth® radio technology, communication protocols described in IEEE 802.11 (including any IEEE 802.11 revisions), Cellular technology (such as GSM, CDMA, UMTS, EV-DO, WiMAX, or LTE), or Zigbee® technology, among other possibilities. Theremote device 240 may be accessible via the Internet and may include a computing cluster associated with a particular web service (e.g., social-networking, photo sharing, address book, etc.). - C. Example Image Projection
-
FIG. 2B shows an example projection of UI elements described herein via animage 280 by an example head-mountable device (HMD) 252, according to an example embodiment. Other configurations of an HMD may be also be used to present the UI described herein viaimage 280.FIG. 2B showswearer 254 ofHMD 252 looking at an eye ofperson 256. As such,wearer 254's gaze, or direction of viewing, is alonggaze vector 260. A horizontal plane, such ashorizontal gaze plane 264 can then be used to divide space into three portions: space abovehorizontal gaze plane 264, space inhorizontal gaze plane 264, and space belowhorizontal gaze plane 264. In the context ofprojection plane 276,horizontal gaze plane 260 appears as a line that divides projection plane into a subplane above the line ofhorizontal gaze plane 260, a subplane a subspace below the line ofhorizontal gaze plane 260, and the line wherehorizontal gaze plane 260 intersectsprojection plane 276. InFIG. 2B ,horizontal gaze plane 264 is shown using dotted lines. - Additionally, a dividing plane, indicated using
dividing line 274 can be drawn to separate space into three other portions: space to the left of the dividing plane, space on the dividing plane, and space to right of the dividing plane. In the context ofprojection plane 276, the dividing plane intersectsprojection plane 276 at dividingline 274. Thus the dividing plane divides projection plane into: a subplane to the left of dividingline 274, a subplane to the right of dividingline 274, and dividingline 274. InFIG. 2B , dividingline 274 is shown as a solid line. - Humans,
such wearer 254, when gazing in a gaze direction, may have limits on what objects can be seen above and below the gaze direction.FIG. 2B shows the uppervisual plane 270 as the uppermost plane thatwearer 254 can see while gazing alonggaze vector 260, and shows lowervisual plane 272 as the lowermost plane thatwearer 254 can see while gazing alonggaze vector 260. InFIG. 2B , uppervisual plane 270 and lowervisual plane 272 are shown using dashed lines. - The HMD can project an image for view by
wearer 254 at someapparent distance 262 alongdisplay line 282, which is shown as a dotted and dashed line inFIG. 2B . For example,apparent distance 262 can be 1 meter, four feet, infinity, or some other distance. That is,HMD 252 can generate a display, such asimage 280, which appears to be at theapparent distance 262 from the eye ofwearer 254 and inprojection plane 276. In this example,image 280 is shown betweenhorizontal gaze plane 264 and uppervisual plane 270; that isimage 280 is projected abovegaze vector 260. In this example,image 280 is also projected to the right of dividingline 274. Asimage 280 is projected above and to the right ofgaze vector 260,wearer 254 can look atperson 256 withoutimage 280 obscuring their general view. In one example, the display element of theHMD 252 is translucent when not active (i.e. whenimage 280 is not being displayed), and so thewearer 254 can perceive objects in the real world along the vector ofdisplay line 282. - Other example locations for displaying
image 280 can be used to permitwearer 254 to look alonggaze vector 260 without obscuring the view of objects along the gaze vector. For example, in some embodiments,image 280 can be projected abovehorizontal gaze plane 264 near and/or just above uppervisual plane 270 to keepimage 280 from obscuring most ofwearer 254′s view. Then, whenwearer 254 wants to viewimage 280,wearer 254 can move their eyes such that their gaze is directly towardimage 280. - D. An Example User Interface for an HMD
- The
display 216 ofdevice 210 may be available as part of a user interface for an HMD, such as one ofexample HMDs FIG. 2A . Thedisplay 216 ofdevice 210 can be used to display portions of a VNUI (voice-navigable user interface) 220, which can includedisplay 216, input device(s) 222, such as microphone(s), to receive speech input, and output device(s) 224 such as the display, speaker(s), and/or BCT(s) for audio and/or video output. In an example operation, a user or wearer of an HMD may utter words or phrases displayed on a voice navigable menu to interact with theVNUI 220. -
FIGS. 3A and 3B show an example voicenavigable menu 300, which VNUI 220 can present on thedisplay 216. The voicenavigable menu 300 can include one ormore categories 301; e.g., “Category 1,” “Category 2,” “Category 3,” and “Category 4” as shown inFIG. 3A . As used herein, a “category,” for example, is a menu item that can describe or can be associated with one or more sub-items. For instance, a restaurant menu category “Breakfast” may describe a number of restaurant menu items for breakfast, such as eggs, toast, oatmeal, bacon, etc. - The voice
navigable menu 300 can include menu items, such ascategories 301 and commands 302 inFIGS. 3A and 3B . The menu items may be organized into “top-level” menu items and “sub-level” menu items. A top-level menu item is, generally, a menu item with which other menu items are associated. In some cases, a top-level menu item is a menu item that can be expanded to reveal lower level menu items, such as sub-level menu items. A sub-level menu item is, generally, a menu item that is associated with another menu item, such as a top-level menu item. - In some cases, the voice
navigable menu 300 can have a parent-child hierarchy, in which top-level menu items correspond to a parent menu item and sub-level menu items correspond to a child menu item. In some cases, top-level menu items are displayed on one physical level of the menu, such as a root or base level, while sub-level menu items are displayed on a second physical level of the menu. In some embodiments, the voicenavigable menu 300 displays top-level menu items as the left-most items in a display. - In some embodiments, the
categories 301 comprise top-level menu items, as shown inFIGS. 3A and 3B . As shown inFIG. 3B , thecategories 301—top-level menu items—can be displayed as the left-most (or least-indented) menu items. - Each category can include or be associated with one or
more commands 302, and eachcommand 302 can be associated with one or more of thecategories 301. In some embodiments, thecommands 302 can be sub-level menu items, as shown inFIG. 3B . As shown inFIG. 3B , thecommands 302—sub-level menu items—can be displayed further to the right (or further indented) as compared to the top-level menu items. - The
categories 301 and commands 302 can be some or all of the menu items in the voicenavigable menu 300. For example, other menu items can include identifications of files. Other examples are possible as well. - Some or all of the menu items of the voice
navigable menu 300 can be displayed to a wearer on thedisplay 216. In some cases, an HMD may interpret certain head-movements as being wearer input, such as nodding, or looking up, down, left, or right.VNUI 220 may, in turn, interpret such movements as wearer input directing the voicenavigable menu 300 to scroll, such that menu items previously not visible ondisplay 216 become visible. In some cases, displayed menu items can also serve as cues to a wearer, by providing the wearer with a word or phrase that the wearer can utter to navigate the menu or invoke a command. - Such utterances by wearer(s) can include the
categories 301 and thecommands 302. In response to an utterance comprising one of thecategories 301,VNUI 220 may display, on thedisplay 216, the command or commands 302 associated with the uttered category. In response to an utterance comprising one of thecommands 302,VNUI 220 may invoke the uttered command. -
FIG. 4 shows anexample display 216. Theexample display 216 can include avisible menu 305. Thevisible menu 305 can include all or a part of the voicenavigable menu 300. For example, in some embodiments, all of voicenavigable menu 300 can be visible on thedisplay 216 asvisible menu 305. In other embodiments, only a portion of the voicenavigable menu 300 may be visible on thedisplay 216 as thevisible menu 305. For example, space limitations on thedisplay 216 and/or the length of the voicenavigable menu 300 can limitvisible menu 305 to displaying only a portion of voicenavigable menu 300. - The
visible menu 305, like the voicenavigable menu 300, can include one or more menu items. In some embodiments, thevisible menu 305 can display menu items from the voicenavigable menu 300 in a modified or rearranged order. In some embodiments, the visible menu can display sub-level menu items above and/or as top-level menu items. - The
visible menu 305 ofFIG. 4 depicts, in this example, three example categories displayed as top-level menu items:Camera 310,Communication 320, andInformation Retrieval 330. Other categories are possible as well. Thevisible menu 305 may include other menu items, such as commands, for example. - As discussed, a wearer can interact with the
VNUI 220 by uttering a menu item, such as an identification of a category. In an example operation, a wearer may utter a phrase such as “ok glass, open camera” to address the HMD by saying “ok glass” and then requesting the HMD access a camera by saying “open camera.” - In response,
VNUI 220 may then display in thevisible menu 305 the available commands associated with the uttered category. For example, as shown inFIG. 5 , example commands associated with theCamera category 310 may include “take a photo” 410 and “record a video” 420. Other commands are possible as well. - In some embodiments, when a wearer opens a category,
VNUI 220 can show the commands associated with the category as sub-level menu items in-line with the top-level menu items, as shown inFIG. 5 . In particular,FIG. 5 shows the “take a photo” 410 and “record a video” 420 sub-level commands in-line with theCamera 310 andCommunication 320 top-level categories in thevisible menu 305. - In this example, the VNUI associates a set of commands with a category by showing the commands below the associated category and slightly indented. Other ways of showing top-level menu items and sub-level menu items, and of differentiating top-level menu items from sub-level menu items, are possible as well. The
visible menu 305 also includes another category,Communication 320, which is not associated with the displayed commands and which is displayed below the commands. - In other embodiments, when a wearer opens a category,
VNUI 220 can show the commands as a stand-alone submenu on thedisplay 216, as shown inFIG. 6 . In particular, as seen inFIG. 6 , thevisible menu 305 includes commands associated with a particular category, but no categories or other menu items. - Minimizing the number of menu items in the
visible menu 305 can increase focus on commands likely to be invoked and so allow more efficient invocation of those commands. For example, the two commands “take a photo” 410 and “record a video” 420 presented in thevisible menu 305 ofFIG. 6 may be the two commands a wearer is most likely to want to invoke (based on, for example, the wearer uttering an identification of theCamera 310 category). - In addition, by minimizing menu items in the
visible menu 305,VNUI 220 may make navigating the menu more efficient. For example, a minimal or reduced number of menu items may keep a wearer from reading or mentally processing additional and potentially unneeded menu items. - In any case,
VNUI 220 can highlight or more prominently display certain menu items. To do so,VNUI 220 can, for example, display the menu item at the top of thevisible menu 305. In other embodiments,VNUI 220 can emphasize the menu item compared to one or more other menu items, without necessarily displaying the menu item at the top of thevisible menu 305. - For example, once a wearer has invoked a command,
VNUI 220 can “bubble-up” the command to the top of thevisible menu 305 or to a position above another command or a category. In particular, the next time a wearer invokes the menu,VNUI 220 can present, for example, a most recently used and/or a most frequently used command above other menu items. In some cases,VNUI 220 can present the command at or near the top of thevisible menu 305. -
FIG. 7 shows an example menu in which thevisible menu 305 includes the command “take a photo” 410 above thecategories Camera 310,Communication 320, andInformation retrieval 330. InFIG. 7 ,VNUI 220 has bubbled-up the command “take a photo” 410 to a position above the displayed categories. There may also be other menu items available but not displayed in thevisible menu 305. -
FIG. 8A shows an example menu in which thevisible menu 305 includes the commands “take a photo” 410 and “send a message” 430 above thecategories Camera 310 andCommunication 320. Here,VNUI 220 has bubbled-up the commands “take a photo” 410 and “send a message” 430 to a position above the displayed categories. There may also be other menu items available but not displayed in thevisible menu 305. - In any case, once a wearer has used
VNUI 220 to navigate to and invoke one or more commands, thevisible menu 305 can include both available categories and commands. In some embodiments, the visible menu can display both available categories and commands as top-level menu items, as inFIGS. 7 and 8A . - By bubbling up or prominently displaying one or more menu items,
VNUI 220 can present the one or more menu items in a manner that attempts to predict a wearer's intent when using the VNUI. In particular, the VNUI can determine a command likely to be used, and the VNUI can display the command to appear more prominently than other menu items. -
VNUI 220 can use any number of various criteria to determine which command or commands a wearer is likely to invoke. As one example, the VNUI can determine a command likely to be used based on how frequently commands are used by the wearer. In particular, the VNUI may bubble up the command or commands used most frequently by a wearer, such that a more frequently invoked command appears at the top of the menu. - As another example, the VNUI can determine a command likely to be used based on how recently a wearer has used the command. In particular, the VNUI may bubble up the command or commands used most recently by a wearer, such that a more recently invoked command appears at the top of the menu.
- As yet another example,
VNUI 220 can bubble up the commands based on some combination of criteria. For instance, the VNUI can bubble up commands based on a first criteria of how recently a wearer has used the command, and then, for those commands with similar frequencies of use, based on a second criteria of how recently a wearer has used the command or commands. - Taking the
visible menu 305 ofFIG. 6 as one particular example,VNUI 220 may have determined that a wearer is more likely to use the “take a photo” 410 command than other menu items. Accordingly, the VNUI can, in this example, display the “take a photo” 410 command above the other menu items in thevisible menu 305. - Taking the
visible menu 305 ofFIG. 8A as another particular example,VNUI 220 may have determined that a wearer is more likely to use the “take a photo” 410 and “send a message” 430 commands than other menu items (such as other commands). Accordingly,VNUI 220 can, in this example, display the “take a photo” 410 and “send a message” 430 commands above the other menu items in thevisible menu 305. -
VNUI 220 may also have determined that a wearer is more likely to use the “take a photo” 410 command than the “send a message” 430 command. Accordingly, the VNUI can, in this example, display the command “take a photo” 410 above the command “send a message” 430 in thevisible menu 305. - In addition, as one or more commands or menu items bubble up, other commands or menu items can “bubble down.” For example, commands that have previously been bubbled up can be displaced by newly bubbled up commands. In some cases, a displaced command can be displayed below a newly bubbled up command. In other cases, the displaced command can be displayed only once a wearer utters the name of a category with which the displaced command is associated. Other examples are possible as well.
- By bubbling up commands, the VNUI also encourages a wearer to speak the command directly from the top-level menu. If a wearer sees the command in a visible menu with top-level menu items, the wearer should not need to navigate to a submenu to view commands associated with a category before invoking the command. Accordingly, bubbling up commands may make the VNUI more efficient for a wearer.
- As an example, a wearer can directly invoke a command that has been bubbled up to the top-level menu. In particular,
FIG. 7 shows the command “take a photo” 410 bubbled up in thevisible menu 305. A wearer can directly invoke this command viaVNUI 220 by uttering a sequence such as “ok glass, take a photo,” instead of having to navigate to the command by uttering the sequence “ok glass, open camera, take a photo.” - Regardless of whether a command has been bubbled up or displayed more prominently, wearers of some embodiments can invoke a command directly from the top-level menu—without needing to navigate to a category. Some embodiments of the VNUI can incorporate a “hotword” approach to voice recognition. Each command can be treated as a hotword, and the VNUI can recognize and carry out the command, even if the command is not displayed on the
visible menu 305. - As an example, other commands may not be visible in the
visible menu 305 ofFIG. 8A , although they may be available. In particular,VNUI 220 may include the command “record a video,” whichVNUI 220 may not display in thevisible menu 305. A wearer can also directly invoke this command viaVNUI 220 by uttering a sequence such as “ok glass, record a video,” instead of having to navigate to the command by uttering a sequence such as “ok glass, open camera, record a video.” Accordingly, the system allows a wearer to utter a command directly, without the command being visible on the menu. - The system also allows for a wearer to be able to invoke commands from one category while viewing commands from another category. For example, the
visible menus 305 ofFIG. 5 andFIG. 6 display commands in the category “Camera” 310. A wearer can also directly invoke, viaVNUI 220, a command from another category, such as the command “send a message” 430 from thecategory Communication 320. In particular, from thevisible menus 305 ofFIG. 5 or 6 , a wearer can utter a sequence such as “ok glass, send a message” to directly invoke the “send a message” command, even if that command is not displayed on thevisible menu 305. - In some embodiments, a wearer may also use
VNUI 220 to navigate to a category that is not in the visible display. For example, thevisible menu 305 ofFIG. 5 shows thecategory Camera 310 and thecategory Communication 320, but not the category Information Retrieval 330 (as shown inFIG. 4 ). In this example, from thevisible menu 305 ofFIG. 5 , a wearer can utter a sequence such as “ok glass, open information retrieval” to view available commands in that category. - Associating commands with categories, bubbling up the command(s) most likely to be used, and allowing commands to be invoked from anywhere within the available menu can help the scalability of voice navigable menus. Such a system can allow for more voice commands to be added with minimal impact on the ability of the VNUI and visible display to efficiently guide a wearer through the menu.
- The menu items in the
visible menu 305 can act as cues for a wearer of the voicenavigable menu 300. In other words, the items in thevisible menu 305 can tell a wearer what to say to invoke a command or to navigate the menu. For example, by speaking a command, a wearer can invoke the command. And by speaking a category, a wearer can navigate to the available commands in that category. - The ability to efficiently guide a wearer through the voice navigable menu may be an especially important consideration for new or infrequent wearers. Likewise, even experienced wearers may be unfamiliar with available menu items such as commands or categories (such as, for example, if commands or categories are added to the voice navigable menu).
- In particular, associating commands with categories can reduce the number of items displayed in, for example, a top-level menu. For instance, multiple commands can be associated with each category, and commands may be added to each category as the system develops. The number of categories will likely be less than the number of commands. A menu that displays some or all available categories may have fewer menu items than a menu that displays, for example, all available commands.
- A menu with fewer menu items may be easier to navigate, especially on a smaller display of an HMD. In particular, an HMD may have a smaller display than other mobile computing devices. In some cases, an HMD may have a significantly smaller display than other computing devices. Accordingly, the
display 216 andvisible menu 305 of an HMD may also be smaller or significantly smaller than other computer devices. - Because of the
smaller display 216, fewer menu items may be able to be presented to a wearer on thevisible menu 305. Accordingly, the fewer menu items in the voicenavigable menu 300, the better chance that thevisible menu 305 can include the entire voice navigable menu. Alternatively, if thevisible menu 305 only includes a portion of the entire voicenavigable menu 300, minimizing the number of menu items in the voicenavigable menu 300 should help increase the amount of the voicenavigable menu 300 included in thevisible menu 305. - A wearer's efficiency in navigating a voice navigable menu should increase with a wearer's ability to see more of the voice navigable menu in the
display 216. In other words, the time spent by a wearer navigating the voice navigable menu should be less if thevisible menu 305 includes more of the available categories and commands. - Bubbling up the command or commands most likely to be used can also help a wearer efficiently navigate a voice navigable menu. For example, the bubbled up commands may be the commands a wearer is most likely to want to invoke. In such a case, a wearer may be able to more quickly recall or invoke a command if the command is visually presented to the wearer—or visually presented to the wearer in a prominent way, such as at the top of a visible menu.
- In particular, a wearer seeking a particular command may avoid having to navigate to that command. Instead, if that command is displayed in the top-level menu (at the top or in some other, prominent way), a wearer can immediately receive the visual cue for the command without having to navigate to the category.
- In addition, allowing commands to be invoked from anywhere within the available menu can also reduce the need for a wearer to navigate to a particular category (or top-level visible menu) before invoking the command.
- E. Updating the Example User Interface
- Some embodiments also allow for the addition of applications or features, in some cases from third-parties. In such embodiments, the added applications can result in added commands. In the voice navigable menu, the added commands can be associated with an added command menu item, which can comprise an added command category in the voice navigable menu.
- For discussion purposes, an added command can be distinguished from an original command. An original command can refer to a command that may have been originally provided in or, in some cases, previously added to a voice navigable menu. In addition, an added command menu item can be distinguished from an original menu item. An original menu item can refer to a menu item, such as a category, that may have been originally provided in or, in some cases, previously added to a voice navigable menu.
- In some instances, the added applications can be treated collectively as a category in the voice-navigable menu (such as a “Glass Apps” category or an “Added Command” category, for example). In other cases, a third-party application or one or more added commands may be treated as its own category (such as a “Facebook” category, for example).
- Turning to
FIG. 8B , as a more particular example, a category for added applications (such as third-party applications) can beGlass Apps 340, and commands within that category may be, for example, (i) “post a tweet” 440 and (ii) “call an Uber car” 450—commands associated with two different third-party features. - As shown in
FIG. 8B , in thevisible menu 305, uttering “ok glass, open Glass Apps” would show the added commands “post a tweet” 440 and “call an Uber car” 450. Accordingly, added commands can be invoked viaVNUI 220 by uttering a sequence such as “ok glass, open Glass Apps, post a tweet.” - As with other commands, added commands such as “post a tweet” 440 and “call an Uber car” 450 can be bubbled up in the top-level menu. As also with other commands, added commands can be directly invoked via
VNUI 220 by uttering a sequence such as “ok glass, post a tweet,” instead of having to navigate to the added command by uttering the sequence “ok glass, open Glass Apps, post a tweet.” - In addition, a menu item for an added command can be the command itself, instead of an ambiguous menu item that merely opens an app or leads to further menu items. For example, a menu item such as the command “post a tweet” provides more guidance to a wearer than a menu item such as “open Twitter.”
- A wearer may choose which additional or third-party applications or features to install or enable in a set-up portal for the HMD device. The set up portal may be part of the HMD or the
VNUI 220 itself, or it may be accessed through interfaces of other devices (such as an Internet browser on a computing device). Additional or third-party applications may also be added to the VNUI automatically by a computing device executing suitable software. - If a wearer chooses particular additional or third-party applications or features, there may be a set-up sequence that asks a wearer to specify whether:
- I'd like to use Glass to . . .
- . . . post a tweet [ ON OFF ]
- . . . call an Uber car [ ON OFF ]
Accordingly, commands can be added to the voicenavigable menu 300 based on the features that the wearer enables. Once added to the voicenavigable menu 300, the added commands can be displayed in thevisible menu 305 and treated similarly to the commands discussed above. - One unique property of this example set-up sequence is that the set-up flow uses the same verb form of a command that a wearer would utter when invoking the command. In particular, uttered commands (e.g., “post a tweet”) use the English imperative verb form, while the set-up flow (“I'd like to use Glass to . . . ”) uses the English infinitive verb form, and each verb form is orthographically/lexicographically identical in English. In other words, a wearer can use the same verb form of “post a tweet” both during a set-up sequence (“I'd like to use Glass to post a tweet”) and when invoking the command (“ok glass, post a tweet”).
- In particular,
FIGS. 9A-9C depict an example set-up sequence that can be presented on thedisplay 216 ofVNUI 220. In this example,FIG. 9A shows a menu itemAdd Glass Apps 332 in thevisible menu 305. To select theAdd Glass Apps 332 menu item, a wearer can utter “ok glass, add glass apps.” -
VNUI 220 may then present to the wearer thevisible menu 305 ofFIG. 9B , which displays two available commands for selection: enable “post a tweet” 334 and enable “call an Uber car” 336. To enable one of the available commands, a wearer can utter “ok glass, enable ‘post a tweet.’” -
VNUI 220 may then present to the wearer thevisible menu 305 ofFIG. 9C , which displays the “post a tweet” 440 command as a menu item. As discussed, the “post a tweet” command may also be added or associated with a category of added commands, such as theGlass Apps 340 category ofFIG. 8B . - Added commands (such as third-party or other added commands) may be merged into an existing library of voice commands. Because of the potentially large number of added or third-party commands, potential added commands can be selected and approved to maintain distinctiveness from other commands. One consideration may be selecting potential added commands that are long enough to provide phonetic distinctiveness from other commands (for example, “post a tweet” instead of “tweet”).
- In addition, a computer executing suitable software can determine a phonetic distance between a potential added command set and existing commands, perhaps in an existing command set. If the smallest phonetic distance between commands in the potential added command set and an existing command set is greater than a threshold, the computer can determine that the potential added command set may be acceptable for addition in the command set. If the smallest phonetic distance is less than the threshold, however, then the computer can determine that the potential added command set may not be distinguishable from the existing command set by the speech recognition system. In some embodiments, the computer can identify command(s) in the potential added command set whose phonetic distance is within the threshold, and suggest those commands be modified or rejected for inclusion of the potential added command set into the existing command set.
- The VNUI can be periodically updated with added commands as needed.
- F. Example Methods of Operation
- As noted above, the user of an HMD or other computing device may be able to give voice commands to the device. These commands may be accessible on voice-navigable menus as part of a VNUI, for example. Certain voice commands may require fulfillment by a third party service provider. For instance, an HMD user may give a command to buy a dozen roses, order a pizza, buy a particular widget, request a plumber, request emergency assistance, and so on.
-
FIG. 10 is a flow chart illustrating amethod 1000, according to an example embodiment. InFIG. 10 ,method 1000 is described by way of example as being carried out by a wearable computer and possibly a wearable computer that includes a head-mounted display (HMD). However, it should be understood that example methods, such asmethod 1000, may be carried out by a wearable computer without wearing the computer. For example, such methods may be carried out by simply holding the wearable computer using the wearer's hands. Other possibilities may also exist. - Further, example methods, such as
method 1000, may be carried out by devices other than a wearable computer, and/or may be carried out by sub-systems in a wearable computer or in other devices. For example, an example method may alternatively be carried out by a device such as a mobile phone or laptop computer. Other examples are also possible. - In some exemplary embodiments, a remote server may help reduce the HMD's processing load. In such embodiments, the HMD may send certain data about a service request to a remote, cloud-based server system, which may perform some or all of the necessary data processing (e.g., determining a selected service provider) in order to reduce the load on the HMD. As part of a cloud-based implementation, the HMD may communicate with the server through a wireless connection, through a wired connection, or through a network of wireless and/or wired connections. In some examples, the server may also communicate with third party service providers through a wired connection, or through a network of wireless and/or wired connections.
- As shown in
FIG. 10 ,method 1000 begins atblock 1010, where a computing device such as an HMD may receive a first utterance, which includes a first command. For example, an utterance may be one or more words, one or more phrases, a sentence, or a series of sentences spoken by a user of an HMD. As described above, the HMD may process a user's speech and determine that a certain command has been issued by the user. In some examples, the command may be selected by the user from a menu within a VNUI. - A command could be any number of a wide variety of requests from the user to the device. A certain subset of those commands may require fulfillment by a third party service provider.
FIG. 11A shows an example list of commands, according to an example embodiment. Each of the commands may be accessible to the user, for example by including the commands in one or menus of a VNUI. Each command (“order a pizza” 1110, “call a plumber” 1120, “buy a movie ticket” 1130) may require fulfillment by a third party service provider (e.g., a pizza restaurant, a plumber, a movie theater). It should be understood that these commands are meant only as examples. Any command to order a product or request a different type of service from a service provider may be used as well. - In some examples, the space of possible voice commands that require the assistance of a third party may be predetermined. The voice commands that can be recognized at
block 1010 of themethod 1000 may be taken from a predetermined set of voice commands that may include 500 commands or 5,000 commands or 50,000 commands, for example. In some examples, the set of possible voice commands may be all of the commands that are included within menus of a VNUI, or that can be added to one of the menus as described above. - By limiting the set of possible voice commands, the step of identifying a command from a voice utterance may be simplified. There may be less chance of error when the space of possible commands is limited because there may be fewer similar sounding commands. Additionally, there may also be less risk of ambiguity about the intent of an HMD user when the user issues a command. For example, if the user could issue any possible command such as “pizza,” the user's intent may not be easily identified. For instance, the user may wish to order a pizza, may wish to run a search engine search for pizza, may wish to find local pizza restaurants, may wish to find pizza recipes, and so on. In some examples, the user may be limited to giving only certain voice commands that are unlikely to create ambiguous intent. For instance, the user may be limited to using the command “order a pizza,” in order to unambiguously demonstrate an intent to purchase a pizza. Other possible constructions for defining the scope of possible voice commands exist as well.
- At
block 1020 ofmethod 1000, the HMD may select a service action corresponding to the first command. As noted, certain commands within the space of commands may require fulfillment by a third party service provider. By issuing a command from the space of commands that indicates a need for a service provider, a user may be communicating a specific intent to receive a certain selected service. In order to fulfill the request, a selected service may be identified. - A framework may be used to select a service action for a given voice command.
FIG. 11B shows an example command-service mapping, according to an example embodiment. Each voice command that may require fulfillment by a third party service provider may be mapped to a specific service action. For instance, “order a pizza” 1110 may be mapped to a pizzadelivery service action 1150, “call a plumber” 1120 may be mapped to aplumbing service action 1160, “buy a movie ticket” 1130 may be mapped to a ticketselling service action 1170, and so on. - In some example embodiments, a service action may incorporate input from users and/or third parties that is needed to fulfill a service request. For instance, instead of just issuing a command to “order a pizza,” a user may be able to issue a command to “order a pepperoni pizza.” The type of pizza topping may then be included within the selected service action. Additionally, a user may be able to issue a command to “order a large, pepperoni pizza” so that the size of the pizza may also be included within the selected service action, and so on. In further examples, information needed to fulfill the service request may be included within the selected service action, such as billing information or the delivery address of the HMD user.
- At
block 1030 ofmethod 1000, after selecting a service action, the HMD can determine a selected service provider for the selected service action. The selected service provider may be selected from a number of different service providers that are each capable of fulfilling the requested service. -
FIG. 12A shows an example determination of a selected service provider, according to an example embodiment. As shown, multiple service providers (plumber # 1 1220,plumber # 2 1230,plumber # 3 1240) may be capable of fulfilling the requestedplumbing service 1210. Each service provider may indicate in advance which services it is capable and willing to fulfill. A selected service provider may then be chosen to complete the selected service action from those service providers willing to fulfill the selected service. In this case,plumber # 2 1230 may be the selected service provider from among the available plumbers. - In some examples, determining the selected service provider may involve the use of an auction. Each service provider may indicate which services it would like to fulfill. Each service provider may then provide a bid for the right to fulfill the requested service. Limiting the set of possible service requests to a predetermined set where each service request corresponds to a voice command with a specific user intent may facilitate the bidding process because only a certain number of possible requests must be considered by the bidders. The service provider with the highest bid may then be chosen as the selected service provider to fulfill the requested service. The data processing for the auction may be carried out on the HMD's or remotely on a cloud-based server system.
- In further examples, the auction may be carried out in real time. The service providers may each provide parameters that may be used to determine their bids when a certain service is requested. In some examples, the service providers may first provide a bid price for each service it wishes to fulfill. The bid price may then be modified according to various parameters, such as the location of the HMD user or the time of day. The service providers may also input a budget that indicates the total amount they are willing to bid in a certain period of time. When a service request comes in, bids from a number of different providers may be determined, and a winning service provider may be determined based on the bids. In further examples, bids from different service providers may be periodically refreshed using a timeout period.
- In additional examples, the auction results may be predetermined. For instance, a winning service provider may be pre-computed for each possible service request. Accordingly, when a service request is received, a selected service provider may immediately be determined without accessing the network. For instance, a cloud-based server system may pre-compute auction results and send those results to local HMD's. Then, when an HMD receives a service request, it may use the pre-computed auction results to determine the selected service provider. In further examples, the auction results may be periodically updated, for instance, after receiving each service request or after receiving a certain number of service requests.
- Other factors may be used in addition to or instead of auctions to determine a selected service provider as well. For example, a preference metric may be determined for each service provider. The preference metric may be based on the total number of service requests fulfilled by each of the service providers in a certain period time, the prices charged by each of the service providers, or the overall satisfaction of users making the requests from each of the service providers, for instance. In another example, the preference metric may also be preset by individual HMD users. A service provider with a higher preference metric may be chosen to fulfill a service over a service provider with a lower preference metric.
- In another example, the distance of the HMD from each of the service providers may also be factored into the determination of a selected service provider. For instance, a threshold distance could be set, and only selected service providers closer to the HMD than the threshold distance may be eligible to become the selected service provider. In another example, the distance of each service provider from the HMD may be factored into the determination of a preference metric. Other examples for determining a selected service provider exist as well.
- At
block 1040 ofmethod 1000, the HMD may send a service fulfillment request to the selected service provider to execute the selected service action. The service fulfillment request may contain enough information such that the third party service provider can fulfill the request. For instance, the request may include the requested service, the location of the HMD user, the mailing address of the intended recipient, price information, timeline for filling the request, and so on. -
FIG. 12B shows an example service request, according to an example embodiment. After a selected service provider is determined (e.g.,plumber # 2 1230), aplumbing service request 1250 may be sent to the selected plumber. The request may include information about where the plumbing service is needed, by what day or time the service is needed, what time of day the plumber should come to provide the service, and so on. - In some examples, the HMD user may not see which service provider was selected to fulfill the user's service request. For example, the user may order the device to “purchase widget 18573.” A selected service provider may be determined by using an auction and/or one or more of the other methods described above. The widget may then be received at the user's door a few days later. Accordingly, the process may be streamlined to present a better overall user experience.
-
FIG. 13 is a flow chart illustrating amethod 1300, according to an example embodiment. InFIG. 13 ,method 1300 is described by way of example as being carried out by a wearable computer and possibly a wearable computer that includes a head-mounted display (HMD). However, it should be understood that example methods, such asmethod 1300, may be carried out by a wearable computer without wearing the computer. For example, such methods may be carried out by simply holding the wearable computer using the wearer's hands. Other possibilities may also exist. - Further, example methods, such as
method 1300, may be carried out by devices other than a wearable computer, and/or may be carried out by sub-systems in a wearable computer or in other devices. For example, an example method may alternatively be carried out by a device such as a mobile phone or laptop computer. Other examples are also possible. Themethod 1300 may be carried out by a remote server system as described above as well. - As shown in
FIG. 13 ,method 1300 begins atblock 1310, where a computing device such as an HMD may receive a first utterance, which includes a first command. As described above, the first command may be a command that requires fulfillment by a third party service provider. Each command may be accessible to the user, for example by including the commands in one or menus of VNUI. Furthermore, the command may be selected from a predetermined space of possible voice commands that require the assistance of a third party. - At
block 1320 ofmethod 1300, the HMD may select a service action associated with the first command. Each command may be associated with a specific service action that the HMD user is indicating a desire to have fulfilled. As described above, a framework, or mapping, may be used to select a service action for a given voice command. Furthermore, the selected service action may incorporate information needed to complete the requested service. - At
block 1330 ofmethod 1300, after selecting a service action, the HMD may determine one or more selected service providers for the selected service action. The selected service providers may be selected from a number of different service providers that are each capable of fulfilling the requested service. -
FIG. 14A shows an example determination of multiple selected service providers, according to an example embodiment. As shown, multiple service providers (plumber # 1 1420,plumber # 2 1430,plumber # 3 1440,plumber # 4 1450, andplumber # 5 1460) may each be capable of fulfilling the requestedplumbing service action 1410. Each service provider may indicate in advance which services it is capable and willing to fulfill. The selected service providers may then be chosen from those service providers willing to fulfill the selected service action. - In this case,
plumber # 1 1420,plumber # 3 1440, andplumber # 4 1450 may be the selected service providers from among the available plumbers. Three selected service providers are shown in this example, but any number could be used. Furthermore, a set number of selected service providers could always be chosen or the number of selected service providers could vary depending on various factors such as how many service providers in total are capable and willing to fulfill the requested service. - In some examples, determining the selected service providers may involve the use of an auction. Each service provider may indicate which services it would like to fulfill. Each service provider may then provide a bid for the right to fulfill the requested service. Limiting the set of possible service requests to a predetermined set where each service request corresponds to a voice command with a specific user intent may facilitate the bidding process because only a certain number of possible requests must be considered by the bidders. A certain number of service providers with the highest bids may then be chosen as the selected service providers. The data processing for the auction may be carried out on the HMD's or remotely on a cloud-based server system.
- As in
method 1000, the auction may be carried out in real time or the auction results may be predetermined. Additionally, other factors may be used in addition to or instead of an auction to determine the selected service providers as well. For example, a preference metric may be determined for each service provider, and may then be used to help determine the selected service providers. Additionally, the distance from the HMD to each of the service providers may also be factored into the determination of the selected service providers. Other factors may be used for determining the selected service providers as well. - At
block 1340 ofmethod 1300, after determining the selected service providers, the HMD may display advertisements corresponding to the selected service action from the selected service providers. For instance, if three selected service providers were determined, then a user of the HMD may be presented with an advertisement from each of the three selected service providers to fulfill the service request. -
FIG. 14B shows an example display showing ads from multiple service providers, according to an example embodiment. As shown, the three selected service providers (plumber # 1,plumber # 3, and plumber #4) may each display an advertisement within aview 1470 of a display of the HMD. In some cases, the ads may be created separately by each of the service providers and then transmitted to the HMD to display them. In other cases, a uniform format may be used for each of the ads along with some identifying information from each of the service providers. In additional examples, service providers may be able to provide different advertisements depending on the requested service or on other factors. Other methods of presenting advertisements from the service providers to the user may be used as well. - In some embodiments, method 1400 may further involve the HMD receiving a selected advertisement from the one or more displayed advertisements, and sending a service fulfillment request to the service provider corresponding to the selected advertisement to execute the selected service action. For instance, the HMD user may select which service provider she would like to fulfill her service request by selecting one of the displayed advertisements using a voice command, a physical or virtual button, a head or eye movement, or a different type of user input.
-
FIG. 14C shows an example service request to a selected service provider, according to an example embodiment. In this case, the HMD may have received a selection of the advertisement fromplumber # 3 from the HMD user, as shown in 1470. Aplumbing service request 1480 may then be issued toplumber # 3 1440. The request may include information about where the plumbing service is needed, by what day or time the service is needed, what time of day the plumber should come to provide the service, and so on. - In some embodiments, method 1400 may additionally include the HMD receiving one or more additional utterances on the computing device, where each of the one or more additional utterances includes the first command. Furthermore, the method 1400 may also include the HMD sending a service fulfillment request to the service provider corresponding to the selected advertisement to execute the selected service action for each of the one or more additional utterances.
- Accordingly, a user may only need to select an advertisement from the list of
advertisements 1470 the first time the service is requested. Afterwards, when the user requests the same service again, a service request may automatically be sent to the same selected service provider that the user already chose in order to again service the request. The user experience may therefore be improved by not requiring the user to choose a service provider each time she issues the same service request. - In another example, the user may select an advertisement from the list of
advertisements 1470 when the first command is first added to a menu, or at some other time before the service is ever requested by the user. Accordingly, the user may be able to pre-program which service provider will handle one or more different service requests before issuing the requests. Then, when the user does issue a service request, a service fulfillment request may immediately be sent to the chosen service provider to handle the request. The user may therefore be able to request services from third parties without any wait time after initially configuring which service providers will handle the requests. - G. Conclusion
- The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.
- The above detailed description describes various features and functions of the disclosed systems, devices, and methods with reference to the accompanying figures. In the figures, similar symbols typically identify similar components, unless context dictates otherwise. The example embodiments described herein and in the figures are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.
- With respect to any or all of the ladder diagrams, scenarios, and flow charts in the figures and as discussed herein, each block and/or communication may represent a processing of information and/or a transmission of information in accordance with example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, functions described as blocks, transmissions, communications, requests, responses, and/or messages may be executed out of order from that shown or discussed, including substantially concurrent or in reverse order, depending on the functionality involved. Further, more or fewer blocks and/or functions may be used with any of the ladder diagrams, scenarios, and flow charts discussed herein, and these ladder diagrams, scenarios, and flow charts may be combined with one another, in part or in whole.
- A block that represents a processing of information may correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique. Alternatively or additionally, a block that represents a processing of information may correspond to a module, a segment, or a portion of program code (including related data). The program code may include one or more instructions executable by a processor for implementing specific logical functions or actions in the method or technique. The program code and/or related data may be stored on any type of computer readable medium such as a storage device including a disk or hard drive or other storage medium.
- The computer readable medium may also include non-transitory computer readable media such as computer-readable media that stores data for short periods of time like register memory, processor cache, and random access memory (RAM). The computer readable media may also include non-transitory computer readable media that stores program code and/or data for longer periods of time, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. A computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device.
- Moreover, a block that represents one or more information transmissions may correspond to information transmissions between software and/or hardware modules in the same physical device. However, other information transmissions may be between software modules and/or hardware modules in different physical devices.
- The particular arrangements shown in the figures should not be viewed as limiting. It should be understood that other embodiments can include more or less of each element shown in a given figure. Further, some of the illustrated elements can be combined or omitted. Yet further, an example embodiment can include elements that are not illustrated in the figures.
- While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
Claims (20)
1. A method comprising:
determining, by a computing device, for each respective service action of a plurality of service actions requiring fulfillment by third-party service providers, a respective third-party service provider that will receive future requests to execute the respective service action, wherein the respective third-party service provider is determined based on a plurality of bids received from a plurality of third-party service providers for a right to execute the respective service action;
at a first time, caching on the computing device, for each respective service action, the respective third-party service provider that will receive the future requests to execute the respective service action;
at a second time later than the first time, receiving, by the computing device, an indication of a selected service action from the plurality of service actions;
selecting, by the computing device, from the cached third-party service providers, a service provider corresponding to the selected service action, wherein the selected service provider is the respective cached third-party service provider determined to receive the future requests to execute the selected service action; and
sending a service fulfillment request to the selected service provider to execute the selected service action.
2. The method of claim 1 , further comprising:
providing instructions for display of a voice-navigable user interface (VNUI) on a display interface, the VNUI comprising one or more visible menus that include a predetermined set of commands, wherein each command of the predetermined set of commands is mapped to a corresponding service action of the plurality of service actions.
3. The method of claim 2 , wherein the computing device is a server device communicatively connected to a client device, wherein the display interface is a display interface of the client device, wherein providing the instructions comprises transmitting the instructions from the server device to the client device, and wherein reception of the instructions causes the client device to display the VNUI on the display interface of the client device.
4. The method of claim 2 , wherein the display interface is a display interface of the computing device, wherein providing the instructions comprises transmitting the instructions from the computing device to the display interface, and wherein reception of the instructions causes the display interface of the computing device to display the VNUI.
5. The method of claim 2 , further comprising:
receiving a request to add a new voice command to the one or more visible menus of the VNUI;
determining a smallest phonetic distance between the new voice command and each command of the predetermined set of commands of the VNUI; and
when the smallest phonetic distance is greater than a threshold, adding the new voice command to the predetermined set of commands of the VNUI and mapping the new voice command to a corresponding new service action.
6. The method of claim 1 , wherein the plurality of bids is a first plurality of bids, wherein the plurality of third-party service providers is a first plurality of third-party service providers, and wherein the method further comprises:
receiving a request to add a new service action to the plurality of service actions; and
determining a new third-party service provider that will receive future requests to execute the new service action, wherein the new third-party service provider is determined based on a second plurality of bids received from a second plurality of third-party service providers for a right to execute the new service action.
7. The method of claim 1 , wherein receiving the indication of the selected service action comprises:
detecting, using a microphone communicatively connected to the computing device, a first utterance; and
determining that the first utterance corresponds to the selected service action of the plurality of service actions.
8. The method of claim 1 , wherein the computing device is a wearable computing device.
9. The method of claim 1 , wherein determining the respective third-party service provider that will receive future requests to execute the respective service action comprises:
receiving the plurality of bids from the plurality of third-party service providers; and
selecting a highest-bidding third-party service provider that provided a highest bid of the plurality of bids received from the plurality of third-party service providers.
10. The method of claim 9 , wherein caching on the computing device the respective third-party service provider that will receive the future requests to execute the respective service action comprises:
caching on the computing device the highest-bidding third-party service provider.
11. The method of claim 1 , wherein the respective third-party service provider is determined further based on a preference metric for each of the plurality of third-party service providers that provided the plurality of received bids.
12. The method of claim 1 , further comprising:
refreshing the respective third-party service provider after sending the service fulfillment request to the selected service provider.
13. A non-transitory computer readable medium having stored thereon instructions that, when executed by a computing device, cause the computing device to perform operations comprising:
determining for each respective service action of a plurality of service actions requiring fulfillment by third-party service providers, a respective third-party service provider that will receive future requests to execute the respective service action, wherein the respective third-party service provider is determined based on a plurality of bids received from a plurality of third-party service providers for a right to execute the respective service action;
at a first time, caching on the computing device, for each respective service action, the respective third-party service provider that will receive the future requests to execute the respective service action;
at a second time later than the first time, receiving an indication of a selected service action from the plurality of service actions;
selecting from the cached third-party service providers, a service provider corresponding to the selected service action, wherein the selected service provider is the respective cached third-party service provider determined to receive the future requests to execute the selected service action; and
sending a service fulfillment request to the selected service provider to execute the selected service action.
14. The non-transitory computer readable medium of claim 13 , wherein the operations further comprise:
providing instructions for display of a voice-navigable user interface (VNUI) on a display interface, the VNUI comprising one or more visible menus that include a predetermined set of commands, wherein each command of the predetermined set of commands is mapped to a corresponding service action of the plurality of service actions.
15. The non-transitory computer readable medium of claim 13 , wherein receiving the indication of the selected service action comprises:
detecting, using a microphone communicatively connected to the computing device, a first utterance; and
determining that the first utterance corresponds to the selected service action of the plurality of service actions.
16. The non-transitory computer readable medium of claim 13 , wherein determining the respective third-party service provider that will receive future requests to execute the respective service action comprises:
receiving the plurality of bids from the plurality of third-party service providers; and
selecting a highest-bidding third-party service provider that provided a highest bid of the plurality of bids received from the plurality of third-party service providers.
17. The non-transitory computer readable medium of claim 16 , wherein caching on the computing device the respective third-party service provider that will receive the future requests to execute the respective service action comprises:
caching on the computing device the highest-bidding third-party service provider.
18. A computing system comprising:
a processor;
a non-transitory computer readable memory; and
program instructions stored on the non-transitory computer readable memory and executable by the processor to perform operations comprising:
determining for each respective service action of a plurality of service actions requiring fulfillment by third-party service providers, a respective third-party service provider that will receive future requests to execute the respective service action, wherein the respective third-party service provider is determined based on a plurality of bids received from a plurality of third-party service providers for a right to execute the respective service action;
at a first time, caching on the computing system, for each respective service action, the respective third-party service provider that will receive the future requests to execute the respective service action;
at a second time later than the first time, receiving an indication of a selected service action from the plurality of service actions;
selecting from the cached third-party service providers, a service provider corresponding to the selected service action, wherein the selected service provider is the respective cached third-party service provider determined to receive the future requests to execute the selected service action; and
sending a service fulfillment request to the selected service provider to execute the selected service action.
19. The computing system of claim 18 , wherein receiving the indication of the selected service action comprises:
detecting, using a microphone communicatively connected to the computing system, a first utterance; and
determining that the first utterance corresponds to the selected service action of the plurality of service actions.
20. The computing system of claim 18 , wherein determining the respective third-party service provider that will receive future requests to execute the respective service action comprises:
receiving the plurality of bids from the plurality of third-party service providers; and
selecting a highest-bidding third-party service provider that provided a highest bid of the plurality of bids received from the plurality of third-party service providers.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/582,759 US20170236515A1 (en) | 2013-07-25 | 2017-04-30 | Model for Enabling Service Providers to Address Voice-Activated Commands |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/950,503 US9666187B1 (en) | 2013-07-25 | 2013-07-25 | Model for enabling service providers to address voice-activated commands |
US15/582,759 US20170236515A1 (en) | 2013-07-25 | 2017-04-30 | Model for Enabling Service Providers to Address Voice-Activated Commands |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/950,503 Continuation US9666187B1 (en) | 2013-07-25 | 2013-07-25 | Model for enabling service providers to address voice-activated commands |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170236515A1 true US20170236515A1 (en) | 2017-08-17 |
Family
ID=58737965
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/950,503 Active 2035-02-03 US9666187B1 (en) | 2013-07-25 | 2013-07-25 | Model for enabling service providers to address voice-activated commands |
US15/582,759 Abandoned US20170236515A1 (en) | 2013-07-25 | 2017-04-30 | Model for Enabling Service Providers to Address Voice-Activated Commands |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/950,503 Active 2035-02-03 US9666187B1 (en) | 2013-07-25 | 2013-07-25 | Model for enabling service providers to address voice-activated commands |
Country Status (1)
Country | Link |
---|---|
US (2) | US9666187B1 (en) |
Cited By (61)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180061420A1 (en) * | 2016-08-31 | 2018-03-01 | Bose Corporation | Accessing multiple virtual personal assistants (vpa) from a single device |
US10565999B2 (en) | 2016-08-05 | 2020-02-18 | Sonos, Inc. | Playback device supporting concurrent voice assistant services |
US10573321B1 (en) | 2018-09-25 | 2020-02-25 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
US10586540B1 (en) | 2019-06-12 | 2020-03-10 | Sonos, Inc. | Network microphone device with command keyword conditioning |
US10606555B1 (en) | 2017-09-29 | 2020-03-31 | Sonos, Inc. | Media playback system with concurrent voice assistance |
US10614807B2 (en) | 2016-10-19 | 2020-04-07 | Sonos, Inc. | Arbitration-based voice recognition |
US10621981B2 (en) | 2017-09-28 | 2020-04-14 | Sonos, Inc. | Tone interference cancellation |
US10692518B2 (en) | 2018-09-29 | 2020-06-23 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection via multiple network microphone devices |
US10699711B2 (en) | 2016-07-15 | 2020-06-30 | Sonos, Inc. | Voice detection by multiple devices |
US10714115B2 (en) | 2016-06-09 | 2020-07-14 | Sonos, Inc. | Dynamic player selection for audio signal processing |
US10743101B2 (en) | 2016-02-22 | 2020-08-11 | Sonos, Inc. | Content mixing |
US10847178B2 (en) | 2018-05-18 | 2020-11-24 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection |
US10847143B2 (en) | 2016-02-22 | 2020-11-24 | Sonos, Inc. | Voice control of a media playback system |
US10871943B1 (en) | 2019-07-31 | 2020-12-22 | Sonos, Inc. | Noise classification for event detection |
US10873819B2 (en) | 2016-09-30 | 2020-12-22 | Sonos, Inc. | Orientation-based playback device microphone selection |
US10880644B1 (en) | 2017-09-28 | 2020-12-29 | Sonos, Inc. | Three-dimensional beam forming with a microphone array |
US10878811B2 (en) | 2018-09-14 | 2020-12-29 | Sonos, Inc. | Networked devices, systems, and methods for intelligently deactivating wake-word engines |
US10880650B2 (en) | 2017-12-10 | 2020-12-29 | Sonos, Inc. | Network microphone devices with automatic do not disturb actuation capabilities |
US10891932B2 (en) | 2017-09-28 | 2021-01-12 | Sonos, Inc. | Multi-channel acoustic echo cancellation |
US10959029B2 (en) | 2018-05-25 | 2021-03-23 | Sonos, Inc. | Determining and adapting to changes in microphone performance of playback devices |
US10970035B2 (en) | 2016-02-22 | 2021-04-06 | Sonos, Inc. | Audio response playback |
US11017789B2 (en) | 2017-09-27 | 2021-05-25 | Sonos, Inc. | Robust Short-Time Fourier Transform acoustic echo cancellation during audio playback |
US11024331B2 (en) | 2018-09-21 | 2021-06-01 | Sonos, Inc. | Voice detection optimization using sound metadata |
US11042355B2 (en) | 2016-02-22 | 2021-06-22 | Sonos, Inc. | Handling of loss of pairing between networked devices |
US11076035B2 (en) | 2018-08-28 | 2021-07-27 | Sonos, Inc. | Do not disturb feature for audio notifications |
US11080005B2 (en) | 2017-09-08 | 2021-08-03 | Sonos, Inc. | Dynamic computation of system response volume |
US11100923B2 (en) | 2018-09-28 | 2021-08-24 | Sonos, Inc. | Systems and methods for selective wake word detection using neural network models |
US11120794B2 (en) | 2019-05-03 | 2021-09-14 | Sonos, Inc. | Voice assistant persistence across multiple network microphone devices |
US11132989B2 (en) | 2018-12-13 | 2021-09-28 | Sonos, Inc. | Networked microphone devices, systems, and methods of localized arbitration |
US11138975B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
US11138969B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
US11159880B2 (en) | 2018-12-20 | 2021-10-26 | Sonos, Inc. | Optimization of network microphone devices using noise classification |
US11175880B2 (en) | 2018-05-10 | 2021-11-16 | Sonos, Inc. | Systems and methods for voice-assisted media content selection |
US11184969B2 (en) | 2016-07-15 | 2021-11-23 | Sonos, Inc. | Contextualization of voice inputs |
US11183181B2 (en) | 2017-03-27 | 2021-11-23 | Sonos, Inc. | Systems and methods of multiple voice services |
US11183183B2 (en) | 2018-12-07 | 2021-11-23 | Sonos, Inc. | Systems and methods of operating media playback systems having multiple voice assistant services |
US11189286B2 (en) | 2019-10-22 | 2021-11-30 | Sonos, Inc. | VAS toggle based on device orientation |
US11197096B2 (en) | 2018-06-28 | 2021-12-07 | Sonos, Inc. | Systems and methods for associating playback devices with voice assistant services |
US11200889B2 (en) | 2018-11-15 | 2021-12-14 | Sonos, Inc. | Dilated convolutions and gating for efficient keyword spotting |
US11200894B2 (en) | 2019-06-12 | 2021-12-14 | Sonos, Inc. | Network microphone device with command keyword eventing |
US11200900B2 (en) | 2019-12-20 | 2021-12-14 | Sonos, Inc. | Offline voice control |
US11308962B2 (en) | 2020-05-20 | 2022-04-19 | Sonos, Inc. | Input detection windowing |
US11308958B2 (en) | 2020-02-07 | 2022-04-19 | Sonos, Inc. | Localized wakeword verification |
US11315556B2 (en) | 2019-02-08 | 2022-04-26 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing by transmitting sound data associated with a wake word to an appropriate device for identification |
US11343614B2 (en) | 2018-01-31 | 2022-05-24 | Sonos, Inc. | Device designation of playback and network microphone device arrangements |
US11361756B2 (en) | 2019-06-12 | 2022-06-14 | Sonos, Inc. | Conditional wake word eventing based on environment |
US11380322B2 (en) | 2017-08-07 | 2022-07-05 | Sonos, Inc. | Wake-word detection suppression |
US11405430B2 (en) | 2016-02-22 | 2022-08-02 | Sonos, Inc. | Networked microphone device control |
US11432030B2 (en) | 2018-09-14 | 2022-08-30 | Sonos, Inc. | Networked devices, systems, and methods for associating playback devices based on sound codes |
US11482978B2 (en) | 2018-08-28 | 2022-10-25 | Sonos, Inc. | Audio notifications |
US11482224B2 (en) | 2020-05-20 | 2022-10-25 | Sonos, Inc. | Command keywords with input detection windowing |
US11551700B2 (en) | 2021-01-25 | 2023-01-10 | Sonos, Inc. | Systems and methods for power-efficient keyword detection |
US11556306B2 (en) | 2016-02-22 | 2023-01-17 | Sonos, Inc. | Voice controlled media playback system |
US11556307B2 (en) | 2020-01-31 | 2023-01-17 | Sonos, Inc. | Local voice data processing |
US11562740B2 (en) | 2020-01-07 | 2023-01-24 | Sonos, Inc. | Voice verification for media playback |
US11641559B2 (en) | 2016-09-27 | 2023-05-02 | Sonos, Inc. | Audio playback settings for voice interaction |
US11646023B2 (en) | 2019-02-08 | 2023-05-09 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing |
US11676590B2 (en) | 2017-12-11 | 2023-06-13 | Sonos, Inc. | Home graph |
US11698771B2 (en) | 2020-08-25 | 2023-07-11 | Sonos, Inc. | Vocal guidance engines for playback devices |
US11727919B2 (en) | 2020-05-20 | 2023-08-15 | Sonos, Inc. | Memory allocation for keyword spotting engines |
US11899519B2 (en) | 2018-10-23 | 2024-02-13 | Sonos, Inc. | Multiple stage network microphone device with reduced power consumption and processing load |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150127505A1 (en) * | 2013-10-11 | 2015-05-07 | Capital One Financial Corporation | System and method for generating and transforming data presentation |
US11334314B2 (en) * | 2013-10-25 | 2022-05-17 | Voyetra Turtle Beach, Inc. | Networked gaming headset with automatic social networking |
US9632748B2 (en) * | 2014-06-24 | 2017-04-25 | Google Inc. | Device designation for audio input monitoring |
US11183185B2 (en) | 2019-01-09 | 2021-11-23 | Microsoft Technology Licensing, Llc | Time-based visual targeting for voice commands |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU5220199A (en) * | 1998-07-20 | 2000-02-07 | Signalsoft Corp. | Subscriber delivered location-based services |
US20030060211A1 (en) * | 1999-01-26 | 2003-03-27 | Vincent Chern | Location-based information retrieval system for wireless communication device |
US20020010608A1 (en) * | 1999-10-08 | 2002-01-24 | Scott Faber | System for provding services in real-time overthe internet |
US20020038233A1 (en) * | 2000-06-09 | 2002-03-28 | Dmitry Shubov | System and method for matching professional service providers with consumers |
US7487112B2 (en) * | 2000-06-29 | 2009-02-03 | Barnes Jr Melvin L | System, method, and computer program product for providing location based services and mobile e-commerce |
KR20000058815A (en) * | 2000-06-30 | 2000-10-05 | 박성준 | Service exchanging system and method thereof |
US7437295B2 (en) * | 2001-04-27 | 2008-10-14 | Accenture Llp | Natural language processing for a location-based services system |
US7558744B2 (en) * | 2004-01-23 | 2009-07-07 | Razumov Sergey N | Multimedia terminal for product ordering |
US7702318B2 (en) * | 2005-09-14 | 2010-04-20 | Jumptap, Inc. | Presentation of sponsored content based on mobile transaction event |
RU2008134153A (en) | 2006-01-23 | 2010-02-27 | ЧаЧа Сёрч, Инк. (US) | TARGET ADVERTISEMENTS FOR MOBILE DEVICES |
US20070174258A1 (en) * | 2006-01-23 | 2007-07-26 | Jones Scott A | Targeted mobile device advertisements |
US20080095331A1 (en) * | 2006-10-18 | 2008-04-24 | Prokom Investments S.A. | Systems and methods for interactively accessing networked services using voice communications |
WO2008083172A2 (en) | 2006-12-26 | 2008-07-10 | Voice Signal Technologies, Inc. | Integrated voice search commands for mobile communications devices |
US20080153465A1 (en) * | 2006-12-26 | 2008-06-26 | Voice Signal Technologies, Inc. | Voice search-enabled mobile device |
US7818176B2 (en) * | 2007-02-06 | 2010-10-19 | Voicebox Technologies, Inc. | System and method for selecting and presenting advertisements based on natural language processing of voice-based input |
US8843107B2 (en) * | 2007-02-08 | 2014-09-23 | Yp Interactive Llc | Methods and apparatuses to connect users of mobile devices to advertisers |
US20120150657A1 (en) | 2010-12-14 | 2012-06-14 | Microsoft Corporation | Enabling Advertisers to Bid on Abstract Objects |
US20120158502A1 (en) * | 2010-12-17 | 2012-06-21 | Microsoft Corporation | Prioritizing advertisements based on user engagement |
JP5960796B2 (en) * | 2011-03-29 | 2016-08-02 | クアルコム,インコーポレイテッド | Modular mobile connected pico projector for local multi-user collaboration |
US20140012574A1 (en) * | 2012-06-21 | 2014-01-09 | Maluuba Inc. | Interactive timeline for presenting and organizing tasks |
-
2013
- 2013-07-25 US US13/950,503 patent/US9666187B1/en active Active
-
2017
- 2017-04-30 US US15/582,759 patent/US20170236515A1/en not_active Abandoned
Cited By (124)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11042355B2 (en) | 2016-02-22 | 2021-06-22 | Sonos, Inc. | Handling of loss of pairing between networked devices |
US10847143B2 (en) | 2016-02-22 | 2020-11-24 | Sonos, Inc. | Voice control of a media playback system |
US11137979B2 (en) | 2016-02-22 | 2021-10-05 | Sonos, Inc. | Metadata exchange involving a networked playback system and a networked microphone system |
US11405430B2 (en) | 2016-02-22 | 2022-08-02 | Sonos, Inc. | Networked microphone device control |
US11556306B2 (en) | 2016-02-22 | 2023-01-17 | Sonos, Inc. | Voice controlled media playback system |
US11212612B2 (en) | 2016-02-22 | 2021-12-28 | Sonos, Inc. | Voice control of a media playback system |
US11006214B2 (en) | 2016-02-22 | 2021-05-11 | Sonos, Inc. | Default playback device designation |
US11184704B2 (en) | 2016-02-22 | 2021-11-23 | Sonos, Inc. | Music service selection |
US10970035B2 (en) | 2016-02-22 | 2021-04-06 | Sonos, Inc. | Audio response playback |
US11513763B2 (en) | 2016-02-22 | 2022-11-29 | Sonos, Inc. | Audio response playback |
US11750969B2 (en) | 2016-02-22 | 2023-09-05 | Sonos, Inc. | Default playback device designation |
US11863593B2 (en) | 2016-02-22 | 2024-01-02 | Sonos, Inc. | Networked microphone device control |
US10971139B2 (en) | 2016-02-22 | 2021-04-06 | Sonos, Inc. | Voice control of a media playback system |
US10743101B2 (en) | 2016-02-22 | 2020-08-11 | Sonos, Inc. | Content mixing |
US10764679B2 (en) | 2016-02-22 | 2020-09-01 | Sonos, Inc. | Voice control of a media playback system |
US11832068B2 (en) | 2016-02-22 | 2023-11-28 | Sonos, Inc. | Music service selection |
US11736860B2 (en) | 2016-02-22 | 2023-08-22 | Sonos, Inc. | Voice control of a media playback system |
US11514898B2 (en) | 2016-02-22 | 2022-11-29 | Sonos, Inc. | Voice control of a media playback system |
US11726742B2 (en) | 2016-02-22 | 2023-08-15 | Sonos, Inc. | Handling of loss of pairing between networked devices |
US10714115B2 (en) | 2016-06-09 | 2020-07-14 | Sonos, Inc. | Dynamic player selection for audio signal processing |
US11133018B2 (en) | 2016-06-09 | 2021-09-28 | Sonos, Inc. | Dynamic player selection for audio signal processing |
US11545169B2 (en) | 2016-06-09 | 2023-01-03 | Sonos, Inc. | Dynamic player selection for audio signal processing |
US10699711B2 (en) | 2016-07-15 | 2020-06-30 | Sonos, Inc. | Voice detection by multiple devices |
US11184969B2 (en) | 2016-07-15 | 2021-11-23 | Sonos, Inc. | Contextualization of voice inputs |
US11664023B2 (en) | 2016-07-15 | 2023-05-30 | Sonos, Inc. | Voice detection by multiple devices |
US10847164B2 (en) | 2016-08-05 | 2020-11-24 | Sonos, Inc. | Playback device supporting concurrent voice assistants |
US10565998B2 (en) | 2016-08-05 | 2020-02-18 | Sonos, Inc. | Playback device supporting concurrent voice assistant services |
US10565999B2 (en) | 2016-08-05 | 2020-02-18 | Sonos, Inc. | Playback device supporting concurrent voice assistant services |
US11531520B2 (en) | 2016-08-05 | 2022-12-20 | Sonos, Inc. | Playback device supporting concurrent voice assistants |
US20180061420A1 (en) * | 2016-08-31 | 2018-03-01 | Bose Corporation | Accessing multiple virtual personal assistants (vpa) from a single device |
US10186270B2 (en) * | 2016-08-31 | 2019-01-22 | Bose Corporation | Accessing multiple virtual personal assistants (VPA) from a single device |
US10685656B2 (en) | 2016-08-31 | 2020-06-16 | Bose Corporation | Accessing multiple virtual personal assistants (VPA) from a single device |
US11641559B2 (en) | 2016-09-27 | 2023-05-02 | Sonos, Inc. | Audio playback settings for voice interaction |
US11516610B2 (en) | 2016-09-30 | 2022-11-29 | Sonos, Inc. | Orientation-based playback device microphone selection |
US10873819B2 (en) | 2016-09-30 | 2020-12-22 | Sonos, Inc. | Orientation-based playback device microphone selection |
US11308961B2 (en) | 2016-10-19 | 2022-04-19 | Sonos, Inc. | Arbitration-based voice recognition |
US10614807B2 (en) | 2016-10-19 | 2020-04-07 | Sonos, Inc. | Arbitration-based voice recognition |
US11727933B2 (en) | 2016-10-19 | 2023-08-15 | Sonos, Inc. | Arbitration-based voice recognition |
US11183181B2 (en) | 2017-03-27 | 2021-11-23 | Sonos, Inc. | Systems and methods of multiple voice services |
US11900937B2 (en) | 2017-08-07 | 2024-02-13 | Sonos, Inc. | Wake-word detection suppression |
US11380322B2 (en) | 2017-08-07 | 2022-07-05 | Sonos, Inc. | Wake-word detection suppression |
US11080005B2 (en) | 2017-09-08 | 2021-08-03 | Sonos, Inc. | Dynamic computation of system response volume |
US11500611B2 (en) | 2017-09-08 | 2022-11-15 | Sonos, Inc. | Dynamic computation of system response volume |
US11017789B2 (en) | 2017-09-27 | 2021-05-25 | Sonos, Inc. | Robust Short-Time Fourier Transform acoustic echo cancellation during audio playback |
US11646045B2 (en) | 2017-09-27 | 2023-05-09 | Sonos, Inc. | Robust short-time fourier transform acoustic echo cancellation during audio playback |
US11302326B2 (en) | 2017-09-28 | 2022-04-12 | Sonos, Inc. | Tone interference cancellation |
US10891932B2 (en) | 2017-09-28 | 2021-01-12 | Sonos, Inc. | Multi-channel acoustic echo cancellation |
US11538451B2 (en) | 2017-09-28 | 2022-12-27 | Sonos, Inc. | Multi-channel acoustic echo cancellation |
US10880644B1 (en) | 2017-09-28 | 2020-12-29 | Sonos, Inc. | Three-dimensional beam forming with a microphone array |
US11769505B2 (en) | 2017-09-28 | 2023-09-26 | Sonos, Inc. | Echo of tone interferance cancellation using two acoustic echo cancellers |
US10621981B2 (en) | 2017-09-28 | 2020-04-14 | Sonos, Inc. | Tone interference cancellation |
US11288039B2 (en) | 2017-09-29 | 2022-03-29 | Sonos, Inc. | Media playback system with concurrent voice assistance |
US11175888B2 (en) | 2017-09-29 | 2021-11-16 | Sonos, Inc. | Media playback system with concurrent voice assistance |
US10606555B1 (en) | 2017-09-29 | 2020-03-31 | Sonos, Inc. | Media playback system with concurrent voice assistance |
US11893308B2 (en) | 2017-09-29 | 2024-02-06 | Sonos, Inc. | Media playback system with concurrent voice assistance |
US11451908B2 (en) | 2017-12-10 | 2022-09-20 | Sonos, Inc. | Network microphone devices with automatic do not disturb actuation capabilities |
US10880650B2 (en) | 2017-12-10 | 2020-12-29 | Sonos, Inc. | Network microphone devices with automatic do not disturb actuation capabilities |
US11676590B2 (en) | 2017-12-11 | 2023-06-13 | Sonos, Inc. | Home graph |
US11689858B2 (en) | 2018-01-31 | 2023-06-27 | Sonos, Inc. | Device designation of playback and network microphone device arrangements |
US11343614B2 (en) | 2018-01-31 | 2022-05-24 | Sonos, Inc. | Device designation of playback and network microphone device arrangements |
US11797263B2 (en) | 2018-05-10 | 2023-10-24 | Sonos, Inc. | Systems and methods for voice-assisted media content selection |
US11175880B2 (en) | 2018-05-10 | 2021-11-16 | Sonos, Inc. | Systems and methods for voice-assisted media content selection |
US10847178B2 (en) | 2018-05-18 | 2020-11-24 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection |
US11715489B2 (en) | 2018-05-18 | 2023-08-01 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection |
US11792590B2 (en) | 2018-05-25 | 2023-10-17 | Sonos, Inc. | Determining and adapting to changes in microphone performance of playback devices |
US10959029B2 (en) | 2018-05-25 | 2021-03-23 | Sonos, Inc. | Determining and adapting to changes in microphone performance of playback devices |
US11696074B2 (en) | 2018-06-28 | 2023-07-04 | Sonos, Inc. | Systems and methods for associating playback devices with voice assistant services |
US11197096B2 (en) | 2018-06-28 | 2021-12-07 | Sonos, Inc. | Systems and methods for associating playback devices with voice assistant services |
US11563842B2 (en) | 2018-08-28 | 2023-01-24 | Sonos, Inc. | Do not disturb feature for audio notifications |
US11482978B2 (en) | 2018-08-28 | 2022-10-25 | Sonos, Inc. | Audio notifications |
US11076035B2 (en) | 2018-08-28 | 2021-07-27 | Sonos, Inc. | Do not disturb feature for audio notifications |
US11432030B2 (en) | 2018-09-14 | 2022-08-30 | Sonos, Inc. | Networked devices, systems, and methods for associating playback devices based on sound codes |
US10878811B2 (en) | 2018-09-14 | 2020-12-29 | Sonos, Inc. | Networked devices, systems, and methods for intelligently deactivating wake-word engines |
US11551690B2 (en) | 2018-09-14 | 2023-01-10 | Sonos, Inc. | Networked devices, systems, and methods for intelligently deactivating wake-word engines |
US11778259B2 (en) | 2018-09-14 | 2023-10-03 | Sonos, Inc. | Networked devices, systems and methods for associating playback devices based on sound codes |
US11024331B2 (en) | 2018-09-21 | 2021-06-01 | Sonos, Inc. | Voice detection optimization using sound metadata |
US11790937B2 (en) | 2018-09-21 | 2023-10-17 | Sonos, Inc. | Voice detection optimization using sound metadata |
US11031014B2 (en) | 2018-09-25 | 2021-06-08 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
US10573321B1 (en) | 2018-09-25 | 2020-02-25 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
US11727936B2 (en) | 2018-09-25 | 2023-08-15 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
US10811015B2 (en) | 2018-09-25 | 2020-10-20 | Sonos, Inc. | Voice detection optimization based on selected voice assistant service |
US11100923B2 (en) | 2018-09-28 | 2021-08-24 | Sonos, Inc. | Systems and methods for selective wake word detection using neural network models |
US11790911B2 (en) | 2018-09-28 | 2023-10-17 | Sonos, Inc. | Systems and methods for selective wake word detection using neural network models |
US10692518B2 (en) | 2018-09-29 | 2020-06-23 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection via multiple network microphone devices |
US11501795B2 (en) | 2018-09-29 | 2022-11-15 | Sonos, Inc. | Linear filtering for noise-suppressed speech detection via multiple network microphone devices |
US11899519B2 (en) | 2018-10-23 | 2024-02-13 | Sonos, Inc. | Multiple stage network microphone device with reduced power consumption and processing load |
US11200889B2 (en) | 2018-11-15 | 2021-12-14 | Sonos, Inc. | Dilated convolutions and gating for efficient keyword spotting |
US11741948B2 (en) | 2018-11-15 | 2023-08-29 | Sonos Vox France Sas | Dilated convolutions and gating for efficient keyword spotting |
US11557294B2 (en) | 2018-12-07 | 2023-01-17 | Sonos, Inc. | Systems and methods of operating media playback systems having multiple voice assistant services |
US11183183B2 (en) | 2018-12-07 | 2021-11-23 | Sonos, Inc. | Systems and methods of operating media playback systems having multiple voice assistant services |
US11538460B2 (en) | 2018-12-13 | 2022-12-27 | Sonos, Inc. | Networked microphone devices, systems, and methods of localized arbitration |
US11132989B2 (en) | 2018-12-13 | 2021-09-28 | Sonos, Inc. | Networked microphone devices, systems, and methods of localized arbitration |
US11540047B2 (en) | 2018-12-20 | 2022-12-27 | Sonos, Inc. | Optimization of network microphone devices using noise classification |
US11159880B2 (en) | 2018-12-20 | 2021-10-26 | Sonos, Inc. | Optimization of network microphone devices using noise classification |
US11315556B2 (en) | 2019-02-08 | 2022-04-26 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing by transmitting sound data associated with a wake word to an appropriate device for identification |
US11646023B2 (en) | 2019-02-08 | 2023-05-09 | Sonos, Inc. | Devices, systems, and methods for distributed voice processing |
US11798553B2 (en) | 2019-05-03 | 2023-10-24 | Sonos, Inc. | Voice assistant persistence across multiple network microphone devices |
US11120794B2 (en) | 2019-05-03 | 2021-09-14 | Sonos, Inc. | Voice assistant persistence across multiple network microphone devices |
US11854547B2 (en) | 2019-06-12 | 2023-12-26 | Sonos, Inc. | Network microphone device with command keyword eventing |
US11200894B2 (en) | 2019-06-12 | 2021-12-14 | Sonos, Inc. | Network microphone device with command keyword eventing |
US11501773B2 (en) | 2019-06-12 | 2022-11-15 | Sonos, Inc. | Network microphone device with command keyword conditioning |
US10586540B1 (en) | 2019-06-12 | 2020-03-10 | Sonos, Inc. | Network microphone device with command keyword conditioning |
US11361756B2 (en) | 2019-06-12 | 2022-06-14 | Sonos, Inc. | Conditional wake word eventing based on environment |
US11138975B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
US11551669B2 (en) | 2019-07-31 | 2023-01-10 | Sonos, Inc. | Locally distributed keyword detection |
US11138969B2 (en) | 2019-07-31 | 2021-10-05 | Sonos, Inc. | Locally distributed keyword detection |
US11714600B2 (en) | 2019-07-31 | 2023-08-01 | Sonos, Inc. | Noise classification for event detection |
US11710487B2 (en) | 2019-07-31 | 2023-07-25 | Sonos, Inc. | Locally distributed keyword detection |
US10871943B1 (en) | 2019-07-31 | 2020-12-22 | Sonos, Inc. | Noise classification for event detection |
US11354092B2 (en) | 2019-07-31 | 2022-06-07 | Sonos, Inc. | Noise classification for event detection |
US11862161B2 (en) | 2019-10-22 | 2024-01-02 | Sonos, Inc. | VAS toggle based on device orientation |
US11189286B2 (en) | 2019-10-22 | 2021-11-30 | Sonos, Inc. | VAS toggle based on device orientation |
US11869503B2 (en) | 2019-12-20 | 2024-01-09 | Sonos, Inc. | Offline voice control |
US11200900B2 (en) | 2019-12-20 | 2021-12-14 | Sonos, Inc. | Offline voice control |
US11562740B2 (en) | 2020-01-07 | 2023-01-24 | Sonos, Inc. | Voice verification for media playback |
US11556307B2 (en) | 2020-01-31 | 2023-01-17 | Sonos, Inc. | Local voice data processing |
US11308958B2 (en) | 2020-02-07 | 2022-04-19 | Sonos, Inc. | Localized wakeword verification |
US11961519B2 (en) | 2020-02-07 | 2024-04-16 | Sonos, Inc. | Localized wakeword verification |
US11694689B2 (en) | 2020-05-20 | 2023-07-04 | Sonos, Inc. | Input detection windowing |
US11727919B2 (en) | 2020-05-20 | 2023-08-15 | Sonos, Inc. | Memory allocation for keyword spotting engines |
US11482224B2 (en) | 2020-05-20 | 2022-10-25 | Sonos, Inc. | Command keywords with input detection windowing |
US11308962B2 (en) | 2020-05-20 | 2022-04-19 | Sonos, Inc. | Input detection windowing |
US11698771B2 (en) | 2020-08-25 | 2023-07-11 | Sonos, Inc. | Vocal guidance engines for playback devices |
US11551700B2 (en) | 2021-01-25 | 2023-01-10 | Sonos, Inc. | Systems and methods for power-efficient keyword detection |
Also Published As
Publication number | Publication date |
---|---|
US9666187B1 (en) | 2017-05-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9666187B1 (en) | Model for enabling service providers to address voice-activated commands | |
US10319382B2 (en) | Multi-level voice menu | |
US9368113B2 (en) | Voice activated features on multi-level voice menu | |
US9798517B2 (en) | Tap to initiate a next action for user requests | |
US10114466B2 (en) | Methods and systems for hands-free browsing in a wearable computing device | |
US20150278737A1 (en) | Automatic Calendar Event Generation with Structured Data from Free-Form Speech | |
US9176582B1 (en) | Input system | |
US9507426B2 (en) | Using the Z-axis in user interfaces for head mountable displays | |
US8223088B1 (en) | Multimode input field for a head-mounted display | |
US9456284B2 (en) | Dual-element MEMS microphone for mechanical vibration noise cancellation | |
US9448687B1 (en) | Zoomable/translatable browser interface for a head mounted device | |
US9100732B1 (en) | Hertzian dipole headphone speaker | |
US9541996B1 (en) | Image-recognition based game | |
US9547175B2 (en) | Adaptive piezoelectric array for bone conduction receiver in wearable computers | |
US9336779B1 (en) | Dynamic image-based voice entry of unlock sequence | |
US10559024B1 (en) | Voice initiated purchase request | |
US20170115736A1 (en) | Photo-Based Unlock Patterns | |
US11914835B2 (en) | Method for displaying user interface and electronic device therefor | |
US20150130688A1 (en) | Utilizing External Devices to Offload Text Entry on a Head Mountable Device | |
US8893247B1 (en) | Dynamic transmission of user information to trusted contacts | |
US9367613B1 (en) | Song identification trigger | |
US20170139567A1 (en) | Entering Unlock Sequences Using Head Movements | |
US9305064B1 (en) | Keyword-based conversational searching using voice commands | |
US20160299641A1 (en) | User Interface for Social Interactions on a Head-Mountable Display | |
US9418617B1 (en) | Methods and systems for receiving input controls |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GOOGLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PINSKY, YURY;LEE, STEVEN JOHN;BALEZ, MAT;AND OTHERS;SIGNING DATES FROM 20130719 TO 20130725;REEL/FRAME:042188/0879 |
|
AS | Assignment |
Owner name: GOOGLE LLC, CALIFORNIA Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044129/0001 Effective date: 20170929 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |