WIRELESS HANDSFREE HEADSET METHOD AND SYSTEM WITH HANDSFREE APPLICATIONS
Embodiments include method for providing a handsfree service to a user of a wireless, handsfree headset. In an embodiment the method comprises the headset performing service discovery on the audio gateway to determine a method of transferring an application to the audio gateway, wherein the application provides the service, the headset causing the application to be transferred to the audio gateway using a method based on the service discovery; and the audio gateway executing the application, wherein this user issues voice commands that are executed by the audio gateway to provide the service.
This application is a continuation of U.S. Nonprovisional patent application Ser. No. 13/246,617, filed Sep. 27, 2011, entitled “Wireless Handsfree Headset Method and System with Handsfree Applications,” which is a continuation of U.S. Nonprovisional patent application Ser. No. 12/039,718, filed Feb. 28, 2008, entitled “Wireless Handsfree Headset Method and System with Handsfree Applications,” all of which are incorporated by reference herein in their entirety for all purposes.TECHNICAL FIELD
Embodiments described herein are related to sophisticated wireless headsets that include various software applications and communication technologies.BACKGROUND
Wireless headsets enhance the experience of the mobile communication device user by allowing handsfree operation. Mobile communication devices can include cellular or satellite phones, personal data assistants (PDA's) with cellular phone capabilities or any other devices using known wireless communication networks. Mobile communication devices will be referred to herein collectively as mobile phones. Wireless headsets allow mobile phone users to talk handsfree once a call is initiated. Typical wireless headsets are controlled by an audio gateway, such as a mobile phone or personal computer (PC). The wireless headset abides by the rules and limitations defined by the software of the audio gateway. The audio gateway is the unit in communication with the wireless communication network being used. Applications available over the network must be accessed using the audio gateway, typically by establishing a connection via the network by using a physical interface of the audio gateway. Once a connection to the application is established, the wireless headset can be used to communicate with the application. This has limitations in that it is a multi-step process to access applications and then interact with them using the wireless headset. It would be desirable to have a headset that includes interfaces to the audio gateway allowing control of data and translation of data to an audio stream that is sent to the headset and heard by the user. It would be desirable to have such a headset that did not require a physical interface to issue commands and receive audio and visual feedback.
An example of the operation of the system 800 will now be described with reference to the circled numbers and arrows in the diagram. As shown at 1, a voice command is issued from a headset 806 through a voice gateway to a communications network 808. The voice gateway can either be located on a network 808 or included in a wired or wireless headset 806. A voice gateway may support digitized voice, VoIP or traditional voice services. A voice or data gateway may be comprised of a PC, WiFi Access Point, Cellular phone, Wireless home phone, etc.
Referring to 1a, 1b, and 1c, if the voice command is co-processed by a network 808-based service it may be transported through the Internet or directly to a service of the proprietary network 812. If the service is a voice-based service, voice is returned to the user. An example is a request for streaming music from a back-end library, a music library located in the home, etc.
Another example is a voice-based messaging service. If the voice command is a request for data (from either a back-end service or a service on a co-located network) a data path is established through a data gateway. The data gateway may be included as part of a voice gateway or a separate entity such as a WiFi Access point.
Referring to 2a, 2c, and 2d, a data command is delivered to a back-end server. The data command could be a request for an application or other service. Data commands are not limited to any standard based protocol and may be a proprietary protocol. This includes using the platform to install a protocol that can run over Bluetooth as only a transport, or a standard protocol such as SMS, HTTP, WAP Push, etc. The service could be provided through the Internet 810 or directly to the proprietary network 812.
Referring to 2b, 2e, and 2f, the requested service is returned to the headset 806 through the data network (e.g., the Internet 801 or the proprietary network 812 directly). A data service may be any service that could reside on the headset 806, voice gateway, data gateway, or any other device such as a DVR. The service may also be a service that is shared between the headset 806 and the audio or data gateway, such as headset configuration management or service management. A shared service can be any service that is shared or allows voice-driven command and control of the headset 806 or other device including the voice or data gateway, or home services such as music players, DVRs etc.
The data service can be delivered any device that requires command/control. This could include an applet on the headset 806 alone (such as a voice-driven interface where different languages are requested, a streaming music interface, or to remotely program a DVR, etc). Alternatively an application can be installed on a device to allow the device to directly accept voice-driven commands from the headset 806 or to provide a shared service between the headset 806 and the device (such as using the device to control headset feature and visa-versa).
When wireless communications networks 808 are used, such as the cellular network that may be subject to signal fade, packet or signal loss, a shared service between the headset 806 and the voice or data gateway may be used to buffer the requests and send them as the network 808 becomes available. The headsets 806 can be connected to a voice or data gateway either directly or through a wired interface. Where wireless headsets 806 are used it is assumed that they support multi-pairing or multidevice connection when interfacing with more than one data or voice gateway.
A wired headset 806 may include a handset that is equipped with the data management platform 802. In an embodiment the headset 806 is equipped with a proprietary noise suppression service developed by Aliph, Inc. Aliph's proprietary microphones and Noise Suppression techniques make voice-based services possible in headsets, while other noise suppression headsets have too much voice signal degradation to support such services.
Embodiments described herein include a wireless headset with software application stored in memory. In one embodiment, the wireless headset sends data to an audio gateway for the purpose of retrieving an application to provide the headset with a control schema/interface that normally would not be provided. The headset is provided with interfaces to the audio gateway allowing it to control the access of data and translate it back to an audio stream that is sent to the headset and heard by the user. A physical interface is not required to issue commands and receive feedback. Voice is used to command, control, and navigate functionalities of the headset's server application (on an audio gateway). The audio gateway's headset-server suite processes voice data in order to receive an instruction set (e.g., an application or metadata) from the headset, retrieve the data requested from an external source, and communicate requested data over wireless audio channel(s) to the user.
A wireless, handsfree headset uses two input sources for control. One of the inputs (e.g. physical interaction or press) requires one to use one's hands to physically interact with headset (located on the ear). Another input (e.g. voice) requires one to speak into the microphone of the headset to accomplish tasks or actions. In an embodiment, to eliminate physical interaction, the headset transfers compatible, feature-rich software to the audio gateway so that voice may be used to issue commands for controlling the software that will in turn control the audio gateway.
An aspect of embodiment is a methodology for enabling wireless binary install operations to and from a wireless headset. The wireless headset uses a transport medium such as Bluetooth wireless technology to setup connections for sending and receiving data. The data includes binary, compiled data that can be executed on the audio gateway. The headset acts as a control point when interfacing with other devices such as a mobile cellular phone or a computer. The control point enables the user to create and customize their mobile communication experience by wireless application download service or over-the-air data transfer.
In an embodiment the headset uses Bluetooth wireless technology, and uses data transfer profiles for data exchange from headset to audio gateway, and for controlling the audio gateway. These profiles can be either Object Push Profile (OPP), File Transfer Profile (FTP), Human Interface Device Profile (HID), Personal Area Networking Profile (PAN), and Wireless Application Protocol Bearer (WAPB) Profile. Voice is carried via Hands-Free and Headset Profiles (HFP and HSP). Once both devices are bonded and paired, data and voice channels are both opened concurrently.
In an embodiment the headset uses a wireless transport (e.g. Bluetooth) to discover services, and uses the appropriate negotiation or profile to communicate data and receive capabilities from the audio gateway. The headset stores the capabilities of the audio gateway and continuously “learns” about the device's characteristics and specifications through the application (referred to herein as the server application or the client application) that is loaded on the audio gateway.
Once the server application is loaded on the audio gateway, the audio gateway behaves as a wireless, ultra-portable modem that is in constant data exchange and communication with its primary client, the headset. The headset uses voice commands for control of the audio gateway (via server applet, for example). The application parses and processes the voice commands. Once processed, the voice command is answered with the requesting information, or confirmed (e.g., audio is sent back to headset).
For example a mobile phone goes to the gateway and causes the gateway to act on commands to execute applications such as giving directions, finding a business, etc. One aspect is that the application is always present. As soon as the user speaks, the process of executing the application and communicating with the gateway to provide the service is initiated. A user can be driving and using the headset on which the application is already loaded. When the user says “directions”, a confirmation is received and a response such as “where do you want to go?” The user can then state an address, and in return receive a message (or atone) “the directions are here”. The user can then say “begin”, and a first direction is given to the user. The user can prompt the application for further directions by stating “next”. The application acts on key words to provide directions without the user needing to look at the phone at all. In an embodiment, once the application has the address, the directions are acquired by the application from a network (typically the Internet). Acquiring driving directions is just one example of a service that can be delivered in this manner.
In further embodiments described herein, the connected devices are audio gateways, but the invention is not so limited. Audio gateways 106 include personal computers (PCs), mobile phones, or any other devices capable of wireless communication via the known networks and protocols. For example, the application is sent to the gateway using Bluetooth, and service discovery is performed by the headset to determine which protocols are supported, whether the client can actually receive an application, and so on. The headset is thus enabled to gain control of the client audio gateway. For example, the headset 102 may not have a Bluetooth profile to accept applications, but is able to accept text over Bluetooth. The application can be sent via Bluetooth transports. Within Bluetooth transports are multiple protocols. For the case shown, an OBEX protocol (which is an object push profile or OPP) can be used. File transfer protocol (FTP) could also be used.
In an embodiment, one or more of the audio gateways 106 includes improved noise cancellation capability. Inferior audio quality has hampered voice dialing and other voice services in the past. In an embodiment, improved audio quality is coupled with management of voice service requests in an asynchronous manner. For example, small voice requests are stored on the device 106 for delivery at the best possible time (and visa-versa in the network). This reduces packet loss and connection loss when the voice services do not need immediate attention.
Once the application 104 is stored on an audio gateway 106, it is executed on the audio gateway 106. Audio gateways 106 are also referred to as clients of the headset. The application 104 typically provides a service, so it is assumed that the audio gateway 106 has some connection to the Internet, as shown in
Once the application 104 has established an Internet connection, the audio gateway 106 can reestablish its connection with the headset 102. Once the headset 102 is aware the connection has been reestablished, it assumes that the connection is successful. At this point the headset 102 is in complete control of the audio gateway 106. For example, the headset 102 user issues a voice direction, which can be a command such as a request for directions, a request for a notepad, an inquiry (such as where is a Chinese restaurant within 10 miles?) or anything that requires the audio gateway 106 to the access the Internet and to provide some sort of service through the headset 102.
As shown in
The AT command is sent to the audio gateway 106 and the audio gateway 106 sends the message via a cellular network 118. For example the message may be a URL 120 for an application. The audio gateway 106 sends the text message to a predefined number and the URL 120 for the application is actually a reply from the gateway 116 to the audio gateway 106. The application 104 is then sent via the Internet 108 to the audio gateway 106 (
At this point, one of two processes follows. One process is shown at 416 and 418, where voice commands sent by the headset are interpreted by the application on the audio gateway. For example the commands can include commands to get directions, take down notes, find a business, or anything else that can be communicated to the gateway with a key word that the gateway can act on. In response, the audio gateway sends the requested service in the form of an audio stream to the headset.
Another process is shown at 420, where the application is used to configure the headset. For example, this process can be executed when a user initializes a new headset, in which case an application can customize the headset for language, ringtone, audio tone, etc.
The elements of the headset 502 also include an analog to digital converter (ADC) 506 that includes the SSM, a PCM bus and an I2C bus.
A memory management unit (MMU) 516 communicates with a memory interface 510. The memory interface 510 includes flash memory, and ROM memory. In an embodiment, the ROM memory stores the headset applications 512 as previously described herein. The applications 512 communicate with one or more of the profiles 612 as shown and described with reference to
A programmable input/output (PIO) module 514 includes light emitting diodes (LEDs) on the headset that are controlled or programmed by the by PIO pins. Analog 10 access (AIO) and general purpose 10 (OPIO) are also provided.
A Bluetooth stack 610 that is proprietary to the headset includes an LCAP module 614, an radio frequency communication (RFCOMM) module 616, and profiles 612. The profiles are used in the various use cases as illustrated in
Flash interface 618 is an interface with Flash ROM 620. Flash Rom 620 is where the data to be sent by the headset to gateways or clients is stored. The data includes application 622, metadata 624 and headset data 626.
At the bottom of the architecture 600 is headset application 628. Applications may be “built into the headset” or downloaded to the headset. For example, application can be a set of applications that are downloaded and flashed into the flash ROM of the device. Application 628 may be a pre-installed application in the headset that can leverage the data, metadata or other information that is stored in the flash ROM, including using application 622 to perform its function. An example of this may be a voice recognition application that is pre-installed in the headset, where the application in flash ROM may be extended grammar that can invoke some new function. For example, a function can be added such that a user says “CNN”. The grammar to recognize “CCN” may be downloaded over the air to the headset along with the data needed to invoke a data or voice call that results in returning the CCN headlines.
Each of the steps depicted in the flow diagrams presented herein can itself include a sequence of operations that need not be described herein. Those skilled in the relevant art can create routines, algorithms, source code, microcode, program logic arrays or otherwise implement the invention based on the flow diagrams and the detailed description provided herein. The routines described herein can be provided with one or more of the following, or one or more combinations of the following: stored in nonvolatile memory (not shown) that forms part of an associated processor or processors, or implemented using conventional programmed logic arrays or circuit elements, or stored in removable media such as disks, or downloaded from a server and stored locally at a client, or hardwired or preprogrammed in chips such as EEPROM semiconductor chips, application specific integrated circuits (ASICs), or by digital signal processing (DSP) integrated circuits.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application.
The above description of illustrated embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. The teachings of the invention provided herein can be applied to other headset systems, not only for the headset system described above. Further, the elements and acts of the various embodiments described above can be combined to provide further embodiments.
Various changes can be made to the invention in light of the above detailed description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include all speech signal systems that operate under the claims to provide a method for procurement. Accordingly, the invention is not limited by the disclosure, but instead the scope of the invention is to be determined entirely by the claims.
While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. Thus, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.
1. A wireless, hands free headset comprising:
- communications hardware and software for wireless communication via at least one connected device; and
- a memory device that stores an application, the application configurable to provide a service to a user of the headset, wherein the headset is configurable to communicate with an connected device to determine services available on the connected device, and to cause the application to be installed on the connected device by one of multiple methods chosen based on the services available.
International Classification: H04M 1/60 (20060101);