Method and apparatus for providing federated service accounts

Background

Network service providers and device manufacturers are continually challenged to deliver value and convenience to consumers by, for example, providing a suite of compelling network services. Subscription network services traditionally involve authenticating users during a user sign-on process. However, network resources are wasted and user experience is diminished when a user is required to sign-on several times to participate in multiple services. Thus there is a move to allow a user to sign-on once and thereby gain access to several services from the same provider.

Federated identity, or the “federation” of identity, refers to technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains, e.g., by different providers. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. As part of this goal, service providers and device manufacturers also face significant technical challenges to ensuring that once a user is authenticated into multiple services via a federated identity, service account information (e.g., user profile information, billing information, payment information, etc.) can also be federated or coordinated across the services to provide a seamless user experience.

Some example embodiments

Therefore, there is a need for an approach for enabling a federation of service accounts for services that rely on federated identification and/or authentication of users (e.g., services participating in single sign-on processes).

According to one embodiment, a method comprises determining that a user has been authenticated for an access to at least one service using a federated identity. The federated identity is associated with the at least one service, at least one or more other services, or a combination thereof. The method also comprises determining federated account information associated with the user based, at least in part, on one or more user accounts associated with the federated identity, the at least one service, the at least one or more other services, or a combination thereof. The method further comprises determining one or more functions of the at least one service, the at least one or more other services, or a combination thereof to make available to the user based, at least in part, on the federated account information.

According to another embodiment, an apparatus comprising at least one processor, and at least one memory including computer program code for one or more computer programs, the at least one memory and the computer program code configured to, with the at least one processor, cause, at least in part, the apparatus to determine that a user has been authenticated for an access to at least one service using a federated identity. The federated identity is associated with the at least one service, at least one or more other services, or a combination thereof. The apparatus is also caused to determine federated account information associated with the user based, at least in part, on one or more user accounts associated with the federated identity, the at least one service, the at least one or more other services, or a combination thereof. The apparatus is further caused to determine one or more functions of the at least one service, the at least one or more other services, or a combination thereof to make available to the user based, at least in part, on the federated account information.

According to another embodiment, a computer-readable storage medium carrying one or more sequences of one or more instructions which, when executed by one or more processors, cause, at least in part, an apparatus to apparatus to determine that a user has been authenticated for an access to at least one service using a federated identity. The federated identity is associated with the at least one service, at least one or more other services, or a combination thereof. The apparatus is also caused to determine federated account information associated with the user based, at least in part, on one or more user accounts associated with the federated identity, the at least one service, the at least one or more other services, or a combination thereof. The apparatus is further caused to determine one or more functions of the at least one service, the at least one or more other services, or a combination thereof to make available to the user based, at least in part, on the federated account information.

According to another embodiment, an apparatus comprises means for determining that a user has been authenticated for an access to at least one service using a federated identity. The federated identity is associated with the at least one service, at least one or more other services, or a combination thereof. The apparatus also comprises means for determining federated account information associated with the user based, at least in part, on one or more user accounts associated with the federated identity, the at least one service, the at least one or more other services, or a combination thereof. The apparatus further comprises means for determining one or more functions of the at least one service, the at least one or more other services, or a combination thereof to make available to the user based, at least in part, on the federated account information.

In addition, for various example embodiments of the invention, the following is applicable: a method comprising facilitating a processing of and/or processing

data and/or

information and/or

at least one signal, the

data and/or

information and/or

at least one signal based, at least in part, on (including derived at least in part from) any one or any combination of methods (or processes) disclosed in this application as relevant to any embodiment of the invention.

For various example embodiments of the invention, the following is also applicable: a method comprising facilitating access to at least one interface configured to allow access to at least one service, the at least one service configured to perform any one or any combination of network or service provider methods (or processes) disclosed in this application.

For various example embodiments of the invention, the following is also applicable: a method comprising facilitating creating and/or facilitating modifying

at least one device user interface element and/or

at least one device user interface functionality, the

at least one device user interface element and/or

at least one device user interface functionality based, at least in part, on data and/or information resulting from one or any combination of methods or processes disclosed in this application as relevant to any embodiment of the invention, and/or at least one signal resulting from one or any combination of methods (or processes) disclosed in this application as relevant to any embodiment of the invention.

