Generating and transmitting a token for account authentication across multiple platforms via processing circuitry

EP4754657A1Pending Publication Date: 2026-06-10NAGRAVISION SA

Patent Information

Authority / Receiving Office
EP · EP
Patent Type
Applications
Current Assignee / Owner
NAGRAVISION SA
Filing Date
2024-07-23
Publication Date
2026-06-10

AI Technical Summary

Technical Problem

Consumers face friction and complexity when entering credentials into multiple accounts for various products and services, leading to a desire for a unified authentication process across multiple platforms.

Method used

A method and system for generating and transmitting a token for account authentication across multiple platforms, where a token is received from a first application, transmitted to a second application upon authorization, and used to access content from a second content provider server, streamlining the authentication process.

Benefits of technology

This solution reduces consumer friction by allowing a single sign-on across multiple platforms, simplifying the authentication process and enhancing user experience as the number of applications increases.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2024057140_13022025_PF_FP_ABST
    Figure IB2024057140_13022025_PF_FP_ABST
Patent Text Reader

Abstract

A method includes receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible on the user device, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the first application having determined the second application to be authorized to receive the token during the token request; and authorizing access to the content of the second content provider server to the second application.
Need to check novelty before this filing date? Find Prior Art

Description

GENERATING AND TRANSMITTING A TOKEN FOR ACCOUNT AUTHENTICATION ACROSS MULTIPLE PLATFORMS VIA PROCESSING CIRCUITRYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to U.S. Provisional Application No. 63 / 517,798, filed August 4, 2023, which is incorporated herein by reference in its entirety for all purposes.BACKGROUNDFIELD OF THE DISCLOSURE

[0002] The present disclosure relates to generating a token and transmitting the token across multiple platforms in order to authenticate corresponding accounts on said platforms.DESCRIPTION OF THE RELATED ART

[0003] Entering user credentials into multiple accounts for various products and services can result in consumer friction and increased complexity for consumers to follow. A single trust authority that can streamline and unify the authentication process can be desired.

[0004] The foregoing description is for the purpose of generally presenting the context of the disclosure. Work of the inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present disclosure.SUMMARY

[0005] The foregoing paragraphs have been provided by way of general introduction, and are not intended to limit the scope of the following claims. The described embodiments, together with further advantages, will be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings.

[0006] In one embodiment, the present disclosure is related to a method, including receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user deviceproviding the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.

[0007] In one embodiment, the present disclosure is additionally related to a device, including processing circuitry configured to receive, from a first application on a user device, a first sign- on request for obtaining access to content from a first content provider server; transmit, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receive, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorize access to the content of the second content provider server to the second application.

[0008] In one embodiment, the present disclosure is additionally related to a non-transitory computer-readable storage medium for storing computer-readable instructions that, when executed by a computer, cause the computer to perform a method, the method including receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response totransmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0010] FIG. 1A is a schematic view of an authentication and authorization system, according to an embodiment of the present disclosure.

[0011] FIG. IB is a schematic of the authentication and authorization system, according to an embodiment of the present disclosure.

[0012] FIG. 2 is a schematic illustrating a method of authenticating credentials and authorizing access to content via dynamic provisioning, according to an embodiment of the present disclosure.

[0013] FIG. 3 is a schematic illustrating a method of authenticating credentials and authorizing access to content via a transparent sign on, according to an embodiment of the present disclosure.

[0014] FIG. 4 is a schematic illustrating a method of authenticating credentials and authorizing access to content via connected account sign on, according to an embodiment of the present disclosure.

[0015] FIG. 5 is a schematic illustrating a method of authenticating credentials and authorizing access to content via notification-based sign on, according to an embodiment of the present disclosure.

[0016] FIG. 6 is a schematic illustrating a method of authenticating credentials and authorizing access to content via network-based sign on, according to an embodiment of the present disclosure.

[0017] FIG. 7 is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via dynamic provisioning, according to an embodiment of the present disclosure.

[0018] FIG. 8 A is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via transparent sign on, according to an embodiment of the present disclosure.

[0019] FIG. 8B is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via transparent sign on, according to an embodiment of the present disclosure.

[0020] FIG. 9 is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via connected account sign on, according to an embodiment of the present disclosure.

[0021] FIG. 10A is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure.

[0022] FIG. 10B is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure.

[0023] FIG. 10C is an exemplary flow chart for a method of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure.

[0024] FIG. 11 is a schematic of a user device for performing a method, according to an exemplary embodiment of the present disclosure;

[0025] FIG. 12 is a schematic of a hardware system for performing a method, according to an exemplary embodiment of the present disclosure; and

[0026] FIG. 13 is a schematic of a hardware configuration of a device for performing a method, according to an exemplary embodiment of the present disclosure.DETAILED DESCRIPTION

[0027] The terms “a” or “an”, as used herein, are defined as one or more than one. The term “plurality”, as used herein, is defined as two or more than two. The term “another”, as used herein, is defined as at least a second or more. The terms “including” and / or “having”, as used herein, are defined as comprising (i.e., open language). Reference throughout this document to "one embodiment", “certain embodiments”, "an embodiment", “an implementation”, “an example” orsimilar terms means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of such phrases or in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments without limitation.

[0028] Pay TV operators, also known as pay television operators, and telecommunications companies provide subscription-based television services to customers. The Pay TV operators can transmit television programming through various distribution methods, such as cable, satellite, or internet-based platforms. Pay TV operators acquire the rights to distribute television channels and content from broadcasters, production companies, and other content providers. They bundle these channels and packages into subscription plans that customers can choose from based on their preferences and interests. The bundles can also include landline phone, television, broadband, and mobile all in a single package or product. Further, Pay TV operators can bundle applications, such as Netflix, Hulu, Disney+, etc. into the packages to attract more customers.

[0029] With the rise of streaming services and over-the-top (OTT) platforms, Pay TV operators have faced competition from online streaming providers. An OTT platform refers to a service or platform that delivers video, audio, and other media content directly to users over the internet, bypassing some methods of content distribution like cable or satellite television providers. OTT platforms can be accessed through devices such as smartphones, tablets, smart TVs, or streaming media players. Examples of OTT platforms include Netflix, Amazon Prime (Video), Disney+, Hulu, HBO Max, and YouTube (Premium). These platforms have gained popularity and disrupted broadcasting models by offering a convenient method for users to access a wide range of content on-demand. However, Pay TV operators can adapt by offering their own streaming services or integrating streaming platforms into their offerings to remain competitive.

[0030] When a consumer signs up for a package that includes bundled applications, the consumers can be requested to create an account on those applications with separate credentials and link them into a single bill. This process can create consumer friction and can be complex for some consumers to follow, especially as the number of applications increases. Thus, a method that provisions, into a single platform and trust authority, the consumer’s account and entitlements across various applications, television, etc. is desired.

[0031] Referring now to the Drawings, FIG. 1A is a schematic view of an authentication and authorization system 199, according to an embodiment of the present disclosure. In an embodiment, the system 199 can include a first electronic device 125, such as a user device, communicatively connected to a second electronic device 190, such as a server, via a network 120. A third electronic device 195 can be communicatively connected to the first electronic device 125 and the second electronic device 190. The devices can be connected via a wired or a wireless connection. The connection between, for example, the first electronic device 125 and the second electronic device 190 can be via the network 120, wherein the network 120 is wireless. In an embodiment, the first electronic device 125 can be configured to obtain data from the user (of the first electronic device 125), such as user information (credentials, login / sign in usernames and passwords, personal data, etc.). Notably, the first electronic device 125 can transmit the data over the communication network 120 to the networked second electronic device 190 and / or the third electronic device 195. Additionally or alternatively, more electronic devices can be included and networked in the authentication system 199.

[0032] In an embodiment, the first electronic device 125 need not be communicatively coupled to the other device or the network 120. That is, the method described herein can be run entirely on the first electronic device 125 using the obtained data, such as the obtained user information.

[0033] In an embodiment, the first electronic device 125 can include a central processing unit (CPU), among other components (discussed in more detail in FIGs. 11-12). An application can be installed or accessible on the first electronic device 125 for executing the methods described herein. The application can also be integrated into an operating system (OS) of the first electronic device 125. The first electronic device 125 can be any electronic device such as, but not limited to, a smart-phone, a personal computer, a tablet pc, a smart-watch, a smart-television, an interactive screen, an loT (Internet of things) device, or the like. Notably, the first electronic device 105 can be used by a user, such as a consumer of a telecommunications company or Pay TV operator, to generate a user account that can sign on (hereinafter also referred to as “log in”, “log on”, and “sign on”) to various other existing user accounts of the user.

