CN117223258A

CN117223258A - Accompanying device authentication

Info

Publication number: CN117223258A
Application number: CN202280030368.5A
Authority: CN
Inventors: C·M·达文波特; Q·D·琼斯; P·J·肖尔茨; P·J·黑尔
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2021-04-23
Filing date: 2022-04-22
Publication date: 2023-12-12

Abstract

The subject disclosure provides systems and methods for attendant device authentication. A user of a first device may not be able to access services that may be provided by the first device. The service may be a streaming service, a cloud-based service, or the like. The companion device authentication may allow the user or another user to use the companion device of the first device to authorize access to the service at the first device. The first device and the companion device may exchange communications to designate the companion device prior to notifying a user of the companion device of a companion device authentication request for the first device.

Description

Accompanying device authentication

Cross Reference to Related Applications

The present application claims the benefit of priority from U.S. provisional patent application No. 63/179,165, entitled "Companion Device Authentication," filed 4/23 at 2021, the disclosure of which is hereby incorporated herein in its entirety.

Technical Field

The present description relates generally to authenticated access to applications, content, and services for electronic devices.

Background

Users of electronic devices often access streaming media services via applications on the electronic device. When a user logs into an electronic device and has previously logged into a streaming service on the electronic device, the user is typically provided with later access to the streaming service without having to log into the streaming service again. Some electronic devices allow users other than those logged into the electronic device to log into a streaming service on the electronic device. However, in various scenarios, it may be cumbersome and/or inefficient for users to coordinate their individual login information on the user's device.

Drawings

Some features of the subject technology are set forth in the following claims. However, for purposes of explanation, several embodiments of the subject technology are set forth in the following figures.

FIG. 1 illustrates an exemplary network environment including an environment including user equipment in accordance with one or more implementations.

FIG. 2 illustrates an example device that can implement the system for companion device authentication in accordance with one or more implementations.

Fig. 3 illustrates an electronic device and companion electronic device in accordance with one or more implementations.

Fig. 4 illustrates an electronic device providing beacons to an inactive companion electronic device in accordance with one or more implementations.

FIG. 5 illustrates an electronic device receiving a designation from a companion electronic device in accordance with one or more implementations.

Fig. 6 illustrates a companion electronic device with a display that has been activated in response to an authentication request from the electronic device in accordance with one or more implementations.

FIG. 7 illustrates a flow diagram of an exemplary process that may be performed by an electronic device for accompanying device authentication, in accordance with one or more implementations.

FIG. 8 illustrates a flow diagram of an exemplary process that may be performed by a companion electronic device for companion device authentication in accordance with one or more implementations.

FIG. 9 illustrates an electronic device that initiates purchase approval in accordance with one or more implementations.

FIG. 10 illustrates an electronic device and companion electronic device performing companion device purchase approval in accordance with one or more implementations.

FIG. 11 illustrates a flow diagram of an exemplary process that may be performed by a requesting device for accompanying device purchase approval, in accordance with one or more implementations.

FIG. 12 illustrates a flow diagram of an exemplary process that may be performed by an approval device for concomitant device purchase approval, according to one or more implementations.

FIG. 13 illustrates an exemplary electronic system that can be used to implement various aspects of the subject technology in accordance with one or more implementations.

Detailed Description

The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configuration in which the subject technology may be practiced. The accompanying drawings are incorporated in and constitute a part of this specification. The specific embodiments include specific details for the purpose of providing a thorough understanding of the subject technology. The subject technology is not limited to the specific details described herein, however, and may be practiced using one or more other implementations. In one or more implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

The subject technology provides for logging in or logging in to an application and/or service on a first device using an authentication operation performed at least in part at another device (e.g., also referred to herein as a companion device or authentication device) in proximity to the first device. The companion device may provide credentials of the application and/or service itself to the first device and/or credentials of a user account associated with the companion device (e.g., a user account of a user of the companion device) that may be used by the first device to obtain the credentials of the application and/or service. The companion device may log into and/or register with a user account associated with the companion device. The user account of the companion device may be the same as or different from the user account associated with the first device (e.g., the user account to which the first device is logged into or registered with, such as the user account of the user of the first device). In this way, aspects of the disclosed technology allow for extended use of companion devices to authenticate access to applications and/or services at a first device.

In one or more implementations, when companion device authentication is requested at a first device, the first device may broadcast a beacon for potential authentication devices. Devices near the first device may not be significantly activated to perform authentication operations until after a particular one of the devices is specified by a user of the particular device with an action at the particular device. Waiting to provide, for example, a notification on the companion/authentication device until the device is designated to perform authentication may prevent warning and/or buzzing of all nearby devices, which may be undesirable for some users and may waste power and computing resources of devices (e.g., including companion devices) that are ultimately not used for authentication.

The subject technology also provides for purchase or other approval (e.g., approval of terms and conditions, approval for download and/or installation of software such as an application, etc.) initiated at a first device using an approval and/or authentication operation performed at least in part at another device (e.g., also referred to herein as a companion device, an approval device, or an authentication device) proximate to the first device. For example, the first device may initiate a purchase or other approval process to the server and then hand over the approval process to the companion device. The companion device may provide authorization or approval of the purchase or other approval process to the server and obtain a token from the server corresponding to the purchase or other approval process. The companion device may provide the token to the first device, which may then complete a purchase or other approval process with the server using the token received from the companion device. In this way, aspects of the disclosed technology allow for extended use of companion devices to provide approval, such as purchase of applications and/or services at the first device and/or authenticated approval of purchases via applications and/or services at the first device.

FIG. 1 illustrates an exemplary network environment 100 including various devices in accordance with one or more implementations. However, not all of the depicted components may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figures. Variations in the arrangement and type of these components may be made without departing from the spirit or scope of the claims set forth herein. Additional components, different components, or fewer components may be provided.

Network environment 100 includes electronic devices 102, 103, 104, 105, 106, and 107 (hereinafter referred to as "electronic devices 102-107"), a local area network ("LAN") 108, a network 110, and one or more content providers, such as content provider 112, one or more cloud-based services, such as cloud-based service 114, and one or more merchant services, such as merchant server 121.

