Patent Description:
Various virtual personal assistants (VPAs) (also referred to as intelligent personal assistants (IPAs)) are available on mobile devices and computing devices for providing voice-activated services and controls. Examples of VPAs include), Alexa® (provided by Amazon Inc. of Seattle, WA), Google Assistant® (provided by Google Inc. of Mountain View, CA), S Voice® (provided by Samsung Electronics of Suwon, South Korea), Voice Mate® (provided by LG Electronics of Seoul, South Korea) and Cortana® (provided by Microsoft Inc. of Redmond, WA).

The availability of multiple VPAs on a device is shown in the Internet article "<NPL>) and in <CIT>.

In one aspect, this document features a method for accessing multiple virtual personal assistants, VPAs, the method comprising:.

In another aspect, the document also features a system for accessing multiple virtual personal assistants, VPAs, the system comprising:.

Two or more of the features described in this disclosure, including those described in this summary section, may be combined to form implementations not specifically described herein.

Virtual personal assistants (VPAs) (which may also be referred to as intelligent personal assistants (IPAs) or knowledge navigators) are increasingly being used in mobile devices and other computing devices, for example, to facilitate hands-free interaction with the devices. A VPA can be implemented as an agent application that executes on a particular device (e.g., a computing device or mobile device), and communicates with one or more remote computing devices (e.g., servers) associated with a corresponding VPA service provider to carry out tasks and provide responses and services based on a user input. For example, the agent application can provide at least a portion of the user input (e.g., speech input) to one or more computing devices (e.g., servers) associated with a remote, cloud-based VPA service provider, which then processes the portion of the user input to generate a response. The response is transmitted back to the particular device, which then executes one or more tasks (e.g., generate a display and/or play an audio file) based on the response. The VPA service provider may use information from various other sources (e.g., location information of the particular device, information on weather, news, stock prices etc. as available, for example, from various databases, user information and schedules as available, for example, from a user account, etc.) in generating the response.

VPA service providers typically provide VPA services to corresponding specific devices or applications. For example, various mobile devices have dedicated VPA applications executing on the devices. In some cases, a VPA service provider may provide an application programming interface (API) that may be used to integrate a corresponding VPA into a device. Either way, only one VPA may be available from a particular device. However, with the availability of various VPAs from multiple VPA service providers, a user may be interested in leveraging a choice of VPAs. For example, a user may want to ask for driving directions using a first VPA (e.g., Siri® provided by Apple Inc. of Cupertino, CA), but prefer a second VPA (e.g., Alexa® provided by Amazon Inc. of Seattle, WA) for ordering goods online. The technology described in this document allows for a selecting one of multiple available VPAs (or VPA service providers) from a single device. The selection may be made, for example, based on the presence of one or more keywords in the user-input, via pre-configured user settings, or automatically, e.g., based on the content of the user-input. In some implementations, the selection may be made from personal acoustic devices such as headphones or earphones connected to a source device (e.g., a mobile device, media player, or streaming device), which in turn may allow users to access their favorite VPA services through the personal acoustic devices without having to invest in devices associated with the corresponding VPA services. In some implementations, the technology described herein may also allow users to seamlessly switch between VPA choices based on, for example, preferences associated with different queries and requests. In implementations where the personal acoustic device has one or more built-in communications modules to communicate directly to cloud-based VPA service providers, the source device may not be needed.