[0034] FIG. IB is a schematic of the authentication and authorization system 199, according to an embodiment of the present disclosure. In an embodiment, the first electronic device 125 (herein also referred to as “the first user device 125”) can include a first OTT application 130, a second OTT application 140, and an operator application 150. The first OTT application 130, the secondOTT application 140, and the operator application 150 can include software developer kits (SDKs). An SDK can be a collection of tools, libraries, documentation, and resources that users (e.g., developers) can use to create software applications for specific platforms or frameworks. Platforms owners, like operating system vendors, hardware manufacturers, or service providers, can provide SDKs to assist developers in utilizing the target technologies. The SDK can provide developers with a standardized method to interact with the platform. Notably, the SDK can include libraries or application programming interfaces (APIs), development tools, documentation and sample code, etc. APIs can be pre-built code modules that provide functions and methods to interact with a platform and the platform’s features. The development tools of the SDK can include integrated development environments (IDEs) for writing and organizing code, compilers for translating code into machine-readable instructions, debuggers for finding and fixing issues, emulators and simulators for testing applications, and profiling tools for performance analysis.

[0035] SDKs can be provided for various platforms and technologies. For example, SDKs can be used for mobile operating systems, such as iOS and Android. For example, SDKs can be used for web development frameworks, such as React, Angular, and Node.js. For example, SDKs can be used for cloud platforms, such as Amazon Web Services and Google Cloud. For example, SDKs can be used for gaming platforms, such as GeForce NOW.

[0036] In an embodiment, the first OTT application 130 can include an SDK 135, the second OTT application 140 can include an SDK 145, and the operator application 150 can include an SDK 155. The first OTT application 130 can be a streaming service, such as Netflix. The second OTT application 140 can be a streaming service, such as Hulu. The user device 125 can be, for example, a smart phone device. The first OTT application 130, the second OTT application 140, and the operator application 150 can communicate with one another, as well as with a platform API 160 included on the user device 125.

[0037] In an embodiment, the first user device 125 can communicate with the second electronic device 190 (herein also referred to as “the server 190”) via the network 120. The server 190 can include a connected accounts platform 105, an access server 110, and an operator customer relationship management (CRM) 115. The operator CRM 115 can be a software system designed to manage customer or user interactions, relationships, and data for the telecommunications company and / or Pay TV operator. The operator CRM 115 can organize and maintain user information, track communication history, and facilitate user support and engagement processes.For example, the operator CRM 115 can store and manage user data, including contact information, service subscriptions, billing information, usage history, and user preferences. The operator CRM 115 can also allow the telecommunications company and / or the Pay TV operator to access and update user information. The access server 110 can be configured to receive provisioning from the operator CRM 115 or from the first user device 125 via the user (e.g., inapplication purchases, web-based purchases, etc.). The access server 110 can be configured to maintain user account entitlements, such as a product or service the user has purchased to use. To do this, the access server 110 can receive credentials from the user, such as a login and password for an account, and authenticate the user credentials and authorize access to corresponding account entitlements. For example, a token can be used that provides both authentication and authorization in order to log in the user and authorize a content set as part of the exchange. Lastly, the connected accounts platform 105 can be configured to maintain connected sign on account information / credentials or connected accounts of the user from other services and platforms. The connected accounts platform 105 can maintain a list of valid connected account credentials for the user, such as login information for ApplelD, Google ID, Facebook, etc.

[0038] It may be appreciated that a user experience can be significantly degraded as the number of OTT applications on the first user device 125 increases and the user is required to sign on to his / her corresponding account for each OTT application. For example, the first user device 125 can include a separate OTT application for Netflix, Hulu, HBO Max, Disney+, and Amazon Prime, and the user can be required to enter user credentials 5 times in order to sign on to the 5 accounts. For example, the first user device can include a separate OTT application for 100 different services or providers and the user can be required to enter user credentials 100 times in order to log in to the 100 accounts.

[0039] To this end, FIG. 2 is a schematic illustrating a method of authentication and authorizing access to content via dynamic provisioning, according to an embodiment of the present disclosure. As previously described, the access server 110 can receive provisioning from the operator CRM 115. At step 205, the operator CRM 115 can transmit the account entitlements for a user to the access server 110. The account entitlements can allow access to corresponding products, such as live TV, video on demand (VOD) services, or capabilities which represent access to applications and can include limits on the aforementioned. The limits can include, for example, a maximumnumber of hours of personal video recording (PVR), a maximum number of concurrent streams in use, etc.

[0040] The access server 110, at step 210, can receive a single sign on (SSO) request from the first OTT application 130 on the first user device 125. The access server 110 can provide a SSO service using a protocol such as OAUTH2, OpenlD Connect, or any other relevant protocol. This can allow each application to authenticate, sign on, and authorize access. The SSO request can prompt the user to enter, for example, a username and a password. The first OTT application 130 can, when successfully signing in using approved user credentials, receive a signed token from the access server 110 that includes the account entitlements and details of the corresponding user account. Thus, the access server 110 can, at step 215, transmit or provide a token to the first OTT application 130 on the first user device 125. The first OTT application 130 can, at step 220, transmit the token to a content provider 200. In an embodiment, the content provider 200 can be a streaming service such as Netflix, HBO Max, Hulu, Disney+, etc. The content provider 200 can provide or stream, for example, video data to the first user device 125 in the form of TV shows, movies, etc. The content provider 200 can validate the signed token using public key infrastructure (PKI) or shared secrets. At step 225, the content provider 200 can update an existing user account corresponding to the token or, in the event a user account does not exist for the corresponding token, create a new user account. For the new user account, the content provider 200 can provision the account with access as defined in the token. For an existing user account, the content provider 200 can update the account with access as defined in the token (which may have changed since the last use of the service). At step 230, the content provider 200 can allow immediate access to content of the content provider 200 to the first OTT application 130 on the first user device 125.

[0041] Notably, the signed token can have a refresh period and a refresh token defined, and on expiry, the content provider 200 can call the access server 110 with a refresh token (to ensure security) and the process above can re-execute updating access to the content. To this end, at step 235, the content provider 200 can transmit a token update request to the access server 110 and the access server 110 can, at step 240, transmit an updated token to the content provider 200. At step 245, the content provider 200 can update (or create) the user account and, at step 250, allow immediate content access to the first OTT application 130 based on the updated token. For example, the user account could have changed since the last refresh period and entitlements of the user account can be updated, such as an upgrade from a basic level account to a premium levelaccount that provides access to higher quality video content, faster streaming, video storages for offline viewing, etc.

[0042] Additionally or alternatively, the token can be used to authenticate trusted applications on the first user device 125 to reduce the number of sign on prompts experienced by the user.

[0043] To this end, FIG. 3 is a schematic illustrating a method of authenticating credentials and authorizing access to content via a transparent sign on, according to an embodiment of the present disclosure. The first OTT application 130 can include the SDK 135 (and the second OTT application 140 can include the SDK 145) provided by the operator (the Pay TV operator) of the operator application 150. Similarly, the SDK 155 of the operator application 150 can be provided by the operator. The operator application 150 can obtain a trusted token after a successful first sign on by the user, which can be obtained by the SDK 135 of the first OTT application 130 to perform a second sign on into another account for the second OTT application 140 without prompting the user for an additional sign on (thus requiring data entry by the user). Therefore, the additional sign on is essentially transparent to, or not experienced by, or hidden from the user.

[0044] In an embodiment, at step 300, the operator CRM 115 can transmit the account entitlements for the user to the access server 110. That is to say, at step 300, the access server 110 can receive, from the operator CRM 115, the account entitlements for the user. Again, the account entitlements can allow access to corresponding products, such as live TV, VOD services, or capabilities which represent access to applications and can include limits on the aforementioned. The limits can include, for example, a maximum number of hours of PVR, a maximum number of concurrent streams in use, etc.

[0045] In an embodiment, at step 305, the operator application 150 can transmit or provide the SSO request to the access server 110 via the network 120. That is to say, the access server 110 can, at step 305, receive a SSO request from the operator application 150 on the first user device 125. Here, the SSO request originates from the operator application 150 instead of the OTT application 130, as compared to FIG. 2. Additionally or alternatively, at step 305a, the first OTT application 130 can transmit or provide the SSO request to the access server 110 via the network 120. That is to say, the access server 110 can, at step 305a, receive the SSO request from the first OTT application 130 on the first user device 125.