The content provider 112 may provide access to content, such as streaming media content (e.g., video content, audio content) or other subscription-based content (e.g., e-book content, etc.), to user devices (e.g., to one or more of the electronic devices 102-107) that are associated with user accounts that have been established with the content provider 112. The cloud-based service 114 may provide access to cloud-based storage, content stored in the cloud-based storage (e.g., photos, videos, calendar information, etc.), applications (e.g., gaming applications, streaming applications, and/or any other application) to user devices (e.g., to one or more of the electronic devices 102-107) associated with user accounts that have been established through the cloud-based service 114. The user of the electronic device 102-107 may provide authentication information to the device to log the device into one or more accounts maintained for the user at one or more of the content provider 112 and/or the cloud-based service 114, and/or to authorize and/or approve purchases (e.g., purchases of applications, rentals of streaming media, purchases of streaming media, and/or any other purchases that may be made over the network 110) from the one or more of the content provider 112 and/or the cloud-based service 114. In one or more implementations, merchant server 121 may represent one or more merchant servers that may process purchases and/or payments to content provider 112, cloud-based service 114, and/or any other network-connected merchant (e.g., in cooperation with a bank's payment server, credit card server, or other payment service).

According to aspects of the subject disclosure, an electronic device, such as electronic device 106 or electronic device 107, may be used as a companion device or authentication device to provide authentication for accessing and/or purchasing from a content provider 112 and/or cloud-based service 114 by another device, such as electronic device 102, electronic device 103, electronic device 104, and/or electronic device 105.

For example, both the electronic device 105 and the electronic device 106 may log into a first user account (e.g., a first user account of a first user) through the cloud-based service 114 or another server. In an exemplary operating scenario, the electronic device 105 may also log into a user account with the content provider 112 using an application on the electronic device 105 for that content provider. The electronic device 105 and/or the cloud-based service 114 may securely store authentication information of the content provider 112 in association with the first user account with the cloud-based service 114 such that the electronic device 105 may repeatedly access the content provider 112 without re-authenticating with the content provider 112 for each access.

In an exemplary scenario, the electronic device 104 may log into a second user account (e.g., a second user account of a second user) through the cloud-based service 114 or another server. In this example, while the application for the content provider 112 may be installed at the electronic device 104, the electronic device 104 may not be associated with an account with the content provider 112 or may not be logged into an account with the content provider 112.

The first user may be, for example, the only or primary user of the electronic device 105, and the second user may be the only or primary user of the electronic device 104. In some scenarios, the first user may also be a secondary user of the electronic device 104, and the first user may access the content provider 112 by switching to become the primary user of the electronic device 104. However, there are other scenarios in which the first user may not be a user of the electronic device 104 but may still desire to use the electronic device 104 to access the content provider 112.

For example, the first user may be a guest at the second user's home or other location, and the first user and the second user may desire to use the electronic device 104 to stream movies from the content provider 112. Because the second user of the electronic device 104 does not have an account with the content provider 112, it may be necessary to authenticate the first user's account with the content provider 112 in order to use the first user's account and stream the movie using the second user's electronic device 104.

In some scenarios, the first user may operate the electronic device 104 to authenticate the first user's account with the content provider (e.g., log into an account in the content provider) by typing the user name and password of the first user's account with the content provider 112 into the electronic device 104. However, when the electronic device 104 is implemented in the form of a media player (or smart speaker, such as the smart speaker in the example of the electronic device 102), the electronic device 104 (e.g., without a keyboard or touch interface) may be more difficult to operate for this type of operation than the electronic device 106 (e.g., which may have a touch screen that may provide a keyboard). Further, in connection with a cloud-based service to which the electronic device 106 is logged in and/or registered, authentication information for authenticating with the content provider 112 may have been securely stored (e.g., at the electronic device 106 and/or at the cloud-based service) for the account of the first user.

When the electronic device 106 is proximate to the electronic device 104 (e.g., within the range of a bluetooth connection or a secure direct Wi-Fi connection), aspects of the subject technology facilitate using the electronic device 106 (or another electronic device such as the electronic device 107) as an authentication device (also referred to herein as an authentication device) for the electronic device 104 to provide authentication of the first user with the content provider 112. In some scenarios, an application for the content provider 112 may also be installed at the electronic device 106, and the application may be launched at the electronic device 106 and used to provide authentication information to a corresponding application at the electronic device 104. However, in other scenarios, even if the first user of the electronic device 106 has an account with the content provider, the application of the content provider 112 may not be installed at or accessible at the electronic device 106.

When the electronic device 106 is proximate to the electronic device 104, aspects of the subject technology facilitate using the electronic device 106 (or another electronic device such as the electronic device 107) as a companion device or authentication device for the electronic device 104 for authenticating the first user's account with the content provider 112 even when an application for the content provider 112 is not installed at or is not accessible at the electronic device (e.g., for a third party application that is not present on the companion device).

Each of the electronic devices 102-107 may be a single user device or a multi-user device. A single user device (e.g., electronic devices 106 and 107) may be associated with a single user account, such as a separate user account to one or more of servers 112-114. A multi-user device (e.g., electronic devices 102, 103, 104, and 105) may provide functionality to switch the current state of the device between individual user accounts of one or more users and/or a single group of accounts associated with a group of users (e.g., at a remote server such as cloud-based service 114). In one or more implementations, the electronic devices 102-107 may form part of an interconnected home environment 116, and the LAN 108 may be communicatively coupled (directly or indirectly) to any two or more of the electronic devices 102-107 within the interconnected home environment 116. Further, the network 110 may communicatively couple (directly or indirectly) any two or more of the electronic devices 102-107 with the content provider 112 and/or the cloud-based service 114, for example, in conjunction with the LAN 108. As shown in fig. 1, electronic devices such as electronic device 106 and electronic device 105 may communicate directly through a secure direct connection, such as when electronic device 106 is proximate to electronic device 105. Although the electronic devices 102-107 are shown in FIG. 1 as forming part of an interconnected home environment in which all devices are connected to the LAN 108, one or more of the electronic devices 102-107 may not be part of an interconnected home environment and/or may not be connected to the LAN 108 at one or more times.

In one or more implementations, the LAN 108 may include one or more different network devices/network mediums and/or may utilize one or more different wireless and/or wired network technologies, such as ethernet, optical, wi-Fi, bluetooth, zigbee, ethernet power line, coaxial, ethernet, Z-wave, cellular, or generally any wireless network technology and/or wired network technology that communicatively couples two or more devices.

In one or more implementations, the network 110 may be an interconnection network that may include the internet and/or devices communicatively coupled to the internet. For purposes of explanation, the network environment 100 in FIG. 1 is illustrated as including electronic devices 102-107 and servers 112-114; however, network environment 100 may include any number of electronic devices and any number of servers.

One or more of the electronic devices 102-107 may be, for example, a portable computing device such as a laptop computer, a smart phone, a smart speaker, a peripheral device (e.g., a digital camera, an earphone), a digital media player, a tablet device, a wearable device such as a smart watch or bracelet, an interconnected home device such as a wireless camera, a router, and/or a wireless access point, a wireless access device (e.g., a door lock), a smart thermostat, a smart light bulb, a home security device (e.g., a motion sensor, a door/window sensor, etc.), a smart socket, a smart switch, etc., or any other suitable device that includes and/or is communicatively coupled to, for example, one or more wired or wireless interfaces such as a WLAN radio, a cellular radio, a bluetooth radio, a Zigbee radio, a Near Field Communication (NFC) radio, and/or other wireless radio.

By way of example, in fig. 1, each of electronic devices 102-103 is depicted as a smart speaker, electronic device 106 is depicted as a smart phone, electronic device 107 is depicted as a smart watch, and each of electronic devices 104 and 105 is depicted as a digital media player (e.g., configured to receive and stream digital data such as music and/or video to a display device such as a television or other video display). In one or more implementations, one or more of the electronic devices 104 and 105 can be integrated into or separate from the respective display device. One or more of the electronic devices 102-107 may be and/or may include all or part of the devices discussed below in connection with fig. 2 and/or the electronic systems discussed below in connection with fig. 9.

One or more of the electronic devices 102-107 may be configured to receive user authorization to access a respective user account profile of a single user account and/or group account in order to provide access to content, applications, services, or storage within the interconnected home environment 116 and/or with the servers 112-114.

In one or more implementations, the electronic device 106 can correspond to a personal device associated with a user account (e.g., of a user named "Alison"). The Alison may reside in or be a visitor to a home/residence (e.g., corresponding to the interconnected home environment 116) that is the home of another user (e.g., named "Bob"). Electronic device 107 may be associated with an Allison user account and electronic devices 102-104 may correspond to an account such as Bob's home account or cloud-based account. In one example, the electronic device 105 may also correspond to an Alison's user account. For example, a respective user may register and/or associate their respective electronic device 102-106 with their respective user account through a service provider, such as through the cloud-based service 114.

In one or more implementations, bob may interact with the electronic device 104 in order to access and/or output content (e.g., video and/or music available through Bob's content library associated with Bob's user account) on one or more of the electronic devices 102-104. For example, the electronic devices 102-103 (e.g., smart speakers) may have a virtual assistant application running thereon, and Bob may provide a voice request to stream music (e.g., via the content provider 112) in association with his user account.

The Alison may access its media content (e.g., music and/or video) on one or more of the electronic devices 105-107. For example, the electronic device 105 (e.g., a digital media player) may have a remote control device that the Alison may use (e.g., via physical buttons, touch surfaces, and/or voice requests spoken to the remote control) to control the output of video and/or music via the content provider 112 in association with its user account.

In one or more implementations, the cloud-based service 114 may be configured to perform operations associated with a user account, such as: storing data about a user account (e.g., voice profiles, user settings/preferences, files such as documents and/or photographs, etc.), sharing and/or sending data about a user account with other users, backing up device data about a user account, and/or associating devices and/or groups of devices with a user account.

One or more of the servers for the content provider 112 and/or the cloud-based service 114 may be and/or may include all or part of the devices discussed below with respect to fig. 2 and/or the electronic systems discussed below with respect to fig. 9. Each of the content provider 112 and/or cloud-based service 114 may include one or more servers, such as a server cloud. For purposes of explanation, a single server is shown and discussed for each of the various operations for the content provider 112 and/or the cloud-based service 114. However, these operations and other operations discussed herein may be performed by one or more servers, and each different operation may be performed by the same or a different server.

FIG. 2 illustrates an example device that can implement the system for companion device authentication in accordance with one or more implementations. For example, the device 200 of fig. 2 may correspond to any of the servers and/or cloud-based services 114 of the electronic devices 102-107 and/or content provider 112 of fig. 1. However, not all of the depicted components may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figures. Variations in the arrangement and type of these components may be made without departing from the spirit or scope of the claims set forth herein. Additional components, different components, or fewer components may be provided.

The device 200 may include a processor 202, a memory 204, a communication interface 206, and an input device 208. The processor 202 may comprise suitable logic, circuitry, and/or code that may be enabled to process data and/or control the operation of the device 200. In this regard, the processor 202 may be enabled to provide control signals to various other components of the device 200. Processor 202 may also control the transfer of data between portions of device 200. In addition, the processor 202 may enable an operating system or otherwise execute code to manage the operation of the device 200.

The memory 204 may comprise suitable logic, circuitry, and/or code that may enable storage of various types of information, such as received data, generated data, code, and/or configuration information. Memory 204 may include, for example, random Access Memory (RAM), read Only Memory (ROM), flash memory, and/or magnetic storage devices.

In one or more implementations, where the device 200 corresponds to one of the electronic devices 102-107, the memory 204 can store authentication information associated with one or more user accounts of one or more applications and/or services using data stored locally in the memory 204. Further, the input device 208 may comprise suitable logic, circuitry, and/or code that may be operable to capture input, such as audio input (e.g., a voice request), remote control input, touch screen input, keyboard input, etc.

The communication interface 206 may comprise suitable logic, circuitry, and/or code that may enable wired or wireless communication (e.g., in connection with the LAN 108) over the network 110, such as between the electronic devices 102-107 and/or any of the servers 112-114. The communication interface 206 may include, for example, one or more of a bluetooth communication interface, a cellular interface, an NFC interface, a Zigbee communication interface, a WLAN communication interface, a USB communication interface, or generally any communication interface.

In one or more implementations, one or more of the processor 202, the memory 204, the communication interface 206, the input device 208, and/or one or more portions thereof may be implemented in software (e.g., subroutines and code), may be implemented in hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, a gate logic component, discrete hardware components, or any other suitable device), and/or in a combination of both software and hardware.

