Patent Description:
For a long time, services have existed which provided a one-call solution to the problem of a lost/stolen wallet. These services ensure that all your credit cards are blocked, replacements are ordered, and your financial losses from the theft are mitigated as much as possible.

Today, our digital lives require the same solution. In the event of someone stealing your digital identity, perhaps by obtaining one of your online passwords, would it not be valuable to have a service which automatically changed or disabled all your credentials for your online life, protecting your social networks, email access, banking passwords, health information etc.?.

Today we might panic due to loss of a wallet, a theft in the house, or a robbery. While panicking is a natural reaction, what we aspire to today is a sophisticated solution, that could lock or block access to all our assets (physical or digital) simply and easily, irrespective of the location someone is in.

Such a service could be used for example, a) after a retail breach to change all your online passwords; b) after a mobile device is stolen that was not secured with a pin; c) by relations or legal representatives post death, to block or secure future access to your digital life;
d) by a trusted third party after an aggressive act by an oppressive regime, to prevent government access to data without legal process; or e) on confiscation of a device to prevent self-incrimination.

<CIT> describes a system and method for selective erasure, encryption and or copying of data on a remote device if the remote device has been compromised or the level of authorization of a roaming user in charge of the remote device has been modified.

<CIT> relates to an information processing apparatus that includes a transfer unit that accesses a mail server in response to a mail browsing request from a user terminal, and reads mail data in the mail server from the mail server so as to be transferred to the user terminal, a transmission unit that transmits a notification mail for notifying the user terminal of a predetermined event to the mail server, and a deletion unit that accesses the mail server in response to a mail deletion request from the user terminal, and deletes mail data in the mail server, wherein deletion of the notification mail by the deletion unit is restricted.

<CIT> describes security systems for protecting assets, including password-based security systems that can provide different levels of access responsive to entry of a primary or secondary password. In some versions, user-configurable security rules can provide customized responses to entry of primary or secondary passwords, including feigned or limited access, security alerts, etc. Passwords comprising overt and covert components can be used to provide enhanced security and improved user control over system response. Improved security systems involving transactions between multiple parties are also considered, with options for user-customized security rules including primary and secondary passwords, and reverse challenge and response methods. Systems for Limited Use Credentials are also described to reduce the risk of identity theft.

<CIT> describes systems, methods and computer program products for processing payments for a proxy card. Embodiments of the system include a processor, and a memory in communication with the processor. The memory may be configured to store processing instructions for directing the processor to receive a request for authorization of a payment. In various embodiments, the request is triggered at a merchant server, by the use of a proxy card of the customer. The processor attempts to identify at least one desired payment mode for making the payment, from among payment mode(s) associated with the proxy card. The processor first selects the payment modes based at least in part on one or more selection criteria, such as predefined customer goals, and then the processor performs an authorization check to identify the desired payment modes. Subsequently, the processor authorizes the payment if at least one desired payment mode is identified.

The existing blocking and asset control mechanisms require users to memorize every service or asset means, such as all the cards, the bank or other organization to which they belong, find their own protocol and call center contacts, and then explain the loss. That procedure is tiresome and time consuming for anyone who is already threatened with risk to one or more of their assets, which can bring about mental agony and possibly even physical injury.

In a first aspect, there is provided a gateway system as defined in appended claim <NUM>. In a second aspect, there is provided a storage device as defined in appended claim <NUM>. In a third aspect, there is provided a method of controlling access to user-owned digital assets as defined in appended claim <NUM>.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. lt will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to "one embodiment" or to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to "one embodiment" or "an embodiment" should not be understood as necessarily all referring to the same embodiment.

As used herein, the term "a computer system" can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.

As described in more detail below, an "SOS" or "Panic Button" service secures a person's digital life, providing a single aggregation point between the person and numerous independent online services, allowing actions such as change password, secure account, delete data, etc., to be performed across said numerous services by a single trigger event such as a digital compromise.

In addition, an "SOS Gateway" described in more detail below provides an online service that when triggered causes protective measures to be put into place to secure a person's digital life. Such a service can be triggered manually by the owner of the digital information (post-theft, for example), by the loss of communication to a device (mobile phone, wearable, etc.), by a nominated third party (such as a parent, spouse, or legal representative), or perhaps at a timed event.