[0046] In an embodiment, the access server 110 can, at step 307, log the operator application 150 into an account of the content provider 200. The access server 110 can, at step 310, transmit thetoken to the operator application 150 upon authenticating the user credentials which authorizes access to content of the content provider 200. The token can be described as a transparent SSO token. That is to say, the operator application 150 can, at step 310, receive the transparent SSO token from the access server 110. Additionally or alternatively, at step 310a, the access server 110 can transmit the token to the first OTT application 130 upon authenticating the user credentials. That is to say, the first OTT application 130 can, at step 310a, receive the transparent SSO token from the access server 110.

[0047] In an embodiment, at step 315, when the user completes the SSO request, the transmitted transparent SSO token can represent authenticated user credentials and authorized access to the content of the content provider 200, and the transmitted SSO token can be stored securely in a storage of the first user device 125. The transparent SSO token can provide access to the content on the content provider 200. Further, the SDK 135 of the first OTT application 130, the SDK 145 of the second OTT application 140, and the SDK 155 of the operator application 150 can register, using inter-process communication methods, a listener for other applications that can use the transparent SSO token. In the context of a device platform, the listener can be a software component that actively listens for specific events or signals generated by the device. When the specific event occurs, the listener can be triggered, and the listener can execute a designated code or callback function to address the specific event.

[0048] In an embodiment, the user can be logged into the first OTT application 130 and then attempt to access, without being logged in, the second OTT application 140. At this point, the attempt to access the second OTT application 140 can cause the second OTT application 140 to call the first OTT application 130 using the inter-process communication method. That is, in step 330, the second OTT application 140 can transmit the transparent SSO token request to the first OTT application 130. The first OTT application 130 can already be authenticated and authorized to have access to the transparent SSO token stored on the first user device 125. Thus, the transparent SSO token can be accessible on the first user device 125. The first OTT application 130 can, at step 332, initially authenticate or ensure that the second OTT application 140 is trusted and authentic to the operator of the operator application 150, and therefore also authorized or trusted to access the transparent SSO token stored on the first user device 125.

[0049] In an embodiment, upon determining the second OTT application 140 is trusted and authorized to access the transparent SSO token, the first OTT application 130 can, at step 335,transmit the transparent SSO token to the second OTT application 140. Again, although not shown, the first OTT application 130 can have already been provided the transparent SSO token in order to transmit the transparent SSO token to the second OTT application 140.

[0050] Additionally or alternatively, in an embodiment, at step 330a, the second OTT application 140 can transmit a request for the transparent SSO token to the operator application 150. That is, the operator application 150 can, at step 330a, receive a transparent SSO token request from the second OTT application 140. The operator application 150 can, at step 332a, initially authenticate or ensure that the second OTT application 140 is trusted and authentic to the operator of the operator application 150, and therefore also authorized or trusted to access the transparent SSO token stored on the first user device 125. The transparent SSO token request can be digitally signed (e.g., by the first OTT application 130) to ensure the SDK 145 of the second OTT application 140 making the call is also authorized or trusted by (and / or provided by) the operator of the operator application 150.

[0051] Additionally or alternatively, in an embodiment, upon determining the second OTT application 140 is authenticated and authorized to access the transparent SSO token, the operator application 150 can, at step 335a, transmit or provide the transparent SSO token to the second OTT application 140.

[0052] In an embodiment, the second OTT application 140 can, at step 340, transmit the transparent SSO token to the access server 110 along with another SSO request for obtaining access to content from the content provider 200 (or a different content provider having different content). This can result in authentication of the transparent SSO token and the user credentials, and access authorized for the second OTT application 140. For example, in response to determining the transparent SSO token received from the second OTT application 140 is a same transparent SSO token transmitted to the first OTT application 130 and / or the operator application 150 in response to the first SSO request (the authentication step), the access server 110 can authorize access to the content of the content provider 200 to the second OTT application 140.

[0053] In an embodiment, upon authenticating the user, the access server 110 can, at step 345, log the user into an account of the content provider 200 (or different content provider) that corresponds to the second OTT application 140 and authorize access to the content of the content provider 200, triggering similar logic to a username / password event.

[0054] In an embodiment, the content provider 200 can, at step 350, allow access to the content of the content provider 200 to the second OTT application 140. Notably, the user has effectively logged into the second OTT application 140 without having to enter user credentials. Instead, the process to log the user into the second OTT application 140 leverages the trust between the SDK 135 of the first OTT application 130, the SDK 145 of the second OTT application 140, and the SDK 155 of the operator application 150, and the transparent SSO token. Further, the process is effectively transparent or not seen / experienced by the user since the user did not have to actively answer any prompts or provide additional credentials. Notably, the account entitlements can be provided by the operator CRM 115 as previously described. Advantageously, as the number of OTT applications the user wishes to access increases, the amount of user input or effort saved increases. Furthermore, the concepts described above and herein can also be applicable to other forms of membership-based accounts, such as over social media, gaming platforms, live gaming or content creator streaming services, and the like.

[0055] Connected accounts can also be used to sign the user into accounts. FIG. 4 is a schematic illustrating a method of authenticating credentials and authorizing access to content via connected account sign on, according to an embodiment of the present disclosure. In an embodiment, the operator CRM 115 can transmit the account entitlements for the user to the access server 110. That is to say, at step 400, the access server 110 can receive, from the operator CRM 115, the account entitlements for the user. Again, the account entitlements can allow access to corresponding products, such as live TV, VOD services, or capabilities which represent access to applications and can include limits on the aforementioned. The limits can include, for example, a maximum number of hours of PVR, a maximum number of concurrent streams in use, etc.

[0056] In an embodiment, the connected accounts platform 105 can, at step 405, transmit connected sign on account credentials to the access server 110. That is to say, the access server 110 can, at step 405, receive the connected sign on account credentials from the connected accounts platform 105. Again, the connected sign on account credentials can include a list of one or more valid connected accounts or account credentials for the user, such as login information for ApplelD, Google ID, Facebook, etc. that can be used to also sign on to other applications, platforms, and services.

[0057] In an embodiment, the operator application 150 can, at step 410, transmit a connected account ID to the access server 110. That is to say, the access server 110 can, at step 410, receivethe connected account ID from the operator application 150. For example, the connected account ID can be an email address. The connected account ID can be matched and exchanged for a token by the access server 110.

[0058] In an embodiment, the access server 110 can, at step 415, transmit or provide the token to the operator application 150. That is to say, the operator application 150 can, at step 415, receive the token from the access server 110. Again, the transmitted token can represent authenticated user credentials which can correspond to the connected sign on account credentials and authorizes access to content of the content provider 200.

[0059] In an embodiment, the operator application 150 can, at step 420, store the token. The transmitted token can be stored securely in a storage of the first user device 125, but be accessible to the first OTT application 130, the second OTT application 140, the operator application 150, etc. In an embodiment, the token can be accessible to the first OTT application 130, the second OTT application 140, the operator application 150, etc. when requested. For example, the token can remain held by the access server 110. Importantly, the token will always be accessible to the first OTT application 130, the second OTT application 140, the operator application 150, etc. after authentication.

[0060] In an embodiment, the first OTT application 130 can, at step 430, request the token from the operator application 150.

[0061] In an embodiment, the operator application 150 can, at step 432, initially authenticate or ensure that the first OTT application 130 is trusted and authentic to the operator of the operator application 150, and therefore also authorized or trusted to access the token stored on the first user device 125.

[0062] In an embodiment, the operator application 150 can, at step 440, transmit or provide the token to the first OTT application 130. The operator application 150 can first authenticate the first OTT application 130 using the SDK 135 before transmitting or providing the token. For example, the operator application 150 can determine the first set of connected account credentials matches an authorized connected account on the list of valid or authorized connected sign on accounts or account credentials before sending the token to the first OTT application 130.

[0063] In an embodiment, in turn, the first OTT application 130 can, at step 445, transmit or provide the token to the access server 110.

[0064] In an embodiment, the access server 110 can, at step 450, log the first OTT application 130 into the account of the content provider 200 (or a different content provider) upon determining the token is authentic and authorize access to content of the content provider 200.

[0065] In an embodiment, the content provider 200 can then, at step 455, allow access to content of the content provider 200 to the first OTT application 130.