<FIG> is a block diagram of an example environment <NUM> in which one or more devices can interact with multiple cloud-based VPA service providers. In the example environment <NUM>, a headphone <NUM> is connected to a mobile device <NUM>, for example, via a wireless connection such as a Bluetooth® connection or Wi-Fi® connection. Also, unless specified otherwise, the term headphone, as used in this document, includes various types of personal acoustic devices such as over-the-ear and in--ear headsets, earphones, earbuds, hearing aids, or other wireless-enabled acoustic devices. Other devices such as a smart watch <NUM>, portable speakers, docking speakers, home theater systems, radios, stereo speakers, or fitness trackers can also be used to communicate with multiple VPA service providers <NUM>. In some implementations, a device that may communicate with multiple cloud-based VPA service providers <NUM> can also include a remote controller <NUM> configured to control a media playing device <NUM>. The media playing device <NUM> can include, for example, a media streaming device, an optical disk player, a home theater receiver, or a speaker device that may be connected to a TV. The technology is described herein primarily using an example of a headphone <NUM> connected to a mobile device <NUM>. However, the description is also applicable to other devices such as the remote controller <NUM>, media playing device <NUM>, smart watch <NUM>, or other devices such as portable speakers, docking speakers, home theater systems, radios, stereo speakers, or fitness trackers. For example, the remote controller <NUM> or smart watch <NUM> can include a microphone configured to receive input speech data and communicate the same to the one or more VPA service providers <NUM> either directly over a network <NUM> or via an intervening device such as the media playing device <NUM> or the mobile device <NUM>, respectively.

The headphones <NUM> and/or mobile device <NUM> can be configured to communicate with one or more computing devices (e.g., servers <NUM>) associated with each of multiple VPA service providers 125a, 125b, and 125c (<NUM>, in general). For example, at least a portion of input speech data (based, for example, on the speech of a user <NUM>) received by the device <NUM>, <NUM>, <NUM> and/or <NUM> may be provided over a network <NUM> to one or more of the VPA service providers <NUM>, which then processes the received portion of the input speech data to generate a response. The portion of the input speech may be packaged into one or more electronic files in accordance with a specification of the particular destination VPA service provider <NUM>. Information representing the response is then transmitted back over the network <NUM> to the mobile device <NUM> and/or the personal acoustic device <NUM>. The information is then processed at the recipient device to generate an output (e.g., an audio clip, or a video display) for the user <NUM>. In some implementations, input speech data can be captured by a microphone at a first acoustic device (e.g., smart watch <NUM>) and the output can be routed to a second acoustic device (e.g., headphone <NUM>).

In some implementations, the input speech data can be captured via a microphone <NUM> of the headphone <NUM>. In some implementations, the microphone <NUM> could be supported by a housing of the headphone (and could be, for example, a feedback or feed-forward microphone associated with active noise reducing circuitry in the headphone). The input speech data may also be captured by a microphone of another device such as the mobile device <NUM> or a smart watch <NUM>. In some implementations, the headphone <NUM> can include a VPA access button that may be activated to trigger the microphone <NUM> to capture speech input data intended for a VPA service provider <NUM>. In some implementations, the microphone <NUM> can be configured to be always listening for one or more keywords indicative of a preferred VPA service provider. For example, if the keywords associated with VPA service provider A 125a are "Hello There," and are detected by the microphone <NUM>, words or phrases following the detected keywords are captured as input speech data intended for the VPA service provider A 125a. Similarly, if the keywords associated with VPA service provider B 125b are "Tell Me," and are detected by the microphone <NUM>, words or phrases following the detected keywords are captured as input speech data intended for the VPA service provider A 125b. In some implementations, these keywords are dictated by the VPA service providers.

In some implementations, the user can customize keywords and/or phrases to be associated with a particular VPA service provider. For example, if a user is interested in using VPA service provider A for directions, the user could configure personal acoustic device <NUM> to recognize a customized keyword and/or phase (e.g., "Give me directions" or "Directions") that would indicate that the input speech data is intended for the VPA service provider A. Similarly, if a user is interested in using VPA service provider B for shopping online, the user could configure personal acoustic device <NUM> to recognize a customized keyword and/or phrase (e.g., "I'd like to shop" or "Shopping") that would indicate that the input speech data is intended for the VPA service provider B. The user could configure these customized keywords and/or phrases via a voice and/or visual user interface (for example the interface shown in <FIG> as described below). The input speech data can then be provided to the connected mobile device <NUM> for processing and subsequent packaging for transmission to a destination VPA service provider <NUM>. This may be done, for example, using an application program executing on the mobile device <NUM> and/or the personal acoustic device. In some implementations, once the microphone <NUM> is triggered to capture the input speech data, the headphone <NUM> may establish a connection (e.g., a wireless connection) with the mobile device <NUM> and start streaming the data captured by the microphone to the application program executing on the mobile device <NUM>. In some implementations, the application may already be executing on the mobile device when the microphone <NUM> is triggered. In some cases, where the application is not already executing, triggering of the microphone <NUM> can cause the application to be launched. In some implementations, launching of the application upon triggering of the microphone <NUM> may require a user-input (e.g., via the mobile device <NUM>) indicative of a permission to launch the application.