Fig. 3 illustrates an example in which the electronic device 106 is proximate to the electronic device 104 when access to content or services has been initiated, such as access to the content provider 112 via an application 302 running at the electronic device 104. For example, when a user of the electronic device 104 is not logged into the application 302, the user of the electronic device may have launched the application 302 at the electronic device 104.

As shown in fig. 3, in response to launching application 302 when a user is not logged into application 302, a system process separate from application 302 may provide notification 322, such as using display 300 connected to or integrated with electronic device 104. As shown in fig. 3, the electronic device 104 may have previously stored encryption information 310 that may be used to establish a secure direct connection (e.g., a secure direct peer-to-peer channel) with the electronic device 106. Fig. 3 also shows how the electronic device 106 may have previously stored encrypted information 308 that may be used to establish a secure direct connection with the electronic device 104. For example, the electronic device 104 and the electronic device 106 may have previously exchanged encryption information 308 and 310 (e.g., public keys, link keys, etc.) as part of a previous pairing operation or as part of a registration operation of a device that registers the device as a home or a member of a home. In one or more implementations, the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 by a direct peer-to-peer connection between the electronic devices 104 and 106, and/or the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 by a server-based transport mechanism.

For example, the electronic device 104 may have been previously paired with the electronic device 106 and exchanged for encryption information that may be stored for later establishment of a secure direct connection. In another example, the electronic device 106 may be a device associated with a user account of the electronic device 104 (e.g., the electronic device 104 and the electronic device 106 may be registered devices of the same user). In another example, the electronic device 106 may be a device associated with its own user account that is different from but associated with the account of the electronic device 104 (e.g., and the electronic device 106 may be a device that is registered as a family member device of a family member of the user of the electronic device 104, or a device of another user that is associated with the family environment of the user of the electronic device 104).

In the example of fig. 3, the display 320 of the electronic device 106 is inactive and the notification 322 provided by the electronic device 104 includes a request to the user indicating whether authentication (login) to the application 302 using another device is desired. In the example of fig. 3, notification 322 includes selectable option 304 (e.g., "yes") to request companion device authentication and selectable option 306 (e.g., "no") to reject companion device authentication. However, selectable options 304 and 306 are merely illustrative, and other or different selectable options for requesting accompanying device authentication may be provided.

Fig. 4 illustrates an example of the electronic device 106 and the electronic device 104 after the user of the electronic device 104 has requested an accompanying device authentication (e.g., by selecting the selectable option 304 of fig. 3). As shown in fig. 4, in response to a request at the electronic device 104, the electronic device 104 (e.g., a system process at the electronic device 104) broadcasts a beacon 400 to any electronic devices that are proximate to the electronic device 104. As shown in fig. 4, while the electronic device 104 is broadcasting the beacon 400, the display 320 of the electronic device 106 is still inactive (or is active and has no notification associated with the beacon), and the electronic device 106 does not provide any external notification (e.g., a beep, audio output, or visual output) in response to the beacon.

Because the user of the electronic device 106 is aware that they (or another user) have requested companion device authentication at the electronic device 104, the user of the electronic device 106 may pick up and/or unlock the electronic device 106 to provide companion device authentication (e.g., before any notifications have been provided at the electronic device 106). In this manner, user input may be provided to the electronic device 106 to specify that the electronic device 106 (e.g., as an authentication device) provide for concomitant device authentication. The user input to the electronic device 106 (e.g., to indicate a designation) may be active user input (e.g., pressing a button or providing a touch screen input) or passive user input (e.g., lifting the device).

As shown in fig. 5, in response to being picked up (e.g., as sensed using an accelerometer or other inertial measurement unit (inertial measurement unit, IMU) component in the electronic device 106) and/or unlocked, the electronic device 106 (e.g., still does not activate the display 320 or otherwise provide an external notification, and does not have a user instruction) provides a designation signal 500 to the electronic device 104 that signals the electronic device 106 to provide accompanying device authentication.

As shown in fig. 6, in response to receiving the designation signal 500, the electronic device 104 ceases broadcasting the beacon and establishes a secure direct connection 600 (e.g., a secure direct peer-to-peer channel) with the electronic device 106 (e.g., using the encrypted information 308 and 310 discussed above in connection with fig. 3). Fig. 6 also shows how the electronic device 104 provides an authentication request 602 to the electronic device 106 once the secure direct connection 600 is established. As shown in fig. 6, because the authentication request 602 is provided over the secure direct connection 600, the authentication request 602 may include sufficient information to allow the initial notification 604 provided by the electronic device 106 to include meaningful information to the user about the companion device authentication request (e.g., including applications and devices that desire to accompany device authentication).

For example, in fig. 6, the initial notification 604 includes the text "do you want to log into application 1 on device 2 using the device? ". In this example, "application 1" may represent a title or name of an application (e.g., application 302) that is requested for authentication by "device 2" (which corresponds to electronic device 104 in this example). In the example of fig. 6, the initial notification includes a selectable option 606 to proceed with accompanying device authentication (e.g., "yes") and a selectable option 608 to reject accompanying device authentication (e.g., "no"). However, other or different selectable options may be provided to continue (accept) or reject the attendant device authentication.

Continued companion device authentication may be performed in various ways depending on the configuration of the electronic device 106, the state of the electronic device 106, and/or access permissions maintained by the electronic device 106.

For example, in one or more implementations, the electronic device 106 can have a token stored in memory for authentication with the application 302, the content provider 112, and/or the cloud-based service 114, which can be communicated to the electronic device 104 to allow the electronic device to authenticate with the application 302, the content provider 112, and/or the cloud-based service 114. In one or more implementations, to authorize the transfer of the token, the user of the electronic device 106 may be required to provide an unlock password, biometric authentication, or other local authentication for accessing the electronic device 106.

In another example, in one or more implementations, the electronic device 106 can securely store passwords for accessing the application programs 302, the content provider 112, and/or the cloud-based service 114 at the electronic device 106. In this example, the electronic device 106 may provide the stored password to the electronic device 104 over the secure direct connection 600 (e.g., after user authentication for accessing the stored password, such as using a device unlock code or biometric authentication) for authenticating the user account of the application 302, the content provider 112, and/or the cloud-based service 114 at the electronic device 104.

In another example, in one or more implementations, continuing with companion device authentication with the electronic device 106 can include redirecting a user of the electronic device 106 to a web page of the application 302, the content provider 112, and/or the cloud-based service 114 (e.g., using a browser of the electronic device 106). In this example, a physical or virtual keyboard and/or other input component of the electronic device 106 can be used to manually input authentication information to the web page for the electronic device 104 to access the application programs 302, the content provider 112, and/or the cloud-based service 114. For example, once the user of the electronic device 106 provides authentication information via the web page, a server associated with the web page may authorize the electronic device 104 to access the application programs 302, the content provider 112, and/or the cloud-based service 114.