For various example embodiments of the invention, the following is also applicable: a method comprising creating and/or modifying

at least one device user interface element and/or

at least one device user interface functionality, the

at least one device user interface element and/or

at least one device user interface functionality based at least in part on data and/or information resulting from one or any combination of methods (or processes) disclosed in this application as relevant to any embodiment of the invention, and/or at least one signal resulting from one or any combination of methods (or processes) disclosed in this application as relevant to any embodiment of the invention.

In various example embodiments, the methods (or processes) can be accomplished on the service provider side or on the mobile device side or in any shared way between service provider and mobile device with actions being performed on both sides.

For various example embodiments, the following is applicable: An apparatus comprising means for performing a method of any of the claims.

Still other aspects, features, and advantages of the invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the invention. The invention is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

Brief description of the drawings

The embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings:

FIG. 1 is a diagram of a system capable of providing federated service accounts, according to one embodiment;

FIG. 2A is a diagram of federating service accounts across multiple services, according to one embodiment;

FIG. 2B is a diagram comparing a federated service account process to a standard sign-on process, according to one embodiment;

FIG. 3 is a time sequence diagram that illustrates a sequence of messages and processes for federation of service accounts, according to various embodiments;

FIG. 4 is a flowchart of a process for providing federated service accounts, according to one embodiment;

FIG. 5 is a flowchart of a process for maintaining user accounts after dissolution of a identity federation among multiple services, according to one embodiment;

FIG. 6A is a diagram of a device provisioning request message, according to one embodiment;

FIG. 6B is a diagram of a device provisioning response message, according to one embodiment;

FIG. 6C is a diagram of an identity authentication request message for a network resource, according to one embodiment;

FIG. 7A is a diagram of an authentication user interface (UI) message, according to one embodiment;

FIG. 7B is a diagram of a user credentials message, according to one embodiment;

FIG. 7C is a diagram of an identity authentication result message, according to one embodiment;

FIG. 8 is a flowchart of a process for an identifier (ID) federation gateway, according to one embodiment;

FIG. 9 is a time sequence diagram that illustrates a sequence of messages and processes for an ID federation gateway, according to various embodiments;

FIG. 10 is a diagram of hardware that can be used to implement an embodiment of the invention;

FIG. 11 is a diagram of a chip set that can be used to implement an embodiment of the invention; and

FIG. 12 is a diagram of a mobile terminal (e.g., handset) that can be used to implement an embodiment of the invention.

Description of some embodiments

Examples of a method, apparatus, and computer program for providing federated service accounts are disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.

As used herein, the term network resource refers to any service or data structure or communication link available through connection to a network. A single sign-on (SSO) process refers to any process of one or more providers, which enables a user, during one session connected to the network, to access a plurality of network resources from that providers without redundant entry by the user of user identification information. In one embodiment, a provider is often identified by a single network domain name in the uniform resource identification (URI) naming system, as used for example with a uniform resource locator (URL) naming system. An example single sign-on process is the single sign-on processes for the OVI™ system of the NOKIA CORPORATION™ of Espoo, Finland. An access provider is a network service provider that grants access for user equipment (e.g., UE 101 , described below) to access a network (e.g., communication network 105 , described below). As used herein, an identification process (e.g., identifying) includes determining an identity, or authenticating a particular user as having that identity, or determining that the particular user is authorized to access one or more services, or some combination.

Although various embodiments are described with respect to involving, in the SSO of a network resource provider, identification by a different network access provider, it is contemplated that the approach described herein may be used with other sets of two or more different providers and any federated identity services with legacy authentication processes, whether SSO processes or not.

FIG. 1 is a diagram of a system 100 capable of providing federated service accounts, according to one embodiment. The system 100 includes a communication network 105 , user equipment 101 , multiple network resources, including services 110 a through 110 n (collectively referenced hereinafter as network services 110 ) available through an internal authentication service 120 of the resource provider. Also included is an access provider identification service 130 as an example of federated identity services. Traditionally, for a user of UE 101 to be identified by the federated identity services, each component of the internal authentication service 120 , corresponding to each service 110 a through 110 n , would be modified to interact with the federated identity services to obtain the user credentials. This is an error-prone process affecting many different areas of memory, and consuming processing resources as each component is modified, compiled and stored in executable form. Each update of the federated identity services would similarly be propagated to all the components of internal authentication service 120 , consuming even more processing resources. If replicated on multiple hosts for safety, the consumption of processing resources and bandwidth resources are even greater. Similarly, client processes on each of many thousands of user equipment, such as cell phones, would be modified to interact with the federated identity services. These modifications consume valuable processing power, memory, battery life, and communication bandwidth that is especially scarce on mobile terminals.

