DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 12/23/2025. Claims 1, 8, and 15 are amended. Claims 3, 5-6, 10, 12-13, 17, and 19 are cancelled. Claims 1-2, 4, 7-9, 11, 14-16, 18, and 20 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 18/116,400.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Response to Argument
Applicant’s arguments with respect to claims 1, 8, and 15 for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 7-9, 11, 14-16, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable (US2021/0097166) issued to Arora, and further in view of US Patent No. (US2021/0164860)) issued to Young, and further in view of US Patent No. (US2022/028160)) issued to Patel, and further in view of Le Van Gong (US20190306132).
Regarding claim 1 Arora discloses a system for generation of authentication tokens, the system comprising: a memory device with computer-readable program code stored thereon; a communication device; a processing device operatively coupled to the memory device and the communication device, wherein the processing device is configured to execute the computer-readable program code to [see Figs 1, and 2, and corresponding text for more details]; and
receive, from a user device associated with a user, a first data transmission, wherein the first data transmission comprises one or more first datasets associated with the user, and wherein the one or more first datasets comprise a physical dataset associated with the user [0071] At step S214, the user 202 can provide a biometric instance to the communication device 204. For example, the user 202 can use a camera on communication device 204 in order to collect a face scan, iris scan or retina scan. Alternatively, the user 202 can use a microphone on communication device 204 in order to capture a voice recording, or a touch screen on communication device 204 in order to capture a handwriting sample. The communication device 204 may generate a biometric instance, and then a biometric template, and may then securely store the biometric template on a secure memory element.[0093] At step S236, public device 206 can collect from user 202, a first biometric instance corresponding to user 202. The biometric instance can be transformed into a biometric instance, which may in turn be transformed into a first biometric template. The first biometric template may comprise data based on a fingerprint scan, a face scan, an iris scan, a retina scan, a DNA sample, a hand-written signature, and/or a voice recording, or any other biometric data. The public device 206 may collect the first biometric instance using any appropriate biometric interface. For example, the public device 206 may capture an iris scan of the user using a camera attached to public device 206. The public device 206 may store the first biometric template in temporary memory]; and
apply an encryption algorithm to each first dataset to generate an encrypted dataset [0023-0024] A “fuzzy vault” or “fuzzy vault scheme” can be a method of providing secure authentication based on fuzzy matching of sets. A fuzzy vault can be an encryption scheme which leverages some of the concepts of error correction codes, to encode information in such a way as to be difficult to obtain without the ‘key’ used to encode it, even if the methods used for encoding are publicly known…. A “data vault” may be a secure encoding of data. Data in a data vault may be secured in a form, such that the data can only be obtained with a correct key. A data vault may be encrypted data, and in some embodiments, the data vault may be formed using a fuzzy vault scheme], and [0083] At step S230, communication device 204 can generate a data vault using a fuzzy vault method/technique by locking the interaction token using a biometric template corresponding to user 202. In other embodiments, the communication device 204 can generate a data vault using a fuzzy vault method/technique by locking a master secret key that is generated to encrypt the interaction token. The biometric template can be based off the biometric instance or sample collected from user 202 at step S214. The data vault can be transferred to public device 206 and used by the user 202 to perform biometric authentication and interactions (e.g., transactions) using public device 206]; and
configure the encrypted dataset into an authentication token [0008] Embodiments are directed to a delegated biometric authentication system and related methods. Embodiments allow users to use public devices for biometric authentication without compromising user security and privacy. In doing so, sensitive biometric information (e.g., biometric templates) and interaction tokens (e.g., payment tokens, including limited use or limited time tokens) are protected without sacrificing user convenience], and [0036] An “interaction token” may include any substitute value for a real credential that can be used in an interaction. A token may be a type of credential, and may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, personal identification tokens, etc.], and . A data vault formed using a fuzzy vault scheme can lock an interaction token or a master secret key used to encrypt the interaction token using a biometric template corresponding to the user], and [0083] At step S230, communication device 204 can generate a data vault using a fuzzy vault method/technique by locking the interaction token using a biometric template corresponding to user 202. In other embodiments, the communication device 204 can generate a data vault using a fuzzy vault method/technique by locking a master secret key that is generated to encrypt the interaction token. The biometric template can be based off the biometric instance or sample collected from user 202 at step S214. The data vault can be transferred to public device 206 and used by the user 202 to perform biometric authentication and interactions (e.g., transactions) using public device 206]; and
transfer the authentication token to one or more entity systems, wherein the authentication token comprises a licensing layer identifying a predetermined period of time during which the one or more entity systems has access to the authentication token [0008] Embodiments are directed to a delegated biometric authentication system and related methods. Embodiments allow users to use public devices for biometric authentication without compromising user security and privacy. In doing so, sensitive biometric information (e.g., biometric templates) and interaction tokens (e.g., payment tokens, including limited use or limited time tokens) are protected without sacrificing user convenience], and [0068] The token server computer 114 may comprise a server computer associated with tokenization services. Token server computer 114 may generate, manage, and distribute interaction tokens that may be used to conduct interactions with resource providers 108. Interaction tokens may comprise, for example, numeric or alphanumeric sequences, such as “4000 1234 5678 9000.” Interaction tokens may be subject to any number of limitations assigned and/or enforced by token server computer 114. For example, token server computer 114 may generate limited use tokens, which may be valid for a limited number of interactions (e.g., three interactions). Additionally, token server computer 114 may generate limited time tokens, which may be valid only during a specific time period (e.g., within one week of generation). Further, token server computer 114 may generate limited amount tokens, which may be valid provided a certain amount of something is not exceeded (e.g., for transactions, a limited amount token may correspond to an amount of money, such as $100.00. The limited amount token may be valid provided that less than $100.00 is spent over the course of one or more transactions)]; and
receive , a second data transmission, wherein the second data transmission comprises a request to access a resource, and a second physical dataset associated with the user and wherein the second data transmission is received via a short-range communication channel between a user access card and an entity device [0026-0027] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer. A “biometrics instance” may include information related to a biological observation. A biometric instance may include biometric data corresponding to a biometric sample. A “biometric template” may be derived from the biometric instance. A biometric instance may be captured via a “biometric interface,” hardware used to capture biometric instances. For example, a biometric instance may be captured via a biometric interface such as an iris scanner, comprising an infrared light source and a camera. Examples of biometric instances include digital representations of iris scans (e.g., binary codes that represent an iris), fingerprints, voice recordings, face scans, etc.], and [0034] A “credential” may include any suitable information that serves as reliable evidence of worth, ownership, identity or authority. An “access credential” may be a credential that may be used to gain access to a particular resource (e.g., a good, service, location, etc.). A credential may be a string of numbers, letters, or any other suitable characters, or any object or document that can serve as confirmation. Examples of credentials include identification cards, certified documents, access cards, passcodes and other login information, payment account numbers, access badge numbers, payment tokens, access tokens, etc.], and [0060] Further, in order to conduct these interactions using public device 104, public device 104 can authenticate the user 102 using biometrics, that is, verify the user's 102 identity using one or more biometrics corresponding to the user 102 (e.g., an iris scan, retina scan, face scan, fingerprint, etc.). This provides additional security to user 102 by making it more difficult for malicious users or fraudsters to impersonate user 102.], and [ [0063] Public device 104 may comprise an Internet of Things (IoT) or other smart device capable of communicating with other devices via networks such as the Internet. Public device 104 may additionally communicate with devices using other means. For example, public device 104 may communicate with communication device 106 via Bluetooth or NFC. Public device 104 may exist in a public or shared space, such as a hotel room, library, restaurant, bank, grocery store, etc.], and [0072, , the user 202 may connect communication device 204 to public device 206 via near field communication, i.e., by bringing communication device 204 in close proximity with a near-field communication element on public device 206. Alternatively, communication device 204 may connect to public device 206 via Bluetooth, Zigbee, Wi-Fi, or any other appropriate networking or communication means. ],and [0020, 0031, 0090].
Arora does not explicitly disclose, however, Young discloses receive, from at least one of the managing entity system, the user device, and the one or more entity systems, instructions to recall the authentication token from the managing entity system, the user device, or the one or more entity systems [¶41, The authentication module 240 is configured to monitor and authenticate data communications between the back-end system 110 and other devices within the water monitoring system 100. For example, the authentication module 240 is configured to provide an access token for each session between back-end system 110 and local system 120, back-end system 110 and client device 130, and back-end system 110 and third-party system 140. The back-end system 110 stores information about the user P, including information which identifies the local system 120, client device 130, and any third-party accounts associated with the user P. The authentication module 240 is configured to store and recall a unique token to distinguish each device upon communication with the back-end system 110, thereby associating multiple devices with a single user P and enabling the back-end system 110 to distinguish between them].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Arora by incorporating “unique token for each device”, as taught by Young. One could have been motivated to do so in order for the authentication module to store and recall a unique token to distinguish each device upon communication with the back-end system, hereby associating multiple devices with a single user P and enabling the back-end system to distinguish between them [ Young, ¶41].
Arora, and Yong do not explicitly disclose, however, Patel discloses and revoke access of the authentication token from the managing entity system, the user device, or the one or more entity systems [¶2, When a client device makes a request for a particular service from a server system, it may provide an authentication token to the server system along with the request. The client device may obtain the authentication token from an authentication service by providing valid credentials—for example, a username and password—to the authentication service. In order to protect the security of the information and resources of the server system, the server system may verify the validity of the authentication token with the authentication service before accessing the resource. The validation is performed because the authentication service may revoke a previously granted authentication token at any time], and [0019] Authentication tokens are typically valid for a specified period of time (in some systems, a typical period of validity is a couple of hours) in order to reduce the potential exposure that can occur if an unauthorized actor obtains an authentication token. When this period of time ends, the token is said to “expire.” Prior to this time of expiration, a token may be “revoked.” Revocation allows the system to react to potential security events such as suspension of a user's credentials. Note that an authentication service may revoke a previously granted authentication token at any time, in a manner that may not be predictable for either the clients or the server system.], and [¶27, As illustrated in FIG. 1, a user of the client device 110 sends an authentication token request 101 to the authentication service 160. The authentication service 160, subsequent to verifying user credentials presented by the user of the client device 110, responds to the client device 110 with an authentication token grant 102. Note that the authentication token has some expiration period during which the authentication token is valid (although the token may be revoked before the expiration period)], and [¶¶19, 28-30].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Arora, and Young by incorporating “a previously granted authentication token revocation”, as taught by Patel. One could have been motivated to do so in order for the authentication tokens which are typically valid for a specified period of time to reduce the potential exposure that can occur if an unauthorized actor obtains an authentication token. When this period of time ends, the token is said to “expire.” Prior to this time of expiration, a token may be “revoked.” Revocation allows the system to react to potential security events such as suspension of a user's credentials and note that an authentication service may revoke a previously granted authentication token at any time [Patel ¶¶19, 27-31].
Arora, and Yong, and Patel do not explicitly disclose, however Le Van Gong discloses,
wherein the encryption algorithm is selected from a plurality of rotating encryption algorithms [¶14, To further enhance security, a rotating keys mechanism may be adopted for the encrypted communication session. The rotating keys mechanism provides, in various embodiments, that different encryption keys may be used to encrypt the records or data transmitted between the two devices during different time periods of the session. In particular, each of the two devices may negotiate a key rotation scheme before establishing the encrypted communication session, and each device may use the key rotation scheme to periodically generate new encryption keys throughout the encrypted communication session such that one encryption key may be used for encrypting records or data transmitted-during a first period of time and a different encryption key may be used for encrypting records or data transmitted during a second period of time. Rotation of keys can increase the difficulty for an unauthorized party to breach encryption by ensuring that only limited amounts of records or data are encrypted using particular keys, for example].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Arora, and Yong, and Patel by incorporating “rotating keys mechanism”, as taught by Le Van Gong. One could have been motivated to do so in order to increase the difficulty for an unauthorized party to breach encryption by ensuring that only limited amounts of records or data are encrypted using particular keys [ Le Van Gong, ¶14].
Regarding claim 2, Arora discloses wherein the processing device is further configured to execute the computer-readable program code to [see Figs 1, and 2, and corresponding text for more details]; and
detect, based on monitoring an application of the user device, a request for resource access between the one or more entity systems and at least one of the user device and the managing entity system [see Figs 1, and 2, and corresponding text for more details]; and[0028-0030] A “resource provider” may include any entity that can provide resources such as goods, services, information and/or access. Examples of resource providers include merchants, governmental entities, entities that provide access to secure locations, data access providers, etc. A “merchant” may be an entity that engages in transactions and can sell goods or services or provide access to goods or services. An “acquirer” may include a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer. ”An “authorizing entity” may include any entity that authorizes a request. Examples of an authorization entities may include issuers, governmental agencies, document repositories, access administrators, etc. An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a mobile device, such as a cellular telephone, smart cart card, tablet, or laptop to the consumer. An authorizing entity may operate an authorization computer], and[0065] Resource providers 108 may comprise one or more resource providers that provide resources to users as part of interactions. These resource providers can include, for example, businesses, governments, and non-profit organizations. Examples of resource providers include merchants that provide goods or services to customers, libraries that lend books to borrowers, building managers that allow access to buildings, broadcasting companies that allow access to broadcast content, etc.], and [0059]; and
cause the at least one of the user device and the managing entity system to transmit a user dataset stored at the at least one of the user device and the managing entity system to the one or more entity systems[see Figs 1, and 2, and corresponding text for more details]; and [0071-0074] At step S214, the user 202 can provide a biometric instance to the communication device 204. For example, the user 202 can use a camera on communication device 204 in order to collect a face scan, iris scan or retina scan. Alternatively, the user 202 can use a microphone on communication device 204 in order to capture a voice recording, or a touch screen on communication device 204 in order to capture a handwriting sample. The communication device 204 may generate a biometric instance, and then a biometric template, and may then securely store the biometric template on a secure memory element… At step S218, the public device 206 can transmit a validation request message to authentication server computer 208. The validation request message can indicate to authentication server computer 208 that communication device 204 is attempting to delegate biometric authentication to public device 206. The validation request message can further indicate that the public device 206 wants to validate communication device 204 and the delegation request. The validation request message may comprise a communication device identifier and/or a user identifier used to identify communication device 204. The authentication server computer 208 may maintain a registry of users or communication devices (including user 202 and communication device 204) that are registered or enrolled in a biometric authentication program. User 202 may have previously enrolled communication device 204 in this program. Authentication server computer 208 may verify that communication device 204 is enrolled or registered using a communication device identifier, user identifier, or other appropriate identifier contained in the validation request message]; and
cause the one or more entity systems to verify that the transmitted user dataset matches the authentication token transferred to the one or more third party systems ;and cause the one or more entity systems to authorize the request for resource access [0060] Further, in order to conduct these interactions using public device 104, public device 104 can authenticate the user 102 using biometrics, that is, verify the user's 102 identity using one or more biometrics corresponding to the user 102 (e.g., an iris scan, retina scan, face scan, fingerprint, etc.). This provides additional security to user 102 by making it more difficult for malicious users or fraudsters to impersonate user 102. Additionally, biometric authentication may provide improved convenience to user 102, as they may be able to conduct interactions without devices typically associated with those interactions, for example, conduct a transaction without using a credit card or borrow a library book without a library card], and [0067-0068] Authentication server computer 112 may comprise a server computer that can validate user 102 and communication device 106. It can also verify biometric delegation. The authentication server computer 112 may store or otherwise manage a list or registry of users or communication devices enrolled in a biometric authentication system. User 102 may have enrolled communication device 106 in the biometric authentication system at some point in the past. In some embodiments, enrollment with authentication server computer 112 may be a pre-requisite for using system 100 for performing delegated biometric authentication. The authentication server computer 112 may use a list or registry of users in order to verify that user 102 is legitimate (e.g., is not being impersonated by a fraudster). Authentication server computer 112 may communicate with a token server computer 114 in order to provision an interaction token (or other access data) to communication device 106. These interaction tokens (or other access data) may subsequently be locked by communication device 106 in a data vault. The token server computer 114 may comprise a server computer associated with tokenization services. Token server computer 114 may generate, manage, and distribute interaction tokens that may be used to conduct interactions with resource providers 108], and [0073-0074] At step S218, the public device 206 can transmit a validation request message to authentication server computer 208. The validation request message can indicate to authentication server computer 208 that communication device 204 is attempting to delegate biometric authentication to public device 206. The validation request message can further indicate that the public device 206 wants to validate communication device 204 and the delegation request. The validation request message may comprise a communication device identifier and/or a user identifier used to identify communication device 204. The authentication server computer 208 may maintain a registry of users or communication devices (including user 202 and communication device 204) that are registered or enrolled in a biometric authentication program. User 202 may have previously enrolled communication device 204 in this program. Authentication server computer 208 may verify that communication device 204 is enrolled or registered using a communication device identifier, user identifier, or other appropriate identifier contained in the validation request message].
Regarding claim 4, Arora discloses wherein the processing device is further configured to execute the computer-readable program code to: receive, from at least one of the managing entity system, the user device, and the one or more entity systems, instructions to enable access of the authentication token to the managing entity system, the user device, or the one or more entity systems; and enable access of the authentication token to the managing entity system, the user device, or the one or more entity systems
[see Figs 1, and 2, and corresponding text for more details].
Regarding claim 7, Arora discloses wherein the user device is associated with a first distributed computing system and wherein the resource is stored in a second distributed computing system [see Figs 1, and 2, and corresponding text for more details].
Regarding claims 8, and 15, these claims are interpreted and rejected for the same rational set forth in claim 1.
Regarding claims 9, and 16, these claims are interpreted and rejected for the same rational set forth in claim 2.
Regarding claims 11, and 18, these claims are interpreted and rejected for the same rational set forth in claim 4.
Regarding claims 14, and 20, these claims are interpreted and rejected for the same rational set forth in claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Feekes (US2015/0117639) [0025] In accordance with one embodiment, the Receiving Device 104 randomly selects an encryption algorithm from the EA table, at block 306. Then, the Receiving Device 104 returns an SAI to the Transmitting Device 102, at block 308. The SAI is then employed by the Transmitting Device 102, at block 310, to select the encryption scheme to be employed with regard to subsequent data encryption going forward. The encryption scheme selected by the Transmitting Device 102 may be employed for either a fixed or variable amount of time. Then, at decision block 312, a determination is made regarding whether to change which encryption algorithm is being used to encrypt data. In this regard and in accordance with one embodiment, the Transmitting Device 102 can, at any point, issue a new encryption algorithm key set to change encryption algorithms. The attributes regarding when to rotate between encryption algorithms are defined in the encryption scheme. In instances when the result of the test at decision block 312 is "YES", the Receiving Device 104 then selects, at block 314, the encryption algorithm that will be employed for the subsequent window. This process of changing encryption algorithms continues until the communication session terminates at block 316.
Peddada (US2019/0340251) [ 0028] In some cases, data center 120 may include one or more databases that support encryption at rest for stored data records or data objects. A cloud client 105 (e.g., a tenant or customer) may select an encryption policy for data stored in the database for that cloud client 105. For example, in some cases, the cloud client 105 may select specific data records or data record types to be stored as plaintext or ciphertext, select an encryption key or key management policy (e.g., specifying a key rotation policy indicating one or more triggers or periodicities for rotating the encryption key), or select an encryption scheme (e.g., probabilistic encryption, deterministic encryption, etc.). Additionally, or alternatively, each database in the data center 120 may use a respective database-specific encryption key for encrypting and securely storing data records (e.g., across all tenants of that database). To enhance security, these database-specific keys may remain internal (i.e., local) to the database or to an associated database server and, as such, each database may not be able to determine the respective database-specific encryption keys for the other databases in the data center 120.
Levin (US10587406) [ 21) FIG. 2 is a diagram in which various aspects of a key rotation scheme and file system encryption are illustrated in accordance with an embodiment. As described above, key rotation may involve replacing keys with other keys to prevent security threats such as the collection of enough decrypted data to allow practical cracking of a cipher used. Various embodiments of the present disclosure allow for enhanced security of encrypted file systems 204 and/or logical storage volumes in connection with key rotation regimes. Accordingly, FIG. 2 illustrates key rotation and re-encryption of data in accordance with an embodiment. The key rotation scheme may be performed by a key rotation described above or any system configured with privileges to cause key rotation, which may be the same system (e.g., same device) that utilizes the cryptographic key(s) to perform cryptographic operations or a separate system (e.g., not the same device).
Luykx (US2021/0351924) [ [0018] A “key rotation period” can include repeating interval at which a first cryptographic key may be rotated for a second cryptographic key. A key rotation period may include an amount of time a cryptographic key may be used before being replaced by another cryptographic key. For example, a key rotation period may be a time of 1 day for a first cryptographic key. After 1 day of use of the first cryptographic key, a key management computer can replace the first cryptographic key with a second cryptographic key. In some embodiments, a key rotation period need not be time based. For example, a key rotation period may specify an encryption data limit for the first cryptographic key. For example, the key rotation period may be an encryption data limit of 2{circumflex over ( )}70 bits. After a key management computer uses a first cryptographic key to encrypt 2{circumflex over ( )}70 bits of data, the key management computer can begin utilizing a second cryptographic key. As another example, a key rotation period may specify a cipher call limit for the first cryptographic key. For example, the key rotation period may specify a cipher call limit for the first cryptographic key equal to, for example, 2{circumflex over ( )}63 calls. After the cipher calls have been made, then a key management computer can rotate to the next (e.g., second) cryptographic key.
Doraiswamy (US2021/0182863) [ ¶157, the issuing bank 107 revokes the authentication token T and reissues a new one periodically, for example, after a specified number of payment transactions, to reduce the window of time an attacker has to use a stolen authentication token T.
Douglas (US2024/0113882) [0001] Systems and methods are described herein for facilitating execution of an operation associated with a user over multiple communication networks. For example, there may be multiple authentication tokens associated with the user (e.g., tokens associated with multiple accounts for the user). When attempting to authenticate one of their user accounts at an external system, the user may not have suitable information available to recall the desired authentication token to be used or may have to review one or more of their authentication tokens in succession before eventually selecting the desired authentication token. Further, if a communication network associated with the selected authentication token is unavailable, the user may not be able to complete the operation. The user may not realize that the communication network is unavailable and attempt to use another authentication token associated with the same communication network. This may result in a low operation completion rate as the operation and others like it would remain uncompleted even after user effort to address the issue.
Nordstrom (US20160308858) (filed in IDS) [¶52, see FIG. 2, Computing device 201 and/or terminals 240 may also be mobile terminals (e.g., mobile phones, smartphones, personal digital assistants (PDAs), notebooks, etc.)], and [¶192, local communication network protocols having shorter communication ranges, such as Bluetooth or NFC, may be used for added security].
KR 101853705 B1 [When the application service apparatuses 200 provide a session creation request message based on the integrated ID information provided by the terminal 100 in which the specific application is activated, the single authentication service apparatus 300 transmits a single authentication token and a single authentication token and may provide the recall connection key to a specific application of the terminal 100. [ Then, the single authentication service apparatus 300 provides a single authentication cookie to the web browser of the terminal 100 to be accessed using the one-time access key and transmits the single authentication cookie to the application Can support the assignment of integrated service numbers. As a result, the single authentication service device 300 supports various applications based on the web browser of the terminal 100 to perform the automatic login function].
Doraiswamy (US2021/0182863) [ ¶157, the issuing bank 107 revokes the authentication token T and reissues a new one periodically, for example, after a specified number of payment transactions, to reduce the window of time an attacker has to use a stolen authentication token T.].
Dubeau (US2023/0014916) [ ¶23, the access rights defined via the API 121 are associated with expiration timers which, upon expiration, causes the access rights provided by the actor to be revoked. To revoke the access rights, the access rights system 120 may delete an authentication token associated with the access rights from the access rights smart contract].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496