In accordance with one or more aspects, the systems and methods disclosed herein provide the ability for a companion device (also referred to herein as an authentication device) to provide meaningful initial notification to a user by receiving information (after designating itself) via a secure channel and by waiting to provide initial notification on the companion device until the user temporarily "designates" that device to receive notification (e.g., by picking up the device or turning on a display).

In accordance with one or more aspects, the systems and methods disclosed herein may also allow for relay operation between multiple companion devices (such as smartphones and smartwatches) to allow the smartwatch to act as an authentication device providing companion device authentication via the smartphones.

Although a single companion device is shown in the examples of fig. 3-6 proximate to the electronic device 104, one or more additional devices may also be proximate to the electronic device 104 and receive the beacon 400. These additional devices may include devices that are eligible to provide companion device authentication (e.g., devices previously paired, home or family member devices, devices on the same network as the electronic device, or other devices registered to the same user as the user of the electronic device 104 or the host user), and/or devices that are ineligible to provide companion device authentication (e.g., devices that are not previously paired with the electronic device 104, that are not connected to the same wireless network, and/or that are not registered as other users of the device of the home or family member).

Although both the eligible and ineligible devices may receive the beacon 400 (e.g., and in some implementations specify themselves), because the electronic device 104 does not have encryption information for establishing a secure direct connection with the ineligible device, the electronic device 104 will not be able to provide an accompanying device authentication request to the ineligible device. In this way, the disqualified device is prevented from receiving any information indicative of activity at the electronic device 104 (e.g., because the beacon is a generic beacon that does not include specific information about the request, application, or device), and the disqualified device does not waste power and computing resources to generate notifications of requests from the electronic device 104.

Fig. 7 illustrates a flow diagram of an exemplary process 700 for performing companion device authentication in accordance with one or more implementations. For purposes of explanation, the process 700 is described herein primarily with reference to the electronic device 104, the electronic device 106, the content provider 112, and the cloud-based service 114 of fig. 1 and 2. However, the process 700 is not limited to the electronic device 104, the electronic device 106, the content provider 112, and the cloud-based service 114 of fig. 1 and 2, and one or more blocks (or operations) of the process 700 may be performed by one or more other suitable devices and/or used to authenticate with other devices or services. For further explanation purposes, the blocks of process 700 are described herein as occurring sequentially or linearly. However, multiple blocks of process 700 may occur in parallel. Furthermore, the blocks of process 700 need not be performed in the order shown, and/or one or more blocks of process 700 need not be performed and/or may be replaced by other operations.

At block 702, a system process of a device (e.g., electronic device 104) receives a request for authentication information for an application (e.g., application 302) on the device from the application. The application may be associated with, for example, a content provider (e.g., content provider 112) or a cloud-based service (e.g., cloud-based service 114).

At block 704, in response to the request, the device may broadcast a beacon (e.g., beacon 400) to one or more proximate devices for accompanying device authentication of the application. In one or more implementations, the beacon may not contain information identifying the application or device.

At block 706, the system process of the device may receive a designation (e.g., designation signal 500) from one of the one or more proximate devices to provide concomitant device authentication to the one of the one or more proximate devices (e.g., electronic device 106).

In response to receiving the designation, the device may cease broadcasting of the beacon at optional block 708, establish a secure direct peer-to-peer channel (e.g., secure direct connection 600) with the one of the one or more proximate devices using previously stored encryption information (e.g., encryption information 308 and/or 310 as described above in connection with fig. 3) associated with the one of the one or more proximate devices at block 710, and provide information associated with the application (e.g., name or title of the application) and the request for authentication (e.g., authentication request 602) to the one of the one or more proximate devices via the secure direct peer-to-peer channel at block 712. For example, in one or more implementations, prior to a request for authentication information, a device may pair with the one of the one or more proximate devices and store encrypted information associated with the one of the one or more proximate devices based on the pairing.

In various implementations, the one of the one or more proximity devices may be a device of a registered member of a user of the device, another device of a user of the device, or a device that has been previously paired with the device. For example, the device may be a device of the first user and the other device may be a device associated with a member of the first user's home or the first user's home.

At block 714, in response to providing the information, the system process of the device may receive authentication information (e.g., a token, password, or other authentication information) for the application from the one of the one or more proximate devices. In one or more implementations, the device is associated with a first user account (e.g., a first user account of a user of the device) and the authentication information is associated with a second user account (e.g., a second user account of a user of the one or more proximate devices). For example, the first user account may be an account with a cloud-based service (e.g., cloud-based service 114) and the second user account may be an account with a content provider. In one or more implementations, a user of the one or more proximate devices may also have an account (e.g., a third account) for the cloud-based service. The one or more proximate devices and/or another device may log into and/or register with an account (e.g., a third account) for the cloud-based service.

At block 716, the received authentication information may be provided from the system process to the application. As an example, the authentication information may include a token or password that may be used by another device to authenticate a user account of the application.

At optional block 718, the application may perform authentication using the received authentication information. Performing authentication may include, for example, providing authentication information received from another device to a server (e.g., content provider 112 and/or cloud-based service 114) associated with the application. Once the information is authenticated, the application may provide access to the content and/or services based on the authentication.

Fig. 8 illustrates a flow diagram of an example process 800 for performing companion device authentication at an authentication device in accordance with one or more implementations. For purposes of explanation, the process 800 is described herein primarily with reference to the electronic device 104, the electronic device 106, the content provider 112, and the cloud-based service 114 of fig. 1 and 2. However, the process 800 is not limited to the electronic device 104, the electronic device 106, the content provider 112, and the cloud-based service 114 of fig. 1 and 2, and one or more blocks (or operations) of the process 800 may be performed by one or more other suitable devices and/or used to authenticate with other devices or services. For further explanation purposes, the blocks of process 800 are described herein as occurring sequentially or linearly. However, multiple blocks of process 800 may occur in parallel. Furthermore, the blocks of process 800 need not be performed in the order shown, and/or one or more blocks of process 800 need not be performed and/or may be replaced by other operations.

At block 802, an electronic device (e.g., electronic device 106) receives a beacon (e.g., beacon 400) from another device (e.g., electronic device 104) for an application (e.g., application 302) at the other device to accompany device authentication. In one or more implementations, the electronic device does not have local access to the application (e.g., because the application is not installed at the electronic device or updated at the electronic device).

At block 804, the electronic device receives a user input indicating the electronic device for providing a designation accompanying device authentication prior to displaying the notification related to the beacon. The user input may include movement of the device (e.g., as a result of the user picking up or lifting the device for viewing, as indicated by a motion sensor such as an IMU of the device), unlocking of the device, or other active or passive user input to the device prior to providing any external notification of a beacon to the user. For example, the user input may be movement of the electronic device prior to display of the user notification.

At block 806, in response to receiving the beacon and the user input, the electronic device may send a designation signal (e.g., designation signal 500) to another device. The electronic device may then establish a secure direct connection with another device.

At block 808, the electronic device can receive information associated with the companion device authentication request in response to sending the designation signal (e.g., and via the secure direct connection). For example, this information may be received in an authentication request, such as authentication request 602 of fig. 6. As described above in connection with, for example, fig. 6, the authentication request may include information for providing meaningful notifications to a user of the electronic device, such as a name or title of an application for which authentication is desired, and/or an identifier of another device. In one or more implementations, receiving information associated with the companion device authentication may include receiving the information in a companion device authentication request.

At block 810, the electronic device can display a user notification (e.g., initial notification 604) using the received information. For example, the user notification includes a name or title of the application at the other device and an identifier of the other device.

In one or more implementations, after displaying the user notification, the electronic device can receive user input indicating acceptance of the companion device authentication request. The electronic device may then obtain authentication information stored at the electronic device and provide the authentication information to another device. For example, an electronic device may be associated with a first user account (e.g., a first user account of a first user) and another device may be associated with a second user account (e.g., a second user account of a second user). In one or more implementations, the authentication information may include a token corresponding to a first user account of the first user. In one or more implementations, the authentication information can include a password. For example, the authentication information may include a password associated with a third user account of the first user, the third user account being associated with the content provider. In one or more other implementations, the electronic device can provide redirection to a web page for accompanying device authentication (e.g., when the electronic device does not have a token or password that can provide authentication of an application locally stored at the electronic device).