[0066] With regards to the method of FIG. 4, in an embodiment, the first OTT application 130 may or may not support connected account sign on. In the event the first OTT application 130 does support connected account sign on, the first OTT application 130 can call the access server 110 with the connected sign on account credentials and, if the connected sign on account credentials match or correspond to a target token, the first OTT application 130 can be authenticated and signed into the account corresponding to the content provider 200. In the event the first OTT application 130 does not support connected account sign on or does not have an account mapping established, the access server 110 can use the transparent sign on method to log in.

[0067] Further, the first OTT application 130 can obtain data of connected sign on account credentials permitting sign on in the future. An event can occur where the first OTT application 130 supports connected sign on and the second OTT application 140 supports connected sign on, but the connected sign on account credentials used for the first OTT application can be invalid for the second OTT application 140. In such an event, a second set of connected sign on account credentials can be input or provided by the user for signing on to the second OTT application 140. Upon determining the second set of connected sign on account credentials is valid for the second OTT application 140, the access server 110 can update the list of valid connected sign on accounts or account credentials via the connected accounts platform 105. For example, the access server 110 can check the second set of connected sign on account credentials is valid with the content provider 200 (or another content provider associated with the second set of connected sign on account credentials).

[0068] In an embodiment, authorizing the access to the content of the content provider 200 to the second OTT application 140 can include determining whether the second OTT application 140 is on the (same) user device with the first OTT application 130. For example, the first OTT application 130 and the second OTT application 140, when installed on the first user device 125, can have an additional configuration parameter or setting outlining that both OTT applications originate from the same device to ensure any malicious software on another device cannot mimicor emulate one of the OTT applications. Upon determining the first OTT application 130 and the second OTT application 140 are not on the same device, the authorization can be denied. Otherwise, the authentication and authorization process can proceed.

[0069] In an embodiment, authorizing the access to the content of the content provider 200 to the second OTT application 140 can include determining whether the second OTT application 140 is on the same network with the first OTT application 130. For example, the first OTT application 130 and the second OTT application 140, when installed on the first user device 125, can have an additional configuration parameter or setting outlining that both OTT applications originate from the same network to provide additional security, such as both OTT applications being on the same home / residential Wi-Fi network. Upon determining the first OTT application 130 and the second OTT application 140 are not on the same network, the authorization can be denied. Otherwise, the authentication and authorization process can proceed.

[0070] Advantageously, with regards to the method of FIG. 4, the first OTT application 130 and the second OTT application 140 can be different application platforms, and the connected sign on can allow cross-application authentication and access authorization.

[0071] FIG. 5 is a schematic illustrating a method of authenticating credentials and authorizing access to content via notification-based sign on, according to an embodiment of the present disclosure. In an embodiment, the SDK 135 of the first OTT application 130, the SDK 145 of the second OTT application 140, and the SDK 155 of the operator application 150 can support receiving of push notifications. When a user wants to sign on to the second OTT application 140 and has already signed on to the first OTT application 130, the notification-based sign on can provide a passwordless log in.

[0072] In an embodiment, the operator CRM 115 can transmit the account entitlements for the user to the access server 110. That is to say, at step 500, the access server 110 can receive, from the operator CRM 115, the account entitlements for the user.

[0073] In an embodiment, at step 505, the operator application 150 can sign the user into the first OTT application 130.

[0074] In an embodiment, the content provider 200 can, at step 510, allow access to content of the content provider 200 to the operator application 150 upon determining the user credentials provided are valid or authenticated. Thus, the first OTT application 130 also has access to the content of the content provider 200.

[0075] In an embodiment, the user can attempt to sign on to the second OTT application 140. Instead of providing all the user credentials, the user can input or provide just a username, for example, to the access server 110. Thus, the second OTT application 140 can, at step 515, transmit the username to the access server 110 with a sign-on request.

[0076] In an embodiment, the access server 110 can transmit a notification to the operator application 150 that a passwordless login attempt is occurring for the second OTT application 140 and instruct the operator application 150 to display a sign on notification to the user.

[0077] In an embodiment, the operator application 150 can, at step 525, display the sign on notification to the user via the first OTT application 130 that the user has already successfully signed into.

[0078] In an embodiment, the user can approve or accept the sign on attempt and the operator application can, at step 530, transmit the acceptance of the passwordless login attempt.

[0079] In an embodiment, the access server 110 can transmit a notification to the operator application 150 that a passwordless login attempt is occurring for the second OTT application 140 and instruct the operator application 150 to display a sign on notification to the user that the second OTT application 140 will be authorized to access the content of the content provider 200 (or different content provider) after a set / predetermined duration of time has lapsed without intervention from the user (in other words, if the user does not intervene, access will be authorized after a particular duration of time). This duration of time can be set to any amount of time - for example, 5 seconds, 10 seconds, etc. For example, the notification can include an option for the user to cancel the sign on before 90 seconds has elapsed.

[0080] In an embodiment, the transparent sign on method can be used at step 535 to sign on to the second OTT application 140. Again, since the first OTT application 130 and the second OTT application 140 need not be from the same application platform, the notification-based sign on can also allow cross-application authentication.

[0081] FIG. 6 is a schematic illustrating a method of authenticating credentials and authorizing access to content via network-based sign on, according to an embodiment of the present disclosure. In an embodiment, even a username need not be provided by the user for a sign on attempt. Instead, another protocol, such as Bonjour, can be used to detect other applications on a local network. In the non-limiting example of Bonjour, Bonjour is a network protocol that can provide automatic discovery and configuration of devices or services on a local network without the need for manualconfiguration or the use of IP addresses. Bonjour can allow devices and services to find and communicate with one another on a local network. Bonjour can facilitate the process of connecting devices, such as computers, printers, and other network-enabled devices, by automatically detecting and broadcasting their presence. It may be appreciated that other protocols can be used.

[0082] In an embodiment, the first user device 125 can be on a local network 605 with an application 600. The operator CRM 115 can transmit the account entitlements for the user to the access server 110. That is to say, at step 610, the access server 110 can receive, from the operator CRM 115, the account entitlements for the user.

[0083] In an embodiment, the first OTT application 130 can, at step 615, transmit a content access request to the content provider 200. That is to say, the content provider 200 can, at step 615, receive the content access request from the first OTT application 130.

[0084] In an embodiment, the content provider 200 can, at step 620, transmit an OTT application authorization request to the access server 110. That is to say, the access server 110 can, at step 620, receive the OTT application authorization request.

[0085] In an embodiment, the access server 110 can, at step 625, transmit a sign-on request for the first OTT application 130 to the application 600. That is to say, the application 600 can, at step 625, receive the sign-on request for the first OTT application 130 from the access server 110. The application 600 can determine whether the first OTT application 130 on the first user device 125 is on a (same) local network 605 as the application 600. Upon determining the first OTT application 130 on the first user device 125 is, in fact, on the local network 605, the first OTT application 130 can be authorized. Otherwise, the authorization can be denied.

[0086] In an embodiment, the application 600 can, at step 630, sign the first OTT application 130 into an account of the content provider 200.

[0087] In an embodiment, the content provider 200 can, at step 635, allow access to content of the content provider 200 to the first OTT application 130.

[0088] With reference to FIG. 2, FIG. 7 is an exemplary flow chart for a method 700 of authenticating credentials and authorizing access to content via dynamic provisioning, according to an embodiment of the present disclosure. In an embodiment, at step 705, the access server 110 can receive the account entitlement information. In an embodiment, at step 710, the access server 110 can receive the SSO request. In an embodiment, at step 715, the access server 110 can determine whether to authorize or reject the SSO request. In an embodiment, at step 720, the accessserver 110 can reject (not authorize) the SSO request and the method 700 ends at step 730. In an embodiment, at step 725, the access server 110 can authorize the SSO request and transmit the token. For example, the access server 110 can transmit the token to the first OTT application 130. In an embodiment, at step 735, the access server 110 can determine whether a token update is requested. In an embodiment, upon determining a token update is not requested, the method 700 can proceed back to step 735. In an embodiment, upon determining a token update is requested, the access server 110 can transmit the updated token at step 740. For example, the access server 110 can transmit the updated token to the content provider 200.