The application program can be configured to record the incoming data from the microphone <NUM> substantially continuously until, for example, a gap in speech (which may signify an end of the spoken input) is detected. The application can then be configured to package at least a portion of the recorded audio into one or more electronic files in accordance with specifications of the destination VPA service provider as selected or indicated by the user. For example, the specified file format for VPA service provider A 125a may be. wav, whereas the specified file formats for VPA service providers 125b and 125c are. txt, respectively. In this example, the application can be configured to package portions of the input speech into. mpg files depending on whether the destination VPA service provider is 125a or 125b, respectively. If the destination VPA service provider is 125c, the application can also be configured to perform speech recognition and include portions of the recognized speech within a. txt file, as per specifications for VPA service provider C 125c.

In some implementations, the headphone <NUM> may directly communicate at least a portion of the speech input to a destination VPA service provider <NUM>. For example, if the headphone <NUM> is wireless-enabled (e.g., a Wi-Fi® enabled device having an IP address), the headphone <NUM> may directly transmit a portion of the speech input to a destination VPA service provider <NUM> over the network <NUM>. Similarly, if a remote controller <NUM> is wireless-enabled, the remote controller <NUM> may directly communicate with a VPA service provider <NUM> (e.g., bypassing the corresponding media playing device <NUM>) over the network <NUM>. In such cases, one or more processing devices (e.g., microprocessors, microcontrollers, or digital signal processors) on the headphone <NUM> (or the remote controller <NUM>) can be configured to execute an application program that processes the input speech data in accordance with specifications of the destination VPA service provider <NUM>.

<FIG> shows an example block-diagram of a device <NUM> configured to interact with multiple VPA service providers. Examples of the device <NUM> can include a headphone <NUM>, a smart watch <NUM>, a mobile device <NUM>, or a remote controller <NUM>. In some implementations, the device <NUM> includes one or more microphones <NUM> for capturing input speech and one or more acoustic transducers (e.g., speakers) for generating an acoustic output based on, for example, a response to the input speech data. In some implementations, the device <NUM> includes a display device <NUM> configured to present, for example, one or more user interfaces associated with accessing one of the multiple VPA service providers. For example, the display device <NUM> can be configured to present a user-interface that includes a user-selectable menu of multiple VPA service providers. In some implementations, the display device <NUM> can also be configured to present a user-interface for receiving credentials (e.g., username-password pair) for using a particular VPA service provider. In some implementations, for example where the device <NUM> is tethered (e.g., via a wireless connection) to a mobile device (or another device that includes a display), the device <NUM> may not include the display device <NUM>. In some implementations, for example an in-ear headphone where there is limited space for a display, the one or more acoustic transducers may be used to provide voice prompts to a user, which may act as the user interface for configuring multiple VPA service providers. In some implementations, the microphone <NUM> and/or acoustic transducer <NUM> may be disposed in a separate device. For example, if the device <NUM> is a mobile device, the microphone <NUM> and/or acoustic transducer <NUM> may be disposed in a separate device (e.g., a headphone) connected to the mobile device.

