Patent Grant
11658962
This invention relates generally to the digital security services field, and more specifically to a new and useful system and method of notifying mobile devices to complete transactions in the digital security field.
Fraudulent transactions, whether executed online by a malicious party who has stolen a user's online banking password or offline by a malicious party entering a restricted building using a forged identification card, are indicators of a lack of authentication in present day security systems. Similarly, authorization (permission to complete a transaction) is limited without a strong notion of authentication. Traditionally, techniques for authentication are classified into several broad classes such as “what you know” (e.g., passwords or a social security number), “what you have” (e.g., physical possessions such as ATM cards or a security dongle), and “what you are” (e.g., biometric information such as a finger print or DNA). However, many of these solutions are burdensome to users, requiring the user to remember information or carry extra devices to complete a transaction.
Recent innovations in the digital security space has provided authentication and/or verification solutions that overcome the deficiencies of the above-mentioned problems by enabling push-based authentication to mobile communication devices and the like, as described in the prior applications that are related to the instant application. While the push-based authentication as implemented in modern security applications may typically be used to authenticate and/or authorize a user typically at login or at an access point, there is no current solution for authenticating and/or confirming authorization of ad-hoc requests from internal users of an enterprise for performing a sensitive operation or the like. This deficiency is equally apparent with customers and/or external users to the enterprise.
Thus, there is a need in the digital security services field to create a new and useful system and method of verifying internal users and/or external users of an enterprise via an out-of-band technique, such as by notifying mobile devices to complete or confirm a request for a transaction or the like. The one or more inventions described herein below provide such new and useful systems and methods.
In one embodiment, a method for implementing an application programming interface for multi-factor authentication service includes at a subscriber entity: receiving, from a requestor, an access request to one or more services or to one or more resources of the subscriber entity, wherein the subscriber entity relates to an entity having a subscriber account with a remote security service, wherein the subscriber account subscribes the subscriber entity to one or more security services of the remote security service; transmitting a user validation request via a validation application programming interface (API) of the remote security service based on the access request; at the validation API of the remote security service: identifying: (i) the subscriber account of the subscriber entity and (ii) an enrolled user device of a user enrolled with the subscriber account based on the user validation request; identifying an authentication scheme from a plurality of distinct authentication schemes based on the user validation request; transmitting to the enrolled user device an authentication request based on the authentication scheme; collecting from the enrolled user device a response to the authentication request and presenting a validation response to the authentication request to the subscriber entity based on the response; and granting or denying the access request of the requestor based on the validation response from the validation API of the remote security service.
In one embodiment, transmitting the user validation request includes selecting by the subscriber entity the authentication scheme via the validation API, wherein the authentication scheme indicates one distinct authentication method selected from a plurality of distinct authentication methods for authenticating the requestor.
In one embodiment, the enrolled user device of the user includes a security application of the remote security service installed locally on the enrolled user device of the user, and the authentication scheme includes pushing the authentication request, via the API, to the security application of the enrolled user device of the user.
In one embodiment, the authentication scheme includes transmitting from the API the authentication request in a short message service message to the enrolled user device of the user.
In one embodiment, the authentication scheme includes (a) generating a one-time password (OTP) by the API and transmitting from the API the authentication request comprising the OTP to the enrolled user device of the user.
In one embodiment, the authentication scheme includes (a) generating a universal second factor (U2F) token by the API and transmitting from the API the authentication request comprising the U2F token to the enrolled user device of the user.
In one embodiment, the method includes at the subscriber entity: identifying the requestor via the validation API, wherein the identifying includes: searching the requestor via the validation API based on identification data of the requestor, and selecting the requestor from search results of the validation API, wherein transmitting the user validation request via the validation API is based on the selection of the requestor.
In one embodiment, the authentication service maintains a list of users having one or more enrolled user devices with the subscriber account, and the list of users is exposed via the validation API based on an initiation of the user validation request by the subscriber entity.
In one embodiment, the authentication service maintains a list of users having one or more enrolled user devices with the subscriber account, and the list of users is exposed via the validation application programming interface based on the searching the requestor via the validation API.
In one embodiment, presenting the validation response to the authentication request to the subscribing entity includes presenting the validation response via the validation API, the validation response indicating a successful authentication or an unsuccessful authentication of the user.
In one embodiment, the requestor relates to an internal requestor that includes an agent of the subscriber entity.
In one embodiment, the requestor relates to an external requestor that includes a non-agent of the subscriber entity, and the external requestor enrolls a user device to the subscriber account at the remote security service based on scanning with the user device a computer-readable code that automatically enrolls the user device that scans the computer-readable code to the subscriber account.
In one embodiment, the method includes at the subscriber entity: implementing a web-based interface that exposes the validation API of the remote security service.
In one embodiment, the remote security service is implemented by a distributed network of computers including the validation API.
In one embodiment, the validation response comprises an indication computed by the remote security service indicating that a validation of the requestor is successful based on the response to the authentication request.
In one embodiment, the validation response comprises an indication computed by the remote security service indicating that a validation of the requestor is unsuccessful based on the response to the authentication request.
In one embodiment, a method of implementing an application programming interface of an authentication service for authenticating internal users or external users to a subscriber of the authentication service includes implementing confirmation application programming interface (API) that is in operable communication with API endpoints of a remote authentication service, wherein the implementing includes: initiating a confirmation API request based on receiving an access request at a subscriber to the remote authentication service, wherein the confirmation API request operates to perform an authentication of a requestor making the access request; identifying the requestor based on a search of the requestor via the confirmation API; identifying, by one or more API endpoints of the remote authentication service: (i) a subscriber account of the subscriber maintained by the remote authentication service and (ii) identifying a user device of the requestor that is enrolled with the subscriber account based on the confirmation API request; transmitting a confirmation request, by the one or more API endpoints of the remote authentication service, to the user device that is enrolled with the subscriber account; obtaining from the user device a response to the confirmation request and presenting the response to the confirmation request to the subscriber; and granting or denying the access request based on the response from the confirmation API of the remote authentication service.
In one embodiment, the method includes at the subscriber entity: identifying the requestor via the validation API, wherein the identifying includes: searching the requestor via the validation API based on identification data of the requestor, and selecting the requestor from search results of the validation API, wherein transmitting the user validation request via the validation API is based on the selection of the requestor.
The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
As shown in
Generally, the method 100 functions to use push-based challenges on mobile communication device for the authentication and/or authorization of parties involved in a transaction. The method 100 functions to utilize non-intrusive techniques while providing improved security. The pushed messages preferably alert a user to the transaction request in real-time such that a decision of confirmation or denial of a transaction can be communicated to a requesting party with minimal time lag (e.g., preferably less than a minute, and more preferably less than 10 seconds). The method may be employed as standalone transaction validation or incorporated into a multifactor system. The method may be used in application such as web-based applications, remote access credentials, privileged account management, financial transactions, password recovery/reset mechanisms, physical access control, Automatic Teller Machine (ATM) withdrawals, domain name transfers, online or offline transactions, building access security, internal enterprise or any suitable application requiring authentication and/or authorization.
As shown in
The method 100 is preferably performed in conjunction with a remote authentication service that provides an application programming interface (API) that enables a subscriber to the authentication service to initiate a push-based authentication and/or authorization request to a mobile communication device of a requestor that is enrolled with the authentication service, as described in U.S. application Ser. No. 13/039,209 and U.S. application Ser. No. 15/146,223, which are both incorporated herein in their entireties by this reference. The authentication service is preferably an internet-accessible server that may be hosted on a distributed computing system but may be hosted on any suitable platform. The initiating agent may typically be an agent of an entity or enterprise (i.e., a subscriber to the authentication service) that is responsible for handling one or more request from internal requestors and/or external requestors for security sensitive operations and/or resources of the entity.
The requested transaction is preferably initiated by the initiating agent through a client such as a website, application, a mobile communication device, a communication application (e.g., a messaging application, or any suitable device capable of achieving a communication connection with the subscriber entity. For authentication, the initiator agent may be a legitimate party or a malicious party attempting to fraudulently impersonate the legitimate party. For authorization, the initiating agent may be a legitimate authenticated party but may require authorization approval to perform the action of the transaction. The authority device is preferably a device associated with an authentic agent that is a user or process that is legitimately authenticated or authorized to execute transactions. Even if a malicious entity were attempting to impersonate a user or authentic agent through stolen credentials or other means, they would—ideally—lack the authority device to complete a transaction because the malicious entity would most likely lack the authority device required for processing additional authentication and/or authorization.
S110, which includes registering an authority device for an account on an authentication service, functions to identify a suitable device of an agent that is permitted to authenticate or authorize transactions and enroll the device with the authentication service. The registration preferably occurs prior to a transaction request and is preferably performed during an initial setup of an account on the authentication service. For example, in the circumstance that the method 100 is implemented with an enterprise subscriber, each employee or agent of the enterprise may be required to enroll a secure device for authenticating the employee or agent (e.g., internal users) for accessing and/or performing security-sensitive transactions (i.e., any transaction determined to need authentication via the authentication service). Additionally, or alternatively, external users (e.g., customers, service providers, etc.) of the enterprise subscriber may similarly be required to enroll or register an authority/authentication device for enabling a provision of a service and/or performing a transaction with the enterprise subscriber.
In a preferred embodiment, Silo may function to enroll an authority device of a (internal/external) user to an account of the subscriber entity that is held and/or maintained by the authentication service. That is, in such embodiments, the subscriber entity may have a preexisting subscription or a subscriber account with the authentication service onto which internal or external users who intend to authenticate with the subscriber may have one or more user devices enrolled to the preexisting subscriber account.
It shall be noted that the method 100 may equally be applicable for authenticating and/or confirming authorization of security-sensitive users (i.e., any user determined to need authentication/authorization via the authentication service). Security-sensitive users may include users of a subscriber entity (as designated by the subscriber entity); in such an implementation, the subscriber entity may communicate such designation to the authentication service in any manner including, but not limited to, via communicating an access policy to the authentication service. For example, the subscriber entity may simply flag any transaction requests related to a security-sensitive user as requiring authentication/authorization verification (without explicitly informing the authentication service that a particular user is security-sensitive). As another example, the subscriber entity may provide a list of security-sensitive users to an authentication service; these users may in turn be linked to specific instances of authenticating apps and/or authority devices. Security-sensitive users may additionally or alternatively include authority agents; that is, security-sensitive users may be specified by the authentication service rather than another entity. For example, a user of an authentication app (of the authentication platform) may be an authority agent for transactions involving several external entities; the authentication app may require authentication/authorization verification for that user for transactions involving all of those external entities if the user is determined to be a security-sensitive user by the authentication service. Security-sensitive users may additionally or alternatively be determined by any entity in any manner.
It shall be noted that the method 100 may equally be applicable for authenticating and/or confirming authorization of a requestor for accessing security-sensitive applications (i.e., any application that requires authentication/authorization via the authentication service). In one or more embodiments, if a transaction related to a security-sensitive application occurs, authenticating and/or confirming authorization of the requestor must occur to complete the transaction. In this example, the method 100 may enable an agent of the subscriber entity to detect that a transaction is associated with a security sensitive application in any manner. The method 100 may enable an agent of the subscriber entity to detect security sensitivity of applications using any technique of U.S. patent application Ser. No. 15/075,687, the entirety of which is incorporated by this reference.
During the setup authentication and/or authorization rules are preferably set. The authority device is preferably a mobile computing (communication) device possessed by an authentic user or an authorized agent. The mobile device is preferably a mobile phone, tablet computer, smartphone, personal data assistant (PDA), personal computer, and/or any suitable computing device. The authority device preferably has access to a network over which communication with the authentication platform is performed, such as a WiFi network, local-area network, telephony network, short message service (SMS) network, multimedia messaging service (MMS), or any suitable network. A plurality of devices may additionally be registered. A second authority device may provide a backup communication point if a primary authority device does not respond. For example, after attempting to contact a primary authority device, the authentication platform may message a secondary authority device for authentication or authorization. Or, alternatively, a threshold of two confirmations may need to be received to authorize a transaction. Additionally, a first authority device may be registered for authenticating the identity of an agent of the transaction request, and a second authority device may be registered for authorizing an action of an agent such that authentication and authorization may both be enabled.
S120, which includes receiving a transaction request from an initiator to a subscriber entity, functions to initiate a (protected) transaction. The transaction is preferably any event, attempt to access a computing resource (e.g., secured data, secured computing elements, etc.), transfer, action, or activity (e.g., involving a subscriber entity) that requires authentication and/or authorization of an involved party (e.g., an authority agent or an initiator, etc.). An exemplary transaction may include an attempt by an employee of a subscriber entity to access a secure data resource or a protected application of the subscriber entity by contacting an information technology (IT) agent of the subscriber entity. In such example, the employee may function to contact the IT agent requesting access to a secure data resource and prior to granting permissions or access to the secure data resource, the IT agent may function to authenticate or confirm authorization for the request by identifying or validating the requestor as a recognized employee and further, initiating a push-based challenge to an enrolled mobile communication device of the employee. Other exemplary transactions may include logging into a website, application or computer system; a user withdrawing money from an ATM; a user initiating a “forgotten password” procedure; a user attempting to enter a restricted area of a building or environment; a payment exchange between two entities; a user attempting to perform a restricted action in a computer system; and/or any suitable application requiring authentication and/or authorization.
Authentication preferably includes validating the identity of at least one involved party relevant to a transaction. Authorization preferably includes validating authority or permission of an entity to execute a transaction. For authentication, the authority device preferably belongs to the authentic user for self-approval of transactions. For authorization, the authority device preferably belongs to an authoritative user (e.g., an authority agent) that is preferably in charge of regulating transactions of a user involved in the transaction. The transactions are preferably initiated in an online environment, where parties may be communicating using a computing device or public/private network, but the transactions may alternatively occur offline where parties may be interacting in the real world. The user or device initiating the transaction is ideally a legitimate party, but in the situations where a malicious party initiates or participates in the transaction, the method 100 is preferably able to properly identify such a situation. After a malicious transaction is prevented the approval rules for a transaction may be dynamically altered to increase security. The transaction is preferably sent from a requesting entity such as a website, application, or device. The requesting entity is typically a system of a subscriber entity in communication with the authentication service. As mentioned previously, an application programming interface (API) or any suitable protocol is preferably used to communicate between the subscriber entity and the authentication service.
In one variation, the communication sent from the subscriber entity is encrypted and the authority device preferably decrypts the information. This variation preferably prevents the authentication service from inspecting or accessing the communicated information which may be applicable when a third party is passing sensitive information through the authentication service. As an alternative variation, the communication between the subscriber entity and the authentication service may preferably be encrypted or otherwise cryptographically protected and communication between the authentication service and the authority device verifies that the communication is from the authority device. Any suitable steps may be taken to secure the communication between the requesting entity, the authentication service and the authority device.
Note that the authority of the authority agent to authorize transactions may be managed in any manner. For example, the authentication service may maintain descriptors of user identity that may be used to link accounts of authority agents with service providers/subscriber entity (e.g., login information of a website) to the authority agent and/or authority device. In this example, when attempting to authenticate or confirm an authorization of a requestor for a transaction, the authentication service may function to expose the descriptors of user identity along with some account data to the subscriber entity via an API. Accordingly, an agent of the subscriber entity may function to manipulate and/or select a descriptor associated with the purported requestor in order to initiate an authentication and/or confirmation of an authorization of the requestor. Additionally, or alternatively, information corresponding to these user identity descriptors may be transmitted by the subscriber entity or other initiator to the authentication service (when requesting authorization). At the authentication service, this information may be used to identify the authority agent or authority device (e.g., a user account at the authentication platform associated with the authority agent, which may be independent of any user account maintained at the service provider).
S130, which includes implementing a confirmation API, may function to provide a confirmation API that enables an agent of the subscriber entity to identify and/or locate a requestor that is enrolled or registered with the authentication service. That is, at the subscriber entity, an agent of the subscriber entity handling a transaction request from a request may function to access a confirmation API provided by the authentication service for purposes of locating users enrolled and/or registered with the authentication service. In a preferred embodiment, the transaction request from the request may include or otherwise, be presented to the subscriber entity with requestor identification data or credentials. In such preferred embodiment, the subscriber entity (or an agent thereof) may function to use the confirmation API of the authentication service and the requestor identification data to locate the requestor.
In some embodiments, the confirmation API of the authentication service may enable the subscriber entity to call a directory of internal users (e.g., employees, agents, contractors, systems, etc.) of the subscriber entity and/or a directory of external users of the subscriber entity and locate (select) the requestor using the directory based on the requestor identification data. In one variation, the confirmation API of the authentication service may enable the subscriber to generate an API call using the requestors identification data that enables the subscriber entity to (automatically) generate a push-based request to an enrolled device of the requestor.
Additionally, or alternatively, once the requestor of the transaction is located and/or selected, S130 may function to enable the subscriber entity to include transaction details with the push-based message prior to initiating an API request to send the push-based message to the enrolled device of the requestor.
It shall also be noted that while in a preferred embodiment, the subscriber entity may use the confirmation API to trigger a push-based confirmation message to an enrolled device of a requestor, other or additional confirmation/authentication schemes may be performed or implemented using the confirmation API including, but not limited to, short messaging service (SMS), electronic mail (e-mail) one-time password (OTP), universal second factor (U2F) authentication token, an automated phone call with authentication data, a chat messaging communication, and/or any suitable electronic communication medium that may be deployed with the confirmation API. That is, the confirmation API may be used to independently or additionally send a confirmation to the enrolled device that includes one or more of the above-mentioned confirmation schemes or any known electronic communication medium. For instance, in the case that an SMS message is triggered using the confirmation API, the SMS messaging may be provided to the enrolled device of the requestor indicating that an action needs to be taken in an authentication service application hosted on the enrolled mobile communication (authority) device of the requestor. In another example, in the circumstance that an OTP is triggered using the confirmation API, the confirmation API may function to generate the OTP and transmit the OTP via SMS, via a security application installed locally on the enrolled device, to a communication medium or channel (e.g., Slack, chat messaging, and/or the like) operating on the enrolled device. In yet another example, in the circumstance that a U2F token is provided, S130 may function to redirect an authenticating user to a web page or the like into which the authenticating user may use or provide the U2F token for authenticating the authenticating user.
S140, which includes messaging the authority device with the transaction request, functions to push a notification or message to an enrolled authority device for authentication or authorization. The messaging of the authority device is preferably initiated by the subscriber entity using the confirmation API. In such preferred implementation, an agent of the subscriber entity may function to locate or select the requestor via the confirmation API and additionally, trigger an initialization or transmission of the push notification using an API call or the like.
A push notification to the enrolled authority device preferably includes a response prompt and is displayed on the enrolled authority device, enabling a user response. Additionally, or alternatively, response to the transaction request may be performed in any manner. The authority device is preferably a device only the authentic user or an authorized user would possess. The message is preferably sent through a communication channel between the authority device and the authentication service. The communication channel is preferably a push notification service provided through the authority device. The communication channel may alternatively be a short message system SMS network, email, an instant message, an in-app notification system, web-based websocket or publication-subscription channels, image based transmission of transaction information such as through QR-codes captured by a camera, or any suitable technique for messaging the device. The messages preferably appear on the authority device or create an alert in substantially real-time (e.g., in less than 5 minutes). The real-time aspect of the messaging functions to enable authentication and authorization at the time of the transaction.
In one variation, tracking a registered authority device may additionally be performed by the authentication service. For example, in a persistent TCP/IP connection model, a mobile device moving from a service provider data network to a WiFi network may change IP addresses and therefore initiate a new persistent connection. Upon receiving that new connection and an identifier of the mobile device, the authentication service preferably updates the state of the device for the account associated with that device. Then, the proper connection is preferably used for messaging the authority device. Some communication channels may have limited throughput and lack the capability to present a full message from the authentication platform. For example, SMS messages have a 160 character limit. An initial message may include a unique identifier, which can then be used to retrieve a full message. For example, the SMS message may include a URL link or code which can be used to retrieve a full message from an application or website. The full message may provide additional information and options for a transaction response. The messages transmitted over the communication channel may additionally be cryptographically signed and encrypted using an established setup between the authentication device and the authentication platform. Additionally, the messages preferably include transaction information (i.e., metadata). The transaction information may include account or entity name, transaction details, location and time of transaction, IP address of initiating host, geolocation of the IP address or any suitable information or any suitable data on the transaction. In one example an online bank transfer may have a message with transaction information including payer, payee, account numbers, transfer amount, and transaction date and time.
S150, which includes receiving an authority agent response from the enrolled authority device to the authentication service, functions to process a response from an authentic user or authorized user. The response preferably confirms or denies a transaction. The confirmation and denial of a transaction may additionally be set to indicate any suitable form of response. Preferably, the initial options are to accept or reject a transaction. Additionally, if a transaction is rejected a reason for rejection may be included such as “canceled because of change of mind” or “possible malevolent transaction”. Other variations may include a variety of options that may change based on the application. The available forms of responses may be included in the message information. Other forms of responses may allow a variety of multiple-choice options, variable setting options, or any suitable form of response input. For example, if a manager is acting as an authorization provider for an access request to a sensitive enterprise application made by an internal user (e.g., an employee), a message may be sent to a phone of the manager indicating that the employee is attempting to access a sensitive application. The manager may be able to respond allowing the access to the sensitive application for a restricted or limited period (e.g., access for 10 minutes). As an additional sub-step to receiving an authority agent response, the response is preferably verified to be a legitimate response from the authority device as opposed to an entity imitating the device. Secure Socket Layer (SSL), a Hash-based Message Authentication Code (HMAC), message signing, or any suitable cryptographic protocol may be used to verify the response is from the authority device.
Additionally, or alternatively, S150 may function to provide a result of a confirmation request (push notification) via a user interface of an administrative panel or the like of an agent of the subscriber entity that initiated the confirmation request. As shown by way of example in
Optionally, S160 and S162, which include if the authority agent response confirms the transaction, communicating a confirmed transaction to the initiator, and if the authority agent response denies the transaction, communicating a denied transaction to the requestor, function to communicate the authentication and/or authorization to the requestor of the transaction. Any suitable response to a transaction is preferably communicated back to the subscriber entity. The subscriber entity can then preferably take appropriate action. If the transaction is confirmed or approved, the transaction proceeds. If the transaction is denied or altered, the subscriber entity preferably halts or prevents the transaction. The subscriber entity can preferably use the transaction response to modify a transaction state in any suitable manner. Based on the variety of responses from authentic users and/or authorized users, rules may determine when to confirm or deny a transaction. In a variation of the method, there may be a plurality of authority devices registered for authorization and/or authentication. A rule may be setup for which authority devices to message, in what order, and the timing of the messaging. Additionally, rules may be set for received responses. A particular threshold for the number of responses from the plurality of authority devices may be set. For example, four authority devices may be messaged for authorization and at least three must confirm the transaction for it to be confirmed. In another example, a plurality of authority devices for authentication may be registered, and the authority devices are messaged one after the other until at least one responds. The response from an authority agent may alternatively be passed on to the requesting entity with no analysis.
Alternative embodiments may implement the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with an authentication platform. The authentication platform is preferably hosted on a distributed computing system or cloud based platform but may alternatively be hosted in any suitable system. The computer-readable medium may be stored on any suitable computer readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device. The authentication platform preferably includes an API for third party services and devices to use in initiating transactions and interpreting responses from the authentication platform. The platform preferably includes a communication channel such as a public or private network or SMS network to communicate with at least one authority device. The authority device is preferably a mobile phone but may be any suitable personal computing device.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
This application claims the benefit of U.S. Provisional Application No. 62/776,641 filed 7 Dec. 2018, which is incorporated in its entirety by this reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5754763 | Bereiter | May 1998 | A |
| 5838792 | Ganesan | Nov 1998 | A |
| 5870723 | Pare et al. | Feb 1999 | A |
| 6119096 | Mann et al. | Sep 2000 | A |
| 6209091 | Sudia et al. | Mar 2001 | B1 |
| 6311272 | Gressel | Oct 2001 | B1 |
| 6662205 | Bereiter | Dec 2003 | B1 |
| 6694025 | Epstein et al. | Feb 2004 | B1 |
| 6758394 | Maskatiya et al. | Jul 2004 | B2 |
| 6823359 | Heidingsfeld et al. | Nov 2004 | B1 |
| 6934858 | Woodhill | Aug 2005 | B2 |
| 6956950 | Kausik | Oct 2005 | B2 |
| 6990591 | Pearson | Jan 2006 | B1 |
| 6996716 | Hsu | Feb 2006 | B1 |
| 7000247 | Banzhof | Feb 2006 | B2 |
| 7093133 | Hopkins et al. | Aug 2006 | B2 |
| 7096354 | Wheeler et al. | Aug 2006 | B2 |
| 7107246 | Wang | Sep 2006 | B2 |
| 7146009 | Andivahis et al. | Dec 2006 | B2 |
| 7172115 | Lauden | Feb 2007 | B2 |
| 7213260 | Judge | May 2007 | B2 |
| 7331518 | Rable | Feb 2008 | B2 |
| 7334255 | Lin et al. | Feb 2008 | B2 |
| 7340600 | Corella | Mar 2008 | B1 |
| 7386720 | Sandhu et al. | Jun 2008 | B2 |
| 7447784 | Eun | Nov 2008 | B2 |
| 7463637 | Bou-Diab et al. | Dec 2008 | B2 |
| 7483384 | Bryant et al. | Jan 2009 | B2 |
| 7496662 | Roesch et al. | Feb 2009 | B1 |
| 7526792 | Ross | Apr 2009 | B2 |
| 7562382 | Hinton et al. | Jul 2009 | B2 |
| 7562385 | Thione et al. | Jul 2009 | B2 |
| 7571471 | Sandhu et al. | Aug 2009 | B2 |
| 7574733 | Woodhill | Aug 2009 | B2 |
| 7599493 | Sandhu et al. | Oct 2009 | B2 |
| 7630493 | Sandhu et al. | Dec 2009 | B2 |
| 7711122 | Allen et al. | May 2010 | B2 |
| 7712137 | Meier | May 2010 | B2 |
| 7716240 | Lim | May 2010 | B2 |
| 7764970 | Neil et al. | Jul 2010 | B2 |
| 7793110 | Durfee et al. | Sep 2010 | B2 |
| 7836501 | Sobel et al. | Nov 2010 | B2 |
| 7904608 | Price | Mar 2011 | B2 |
| 7953979 | Borneman et al. | May 2011 | B2 |
| 7958362 | Hwang | Jun 2011 | B2 |
| 7961645 | Gudipudi et al. | Jun 2011 | B2 |
| 7982595 | Hanna et al. | Jul 2011 | B2 |
| 7983987 | Kranzley et al. | Jul 2011 | B2 |
| 8001610 | Chickering et al. | Aug 2011 | B1 |
| 8010779 | Sermersheim et al. | Aug 2011 | B2 |
| 8028329 | Whitcomb | Sep 2011 | B2 |
| 8099368 | Coulter et al. | Jan 2012 | B2 |
| 8108933 | Mahaffey | Jan 2012 | B2 |
| 8136148 | Chayanam et al. | Mar 2012 | B1 |
| 8141146 | Ozeki | Mar 2012 | B2 |
| 8151333 | Zhu et al. | Apr 2012 | B2 |
| 8161527 | Curren | Apr 2012 | B2 |
| 8185744 | Brown et al. | May 2012 | B2 |
| 8200980 | Robinson et al. | Jun 2012 | B1 |
| 8225392 | Dubrovsky et al. | Jul 2012 | B2 |
| 8245044 | Kang | Aug 2012 | B2 |
| 8259947 | Gantman et al. | Sep 2012 | B2 |
| 8332627 | Matthews et al. | Dec 2012 | B1 |
| 8335933 | Humphrey et al. | Dec 2012 | B2 |
| 8340287 | Sandhu et al. | Dec 2012 | B2 |
| 8340635 | Herz et al. | Dec 2012 | B2 |
| 8380192 | Kim et al. | Feb 2013 | B2 |
| 8397301 | Hering et al. | Mar 2013 | B2 |
| 8397302 | Mont et al. | Mar 2013 | B2 |
| 8402526 | Ahn | Mar 2013 | B2 |
| 8418168 | Tyhurst et al. | Apr 2013 | B2 |
| 8458798 | Williams et al. | Jun 2013 | B2 |
| 8484708 | Chern | Jul 2013 | B2 |
| 8495720 | Counterman | Jul 2013 | B2 |
| 8499149 | Chen | Jul 2013 | B2 |
| 8499339 | Chao et al. | Jul 2013 | B2 |
| 8510820 | Oberheide et al. | Aug 2013 | B2 |
| 8522010 | Ozzie et al. | Aug 2013 | B2 |
| 8528039 | Chakarapani | Sep 2013 | B2 |
| 8533844 | Mahaffey et al. | Sep 2013 | B2 |
| 8538028 | Goeller et al. | Sep 2013 | B2 |
| 8539544 | Srinivasan et al. | Sep 2013 | B2 |
| 8539567 | Luxemberg et al. | Sep 2013 | B1 |
| 8548426 | Smith | Oct 2013 | B2 |
| 8549601 | Ganesan | Oct 2013 | B2 |
| 8571220 | Ollikainen et al. | Oct 2013 | B2 |
| 8578162 | Jentzsch et al. | Nov 2013 | B2 |
| 8588422 | Beachem et al. | Nov 2013 | B2 |
| 8595809 | Chayanam et al. | Nov 2013 | B2 |
| 8595822 | Schrecker et al. | Nov 2013 | B2 |
| 8601554 | Gordon et al. | Dec 2013 | B2 |
| 8612305 | Dominguez et al. | Dec 2013 | B2 |
| 8627438 | Bhimanaik | Jan 2014 | B1 |
| 8646060 | Ben Ayed | Feb 2014 | B1 |
| 8646086 | Chakra et al. | Feb 2014 | B2 |
| 8667288 | Yavuz | Mar 2014 | B2 |
| 8689287 | Bohmer et al. | Apr 2014 | B2 |
| 8700729 | Dua | Apr 2014 | B2 |
| 8707365 | Corl | Apr 2014 | B2 |
| 8707384 | Jain et al. | Apr 2014 | B2 |
| 8713329 | Schneider | Apr 2014 | B2 |
| 8713639 | Cheeniyil et al. | Apr 2014 | B2 |
| 8719930 | Lapsley et al. | May 2014 | B2 |
| 8732475 | Fahrny et al. | May 2014 | B2 |
| 8732839 | Hohl | May 2014 | B2 |
| 8737623 | Hart | May 2014 | B2 |
| 8745703 | Lambert et al. | Jun 2014 | B2 |
| 8751801 | Harris et al. | Jun 2014 | B2 |
| 8756651 | Baer et al. | Jun 2014 | B2 |
| 8756698 | Sidagni | Jun 2014 | B2 |
| 8763077 | Oberheide et al. | Jun 2014 | B2 |
| 8806609 | Gladstone et al. | Aug 2014 | B2 |
| 8806638 | Mani | Aug 2014 | B1 |
| 8838759 | Eatough et al. | Sep 2014 | B1 |
| 8850017 | Ebrahimi et al. | Sep 2014 | B2 |
| 8850516 | Hrebicek et al. | Sep 2014 | B1 |
| 8850530 | Shahbazi | Sep 2014 | B2 |
| 8862097 | Brand et al. | Oct 2014 | B2 |
| 8891772 | D'Souza et al. | Nov 2014 | B2 |
| 8893230 | Oberheide et al. | Nov 2014 | B2 |
| 8898762 | Kang | Nov 2014 | B2 |
| 8903365 | Stricklen et al. | Dec 2014 | B2 |
| 8935769 | Hessler | Jan 2015 | B2 |
| 8938531 | Cotton et al. | Jan 2015 | B1 |
| 8938799 | Kuo | Jan 2015 | B2 |
| 8949596 | Yin et al. | Feb 2015 | B2 |
| 8949927 | Arnott et al. | Feb 2015 | B2 |
| 8955038 | Nicodemus et al. | Feb 2015 | B2 |
| 8955075 | Von Bokern et al. | Feb 2015 | B2 |
| 8966587 | Nair et al. | Feb 2015 | B2 |
| 8984276 | Benson et al. | Mar 2015 | B2 |
| 9037127 | Raleigh | May 2015 | B2 |
| 9043886 | Srinivasan et al. | May 2015 | B2 |
| 9049011 | Agrawal | Jun 2015 | B1 |
| 9049594 | Chen et al. | Jun 2015 | B2 |
| 9071611 | Yadav et al. | Jun 2015 | B2 |
| 9076343 | Chaar et al. | Jul 2015 | B2 |
| 9077758 | McGovern et al. | Jul 2015 | B1 |
| 9110754 | Poonamalli et al. | Aug 2015 | B2 |
| 9118656 | Ting et al. | Aug 2015 | B2 |
| 9122888 | Devi | Sep 2015 | B2 |
| 9124582 | Kalinichenko et al. | Sep 2015 | B2 |
| 9135458 | Hankins et al. | Sep 2015 | B1 |
| 9154387 | Maki et al. | Oct 2015 | B2 |
| 9172545 | Edstrom et al. | Oct 2015 | B2 |
| 9189491 | Fushman et al. | Nov 2015 | B2 |
| 9201644 | Klein et al. | Dec 2015 | B2 |
| 9203841 | Neuman et al. | Dec 2015 | B2 |
| 9223961 | Sokolov | Dec 2015 | B1 |
| 9225840 | Malatack et al. | Dec 2015 | B2 |
| 9253185 | Alaranta et al. | Feb 2016 | B2 |
| 9258296 | Juthani | Feb 2016 | B2 |
| 9270674 | Lang et al. | Feb 2016 | B2 |
| 9282085 | Oberheide et al. | Mar 2016 | B2 |
| 9338156 | Oberheide et al. | May 2016 | B2 |
| 9338163 | Wendling et al. | May 2016 | B2 |
| 9344275 | Bar-El et al. | May 2016 | B2 |
| 9374654 | Lindeman et al. | Jun 2016 | B2 |
| 9386003 | Kumar | Jul 2016 | B2 |
| 9391980 | Krahn et al. | Jul 2016 | B1 |
| 9397892 | Kirner et al. | Jul 2016 | B2 |
| 9430938 | Proud | Aug 2016 | B2 |
| 9443073 | Oberheide et al. | Sep 2016 | B2 |
| 9443084 | Nice et al. | Sep 2016 | B2 |
| 9454365 | Oberheide et al. | Sep 2016 | B2 |
| 9467463 | Oberheide et al. | Oct 2016 | B2 |
| 9479509 | Zeuthen | Oct 2016 | B2 |
| 9501315 | Desai et al. | Nov 2016 | B2 |
| 9544143 | Oberheide et al. | Jan 2017 | B2 |
| 9607155 | Beresnevichiene et al. | Mar 2017 | B2 |
| 9659160 | Ligatti et al. | May 2017 | B2 |
| 9680864 | Khesin | Jun 2017 | B2 |
| 9706410 | Sreenivas et al. | Jul 2017 | B2 |
| 9723019 | Rathor | Aug 2017 | B1 |
| 9754097 | Hessler | Sep 2017 | B2 |
| 9762429 | Elmaliah | Sep 2017 | B2 |
| 9769538 | Killick | Sep 2017 | B2 |
| 9832221 | Newstadt et al. | Nov 2017 | B1 |
| 9918226 | Khan | Mar 2018 | B2 |
| 9940119 | Brownell et al. | Apr 2018 | B2 |
| 9996343 | Oberheide et al. | Jun 2018 | B2 |
| 20020013898 | Sudia et al. | Jan 2002 | A1 |
| 20020091745 | Ramamurthy et al. | Jul 2002 | A1 |
| 20020123967 | Wang | Sep 2002 | A1 |
| 20020131404 | Mehta et al. | Sep 2002 | A1 |
| 20020136410 | Hanna | Sep 2002 | A1 |
| 20030011545 | Sagano et al. | Jan 2003 | A1 |
| 20030012093 | Tada et al. | Jan 2003 | A1 |
| 20030061506 | Cooper et al. | Mar 2003 | A1 |
| 20030115452 | Sandhu et al. | Jun 2003 | A1 |
| 20030120931 | Hopkins et al. | Jun 2003 | A1 |
| 20030126472 | Banzhof | Jul 2003 | A1 |
| 20030147536 | Andivahis et al. | Aug 2003 | A1 |
| 20030149781 | Yared et al. | Aug 2003 | A1 |
| 20030172291 | Judge et al. | Sep 2003 | A1 |
| 20040064706 | Lin et al. | Apr 2004 | A1 |
| 20040139318 | Fiala et al. | Jul 2004 | A1 |
| 20040187018 | Owen et al. | Sep 2004 | A1 |
| 20040215672 | Pfitzner | Oct 2004 | A1 |
| 20040218763 | Gantman et al. | Nov 2004 | A1 |
| 20050024052 | Bendall et al. | Feb 2005 | A1 |
| 20050097350 | Patrick et al. | May 2005 | A1 |
| 20050097352 | Patrick et al. | May 2005 | A1 |
| 20050218215 | Lauden | Oct 2005 | A1 |
| 20050221268 | Chaar et al. | Oct 2005 | A1 |
| 20050240522 | Kranzley et al. | Oct 2005 | A1 |
| 20050268107 | Harris et al. | Dec 2005 | A1 |
| 20050268326 | Bhargavan et al. | Dec 2005 | A1 |
| 20060021018 | Hinton et al. | Jan 2006 | A1 |
| 20060024269 | Doyle et al. | Feb 2006 | A1 |
| 20060026304 | Price | Feb 2006 | A1 |
| 20060031938 | Choi | Feb 2006 | A1 |
| 20060059569 | Dasgupta et al. | Mar 2006 | A1 |
| 20060075475 | Boulos et al. | Apr 2006 | A1 |
| 20060130139 | Sobel et al. | Jun 2006 | A1 |
| 20060165060 | Dua | Jul 2006 | A1 |
| 20060182276 | Sandhu et al. | Aug 2006 | A1 |
| 20060184787 | Sandhu et al. | Aug 2006 | A1 |
| 20060184788 | Sandhu et al. | Aug 2006 | A1 |
| 20060242692 | Thione et al. | Oct 2006 | A1 |
| 20070016948 | Dubrovsky et al. | Jan 2007 | A1 |
| 20070027961 | Holzer | Feb 2007 | A1 |
| 20070033148 | Cahill | Feb 2007 | A1 |
| 20070081667 | Hwang | Apr 2007 | A1 |
| 20070101145 | Sachdeva et al. | May 2007 | A1 |
| 20070143860 | Hardt | Jun 2007 | A1 |
| 20070156592 | Henderson | Jul 2007 | A1 |
| 20070156659 | Lim | Jul 2007 | A1 |
| 20070185978 | Montulli | Aug 2007 | A1 |
| 20070186106 | Ting et al. | Aug 2007 | A1 |
| 20070199060 | Touboul | Aug 2007 | A1 |
| 20070204016 | Kunz et al. | Aug 2007 | A1 |
| 20070228148 | Rable | Oct 2007 | A1 |
| 20070250914 | Fazal et al. | Oct 2007 | A1 |
| 20070254631 | Spooner | Nov 2007 | A1 |
| 20070258594 | Sandhu et al. | Nov 2007 | A1 |
| 20070284429 | Beeman | Dec 2007 | A1 |
| 20070297607 | Ogura et al. | Dec 2007 | A1 |
| 20080004964 | Messa et al. | Jan 2008 | A1 |
| 20080010665 | Hinton et al. | Jan 2008 | A1 |
| 20080012041 | Kesler | Jan 2008 | A1 |
| 20080034413 | He et al. | Feb 2008 | A1 |
| 20080049642 | Gudipudi et al. | Feb 2008 | A1 |
| 20080059804 | Shah et al. | Mar 2008 | A1 |
| 20080069347 | Brown et al. | Mar 2008 | A1 |
| 20080120411 | Eberle | May 2008 | A1 |
| 20080134311 | Medvinsky et al. | Jun 2008 | A1 |
| 20080201186 | Poon et al. | Aug 2008 | A1 |
| 20080229104 | Ju et al. | Sep 2008 | A1 |
| 20080301669 | Rao et al. | Dec 2008 | A1 |
| 20090055906 | Von | Feb 2009 | A1 |
| 20090077060 | Sermersheim et al. | Mar 2009 | A1 |
| 20090083225 | Jacobs et al. | Mar 2009 | A1 |
| 20090167489 | Nan et al. | Jul 2009 | A1 |
| 20090187986 | Ozeki | Jul 2009 | A1 |
| 20090198997 | Yeap et al. | Aug 2009 | A1 |
| 20090210705 | Chen | Aug 2009 | A1 |
| 20090254978 | Rouskov et al. | Oct 2009 | A1 |
| 20090259848 | Williams et al. | Oct 2009 | A1 |
| 20090271863 | Govindavajhala et al. | Oct 2009 | A1 |
| 20090300596 | Tyhurst et al. | Dec 2009 | A1 |
| 20090300707 | Garimella et al. | Dec 2009 | A1 |
| 20090328178 | McDaniel et al. | Dec 2009 | A1 |
| 20100002378 | Chen et al. | Jan 2010 | A1 |
| 20100011433 | Harrison et al. | Jan 2010 | A1 |
| 20100018000 | Hsu | Jan 2010 | A1 |
| 20100023781 | Nakamoto | Jan 2010 | A1 |
| 20100026302 | Doty et al. | Feb 2010 | A1 |
| 20100036931 | Certain et al. | Feb 2010 | A1 |
| 20100042954 | Rosenblatt et al. | Feb 2010 | A1 |
| 20100069104 | Neil et al. | Mar 2010 | A1 |
| 20100100725 | Ozzie et al. | Apr 2010 | A1 |
| 20100100924 | Hinton | Apr 2010 | A1 |
| 20100107225 | Spencer et al. | Apr 2010 | A1 |
| 20100114740 | Dominguez et al. | May 2010 | A1 |
| 20100115578 | Nice et al. | May 2010 | A1 |
| 20100121767 | Coulter et al. | May 2010 | A1 |
| 20100125737 | Kang | May 2010 | A1 |
| 20100131755 | Zhu et al. | May 2010 | A1 |
| 20100180001 | Hardt | Jul 2010 | A1 |
| 20100186082 | Ladki et al. | Jul 2010 | A1 |
| 20100202609 | Sandhu et al. | Aug 2010 | A1 |
| 20100216425 | Smith | Aug 2010 | A1 |
| 20100217986 | Schneider | Aug 2010 | A1 |
| 20100233996 | Herz et al. | Sep 2010 | A1 |
| 20100257610 | Hohl | Oct 2010 | A1 |
| 20100263021 | Arnott et al. | Oct 2010 | A1 |
| 20100274859 | Bucuk | Oct 2010 | A1 |
| 20100319068 | Abbadessa et al. | Dec 2010 | A1 |
| 20100330969 | Kim et al. | Dec 2010 | A1 |
| 20110026716 | Tang et al. | Feb 2011 | A1 |
| 20110055903 | Leggette | Mar 2011 | A1 |
| 20110086616 | Brand et al. | Apr 2011 | A1 |
| 20110107389 | Chakarapani | May 2011 | A1 |
| 20110113484 | Zeuthen | May 2011 | A1 |
| 20110119765 | Hering et al. | May 2011 | A1 |
| 20110138469 | Ye et al. | Jun 2011 | A1 |
| 20110145900 | Chern | Jun 2011 | A1 |
| 20110179472 | Ganesan | Jul 2011 | A1 |
| 20110197266 | Chu et al. | Aug 2011 | A1 |
| 20110197267 | Gravel et al. | Aug 2011 | A1 |
| 20110219449 | St et al. | Sep 2011 | A1 |
| 20110225637 | Counterman | Sep 2011 | A1 |
| 20110231265 | Brown et al. | Sep 2011 | A1 |
| 20110277025 | Counterman | Nov 2011 | A1 |
| 20110282908 | Fly et al. | Nov 2011 | A1 |
| 20110302410 | Clarke et al. | Dec 2011 | A1 |
| 20110302630 | Nair et al. | Dec 2011 | A1 |
| 20120029084 | Wong | Feb 2012 | A1 |
| 20120030093 | Farias | Feb 2012 | A1 |
| 20120060360 | Liu | Mar 2012 | A1 |
| 20120063601 | Hart | Mar 2012 | A1 |
| 20120090028 | Lapsley et al. | Apr 2012 | A1 |
| 20120096274 | Campagna et al. | Apr 2012 | A1 |
| 20120117229 | Van et al. | May 2012 | A1 |
| 20120117626 | Yates et al. | May 2012 | A1 |
| 20120151567 | Chayanam et al. | Jun 2012 | A1 |
| 20120159600 | Takagi | Jun 2012 | A1 |
| 20120198050 | Maki et al. | Aug 2012 | A1 |
| 20120198228 | Oberheide et al. | Aug 2012 | A1 |
| 20120216239 | Yadav et al. | Aug 2012 | A1 |
| 20120227098 | Obasanjo et al. | Sep 2012 | A1 |
| 20120254957 | Fork et al. | Oct 2012 | A1 |
| 20120278454 | Stewart et al. | Nov 2012 | A1 |
| 20120290841 | Jentzsch | Nov 2012 | A1 |
| 20120300931 | Ollikainen et al. | Nov 2012 | A1 |
| 20120317287 | Amitai et al. | Dec 2012 | A1 |
| 20120321086 | D'Souza et al. | Dec 2012 | A1 |
| 20130004200 | Okabe | Jan 2013 | A1 |
| 20130008110 | Rothwell | Jan 2013 | A1 |
| 20130012429 | Eddowes et al. | Jan 2013 | A1 |
| 20130017968 | Gurtner et al. | Jan 2013 | A1 |
| 20130024628 | Benhase et al. | Jan 2013 | A1 |
| 20130042002 | Cheeniyil et al. | Feb 2013 | A1 |
| 20130055233 | Hatton et al. | Feb 2013 | A1 |
| 20130055247 | Hiltgen et al. | Feb 2013 | A1 |
| 20130060708 | Oskolkov et al. | Mar 2013 | A1 |
| 20130067538 | Dharmarajan et al. | Mar 2013 | A1 |
| 20130074061 | Averbuch et al. | Mar 2013 | A1 |
| 20130074601 | Jackson | Mar 2013 | A1 |
| 20130081101 | Baer et al. | Mar 2013 | A1 |
| 20130086210 | Yiu et al. | Apr 2013 | A1 |
| 20130086658 | Kottahachchi et al. | Apr 2013 | A1 |
| 20130091544 | Oberheide et al. | Apr 2013 | A1 |
| 20130097585 | Jentsch et al. | Apr 2013 | A1 |
| 20130110676 | Kobres | May 2013 | A1 |
| 20130117826 | Gordon et al. | May 2013 | A1 |
| 20130124292 | Juthani | May 2013 | A1 |
| 20130125226 | Shah et al. | May 2013 | A1 |
| 20130174246 | Schrecker et al. | Jul 2013 | A1 |
| 20130179681 | Benson et al. | Jul 2013 | A1 |
| 20130239167 | Sreenivas et al. | Sep 2013 | A1 |
| 20130239168 | Sreenivas et al. | Sep 2013 | A1 |
| 20130239177 | Sigurdson et al. | Sep 2013 | A1 |
| 20130246281 | Yamada et al. | Sep 2013 | A1 |
| 20130263211 | Neuman et al. | Oct 2013 | A1 |
| 20130276142 | Peddada | Oct 2013 | A1 |
| 20130310006 | Chen et al. | Nov 2013 | A1 |
| 20130311776 | Besehanic | Nov 2013 | A1 |
| 20130326224 | Yavuz | Dec 2013 | A1 |
| 20130326493 | Poonamalli et al. | Dec 2013 | A1 |
| 20140001975 | Lee et al. | Jan 2014 | A1 |
| 20140019752 | Yin et al. | Jan 2014 | A1 |
| 20140020051 | Lu et al. | Jan 2014 | A1 |
| 20140020184 | Loth | Jan 2014 | A1 |
| 20140047546 | Sidagni | Feb 2014 | A1 |
| 20140181517 | Alaranta et al. | Jun 2014 | A1 |
| 20140181520 | Wendling et al. | Jun 2014 | A1 |
| 20140188796 | Fushman et al. | Jul 2014 | A1 |
| 20140201841 | Deshpande et al. | Jul 2014 | A1 |
| 20140208405 | Hashai | Jul 2014 | A1 |
| 20140235230 | Raleigh | Aug 2014 | A1 |
| 20140237236 | Kalinichenko et al. | Aug 2014 | A1 |
| 20140244993 | Chew | Aug 2014 | A1 |
| 20140245278 | Zellen | Aug 2014 | A1 |
| 20140245396 | Oberheide | Aug 2014 | A1 |
| 20140247140 | Proud | Sep 2014 | A1 |
| 20140297840 | Qureshi | Oct 2014 | A1 |
| 20140310415 | Kirner et al. | Oct 2014 | A1 |
| 20140351954 | Brownell et al. | Nov 2014 | A1 |
| 20140376543 | Malatack et al. | Dec 2014 | A1 |
| 20150002646 | Namii | Jan 2015 | A1 |
| 20150012914 | Klein et al. | Jan 2015 | A1 |
| 20150026461 | Devi | Jan 2015 | A1 |
| 20150172321 | Kirti et al. | Jun 2015 | A1 |
| 20150213268 | Nance et al. | Jul 2015 | A1 |
| 20150237026 | Kumar | Aug 2015 | A1 |
| 20150242643 | Hankins et al. | Aug 2015 | A1 |
| 20150312233 | Graham et al. | Oct 2015 | A1 |
| 20150381662 | Nair et al. | Dec 2015 | A1 |
| 20160005696 | Tomohiro | Jan 2016 | A1 |
| 20160018007 | Eckholz | Jan 2016 | A1 |
| 20160021117 | Harmon et al. | Jan 2016 | A1 |
| 20160028639 | Wong et al. | Jan 2016 | A1 |
| 20160030023 | Hayakawa et al. | Feb 2016 | A1 |
| 20160056962 | Mehtälä | Feb 2016 | A1 |
| 20160080366 | Agarwal | Mar 2016 | A1 |
| 20160099963 | Mahaffey et al. | Apr 2016 | A1 |
| 20160164866 | Oberheide et al. | Jun 2016 | A1 |
| 20160180072 | Ligatti et al. | Jun 2016 | A1 |
| 20160180343 | Poon et al. | Jun 2016 | A1 |
| 20160212129 | Johnston et al. | Jul 2016 | A1 |
| 20160286391 | Khan | Sep 2016 | A1 |
| 20160300231 | Shavell et al. | Oct 2016 | A1 |
| 20160366589 | Jean | Dec 2016 | A1 |
| 20170039242 | Milton et al. | Feb 2017 | A1 |
| 20170169066 | Mantri et al. | Jun 2017 | A1 |
| 20170214701 | Hasan | Jul 2017 | A1 |
| 20180027006 | Zimmermann et al. | Jan 2018 | A1 |
| 20180205726 | Chari et al. | Jul 2018 | A1 |
| 20190334921 | Pattar | Oct 2019 | A1 |
| Number | Date | Country |
|---|---|---|
| 2639997 | Sep 2014 | EP |
| 2007075850 | Jul 2007 | WO |
| 2014150073 | Sep 2014 | WO |
| Entry |
|---|
| Aloul S Zahidi; et al. “Two factor authentication using mobile phones,” 2009 IEEE/ACS International Conference on Computer Systems and Applications, Rabat, 2009, pp. 641-644., Feb. 6, 2018 00:00:00.0. |
| Bonneau Joseph; et al. “Passwords and the evolution of imperfect authentication.” Communications of the ACM 58.7 (2015): 78-87., Feb. 6, 2018 00:00:00.0. |
| Edge, Kenneth, et al. “The use of attack and protection trees to analyze security for an online banking system.” System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on. IEEE, 2007. |
| Goldfeder et al., Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme, http://www.cs.princeton.edu/˜stevenag/threshold_sigs.pdf. |
| Kher Vishal; et al. “Securing distributed storage: challenges, techniques and systems.” Proceedings of the 2005 ACM workshop on Storage security and survivability. ACM, 2005, pp. 9-25., Feb. 6, 2018 00:00:00.0. |
| Neuenhofen, Kay, and Mathew Thompson. “A secure marketplace for mobile java agents.” Proceeding of the second international Conference on Autonomous agents. ACM, 1998. (pp. 212-218). |
| Simske et al., “APEX: Automated Policy Enforcement exchange”, Sep. 21-24, 2010, ACM, pp. 139-142. |
| “Symantec, Administration guide for Symantec Endpoint protection and Symantec network access control, 2009, version 11.00.05.00.00”. |
| “Symantec, Administration Guide for Symantec TM Endpoint Protection and Symantec Network Access Control, Aug. 1, 2007”. |
| Number | Date | Country | |
|---|---|---|---|
| 20200186520 A1 | Jun 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62776641 | Dec 2018 | US |