[0089] With reference to FIG. 3, FIG. 8A is an exemplary flow chart for a method 800 of authenticating credentials and authorizing access to content via transparent sign on, according to an embodiment of the present disclosure. In an embodiment, at step 805, the access server 110 can receive the account entitlement information. In an embodiment, at step 810, the access server 110 can receive the SSO request. In an embodiment, at step 815, the access server 110 can transmit the transparent SSO token. For example, the access server 110 can transmit the transparent SSO token to the operator application 150. For example, the access server 110 can transmit the transparent SSO token to the first OTT application 130. In an embodiment, at step 817, the operator application 150 or the first OTT application 130 can store the transparent SSO token in a storage. In an embodiment, at step 820, the operator application 150 can determine whether a token request has been received from an OTT application (the first OTT application 130, the second OTT application 140, etc.). In an embodiment, the first OTT application 130 can be authenticated, have a listener installed, and receive the token request from another OTT application (the second OTT application 140). In an embodiment, upon determining a token request has not been received, the operator application 150 or the first OTT application 130 can continue monitoring for a token request. In an embodiment, upon determining a token request has been received from the OTT application, the operator application 150 can determine whether the OTT application and / or the token request is authentic at step 825. Additionally or alternatively, at step 825, upon determining a token request has been received from the second OTT application 140, the first OTT application 130 can determine whether the second OTT application 140 and / or the token request is authentic. In an embodiment, upon determining the OTT application and / or the token request is authentic, the operator application 150 can transmit or provide the transparent SSO token to the requesting OTT application at step 830 to authorize access to the content of the content provider 200. Additionallyor alternatively, at step 830, upon determining the second OTT application 140 and / or the token request is authentic, the first OTT application 130 can transmit or provide the transparent SSO token to the second OTT application 140 to authorize access to the content of the content provider 200. In an embodiment, upon determining the OTT application and / or the token request is not authentic, the operator application 150 (or the first OTT application 130) can reject the token request at step 835. In an embodiment, at step 840, the OTT application can transmit the transparent SSO token to the access server 110. In an embodiment, at step 845, the access server 110 can determine whether the OTT application and / or the token is authentic. In an embodiment, upon determining the OTT application and / or the token is not authentic, the access server 110 can reject the request (shown as proceeding to step 835). In an embodiment, upon determining the OTT application and / or the token is authentic, the access server 110 can log the OTT application in to an account of the content provider 200 at step 850. In an embodiment, at step 855, the content provider 200 can allow access to content of the content provider 200 to the OTT application.

[0090] Additionally or alternatively, in an embodiment, at step 815, the access server 110 can transmit the transparent SSO token to the first OTT application 130. To this end, with reference to FIG. 3 and the method 800 of FIG. 8 A, FIG. 8B is an exemplary flow chart for a method 800a of authenticating credentials and authorizing access to content via transparent sign on, according to an embodiment of the present disclosure. In an embodiment, at step 805a (which can correspond to a similar action at step 820 of the method 800), the first OTT application 130 can receive a token request from the second OTT application 140. In an embodiment, at step 810a, upon determining the token request has been received from the second OTT application 140, the first OTT application 130 can determine whether the second OTT application 140 and / or the token request is authentic. In an embodiment, upon determining the second OTT application 140 and / or the token request is authentic, the first OTT application 130 can transmit or provide the transparent SSO token to the second OTT application 140 at step 815a to authorize access to the content of the content provider 200. In an embodiment, upon determining the second OTT application 140 and / or the token request is not authentic, the first OTT application 130 can reject the token request and end at step 835a. In an embodiment, at step 820a, the second OTT application 140 can transmit the transparent SSO token to the access server 110 with a sign-on request. In an embodiment, at step 825a, the access server 110 can determine whether the second OTT application 140 and / or the token is authentic. In an embodiment, upon determining the OTT application and / or the tokenis not authentic, the access server 110 can reject the request (shown as proceeding to step 835a). In an embodiment, upon determining the second OTT application 140 and / or the token is authentic, the access server 110 can log the second OTT application 140 in to an account of the content provider 200 at step 830a. In an embodiment, at step 840a, the content provider 200 can allow access to content of the content provider 200 to the second OTT application 140.

[0091] With reference to FIG. 4, FIG. 9 is an exemplary flow chart for a method 900 of authenticating credentials and authorizing access to content via connected account sign on, according to an embodiment of the present disclosure. In an embodiment, at step 905, the access server 110 can receive the account entitlement information. In an embodiment, at step 910, the access server 110 can receive connected sign on account credentials / information. For example, the operator CRM 115 can transmit the connected sign on account credentials to the access server 110. In an embodiment, at step 915, the access server 110 can receive the connected account ID information that corresponds to the connected sign on account credentials. For example, the operator application 150 can prompt the user to enter the connected account ID information and transmit the connected account ID information to the access server 110. In an embodiment, at step 920, the access server 110 can transmit the token. For example, the access server 110 can transmit the token corresponding to the received connected account ID information to the operator application 150. In an embodiment, at step 925, the operator application 150 can store the token in a storage. In an embodiment, at step 935, the operator application 150 can determine whether a token request has been received from an OTT application (e.g., the first OTT application 130, the second OTT application 140, etc.). In an embodiment, upon determining a token request has not been received, the operator application 150 can continue monitoring for a token request. In an embodiment, upon determining a token request has been received from the OTT application, the operator application 150 can determine whether the OTT application and / or the token request is authentic at step 940. In an embodiment, upon determining the OTT application and / or the token request is authentic, the operator application 150 can transmit or provide the token to the requesting OTT application at step 950 to authorize access to the content of the content provider 200. In an embodiment, upon determining the OTT application and / or the token request is not authentic, the operator application 150 can reject the token request at step 945. In an embodiment, at step 955, the OTT application can transmit the token and the connected account sign on credentials to the access server 110. In an embodiment, at step 960, the access server 110 can determine whether theOTT application and / or the token is authentic. In an embodiment, upon determining the OTT application and / or the token is not authentic, the access server 110 can reject the request (shown as proceeding to step 945). In an embodiment, upon determining the OTT application and / or the token is authentic, the access server 110 can log the OTT application in to an account of the content provider 200 at step 965. In an embodiment, at step 970, the content provider 200 can allow access to content of the content provider 200 to the OTT application.

[0092] With reference to FIG. 5, FIG. 10A is an exemplary flow chart for a method 1000 of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure. In an embodiment, at step 1005, the OTT application can transmit a request for passwordless login to the access server 110. In an embodiment, at step 1010, the access server 110 can determine whether the OTT application is authentic. Upon determining the OTT application is not authentic, the access server 110 can reject the request and end at step 1020. Upon determining the OTT application is authentic, the access server 110 can perform a SSO at step 1015 to authorize access to the content of the content provider 200.

[0093] With reference to FIG. 5, FIG. 10B is an exemplary flow chart for a method 1025 of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure. Similar to the method 1000, in an embodiment, at step 1030, the OTT application can transmit a request for passwordless login to the access server 110. In an embodiment, at step 1035, the access server 110 can transmit an instruction to the operator application 150 to display a notification that a passwordless login is occurring. In an embodiment, at step 1040, the user can determine whether the OTT application is authentic and should be allowed to perform the passwordless login. Upon determining the OTT application is not authentic, the user can deny the login request and end at step 1055. Upon determining the OTT application is authentic, the user can accept the login request at step 1045 and the passwordless login process can continue.

[0094] With reference to FIG. 5, FIG. 10C is an exemplary flow chart for a method 1025 of authenticating credentials and authorizing access to content via passwordless sign on, according to an embodiment of the present disclosure. Similar to the method 1000 and the method 1025, in an embodiment, at step 1065, the OTT application can transmit a request for passwordless login to the access server 110. Here, this can be triggered via a network-based protocol, such as Bonjour. In an embodiment, at step 1070, the access server 110 can transmit an instruction to the operatorapplication 150 to display a notification that a passwordless login is occurring. In an embodiment, at step 1075, the user can determine whether the OTT application is authentic and should be allowed to perform the passwordless login. Upon determining the OTT application is not authentic, the user can deny the login request and end at step 1085. Upon determining the OTT application is authentic, the user can accept the login request at step 1080 and the passwordless login process can continue.

[0095] Embodiments of the subject matter and the functional operations described in this specification can be implemented by digital electronic circuitry (on one or more of devices 125, 190, 195, etc.), in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory program carrier for execution by, or to control the operation of data processing apparatus, such as the devices of FIG. 1A (e.g., devices 125, 190, 195, etc.) or the like. The computer storage medium can be a machine- readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0096] The term “data processing apparatus” refers to data processing hardware and may encompass all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be or further include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0097] A computer program, which may also be referred to or described as a program, software, a software application, a module, a software module, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, Subroutine, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0098] The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA an ASIC.