The input speech data captured by the microphone <NUM> (or received from another device) can be processed by the device <NUM> in various ways. In some implementations, at least a portion of the input speech data may be processed locally at the device <NUM> to address one or more requests or queries included within the input speech data. For example, if a portion of the input speech data requests product-based information or control pertaining to the device <NUM>, the portion of the input speech data may be processed and/or addressed locally at the device <NUM> or at a connected device. In some implementations, the device <NUM> can be a mobile device to which an acoustic device (e.g., a headset) is connected. In such cases, input speech data received through a microphone of the headset may be parsed at the mobile device (e.g., using an application executing on the mobile device), and at least a portion of the input speech data may be addressed/processed locally at the mobile device, for example, to control and/or provide information about the acoustic device. Examples of such product based information and control include a query about the battery level of the acoustic device, and an instruction for altering a volume level or other playback control parameter of the acoustic device. In another example, a portion of the input speech data may request information and/or control pertaining to an application ecosystem. Examples of such information and control include a query on which applications are currently executing on a connected mobile device (or on the device <NUM> itself, for example, if the device <NUM> is capable of executing applications), a query on remaining battery power of the mobile device, or a request to perform a particular task on the mobile device (e.g., launch a particular application or provide particular information). In such cases, the portion of the input speech data may also be processed and/or addressed locally, for example, either at the device <NUM> itself, or at a mobile device connected to the device <NUM> (e.g., in cases where the device <NUM> is an acoustic device such as a headset).

In some implementations, such local processing of at least portions of input speech data may reduce an amount of data that is sent to a remote computing system (e.g., one or more computing devices associated with a cloud-based VPA service provider) and/or time required to address the corresponding portions of the request. For example, information about remaining battery life of the device <NUM> is available locally, and may be provided to a user without having to send the information to a VPA service provider and generate an output based on a response received from the VPA service provider. In some cases, such local processing may reduce latency in providing information to a user, thereby potentially improving the overall user experience.

In some implementations, if a portion of the input speech data may be processed and/or addressed locally, the portion may be excluded from information sent to a VPA service provider. In some implementations, even if a portion of the input speech data is addressable locally, the portion is not excluded from the information sent to a VPA service provider. In such cases, if the response generated by the VPA service provider is received before the locally generated response, the former can be used for providing a corresponding output to the user. Such redundancy may be useful, for example, in leveraging superior processing power available from the VPA service provider (or in compensating for lack of adequate processing power available locally), and ensuring that a response is provided to the user as quickly as possible.