Moreover, as discussed briefly above, once a user is authenticated to access multiple services via a federated identity, service providers face additional challenges to providing a seamless user experience across the corresponding multiple services. In other words, although a user may use a single federated identity to reduce the burden of having to sign into each separate service, the federated identity process generally does not provide for continuity of experience across the multiple services or multiple sessions of the services. For example, account information (e.g., billing information, payment information, etc.) established by the user in one service may not be available to the user when use another service even when the user has used a federated identity to access the other service. In some cases, sharing of account information may be further restricted by privacy policies, security policies, regulations, business standards (e.g., Payment Card Industry (PCI) data security standards, etc.), and the like.

To address these problems, the system 100 introduces the capability to provide federated of service accounts so that a user's service profile, account information, etc. established in one service can be used, transferred, or otherwise accessed by another service that shares a common federated identity for the user. In one embodiment, the service account information shared in federated service accounts include, at least in part, billing information, payment information, invoicing information, and/or other information related to potentially sensitive user information. In this way, when a user accesses a service by authenticating through another service (e.g., through a federated identity), the user can make a purchase in one service (or otherwise access a function involving payment or billing) using payment information already established in an account established in the other service, and vice-versa.

In one embodiment, the system 100 provides federated service accounts (e.g., service accounts or account information that can be shared by a user among different services) through the creation of shadow accounts associated with each service. For example, when a user authenticates using a federated identity to multiple services and accesses a particular one of the services, the system 100 can create a shadow account in that particular service to capture user session information and provide continuity of user interaction across multiple sessions of the service. In one embodiment, the shadow account can be linked to the federated identity or an authentication token associated with the federated identity without requesting additional information from the user.

In some embodiments, the shadow account includes a subset of information available from federated account information or other service accounts. For example, even though federated account information or information in other service accounts may include complete contact information, billing information, etc., the shadow account may be created using only a minimal set of fields of data taken from the account information (e.g., to comply with privacy policies, security policies, business policies, regulations, etc.). For instance, even though complete contact information (e.g., name, address, phone number, etc.) may be available, the shadow account may be created to include only the user's name. Similarly, in one embodiment, a shadow account may not include billing account information. Accordingly, they system 100 and/or the applicable service may provide for differentiated access to service content and/or functions when compared to full accounts established directly through the service. For example, a shadow account may enable a user to browse a service's catalog of products, but a full account is needed to make a purchase from the catalog.

In another embodiment, the system 100 may provide for “just-in-time” sharing of account information. More specifically, the system 100 may share account information among federated service accounts only when a user or the service requires the information when accessing a function or content provided by a service. By way of example, billing account information may not be shared from one federated service account to another until a user actually attempts or makes a request to purchase an item. In another example, contact information (e.g., a home address) for a user may not be shared with a federated service account until the contact information is needed by the service.

In one embodiment, the system 100 can recommend to the user to convert a shadow account to a full account. For example, if the user attempts to access a function, content, etc. of a service that requires a full account, the system 100 can recommend that the user create the new account. In one embodiment, creating a new account includes, at least in part, a request to the user to provide authentication credentials for the service that is different from the federated identity. In this way, the user can then access the service via either the federated identity (e.g., an authentication token associated with the federated identity) or the authentication credentials provided to establish the full account.

In another embodiment, when a federated identity is deleted or otherwise dissolved, the system 100 can continue to enable authentication to the individual services previously served by the federated identity via the respective authentication credentials used to create the full account. In some embodiments, on receiving a request to dissolve a sharing of the federated identity among multiple services, the system 100 can request that the user convert to full accounts for the respective services before the dissolution of the federated identity. Accordingly, the user will continue to have access to the services and maintain service information even after the services no longer shared or recognize the user's federated identity.