Various examples are described in connection with fig. 3-8, wherein an companion device is used to provide authentication operations for another device to log in or log into an account or service. However, as described herein, accompanying device approval and/or authentication may also be provided by the subject technology for an approval process, such as for approving a purchase, approving a download and/or installation of an application and/or other software, approving terms and conditions, and/or other approval processes.

For example, fig. 9 illustrates an example in which the electronic device 104 is proximate to the electronic device 104 when a user is attempting to perform a purchase using the electronic device 106. For example, the user may be attempting to rent a movie for streaming with the electronic device 104, attempting to purchase a game or application for the electronic device 104, or attempting to make any other purchase (e.g., an in-application purchase) using the electronic device 104. In the example of fig. 9, the purchase has been initiated by the user at the electronic device 104. For example, when the user of the electronic device 104 is the current user of the electronic device 104, the user of the electronic device 106 may have selected a movie purchased or rented at the electronic device 104.

As shown in fig. 9, in response to initiating a purchase at the electronic device 104, the electronic device 104 may initiate a purchase with a merchant service (such as the merchant server 121). The merchant server 121 may provide an authorization request (e.g., a cryptographic challenge) for the purchase to the electronic device 104. In one or more implementations, merchant server 121 may determine that electronic device 104 is eligible to delegate purchase authorization based on the purchase occurrence. For example, the merchant server 121 may inform the electronic device 104 (e.g., using information included with the authorization request) that delegated authorization is an option for completing the purchase.

As shown, the electronic device 104 may provide a notification 922, such as using a display 300 connected to or integrated with the electronic device 104. As shown in fig. 9, the electronic device 104 may have previously stored encryption information 310 that may be used to establish a secure direct connection (e.g., a secure direct peer-to-peer channel) with the electronic device 106. Fig. 9 also shows how the electronic device 106 may have previously stored encryption information 308 that may be used to establish a secure direct connection with the electronic device 104. For example, before a purchase is initiated at the electronic device 104, the electronic device 104 and the electronic device 106 may have previously exchanged and stored encryption information 308 and 310 (e.g., public keys, link keys, etc.) that may be later used to establish a secure direct peer-to-peer channel. For example, the encryption information 308 and 310 may have been previously exchanged as part of a previous pairing operation, or as part of a registration or login operation, to register or login the device to a public user account and/or to a device that is a household or member of a household. In one or more implementations, the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 by a direct peer-to-peer connection between the electronic devices 104 and 106, and/or the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 by a server-based transport mechanism.

For example, the electronic device 104 may have been previously paired with the electronic device 106 and exchanged for encryption information that may be stored for later establishment of a secure direct connection. In another example, the electronic device 106 may be a device associated with a user account of a current user of the electronic device 104 (e.g., the electronic device 104 and the electronic device 106 may be registered devices of the same user, and if one or more of the electronic device 106 and the electronic device 104 are multi-user devices, the same user may be the current user of both devices).

In the example of fig. 9, the display 320 of the electronic device 106 is inactive and the notification 922 provided by the electronic device 104 includes a request to the user indicating whether approval to use another device purchase (e.g., with device approval) is desired. In the example of fig. 9, notification 922 includes selectable option 904 requesting an accompanying device purchase approval (e.g., "yes") and selectable option 906 rejecting an accompanying device purchase approval (e.g., "no"). However, selectable options 904 and 906 are merely illustrative, and other or different selectable options for requesting an accompanying device purchase approval may be provided. In one or more implementations, additional options for completing a purchase using only the electronic device 104 (e.g., by directly entering a password into the electronic device 104) may also be included or included with the notification 922.

Fig. 10 illustrates an operational scenario in which, in response to receiving user input (e.g., selection of selectable option 904) indicating that a concomitant device authorization for purchase is desired, electronic device 104 may provide a purchase handoff to electronic device 106 (e.g., through secure direct peer-to-peer connection 600 established as described above in connection with fig. 6). Purchase handoff may be or include a request for companion device approval provided to any or all electronic devices proximate to the electronic device 104 and/or associated with the same user (e.g., a proximate electronic device logged into the same user account as the current user of the electronic device 104). For example, in one or more implementations, the electronic device 104 may have multiple registered users, and may only provide purchase handoffs to the electronic device of the current user of the multiple users, and not to any devices of any other users of the electronic device 104 (e.g., even if devices of other users of the electronic device 104 are proximate to and/or paired with the electronic device 104). In this way, purchase handoff of a user's purchase may include information identifying the purchase without exposing any personal user information associated with the purchase to any device other than the user's device. As other examples, in one or more implementations, the request may be provided to any proximate device, any previously paired proximate device, any proximate device associated with the same user account as any profile on the electronic device 104, any proximate device in the same group (e.g., home) as the current profile on the electronic device 104, and/or any other device associated with and/or proximate to the electronic device 104.

As shown in fig. 10, in response to receiving a purchase handoff from electronic device 104, electronic device 106 may provide notification 1004 (e.g., using display 320) that includes text "do you want to approve the purchase of device 2 using this device? ". In this example, "device 2" corresponds to the electronic device 104. The purchase handoff may include information associated with the purchase, such as the name of the application at the electronic device 104 in which the purchase was initiated and/or other metadata for the purchase. For example, for the purchase operations shown in fig. 9 and 10, the purchase handoff may include a purchase price, an age level associated with the purchase, a purchase title, and/or other metadata associated with the purchase. The notification 1004 may also include some or all of the metadata received from the electronic device 104 in the purchase handoff, such as information identifying the purchase and/or the purchase quantity. In the example of fig. 10, notification 1004 includes selectable option 1006 to proceed with the companion device purchase approval (e.g., "yes") and selectable option 1008 to decline the companion device purchase approval (e.g., "no"). However, other or different selectable options may be provided to continue (accept) or reject the companion device purchase approval.

In one or more implementations, to complete selection of selectable option 1006 to continue with accompanying device approval (e.g., to perform a delegated authentication operation to answer a cryptographic challenge provided to electronic device 104 from server 121 and handed over from electronic device 104 to electronic device 106), electronic device 106 may request user authentication at electronic device 106 (e.g., where electronic device 106 is locked upon receipt of a purchase handoff). For example, in response to receiving a selection of selectable option 1006 (or in other cases before receiving the selection, such as when the device is unlocked for another reason before receiving a purchase handoff), electronic device 106 may provide the user with an option to provide biometric authentication information (e.g., a fingerprint or facial scan) and/or a password for electronic device 106 in order to unlock electronic device 106 to continue with accompanying device approval at electronic device 106.

In response to accepting an option to proceed with the attendant purchase approval (e.g., selectable option 1006) and/or in response to receiving authentication information for accessing electronic device 106, electronic device 106 may provide purchase authorization (e.g., including an indication of approval and/or including user authentication information) to merchant server 121 after authenticating the user at electronic device 106. In one or more implementations, the electronic device 106 can utilize the same previously obtained authorization information (e.g., biometric information or password information) that has been established on the device (e.g., to unlock the device) to authenticate the user as authorized to make purchases with the electronic device 106. In one or more other implementations, the electronic device 106 may require additional authentication of the user before providing purchase authorization to the merchant server 121. For example, the user of the electronic device 106 may provide a password for the user account, may enter new payment information, or may (e.g., again) provide other authentication information such as biometric authentication information (e.g., a fingerprint or facial scan) to authenticate the user as authorized to make purchases with the electronic device 106. For example, in various operational scenarios, the user account settings and/or user device settings may determine whether authentication information of the unlocking device is sufficient to authorize a purchase and/or whether additional authentication information is needed or re-entered for each new purchase or for a purchase initiated some time since the last purchase authorization. Upon receipt of the user authentication at the electronic device 106, the electronic device 106 may provide the merchant server 121 with purchase authorization, and the merchant server may return a token (e.g., a delegate token) to the electronic device 106 for purchase (e.g., after processing a payment for the purchase with the payment server).

The electronic device 106 may then provide a token for purchase to the electronic device 104 via the secure direct peer-to-peer connection 600, and the electronic device 104 may use the token to complete the purchase with the merchant server 121. For example, by providing a token from the electronic device 104 to the merchant server 121, the merchant server 121 may identify authorized purchases to the electronic device 104 even though a persistent connection with the electronic device 104 is not maintained during the purchase operation.

