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 .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 “ filed on November 13, 2025 in response to a non-final office action issued by the office on August 6, 2025.
Claims 1 – 22 are pending.
Claims 1, 13, and 18 are amended.
Claims 1 – 22 are rejected.
Response to Arguments
Applicant’s arguments filed on 11/13/2025 have been fully considered. The examiner here now responds to each argument. Underlined text indicates claim language that was amended since the last office action
In regard to claims 1, 13, 18, the applicant argues that the combination of Kukreja and Hunt fails to teach, anticipate, or suggest:
“requesting, by the client system of the network environment, a digital token from an authorization system separate from the client system and the computing device by authenticating with the authorization system using the authorization from the computing device;” (as recited in claim 1 and substantially replicated in claims 13 and 18)
“ receiving, by the client system of the network environment, the requested digital token from the authorization system;” (as recited in claim 1 and substantially replicated in claims 13 and 18)
“encrypting, by the client system of the network environment, the received digital token using an identification code for the computing device to form an encrypted digital token;” (as recited in claim 1 and substantially replicated in claims 13 and 18)
The applicant states in “Remarks” on pages 10 – 18 in response to the non-final rejection, that the obviousness rejection of the independent claims 1, 13, and 18 is not proper because the combination of Kukreja and Hunt does not teach in an ordered combination of said limitations shown above. Specifically, the applicant’s arguments are persuasive that the cited references fail to teach the claims are amended. Therein, said rejections are withdrawn. However a new search and consideration was performed and new grounds of rejection were found under 35 U.S.C. 103. The rejections are:
Claims 1 – 8, 10, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt).
Claims 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims 1 -8, 10, 13, 18, and 20 in further view of Tang et al. (U.S. 2021/0144010 A1; herein referred to as Tang).
Claims 11 – 12 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims 1 -8, 10, 13, 18, and 20 in further view of Kukreja et al. (U.S. 2020/0127994 A1; herein referred to as Kukreja).
Claims 14 – 16, 19, and 21 – 22 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims1 -8, 10, 13, 18, and 20 in further view of Grajek et al. (U.S. 2015/0244706 A1; herein referred to as Grajek).
Details of the rejections are described below.
As new prior art was introduced and the claims had minor amendments, the case is re-opened to allow the applicant to analyze the rejections and provide new amendments to the claims as necessary. The applicant is invited to contact the examiner and schedule an interview to discuss ways to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for securing the use of digital tokens (for example, access tokens or refresh tokens) in network environments (for example, in networks that include servers of a branded entity and a plurality of their customer's mobile devices). The claimed invention recites steps to: encrypting a digital token using an identification code for a computing device (for example, a symmetric encryption key that also serves to identify a designated mobile device) to form an encrypted digital token; assigning the encrypted digital token to the computing device; iii) transmitting the identification code to the computing device; and iv) expunging (for example, permanently deleting from volatile and/or non-volatile memory) the digital token and the identification code. The ordered combination of the elements and limitations bound the claimed invention to a specific and useful improvement to prevent the compromise of digital token stores that could result in unauthorized access to digital information, based on the discovery that each customer of a client entity can substantially mitigate the risk that the client entity's digital token store will be compromised by storing a token encryption key (for decrypting an encrypted digital token) as a non-public device identification code in secured memory of the customer's computing device. Token management operations based on this discovery allow the client entity expunge the token encryption key and an unencrypted digital token from its volatile and non-volatile memory, retaining only the customers' encrypted digital tokens (for example, in a database).
Claim Rejections - 35 USC § 103
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.
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.
Claim 1 – 8, 10, 13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt)
In regard to claim 1, Singh teaches A computer-implemented method for securing the use of a digital token (e.g. machine readable code) in a network environment (see abstract “. . . . A user may engage in a transaction with another user, such as a purchase of goods, services, or other items a merchant at a merchant location using machine-readable codes. A machine-readable code may be provided via a mobile device of a user. In order to provide faster and more efficient code generation, an interface widget or other tool may be provided, which, on selection, may execute API calls to a server of a transaction processor. The transaction processor may generate a code without requiring the user to go through a code generation and processing flow in a corresponding application. The code may be limited in validity and may be presented via the widget. Once scanned, the code may provide encoded data for a financial instrument. . . .”)
comprising:
requesting, by a client system of a network environment (see Fig. 1 Merchant device 130), authorization from a computing device (see Fig. 1 mobile device 110) separate from the client system for access to a protected resource (e.g. card data, account data, or other financial data) (see ¶¶ [0035-0036] “ . . . Merchant device 130 of FIG. 1 contains a sales application 132 and a network interface component 138. Sales application 132 may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, merchant device 130 may include additional or different software as required. Sales application 132 may correspond to one or more processes to execute software modules and associated components of mobile device 110 to process electronic transactions at a physical merchant location by a merchant associated with merchant device 130, as well as sending and receiving payments with a user associated with mobile device 110. In this regard, sales application 132 may correspond to specialized hardware and/or software utilized by the merchant of merchant device 130 to establish a transaction, for example, by requesting payment for a purchase of certain items or services at a physical location that may be scanned and/or entered to merchant device 130. At a physical merchant location, sales application 132 may designate the items for purchase or the user may bring items to a checkout, where merchant device 130 may request card data, account data, or other financial data to process the transaction. For example, the transaction data may be received via a checkout interface dynamically rendered through sales application 132 . . .”)
receiving, by the client system (see Fig. 1 Merchant device 130) of the network environment, authorization from the computing device (see Fig. 1 mobile device 110) for access to the protected resource (see ¶ [0037] “ . . . sales application 132 may receive the payment request from mobile device 110, which may be received through a digital payment platform. Sales application 132 may display information for the payment request, such as the amount required to be paid by mobile device 110 using QR codes 122. Thus, an interface of sales application 132 may include interface data and interface elements that allow for interaction with the payment request and/or viewing additional transaction data for a transaction associated with the payment request. During transaction processing, such as to provide a payment or transfer from the user's digital account and/or financial or funding instrument, sales application 132 may be utilized to enter and/or select payment instrument(s) for use in providing payment for a purchase, transfer, or other financial process. . . .”)
requesting, by the client system (see Fig. 1 Merchant device 130) of the network environment, a digital token (e.g. QR code 122) from an authorization system (see Fig. 1 Transaction Processor 140) separate from the client system (see Fig. 1 Merchant device 130) and the computing device (see Fig. 1 mobile device 110) (see ¶ [0027] “ . . . Payment application 112 may correspond to one or more processes to execute modules and associated devices of mobile device 110 to provide a convenient interface to permit a user for mobile device 110 to enter, view, and/or process items the user wishes to purchase in a transaction, as well as perform peer-to-peer payments and transfers on a payment platform provided by transaction processor 140. In this regard, payment application 112 may correspond to specialized hardware and/or software utilized by mobile device 110 that may provide transaction processing for the items, such as through a user interface enabling the user to enter and/or view the items that the user associated with mobile device 110 wishes to purchase. Payment application 112 may also be used by a first user to provide payments and transfers to a second user or merchant associated with merchant device 130 using a payment process 114. For example, payment application 112 may utilize user financial information, such as credit card data, bank account data, or other funding source data, as a payment instrument when providing payment information via payment process 114 . . .”) by authenticating with the authorization system (Transaction Processor 140) using the authorization from the computing device (e.g. mobile device 110) (see ¶ [0029] “ . . . Payment application 112 and/or an OS or other platform of mobile device 110 may provide code widget 120, which may be used to request and display QR codes 122 in a faster and more efficient manner than utilizing payment application 112 to request and display a machine-readable code and/or QR codes 122. Thus, code widget 120 may further enable the user associated with mobile device 110 to display an image, video (e.g., when a machine-readable code may be dynamic and/or animated), or otherwise scannable version of a machine-readable code that includes encoded an account identifiers, data, financial instruments, or the like to mobile device 130. Code widget 120 may be accessible via a home screen interface or other displayable interface of mobile device 110. When selected, code widget 120 may be used to execute one or more API calls to transaction processor 140, which requests generation of one or more of QR codes 122 displayable via an output component of mobile device 110. QR codes 122 may be displayable when code widget 120 is executing and/or in a foreground of an OS of mobile device 110. Code widget 120 may receive QR codes 122 from transaction processor 140, and may further display or otherwise present (e.g., based on the data provided by transaction processor 140) an application interface associated with a peer-to-peer payment or transfer using QR codes 122. The interface may include an option to enter an amount, send or request the amount, provide a message or graphical object, or otherwise converse and social network with merchant device 130 . . .”)
receiving, by the client system (merchant device 130) of the network environment, the requested digital token from the authorization system (transaction processor 140) (see ¶ [0036] “ . . . Sales application 132 may further provide one or more user interfaces to send and receive payments or transfers with the user associated with mobile device 110, for example, in response to merchant device 130 capturing QR codes 122 on mobile device 110 and transmitting a payment request to sales application 132 via transaction processor 140. . . “).
Singh fails to explicitly teach
However Beye teaches encrypting, by the client system (see Fig. 1 merchant user device 112) of the network environment, the received digital token using an identification code (e.g. reference identification code) for the computing device (see Fig. 1 user device 110) to form an encrypted digital token (see ¶ [0006] “ . . . Once the merchant and the user have established a desired or proposed exchange or transaction, the computing device of the merchant may transmit an exchange prompt requesting an exchange token to the computing device of the user comprising an exchange amount, details about the exchange (e.g., a bill of sale), and the like (e.g., including an encryption of at least a portion of the exchange prompt using a private key of the merchant), via a near field communication channel. The mobile device of the user receives, via the near field communication channel from the computing device of the merchant, the exchange prompt . . .”; see ¶ [0007] “ . . . Once the user has confirmed their desire to execute the exchange as prompted the managing entity application on the mobile device of the user may generate the exchange token using the exchange token structure consisting of a first encrypted envelope (i.e., encrypted by the user's resource public key) comprising at least (1) an exchange amount (i.e., from the remaining available user resources), (2) an exchange timestamp, (3) a time to live expiration arising out of the exchange timestamp, and (4) information from the merchant's exchange prompt including the encrypted portion; and a second encrypted envelope (the “exchange token”) (i.e., encrypted by the managing entity application's private key assigned to the user and corresponding to the transmitted reference identification code) comprising at least (1) the first encrypted envelope, (2) the exchange amount, (3) the exchange timestamp, (4) the exchange token expiration arising out of the exchange timestamp, and (5) a hashed value of the first encrypted envelope's contents combined with the user's assigned GUID with the hashing mechanism known only to the managing entity . . .”);
assigning, by the client system of the network environment, the encrypted digital token to the computing device (see ¶ [0008] “ . . . The mobile device of the user may then transmit (1) the reference identification code, (2) the identity of the managing entity authoring the reference identification code, (3) the user's assigned GUID, and (4) the encrypted exchange token to the computing device of the merchant via a near field communication channel. The computing device of the merchant receives the transmitted reference identification code, the identity of the managing entity system, the user's assigned GUID, and the encrypted exchange token from the computing device of the user. The computing device of the merchant may then employ the reference identification code to the internally stored list of managing entity public keys to identify the managing entity public key assigned to the user. The computing device of the merchant can then decrypt the second encrypted envelope, using the identified public key of the managing entity authenticating the token. . . .”);
transmitting, by the client system of the network environment, the identification code(e.g. user id) to the computing device (see ¶¶ [0046-0047] “ . . . The memory 320 may also include the public key and identification code repository 324. In embodiments where the computing device system 300 is owned or managed by a user 110, this public key and identification code repository 324 may comprise a list of reference identification codes for a plurality of merchants, where each such reference identification code is linked with a public key for that same merchant. In this way, the user 110 (or the computing device system 300 itself) can input the reference identification code of a merchant that the user 110 is interacting with, and the identification code repository 324 will output the public key for that merchant, which can be used by the computing device system 300 to decrypt a message, exchange prompt, or other encrypted information received from a separate computing device system 300 that is associated with that merchant. In embodiments where the computing device system 300 is owned or managed by a merchant user 112, the public key and identification code repository 324 may comprise a list of reference identification codes for a plurality of customers (including the user 110), where each such reference identification code is linked with a public key for that same customer. In this way, the merchant user 112 (or the computing device system 300 itself) can input the reference identification code of a customer that the merchant user 112 is interacting with, and the public key and the identification code repository 324 will output the public key for that customer, which can be used by the computing device system 300 to decrypt a message, exchange envelope, or other encrypted information received from a separate computing device system 300 that is associated with that customer . . .”);
storing, by the client system of the network environment, the encrypted digital token in the client system remotely from the computing device (see ¶ [0033] “ . . . the encryption application 250 includes key pairing data 252 and reference data 254. The key pairing data 252 may comprise information that the managing entity system can utilize to generate private and public key pairs that can be used for asymmetric cryptographic key encryption schemes and/or digital signature schemes. The reference ID data 254 may include information that links an individual customer (e.g., the user 110) to a key pair, and especially to link said user to a public key that can be stored in a repository (e.g., the active reference ID repository 120) and/or transmitted to computing devices of other parties (e.g., the computing device system 300 of the merchant user 112) for use in decrypting transmitted information and/or verifying digital signatures on information. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods for secure authentication of transactions between a user and merchant where a merchant device internally stores a repository of reference codes and managing entity public keys that are paired with managing entity private keys, and when the user requests an amount of resources for offline exchange from the managing entity system, the managing entity system transmits certain authorization and encryption information to a user device such that when the user device receives an exchange prompt from the computing device of the merchant through near field communication, it generates a digital token incorporating layers of content encryption ending with a managing entity's private key so that the encrypted token and reference code are transmitted via near field communication to the merchant device, and then the merchant device matches the reference code to the managing entity public key and decrypts portions of the token with the managing entity public key to acquire the usable exchange information, as taught by Beye, into systems, devices, and methods to manage sales transactions between a mobile device and a merchant device using a separate device transaction processor to create digital tokens that can be used to authorize the mobile device and merchant device to perform a secure transaction, as taught by Singh. Such incorporation provides for identifying a purchasing mobile device that can be authenticated by the merchant to complete the transaction.
The combination of Singh and Beye fails to explicitly teach,
However Hunt teaches expunging, by the client system of the network environment, the received digital token and the identification code from the client system (see Fig. 17B, step 7a – 7c ¶¶ [0166-0168] “ . . . FIG. 17B is a block diagram illustrating the sandboxed single sign-on method, depicting a subsequent sign-on process consistent with the present disclosure. The subsequent sign-on process may be used to gain access to further pre-configured relying parties without the need for full authentication, as is the case with the initial sign-on process of FIG. 17A. Fundamentally, the user agent must manage local biometric/PIN accesses appropriately, wherein, if a device is reset or the biometric data used to access the preclearance application changes, any and all tokens must be revoked. This is, possibly, enforced through MDM and/or various features, such as attestation from mobile-oriented key grant authorities. . . . The session token together with the relying party selected is sent (encrypted/signed according to prior key exchange) to the access/session management system (step 7) and various checks carried out (step 7a). If the token is found to have expired, it is expunged (step 7c) . . .“) .
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods for a secure authentication system that relies on a single trusted device associated with a user, such as a smartphone or other personal computing device, to facilitate strong and usable multi-factor authentication through the generation of a token and separate code maintained by an authorization system, as taught by Hunt, , into systems, devices, and methods to manage sales transactions between a mobile device and a merchant device using a separate device transaction processor to create digital tokens that can be used to authorize the mobile device and merchant device to perform a secure transaction, where a merchant device internally stores a repository of reference codes and managing entity public keys that are paired with managing entity private keys, and when the user requests an amount of resources for offline exchange from the managing entity system, the managing entity system transmits certain authorization and encryption information to a user device such that when the user device receives an exchange prompt from the computing device of the merchant through near field communication, it generates a digital token incorporating layers of content encryption ending with a managing entity's private key so that the encrypted token and reference code are transmitted via near field communication to the merchant device, and then the merchant device matches the reference code to the managing entity public key and decrypts portions of the token with the managing entity public key to acquire the usable exchange information, as taught by the combination of Singh and Beye. Such incorporation provides that the generated token can be stored on a database separate from the user device and can be expunged when the token has expired.
In regard to claim 2, the combination of Singh, Beye, and Hunt teaches further comprising generating the identification code using symmetric cryptography (see Hunt ¶ [0070] “ . . . an additional aspect of the registration process is a key exchange (certificate exchange) between the access/session management system 12 and the smartphone 17(2) to thereby improve the security of registration. In particular, the system 10 may utilize public-key cryptography, or asymmetric cryptography, . . .”).
The motivation to combine Hunt with the combination of Singh and Beye is described for the rejection of claim 1 and is incorporated herein. Additionally, Hunt provides symmetric cryptography to create authentication for the user.
In regard to claim 3, the combination of Singh, Beye, and Hunt teaches wherein the identification code is transmitted to the computing device via a web browser of the computing device (see Singh ¶ [0018] “ . . . The transaction processor may then determine and access an account of the user, and may generate a QR code for display via the interface widget using the account. For example, a QR code may be generated by encoding account and/or payment instrument data to the QR code (e.g., via one or more blocks, cells, dots, or the like of the QR code). Funding instrument data may be passed from an application and/or digital wallet associated with the account to a server and/or platform, which allows for association of the funding instrument with a QR code. The QR code may then be provided to the user's mobile device, which may be stored locally and/or in a cache or database of the mobile device. Thereafter, when the interface widget is open, in a foreground, and/or executing, the QR code may be display via an output component of the mobile device. For example, a touch screen interface or other display component may display the QR code via the interface widget. This may be performed without the user being required to open, log in to, authenticate, and/or provide a request in a corresponding mobile application on the mobile device, such as a resident dedicated application or web browser on the mobile device that may communicate with the transaction processor . . .”).
In regard to claim 4, the combination of Singh, Beye, and Hunt teaches wherein the identification code is a private key corresponding to a public key (see Hunt ¶ [0070] “ . . . the smartphone 17(2) can generate a pair of keys: a public key and a private key, and send the public key to the access/session management system 12 while storing the private key on a hardware-backed keystore on the smartphone 17(2), which is described in greater detail herein with reference to FIG. 9 . . .”).
The motivation to combine Hunt with the combination of Singh and Beye is described for the rejection of claim 1 and is incorporated herein. Additionally, Hunt generates a public key and a private key for effective authorization for the user to access the resource.
In regard to claim 5, the combination of Singh, Beye, and Hunt teaches further comprising storing the encrypted digital token in a database (see Beye ¶ [0061] “ . . . The merchant entity is storing the information from the repository in a local store on its computing device (e.g., a point of sale device, an automated teller machine, a mobile computing device, a computing device, and the like), so that the merchant entity can access the repository information (in its relational format) when a customer (e.g., the user) issues or otherwise transmits a reference identification code and an encrypted envelope which comprises an exchange token. In such embodiments, the computing device of the merchant will be able to validate the reference identification code and encrypted envelope even though the computing device of the merchant does not have a connection to the cloud or any wide area network. As will be described in more detail below, this block 406 allows the merchant to use the local store to look up the customer's particular managing entity public key based on a received reference identification code of that customer, and the computing device system can use that managing entity public key to validate at least a portion of the exchange token and/or decrypt a digital envelope that has been encrypted by the paired managing entity private key of this particular managing entity public key. . . .”).
The motivation to combine Beye with the combination of Singh and Hunt is described for the rejection of claim 1 and is incorporated herein. Additionally, Beye teaches the merchant device storing encrypted digital tokens representing user mobile devices.
In regard to claim 6, the combination of Singh, Beye, and Hunt teaches further comprising storing the encrypted digital token remotely from the computing device (see Hunt ¶ [0170] “ . . . the primary invention with preclearance is the capability to package the single-sign on grant in a token stored securely on an entirely separate device. Once established, that “sign-on pass” can be used to automatically sign-on in any preclearance portal on any hardware/software/browser/network environment, without requiring any special software to be running on that environment, which presents significant advantages. . . .”).
The motivation to combine Hunt with the combination of Singh and Beye is described for the rejection of claim 1 and is incorporated herein. Additionally, Hunt provides for storing the token on a separate device than the one used by the user for enhanced security.
In regard to claim 7, the combination of Singh, Beye, and Hunt teaches wherein the computing device is a smartphone (see Singh ¶ [0013] “ . . . transaction processing may be performed through a mobile application of the online transaction processor on a mobile device of a user. The mobile device may correspond to a mobile smart phone, such as an iPhone running iOS or the like, an Android platform phone, or other mobile communication device. . . .”).
In regard to claim 8, the combination of Singh, Beye, and Hunt teaches wherein the computing device is a customer’s computing device (see Singh ¶ [0063] “ . . . Merchant 310 may then capture the QR code an POS transaction details at an interaction 25, which provides such data and details to a Retail Payment Service (RPS) 316. This allows for processing by RPS 316 with QRC platform server 308. At an interaction 26, RPS 316 interactions with QRC platform server 308 for customer/QR code retrieval, validation, and/or approval. This may include providing a QR code with a funding instrument at an interaction 27 to QRC platform server 308 for processing. QRC platform server 308 may interact with the mobile device and/or mobile application 302 at an interaction 28 in order to inform that a scan happened and provide an event corresponding to the transaction processing using the QR code. Mobile application 302 may respond by polling for the event and/or data at an interaction 29, which may provide transaction data for loading in mobile application 302. . . .”).
In regard to claim 10, the combination of Singh, Beye, and Hunt teaches wherein the identification code is transmitted to the computing device in a cookie (see Singh ¶ [0032] “ . . . Mobile device 110 may further include database 116 which may include, for example, identifiers such as operating system registry entries, cookies associated with payment application 112 and/or additional applications, identifiers associated with hardware of mobile device 110, or other appropriate identifiers. Identifiers in database 116 may be used by a payment/service provider to associate mobile device 110 with a particular account maintained by the payment/service provider. Database 116 may also further store received transaction data, as well as processed transaction data. In various embodiments, a machine-readable code displayable using code widget 120, such as QR codes 122, may be stored by database 116. . . .”).
In regard to claim 13, Singh teaches A system for securing the use of a digital token (e.g. machine readable code) in a network environment (see abstract as described for the rejection of claim 1 and is incorporated herein) comprising: one or more servers of a client system (see Fig. 1) programmed to:
request authorization from a computing device (see Fig. 1 mobile device 110) separate from the client system (see Fig. 1 Merchant device 130) for access to a protected resource (e.g. card data, account data, or other financial data) (see ¶¶ [0035-0036] as described for the rejection of claim 1 and is incorporated herein);
receive authorization from the computing device (see Fig. 1 mobile device 110) for access to the protected resource (see ¶ [0037] as described for the rejection of claim 1 and is incorporated herein);
request a digital token from an authorization system (see Fig. 1 Transaction Processor 140) separate from the client system (see Fig. 1 Merchant device 130) and the computing system by authenticating with the authorization system using the authorization from the computing device (see Fig. 1 mobile device 110) (see ¶ [0027], [0029] as described for the rejection of claim 1 and is incorporated herein);
receive the requested digital token from the authorization system (see ¶ [0036] as described for the rejection of claim 1 and is incorporated herein);
Singh fails to explicitly teach,
However Beye teaches encrypt the received digital token using a identification code for the computing device to form an encrypted digital token (see ¶ [0006] ¶ [0007] as described for the rejection of claim 1 and is incorporated herein)
assign the encrypted digital token to the computing device (see ¶ [0008] as described for the rejection of claim 1 and is incorporated herein);
transmit the identification code to the computing device (see ¶¶ [0046-0047] as described for the rejection of claim 1 and is incorporated herein);
a database configured to store the encrypted digital token in the client system remotely from the computing device (see ¶ [0033] as described for the rejection of claim 1 and is incorporated herein);
The motivation to combine Beye with Singh is described for the rejection of claim 1 and is incorporated herein.
The combination of Singh and Beye fails to explicitly teach,
However Hunt teaches expunge the received digital token and the identification code from the client system (see Fig. 17B, step 7a – 7c ¶¶ [0166-0168] as described for the rejection of claim 1 and is incorporated herein ) ; and
one or more software components configured to store the identification code on the computing device (see ¶ [0070] as described for the rejection of claims 2 and 4 and is incorporated herein ).
The motivation to combine Hunt with the combination of Singh and Beye is described for the rejection of claims 1, 2, and 4 and is incorporated herein.
In regard to claim 18, Singh teaches A product for securing the use of a digital token in a network environment, the product comprising a non-transitory computer readable medium including instructions that, when executed by at least one processor (see Fig. 1 ¶ [0024] “ . . . Mobile device 110, merchant device 130, and transaction processor 140 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 100, and/or accessible over network 150. . . .”) , cause the at least one processor to perform token management operations (see abstract as described for the rejection of claim 1 and is incorporated herein),
requesting, by a client system of a network environment (see Fig. 1 Merchant device 130), authorization from a computing device (see Fig. 1 mobile device 110) separate from the client system for access to a protected resource (e.g. card data, account data, or other financial data) (see ¶¶ [0035-0036] as described for the rejection of claim 1 and is incorporated herein);
receiving, by the client system (see Fig. 1 Merchant device 130) of the network environment, authorization from the computing device (see Fig. 1 mobile device 110) for access to the protected resource (see ¶ [0037] as described for the rejection of claim 1 and is incorporated herein);
requesting, by the client system (see Fig. 1 Merchant device 130) of the network environment, a digital token (e.g. QR code 122) from an authorization system (see Fig. 1 Transaction Processor 140) separate from the client system (see Fig. 1 Merchant device 130) and the computing device (see Fig. 1 mobile device 110) (see ¶ [0027] as described for the rejection of claim 1 and is incorporated herein) by authenticating with the authorization system (Transaction Processor 140) using the authorization from the computing device (e.g. mobile device 110) (see ¶ [0029] as described for the rejection of claim 1 and is incorporated herein);
receiving, by the client system (merchant device 130) of the network environment, the requested digital token from the authorization system (transaction processor 140) (see ¶ [0036] as described for the rejection of claim 1 and is incorporated herein);
Singh fails to explicitly teach
However Beye teaches encrypting, by the client system (see Fig. 1 merchant user device 112) of the network environment, the received digital token using an identification code (e.g. reference identification code) for the computing device (see Fig. 1 user device 110) to form an encrypted digital token (see ¶ [0006], ¶ [0007] as described for the rejection of claim 1 and is incorporated herein);
assigning, by the client system of the network environment, the encrypted digital token to the computing device (see ¶ [0008] as described for the rejection of claim 1 and is incorporated herein);
transmitting, by the client system of the network environment, the identification code(e.g. user id) to the computing device (see ¶¶ [0046-0047] as described for the rejection of claim 1 and is incorporated herein);
storing, by the client system of the network environment, the encrypted digital token in the client system remotely from the computing device (see ¶ [0033] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Beye with Singh is described for the rejection of claim 1 and is incorporated herein.
The combination of Singh and Beye fails to explicitly teach,
However Hunt teaches expunging, by the client system of the network environment, the received digital token and the identification code from the client system (see Fig. 17B, step 7a – 7c ¶¶ [0166-0168] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Hunt with the combination of Singh and Beye is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 20, the combination of Singh, Beye, and Hunt teaches wherein the token management operations further comprise:
receiving the identification code from the computing device (see Hunt ¶ [0088] “ . . . Upon correct entry of the code, the cached session status is upgraded to realized and the method 200 then continues on in which the relying party 14 continues to poll the access/session management system 12 with “enquire-session” requests (operation 460), and, once the authentication session is realized and verification is complete, the access/session management system 12 responds to the “enquire-session” request with an authentication assertion, including details of the realized user 16 (operation 470), and the user 16 is able to progress on to relying party's interface, in which the relying party 14 grants the user 16 access protected resource that relying party is offering (operation 480). . . “);
decrypting the encrypted digital token using the identification code to recover the digital token (see Hunt ¶ [0151] “ . . . The authentication event results in some one-time token that may entered into a simplified user interface (UI) outside of the access/session management system's direct interaction (e.g., within a relying party's UI) that may then be presented to the access/session management system to discover the originating user's secure identity (e.g., username, or some other metadata stored for replay to that relying party). The authentication is that particular token, which is essentially an artifact that relates to the previous full authentication (event). . .”) ;
requesting one or more protected resources associated with the digital token, the requesting comprising transmitting the digital token to a resource system (see Hunt Fig. 6, ¶ [0076] “ . . . FIG. 6 is a flow diagram illustrating an embodiment of a method 100 for authenticating a user via an authentication session request/enquire/realization process. The method 100 includes the relying party 14 requesting an authentication session from the access/session management system 12 (operation 110). For example, a user 16 may attempt to access and initiate a session with the relying party 14, which may include a user 16 navigating to a relying party 14 user interface and requesting access to a protected resource. In this instance, the user 16 has previously completed the registration process and, in turn, is able to attempt to gain access via an authentication session (and subsequently gain access upon successful authentication). The relying party 14 may request an authentication session directly, or may forward the user interface to the authentication portal provided by the access/session management system 12 (where the session is requested directly). In response to the authentication session request, the access/session management 12 issues a session consisting of a public session identifier and an associated private session secret (operation 120). For example, the session information may include a public component, which serves as a tender to realize (made available for an as-yet unknown user agent of the computing device to “realize”), and a private component, which is a token shared between the access/session management system 12 and the relying party 14 to establish provenance, and is required by any exchange of status information for the session. In particular, the relying party 14, or authentication portal on behalf of the relying party 14, polls the access/session management system 12 with “enquire-session” requests for a given public session identifier, to thereby provide provenance of the relying party's right to enquire that particular session by virtue of the accompanying private session secret token. . . .”) ; and
processing a response to the requesting, the response comprising the one or more protected resources (see Hunt ¶ [0078] “ . . . Once the authentication session is realized, the access/session management system 12 responds to the “enquire-session” request with an authentication assertion, including details of the realized user 16 (operation 170). Upon a successful authentication, a user 16 is able to progress on to relying party's interface, in which the relying party 14 grants the user 16 access protected resource that relying party is offering (operation 180) . . . “).
The motivation to combine Hunt with the combination of Singh and Reye is described for the rejection of claim 1 and is incorporated herein. Additionally, Hunt provides steps to have a user access a protected resource once the token has been authenticated.
Claims 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims 1 -8, 10, 13, 18, and 20 in further view of Tang et al. (U.S. 2021/0144010 A1; herein referred to as Tang).
In regard to claim 9, the combination of Singh, Beye and Hunt fails to explicitly teach but Tang teaches wherein the computing device is an employee’s computing device (see Tang ¶ [0041] “ . . . user device 110 can be associated with a user and may be operated by that user. The data device 120 can be associated with data holding entity, such as a commercial institution (e.g., a financial institution or an employer), a government agency, or other entity, and may be operated by the entity. The user device 110 may transmit, via a secure back channel, private information for storage within the memory 122 of the data device 120 or within the database 130. In other examples, the user may provide private information to entity operating the data device in an offline manner, such as through the submission of a paper form or a telephone call. One received, the private information may be securely stored in the memory 122 of the data device 120 or within the database 130. Security measures, including encryption, multifactor authentication, biometric authentication, and other measures can be implemented to increase the security of the private information and reduce the likelihood that the private information can be compromised while being stored. . . .”).
It would been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a system and method for data delegation and protection using tokenized data and managing the delegation and protection of tokenized data, which may include private, sensitive information, between a data device, user device, and merchant device, as taught by Tang, into systems, devices, and methods to manage sales transactions between a mobile device and a merchant device using a separate device transaction processor to create digital tokens that can be used to authorize the mobile device and merchant device to perform a secure transaction, where a merchant device internally stores a repository of reference codes and managing entity public keys that are paired with managing entity private keys, and when the user requests an amount of resources for offline exchange from the managing entity system, the managing entity system transmits certain authorization and encryption information to a user device such that when the user device receives an exchange prompt from the computing device of the merchant through near field communication, it generates a digital token incorporating layers of content encryption ending with a managing entity's private key so that the encrypted token and reference code are transmitted via near field communication to the merchant device, and then the merchant device matches the reference code to the managing entity public key and decrypts portions of the token with the managing entity public key to acquire the usable exchange information, for a secure authentication system that relies on a single trusted device associated with a user, such as a smartphone or other personal computing device, to facilitate strong and usable multi-factor authentication through the generation of a token and separate code maintained by an authorization system as taught by the combination of Singh, Beye, and Hunt. Such incorporation provides a scenario where the access is employee based access.
In regard to claim 17, the combination of Singh, Beye, Hunt, and Tang teaches wherein the client system is configured to obtain the digital token from a resource system based on an authorization grant received from the computing device (see Tang ¶¶ [0043-0044] “ . . . the access token may be selectively configured by the user to allow access to all of the user's stored private information or one or more portions thereof. For example, a user may specify that an access token allow access to all private information stored by a particular data holding entity. As another example, a user may specify that only a particular item of private information (e.g., an account number, a mailing address, a Social Security number, salary information, a password, a security code) is accessible, and accordingly the access token may be configured to grant only that access and may be uniquely associated with the specified information. As another example, the user may specify that an access token grant access to a specific category of information, such as contact information (e.g., home address, mailing address, telephone number, email address), identity information (e.g., legal name, residence address, Social Security number), financial information (e.g., account number(s), account balance, account history, credit history, trade or transaction approval information), and security information (e.g., a password, a security code, a biometric identifier, second factor authentication information). In some examples, the categories may be transaction-based and comprise the private information necessary to complete a certain transaction. For example, a user seeking to complete a transfer of funds between financial accounts could authorize access to account numbers, account balances, passwords, and security codes. In another example, a user seeking to transfer medical records between health care providers could authorize access to patient identifiers, provider identifiers, passwords, security codes, and medical records. The medical record access could be to all medical records related to the patient at one or more providers, all medical records from a certain time period, all medical records pertaining to a certain diagnosis, medical issue, or medical area (e.g., cardiovascular health, mental health. . . “).
The motivation to combine Tang with the combination of Singh, Beye, and Hunt is described for the rejection of claim 9 and is incorporated herein. Additionally, Tang offers a complete access permission scenario.
Claims 11 – 12 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims 1 -8, 10, 13, 18, and 20 in further view of Kukreja et al. (U.S. 2020/0127994 A1; herein referred to as Kukreja).
In regard to claim 11, the combination of Singh, Beye, Hunt, and Kukreja teaches wherein the digital token is a refresh token (see Kukreja ¶ [0023] “ . . . Once the access token or the constraints/rules in the access token are determined to be invalid (e.g., expired), the access token can be regenerated by using a refresh token or a JWT (JavaScript Object Notation (JSON) Web Token) authorization grant flow, which is a two-legged flow in which the token receiving entity directly communicates with the token issuing authority.. . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods for generating and using rule-enhanced access tokens in connection with authorization for access to resources. An access token is generated in response to determining that a user is authorized to access a protected resource. The access token contains rule information including one or more constraints, each constraint corresponding to a condition for granting or denying access to the protected resource, as taught by Kukreja, into systems, devices, and methods to manage sales transactions between a mobile device and a merchant device using a separate device transaction processor to create digital tokens that can be used to authorize the mobile device and merchant device to perform a secure transaction, where a merchant device internally stores a repository of reference codes and managing entity public keys that are paired with managing entity private keys, and when the user requests an amount of resources for offline exchange from the managing entity system, the managing entity system transmits certain authorization and encryption information to a user device such that when the user device receives an exchange prompt from the computing device of the merchant through near field communication, it generates a digital token incorporating layers of content encryption ending with a managing entity's private key so that the encrypted token and reference code are transmitted via near field communication to the merchant device, and then the merchant device matches the reference code to the managing entity public key and decrypts portions of the token with the managing entity public key to acquire the usable exchange information, for a secure authentication system that relies on a single trusted device associated with a user, such as a smartphone or other personal computing device, to facilitate strong and usable multi-factor authentication through the generation of a token and separate code maintained by an authorization system as taught by the combination of Singh, Beye, and Hunt. Such incorporation adds constraints on what information is associated with the token.
In regard to claim 12, the combination of Singh, Beye, Hunt, and Kukreja teaches wherein the digital token is a refresh token (see Kukreja ¶ [0023] “ . . . Once the access token or the constraints/rules in the access token are determined to be invalid (e.g., expired), the access token can be regenerated by using a refresh token or a JWT (JavaScript Object Notation (JSON) Web Token) authorization grant flow, which is a two-legged flow in which the token receiving entity directly communicates with the token issuing authority.. . “).
The motivation to combine Kukreja with the combination of Singh, Beye, and Hunt is described for the rejection of claim 11 and is incorporated herein. Additionally, refresh tokens are used to maintain the token status is the token generated has expired or was initially invalid.
Claims 14 – 16, 19, and 21 – 22 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (U.S. 2023/0281598 A1; herein referred to as Singh) in view of Beye (U.S. 2021/0090066 A1; herein referred to as Beye) in further view of Hunt (U.S. 2020/0162255 A1; herein referred to Hunt) as applied to claims1 -8, 10, 13, 18, and 20 in further view of Grajek et al. (U.S. 2015/0244706 A1; herein referred to as Grajek).
In regard to claim 14, the combination of Singh, Beye, and Hunt fails to explicitly teach but Grajek teaches wherein a mobile app comprises the one or more software components (see Grajek ¶ [0049] “ . . . The registration process may be initiated by pointing the user computing device 110 to the authentication system to begin the device registration process. For example, this could be accomplished via the user being instructed to register their device via a browser based system. As another example, this could be accomplished via the user being instructed to register their device via a mobile application, for example, on an iPhone. Browser-based methods would not require any device control such as routing or administrative access on the user device but merely take the user to a self-enrollment process on the authentication system, for example through the authentication system's web interface. Registration may also not require any routing or administrative access on the mobile device by the mobile app. . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a system and method for a security object creation and validation system which provides an additional factor of authentication, and for generation of a security object (such as an X.509 object, Java object, persistent browser token, or other digital certificate); registration of the generated security object or of an existing security object (such as a near field communication identifier, smart card identifier, OATH token, etc.); validation of the security object as part of an authentication process; and assertion of the identity of the security object to native network resources (such as web resources, network resources, cloud resources, mobile applications, and the like) that may accept the security object, as taught by Grajek, into systems, devices, and methods to manage sales transactions between a mobile device and a merchant device using a separate device transaction processor to create digital tokens that can be used to authorize the mobile device and merchant device to perform a secure transaction, where a merchant device internally stores a repository of reference codes and managing entity public keys that are paired with managing entity private keys, and when the user requests an amount of resources for offline exchange from the managing entity system, the managing entity system transmits certain authorization and encryption information to a user device such that when the user device receives an exchange prompt from the computing device of the merchant through near field communication, it generates a digital token incorporating layers of content encryption ending with a managing entity's private key so that the encrypted token and reference code are transmitted via near field communication to the merchant device, and then the merchant device matches the reference code to the managing entity public key and decrypts portions of the token with the managing entity public key to acquire the usable exchange information, for a secure authentication system that relies on a single trusted device associated with a user, such as a smartphone or other personal computing device, to facilitate strong and usable multi-factor authentication through the generation of a token and separate code maintained by an authorization system as taught by the combination of Singh, Beye, and Hunt. Such incorporation enables the security object to be integrated into a web service for further authentication and to use a mobile application for the functions of the authentication management.
In regard to claim 15, the combination of Singh, Beye, Hunt, and Grajek teaches wherein the mobile app is downloaded to the computing device via the public Internet (see Grajek ¶¶ [0045-0046] “ . . . The system described in FIG. 1 may also have the ability to extract distinct device information from a device utilizing web browser and web-based mechanisms such as Javascript. Other mechanisms may be used to extract distinct device information such as flash programs, cookies, custom downloaded and installed programs (that are downloaded and installed through the web from the authentication system for example), or any other mechanism or instructions that may be transmitted from the authentication system to the user device 110 for collection of characteristic information about the user device, a security object installed on or associated with the user device, a browser installed on the device, other software installed on the device (e.g. OS or other applications), or its user. This characteristic information may be transferred to and stored on the authentication system or any external remote data storage, for example on enterprise directory 104 or any cloud storage. The authentication system can then use and store this information in the enterprise directory 104, in its local storage, or in the cloud. As discussed herein, some or all of this information may be used to create a security object for future comparison to other security objects. In one embodiment, a one-time native mobile app such as an iPhone app, if deployed through the web to an iPhone device, may be utilized to collect and send identification information, including security object information or device characteristics, from a device . . . “).
The motivation to combine Grajek with the combination of Singh, Beye, and Hunt is described for the rejection of claim 14 and is incorporated herein. Additionally Grajek enables the mobile application to be downloaded to a device through the Internet.
In regard to claim 16, the combination of Singh, Beye, Hunt, and Grajek teaches wherein the one or more software components are configured to store the identification code in a secure enclave (e.g. security object) on the computing device (see Grajek ¶ [0025] “ . . . the authentication system may then create a security object to be associated with the device and/or the user. The security object may, for example, comprise a token or other persistent data object which may be created in various formats such as an X.509 object (e.g., an X.508 soft ID, an X.509 smart card), a Java object, a Persistent Browser token, or other type of security object or digital certificate. The security object may include an identifier or ID which may be mapped to a local identity store which stores associations of security objects/IDS, devices, and users. The security object associated with the device is then stored in the authentication system's storage in association with the user ID . . . “).
The motivation to combine Grajek with the combination of Singh, Beye, and Hunt is described for the rejection of claim 14 and is incorporated herein. Additionally Grajek provides additional secure storage options for the authentication data.
In regard to claim 19, the combination of Singh, Beye, Hunt, and Grajek teaches wherein the token management operations further comprise communicating with a downloadable mobile app on the computing device to transmit the identification code (see Grajek ¶¶ [0045-0046] ¶ [0049] as described for the rejections of claims 14 – 15 and is incorporated herein).
The motivation to combine Grajek with the combination of Singh, Beye, and Hunt is described for the rejection of claims 14 - 15 and is incorporated herein.
In regard to claim 21, the combination of Singh, Beye, Hunt, and Grajek teaches further comprising storing the identification code in a secure enclave (e.g. security object) on the computing device (see Grajek ¶ [0025] as described for the rejection of claim 16 and is incorporated herein).
The motivation to combine Grajek with the combination of Singh, Beye, and Hunt is described for the rejection of claim 16 and is incorporated herein.
In regard to claim 22, the combination of Singh, Beye, Hunt, and Grajek teaches wherein the token management operations further comprise storing the identification code in a secure enclave (e.g. security object) on the computing device (see Grajek ¶ [0025] as described for the rejection of claim 16 and is incorporated herein).
The motivation to combine Grajek with the combination of Singh, Beye, and Hunt is described for the rejection of claim 16 and is incorporated herein.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444