As shown in FIG. 1 , the system 100 includes an ID federation gateway 140 for controlling the interactions between the legacy authentication service and federated identity services, such as the access provider identification service 130 , as well as interactions between a legacy authentication client 122 (such as a SSO device enabler (DE) process) and the service federated identity services. Thus the gateway 140 is an example means of achieving the advantage of reducing network resources to utilize federated identity services with legacy authentication service, as well as for other providers and their internal authentication services, if any (not shown). Internal authentication service 120 is a modified process that includes the legacy authentication service and the ID federation gateway 140 .

In one embodiment, the ID federation gateway 140 interacts with the federated account platform 115 to manage, synchronize, and/or otherwise coordinate federated service accounts and account information among the services 110 a - 110 n . The federated account platform 115 , in one embodiment, includes one or more components for managing federated service accounts as described in the various embodiments discussed herein. It is also contemplated that all or a portion of the functions of the federated account platform 115 , the ID federation gateway 140 , or a combination thereof may be performed by components of equivalent functionality or reside in other components of the system 100 .

In one embodiment, the system 100 comprises user equipment (UE) 101 having connectivity to the federated account platform 115 , internal authentication service 120 and services 110 a through 110 n and access provider identification service 130 via a communication network 105 . By way of example, the communication network 105 of system 100 includes one or more networks such as a data network (not shown), a wireless network (not shown), a telephony network (not shown), or any combination thereof. It is contemplated that the data network may be any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), a public data network (e.g., the Internet), short range wireless network, or any other suitable packet-switched network, such as a commercially owned, proprietary packet-switched network, e.g., a proprietary cable or fiber-optic network, and the like, or any combination thereof. In addition, the wireless network may be, for example, a cellular network and may employ various technologies including enhanced data rates for global evolution (EDGE), general packet radio service (GPRS), global system for mobile communications (GSM), Internet protocol multimedia subsystem (IMS), universal mobile telecommunications system (UMTS), etc., as well as any other suitable wireless medium, e.g., worldwide interoperability for microwave access (WiMAX), Long Term Evolution (LTE) networks, code division multiple access (CDMA), wideband code division multiple access (WCDMA), wireless fidelity (WiFi), wireless LAN (WLAN), Bluetooth®, Internet Protocol (IP) data casting, satellite, mobile ad-hoc network (MANET), and the like, or any combination thereof.

The UE 101 is any type of mobile terminal, fixed terminal, or portable terminal including a mobile handset, station, unit, device, multimedia computer, multimedia tablet, Internet node, communicator, desktop computer, laptop computer, Personal Digital Assistants (PDAs), audio/video player, digital camera/camcorder, positioning device, television receiver, radio broadcast receiver, electronic book device, game device, or any combination thereof. It is also contemplated that the UE 101 can support any type of interface to the user (such as “wearable” circuitry, etc.).

By way of example, the UE 101 , federated account platform 115 , services 110 , internal authentication service 120 and access provider identification service 130 communicate with each other and other components of the communication network 105 using well known, new or still developing protocols. In this context, a protocol includes a set of rules defining how the network nodes within the communication network 105 interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model.

Communications between the network nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises

header information associated with a particular protocol, and

payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes

trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The higher layer protocol is said to be encapsulated in the lower layer protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, and various application headers (layer 5, layer 6 and layer 7) as defined by the OSI Reference Model.

The client-server model of computer process interaction is widely known and used. According to the client-server model, a client process sends a message including a request to a server process, and the server process responds by providing a service. The server process may also return a message with a response to the client process. Often the client process and server process execute on different computer devices, called hosts, and communicate via a network using one or more protocols for network communications. The term “server” is conventionally used to refer to the process that provides the service, or the host computer on which the process operates. Similarly, the term “client” is conventionally used to refer to the process that makes the request, or the host computer on which the process operates. As used herein, the terms “client” and “server” refer to the processes, rather than the host computers, unless otherwise clear from the context. In addition, the process performed by a server can be broken up to run as multiple processes on multiple hosts (sometimes called tiers) for reasons that include reliability, scalability, and redundancy, among others. A well known client process available on most nodes connected to a communications network is a World Wide Web client (called a “web browser,” or simply “browser”) that interacts through messages formatted according to the hypertext transfer protocol (HTTP) with any of a large number of servers called World Wide Web servers that provide web pages described by the hypertext markup language (HTML).