Although the examples of fig. 9 and 10 describe attendant device approval for purchases, this is merely illustrative and attendant device approval and/or authentication for other operations may also be provided. For example, in one or more implementations, the operations described in connection with fig. 9 and 10 may also be used to provide companion device approval for operations other than purchasing, such as approval operations for viewing user-related information, such as subscription information or other private information, approval operations for terms and conditions (e.g., for accepting terms and conditions for accessing media or other content via a smart speaker), and/or approval operations for downloading and/or installing software, such as applications (e.g., free applications not associated with purchasing).

FIG. 11 illustrates a flow diagram of an example process 1100 that may be performed by a requesting device with attendant device approval operations in accordance with one or more implementations. For purposes of explanation, process 1100 is described herein primarily with reference to electronic device 104, electronic device 106, and merchant server 121 of fig. 1, 9, and 10. However, process 1100 is not limited to electronic device 104, electronic device 106, and merchant server 121 of fig. 1, 9, and 10, and one or more blocks (or operations) of process 1100 may be performed by and/or used to authenticate with one or more other suitable devices or services. For further explanation purposes, the blocks of process 1100 are described herein as occurring sequentially or linearly. However, multiple blocks of process 800 may occur in parallel. Furthermore, the blocks of process 1100 need not be performed in the order shown, and/or one or more blocks of process 1100 need not be performed and/or may be replaced by other operations.

At block 1102, a device associated with a user (e.g., electronic device 104) may receive a request to initiate an approval process (e.g., a purchase or other approval operation) with a server, such as a merchant server (e.g., merchant server 121).

At block 1104, the device may establish a secure direct peer-to-peer channel with one or more proximate devices (e.g., electronic device 106) that are also associated with the user using previously stored encryption information associated with the one or more proximate devices. In one or more implementations, prior to establishing the secure direct peer-to-peer channel, the device may provide a notification (e.g., notification 922) that includes a user-selectable option (e.g., selectable option 904) to complete the initiated approval process (e.g., purchase) using the one or more proximate devices.

At block 1106, the device may provide a request for companion device approval (e.g., for purchase or other approval operations) to one or more proximate devices also associated with the user (e.g., the same user associated with a single public user account) over a secure direct peer-to-peer channel (e.g., approve a handoff such as a purchase handoff).

At block 1108, the device may receive a token (e.g., representative token) for an approval process (e.g., for purchase) from one of the one or more proximate devices in response to the request for companion device approval and at the device via a secure direct peer-to-peer channel. For example, the token may be an encrypted string that has been provided from the server to the one of the one or more proximate devices (e.g., in the body of a hypertext transfer protocol (HTTP) response from the server) and then provided as an HTTP header from the one of the one or more proximate devices to the device. For example, the token may include and/or be provided with identification information of the approval process (e.g., identification information of the purchase).

At block 1110, the device may provide a token to the server to complete the approval process (e.g., purchase).

FIG. 12 illustrates a flow diagram of an example process 1200 that may be performed by an approval device to accompany device approval operations in accordance with one or more implementations. For purposes of explanation, the process 1200 is described herein primarily with reference to the electronic device 104, the electronic device 106, and the merchant server 121 of fig. 1, 9, and 10. However, process 1200 is not limited to electronic device 104, electronic device 106, and merchant server 121 of fig. 1, 9, and 10, and one or more blocks (or operations) of process 1200 may be performed by one or more other suitable devices and/or used to authenticate with other devices or services. For further explanation purposes, the blocks of process 1200 are described herein as occurring sequentially or linearly. However, multiple blocks of process 1200 may occur in parallel. Moreover, the blocks of process 1200 need not be performed in the order shown, and/or one or more blocks of process 1200 need not be performed and/or may be replaced by other operations.

At block 1202, a device of a user (e.g., electronic device 106) may receive an approval handover (e.g., a purchase handover as described in the examples of fig. 10 and 11) from a proximity electronic device of the user (e.g., electronic device 104) associated with an approval process (e.g., purchase or other approval operation) initiated by the proximity electronic device to a server, such as a merchant server (e.g., merchant server 121). The device may also use previously stored encryption information associated with the proximate electronic device to establish a secure direct peer-to-peer channel between the device and the proximate electronic device, such as a secure direct connection or a secure connection through one or more servers. In one or more implementations, approval of the handover may be received over a secure direct peer-to-peer channel.

At block 1204, in response to receiving the approval handover, the device may provide approval authorization information from the device to the server. The device may obtain user approval to perform an approval process associated with the handover, and may obtain user authentication before providing approval authorization information to the server. For example, in one or more implementations, the device may provide a notification (e.g., notification 1004) prior to providing the approval authorization information to the server, the notification including a request for approval by a user using an approval process of the device. The device may receive user approval from the user at the device, authenticate the user with the device (e.g., using authentication credentials such as a password or passcode stored at the device or entered by the user, and/or biometric authentication obtained at the device), and provide approval authorization information to the server in response to authenticating the user. In one or more implementations, the approval authority information may include or facilitate access to payment information that may be used to process payment for a service with a payment server.

At block 1206, the device may receive a token corresponding to the purchase from a server at the device in response to providing the approval authorization information. The token may be generated and/or validated by the server prior to providing the token to the device. For example, the token may be provided to the device as an encrypted string in the body of the HTTP response from the server.

At block 1208, the device may provide the token to the proximate electronic device in order to complete the approval process by the proximate electronic device and the server. In one or more implementations, the token may be provided from the device to the proximate electronic device via a secure direct peer-to-peer channel. For example, the encrypted string received from the server may be provided from the device to the proximate electronic device as an HTTP header sent to the proximate electronic device via a secure direct peer-to-peer channel.

As described above, one aspect of the subject technology is to collect and use data available from specific and legal sources for accompanying device authentication. The present disclosure contemplates that in some instances, the collected data may include personal information data that uniquely identifies or may be used to identify a particular person. Such personal information data may include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, encrypted information, data or records related to the user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

The present disclosure recognizes that the use of such personal information data in the present technology may be used to benefit users. For example, personal information data may be used to establish a secure direct peer-to-peer connection between a device and a companion device to exchange authentication information. Thus, the use of such personal information data can facilitate authentication operations. In addition, the present disclosure contemplates other uses for personal information data that are beneficial to the user. For example, health and fitness data may be used according to user preferences to provide insight into their overall health condition, or may be used as positive feedback to individuals who use technology to pursue health goals.

The present disclosure contemplates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will adhere to established privacy policies and/or privacy practices. In particular, it would be desirable for such entity implementations and consistent applications to generally be recognized as meeting or exceeding privacy practices required by industries or governments maintaining user privacy. Such information about the use of personal data should be prominent and easily accessible to the user and should be updated as the collection and/or use of the data changes. The user's personal information should be collected only for legitimate use. In addition, such collection/sharing should only occur after receiving user consent or other legal basis specified in the applicable law. In addition, such entities should consider taking any necessary steps to defend and secure access to such personal information data and to ensure that others who have access to personal information data adhere to their privacy policies and procedures. In addition, such entities may subject themselves to third party evaluations to prove compliance with widely accepted privacy policies and practices. In addition, policies and practices should be tailored to the particular type of personal information data being collected and/or accessed and adapted to applicable laws and standards, including jurisdictional-specific considerations that may be employed to impose higher standards. For example, in the united states, the collection or acquisition of certain health data may be governed by federal and/or state law, such as the health insurance flow and liability act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be processed accordingly.

In spite of the foregoing, the present disclosure also contemplates embodiments in which a user selectively prevents use or access to personal information data. That is, the present disclosure contemplates that hardware elements and/or software elements may be provided to prevent or block access to such personal information data. For example, for accompanying device authentication, the present technology may be configured to allow a user to choose to "opt-in" or "opt-out" to participate in the collection of personal information data during or at any time subsequent to the registration service. In addition to providing the "opt-in" and "opt-out" options, the present disclosure also contemplates providing notifications related to accessing or using personal information. For example, the user may be notified that his personal information data will be accessed when the application is downloaded, and then be reminded again just before the personal information data is accessed by the application.

Further, it is an object of the present disclosure that personal information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use. Once the data is no longer needed, risk can be minimized by limiting the data collection and deleting the data. In addition, and when applicable, included in certain health-related applications, the data de-identification may be used to protect the privacy of the user. De-identification may be facilitated by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at a city level instead of at an address level), controlling how data is stored (e.g., aggregating data among users), and/or other methods such as differentiated privacy, as appropriate.

Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that the various embodiments may be implemented without accessing such personal information data. That is, various embodiments of the present technology do not fail to function properly due to the lack of all or a portion of such personal information data.