[0099] Computers suitable for the execution of a computer program include, by way of example, general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a CPU will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer are a CPU for performing or executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0100] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; forexample, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's device in response to requests received from the web browser.

[0101] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more Such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[0102] The computing system can include clients (user devices) and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In an embodiment, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the user device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received from the user device at the server.

[0103] Electronic user device 20 shown in FIG. 11 can be an example of one or more of the devices shown in FIG. 1. In an embodiment, the electronic user device 20 may be a smartphone. However, the skilled artisan will appreciate that the features described herein may be adapted to be implemented on other devices (e.g., a laptop, a tablet, a server, an e-reader, a camera, a navigation device, etc.). The exemplary user device 20 of FIG. 11 includes processing circuitry, as discussed above. The processing circuitry includes one or more of the elements discussed next with reference to FIG. 11. The electronic user device 20 may include other components not explicitly illustrated in FIG. 11 such as a CPU, GPU, frame buffer, etc. The electronic user device 20 includes acontroller 1110 and a wireless communication processor 1102 connected to an antenna 1101. A speaker 1104 and a microphone 1105 are connected to a voice processor 1103.

[0104] The controller 1110 may include one or more processors / processing circuitry (CPU, GPU, or other circuitry) and may control each element in the user device 20 to perform functions related to communication control, audio signal processing, graphics processing, control for the audio signal processing, still and moving image processing and control, and other kinds of signal processing. The controller 1110 may perform these functions by executing instructions stored in a memory 1150. Alternatively or in addition to the local storage of the memory 1150, the functions may be executed using instructions stored on an external device accessed on a network or on a non-transitory computer readable medium.

[0105] The memory 1150 includes but is not limited to Read Only Memory (ROM), Random Access Memory (RAM), or a memory array including a combination of volatile and non-volatile memory units. The memory 1150 may be utilized as working memory by the controller 1110 while executing the processes and algorithms of the present disclosure. Additionally, the memory 1150 may be used for long-term storage, e.g., of image data and information related thereto.

[0106] The user device 20 includes a control line CL and data line DL as internal communication bus lines. Control data to / from the controller 1110 may be transmitted through the control line CL. The data line DL may be used for transmission of voice data, displayed data, etc.

[0107] The antenna 1101 transmits / receives electromagnetic wave signals between base stations for performing radio-based communication, such as the various forms of cellular telephone communication. The wireless communication processor 1102 controls the communication performed between the user device 20 and other external devices via the antenna 1101. For example, the wireless communication processor 1102 may control communication between base stations for cellular phone communication.

[0108] The speaker 1104 emits an audio signal corresponding to audio data supplied from the voice processor 1103. The microphone 1105 detects surrounding audio and converts the detected audio into an audio signal. The audio signal may then be output to the voice processor 1103 for further processing. The voice processor 1103 demodulates and / or decodes the audio data read from the memory 1150 or audio data received by the wireless communication processor 1102 and / or a short-distance wireless communication processor 1107. Additionally, the voice processor 1103 may decode audio signals obtained by the microphone 1105.

[0109] The exemplary user device 20 may also include a display 1120, a touch panel 1130, an operation key 1140, and a short-distance communication processor 1107 connected to an antenna 1106. The display 1120 may be a Liquid Crystal Display (LCD), an organic electroluminescence display panel, or another display screen technology. In addition to displaying still and moving image data, the display 1120 may display operational inputs, such as numbers or icons which may be used for control of the user device 20. The display 1120 may additionally display a GUI for a user to control aspects of the user device 20 and / or other devices. Further, the display 1120 may display characters and images received by the user device 20 and / or stored in the memory 1150 or accessed from an external device on a network. For example, the user device 20 may access a network such as the Internet and display text and / or images transmitted from a Web server.

[0110] The touch panel 1130 may include a physical touch panel display screen and a touch panel driver. The touch panel 1130 may include one or more touch sensors for detecting an input operation on an operation surface of the touch panel display screen. The touch panel 1130 also detects a touch shape and a touch area. Used herein, the phrase “touch operation” refers to an input operation performed by touching an operation surface of the touch panel display with an instruction object, such as a finger, thumb, or stylus-type instrument. In the case where a stylus or the like is used in a touch operation, the stylus may include a conductive material at least at the tip of the stylus such that the sensors included in the touch panel 1130 may detect when the stylus approaches / contacts the operation surface of the touch panel display (similar to the case in which a finger is used for the touch operation).

[0111] In certain aspects of the present disclosure, the touch panel 1130 may be disposed adjacent to the display 1120 (e.g., laminated) or may be formed integrally with the display 1120. For simplicity, the present disclosure assumes the touch panel 1130 is formed integrally with the display 1120 and therefore, examples discussed herein may describe touch operations being performed on the surface of the display 1120 rather than the touch panel 1130. However, the skilled artisan will appreciate that this is not limiting.

[0112] For simplicity, the present disclosure assumes the touch panel 1130 is a capacitance-type touch panel technology. However, it should be appreciated that aspects of the present disclosure may easily be applied to other touch panel types (e.g., resistance-type touch panels) with alternate structures. In certain aspects of the present disclosure, the touch panel 1130 may includetransparent electrode touch sensors arranged in the X-Y direction on the surface of transparent sensor glass.

[0113] The touch panel driver may be included in the touch panel 1130 for control processing related to the touch panel 1130, such as scanning control. For example, the touch panel driver may scan each sensor in an electrostatic capacitance transparent electrode pattern in the X-direction and Y-direction and detect the electrostatic capacitance value of each sensor to determine when a touch operation is performed. The touch panel driver may output a coordinate and corresponding electrostatic capacitance value for each sensor. The touch panel driver may also output a sensor identifier that may be mapped to a coordinate on the touch panel display screen. Additionally, the touch panel driver and touch panel sensors may detect when an instruction object, such as a finger is within a predetermined distance from an operation surface of the touch panel display screen. That is, the instruction object does not necessarily need to directly contact the operation surface of the touch panel display screen for touch sensors to detect the instruction object and perform processing described herein. For example, in an embodiment, the touch panel 1130 may detect a position of a user’s finger around an edge of the display panel 1120 (e.g., gripping a protective case that surrounds the display / touch panel). Signals may be transmitted by the touch panel driver, e.g. in response to a detection of a touch operation, in response to a query from another element based on timed data exchange, etc.

[0114] The touch panel 1130 and the display 1120 may be surrounded by a protective casing, which may also enclose the other elements included in the user device 20. In an embodiment, a position of the user’s fingers on the protective casing (but not directly on the surface of the display 1120) may be detected by the touch panel 1130 sensors. Accordingly, the controller 1110 may perform display control processing described herein based on the detected position of the user’s fingers gripping the casing. For example, an element in an interface may be moved to a new location within the interface (e.g., closer to one or more of the fingers) based on the detected finger position.

[0115] Further, in an embodiment, the controller 1110 may be configured to detect which hand is holding the user device 20, based on the detected finger position. For example, the touch panel 1130 sensors may detect fingers on the left side of the user device 20 (e.g., on an edge of the display 1120 or on the protective casing), and detect a single finger on the right side of the user device 20. In this exemplary scenario, the controller 1110 may determine that the user is holdingthe user device 20 with his / her right hand because the detected grip pattern corresponds to an expected pattern when the user device 20 is held only with the right hand.

[0116] The operation key 1140 may include one or more buttons or similar external control elements, which may generate an operation signal based on a detected input by the user. In addition to outputs from the touch panel 1130, these operation signals may be supplied to the controller 1110 for performing related processing and control. In certain aspects of the present disclosure, the processing and / or functions associated with external buttons and the like may be performed by the controller 1110 in response to an input operation on the touch panel 1130 display screen rather than the external button, key, etc. In this way, external buttons on the user device 20 may be eliminated in lieu of performing inputs via touch operations, thereby improving watertightness.

[0117] The antenna 1106 may transmit / receive electromagnetic wave signals to / from other external apparatuses, and the short-distance wireless communication processor 1107 may control the wireless communication performed between the other external apparatuses. Bluetooth, IEEE 802.11, and near-field communication (NFC) are non-limiting examples of wireless communication protocols that may be used for inter-device communication via the short-distance wireless communication processor 1107.