In the illustrated embodiment, UE 101 includes a client process 114 for at least one of the network services 110 , a web browser 107 and an authentication client module 122 .

The authentication client module 122 may be implemented as a chip set as shown in FIG. 7 and described below, with or without one or more computer program instructions. In the legacy authentication system, when the browser 107 or client 114 attempts to send a message requesting a service 110 of the resource provider, the authentication client module 122 intercepts the message and directs the request to the legacy authentication service. The legacy authentication service determines whether a user of the UE 101 is already signed-on during the current session with network 105 . If not, a user interface (UI) is sent to the authentication client module 122 to present to the user to prompt for user inputs employed to identify the user. The UI may be included in any manner known in the art, such as a script in an HTML document delivered via HTTP. Based on those inputs, communicated from the authentication client module 122 to the legacy authentication service, the user is either accepted or rejected by the legacy authentication service. A rejection is communicated to the user through the authentication client module 122 . If accepted, an authentication token is passed to the authentication client module 122 for use in further requests for other services 110 during the current session. Subsequent messages from client 114 or browser 107 , requesting a network service 110 of the provider, are intercepted by the authentication client module 122 and sent to the legacy authentication service with the authentication token. If the authentication token is not out of date, the request is forwarded to the correct service 110 with whatever credentials required by the service 110 to perform the requested service. If out of date, the UI is sent by the internal authentication service 120 to the authentication client module 122 to present to the user, as described above.

By way of example, the federated account platform 115 and the ID federation gateway 140 include one or more components for providing an ID federation gateway and federated service accounts. The platform 115 and the gateway 140 may be implemented as a chip set as shown in FIG. 7 described below, with or without one or more computer program instructions. It is contemplated that the functions of these components may be combined in one or more components or performed by other components of equivalent functionality on one or more hosts connected to network 105 . The federated account platform 115 and ID federation gateway 140 abstract third party federated identity services for both services 110 (such as OVI Services) and legacy authentication service (such as OVI SSO).

FIG. 2A is a diagram of federating service accounts across multiple services, according to one embodiment. As shown, users 201 (e.g., merchants, consumers, etc.) can access Service A 203 a and Service B 203 b , respectively, via a Service A portal 205 a and a service B portal 205 b through a federated identity process (e.g., as described below with respect to FIGS. 6A to 9 ).

Under one use case, the Service A 203 a and the Service B 203 b provide business services to users 201 who are merchants. More specifically, the principal actors in this use case include:

a merchant user 201 ;

a self-service interface (SSI) portal, e.g., Service A portal 205 a or Service B portal 205 b ; and

a federated account platform 115 that enables federated single-sign-on access across partner services or portals. However, it is contemplated that the various embodiments are applicable to any type of service (e.g., consumer services) and/or users 201 (e.g., consumers).

As preconditions under this example, the merchant user 201 is registered with the Service A 203 a , and has agreed to terms and conditions including SSO-based federation to partner sites (e.g., Service A 203 a in partnership with Service B 203 b ), and account data sharing (e.g., federated service accounts) among the partners to enable a better user experience. The merchant user 201 has an active Service A account 211 a and is logged-in with a valid SSO token (e.g., via the authentication server 215 a and ID federation gateway 140 ).

While browsing within Service A 203 a , the merchant user 201 discovers product information associated with Service B 203 b . The merchant user 201 clicks a corresponding UI link 207 a (e.g., a link, a widget, etc.) for the production information which results in serving of a landing page on the partner portal (e.g., Service B portal 205 b ), including seamless navigation. As a result of the clicking the link to the product information associated with Service B 203 b , the federated account platform 111 through a federation APIs 209 a processes the SSO token to return a federation SSO token (e.g., in OAuth format) to the landing page. In this example, the federation SSO token is scoped for the target partner portal (e.g., Service B portal 205 b ).

The Service B portal 205 b then validates the federation SSO token, and creates a shadow account (e.g., federated account 213 b ) for the user in Service B 203 b . As result, the merchant user 201 is able to access the functions, content, services, etc. of Service B 203 b.

In another use case, the merchant user 201 wants to purchase the products linked to Service B 203 b . This case assumes the same conditions as described above, and the merchant user 201 has completed clicking and viewing the resulting product information in Service B 203 b . After reviewing the information, the merchant user 201 decides to buy the product offered by Service B 203 b . In this case, as part of creating the federated account 213 b for the Service B 203 b , billing/payment account information is included in the federated account. In addition, the merchant 201 may also be asked to register and/or validate billing account or other identification information to transfer or create the billing/payment account information.