If a portion of the input speech data requests information and/or control that is not available locally, the portion of the input speech data is used in generating one or more electronic files that are sent to a selected VPA service provider for processing. Examples of such information and/or control can include information that may be available in remote databases (e.g., weather information, "How tall is the Eiffel Tower?" or "What time does the next 30B bus arrive at South Station?"), or instructions that may require communications with computing devices of a third-party service provider (e.g., "Turn on my lights outside," or "Set the bedroom thermostat to <NUM> degrees at <NUM>:<NUM> PM. In such cases, the device <NUM> processes the input speech data to generate one or more electronic files based on at least a portion of the input speech data in accordance with specifications of the selected VPA service provider.

The device <NUM> includes a controller <NUM> that processes the input speech data, for example, to determine whether at least a portion of the input speech data may be processed locally and accordingly generate the one or more electronic files to be transmitted to the selected VPA service provider. The controller <NUM> can include one or more processing devices (e.g., one or more microprocessors, microcontrollers, or digital signal processors) that may be used for implementing various modules of the controller <NUM>. In some implementations, the controller can execute an application on the device <NUM> for implementing one or more modules. In some implementations, the controller <NUM> includes a speech recognition engine <NUM> that processes the input speech data to determine content of the input speech data. The output of the speech recognition engine can be used to determine, for example, which of the multiple VPA service providers have been selected by the user to process the requests within the input speech data. For example, the output of the speech recognition engine <NUM> can be analyzed to monitor for one or more keywords indicative of the user's choice of a VPA service provider. If such keywords are detected, at least portions of the input speech data are prepared for routing to the selected VPA service provider. On the other hand, if no keywords are detected, relevant portions of the input speech data may be routed to a default VPA service provider (which may also be pre-selected by the user).

The controller <NUM> can also include a packet generator <NUM> that generates data packets based on the portions of the input speech data to be transmitted to the selected VPA service provider. For example, if the controller determines that a portion of the input speech data may be addressed locally at the device <NUM>, the packet generator <NUM> can be configured to omit the relevant portions from the data packets prepared for the selected VPA service provider. In some implementations, such portions may still be included in the data packets even if the portions are locally addressable at the device <NUM>.

The controller <NUM> further includes a VPA specific handler <NUM> that formats the information to be sent to the selected VPA in accordance with the specifications of the selected VPA. For example, if a particular VPA service provider requires an input in the form of a. wav file, the VPA specific handler <NUM> can be configured to generate such a wave file based on, for example, a portion of the input speech data determined to be sent to the particular VPA service provider. In another example, if a selected VPA service provider requires an input in the form of. txt files, the VPA specific handler <NUM> may coordinate with the speech recognition engine in creating such a file for the selected VPA service provider.

The controller <NUM> can receive, responsive to local processing of a portion of the input speech data and/or transmitting a portion of the input speech data to a remote VPA service provider, one or more electronic files that represent a response to requests, queries etc. included within the input speech data. In some implementations, the received electronic files can be used for causing an acoustic transducer to generate an acoustic output. In some implementations, this may be facilitated by a text-to-speech (TTS) engine <NUM> configured to generate intelligible audio based on one or more electronic files that include the response (either locally generated, or received from a remote VPA service provider). In some implementations, the received electronic files can be used for causing an output on a display associated with the device <NUM> or at a mobile device connected to the device <NUM>.

<FIG> are example screenshots associated with configuring an acoustic device to interact with multiple VPA service providers. The screenshots shown in these figures may be presented, for example, on a display device <NUM> described above with reference to <FIG>. Specifically, <FIG> shows a user-interface <NUM> that includes a user-selectable menu of multiple VPA service providers. The user-interface <NUM> can be used, for example, to set a default VPA service provider (e.g., the one to use when the user does not specify a VPA service provider in a spoken input) or to specify the VPA service provider to be used for all requests and queries. In some implementations, the user-interface <NUM> may also be used for configuring the various VPA service providers included in the user-selectable menu.

In some implementations, responsive to receiving a user-selection of a particular VPA service provider via the user-interface <NUM>, a second user-interface <NUM> (as shown in <FIG>) is presented on the display device for receiving credentials for using the particular VPA service provider. For example, if the user-selection indicates the selection of VPA <NUM> as a VPA service provider, the second user-interface <NUM> may display one or more text-boxes for receiving credentials (e.g., email/username and password pair) associated with an account set up for using the VPA <NUM>. Upon receiving the credentials from a user, the credentials may be provided to the corresponding VPA service provider for authentication, and a communication channel with one or more computing devices associated with the corresponding VPA service provider is established upon authentication of the credentials. In some implementations, a third user-interface <NUM> (as shown in <FIG>) for receiving speech input is presented upon the credentials being authenticated. While the examples in <FIG> depict a visual user interface for configuring one or more VPA service providers, in other implementations, a user could configure and establish connections to VPA service providers via a voice user interface and/or manually operable controls on a personal device (for example, on device <NUM> described above with reference to <FIG>).

<FIG> shows a flowchart for an example process <NUM> for interacting with a user-selected VPA service provider. In some implementations, at least a portion of the process <NUM> may be executed on a device such as the device <NUM> described above. For example, the process <NUM> may be executed, at least in part, on a mobile device, a headphone, a remote controller or a smart watch. In some implementations, execution of the process <NUM> may be facilitated, at least in part, by an application executing on a mobile device.

Operations of the process <NUM> include presenting, on a first device, a first user-interface that includes a user-selectable menu of multiple virtual personal assistant (VPA) service providers (<NUM>). The user-interface can be presented, for example, on a display device of the first device. The first device can be, for example, a mobile device, a headphone, a smart watch, or a remote controller. In some implementations, the first interface can be substantially similar to the user-interface <NUM> illustrated in <FIG>. Operations of the process <NUM> also include receiving a user-selection identifying a particular VPA service provider (<NUM>). The user selection can be received via a user-interface such as the user-interface <NUM>, or as a spoken input.

Operations of the process <NUM> also include receiving, at the first device, a first signal representing input speech data (<NUM>). In some implementations, the first signal representing input speech data can be captured using a microphone of an acoustic device (e.g., a headphone, a headset, an earphone, a portable speaker, or a hearing aid), or a smart watch. The input speech data may also be captured using the microphone of a remote controller that controls, for example, an acoustic device, a media streaming device, a home theater system, or a television. In some implementations, the input speech data may also be captured using the microphone of a mobile device such as a smartphone, tablet computer, or e-reader, or another computing device such as a laptop or desktop computer.

Operations of the process <NUM> further include processing, using one or more processors of the first device, the first signal to generate a first electronic file that includes at least a portion of the input speech data, the first electronic file being generated in accordance with a specification of the particular VPA service provider (<NUM>). In some implementations, processing the first signal can include determining that a request included in the input speech data is locally addressable at the first device, and processing the request by the one or more processors of the first device. In some implementations, the locally addressable request may be excluded from the input speech data that is included in the first electronic file. The first electronic file can be generated in accordance with the specification of the particular VPA service, for example, as described above with reference to <FIG> and <FIG>.

Operations of the process <NUM> also include transmitting the first electronic file to one or more remote computing devices associated with the particular VPA service provider (<NUM>) and receiving a second electronic file including a response to the input speech data included in the first electronic file (<NUM>). The one or more remote computing devices can be ones that provide cloud-based services for the particular VPA service provider. The operations further include causing an acoustic transducer to generate an acoustic output based on the second electronic file (<NUM>). If the process <NUM> is being executed on a mobile device, and the acoustic transducer is on a headphone, this can include transmitting a representation of the received response from the mobile device to the headphone such that the acoustic transducers (e.g., speakers) in the headphone can be used for playing back an audible version of the response.

<FIG> shows a flowchart for an example process <NUM> for selecting one of multiple VPA service providers based on detecting the presence of one or more words in a speech input. In some implementations, at least a portion of the process <NUM> may be executed on a device such as the device <NUM> described above. For example, the process <NUM> may be executed, at least in part, on a mobile device, a headphone, a remote controller or a smart watch. In some implementations, execution of the process <NUM> may be facilitated, at least in part, by an application executing on a mobile device.

Operations of the process <NUM> include receiving a first signal representing input speech data (<NUM>). In some implementations, the first signal representing input speech data can be captured using a microphone of an acoustic device (e.g., a headphone, a headset, an earphone, a portable speaker, or a hearing aid), or a smart watch. The input speech data may also be captured using the microphone of a remote controller that controls, for example, an acoustic device, a media streaming device, a home theater system, or a television. In some implementations, the input speech data may also be captured using the microphone of a mobile device such as a smartphone, tablet computer, or e-reader, or another computing device such as a laptop or desktop computer.

Operations of the process <NUM> also include processing the first signal to detect one or more words in the input speech data (<NUM>). The one or more words can be keywords associated with various VPA service providers. For example, the keywords can be words that are pre-determined by a particular VPA service provider to trigger that VPA service provider or the keywords can be words that the user has customized to be associated with a particular VPA service provider. In some implementations, this may be performed, for example, using the speech recognition engine <NUM> of the controller <NUM> described above with reference to <FIG>.

Operations of the process <NUM> further include selecting, based on the one or more words detected in the input speech data, a particular virtual personal assistant (VPA) service provider from a list of multiple voice-activated virtual personal assistant (VPA) service providers (<NUM>). For example, the controller <NUM> of a device <NUM> can be configured to detect that the one or more words include a set of one or more keywords associated with the particular VPA service provider, and in response, select the particular VPA service provider for addressing/routing at least a portion of the input speech data. In some implementations, if the input speech data does not include keywords associated with any of the VPA service providers, a default VPA service provider may be selected to address at least a portion of the input speech data.

Operations of the process <NUM> further include generating a first electronic file that includes at least a portion of the input speech data, the first electronic file being generated in accordance with a specification of the particular VPA service provider (<NUM>). In some implementations, this can include determining that a request included in the input speech data is locally addressable on the device executing the process <NUM>, and processing the request by the one or more processors of the device. In some implementations, the locally addressable request may be excluded from the input speech data that is included in the first electronic file. The first electronic file can be generated in accordance with the specification of the particular VPA service, for example, as described above with reference to <FIG> and <FIG>.

Operations of the process <NUM> also include transmitting the first electronic file to one or more remote computing devices associated with the particular VPA service provider (<NUM>). The one or more remote computing devices can be ones that provide cloud-based services for the particular VPA service provider. The first electronic file may be transmitted via a communication channel established with the one or more remote computing devices. In case such a channel has not already been established, credentials for using the particular VPA service provider can be retrieved (e.g., from a storage location, or from a user via a user-interface as shown in <FIG>), and provided to the particular VPA service provider. The communication channel can then be established in response to the credentials being authenticated by the VPA service provider.

In response to transmitting the first electronic file to the VPA service provider, one or more electronic files may be received from the remote computing devices, such files including a response to the input speech data included in the first electronic file. An acoustic output can then be generated based, at least in part, on the second electronic file, via an acoustic transducer.

The functionality described herein, or portions thereof, and its various modifications (hereinafter "the functions") can be implemented, at least in part, via a computer program product, e.g., a computer program tangibly embodied in an information carrier, such as one or more non-transitory machine-readable media or storage device, for execution by, or to control the operation of, one or more data processing apparatus, e.g., a programmable processor, a computer, multiple computers, and/or programmable logic components.

Actions associated with implementing all or part of the functions can be performed by one or more programmable processors executing one or more computer programs to perform the functions of the calibration process. All or part of the functions can be implemented as, special purpose logic circuitry, e.g., an FPGA and/or an ASIC (application-specific integrated circuit). In some implementations, at least a portion of the functions may also be executed on a floating point or fixed point digital signal processor (DSP) such as the Super Harvard Architecture Single-Chip Computer (SHARC) developed by Analog Devices Inc.

Components of a computer include a processor for executing instructions and one or more memory devices for storing instructions and data. In embodiments not according to the claimed invention, the technology described herein may be used for an automated selection of VPA service provider based on content of the input speech data. For example, a machine learning process may be used to determine that a user typically uses a first VPA service provider in asking for driving directions, and a second VPA service provider for online shopping. Accordingly, when the input speech data is determined to include a shopping request, the request may automatically be routed to the second VPA even if the user has not explicitly specified the keywords for the second VPA. In some implementations, the user may specify, for example via a user-interface, different VPA service providers for different types of requests, and such preferences may be used for automatic routing of the input speech data to different VPA service providers. The machine learning process may be updated and refined based on user input in response to a particular VPA service provider being selected. For example, if the user indicates via a user interface that a different VPA service provider should have been selected for the particular request being processed, the machine learning process may take this information into account in processing future requests.

Claim 1:
A method for accessing multiple virtual personal assistants, VPAs, the method comprising:
receiving first input speech data;
processing, using at least one processor, the first input speech data to detect a first set of one or more words;
based on detecting the first set of one or more words, routing a first electronic file that includes at least a portion of the first input speech data to a first VPA pre-selected from a list of multiple VPAs;
receiving second input speech data;
processing, using the at least one processor, the second input speech data to detect a second set of one or more words; and
based on detecting the second set of one or more words, routing a second electronic file that includes at least a portion of the second input speech data to a second VPA pre-selected from the list of multiple VPAs,
characterised by,
prior to receiving the first input speech data, presenting the list of multiple VPAs to a user for selection of the first VPA and the second VPA.