[0118] The user device 20 may include a motion sensor 1108. The motion sensor 1108 may detect features of motion (i.e., one or more movements) of the user device 20. For example, the motion sensor 1108 may include an accelerometer to detect acceleration, a gyroscope to detect angular velocity, a geomagnetic sensor to detect direction, a geo-location sensor to detect location, etc., or a combination thereof to detect motion of the user device 20. In an embodiment, the motion sensor 1108 may generate a detection signal that includes data representing the detected motion. For example, the motion sensor 1108 may determine a number of distinct movements in a motion (e. g. , from start of the series of movements to the stop, within a predetermined time interval, etc.), a number of physical shocks on the user device 20 (e.g., a jarring, hitting, etc., of the electronic device), a speed and / or acceleration of the motion (instantaneous and / or temporal), or other motion features. The detected motion features may be included in the generated detection signal. The detection signal may be transmitted, e.g., to the controller 1110, whereby further processing may be performed based on data included in the detection signal. The motion sensor 1108 can work in conjunction with a Global Positioning System (GPS) section 1160. The information of the present position detected by the GPS section 1160 is transmitted to the controller 1110. An antenna 1161is connected to the GPS section 1160 for receiving and transmitting signals to and from a GPS satellite.

[0119] The user device 20 may include a camera section 1109, which includes a lens and shutter for capturing photographs of the surroundings around the user device 20. In an embodiment, the camera section 1109 captures surroundings of an opposite side of the user device 20 from the user. The images of the captured photographs can be displayed on the display panel 1120. A memory section saves the captured photographs. The memory section may reside within the camera section 109 or it may be part of the memory 1150. The camera section 1109 can be a separate feature attached to the user device 20 or it can be a built-in camera feature.

[0120] An example of a type of computer is shown in FIG. 12. The computer 9900 can be used for the operations described in association with any of the computer-implement methods described previously, according to one implementation. For example, the computer 9900 can be an example of devices 125, 195, or a server (such as the second electronic device 190). The computer 9900 includes processing circuitry, as discussed above. The second electronic device 190 can include other components not explicitly illustrated in FIG. 12 such as a CPU, GPU, frame buffer, etc. The processing circuitry includes one or more of the elements discussed next with reference to FIG. 12. In FIG. 12, the computer 9900 includes a processor 9910, a memory 9920, a storage device 9930, and an input / output device 9940. Each of the components 9910, 9920, 9930, and 9940 are interconnected using a system bus 9950. The processor 9910 is capable of processing instructions for execution within the system 9900. In one implementation, the processor 9910 is a singlethreaded processor. In another implementation, the processor 9910 is a multi-threaded processor. The processor 9910 is capable of processing instructions stored in the memory 9920 or on the storage device 9930 to display graphical information for a user interface on the input / output device 9940.

[0121] The memory 9920 stores information within the computer 9900. In one implementation, the memory 9920 is a computer-readable medium. In one implementation, the memory 9920 is a volatile memory unit. In another implementation, the memory 9920 is a non-volatile memory unit.

[0122] The storage device 9930 is capable of providing mass storage for the computer 9900. In one implementation, the storage device 9930 is a computer-readable medium. In various different implementations, the storage device 9930 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

[0123] The input / output device 9940 provides input / output operations for the computer 9900. In one implementation, the input / output device 9940 includes a keyboard and / or pointing device. In another implementation, the input / output device 9940 includes a display unit for displaying graphical user interfaces.

[0124] Next, a hardware description of a device according to exemplary embodiments is described with reference to FIG. 13. In FIG. 13, the device 1201, which can be the above-described devices of FIG. 1, includes processing circuitry, as discussed above. The processing circuitry includes one or more of the elements discussed next with reference to FIG. 13. The device can include other components not explicitly illustrated in FIG. 13, such as a CPU, GPU, frame buffer, etc. In FIG. 13, the device includes a CPU 1200 which performs the processes described above / below. The process data and instructions may be stored in memory 1202. These processes and instructions may also be stored on a storage medium disk 1204 such as a hard drive (HDD) or portable storage medium or may be stored remotely. Further, the claimed advancements are not limited by the form of the computer-readable media on which the instructions of the inventive process are stored. For example, the instructions may be stored on CDs, DVDs, in FLASH memory, RAM, ROM, PROM, EPROM, EEPROM, hard disk or any other information processing device with which the device 1201 communicates, such as a server or computer.

[0125] Further, the claimed advancements may be provided as a utility application, background daemon, or component of an operating system, or combination thereof, executing in conjunction with CPU 1200 and an operating system such as Microsoft Windows, UNIX, Solaris, LINUX, Apple MAC-OS and other systems known to those skilled in the art.

[0126] The hardware elements in order to achieve the device 1201 may be realized by various circuitry elements, known to those skilled in the art. For example, CPU 1200 may be a Xenon or Core processor from Intel of America or an Opteron processor from AMD of America, or may be other processor types that would be recognized by one of ordinary skill in the art. Alternatively, the CPU 1200 may be implemented on an FPGA, ASIC, PLD or using discrete logic circuits, as one of ordinary skill in the art would recognize. Further, CPU 1200 may be implemented as multiple processors cooperatively working in parallel to perform the instructions of the processes described above. CPU 1200 can be an example of the CPU illustrated in each of the devices of FIG. 1A.

[0127] The device in FIG. 13 also includes a network controller 1206, such as an Intel Ethernet PRO network interface card from Intel Corporation of America, for interfacing with network 120 (also shown in FIG. 1A), and to communicate with the other devices of FIG. 1A. As can be appreciated, the network 120 can be a public network, such as the Internet, or a private network such as an LAN or WAN network, or any combination thereof and can also include PSTN or ISDN sub-networks. The network 120 can also be wired, such as an Ethernet network, or can be wireless such as a cellular network including EDGE, 3G, 4G and 5G wireless cellular systems. The wireless network can also be WiFi, Bluetooth, or any other wireless form of communication that is known.

[0128] The device further includes a display controller 1208, such as a NVIDIA GeForce GTX or Quadro graphics adaptor from NVIDIA Corporation of America for interfacing with display 1210, such as an LCD monitor. A general purpose I / O interface 1212 interfaces with a keyboard and / or mouse 1214 as well as a touch screen panel 1216 on or separate from display 1210. General purpose I / O interface also connects to a variety of peripherals 1218 including printers and scanners.

[0129] A sound controller 1220 is also provided in the device 1201 to interface with speaker s / microphone 1222 thereby providing sounds and / or music.

[0130] The general purpose storage controller 1224 connects the storage medium disk 1204 with communication bus 1226, which may be an ISA, EISA, VESA, PCI, or similar, for interconnecting all of the components of the device. A description of the general features and functionality of the display 1210, keyboard and / or mouse 1214, as well as the display controller 1208, storage controller 1224, network controller 1206, sound controller 1220, and general purpose I / O interface 1212 is omitted herein for brevity as these features are known.

[0131] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments.

[0132] Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

[0133] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0134] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

[0135] Embodiments of the present disclosure may also be as set forth in the following parentheticals.

[0136] (1) A method, comprising receiving, from a first application on a user device, a first sign- on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.

[0137] (2) The method of (1), wherein the receiving the first sign-on request further comprises receiving a first set of connected account credentials, and the transmitting the token to the first application further comprises determining the first set of connected account credentials matches an authorized connected account on a list of authorized connected accounts before sending the token to the first application.

[0138] (3) The method of either (1) or (2), wherein the receiving the token and the second sign-on request from the second application further comprises receiving a second set of connected account credentials, and the authorizing the access to the content of the second content provider server to the second application further comprises upon determining the received second set of connected account credentials does not match an authorized connected account on the list of authorized connected accounts, transmitting the second set of connected account credentials to the second content provider server for authentication; and upon receiving confirmation from the second content provider server that the second set of connected account credentials permits the second application to receive the access to the content from the second content provider server, updating the list of authorized connected accounts with the second set of connected account credentials to define an additional authorized connected account.

[0139] (4) The method of any one of (1) to (3), wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining whether the second application is on the user device with the first application.

[0140] (5) The method of any one of (1) to (4), wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining the second application is on a second user device that is on a same network as the user device.

[0141] (6) The method of any one of (1) to (5), wherein the first application and the second application include embedded modules to manage sign-on and access based on the token.

[0142] (7) The method of any one of (1) to (6), wherein the authorizing the access to the content of the second content provider server to the second application further comprises instructing the first application to display a prompt requesting input from a user to approve or deny the requested access from the second application before authorizing the access to the content of the second content provider server to the second application.

[0143] (8) The method of any one of (1) to (7), wherein the authorizing the access is performed upon receiving the input from the user approving the requested access from the second application.