In another embodiment, on clicking a link to purchase the product, the service B account 211 b may request the billing/payment account information for the user from the service A account 211 a . The request may include the federation SSO token for authentication and/or validation along with the request to share the billing/payment information. On receipt of the billing/account information from Service A account 211 a , the Service B account 211 b may include the billing/payment information in the federated account 213 b or create a separate billing account under Service B 203 b for the user. In either case, Service B 203 b uses the billing/payment information to complete the transaction and deliver the product to the merchant user 201 . With this process, the billing/payment information represents federated account information that can be obtained without requiring the user to reenter the payment information in Service B 203 b when the user has already provided the information to Service A 203 a , thereby reducing data entry burden on the merchant user 201 and improving user experience.

In some embodiments, Service A 203 a and Service B 203 b may engage in further information sharing or federation of service accounts post transactions depending, e.g., on privacy policies, security policies, business standards, regulations, etc. For example, both Service A 203 a and Service B 203 b can bill the merchant user 201 for their respective products using federated service account information. Service A 203 a and Service B 203 b then can further enter into revenue sharing agreements, transaction history sharing agreements, etc. that can be enforced and/or facilitated by the federated account platform 115 .

In other embodiments, the federated account platform 113 can share federated service account information under different schemes. For example, Service A 203 a and Service B 203 b may enact a “double billing account input.” Under this scheme, both services own the user 201 (e.g., maintain relationships with the user 201 ). Accordingly, both service portals can request the merchant user 201 to enter this account information (e.g., billing account information), and there will be no sharing of billing or payment information between the two services.

Under another scheme, Service A 203 a and Service B 203 b may enact a “single billing account input.” For example, both services own the user 201 by having separate user accounts under each service, but share billing account information. In a variation of this scheme, each respective service may independently validate the shared billing/payment account information. The validation may include, for instance, requesting CVV2 input for credit card billing information.

Under yet another scheme, Service A 203 a and Service B 203 b may enact a “single billing account input, with single validation.” In this case, either one or both of the services can own the user 201 . The services then share or create a common billing account for the merchant user 201 in a centralized payment gateway.

Under another scheme, Service A 203 a and Service B 203 b may enact a “single billing account input, with single ownership.” In this case, either one or both of the services can own the user 201 . The owning service can then act as the payment gateway for the other service.

FIG. 2B is a diagram comparing a federated service account process to a standard sign-on process, according to one embodiment. As shown, the process 241 illustrates a simplified, seamless sign-on to partner services (e.g., Service A portal 205 a and Service B portal 205 b ). In the example of process 241 , a federated sharing of payment account data is performed such that an invoice is still generated by partner portal (e.g., Service B portal 205 b ) for any service or promotions the merchant user 201 ends up buying from the partner portal. In one embodiment, the purchase is completed by a user 201 that first signs into the Service A portal 205 a via a federated identity shared with Service B portal 205 b . As a result, the user 201 need not sign in separately into the Service B portal 205 b because the system 100 automatically shares the payment information associated with the user 201 from the Service A portal 205 a to the Service B portal 205 b.

In contrast, as shown in the process 243 , a standard or traditional sign-on process typically asks the user to first sign into Service A portal 205 a . When the user 201 moves from Service A portal 205 a to Service B portal 205 b , the user 201 is likely to be asked for separate authentication credentials and/or payment information when operating in the Service B portal 205 b . In this case, no service account information is shared, thereby requiring the user to reenter information (e.g., credentials or payment information) and reducing the user experience.

FIG. 3 is a time sequence diagram that illustrates a sequence of messages and processes for federation of service accounts, according to various embodiments. A network process on the network is represented by a thin vertical box, labeled at the top. A message passed from one process to another is represented by horizontal arrows. A step performed by a process is indicated by a box or looping arrow overlapping the process at a time sequence indicated by the vertical position of the box or looping arrow. The processes represented in FIG. 3 are a Service A portal 205 a , a Service A UI link 207 a , a Service A authentication server 215 a , a Service B authentication server 215 b , and a service B API 209 b.

The description continues in the full USPTO document.