The services described below can support measures such as "change password," "disable account," "delete account," etc..

In one embodiment, the service architecture comprises a web portal, coupled with unique "brokers" that understand how to interact with a particular service, for example, FaceBook®, Google+™, Gmail®, Hotmail®, Dropbox®, etc. (FACEBOOK is a registered trademark of Facebook, Inc. ; GOOGLE+ is a trademark of Google, Inc. ; GMAII, is a registered trademark of Google, Inc. ; HOTMAII, is a registered trademark of Microsoft Corporation; DROPBOX is a registered trademark of Dropbox, Inc.

In addition an Application Programming Interface (API) is proposed to allow third party applications to interact with this service architecture, for example to allow a wearable manufacturer to trigger the service if a smartwatch is removed from a user's wrist.

Known solutions to restrict access to resources or accounts are standalone solutions that are neither unified nor integrated to any common authority. The disclosed system proposes an integrated and automated approach to unify operation of block or restrict actions on a number of assets without compromising authentication information. In addition, the system described below provides a time limited block action, cutting across different asset categories, which greatly enhances the user's flexibility to take SOS decisions without any manual intervention of the service providers and limits the dependence on a superficial manual procedure or protocol.

The Service providers can be financial institutions, telecom operators, enterprises and corporates, web-services providers (Email, cloud storage), webmasters, social account providers, etc. The term includes all those entities that provide online or offline assets to the public at large. On one hand, the protection of those assets is a responsibility of the end-user, but providing a safe environment is a responsibility of the SP. Embodiments of SPs typically:.

A number of "broker" engines are provided in various embodiments. The broker engines each know how to interface with a single SP system, and expose a common API to the SOS gateway service. The brokers collectively normalize the individual functions of all the SPs. For example, the act of changing a password within FaceBook, and within Google+ require completely different APIs. In embodiments described below, each service would be interact with a unique broker. A user can then can change the password of both services simply by requesting that action from both brokers.

The public at large, i.e., consumers and the ultimate owners of different assets provided by the SP's. Users typically can:.

In some embodiments, users may have an option to use either a unique short key for each asset or a common key for all the assets.

Typically a user may interact with the CSG using one or more of:.

These techniques are illustrative and by way of example only, and other user interaction types can be provided.

The CSG provides a gateway between users and SP, providing users a common interface for instructing actions related to their digital life. The CSG may then interact with the SPs, possibly through brokers customized for that SP, to effect the user's instructions. As described in more detail below, the CSG may also take actions automatically based on prior user instructions upon the occurrence of a triggering event, including the expiration of a time period. Functions of the CSG include:.

<FIG> is a block diagram <NUM> illustrating a user <NUM> interacting with a CSG <NUM> to control user <NUM>'s digital assets according to one embodiment. Diagram <NUM> assumes the user has already registered with the CSG <NUM>, which knows how to interact with the SP <NUM> to request the SP <NUM> to perform the desired action. In this example, the user <NUM> sends a notification request <NUM> to the CSG <NUM>, identifying the SP <NUM> and the desired action <NUM>, such as block, delete, etc. The CSG <NUM> authenticates the user <NUM>, then requests the SP <NUM> to perform the desired action using request notification <NUM>. Upon receiving the request <NUM>, the SP <NUM> may then perform the desired action <NUM>, using whatever mechanism <NUM> the SP has defined for performing the desired action <NUM>. Neither the user <NUM> nor the CSG <NUM> need to be aware of mechanism <NUM>. The user <NUM> need not be aware of the way in which the CSG <NUM> communicates with the SP <NUM>.

If all SPs <NUM> employed a standard mechanism for the CSG <NUM> to send the request <NUM> to the SP <NUM>, including all necessary authentication information, a single CSG <NUM> might suffice. However, because SPs <NUM> may employ different authentication and request mechanisms, typically using an SP-specific API, embodiments may employ a brokered technique as illustrated in <FIG>.

As illustrated in <FIG>, CSG <NUM> hosts or includes a CSP <NUM> that performs user registration and deregistration functions as well as user configuration functions. In some embodiments, the CSP <NUM> may be implemented remotely to the CSG <NUM> if desired.

In <FIG>, the user continues to communicate with the CSG <NUM> and the SP <NUM> performs the requested action <NUM> as in <FIG>. However, in such an embodiment, the CSG <NUM> may now communicate with a broker <NUM> using a request protocol <NUM> instead of directly with the SP <NUM>. The broker <NUM> is configured to use a common API or communication mechanism with the CSG <NUM> and may be configured specifically for communicating with the SP <NUM>, providing the request <NUM> in the way required by the SP <NUM>. Although only one broker <NUM> and SP <NUM> is illustrated in <FIG>, the CSG <NUM> may communicate with a plurality of SPs <NUM> using a plurality of brokers <NUM>, with each broker <NUM> configured to communicate with the corresponding SP <NUM>. In some embodiments, where multiple SPs <NUM> use a common API or other communication technique, a single broker <NUM> may communicate with multiple SPs <NUM>. In some embodiments, a broker <NUM> may be configured with multiple communication techniques, allowing the broker <NUM> to communicate with a plurality of SPs <NUM> using different communication techniques.

Although only a single CSG <NUM> is illustrated in <FIG>, embodiments may employ a plurality of CSGs <NUM> using load balancing or other load sharing and redundancy techniques to provide a redundant and high performance system of CSG <NUM>. However, such multiple CSG embodiments would typically be invisible to the user <NUM>, who would see the CSG system as being a single CSG <NUM>. Similarly, embodiments may employ a plurality of brokers <NUM> that communicate with SP <NUM> for load balancing or other reasons to provide a reliable system for communicating between the CSG <NUM> and the SPs <NUM>.

<FIG> illustrate various user configuration functionality according to various embodiments. <FIG> illustrates configuring actions that a user may configure, while <FIG> illustrates configuring a way for the user to notify the CSG <NUM> to take a desired action.

In one embodiment, illustrated in <FIG>, SPs <NUM> may be categorized or classified into groups, and actions be associated with those groups. For example, in <FIG>, categories 310A (Social Networking) and 310B (Banking) are defined. These categories are illustrative and by way of example only, and other categories or classifications may be implemented. In category 310A, various social network sites that the CSG <NUM> is capable of interfacing with are listed, such as Facebook (315A), Twitter (315B), and LinkedIn (315C). These social network sites are illustrative and by way of example only, and other social network sites could be listed under category 315A. Similarly, under the banking category 310B, several credit card entities are listed, in this example Bank of America credit card (317A), Bank of America debit card (317B), and American Express credit card (317C).

A group action may be configured by the CSP <NUM>. In <FIG>, social networking entities 310A have an associated action 320A, allowing the user to block access to the listed social networking sites. In this example, a full block is configured to last for <NUM> day after notification by the user <NUM>. The interval can be configured by the user as desired. The banking group entry could be the same as the social networking group entry, but in this example is configured as a partial block for <NUM> week.

Different kinds of partial blocks may be configured in various embodiments. For example, some embodiments may allow blocking any attempt to debit an account, such as by attempting to make a charge on a credit card or cash a check against a banking account, while continuing to allow deposits to the account, such as accepting a payment of a prior credit card bill.

As illustrated in <FIG>, the action taken is defined as lasting for a configured time. Some embodiments may allow defining an action that lasts indefinitely, either until a reversal action is requested, or until some other predefined trigger event occurs. For example, a CSP <NUM> may allow a user <NUM> to block access to a digital asset until some further contact with the user <NUM>, such as the user <NUM> personally visiting an establishment of the SP <NUM> or the user <NUM> responding correctly to a communication from the SP <NUM> or a related system.

The configuration functionality of <FIG> is defined at a group level. Various embodiments may also define default settings for the user <NUM> that can be applied to any group or entity for which no overriding group or single entity configuration is available, using similar configuration interfaces as used for the group configuration. Similarly, embodiments may allow the user <NUM> to specify a custom configuration for an individual entity that is different from the group setting for that category of entities. In such an embodiment, the group configuration would override the user default configuration, and the single entity configuration would override the group and default configurations.

Although illustrated in <FIG> as a "block level," other actions may be defined for the user <NUM>. These actions may include deleting the digital asset or account, changing a password or other authentication information, or requesting the SP <NUM> to stop communicating with the user <NUM>. These actions are illustrative and by way of example only, and any type of action that the SP <NUM> can offer may be made configurable by the user <NUM> in the CSP <NUM>.

In some embodiments, the CSG <NUM> may also accept ad hoc requests, in which the user <NUM> specifies an action to be taken in the notification to the CSG <NUM>. This action may be the same as or different from any action preconfigured by the user <NUM>. In addition, the CSP <NUM> may define default actions, either for the user <NUM>, a category or group of SPs <NUM>, or a specific SP <NUM>, so that a user may be able to skip configuration if the default actions defined by the CSP <NUM> are acceptable.

<FIG> is a block diagram <NUM> illustrating functionality for the user to define ways to provide notifications to the CSG <NUM>- to cause either a predefined or ad hoc action to be taken by the SP <NUM>. The CSP <NUM> in this example may list a plurality of possible notification mechanisms <NUM>. In one embodiment, the list includes Short Messaging Service (SMS) text messages (<NUM>), an email message (<NUM>), a wearable device (<NUM>), web authentication with a one-time password (OTP) (<NUM>), a mobile app (<NUM>), and an IVRS (<NUM>). These notification types are illustrative and by way of example only, and other notification types may be implemented and accepted. In one embodiment, a user may define multiple acceptable notification mechanisms, and may prioritize those mechanisms as configured by the user. Similarly, embodiments may provide for the CSG to notify the user <NUM> when an action has been taken, and a similar configuration mechanism may provide for configuring the way in which the CSG <NUM> should send those notifications. The user <NUM> may configure the CSG to send only certain desired types of notifications. Some embodiments provide for the CSG <NUM> to send notifications to the user <NUM> in multiple forms. In such an embodiment, a priority order may be configured, telling the CSG <NUM> to send notifications in the priority order.

<FIG> is a block diagram illustrating registration of a CSG <NUM> with an SP <NUM>. In embodiments using brokers, such as in <FIG>, the broker <NUM> may perform some or all of the registration activities as an intermediary for the CSG <NUM>. The SP <NUM> may register in communication <NUM> with the CSG <NUM> using any desired communication protocol. In some embodiments, the CSG <NUM> may de-register the SP <NUM> at any time, such as when an SP no longer is trustworthy or fails to perform appropriately in interacting with the CSG <NUM>.

The registration communication <NUM> may also include information about what types of resources are available at the SP <NUM> and what types of valid actions are possible for the CSG <NUM> to request on behalf of a user <NUM>. Other information may be included in the registration communication <NUM>. Although shown as transmitting information from the SP <NUM> to the CSG <NUM> in <FIG>, embodiments have employ two-way communication in one or more steps to complete the registration of the SP <NUM> with the CSG <NUM>.

In communication <NUM>, the CSG <NUM> may authenticate itself to the SP <NUM> using any desired form of authentication. In addition, the CSG <NUM> may perform authentication of the user <NUM>, then communicate acceptance of that authentication to the SP <NUM>, avoiding the need for the user <NUM> to authenticate with the SP <NUM> directly. Any desired authentication technique may be used, typically involving an API defined by the SP <NUM> for trusted authentication by a third party. In embodiments where brokers <NUM> act as intermediaries between the CSG <NUM> and the SPs <NUM>, authentication may performed on behalf of the user <NUM> with the SP <NUM> by the broker <NUM>. For security reasons, all communication between the SP <NUM>, the CSG <NUM>, and any broker <NUM> is preferably cryptographically secured.

From time to time, the CSG <NUM> and the SP <NUM> may synchronize the information that they maintain in communication <NUM>. For example, the SP <NUM> may notify the CSG <NUM> that the user has added or deleted accounts with the SP <NUM>, allowing the CSG to update its enrollment information. Similarly, the CSG <NUM> may notify the SP <NUM> that the user <NUM> has enrolled an SP <NUM> account with the CSG <NUM>. An SP <NUM> may use this mechanism to indicate that the CSG <NUM> is (or is not) allowed to issue commands on behalf of the user <NUM>. Some SPs <NUM> may allow all their services to be used via the CSG <NUM>; other SPs <NUM> may allow access. only to services with lower security concerns, but prohibit use of the CSG <NUM> for control of access to higher security services.

Although in some scenarios, users <NUM> may manually trigger the CSG <NUM> to take necessary actions, such as after the theft of a smartphone or other device, automatic triggering actions may be supported in some embodiments. For example, a dormancy trigger may require the user <NUM> to take a certain action within a predefined time period; otherwise the dormancy event is triggered, causing the CSG <NUM> to instruct one or more of the SPs <NUM> to take an action. In another example, loss of communication with a mobile or wearable device may automatically trigger the CSG <NUM> to take an action. In another example, a user <NUM> may define one or more third parties to serve as a proxy for the user <NUM>. The proxy can then take actions on behalf of the user <NUM> should the user <NUM> be unavailable, incapacitated, or die. In some embodiments, a plurality of third parties may be defined, with some subplurality of the plurality of third parties required to agree that a trigger event (such as death) has occurred before the triggered action may be performed, such as giving access to digital assets to one or more of the plurality of third parties. This is a current problem, because upon the death of an account holder, gaining access to digital assets of the account holder can be extremely difficult.

Any action supported by the SP <NUM> may be triggered in embodiments of such a system. Actions may be configured in the CSG <NUM> that may affect digital assets associated with a single SP <NUM> or with multiple SPs <NUM>. For example, a user <NUM> who loses a wallet may notify the CSG <NUM> to take actions with a plurality of credit card companies, notifying them that the user <NUM>'s credit cards have been lost or stolen, and directing them to take an appropriate action, such as closing the accounts and issuing new credit cards with a new account number. A user <NUM> whose computer has been compromised may notify the CSG <NUM> of that event, causing the CSG <NUM> to request various SPs <NUM> to change passwords for the user <NUM>.

The notification to the CSG <NUM> may also be generated by third parties in some embodiments. For example, a user <NUM> with a wearable device may enroll with the CSG <NUM> so that if the wearable device can detect that it is no longer in proximity to the user <NUM>, such as being out of range of a smartphone or other mobile device belonging to the user <NUM>, the wearable device may communicate directly or indirectly with the CSG <NUM> to trigger an action, such as shutting down the wearable device, or erasing personal data associated with the user <NUM> that might be compromised by the loss of the wearable device.

In some embodiments, the CSG <NUM>, the SP <NUM>, or both may send notifications to the user <NUM> when a trigger event has been recognized, either before or after taking the predefined action. For example, in some embodiments, the CSG <NUM> may notify the user <NUM> that a trigger event has been recognized, and that the SP <NUM> will be instructed to take the action unless the user <NUM> countermands the action within a certain time period. In embodiments where an action such as a change password action is performed as a result of a trigger event, the SP <NUM> may communicate with the user <NUM> to provide necessary information for continued access to the digital assets associated with that SP <NUM>. Where a credit card account is changed, such as upon reporting loss of a credit card, the SP <NUM> may send a new credit card to the user <NUM> by mail, as well as reporting the event to the user by message or email. Any number of different actions and trigger events may be configured in embodiments of such a system. The ability to cause automated actions across a plurality of SPs <NUM> without compromising the authentication of the user <NUM> provides a highly valuable user experience.

The CSG <NUM> preferably does not store user authentication information in any form that can be directly used, such as an unencrypted password. Instead, the CSG <NUM> (and brokers <NUM>) preferably interact with the SPs <NUM> as trusted authentication agents, allowing the CSG <NUM> to authenticate the user <NUM> using any desired authentication mechanism, then communicate with the SP <NUM> using an authentication API that securely allows the SP <NUM> to trust the authentication performed by the CSG <NUM>, without requiring further authentication interactions with the user <NUM>. In some embodiments, users may configure a key or personal identification number (PIN) for use when authenticating a notification to the CSG <NUM> for a specific SP <NUM> or a specific service of an SP <NUM>. Similarly, embodiments may allow a common key or PIN that may be used as an authentication token for all of the assets enrolled by the user in such a system.

When brokers <NUM> are involved, a common protocol or API can be used to communicate with the brokers <NUM>, even though the individual brokers <NUM> may use completely different communication techniques to perform the unique interactions required by different SPs <NUM>.

Referring now to <FIG>, a block diagram illustrates a programmable device <NUM> that may be used for either the CSG <NUM> or the brokers <NUM> in accordance with one embodiment. The programmable device illustrated in <FIG> is a multiprocessor programmable device <NUM> that includes a first processing element <NUM> and a second processing element <NUM>. While two processing elements <NUM> and <NUM> are shown, an embodiment of programmable device <NUM> may also include only one such processing element.

Programmable device <NUM> is illustrated as a point-to-point interconnect system, in which the first processing element <NUM> and second processing element <NUM> are coupled via a point-to-point interconnect <NUM>. Any or all of the interconnects illustrated in <FIG> may be implemented as multi-drop bus rather than point-to-point interconnects.

As illustrated in <FIG>, each of processing elements <NUM> and <NUM> may be multicore processors, including first and second processor cores (i.e., processor cores 674a and 674b and processor cores 684a and 684b). Such cores 674a, 674b, 684a, 684b may be configured to execute instruction code for performing the CSG and broker functionality described above. However, other embodiments may use processing elements that are single core processors as desired. In embodiments with multiple processing elements <NUM>, <NUM>, each processing element may be implemented with different numbers of cores as desired.

Each processing element <NUM>, <NUM> may include at least one shared cache <NUM>. The shared cache 646a, 646b may store data (e.g., instructions) that are utilized by one or more components of the processing element, such as the cores 674a, 674b and 684a, 684b, respectively. For example, the shared cache may locally cache data stored in a memory <NUM>, <NUM> for faster access by components of the processing elements <NUM>, <NUM>. In one or more embodiments, the shared cache 646a, 646b may include one or more mid-level caches, such as level <NUM> (L2), level <NUM> (L3), level <NUM> (L4), or other levels of cache, a last level cache (LLC), or combinations thereof.

While <FIG> illustrates a programmable device with two processing elements <NUM>, <NUM> for clarity of the drawing, the scope of the present invention is not so limited and any number of processing elements may be present. Alternatively, one or more of processing elements <NUM>, <NUM> may be an element other than a processor, such as an graphics processing unit (GPU), a digital signal processing (DSP) unit, a field programmable gate array, or any other programmable processing element. Processing element <NUM> may be heterogeneous or asymmetric to processing element <NUM>. There may be a variety of differences between the processing elements <NUM>, <NUM> in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst the processing elements <NUM>, <NUM>. In some embodiments, the various processing elements <NUM>, <NUM> may reside in the same die package.

First processing element <NUM> may further include memory controller logic (MC) <NUM> and point-to-point (P-P) interfaces <NUM> and <NUM>. Similarly, second processing element <NUM> may include a MC <NUM> and P-P interfaces <NUM> and <NUM>. As illustrated in <FIG>, MCs <NUM> and <NUM> couple the processing elements <NUM>, <NUM> to respective memories, namely a memory <NUM> and a memory <NUM>, which may be portions of main memory locally attached to the respective processors. While MC logic <NUM> and <NUM> is illustrated as integrated into the processing elements <NUM>, <NUM>, in some embodiments the MC logic may be discrete logic outside the processing elements <NUM>, <NUM> rather than integrated therein.

Processing element <NUM> and processing element <NUM> may be coupled to an I/O subsystem <NUM> via P-P interfaces <NUM> and <NUM> and P-P interconnects <NUM> and <NUM>, respectively. As illustrated in <FIG>, I/O subsystem <NUM> includes P-P interfaces <NUM> and <NUM>. Furthermore, I/O subsystem <NUM> includes an interface <NUM> to couple I/O subsystem <NUM> with a high performance graphics engine <NUM>. In one embodiment, bus <NUM> may be used to couple graphics engine <NUM> to I/O subsystem <NUM>. Alternately, a point-to-point interconnect <NUM> may couple these components.

In turn, I/O subsystem <NUM> may be coupled to a first link <NUM> via an interface <NUM>. In one embodiment, first link <NUM> may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another I/O interconnect bus, although the scope of the present invention is not so limited.

As illustrated in <FIG>, various I/O devices <NUM> may be coupled to first link <NUM>, along with a bridge <NUM> which may couple first link <NUM> to a second link <NUM>. In one embodiment, second link <NUM> may be a low pin count (LPC) bus. Various devices may be coupled to second link <NUM> including, for example, a keyboard/mouse <NUM>, communication device(s) <NUM> (which may in turn be in communication with the computer network <NUM>), and a data storage unit <NUM> such as a disk drive or other mass storage device which may include code <NUM>, in one embodiment. The code <NUM> may include instructions for performing embodiments of one or more of the techniques described above. Further, an audio I/O <NUM> may be coupled to second bus <NUM>.

A trusted program module (TPM) <NUM> may be coupled to the I/O subsystem <NUM> or elsewhere in the programmable device <NUM> for providing the TEE <NUM> or <NUM>. The TPM <NUM> typically is cryptographically controlled and restricts execution to only executable code signed with a cryptographic key. The TPM <NUM> may be implemented as a separate chip or chipset from the processing elements, or may be packaged as part of a chipset providing some or all of the elements illustrated in <FIG>.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture of <FIG>, a system may implement a multi-drop bus or another such communication topology. Although links <NUM> and <NUM> are illustrated as busses in <FIG>, any desired type of link may be used. In addition, the elements of <FIG> may alternatively be partitioned using more or fewer integrated chips than illustrated in <FIG>. For example, the components may be implemented as networked (LAN, enterprise network, Internet and/or distributed in the cloud) computing devices (real or virtual) or microcontrollers which jointly perform the <NUM> function.

Referring now to <FIG>, a block diagram illustrates a programmable device <NUM> according to another embodiment. Certain aspects of <FIG> have been omitted from <FIG> in order to avoid obscuring other aspects of <FIG>.

<FIG> illustrates that processing elements <NUM>, <NUM> may include integrated memory and I/O control logic ("CL") <NUM> and <NUM>, respectively. In some embodiments, the CL <NUM>, <NUM> may include memory control logic (MC) such as that described above in connection with <FIG>. In addition, CL <NUM>, <NUM> may also include I/O control logic. <FIG> illustrates that not only may the memories <NUM>, <NUM> be coupled to the CL <NUM>, <NUM>, but also that I/O devices <NUM> may also be coupled to the control logic <NUM>, <NUM>. Legacy I/O devices <NUM> may be coupled to the I/O subsystem <NUM> by interface <NUM>. Each processing element <NUM>, <NUM> may include multiple processor cores, illustrated in <FIG> as processor cores 774A, 774B, 784A, and 784B. As illustrated in <FIG>, I/O subsystem <NUM> includes P-P interfaces <NUM> and <NUM> that connect to P-P interfaces <NUM> and <NUM> of the processing elements <NUM> and <NUM> with interconnects <NUM> and <NUM>. Processing elements <NUM> and <NUM> may also be interconnected by interconnect <NUM> and interfaces <NUM> and <NUM>, respectively.

As with the programmable device <NUM>, the programmable device <NUM> may contain a TPM <NUM>.

The programmable devices depicted in <FIG> and <FIG> are schematic illustrations of embodiments of programmable devices that may be utilized to implement various embodiments discussed herein. Various components of the programmable devices depicted in <FIG> and <FIG> may be combined in a system-on-a-chip (SoC) architecture.

Claim 1:
A gateway system (<NUM>) to allow access to digital assets owned by a user and managed by a first online service provider (<NUM>) and a second online service provider (<NUM>), the system comprising:
a trusted authentication interface;
one or more processors; and
a memory, including instructions that, when executed by the one or more processors, cause the one or more processors to at least:
obtain information from the first online service provider and the second online service provider, the information identifying: (a) a first type of the digital assets managed by the first online service provider and a second type of the digital assets managed by the second online service provider and (b) a first type of actions that the gateway system is permitted to request on behalf of the user for the first type of the digital assets and a second type of actions that the gateway system is permitted to request on behalf of the user for the second type of the digital assets;
in response to an occurrence of a trigger event (<NUM>) that the user has previously defined with the gateway system:
send action instructions (<NUM>, <NUM>), via the trusted authentication interface, to the first online service provider and the second online service provider, the action instructions to instruct the first online service provider and the second online service provider to respectively take an action (<NUM>) corresponding to the trigger event on the first type of the digital assets and the second type of the digital assets, the action included in the first type of actions and the second type of actions that the gateway system is permitted to request on behalf of the user; and
allow, via the trusted authentication interface, the first online service provider and the second online service provider to trust the action instructions without authenticating the user, wherein an authentication API communicates a previous authentication of the user performed by the gateway system to the first online service provider and the second online service provider.