Fig. 13 illustrates an electronic system 1300 that can be used to implement one or more implementations of the subject technology. The electronic system 1300 may be, and/or may be part of, one or more of the electronic devices 102-107, the content provider 112, the cloud-based service 114, and/or the merchant server 121 shown in fig. 1. Electronic system 1300 may include various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 1300 includes a bus 1308, one or more processing units 1312, a system memory 1304 (and/or buffers), a ROM 1310, a persistent storage device 1302, an input device interface 1314, an output device interface 1306, and one or more network interfaces 1316, or subsets and variations thereof.

Bus 1308 generally represents all system, peripheral devices, and chipset buses that communicatively connect many of the internal devices of electronic system 1300. In one or more implementations, a bus 1308 communicatively connects one or more processing units 1312 with the ROM 1310, the system memory 1304, and the persistent storage 1302. One or more processing units 1312 retrieve the instructions to be executed and the data to be processed from these various memory units in order to perform the processes of the subject disclosure. In different implementations, one or more of the processing units 1312 may be a single processor or a multi-core processor.

ROM 1310 stores static data and instructions that are required by one or more processing units 1312 and other modules of electronic system 1300. On the other hand, persistent storage 1302 may be a read-write memory device. Persistent storage 1302 may be a non-volatile memory unit that stores instructions and data even when electronic system 1300 is turned off. In one or more implementations, a mass storage device (such as a magnetic or optical disk and its corresponding disk drive) may be used as persistent storage 1302.

In one or more implementations, removable storage devices (such as floppy disks, flash memory drives, and their corresponding disk drives) may be used as persistent storage 1302. As with persistent storage 1302, system memory 1304 may be a read-write memory device. However, unlike persistent storage 1302, system memory 1304 may be a volatile read-write memory, such as random access memory. The system memory 1304 may store any of the instructions and data that may be needed by the one or more processing units 1312 at runtime. In one or more implementations, the processes of the subject disclosure are stored in system memory 1304, persistent storage 1302, and/or ROM 1310. One or more processing units 1312 retrieve the instructions to be executed and the data to be processed from these various memory units in order to perform one or more embodied processes.

The bus 1308 is also connected to an input device interface 1314 and an output device interface 1306. The input device interface 1314 enables a user to communicate information to the electronic system 1300 and to select commands. Input devices that may be used with input device interface 1314 may include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 1306 may enable, for example, the display of images generated by the electronic system 1300. Output devices that may be used with output device interface 1306 may include, for example, printers and display devices, such as Liquid Crystal Displays (LCDs), light Emitting Diode (LED) displays, organic Light Emitting Diode (OLED) displays, flexible displays, flat panel displays, solid state displays, projectors, or any other device for outputting information. One or more implementations may include a device that serves as both an input device and an output device, such as a touch screen. In these implementations, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input.

Finally, as shown in fig. 13, the bus 1308 also couples the electronic system 1300 to one or more networks and/or to one or more network nodes, such as the content provider 112 shown in fig. 1, through one or more network interfaces 1316. In this manner, electronic system 1300 may be part of a computer network, such as a LAN, a wide area network ("WAN") or an intranet, or may be part of a network of networks, such as the Internet. Any or all of the components of the electronic system 1300 may be used with the subject disclosure.

According to aspects of the present disclosure, there is provided a method comprising receiving, at a system process of a device, a request for authentication information of an application on the device from the application; broadcasting a beacon from the device to one or more neighboring devices for companion device authentication of the application in response to the request; receiving, by the system process of the device, a designation of one of the one or more proximate devices to provide the companion device authentication from the one of the one or more proximate devices; in response to receiving the designation, by the device: stopping broadcasting of the beacon, using previously stored encryption information associated with the one of the one or more proximate devices to establish a secure direct peer-to-peer channel with the one of the one or more proximate devices, and providing information associated with the application and the request for authentication to the one of the one or more proximate devices via the secure direct peer-to-peer channel; receiving, by the system process of the device, the authentication information of the application from the one of the one or more proximate devices in response to providing the information; providing the received authentication information from the system process to the application; and performing authentication using the received authentication information using the application.

According to aspects of the present disclosure, there is provided a non-transitory machine-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving, at an electronic device, a beacon from another device for accompanying device authentication of an application at the other device; receiving a user input indicating a designation of the electronic device for providing authentication of the companion device prior to displaying the notification related to the beacon; transmitting a designation signal to the other device in response to receiving the beacon and the user input; receiving information associated with the companion device authentication in response to transmitting the designation signal; and displaying a user notification using the information.

According to aspects of the present disclosure, there is provided an electronic device comprising a memory and one or more processors, wherein the one or more processors are configured to receive a beacon from another device for accompanying device authentication of an application at the other device; receiving a user input indicating a designation of the electronic device for providing authentication of the companion device prior to displaying the notification related to the beacon; transmitting a designation signal to the other device in response to receiving the beacon and the user input; receiving information associated with the companion device authentication in response to transmitting the designation signal; and displaying a user notification using the received information.

According to aspects of the present disclosure, there is provided a method comprising: receiving, at a device associated with a user, a request to initiate an approval process with a server; establishing a secure direct peer-to-peer channel with one or more proximate devices also associated with the user using previously stored encryption information associated with the one or more proximate devices; providing a request for companion device approval from the device to one or more proximate devices also associated with the user in response to the request and over the secure direct peer-to-peer channel; receiving, at the device and in response to the request for attendant device approval, a token for the approval process from one of the one or more proximate devices via the secure direct peer-to-peer channel; and providing the token from the device to the server to complete the approval process.

According to aspects of the present disclosure, a method is provided that includes receiving, at a device of a user, from a neighboring electronic device of the user, an approval handover associated with an approval process initiated by the neighboring electronic device to a server; providing approval authorization information from the device to the server in response to receiving the approval handover; in response to providing the approval authority information, receiving a token corresponding to the purchase from the server at the device; and providing the token to the proximity electronic device to complete the approval process by the proximity electronic device and the merchant server.

Implementations within the scope of the present disclosure may be partially or fully implemented using a tangible computer-readable storage medium (or multiple tangible computer-readable storage media of one or more types) having one or more instructions written thereon. The tangible computer readable storage medium may also be non-transitory in nature.

A computer readable storage medium may be any storage medium that can be read, written, or otherwise accessed by a general purpose or special purpose computing device including any processing electronics and/or processing circuitry capable of executing the instructions. By way of example, and not limitation, computer readable media can comprise any volatile semiconductor memory such as RAM, DRAM, SRAM, T-RAM, Z-RAM and TTRAM. The computer readable medium may also include any non-volatile semiconductor memory, such as ROM, PROM, EPROM, EEPROM, NVRAM, flash, nvSRAM, feRAM, feTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, racetrack, FJG, and Millipede memories.

Furthermore, the computer-readable storage medium may include any non-semiconductor memory, such as optical disk storage, magnetic tape, other magnetic storage devices, or any other medium capable of storing one or more instructions. In one or more implementations, the tangible computer-readable storage medium may be directly coupled to the computing device, while in other implementations, the tangible computer-readable storage medium may be indirectly coupled to the computing device, for example, via one or more wired connections, one or more wireless connections, or any combination thereof.

The instructions may be directly executable or may be used to develop executable instructions. For example, the instructions may be implemented as executable or non-executable machine code, or may be implemented as high-level language instructions that may be compiled to produce executable or non-executable machine code. Further, the instructions may also be implemented as data, or may include data. Computer-executable instructions may also be organized in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, functions, and the like. As will be appreciated by one of skill in the art, details including, but not limited to, the number, structure, sequence, and organization of instructions may vary significantly without altering the underlying logic, functionality, processing, and output.

While the above discussion primarily refers to a microprocessor or multi-core processor executing software, one or more implementations are performed by one or more integrated circuits, such as an ASIC or FPGA. In one or more implementations, such integrated circuits execute instructions stored on the circuits themselves.

Those of skill in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application. The various components and blocks may be arranged differently (e.g., arranged in a different order, or divided in a different manner) without departing from the scope of the subject technology.

It should be understood that the specific order or hierarchy of blocks in the processes disclosed herein is an illustration of exemplary approaches. Based on design preference requirements, it should be understood that the particular order or hierarchy of blocks in the process may be rearranged or all illustrated blocks may be performed. Any of these blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous. Moreover, the partitioning of various system components in the implementations described above should not be understood as requiring such partitioning in all implementations, and it should be understood that program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

As used in this specification and any claims of this patent application, the terms "base station," "receiver," "computer," "server," "processor," and "memory" refer to an electronic or other technical device. These terms exclude a person or group of people. For purposes of this specification, the term "display" or "displaying" means displaying on an electronic device.