[0144] (9) The method of any one of (1) to (8), wherein the authorizing the access is not performed upon receiving the input from the user denying the requested access from the second application.

[0145] (10) The method of any one of (1) to (9), wherein the authorizing the access to the content of the second content provider server to the second application further comprises instructing the first application to display a notification to a user that the second application will be authorized to access the content of the second content provider server after a set duration of time has lapsed without user intervention.

[0146] (11) The method of any one of (1) to (10), wherein the token is stored on a secure storage of the user device, the secure storage being accessible to both the first application and the second application.

[0147] (12) The method of any one of (1) to (11), wherein the authorizing the access to the content of the second content provider server to the second application further comprises in response to determining the token received from the second application is not the same token transmitted to the first application in response to the first sign-on request, instructing the first application to display a prompt requesting input from a user to approve the requested access from the second application before authorizing the access to the content of the second content provider server to the second application, and authorizing the access to the content of the second content provider server to the second application upon receiving input from the user approving of the requested access from the second application.

[0148] (13) The method of any one of (1) to (12), wherein the first application is a first over-the- top application configured to stream and display the content from the first content provider server, and the second application is a second over-the-top application configured to stream and display the content from the second content provider server.

[0149] (14) The method of any one of (1) to (13), wherein the first application is an operator application configured to authenticate received authentication data from other applications on the user device, and the second application is a first over-the-top application configured to stream and display the content from the first content provider server.

[0150] (15) A non-transitory computer-readable medium encoded with computer-readable instructions that, when executed by a computer, causes the computer to perform a method, the method comprising: receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the firstapplication, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.

[0151] (16) The method of (15), wherein the receiving the first sign-on request further comprises receiving a first set of connected account credentials, and the transmitting the token to the first application further comprises determining the first set of connected account credentials matches an authorized connected account on a list of authorized connected accounts before sending the token to the first application.

[0152] (17) The method of either (15) or (16), wherein the receiving the token and the second sign-on request from the second application further comprises receiving a second set of connected account credentials, and the authorizing the access to the content of the second content provider server to the second application further comprises upon determining the received second set of connected account credentials does not match an authorized connected account on the list of authorized connected accounts, transmitting the second set of connected account credentials to the second content provider server for authentication; and upon receiving confirmation from the second content provider server that the second set of connected account credentials permits the second application to receive the access to the content from the second content provider server, updating the list of authorized connected accounts with the second set of connected account credentials to define an additional authorized connected account.

[0153] (18) The method of any one of (15) to (17), wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining whether the second application is on the user device with the first application.

[0154] (19) The method of any one of (15) to (18), wherein the authorizing the access to the content of the second content provider server to the second application further comprisesdetermining the second application is on a second user device that is on a same network as the user device.

[0155] (20) The method of any one of (15) to (19), wherein the authorizing the access to the content of the second content provider server to the second application further comprises instructing the first application to display a prompt requesting input from a user to approve or deny the requested access from the second application before authorizing the access to the content of the second content provider server to the second application.

[0156] (21) The method of any one of (15) to (20), wherein the authorizing the access is performed upon receiving the input from the user approving the requested access from the second application.

[0157] (22) An apparatus, comprising processing circuitry configured to receive, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmit, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receive, from a second application, the token and a second sign- on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorize access to the content of the second content provider server to the second application.

[0158] Thus, the foregoing discussion discloses and describes merely exemplary embodiments of the present disclosure. As will be understood by those skilled in the art, the present disclosure may be embodied in other specific forms without departing from the spirit thereof. Accordingly, the disclosure of the present disclosure is intended to be illustrative, but not limiting of the scope of the disclosure, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.

Claims

CLAIMS1. A method, comprising: receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.

2. The method of Claim 1 , wherein the receiving the first sign-on request further comprises receiving a first set of connected account credentials, and the transmitting the token to the first application further comprises determining the first set of connected account credentials matches an authorized connected account on a list of authorized connected accounts before sending the token to the first application.

3. The method of Claim 2, wherein the receiving the token and the second sign-on request from the second application further comprises receiving a second set of connected account credentials, and the authorizing the access to the content of the second content provider server to the second application further comprisesupon determining the received second set of connected account credentials does not match an authorized connected account on the list of authorized connected accounts, transmitting the second set of connected account credentials to the second content provider server for authentication; and upon receiving confirmation from the second content provider server that the second set of connected account credentials permits the second application to receive the access to the content from the second content provider server, updating the list of authorized connected accounts with the second set of connected account credentials to define an additional authorized connected account.

4. The method of Claim 1, wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining whether the second application is on the user device with the first application.

5. The method of Claim 1, wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining the second application is on a second user device that is on a same network as the user device.

6. The method of Claim 1, wherein the first application and the second application include embedded modules to manage sign-on and access based on the token.

7. The method of Claim 1, wherein the authorizing the access to the content of the second content provider server to the second application further comprises instructing the first application to display a prompt requesting input from a user to approve or deny the requested access from the second application before authorizing the access to the content of the second content provider server to the second application.

8. The method of Claim 7, wherein the authorizing the access is performed upon receiving the input from the user approving the requested access from the second application.

9. The method of Claim 7, wherein the authorizing the access is not performed upon receiving the input from the user denying the requested access from the second application.

10. The method of Claim 1, wherein the authorizing the access to the content of the second content provider server to the second application further comprises instructing the first application to display a notification to a user that the second application will be authorized to access the content of the second content provider server after a set duration of time has lapsed without user intervention.

11. The method of Claim 1, wherein the token is stored on a secure storage of the user device, the secure storage being accessible to both the first application and the second application.

12. The method of Claim 1, wherein the authorizing the access to the content of the second content provider server to the second application further comprises in response to determining the token received from the second application is not the same token transmitted to the first application in response to the first sign-on request, instructing the first application to display a prompt requesting input from a user to approve the requested access from the second application before authorizing the access to the content of the second content provider server to the second application, and authorizing the access to the content of the second content provider server to the second application upon receiving input from the user approving of the requested access from the second application.

13. The method of Claim 1, wherein the first application is a first over-the-top application configured to stream and display the content from the first content provider server, and the second application is a second over-the-top application configured to stream and display the content from the second content provider server.

14. The method of Claim 1, wherein the first application is an operator application configured to authenticate received authentication data from other applications on the userdevice, and the second application is a first over-the-top application configured to stream and display the content from the first content provider server.

15. A non-transitory computer-readable medium encoded with computer-readable instructions that, when executed by a computer, causes the computer to perform a method, the method comprising: receiving, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmitting, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server; receiving, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorizing access to the content of the second content provider server to the second application.

16. The non-transitory computer-readable medium according to Claim 15, wherein the receiving the first sign-on request further comprises receiving a first set of connected account credentials, and the transmitting the token to the first application further comprises determining the first set of connected account credentials matches an authorized connected account on a list of authorized connected accounts before sending the token to the first application.

17. The non-transitory computer-readable medium according to Claim 16, wherein the receiving the token and the second sign-on request from the second application further comprises receiving a second set of connected account credentials, andthe authorizing the access to the content of the second content provider server to the second application further comprises upon determining the received second set of connected account credentials does not match an authorized connected account on the list of authorized connected accounts, transmitting the second set of connected account credentials to the second content provider server for authentication; and upon receiving confirmation from the second content provider server that the second set of connected account credentials permits the second application to receive the access to the content from the second content provider server, updating the list of authorized connected accounts with the second set of connected account credentials to define an additional authorized connected account.

18. The non-transitory computer-readable medium according to Claim 15, wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining whether the second application is on the user device with the first application.

19. The non-transitory computer-readable medium according to Claim 15, wherein the authorizing the access to the content of the second content provider server to the second application further comprises determining the second application is on a second user device that is on a same network as the user device.

20. An apparatus, comprising: processing circuitry configured to receive, from a first application on a user device, a first sign-on request for obtaining access to content from a first content provider server; transmit, to the first application, a token in response to receiving the first sign-on request, the token being accessible to the first application, the token providing access to the content on the first content provider server in response to the user device providing the token to the first content provider server;receive, from a second application, the token and a second sign-on request for obtaining access to content from a second content provider server, the token being received by the second application in response to transmitting a token request to the first application, the first application having determined the second application to be authorized to receive the token during the token request; and in response to determining the token received from the second application is a same token transmitted to the first application in response to the first sign-on request, authorize access to the content of the second content provider server to the second application.