Mobile assisted television login using discovery and launch protocol
By detecting and displaying user input prompts on the second screen device, automatic user login for applications hosted on the first screen device is achieved, solving the cumbersome and insecure problems of manually entering authentication codes in existing technologies, and improving user experience and security.
Patent Information
- Application Number
- CN202311185507.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2017-05-23
- Filing Date
- 2018-03-06
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2038-03-06
AI Technical Summary
In existing technologies, the login process for users on screen devices is cumbersome and prone to errors. In particular, when automating user login for applications hosted on the first screen device, users are required to manually enter authentication codes, resulting in a time-consuming, error-prone, and insecure process.
The second screen device detects the authentication code sent by the first screen device, and when user input is presented, the application hosted on the second screen device presents user input prompts and receives user input to perform automatic user login.
It simplifies the user login process, improves security and ease of use, reduces the possibility of input errors, and increases user acceptance of the first-screen device-hosted application.
Smart Images

Figure CN117349816B_ABST
Abstract
Description
[0001] Divisional Statement
[0002] This application is a divisional application of Chinese Patent Application No. 201880028617.0, filed March 6, 2018, which is incorporated by reference in its entirety. TECHNICAL FIELD
[0003] The present disclosure relates to the field of assisted sign-in, and in particular, the present disclosure relates to the field of assisted sign-in to a first screen device. BACKGROUND
[0004] A first screen device, such as a network-connected television, can host an application. The application hosted by the first screen device can display data, such as media items, received from a server device via a network. A user can sign-in to the application hosted by the first screen device to display personalized data, such as the user's playlist, via the application. SUMMARY
[0005] The following is a simplified summary of the disclosure in order to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is neither intended to identify key or critical elements of the disclosure nor to delineate any scope of the particular implementations of the disclosure or any scope of the claims. Its sole purpose is to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.
[0006] In one aspect of the disclosure, a method is for facilitating automatic user sign-in into a first application hosted by a first screen device, and the method includes detecting, by a second screen device, a message sent by the first screen device over a network, the message including an authentication code provided by a server device to the first screen device; determining, by the second screen device and based on the message, that the first application hosted by the first screen device is requesting user authentication for the automatic user sign-in; presenting, via a second application hosted by the second screen device, a prompt for user input indicating user acceptance of the automatic user sign-in; receiving, at the second screen device, user input indicating the user's acceptance of the automatic user sign-in; and in response to the user input, sending the authentication code from the message from the second screen device to the server device to perform the user authentication for the automatic user sign-in into the first application hosted by the first screen device.
[0007] In one embodiment, the method further comprises: identifying, by the second screen device, the first screen device by sending a first simple service discovery protocol (SSDP) message to the first screen device via the network and receiving a second SSDP message from the first screen device via the network; and in response to the identification of the first screen device, sending, by the second screen device, a first message to the first screen device to determine whether the first screen device is requesting the user authentication for the automatic user login, wherein the message is sent by the first screen device in response to the sending of the first message.
[0008] In one embodiment, the user input further indicates a selection of an account, wherein the automatic user login into the first application is with respect to the account.
[0009] In one embodiment, sending the authentication code to the server device further comprises sending a selection of the account for the automatic user login.
[0010] In one embodiment, the message is a DIAL URL response to a discovery and launch (DIAL) uniform resource locator (URL) request sent by the second screen device.
[0011] In one embodiment, the determining that the first application is requesting the user authentication for the automatic user login comprises decoding the message to identify the authentication code.
[0012] In one embodiment, the server device is to perform the user authentication for a user login into the second application hosted by the second screen device prior to receipt of the user input indicating acceptance of the automatic user login by the user.
[0013] In one aspect of the disclosure, a non-transitory machine-readable storage medium storing instructions that, when executed, cause a processing device of a first screen device to perform operations for facilitating an automatic user login into a first application hosted by the first screen device, the operations comprising: sending, to a server device, a request for a user authentication for the automatic user login into the first application; receiving, from the server device, an authentication code; generating a message comprising the authentication code; sending, by the first screen device, the message over a network, intended for a second screen device to prompt a user of the second screen device to indicate acceptance of the automatic user login; and receiving, from the server device, credentials for performing the user authentication for the automatic user login into the first application, the received credentials indicating that the authentication code from the message has been provided to the server device by the second screen device.
[0014] In one embodiment, the operations further include receiving, via the first application, a second user input requesting the user authentication for the automatic user login into the first application prior to the sending of the request.
[0015] In one embodiment, the operations further include receiving, over the network, a first simple service discovery protocol (SSDP) message from the second screen device to identify the first screen device; sending, over the network, a second SSDP message to the second screen device in response to the first SSDP message, wherein the first screen device is to be identified by the second screen device in response to the sending of the second SSDP message; and receiving a first message from the second screen device in response to being identified by the second screen device, wherein the sending of the message is in response to the receiving of the first message.
[0016] In one embodiment, the message is to be detected by the second screen device; the prompt is to be presented by the second screen device for user input indicating acceptance of the automatic user login and selection of an account; and the automatic user login into the first application is with respect to the account.
[0017] In one embodiment, the authentication code and the selection of the account for the automatic user login are to be sent by the second screen device to the server device in response to the second screen device receiving the user input.
[0018] In one embodiment, the server device is to perform the user authentication for a user login into a second application hosted by the second screen device prior to the authentication code and the selection of the account for the automatic user login being sent by the second screen device to the server device.
[0019] In one embodiment, the message is a DIAL URL response to a discovery and launch (DIAL) uniform resource locator (URL) request sent by the second screen device.
[0020] In one aspect of the disclosure, a system includes a memory to store instructions to facilitate automatic user login into a first application hosted by a first screen device, and a processing device communicatively coupled to the memory to execute the instructions to receive, from the first screen device, a request for user authentication for the automatic user login into the first application hosted by the first screen device, generate an authentication code for the automatic user login into the first application hosted by the first screen device, send the authentication code to the first screen device intended for the first screen device to generate a message including the authentication code and send the message to a second screen device, receive the authentication code from the message from the second screen device, and in response to receiving the authentication code from the second screen device, send, to the first screen device, a credential to perform the user authentication for the automatic user login into the first application.
[0021] In one implementation, the message is to be detected by the second screen device, the prompt is to be presented by a second application hosted by the second screen device after detecting the message for user input indicating acceptance of the automatic user login, and the authentication code is sent by the second screen device to the processing device in response to the user input.
[0022] In one implementation, the user input further indicates a selection of an account, and the automatic user login into the first application is with respect to the account.
[0023] In one implementation, the selection of the account is sent by the second screen device to the processing device in response to the second screen device receiving the user input.
[0024] In one implementation, the processing device is to perform the user authentication for a user login into a second application hosted by the second screen device prior to sending the credential to the first screen device to perform the user authentication for the automatic user login into the first application.
[0025] In one implementation, the message is a DIAL URL response to a DIAL uniform resource locator (URL) request sent by the second screen device.
[0026] In another aspect of the disclosure, a method of facilitating automatic user login into a first application hosted by a first screen device includes sending, by the first screen device and to a server device, a request for user authentication for the automatic user login into the first application; receiving, by the first screen device from the server device, an authentication code; generating, by the first screen device, a message including the authentication code; sending, by the first screen device, the message via a network, intended for a second screen device to prompt a user of the second screen device to indicate acceptance of the automatic user login; and receiving, by the first screen device from the server device, credentials for performing the user authentication for the automatic user login into the first application, the received credentials indicating that the authentication code from the message has been provided to the server device by the second screen device.
[0027] In another aspect of the disclosure, a method of facilitating automatic user login into a first application hosted by a first screen device includes receiving, at a server from the first screen device, a request for user authentication for the automatic user login into the first application hosted by the first screen device; generating, by the server, an authentication code for the automatic user login into the first application hosted by the first screen device; sending, by the server and to the first screen device, the authentication code, intended for the first screen device to generate a message including the authentication code and send the message to a second screen device; receiving, by the server from the second screen device, the authentication code from the message; and in response to receiving the authentication code from the second screen device, sending, by the server to the first screen device, credentials for performing the user authentication for the automatic user login into the first application.
[0028] In another aspect of the disclosure, a computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any aspect or embodiment described herein. In another aspect of the disclosure, a system includes a processing device communicatively coupled to a memory, the memory storing instructions that, when executed by the processing device, cause the processing device to perform a method according to any aspect or embodiment described herein. BRIEF DESCRIPTION OF DRAWINGS
[0029] In the drawings, the disclosure is illustrated by way of example and not by way of limitation in the accompanying figures.
[0030] Figure 1 is a block diagram illustrating an exemplary system architecture according to an embodiment of the disclosure.
[0031] Figure 2Ais a block diagram illustrating components and modules of a first screen device according to an embodiment of the present disclosure.
[0032] Figure 2B is a block diagram illustrating components and modules of a second screen device according to an embodiment of the present disclosure.
[0033] Figure 3 is a sequence diagram for facilitating automatic user login into a first application hosted by a first screen device according to an embodiment of the present disclosure.
[0034] Figures 4A to 4C is a flow diagram illustrating an example method of facilitating automatic user login into a first application hosted by a first screen device according to an embodiment of the present disclosure.
[0035] Figure 5 is an example flow diagram for facilitating automatic user login into a first application hosted by a first screen device according to an embodiment of the present disclosure.
[0036] Figure 6 is an example graphical interface for facilitating automatic user login into a first application hosted by a first screen device according to an embodiment of the present disclosure.
[0037] Figure 7 is an example graphical interface for facilitating automatic user login into a first application hosted by a first screen device according to an embodiment of the present disclosure.
[0038] Figure 8 is a block diagram illustrating one embodiment of a computer system according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0039] Aspects and embodiments of the present disclosure are directed to automatic sign-in into a first screen device. The first screen device can be a television device connected to a network ("smart TV"), an over-the-air (OTT) streaming device, a set-top box, a Blu-ray player, an operator box, etc. An operating system runs on the first screen device and can provide a platform for applications hosted by the first screen device. Applications can be pre-loaded on the first screen device via an application distribution platform and / or installed on the first screen device. Applications running on the first screen device can provide access to the platform via the network for many purposes such as navigation, storing and retrieving documents, distributed computing, etc. A user can sign-in to an application hosted by the first screen device and perform account authentication in the application hosted by the first screen device to access the platform, which enables access to facilities provided by the platform. However, sign-in and account authentication on the first screen device is typically a laborious process for the user.
[0040] Users typically interact with first screen devices and with applications hosted by first screen devices using infrared remote controls based on a directional pad (d-pad). The directional pad can be a flat four-way directional control with one button in each of four points (e.g., up, down, left, and right). Another button on the d-pad or remote control can be selected (e.g., an enter button). Applications can display an alphanumeric keyboard via the first screen device. One conventional form of authentication includes a user entering a user name and password by navigating to individual characters one at a time by selecting the up, down, left, and right buttons on the d-pad and then selecting the enter button to select the character. Navigating and selecting each character with a remote control can take a long time, is error prone, and hinders the user's use of the application hosted by the first screen device.
[0041] Another conventional form of authentication is cross-device assisted authentication into an application hosted by a first screen device. A user uses a remote control to request that a code be displayed on the first screen device. The user then starts a web browser on a mobile device and enters the specific web address of the activation page (e.g., web endpoint's domain.com / activation type) into the web browser via the mobile device character by character. The activation page prompts the user to enter a user name and password via the mobile device to log into an account. The activation page also prompts the user to enter the code displayed on the first screen device. After entering the web address, user name, password, and code into the mobile device, a server device can log the user into the application hosted by the first screen device. Entering the web address, user name, password, and code into the mobile device can be time consuming and error prone, and errors in the authentication process require the user to start over the authentication process, such that any network resources used in a failed authentication attempt are wasted and can even hinder the user's use of the application hosted by the first screen device. Furthermore, if a user makes multiple errors in authentication, they can be "locked out" from accessing their account until their password is reset, for example, by a system administrator.
[0042] Conventional forms of authentication are cumbersome from a technical security perspective and also from a user comprehension and ease of use perspective, presenting limitations and drawbacks. Users suffer from setup fatigue when using conventional forms of authentication. Fewer users will take the time to go through the process if it is not quick and easy. Conventional forms of authentication suffer from limited input options. Entering text, especially passwords, using a remote control is both difficult and awkward, and this can cause users to choose short passwords, reducing their security. Using a mobile device to enter a specific web address (which can be long and difficult to remember and type), a user name, a password, and a code before the code times out is difficult. Conventional forms of authentication also suffer from technical constraints. Due to policy and security, logging into an account is limited by some authentication servers to web pages hosted by the specific authentication server.
[0043] Aspects of the disclosure address the above and other deficiencies by facilitating automatic user login into a first application hosted by a first screen device. The first screen device can receive an authentication code from a server device, generate a message including the authentication code, and send the message. A second screen device (e.g., a smartphone, tablet computer, laptop, etc.) can receive the message, present a prompt for user input via a second application hosted by the second screen device, and receive user input indicating acceptance of the automatic user login by the user. In response to the user input, the second screen device can send the authentication code from the message to the server device to perform user authentication for the automatic user login into the first application. In one implementation, the prompt for user input is an accept element corresponding to an account, and the user input is a selection (e.g., a tap) of the accept element. From the user's perspective, the automatic user login is easy to understand, easy to find, and easy to use. It is also secure because the authentication code does not require to be easily remembered and entered by the user, so it can be chosen based only on the desired level of security, and the need to type with a cumbersome directional keypad remote control is reduced or eliminated altogether.
[0044] Accordingly, by facilitating automatic user login into a first application hosted by a first screen device, the security of the user is significantly increased. At the same time, the login process becomes significantly easier for the user, so that more users can log into the application hosted by the first screen device, which in turn increases the popularity of the first screen device and the application hosted by the first screen device.
[0045] Figure 1 An example system architecture 100 according to one implementation of the disclosure is illustrated. The system architecture 100 includes an application distribution server 110, a first screen device 120, an authentication server 130, a local network 140, a network 150, a data store 160, and a second screen device 170.
[0046] The application distribution server 110 can be one or more computing devices (such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, etc.), data stores (e.g., hard disks, memories, databases, etc.), networks, software components, and / or hardware components. The application distribution server 110 can be used to provide users with access to the applications 112 (e.g., the application distribution server 110 can host the applications 112). The application distribution server can provide the applications 112 to users (e.g., a user can select an application 112 and download the application 112 from the application distribution server 110 in response to a request or purchase of the application 112). The application distribution server 110 can be part of an application distribution platform (e.g., an application distribution service) that can allow users to consume, develop, upload, download, rate, share, search, upvote ("like"), downvote, and / or comment on the applications 112. The application distribution platform can also include a website (e.g., web page) or application backend software that can be used to provide users with access to the applications 112.
[0047] The application distribution server 110 can host content, such as the applications 112. The applications 112 can be digital content selected by a user, digital content provided by a user, digital content developed by a user, digital content uploaded by a user, digital content developed by a content provider (e.g., an application developer), digital content uploaded by a content provider (e.g., an application developer), digital content provided by the application distribution server 110, etc. Examples of the applications 112 include, without limitation, mobile applications, smart television applications, first screen device applications, second screen device applications, desktop applications, software applications, etc. The applications 112 can display social media updates, digital videos, digital movies, digital photographs, digital music, website content, social media updates, eBooks, eMagazines, digital newspapers, digital audio books, eJournals, web blogs, Really Simple Syndication (RSS) feeds, eComic books, software applications, etc.
[0048] The applications 112 can be consumed via a web browser on the first screen device 120 and the second screen device 170 and / or via an application store on the second screen device 170. As used herein, "application," "mobile application," "smart television application," "first screen device application," "second screen device application," "desktop application," "software application," "digital content," "content," and "content item" can include an electronic file that can be executed or loaded using software, firmware, or hardware configured to present the application 112 to an entity. In one implementation, an application distribution platform can use the data store 160 to store the applications 112. The applications 112 can be presented to and / or downloaded by users of the first screen device 120 and the second screen device 170 from the application distribution server 110 or the application distribution platform. According to aspects of the disclosure, the applications 112 can allow users to interact with prompts, watch content, make purchases, participate in conversations, etc. The applications 112 can include an embedded media player (among other components) to play content provided by a content platform or stored locally. The content platform (not shown) can be, for example, a media sharing platform or a social networking platform, and can be used to provide users with access to and / or provide media items to users. For example, the content platform can allow users to consume, upload, search for, like ("like"), dislike, and / or comment on media items. The application distribution server 110 can be part of the content platform, a standalone system, or part of a different platform.
[0049] The application distribution server 110 can host a set of applications 112 formatted respectively for a corresponding device, a corresponding operating system, a corresponding version of an operating system, a corresponding browser, a corresponding size of a user interface, and the like. For example, the application distribution server 110 can host a set of applications 112 including a first application and a second application. The first application can correspond to the first screen device 120 (e.g., a smart television) and the second application can correspond to the second screen device 170 (e.g., a mobile device). The first and second applications can be associated with a content platform (e.g., a media sharing platform or a social networking platform) and can present content provided by the content platform. In response to the first screen device 120 sending a request for an application 112 associated with the content platform, the application distribution server 110 can identify the first application associated with the content platform and corresponding to the first screen device 120 (e.g., corresponding to a device type, an operating system type, a browser type, and the like of the first screen device 120) and send the first application 602 to the first screen device 120. In response to the second screen device 170 sending a request for an application 112 associated with the content platform, the application distribution server 110 can identify the second application associated with the content platform and corresponding to the second screen device 170 (e.g., corresponding to a device type, an operating system type, and the like of the second screen device 107) and send the second application 702 to the second screen device 170. In some implementations, if a user of the first screen device 120 is the same as a user of the second screen device 170, the first and second applications can be linked to the same account on the content platform (e.g., once the first and second applications are installed on the first screen device 120 and the second screen device 170, respectively).
[0050] In some implementations, the system architecture 100 can also include an authentication server 130 coupled to the first screen device 120 and the second screen device 170 via the network 150 to facilitate automatic user login into the first application hosted by the first screen device 120. In one implementation, the authentication server 130 can be part of the content platform. In another implementation, the authentication server 130 can be a standalone platform including one or more computing devices, such as a rack-mounted server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, and the like.
[0051] The authentication server 130 can include a user authentication manager 132. The user authentication manager 132 can receive a request from the first screen device 120 for user authentication for automatic user sign-in 602 into a first application hosted by the first screen device 120. The user authentication manager 132 can generate an authentication code 114 and send the authentication code 114 to the first screen device 120. The user authentication manager 132 can store the authentication code 114 in a data store 160. Subsequently, the user authentication manager can receive the authentication code 114 from the second screen device 170 and perform user authentication for automatic user sign-in 602 into the first application hosted by the first screen device 120. The user authentication manager 132 can compare the authentication code 114 received from the second screen device 170 to the authentication code 114 stored in the data store 160 to determine that the authentication codes match. The user authentication manager 132 can receive an indication of an account from the second screen device 170 and can perform user authentication for automatic user sign-in into the account in the first application 602.
[0052] The data store 160 can include an authentication code cache 123 to store authentication codes 114 generated by the authentication server 130 and sent to the first screen device 120.
[0053] The first screen device 120 can include a computing device such as a network-connected television ("smart TV"), a network-connected media player (e.g., a Blu-ray player), a set-top box, an over-the-air (OTT) streaming device, an operator box, and the like. The second screen device 170 can include a computing device such as a personal computer (PC), a laptop, a mobile phone, a smartphone, a tablet computer, a netbook computer, and the like. The first screen device 120 and the second screen device 170 and the second screen device 170 can be able to receive (e.g., download) applications 112 from the application distribution server 110 over the network 150. The first screen device 120 and the second screen device 170 can contact servers (e.g., the application distribution server 110, the authentication server 130, and the like) and platforms (e.g., an application distribution platform, a media sharing platform, a social networking platform, and the like) via the network 150 and execute applications 112 independently of one another. For example, the first screen device 120 can launch an application 112 and a media server of a content platform can stream media content to the application 112 executing on the first screen device 120 without interaction with or assistance from the second screen device 170. The first screen device 120 can not have account / profile management software (e.g., can not include single sign-on (SSO) capabilities). The first screen device 120 and the second screen device 170 can be able to receive and send messages (e.g., SSDP messages, discovery and launch (DIAL) messages (e.g., DIAL URL queries, DIAL URL responses, and the like)) over the network 150 and / or the local network 140.
[0054] In response to the first screen device 120 and the second screen device 170 being located on the same network (e.g., a local network), the second screen device 170 can discover the first screen device 120 (e.g., using a protocol, using the DIAL protocol, etc.), search for (e.g., discover) the application 112 on the first screen device 120, launch the application 112 on the first screen device 120, and stop the application 112 on the first screen device 120. For example, the second screen device 170 can launch the application 112 on the first screen device 120 and send a URL to the first screen device 120 such that the first screen device can directly access the video file from the media server of the content platform via the URL. Independent of the second screen device 170, the first screen device 120 can also search for, launch, and stop the application 112 (e.g., a user can use a remote control to search for, launch, and stop the application 112 on the first screen device 120). The application 112 can run on the first screen device 120 and receive data directly from the server device (e.g., rather than being streamed from the server device to the second screen device 170 and then to the first screen device 120). Running the application 112 on the first screen device 120 independent of the second screen device 170 is beneficial for situations when the local network 140 has low available bandwidth, the second screen device 170 has low capabilities (e.g., a low or dead battery on a mobile device). The application 112 can execute on the first screen device 120 at the same time that a different application 112 is executing on the second screen device 170. For example, the first screen device 120 can execute an application associated with a media sharing platform while the second screen device executes an application associated with a social networking platform.
[0055] The local network 140 can be a computing network that provides one or more communication channels between the first screen device 120 and the second screen device 170. In one example, the local network 140 can be a peer-to-peer network that does not rely on pre-existing network infrastructure (e.g., access points, switches, routers), and the first screen device 120 and the second screen device 170 can replace the networking infrastructure to route communications between user devices. The local network 140 can be a wireless network (e.g., an ad hoc wireless network) that is self-configuring and enables the first screen device 120 and the second screen device 170 to contribute to and dynamically connect and disconnect from the local network 140. In another example, the local network 140 can be a computing network that includes networking infrastructure that enables user devices to communicate with other user devices. In the latter example, the local network 140 can or can not be able to access a public network (e.g., the Internet). For example, a vehicle (e.g., a bus, a train) or a location (e.g., a classroom, a library, a coffee shop, etc.) can provide an access point or can act as an access point to enable user devices to communicate with each other without providing Internet access. Alternatively, the local network 140 can provide access to a larger network, such as the network 150 (e.g., the Internet). In one implementation, the local network 140 can be based on any wireless or wired communication technology and can connect a first user device directly or indirectly (e.g., involving intermediate user devices) to a second user device. Wireless communication technologies can include infrared, ultrasonic, or other technologies. Wired communications can include Universal Serial Bus (USB), Ethernet, RS232, or other wired connections. The local network 140 can be a single connection between two devices or can include multiple connections.
[0056] The network 150 can be a public network that provides the first screen device 120 and the second screen device 170 with access to the application distribution server 110, the authentication server 130, and other publicly available computing devices. The network 150 can include one or more wide area networks (WANs), local area networks (LANs), wired networks (e.g., Ethernet network), wireless networks (e.g., an 802.11 network or a Wi-Fi network), cellular networks (e.g., a Long Term Evolution (LTE) network), routers, hubs, switches, server computers, and / or combinations thereof.
[0057] Each of the first screen device 120 and the second screen device 170 can include an operating system that allows a user to execute applications 112. The applications 112 can include a media viewer, a web browser, and the like to present images, videos, audio, web pages, documents, and the like. In one example, the applications 112 can include a web browser that can access, retrieve, present, and / or navigate content served by a web server (e.g., web pages such as hypertext markup language (HTML) pages, digital media items, text conversations, notifications, and the like). The applications 112 can render, display, and / or present the content to a user. The applications 112 can include an embedded media player (e.g., a Flash® player or a HTML5 player) (e.g., embedded in a web page that can provide information about a product sold by an online merchant). In another example, the applications 112 can be a standalone application (e.g., a mobile application or app) that allows a user to view digital media items (e.g., digital videos, digital images, e-books, and the like) to participate in text conversations and / or receive prompts.
[0058] In the example shown in Figure 1 , the first screen device 120 can include a first application login component 122, a device identifier component 124, a message component 126, a prompt component 128, and a data store 129.
[0059] The first application login component 122 can manage requests to log in to a first application hosted by the first screen device 120, receive the authentication code 114, and receive credentials to log in to the first application. The device identifier component 124 can receive and send SSDP messages for the second screen device 170 to identify the first screen device. The message component 126 can receive, generate, and send messages (e.g., DIAL URL requests, DIAL URL responses, messages of another type of protocol, and the like) to transfer the authentication code 114 to the second screen device 170. The prompt component 128 can display prompts and receive user input.
[0060] The data store 129 can be a memory (e.g., a random access memory), a drive (e.g., a hard disk drive, a flash drive), a database system, or another type of component or device capable of storing data. The data store 129 can include multiple storage components (e.g., multiple drives or multiple databases) that can span multiple computing devices (e.g., multiple server computers).
[0061] In the example shown in Figure 1 , the second screen device 170 can include a second application login component 172, a device identifier component 174, a message component 176, a prompt component 178, and a data store 179.
[0062] The second application login component 172 can log into the second application hosted by the second screen device 170. The device identifier component 174 can send and receive SSDP messages to identify the first screen device 120 as being on the same network (e.g., the local network 140) as the second screen device 170. The message component 176 can send, receive, and decode messages (e.g., DIAL URL requests, DIAL URL responses, messages of another type of protocol, etc.) to determine the authentication code 114. The prompt component 178 can provide a prompt, receive user input indicating acceptance of user authentication for automatic login to the first application hosted by the first screen device 120 by the user, and send the authentication code to the authentication server 130.
[0063] The data store 179 can be a memory (e.g., random access memory), a drive (e.g., a hard disk drive, a flash drive), a database system, or another type of component or device capable of storing data. The data store 179 can include multiple storage components (e.g., multiple drives or multiple databases) that can span multiple computing devices (e.g., multiple server computers).
[0064] Generally, functions described in one implementation as being performed on the first screen device 120 and the second screen device 170 can also be performed by the application distribution server 110 and / or the authentication server 130 in other implementations, as appropriate. For example, the authentication server 130 can identify the first screen device 120 and the second screen device 170 as being on the same network (e.g., the network 150, the local network 140). In another example, the application distribution server 110 can identify the first screen device 120 and the second screen device 170 as having downloaded the application 112 from the same set of applications 112 (e.g., a smart TV version and a mobile version of the same application 112).
[0065] Further, the functions of a particular component can be performed by different or multiple components operating together. The application distribution platform, the application distribution server 110, and the authentication server 130 can also be accessed by other systems or devices as services provided through appropriate application programming interfaces (APIs), and thus are not limited to use in websites and applications.
[0066] In implementations of the present disclosure, a "user" can be represented as a single individual. However, other implementations of the present disclosure encompass a "user" as an entity controlled by a group of users and / or automated sources. For example, a group of separate users that are collectively a community in a social network can be considered a "user." In another example, an automated consumer can be an automated ingestion pipeline of the application distribution platform.
[0067] Although implementations of the present disclosure are discussed in terms of an application distribution server 110, an authentication server 130, and an application distribution platform, implementations can also be applied generally to any type of social network that provides content and connectivity between users.
[0068] In situations in which the systems discussed here collect personal information about users, or can make use of personal information, the users can be provided with an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and / or how to receive content from the content server that can be more relevant to the user. In addition, certain data can be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity can be treated so that no personally identifiable information can be determined for the user, or a user's geographic location can be generalized where location information is obtained (such as to a city, postal code, or state level), so that a particular location of a user cannot be determined. Thus, the user can have control over how information is collected about the user and used by the application distribution platform, as well as what user information is sent to the application distribution server 110 and the authentication server 130.
[0069] Figure 2A FIG. 1 is a block diagram illustrating a first screen device 120. In Figure 2A In the example shown in FIG. 1, the first screen device 120 includes a first application login component 122, a device identifier component 124, a message component 126, and a prompt component 128 coupled to a data store 129.
[0070] The first application login component 122 includes a first application login request manager 210, an authentication code receiving module 212, and a credential receiving module 214.
[0071] The first application login request manager 210 can receive user input requesting user authentication for automatic user login into the first application. For example, the first application login request manager 210 can receive user input that initiates the first application, navigates to a login page, selects a login element, etc. The first application login request manager 210 can send a request to the authentication server 130 for user authentication for automatic user login into the first application. In some implementations, the request can be a request for an authentication code 114. In some implementations, the first application login request manager 210 can send the request periodically to the authentication server 130. The first application login request manager 210 can store the request in the data store 129 for later retrieval and resending to the authentication server 130.
[0072] The authentication code receiving module 212 can receive the authentication code 114 from the authentication server 130. The authentication code 114 can be received in response to a request for user authentication. The credential receiving module 214 can receive credentials for automatic user login into the first application from the authentication server 130 in response to the second screen device 170 sending the authentication code 114 to the authentication server 130. The credentials can be used for automatic user login into the first application using a particular account.
[0073] The device identifier component 124 includes a SSDP message receiving component 220 and a SSDP message sending component 222. The SSDP message receiving component 220 can receive a first SSDP message from the second screen device 170 over a network (e.g., the local network 140). In some implementations, the SSDP message receiving component 220 detects a first SSDP broadcast message broadcasted by the second screen device 170 over the network. The SSDP message sending component can send a second SSDP message to the second screen device 170 over the network in response to the first SSDP message. In some implementations, the device identifier components 124 and 174 use different protocols other than SSDP. In some implementations, the device identifier component 124 identifies the second screen device 170 as being located on the same network as the first screen device 120.
[0074] The message component 126 can include a message receiving module 230, a message generating module 232, and a message sending module 234. The message receiving module 230 can receive a first message (e.g., a DIAL application state hypertext transfer protocol (HTTP) request, a DIAL URL request, a DIAL URL query, a query for a DIAL URL of the first screen device 120, etc.) from the second screen device 170. The first message can be a query asking whether the first application is requesting user authentication for automatic user login into the first application.
[0075] In some implementations, the message generating module 232 generates a message (e.g., a DIAL application state HTTP request response, a DIAL URL response) in response to receiving the first message. In some implementations, the message generating module 232 generates the message in response to having sent a request for user authentication to the authentication server 130 and having received the first message. In some implementations, the message generating module 232 generates the message in response to having received an authentication code from the authentication server 130 and having received the first message. In some implementations, the message generating module 232 generates a DIAL URL and appends the authentication code 114 to the DIAL URL to generate the message.
[0076] The message sending module 234 sends a message to the second screen device 170. The message sending module 234 can broadcast the message over a network, and multiple devices communicatively coupled to the network can detect the message.
[0077] The prompt component 128 may include a prompt providing module 240 and an input receiving module 242. The prompt component 128 may display information such as... Figure 6 The prompt is like prompt 604 in the example. The prompt may include instructions (e.g., "Open the second application," "Go to your account on the second application," "Ensure the second screen device is on the same network as the first screen device," etc.). The prompt may include status (e.g., "Searching for the second screen device," etc.). The prompt may include prompt input elements (e.g., "Try another way," "Cancel," etc.). The input receiving module 242 may receive input via the prompt input elements. For example, if the user selects the prompt input element "Try another way," the input receiving module 242 may cause the prompt providing module 240 to display the prompt using another method of logging into the first application (e.g., using the directional keys of a remote control to type in the username and password into the first application). In another example, if the user selects the prompt input element "Cancel," the prompt component 128 may stop displaying the prompt (e.g., the first application may display previous activities, the home screen, etc.).
[0078] Figure 2B This is a block diagram illustrating the second screen device 170. Figure 2B In the example shown, the second screen device 170 includes a second application login component 172, a device identifier component 174, a message component 176, and a prompt component 178 coupled to a data storage 179.
[0079] The second application login component 172 includes a second application login manager 250. The second application login manager 250 can receive a username and password via a second application hosted by the second screen device. The second application login manager 250 can send the username and password to the authentication server 130 and receive a credential for performing user authentication for the user logging into the second application. After login, the second application can have access to personalized information (e.g., playlists, viewing history, purchase history) and the second application can perform actions (e.g., create playlists, make purchases, etc.). The second application can be associated with one or more accounts. If the second application is associated with multiple accounts, upon sign-in (e.g., login), one of the multiple accounts can be used as a default account (e.g., for making purchases, etc.) or the user can be requested to select which account should be used for accessing personalized information, for performing actions, etc. In some embodiments, the user is more convenient to log into an account through the second screen device 170 (e.g., via the second application hosted by the second screen device 170) than through the first screen device 120 (e.g., via the first application hosted by the first screen device 120).
[0080] The device identifier component 174 includes a SSDP message sending component 260 and a SSDP message receiving component 262. The SSDP message sending component 260 can send a first SSDP message via a network. In some embodiments, the SSDP message sending component 260 broadcasts the first SSDP message to be detected by a device (such as the first screen device 120) communicatively coupled to the network. The SSDP message receiving component 262 receives a second SSDP message from the first screen device 120 in response to the first screen device 120 receiving the first SSDP message. In response to receiving the second SSDP message, the device identifier component 174 identifies the first screen device 120. In some embodiments, a protocol other than SSDP is used to identify the first screen device 120.
[0081] The message component 176 can include a message sending module 270, a message receiving module 272, a message decoding module 274. In response to the device identifier component 174 identifying the first screen device 120, the message sending module 270 can send a first message to the first screen device 120 (e.g., query the DIAL URL of the first screen device 120, send a DIAL application state HTTP request). Subsequent to the message sending module 270 sending the first message, the message receiving module 272 can receive a message sent by the first screen device 120 in response to the first message (e.g., a DIAL URL response, a DIAL application state HTTP request response, etc.). The message decoding module 274 can decode the message to determine that the first application is requesting user authentication for automatic user input. The message decoding module can decode the message to determine the authentication code 114 sent from the authentication server 130 to the first screen device 120.
[0082] The prompt component 178 can include a prompt providing module 280, an input receiving module 282, and an authentication code sending module 284. The prompt providing module 280 can present a prompt for user input related to automatic user login. The prompt providing module 280 can provide the prompt 704 shown in FIG. 7. For example, the prompt providing module 280 can provide a prompt for user input indicating acceptance by the user of automatic user login into the first application. The input receiving module 282 can receive user input. For example, the user input can be acceptance by the user of automatic user login into the first application via the account. In another example, the user input is switching accounts. In another example, the user input is canceling the request or denying access to the account. The authentication code sending module 284 can send the authentication code 114 to the authentication server 130 in response to receiving user input indicating acceptance by the user of automatic user login. The authentication code sending module 284 can send the authentication code 114 and an indication of the account corresponding to the user input indicating acceptance by the user of automatic user login. Figure 7
[0083] Figure 3 A sequence diagram 300 is depicted for facilitating automatic user login into a first application hosted by a first screen device 120, in accordance with one or more aspects of the disclosure. As depicted, the sequence diagram 300 includes interactions between the first screen device 120, the authentication server 130, and the second screen device 170. The first screen device 120 and the second screen device 170 are located on the same network (e.g., the local network 140, etc.). The interactions depicted in the sequence diagram 300 can occur in various orders and / or simultaneously, and other interactions are not presented and described herein. Moreover, all of the illustrated interactions can not be required to implement a sequence in accordance with the disclosed subject matter.
[0084] The sequence diagram 300 can receive (302) a user input requesting user authentication for automatic user login into a first application hosted by the first screen device 120 from the first screen device 120. In some implementations, the first screen device 120 receives (302) the user input in response to a user launching the first application on the first screen device 120. In some implementations, the first screen device 120 receives (302) the user input in response to the user navigating to a login screen via the first application on the first screen device 120. In some implementations, the first screen device 120 receives (302) the user input in response to the user interacting with (e.g., tapping a login button) a login element displayed via the first application on the first screen device 120. The first screen device 120 can send (304) a request for an authentication code for automatic user login (e.g., user authentication for automatic user login into the first application) to the authentication server 130 in response to receiving the user input. In some implementations, the first screen device 120 can periodically send (304) the request for user authentication to the authentication server 130. The authentication server 130 can generate (306) the authentication code in response to receiving the request. In some implementations, the authentication server 130 randomly generates (306) the authentication code in response to receiving the request. The authentication server 130 can send (308) the authentication code to the first screen device 120.
[0085] The second screen device 170 can send (310) a first SSDP message to the first screen device 120 over a network (e.g., the local network 140). In some implementations, the second screen device 170 broadcasts the first SSDP message (e.g., a first SSDP broadcast message) over the network. In some implementations, the second screen device periodically sends (310) the first SSDP message to determine whether there is a first screen device 120 that is communicatively coupled to the same network as the second screen device 170. In some implementations, the second screen device periodically sends (310) the first SSDP message to determine whether there is a first screen device 120 that is executing a first application that corresponds to a second application executing on the second screen device 170 and that is communicatively coupled to the same network as the second screen device 170 (e.g., the first and second applications have functionality to facilitate automatic user login into the first application via user input to the second application). In some implementations, the second screen device 170 sends (310) the first SSDP message in response to launching the second application on the second screen device 170. In some implementations, the second screen device 170 sends (310) the first SSDP message in response to receiving user input via the second application. The first screen device 120 can send (312) a second SSDP message to the second screen device 170 in response to receiving the first SSDP message (e.g., detecting the first SSDP broadcast message). The first screen device 120 can send (312) the second SSDP message to provide an acknowledgement (e.g., that the first screen device 120 is communicatively coupled to the same network as the second screen device 170, that the first screen device 120 is executing a first application that corresponds to the second application, etc.). The second screen device 170 can identify (314) the first screen device 120 in response to receiving the second SSDP message (e.g., as being communicatively coupled to the same network, as executing a first application that corresponds to the second application, etc.).
[0086] The second screen device 170 can send (316) a first message (e.g., a DIAL application status HTTP request, a DIAL URL request) to the first screen device 120 over the network. In some embodiments, the second screen device 170 sends (316) the first message to determine whether any identified first screen device 120 is requesting user authentication. In some embodiments, the second screen device 170 sends (316) the first message in response to identifying (314) the first screen device. In some embodiments, the second screen device 170 periodically sends (316) the first message to any first screen device that the second screen device 170 has identified. The first screen device 120 can generate (318) a message including an authentication code (e.g., a DIAL application status HTTP request response, a DIAL URL message) in response to receiving the first message (e.g., generate a DIAL URL and append the authentication code to the DIAL URL). The first screen device 120 can send (320) the message to the second screen device 170 over the network in response to generating the message. In some embodiments, the first screen device 120 broadcasts the message, and any second screen device can receive (e.g., detect) the message. In some embodiments, the first screen device 120 sends (320) the message to the second screen device 170 that sent (316) the first message. The first screen device 120 can send (320) the message to the second screen device 170 to provide confirmation that the first screen device 120 is requesting user authentication. The second screen device 170 can determine (322) that the first application is requesting user authentication for automatic user login in response to receiving the message. In some embodiments, the second screen device 170 determines (322) that the first application is requesting user authentication by decoding the message and identifying the authentication code. The second screen device 170 can present (324) a prompt for user input indicating acceptance of automatic user login by the user in response to determining that the first application is requesting user authentication.
[0087] In some implementations, the second application hosted by the second screen device 170 is logged into one or more accounts (e.g., the second screen device previously sent login credentials corresponding to the one or more accounts to the authentication server 130 to sign into the second application via the one or more accounts), and the second screen device 170 presents a prompt (324) that includes a corresponding accept element for each of the one or more accounts. The user can select (e.g., tap) one of the accept elements corresponding to one account to indicate the user's acceptance of automatic user sign-in into the first application via that account. In some implementations, the second screen device 170 presents (324) a prompt for user input for the user to enter login credentials (e.g., a username and password) via the second application (e.g., the user is not already signed into the second application).
[0088] The second screen device 170 can receive (326) user input indicating the user's acceptance of automatic user sign-in in response to presenting the prompt. In some implementations, the user input is a selection of an accept element corresponding to one account (e.g., a user input that selects one account to authorize the first application to use that account). In another element, the user input is the entry of a username and / or password. In some implementations, the user input is a biometric identifier (e.g., a thumbprint, a fingerprint, an eye scan, etc.).
[0089] The second screen device 170 can send (328) the authentication code from the message to the authentication server 130 in response to receiving the user input. The authentication server 130 can generate credentials in response to receiving the authentication code. In some implementations, the credentials can be login information for signing into the first application hosted by the first screen device. In some implementations, the credentials can be login information for signing into the first application hosted by the first screen device corresponding to the account indicated in the user input.
[0090] The first screen device 120 can send (332) a second request for user authentication for automatic user sign-in into the authentication server 130 (e.g., to sign into the first application hosted by the first screen device 120). In one implementation, the first screen device periodically sends the request for user authentication to the authentication server 130 after receiving (302) the user input and before receiving the credentials. In some implementations, the second request is the same as the first request sent (304) by the first screen device 120. The authentication server 130 can send (334) the credentials to the first screen device 120 to perform user authentication for automatic user sign-in into the first application.
[0091] Figures 4A to 4CFlowcharts depicting illustrative examples of methods 400, 430, and 460 for facilitating automatic user login into a first application hosted by a first screen device 120. Method 400 is an example method from the perspective of a second screen device. Method 430 is an example method from the perspective of a first screen device. Method 460 is an example method from the perspective of a server device. Methods 400, 430, and 460 can be performed by a processing device, which can include hardware (e.g., circuitry, dedicated logic), software (such as software running on a general purpose computer system or a dedicated machine), or a combination of both. Each of methods 400, 430, and 460, and their individual functions, routines, subroutines, or operations, can be performed by one or more processors of the computer device performing the method. In certain implementations, methods 400, 430, and 460 can each be performed by a single processing thread. Alternatively, methods 400, 430, and 460 can be performed by two or more processing threads, each thread performing one or more individual functions, routines, subroutines, or operations of the method.
[0092] For the sake of simplicity in explanation, the methods of the present disclosure are depicted and described as a series of acts. However, acts in accordance with the present disclosure can occur in various orders and / or concurrently, and other acts not presented and described herein can occur. Furthermore, not all illustrated acts can be required to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate the use of the term "comprising" as not excluding the presence of other elements or steps than those listed in a given example. Furthermore, those skilled in the art will appreciate and understand that the methods disclosed and described herein can be replaced by state diagrams or events, as alternative representations of the methods. Additionally, it should be appreciated that the methods disclosed in the specification can be stored on an article of manufacture to facilitate the transport and transfer of such methods to computing devices. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device or storage media. For example, a non-transitory machine-readable storage medium can store instructions which, when executed, cause a processing device (e.g., of the first screen device 120, the authentication server 130, the second screen device 170, etc.) to perform operations including the methods disclosed herein. In one implementation, method 400 can be performed by the second screen device 170 of Figure 1 , method 430 can be performed by the first screen device 120 of Figure 1 , and method 460 can be performed by the authentication server 130 of Figure 1 .
[0093] Referring to Figure 4A , method 400 can be performed by one or more processing devices of the second screen device 170 for facilitating automatic user login into a first application hosted by the first screen device 120.
[0094] Method 400 can begin at block 402, where the processing device can identify the first screen device 120 by sending a first SSDP message (e.g., a first SSDP broadcast message) to the first screen device 120 via the network and receiving a second SSDP message from the first screen device 120 via the network. In some implementations, the first SSDP message and the first SSDP message sent via the local network 140 are requests that inquire whether a first screen device is communicatively coupled to the local network 140. In some implementations, the second SSDP message is a response that confirms that the first screen device 120 is a first screen device communicatively coupled to the local network 140.
[0095] At block 404, the processing device can send a first message (e.g., a DIAL application status HTTP request, a DIAL URL request) to the first screen device 120 to determine whether the first screen device 120 is requesting user authentication for automatic user login. In some implementations, the processing device sends the first message in response to identifying the first screen device 120. In some implementations, the processing device periodically sends the first message for a threshold amount of time (e.g., until a timeout, until a message is received from the first screen device 120). (Blocks 402 and 404 can be omitted in alternative embodiments.)
[0096] At block 406, the processing device can detect (e.g., receive) a message sent by the first screen device 120 over the network. The message can include an authentication code provided to the first screen device by the server device. In some implementations, the processing device periodically sends the message until the processing device receives the message.
[0097] At block 408, the processing device can determine, based on the message, that the first application hosted by the first screen device 120 is requesting user authentication for automatic user login. In some implementations, the processing device determines that the first application is requesting user authentication in response to determining that the message includes the authentication code. In some implementations, the processing device can decode the message to identify the authentication code.
[0098] At block 410, the processing device can present a prompt for user input related to automatic user login via a second application hosted by the second screen device. In some implementations, the prompt is an accept element for the user to select to approve login into the first application. Each accept element can correspond to an account (e.g., the second application can be logged into the account prior to presenting the prompt). In some implementations, the prompt can be Figure 7 the prompt 704 shown in FIG. 7B.
[0099] At block 412, the processing device can receive user input indicating acceptance of the automatic user login by the user. In some implementations, the user input includes selection (e.g., clicking) of an accept element (e.g., the prompt input element 708e) of the prompt. In some implementations, the user input includes selection (e.g., clicking) of a visual representation of the account (e.g., an account avatar, an account tab, a photo, an image, a username, etc.). In some implementations, the user input includes a username and a password. Figure 7
[0100] At block 414, the processing device can send the authentication code from the message to a server device (e.g., the authentication server 130) to perform user authentication for the automatic user login into the first application hosted by the first screen device 120. In some implementations, the processing device sends an indication of the account indicated in the user input for the automatic user login into the first application for that account.
[0101] Referring to Figure 4B , the method 430 can be performed by one or more processing devices of the first screen device 120 for facilitating automatic user login into a first application hosted by the first screen device 120.
[0102] The method 430 can begin at block 432, where the processing device can receive, via the first application, user input requesting user authentication for automatic user login into the first application. In some implementations, the receiving of the user input is in response to launching the first application on the first screen device 120. In some implementations, the receiving of the user input is in response to navigating to the first application hosted by the first screen device 120. In some implementations, the receiving of the user input is in response to selection of a login element on the first application by the user. In some implementations, the receiving of the user input is in response to the first application being navigated to a login page. In some implementations, a prompt can be displayed via the first application. For example, the prompt 604 illustrated in FIG. 6B can be displayed via the first application. Figure 6
[0103] At block 434, the processing device can send, to a server device (e.g., the authentication server 130), a request for user authentication for automatic user login into the first application. The sending of the request can be in response to the receiving of the user input requesting user authentication.
[0104] At block 436, the processing device can receive an authentication code from the server device. The processing device can store the authentication code in a data store of the first screen device 120.
[0105] At block 438, the processing device can receive, from the second screen device over the network, a first SSDP message (e.g., a first SSDP broadcast message) to identify the first screen device, and at block 440, the processing device can send, to the second screen device over the network, a second SSDP message in response to the first SSDP message. The first SSDP message can be a request to ask the processing device whether it is part of the first screen device 120 communicatively coupled to the network, and the second SSDP message can be a response to confirm that the processing device is part of the first screen device 120 communicatively coupled to the network. Blocks 438 and 440 in the method 430 can occur at any point prior to block 430 (e.g., prior to block 432, etc.).
[0106] At block 442, the processing device can receive, from the second screen device, a first message (e.g., a DIAL query, a DIAL message, a DIAL request, a DIAL application state HTTP request, a query for a DIAL URL of the first screen device 120, etc.). The first message can be a request to ask the processing device whether it is hosting the first application for which user authentication is being requested. (Blocks 438, 440, and 442 can be omitted in alternative embodiments.)
[0107] At block 444, the processing device can generate a message including the authentication code (e.g., a DIAL URL response, a DIAL application state HTTP request response, etc.). Generating the message can include generating a DIAL URL, retrieving the authentication code from the data store, and appending the authentication code to the DIAL URL. Block 444 in the method 430 can occur at any point after the authentication code is received from the server device (block 436) and before the message is sent (block 446).
[0108] At block 446, the processing device can send the message over the network. The message can be detected by the second screen device 170. The second screen device 170 can present a prompt for user input, indicate acceptance of automatic user login by the user, and can send the authentication code to the server device in response to receiving the user input.
[0109] At block 448, the processing device can optionally send a second request to the server device for user authentication for automatic user login into the first application. In some implementations, the second request is the same as the first request in block 434. In some implementations, the processing device periodically sends the request for user authentication until the request is cancelled by the processing device (e.g., user input to cancel the request, a timeout of the request, etc.) or by the second screen device 170 (e.g., user input to cancel the request, etc.).
[0110] At block 450, the processing device can receive, from the server device, credentials for performing user authentication for automatic user login into the first application in response to the server device receiving the authentication code from the second screen device 170. The processing device can use the credentials to log into the first application using an account corresponding to the credentials. In response to logging into the first application, the processing device can display user information (e.g., playlists, viewing history, purchases, etc.) corresponding to the account. In response to logging into the first application, the processing device can perform an action requested by the user (e.g., make a purchase, etc.) via the account corresponding to the credentials.
[0111] Referring to Figure 4C The method 460 can be performed by one or more processing devices of a server device (e.g., the authentication server 130) for facilitating automatic user login into a first application hosted by a first screen device 120.
[0112] The method 460 can begin at block 462, where the processing device can receive, from the first screen device 120, a request for user authentication for automatic user login into a first application hosted by the first screen device 120.
[0113] At block 464, the processing device can generate an authentication code for automatic user login into the first application hosted by the first screen device 120. The processing device can randomly generate the authentication code. In one implementation, the authentication code is a random alphanumeric authentication code. The processing device can store the authentication code in a data store (e.g., the authentication code cache 123 of the data store 160).
[0114] At block 466, the processing device can send the authentication code to the first screen device 120. The first screen device 120 can generate and send a message (e.g., a DIAL URL response, a DIAL application state HTTP request response, etc.) that includes the authentication code. The second screen device 170 can receive and decode the message to identify the authentication code.
[0115] At block 468, the processing device can receive the authentication code from the second screen device 170. The processing device can also receive, from the second screen device 170, an indication of an account for automatic user login into the first application in response to the second screen device 170 receiving user input. The second screen device 170 can receive the user input in response to presenting a prompt for the user input indicating acceptance of the automatic user login via the second application. The indication of the account can be in response to the second screen device 170 being logged into the account via the second application.
[0116] At block 470, the processing device can optionally receive, from the first screen device, a second request for user authentication for automatic user login into the first application.
[0117] At block 472, the processing device can generate credentials based on the authentication code received from the second screen device 170. The credentials can be for the account based on the indication of the account received from the second screen device 170.
[0118] At block 474, the processing device can send, to the first screen device, the credentials for performing user authentication for automatic user login into the first application.
[0119] Figure 5 is an example flowchart 500 for facilitating automatic user login into a first application hosted by a first screen device 120.
[0120] At block 502, a first application hosted by a first screen device 120 displays a login instruction (e.g., a television sign-in prompt with instructions). In one implementation, the first screen device 120 also displays a pending element (e.g., a spinning timer, an object indicating that the first screen device 120 is waiting for input) and a status indication (e.g., "Looking for your phone or tablet"). The first application can display the login instruction in response to receiving a user input requesting login into the first application. The first application can display the login instruction in response to launching the first application on the first screen device 120. The method continues to block 504.
[0121] At block 504, a second application is launched on a second screen device 170. The second screen device 170 can receive a user input for opening the second application. The method continues to block 506.
[0122] At block 506, the second screen device 170 determines whether the first screen device 120 and the second screen device 170 are located on the same network (e.g., the local network 140). If the first screen device 120 and the second screen device 170 are located on the same network, the method continues to block 508. If the first screen device 120 and the second screen device 170 are not located on the same network, the method continues to block 510 and then to block 516.
[0123] At block 508, the second screen device 170 determines whether the first screen device 120 is detectable by the second screen device 170. In some embodiments, block 508 also includes the first screen device 120 determining whether the second screen device 170 is detectable by the first screen device 120. The devices can detect each other by sending and receiving SSDP messages. If the second screen device 170 does detect the first screen device 120, the method continues to block 512 or block 520. If the second screen device 170 does not detect the first screen device 120, the method continues to block 510 and then to block 516.
[0124] At block 510, the second application hosted by the second screen device 170 does not update the display of the second application. For example, the second application does not display an indication that the first screen device 120 has been detected or is waiting for a login.
[0125] At block 512, the first application is waiting for an action by the second screen device 170. For example, the first application can be waiting for user input via the second application to accept a login via the first application. In one embodiment, the first application can not update the display of the first application. The method continues to 514.
[0126] At 514, if no action is taken via the second application, the method continues to block 516. In one embodiment, if no user input is received indicating acceptance of the automatic user login by the user, the method continues to 516.
[0127] At block 516, the first application is waiting for an action via the second screen device. In one embodiment, a prompt displayed via the first application times out after a threshold amount of time and the method continues to 518.
[0128] At 518, another login opportunity (e.g., retry) can be granted and the method continues to block 502, where the first application displays login instructions. The first application can display updated login instructions in block 510. The updated login instructions can include a second prompt with one or more methods of logging into the first application. The one or more login methods can include a URL method that can include entering a URL into the second application, entering a username and password into the second application, and entering a code displayed via the first application into the second application. The one or more login methods can include entering a username and password directly into the first application via a remote control (e.g., directional keys). The one or more login methods can include the automatic user login methods described in methods 400, 430, and 460.
[0129] At block 520, the second application displays a login confirmation prompt, and the second screen device 170 receives user input via the second application. In one embodiment, the user input may be an option to "Continue" (e.g., Figure 7 The prompt in the input field indicates the selection of element 708a). The method continues to one or more of blocks 522, 524, or 526.
[0130] At block 522, the second screen device 170 receives user input (e.g., canceling login via the second application) from the user (e.g., ...). Figure 7 The prompt input element 708b). In one implementation, the second application displays a cancel element that the user can accept (e.g., clicking a cancel button). The method continues to block 502.
[0131] At block 524, the first application displays confirmation that the first screen device 120 has found the second screen device 170 and the network. The method continues to block 526.
[0132] At block 526, the second screen device 170 receives user input confirming the login account (e.g., ...). Figure 7 The prompt will indicate the input element 708c. The method continues to block 528, 530, or 532.
[0133] At block 528, the user input confirming the login account can be the user input for switching login accounts (e.g., ...). Figure 7 The prompt indicates the input element 708d. The method continues to block 530 or 532.
[0134] At block 530, the second application displays a prompt to confirm whether the first application is allowed to access the account (e.g., Figure 7 The prompt input element 708e). The method can respond to user input indicating "cancel" or "reject" (e.g., Figure 7 The prompt for input element 708f) continues to block 532, or in response to user input indicating "yes" or "allow" (e.g., ...). Figure 7 The prompt to input element 708e) continues to block 538.
[0135] At block 532, the second application receives user input for canceling the request or denying access to the account (e.g., Figure 7 The prompt indicates that the input element is 708f. The method continues to 534.
[0136] At 534, the first application times out and resets. In some implementations, the first application displays the login instruction (see block 502) for a threshold amount of time or until it times out and resets (e.g., by selecting cancel on the second screen device 170). The method continues to block 536.
[0137] At block 536, the first application displays a prompt indicating that the login was canceled by the second screen device 170 (e.g., in response to user interaction with the second application). The method continues to block 502.
[0138] At block 538, the first application is successfully logged in. In one implementation, the first application is successfully logged in by the second screen device 170 receiving the authentication code from the first screen device 120, the second screen device 170 sending the authentication code to the authentication server 130, and the authentication server 130 performing user authentication for automatic user login into the first application hosted by the first screen device 120.
[0139] At block 540, the first application returns to the previous activity (e.g., what the first application was displaying before the login instruction was displayed in block 502). The first application can also display an indication that the login was successful (e.g., a login successful welcome).
[0140] At block 542, the second application returns to the previous activity (e.g., what the first application was displaying before the login confirmation prompt was displayed). The second application can also display an indication that the login was successful (e.g., a login successful welcome).
[0141] Figure 6 FIG. 6 is an example graphical interface 600 displayed via a first application 602 hosted by a first screen device 120 to facilitate automatic user login into the first application 602 in accordance with implementations of the present disclosure.
[0142] The first application 602 can display a prompt 604. In one implementation, the prompt 604 is displayed in front of a recent activity (e.g., a home page, a media item being played, an item to be purchased, etc.) displayed on the first application 602. The portion of the first application 602 displayed behind the prompt 604 can be obscured (e.g., masked, faded, etc.).
[0143] In some implementations, the prompt 604 is displayed in response to receiving a user input requesting user authentication for automatic user login into the first application. For example, the user input can be launching the first application 602. In another example, the user input can be selecting a login element displayed via the first application 602. In another example, the user input can be navigating to a login screen displayed via the first application 602. In some implementations, the prompt 604 is displayed in response to the first screen device 120 receiving a message from the second screen device 170. For example, the message can be a first SSDP message received from the second screen device 170. In another example, the message can be a DIAL message received from the second screen device 170. In another example, the message can be a message of another type of protocol received from the second screen device 170.
[0144] The prompt 604 can include prompt text 606 and one or more prompt input elements 608. The prompt text 606 can indicate instructions for facilitating automatic user login into the first application 602. For example, the prompt text 606 can include an indication to launch a second application on the second screen device 170. In another example, the prompt text 606 can include an indication to log into an account via the second application on the second screen device. In another example, the prompt text 606 can include instructions to connect the second screen device 170 to the same network as the first screen device 120 (e.g., the local network 140). In another example, the prompt text 606 can include an indication of progress in facilitating automatic user login (e.g., "Searching for second screen device"). The one or more prompt input elements 608 can include a prompt input element 608a to attempt another login method (e.g., enter a username and password via directional keys of a remote control, enter a URL, code, username, and password in the second screen device 170, etc.) and a prompt input element 608b to cancel the login request.
[0145] The prompt 604 can update the login instructions in response to the prompt being displayed for a threshold amount of time (e.g., a timeout). The prompt 604 can update the login instructions in response to identifying the second screen device 170 via the network. The prompt 604 can update the login instructions in response to receiving user input by the second application hosted by the second screen device 170 (e.g., canceling the login request, selecting an account, user acceptance to login into the first application, etc.).
[0146] Figure 7 Displaying Displaying examples user interfaces 700a, 700b, 700c, 700d, 700e, and 700f via a second application 702 hosted by a second screen device 170 for facilitating automatic user login 602 into a first application hosted by a first screen device 120 in accordance with embodiments of the disclosure. Figure 7 Also displayed is a sequence 710, 720, 730, and 740 between different user interfaces 700.
[0147] The user interface 700a displays the second application 702 and a prompt input element 708a. The prompt input element 708a can be displayed when the user interface 700a is displaying the home screen and when the user is browsing content items displayed via the user interface 700a. The prompt input element 708a can include a visual representation of an account in which the second application is logged in. For example, the prompt input element 708a can include an image (e.g., a profile picture, an avatar, etc.) corresponding to the account. In another example, the prompt input element 708a can include an identifier (e.g., a username, a profile name of a user corresponding to the account, an email address corresponding to the account, an account name, etc.) for the account. The prompt input element 708a can be an icon (e.g., a "TV Assistant" icon) that is user-selectable to initiate login to the first application 602. Upon user input of a selection of the prompt input element 708a, the sequence can continue to the user interface 700b (sequence 710) or the sequence can continue to the user interface 700e (sequence 730).
[0148] The sequence 710 can occur if the second screen device 170 has determined that the first application 602 is requesting user authentication. For example, the second screen device 170 has identified the first screen device 120 by sending the first SSDP message and receiving the second SSDP message, and the second screen device 170 has determined that the first screen device 120 is requesting user authentication by sending the first message (e.g., a DIAL message, a query for a DIAL URL, a DIAL application state HTTP request) and receiving a message (e.g., a DIAL URL response, a DIAL application state HTTP request response, etc.). The sequence 730 can occur if the second screen device has not determined that the first application 602 is requesting user authentication. For example, the second screen device 170 has not identified the first screen device 120. In another example, the second screen device 170 has not sent a message to the first screen device 120. In another example, the second screen device has not received an authentication code (e.g., a DIAL URL response, a DIAL application state HTTP request response, etc.) in a message.
[0149] User interface 700b displays second application 702 and prompt 704b. In some embodiments, user interface 700b or prompt 704b can be an account selector page (e.g., an account selector modal, a mobile-aware modal). Prompt 704b can include prompt text 706b (e.g., “Try to sign into the first application hosted by the first user device?” information identifying a username or account) and one or more prompt input elements 708. User input selecting prompt input element 708b can cancel the sign-in to the first application. User interface 700b can further include a prompt to select the first screen device 120 that hosts the first application 602 for the user to sign into (e.g., the prompt can show one or more first screen devices, other devices connected to the same network (projected devices, etc.), etc.). Upon user input selecting prompt input element 708c, sequence 710 can continue to user interface 700c. User input selecting prompt input 708d can initiate a switch of the account for automatic user sign-in.
[0150] User interface 700c displays second application 702 and prompt 704c. Prompt 704c can include prompt text 706c (e.g., “The first application wants: manage your account, view and manage your rental and purchase history, etc.”) and one or more prompt input elements 708. User input selecting prompt input element 708e can indicate user acceptance of automatic user sign-in, and sequence 710 can continue to the first application being successfully signed into (e.g., second screen device 170 can send an authentication code to authentication server 130 to perform user authentication for automatic user sign-in into the first application). User input selecting prompt input element 708f can indicate user rejection of automatic user sign-in and sequence (720) can continue to user interface 700f.
[0151] User interface 700d displays second application 702 and prompt 704d. User interface 700d can be displayed if the user has not selected prompt input element 708a within a threshold amount of time. Prompt 704d can include instructions to select prompt input element 708a to begin signing into the first application 602. Prompt 704d can be displayed for a second threshold amount of time or until the user dismisses prompt 704d or selects prompt input element 708a. Prompt 704d can not be displayed if a sign-in sequence (e.g., sequence 710) has been initiated by another second screen device on the network (e.g., prompt input element 708a has been selected). Upon user input selecting prompt input element 708a, sequence 740 continues to user interface 700b and can proceed as described above.
[0152] The user interface 700e displays the second application 702. The user interface can display user information (e.g., a user name, an email address, a profile picture, an avatar, etc.) corresponding to the account logged in via the second application 702. The user interface 700e can display account information. The user interface 700e can be displayed in response to the user’s selection of the prompt input element 708a (e.g., selecting the account) prior to the second screen device 170 determining that the first application 602 is requesting user authentication for automatic user login. When the second screen device 170 determines that the first application 602 is requesting user authentication, the sequence 730 can continue to the user interface 700b (e.g., the account selector modal automatically appears) and can proceed as described above.
[0153] The user interface 700f displays the second application 702. The user interface can display user information corresponding to the account logged in via the second application 702. The user interface 700f can display account information. The user interface can be displayed in response to the second screen device 170 determining that the first application 602 is requesting user authentication for automatic user login, and the second application 702 receiving a cancellation (e.g., via the prompt input element 708b displayed via the user interface 700b) or a rejection (e.g., via the prompt input element 708f displayed via the user interface 700c) of the user authentication for automatic user login into the first application 602. The user interface 700f can display a prompt 704e (e.g., a welcome prompt, a snack bar prompt, a small pop-up window that allows interaction with other portions of the user interface 700f while being displayed, a prompt that appears after a threshold amount of time (e.g., a timeout)) that includes a prompt text 706e (e.g., “Are you trying to log into the first application?”) and a prompt input element 708h. The sequence can continue to the user interface 700b or 700c upon the user input selecting the prompt input element 708h, for example, the user interface 700 displayed immediately prior to being directed to the user interface 700f.
[0154] Figure 8is a block diagram that illustrates one embodiment of a computer system in accordance with an embodiment of the present disclosure. In some embodiments, computer system 800 can be connected (e.g., via a network) to other computer systems. Computer system 800 can operate in the capacity of a server or a client computer in a client-server environment, or as a peer computer in a peer-to-peer or distributed network environment. Computer system 800 can be provided as a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, the term "computer" shall also include any collection of computers or devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
[0155] In another aspect, computer system 800 can include a processing device 802, volatile memory 804 (e.g., random access memory (RAM)), non-volatile memory 806 (e.g., read-only memory (ROM) or electrically erasable programmable ROM (EEPROM)), and data storage device 818, which can communicate with each other via bus 808.
[0156] Processing device 802 can be provided by one or more processors, such as a general- purpose processor (e.g., a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a microprocessor implementing other instruction sets, or a microprocessor implementing a combination of instruction sets) or a special- purpose processor (e.g., an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), or a network processor).
[0157] Computer system 800 can further include a network interface device 822. Computer system 800 also can include a video display unit 810 (e.g., an LCD), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a signal generation device 820.
[0158] Data storage device 818 can include a non-transitory computer-readable storage medium 824 on which can be stored instructions 826 encoding any one or more of the methodologies or functions described herein, including instructions to Figure 1 message component 126 or 176 and for implementing the method 400, 430, or 460.
[0159] The instructions 826 can further reside, completely or at least partially, within volatile memory 804 and / or within processing device 802 during execution thereof by the computer system 800, so that, for example, volatile memory 804 and processing device 802 also constitute machine-readable storage media. The instructions 826 can further be transmitted or received over a network 806 via the network interface device 808.
[0160] Although the computer-readable storage medium 824 is illustrated in the illustrative example as a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of executable instructions. The term "computer-readable storage medium" shall also include any tangible medium that is capable of storing or encoding a set of instructions for execution by a computer, and that causes the computer to perform any one or more of the methods described herein. The term "computer-readable storage medium" shall include, but not be limited to, solid-state memories, optical media, and magnetic media.
[0161] The methods, components, and features described herein can be implemented by discrete hardware components or can be integrated in the functionality of other hardware components such as ASICs, FPGAs, DSPs or similar devices. Furthermore, the methods, components, and features can be implemented by firmware modules or functional circuitry within hardware devices. Additionally, the methods, components, and features can be implemented in any combination of hardware devices and computer program components or in computer programs.
[0162] Unless specifically stated otherwise, terms such as "promote," "detect," "determine," "present," "receive," "send," "identify," "request," "generate," "authenticate," or the like, refer to operations and processes that are performed by a computer system or machine, manipulated, and transformed by the computer system or machine, and that are represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission, or display devices of the computer system. Additionally, the terms "first," "second," "third," "fourth," etc. as used herein refer to labels assigned to distinguish different elements and do not necessarily have an ordinal meaning or sequence.
[0163] Examples described herein also relate to an apparatus for performing the methods described herein. This apparatus can be specially constructed for performing the methods described herein, or it can comprise a general-purpose computer system selectively programmed by a computer program stored in the computer system. Such a computer program can be stored in a computer-readable tangible storage medium.
[0164] The methods and illustrative examples described herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with or in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the methods 400, 430, 460 and / or each of their individual functions, routines, subroutines, or operations. An example of the structure for a variety of these systems is set forth in the description above.
[0165] The above description is intended to be illustrative, and not restrictive. While the disclosure has been described with reference to specific illustrative examples and implementations, it will be recognized that the disclosure is not limited to the examples and implementations described. The scope of the disclosure should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.
Claims
1. A method for facilitating automatic user login into a first application hosted by a first screen device, the method comprising: sending, by a second screen device, a first message to the first screen device over a wireless network to determine whether the first screen device is requesting user authentication for the automatic user login into the first application hosted by the first screen device; responsive to receiving a second message from the first screen device via the wireless network as a response to the first message, presenting, via a second application hosted by the second screen device, a prompt for user input indicating acceptance by a user of the automatic user login into the first application hosted by the first screen device; receiving the user input indicating acceptance by the user of the automatic user login; and responsive to receiving the user input indicating acceptance by the user of the automatic user login, sending at least a portion of the second message to a server device to perform the user authentication for the automatic user login into the first application hosted by the first screen device. the at least a portion of the second message includes an authentication code provided by the server device to the first screen device.
2. The method of claim 1, wherein, the user input also indicates a selection of an account, wherein the automatic user login into the first application is with respect to the account.
3. The method of claim 1, wherein, sending the at least a portion of the second message also includes sending the selection of the account for the automatic user login.
4. The method of claim 3, wherein, 5. The method of claim 1, further comprising: identifying the first screen device by sending a first Simple Service Discovery Protocol (SSDP) message to the first screen device and receiving a second SSDP message from the first screen device; and responsive to identifying the first screen device, determining that the first screen device is requesting the user authentication for the automatic user login by sending the first message to the first screen device. the second message is a DIAL Uniform Resource Locator (URL) response to a Discovery and Launch (DIAL) URL request sent by the second screen device.
7. The method of claim 1, further comprising:
6. The method of claim 1, wherein, decoding the second message to determine that the first application is requesting an authentication code for the automatic user login.
8. A non-transitory machine-readable storage medium storing instructions that, when executed, cause a processing device of a first screen device to perform operations for facilitating automatic user login into a first application hosted by the first screen device, the operations comprising: receiving, by the first screen device from a second screen device over a wireless network, a first message sent by the second screen device to determine whether the first screen device is requesting user authentication for the automatic user login into the first application hosted by the first screen device; in response to receiving the first message, sending, via the first screen device, a second message intended for the second screen device over the wireless network to prompt a user of the second screen device to indicate acceptance of the automatic user login; and receiving, from a server device, credentials for performing the user authentication for the automatic user login into the first application, the received credentials indicating that at least a portion of the second message was provided to the server device by the second screen device.
9. The non-transitory machine-readable storage medium of claim 8, wherein, the at least a portion of the second message includes an authentication code provided to the first screen device by the server device.
10. The non-transitory machine-readable storage medium of claim 8, wherein, the received credentials further indicate that a selection of an account was provided to the server device by the second screen device, wherein the automatic user login into the first application is with respect to the account.
11. The non-transitory machine-readable storage medium of claim 8, wherein, the operations further include receiving, via the first application, user input requesting the user authentication for the automatic user login into the first application prior to sending the second message.
12. The non-transitory machine-readable storage medium of claim 8, the operations further comprising: receiving a first simple service discovery protocol (SSDP) message from the second screen device to identify the first screen device; and in response to the first SSDP message, sending a second SSDP message to the second screen device, wherein the first screen device is identified by the second screen device in response to the sending of the second SSDP message, wherein the receiving of the first message is in response to the identification by the second screen device.
13. The non-transitory machine-readable storage medium of claim 8, wherein, the second message is a DIAL uniform resource locator (URL) response to a discovery and launch (DIAL) URL request sent by the second screen device.
14. The non-transitory machine-readable storage medium of claim 8, wherein, a user authentication for a user login into a second application hosted by the second screen device is to occur prior to the receiving of the credentials to perform the user authentication for the automatic user login into the first application.
15. A system comprising: a memory to store instructions to facilitate an automatic user login into a first application hosted by a first screen device; and a processing device communicatively coupled to the memory to execute the instructions to: send, to the first screen device, an authentication code intended for the first screen device to generate a second message, and in response to the first screen device receiving a first message from a second screen device over a wireless network, send the second message to the second screen device over the wireless network, the first message sent by the second screen device to determine whether the first screen device is requesting a user authentication for the automatic user login into the first application hosted by the first screen device; receive, from the second screen device, at least a portion of the second message; and in response to receiving the at least a portion of the second message from the second screen device, send, to the first screen device, credentials for performing the user authentication for the automatic user login into the first application. 16. The system of claim 15, wherein, The at least the portion of the second message includes the authentication code.
17. The system of claim 15, wherein, The processing device is to receive the at least the portion of the second message from the second screen device in response to user input via a second application hosted by the second screen device, the user input indicating acceptance of the automatic user login after detecting the second message.
18. The system of claim 17, wherein, The user input also indicates a selection of an account, and wherein the automatic user login into the first application is with respect to the account.
19. The system of claim 17, wherein, The processing device is to perform the user authentication for a user login into the second application hosted by the second screen device prior to sending the credentials to the first screen device to perform the user authentication for the automatic user login into the first application.
20. The system of claim 15, wherein, The second message is a DIAL uniform resource locator (URL) response to a discovery and launch DIAL (DIAL URL) request sent by the second screen device.
Citation Information
Patent Citations
Method and device for account synchronization at multiple terminals
CN104506492A