As used herein, the phrase "at least one of" after separating a series of items of any of the items with the term "and" or "is a modification of the list as a whole, rather than modifying each member (i.e., each item) in the list. The phrase "at least one of" does not require the selection of at least one of each item listed; rather, the phrase allows for the inclusion of at least one of any one item and/or the meaning of at least one of any combination of items and/or at least one of each item. For example, the phrase "at least one of A, B and C" or "at least one of A, B or C" each refer to a only, B only, or C only; A. any combination of B and C; and/or at least one of each of A, B and C.

The predicates "configured to", "operable to", and "programmed to" do not mean any particular tangible or intangible modification to a subject but are intended to be used interchangeably. In one or more implementations, a processor configured to monitor and control operations or components may also mean that the processor is programmed to monitor and control operations or that the processor is operable to monitor and control operations. Likewise, a processor configured to execute code may be interpreted as a processor programmed to execute code or operable to execute code.

Phrases such as an aspect, this aspect, another aspect, some aspects, one or more aspects, an implementation, the implementation, another implementation, some implementations, one or more implementations, an embodiment, the embodiment, another embodiment, some embodiments, one or more embodiments, a configuration, the configuration, other configurations, some configurations, one or more configurations, subject technology, disclosure, the present disclosure, other variations thereof, and the like are all for convenience and do not imply that disclosure involving such one or more phrases is essential to the subject technology nor that such disclosure applies to all configurations of the subject technology. The disclosure relating to such one or more phrases may apply to all configurations or one or more configurations. The disclosure relating to such one or more phrases may provide one or more examples. A phrase such as an aspect or some aspects may refer to one or more aspects and vice versa, and this applies similarly to other previously described phrases.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described herein as "exemplary" or as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, to the extent that the terms "includes," "has," and the like are used in either the description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element should be construed in accordance with the specification of 35u.s.c. ≡112 (f) unless the element is explicitly stated using the phrase "means for … …" or, in the case of method claims, the element is stated using the phrase "step for … …".

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in a singular value is not intended to mean "one only" but rather "one or more" unless specifically so stated. The term "some" means one or more unless specifically stated otherwise. The terminology of male (e.g., his) includes female and neutral (e.g., her and its), and vice versa. Headings and sub-headings (if any) are used for convenience only and do not limit the subject disclosure.

Claims

1. A method, comprising:

receiving, at a system process of a device, a request for authentication information of an application on the device from the application;

broadcasting a beacon from the device to one or more neighboring devices for concomitant device authentication of the application in response to the request;

Receiving, by the system process of the device, a designation of one of the one or more proximate devices to provide the companion device authentication from the one of the one or more proximate devices;

in response to receiving the designation, by the device:

establishing a secure direct peer-to-peer channel with said one of said one or more proximate devices using previously stored encryption information associated with said one of said one or more proximate devices, and

providing information associated with the application and the request for authentication to the one of the one or more proximate devices via the secure direct peer-to-peer channel;

receiving, by the system process of the device, the authentication information of the application from the one of the one or more proximate devices in response to providing the information; and

the received authentication information is provided from the system process to the application.

2. The method of claim 1, wherein the application is associated with a content provider or a cloud-based service.

3. The method of claim 2, wherein the device is associated with a first user account of the device, and wherein the authentication information is associated with a second user account of the one or more proximate devices.

4. The method of claim 3, wherein the first user account is an account for a cloud-based service, and wherein the second user account is an account for a content provider.

5. The method of claim 1, further comprising, prior to the request for the authentication information:

pairing the device with the one of the one or more nearby devices; and

the encrypted information associated with the one of the one or more proximate devices is stored based on the pairing.

6. The method of claim 1, wherein the device is a device of a first user and the one of the one or more proximate devices is a device associated with a member of a family of the first user or a home of the first user.

7. The method of claim 1, wherein the authentication information comprises a token or a password.

8. The method of claim 1, further comprising: in response to receiving the designation, broadcasting of the beacon is stopped by the device.

9. The method of claim 1, further comprising: and performing authentication by using the application program by using the received authentication information.

10. An electronic device, comprising:

a memory; and

one or more processors, wherein the one or more processors are configured to:

receiving a beacon from another device for accompanying device authentication of an application at the other device;

receiving a user input indicating a designation of the electronic device for providing the companion device authentication prior to displaying a notification related to the beacon;

transmitting a designation signal to the other device in response to receiving the beacon and the user input;

receiving information associated with the companion device authentication in response to transmitting the designation signal; and

and displaying a user notification by using the received information.

11. The electronic device of claim 10, wherein the user notification includes a name of the application at the other device and an identifier of the other device.

12. The electronic device of claim 10, wherein receiving the information associated with the companion device authentication comprises receiving the information in a companion device authentication request, and wherein the one or more processors are further configured to:

receiving a user input indicating acceptance of the companion device authentication request;

obtaining authentication information stored at the electronic device; and

the authentication information is provided to the other device.

13. The electronic device of claim 12, wherein the electronic device is associated with a first user account of a first user, and wherein the other device is associated with a second user account of a second user.

14. The electronic device of claim 13, wherein the authentication information comprises a token corresponding to the first user account of the first user.

15. The electronic device of claim 13, wherein the authentication information comprises a password associated with a third user account of the first user, the third user account associated with a content provider.

16. The electronic device of claim 12, wherein the authentication information comprises a password.

17. The electronic device of claim 10, wherein the electronic device does not have local access to the application.

18. The electronic device of claim 10, wherein the user input comprises movement of the electronic device prior to the display of the user notification.

19. The electronic device of claim 10, wherein receiving the information associated with the companion device authentication comprises receiving the information in a companion device authentication request, and wherein the one or more processors are further configured to:

receiving a user input indicating acceptance of the companion device authentication request; and

providing a redirection to a web page for the companion device authentication.

20. A non-transitory machine-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:

receiving, at an electronic device, a beacon from another device for accompanying device authentication of an application at the other device;

and displaying a user notification by using the information.

21. The non-transitory machine readable medium of claim 20, wherein the user notification comprises a title of the application at the other device and an identifier of the other device.

22. The non-transitory machine-readable medium of claim 20, wherein receiving the information associated with the companion device authentication comprises receiving the information in a companion device authentication request, and wherein the operations further comprise:

obtaining authentication information stored at the electronic device; and

the authentication information is provided to the other device.

23. A method, comprising:

receiving, at a device associated with a user, a request to initiate an approval process with a server;

establishing a secure direct peer-to-peer channel with one or more proximate devices that are also associated with the user using previously stored encryption information associated with the one or more proximate devices;

Providing a request for companion device approval from the device to one or more proximate devices also associated with the user in response to the request and over the secure direct peer-to-peer channel;

receiving, at the device and in response to the request for companion device approval, a token for the approval process from one of the one or more proximate devices via the secure direct peer-to-peer channel; and

the token is provided from the device to the server to complete the approval process.

24. The method of claim 23, wherein the token includes identification information of the approval process.

25. The method of claim 23, further comprising, prior to establishing the secure direct peer-to-peer channel: a notification is provided by the device, the notification including a user selectable option to complete the approval process initiated using the one or more proximate devices.

26. The method of claim 23, wherein the approval process comprises an approval process for a purchase, and wherein the token comprises a token for the purchase.

27. A method, comprising:

receiving, at a user's device, an approval handover associated with an approval process initiated by the proximity electronic device to a server from the user's proximity electronic device;

Providing approval authorization information from the device to the server in response to receiving the approval handover;

in response to providing the approval authorization information, receiving, at the device, a token from the server corresponding to the approval process; and

the token is provided to the proximate electronic device for completion of the approval process by the proximate electronic device and the server.

28. The method of claim 27, wherein the approval process comprises an approval process for purchase, the method further comprising:

providing, by the device and prior to providing the approval authorization information to the server, a notification including a request for approval of the user of the purchase using the device;

receiving the user approval from the user at the device;

authenticating the user with the device; and

the approval authority information is provided to the server in response to authenticating the user.

29. The method of claim 28, wherein authenticating the user comprises obtaining at least one of a password, a passcode, or biometric authentication information of the user with the device.

30. The method of claim 27, further comprising:

Establishing a secure direct peer-to-peer channel between the device and the proximate electronic device using previously stored encryption information associated with the proximate electronic device; and

the token is provided to the proximate electronic device via the secure direct peer-to-peer channel.