DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Status of Application
This Communication is a Non-Final Office Action in response to the Amendments, Remarks, and Arguments filed on the 5th day of August, 2025. Currently Claims 1-5, 8-12, and 15-18 are pending. Claims 6-7, 13-14, and 19-20. No claims are allowed.
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 filed on the 5th day of August, 2025, has been entered.
Claim Rejections - 35 USC § 101
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.
Claims 1-5, 8-12, and 15-18 are rejected under 35 U.S.C. §101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) with no practical application and without significantly more.
Under MPEP 2106, when considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (step 1). If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (step 2A prong 1), and if so, it must additionally be determined whether the claim is integrated into a practical application (step 2A prong 2). If an abstract idea is present in the claim without integration into a practical application, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself (step 2B).
In the instant case, claims 1-5, 8-12, and 15-18 are directed to a system, method, and non-transitory computer-readable media. Thus, each of the claims falls within one of the four statutory categories (step 1). However, the claims also fall within the judicial exception of an abstract idea (step 2). While claims 1, 8, and 15, are directed to different categories, the language and scope are substantially the same and have been addressed together below.
Under Step 2A Prong 1, the test is to identify whether the claims are “directed to” a judicial exception. Examiner notes that the claimed invention is directed to an abstract idea in that the instant application is directed to certain methods of organizing human activity specifically commercial interactions and behaviors and managing personal behavior and/or interactions between people (see MPEP 2106.04(a)(2)(II)) and mental processes (see MPEP 2106.04(a)(2)(III).
Examiner notes that claims 1-5, 8-12, and 15-18 recite a generating two or more user keys using a cryptographic function on an aggregate object, wherein the aggregate object includes physical-location information associated with a physical location, user information, and a random number generator, wherein each user key of the one or more user keys is a unique, single-use key, and wherein the two or more user keys are generated at the same time; receiving a transfer request associated with an authorization corresponding to the physical location, wherein the authorization is associated with a first computing device; transmitting, in response to receiving the transfer request, a first communication requesting authentication of the transfer request and a second communication to a second computing device configured to process a portion of the transfer request; transmitting a third communication to one or more client devices via a uniform resource locator address, wherein the third communication includes instructions that cause the one or more client devices to generate an authentication object, wherein the authentication object includes a first user key of the two or more user keys, wherein the uniform resource locator includes a single-use encrypted string generated using an identifier of the first computing device, wherein the third communication is transmitted in response to receiving a response to the first communication that includes an indication that the transfer request is authentic, and wherein the one or more client devices include the second computing device; receiving the authorization object at the uniform resource locator address corresponding to the uniform resource locator; deleting the uniform resource locator address to prevent receiving additional data at the uniform resource locator address; authenticating the authentication object by comparing the first user key of the authentication object with a second user key of the two or more user keys; transmitting a first access code of two or more access codes to the one or more client devices and a second access code of the two or more access codes to the first computing device, wherein the two or more access codes are generated at the same time, and wherein each access code is a single-use access code; receiving, from an independent device, an indication that the first access code matches the second access code, wherein the independent device is configured to receive the first access code and the second access code from the first computing device and the one or more client devices, which authenticates the first computing device and the one or more client devices; and executing the transfer request, wherein executing the transfer request includes storing an indication of a transfer associated with the physical location in a physical-location database which is directed to concepts that are performed mentally and a product of human mental work. The limitations suggest a process similar to standard practice entering into transfers of property when parties are authenticated and authorized prior to effectuating the contract. Information related to a transaction is received, information is compared to determine a match, and then the system stores the transaction based on the match confirmation. This is common practice when transferring property. Because the limitations above closely follow the steps of collecting information, analyzing or processing the information, and displaying the result of the analysis, and the steps involved human judgments, observations and evaluations that can be practically or reasonably performed in the human mind, the claim recites an abstract idea consistent with the “mental process” grouping set forth in the see MPEP 2106.04(a)(2)(III).
Alternatively, Examiner notes that claims 1-5, 8-12, and 15-18 recite a generating two or more user keys using a cryptographic function on an aggregate object, wherein the aggregate object includes physical-location information associated with a physical location, user information, and a random number generator, wherein each user key of the one or more user keys is a unique, single-use key, and wherein the two or more user keys are generated at the same time; receiving a transfer request associated with an authorization corresponding to the physical location, wherein the authorization is associated with a first computing device; transmitting, in response to receiving the transfer request, a first communication requesting authentication of the transfer request and a second communication to a second computing device configured to process a portion of the transfer request; transmitting a third communication to one or more client devices via a uniform resource locator address, wherein the third communication includes instructions that cause the one or more client devices to generate an authentication object, wherein the authentication object includes a first user key of the two or more user keys, wherein the uniform resource locator includes a single-use encrypted string generated using an identifier of the first computing device, wherein the third communication is transmitted in response to receiving a response to the first communication that includes an indication that the transfer request is authentic, and wherein the one or more client devices include the second computing device; receiving the authorization object at the uniform resource locator address corresponding to the uniform resource locator; deleting the uniform resource locator address to prevent receiving additional data at the uniform resource locator address; authenticating the authentication object by comparing the first user key of the authentication object with a second user key of the two or more user keys; transmitting a first access code of two or more access codes to the one or more client devices and a second access code of the two or more access codes to the first computing device, wherein the two or more access codes are generated at the same time, and wherein each access code is a single-use access code; receiving, from an independent device, an indication that the first access code matches the second access code, wherein the independent device is configured to receive the first access code and the second access code from the first computing device and the one or more client devices, which authenticates the first computing device and the one or more client devices; and executing the transfer request, wherein executing the transfer request includes storing an indication of a transfer associated with the physical location in a physical-location database, and is similar to the abstract idea identified in MPEP 2106.04(a)(2)(II) in grouping “II” in that the claims recite certain methods of organizing human activity such as transferring properties and entering into transactions and contracts. This is merely further embellishments of the abstract idea and does not further limit the claimed invention to render the claims patentable subject matter. The limitations, substantially comprising the body of the claim, recite standard processes found in standard practice in property transactions or any asset transfer. This is common practice when parties to a transaction enter and have to prove they are the person entering into the agreement in order to validate the terms of the agreement and validate the contract. It is standard practice in contract law to validate or authorize the specific parties of a contract to validate the agreement and the associated terms and signatures. Because the limitations above closely follow the steps standard in interactions between people and businesses such as property transfers and real estate transactions, and the steps of the claims involve organizing human activity, the claim recites an abstract idea consistent with the “organizing human activity” grouping set forth in the see MPEP 2106.04(a)(2)(II).
The conclusion that the claim recites an abstract idea within the groupings of the MPEP 2106.04(a)(2) remains grounded in the broadest reasonable interpretation consistent with the description of the invention in the specification. For example, [App. Spec ¶ 5 and 2], “Methods are described herein for securing transfers associated with physical locations” and “preventing unauthorized access to secured systems, and more particular to securing data reads and writes to secured systems to prevent unauthorized transfers associated with physical locations”. Accordingly, the Examiner submits claims 1, 8, and 15, recite an abstract idea based on the language identified in claims 1-5, 8-12, and 15-18, and the abstract ideas previously identified based on that language that remains consistent with the groupings of Step 2A Prong 1 of the MPEP 2106.04(a)(1).
If the claims are directed toward the judicial exception of an abstract idea, it must then be determined under Step 2A Prong 2 whether the judicial exception is integrated into a practical application. Examiner notes that considerations under Step 2A Prong 2 comprise most the consideration previously evaluated in the context of Step 2B. The Examiner submits that the considerations discussed previously determined that the claim does not recite “significantly more” at Step 2B would be evaluated the same under Step 2A Prong 1 and result in the determination that the claim does not integrate the abstract idea into a practical application.
The instant application fails to integrate the judicial exception into a practical application because the instant application merely recites words “apply it” (or an equivalent) with the judicial exception or merely includes instructions to implement an abstract idea. The instant application is directed to a method instructing the reader to implement the identified method of organizing human activity of business interactions and risk management (i.e., validating parties of a transaction for a physical location) on generically claimed computer structure. For instance, the additional elements or combination of elements other than the abstract idea itself include the elements such as “processor”, and “uniform resource locator” recited at a high level of generality. These elements do not themselves amount to an improvement to the interface or computer, to a technology or another technical field. This is consistent with Applicant’s disclosure which states that the computing device includes “a general-purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code, etc.”. (App. Spec. ¶ 111).
Accordingly, the claimed “system” read in light of the specification employs any wide range of possible devices comprising a number of components that are “well-known” and included in an indiscriminate “computer”, “processor”, “database”, “uniform resource locator”, and “storage” (e.g., processing device, modules). Thus, the claimed structure amounts to appending generic computer elements to abstract idea comprising the body of the claim. The computing elements are only involved at a general, high level, and do not have the particular role within any of the functions but to be a computer-implemented method using a generically claimed “processor”, “uniform resource locator”, and “memory” and even basic, generic recitations that imply use of the computer such as storing information via servers would add little if anything to the abstract idea.
Similarly, reciting the abstract idea as software functions used to program a generic computer is not significant or meaningful: generic computers are programmed with software to perform various functions every day. A programmed generic computer is not a particular machine and by itself does not amount to an inventive concept because, as discussed in MPEP 2106.05(a), adding the words “apply it” (or an equivalent) with the judicial exception, or more instructions to implement an abstract idea on a computer, as discussed in Alice, 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f)), is not enough to integrate the exception into a practical application. Further, it is not relevant that a human may perform a task differently from a computer. It is necessarily true that a human might apply an abstract idea in a different manner from a computer. What matters is the application, “stating an abstract idea while adding the words ‘apply it with a computer’” will not render an abstract idea non-abstract. Tranxition v. Lenovo, Nos. 2015-1907, -1941, -1958 (Fed. Cir. Nov. 16, 2016), slip op. at 7-8.
Here, the instructions entirely comprise the abstract idea, leaving little if any aspects of the claim for further consideration under Step 2A Prong 2. In short, the role of the generic computing elements recited in claims 1-5, 8-12, and 15-18, is the same as the role of the computer in the claims considered by the Supreme Court in Alice, and the claim as whole amounts merely to an instruction to apply the abstract idea on the generic computerised system. Therefore, the claims have failed to integrate a practical application (2106.04(d)). Under the MPEP 2106.05, this supports the conclusion that the claim is directed to an abstract idea, and the analysis proceeds to Step 2B.
While many considerations in Step 2A need not be reevaluated in Step 2B because the outcome will be the same. Here, on the basis of the additional elements other than the abstract idea, considered individually and in combination as discussed above, the Examiner respectfully submits that the claims 1-5, 8-12, and 15-18, does not contain any additional elements that individually or as an ordered combination amount to an inventive concept and the claims are ineligible.
With respect to the dependent claims do not recite anything that is found to render the abstract idea as being transformed into a patent eligible invention. The dependent claims are merely reciting further embellishments of the abstract idea and do not claim anything that amounts to significantly more than the abstract idea itself.
Claims 2-5, 9-12, and 16-18 are directed to further embellishments of the abstract idea in that they are directed to aspects of the central theme of the abstract idea identified above.
Therefore, since there are no limitations in the claim that transform the abstract idea into a patent eligible application such that the claim amounts to significantly more than the abstract idea itself, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter. See MPEP 2106.
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 (i.e., changing from AIA to pre-AIA ) 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, 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 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.
Claim(s) 1-5, 8-12, and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. US 20190052466 A1 to Bettger in view of U.S. Patent Application Publication No. US 20190124071 A1 to Haeusler in view of U.S. Patent Application Publication No. US 20160035053 A1 to Gerhardt.
Referring to claim 1, 8, and 15 (substantially similar in scope and language), Bettger discloses a method, A non-transitory computer-readable storage medium, having instructions stored thereon that, when executed by at least one computing device cause the at least one computing device to perform operations, and a system comprising; a processor; and a non-transitory computer-readable storage medium, having instructions stored thereon that, when executed by at least one computing device cause the at least one computing device to perform operations (see at least Bettger: ¶ 122 “a user device 402 may communicate with the application distribution server 420 and/or the contract authentication server 440 to authorize transactions or otherwise enter into contracts. The application distribution server 420 can be a computing system (for example, with physical hardware, such as one or more processors, memory, graphical processing power, input/output devices, an internal bus, etc.) configured to distribute applications (for example, mobile applications, desktop and/or laptop applications, other stand-alone third party applications, etc.) to various user devices 402. For example, upon a request submitted by a user device 402 for an application, the application distribution server 420 may retrieve the requested application from the application data store 422 and transmit the requested application to the user device 402.”) comprising:
generating two or more user keys using a cryptographic function on an aggregate object, wherein the aggregate object includes physical-location information associated with a physical location, user information, and a random number generator, wherein each user key of the one or more user keys is a unique, and wherein the two or more user keys are generated at the same time (see at least Bettger: ¶ 207 “an initialization key is generated. For example, a sequential number generator, a random number generator, a pseudorandom number generator, a previous initialization key, and/or the like can be used to generate the initialization key”; see also Bettger: ¶ 169; see also Bettger: ¶ 172 “the contract authentication server 440 may generate the symmetric key based on a master key that is derived from the generated unique initialization key. The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined).”; see also Bettger: ¶ 176 “The hash contract generation routine 650 may include using a symmetric key (for example, a secret key that may or may not be a single-use key) to prevent a malicious device from successfully spoofing the user device 402 and authorizing a transaction unbeknownst to the user even if the malicious device is able to intercept some inputs to the hash function used to generate a hash contract. The hash contract generation routine 650 begins at block 652.”; see also Bettger: ¶ 180 “the user device 402 may prompt a user, in a user interface generated by the application retrieved from the application distribution server 420, to provide one or more inputs that uniquely represent the user (for example, one or more multi-factor authentication factors). For example, such input can include a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has”; see at least Bettger: ¶ 183 “The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request”; see at least Bettger: ¶ 190 “At block 710, first data based on a second value representing an identity of the user is obtained. For example, the user device 402 may prompt a user, in a user interface generated by the application retrieved from the application distribution server 420, to provide one or more inputs that uniquely represent the user (for example, one or more multi-factor authentication factors). For example, such input can include a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has”; see also Bettger: ¶ 193 “a symmetric key is retrieved. The user device 402 may generate the symmetric key based on a master key that is derived using a unique initialization key embedded in an application retrieved from the application distribution server 420. The contract authentication server 440 may have generated the unique initialization key that is embedded in the application retrieved from the application distribution server 420 and executed by the user device 402. Thus, the contract authentication server 440 may generate the symmetric key based on a master key that is derived from the generated unique initialization key. The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request”; see also ¶ 205, 209, 214, 234-235, and 247; see at least Bettger: ¶ 122 “a user device 402 may communicate with the application distribution server 420 and/or the contract authentication server 440 to authorize transactions or otherwise enter into contracts. The application distribution server 420 can be a computing system (for example, with physical hardware, such as one or more processors, memory, graphical processing power, input/output devices, an internal bus, etc.) configured to distribute applications (for example, mobile applications, desktop and/or laptop applications, other stand-alone third party applications, etc.) to various user devices 402. For example, upon a request submitted by a user device 402 for an application, the application distribution server 420 may retrieve the requested application from the application data store 422 and transmit the requested application to the user device 402”; see also Bettger: ¶ 136 “The request generator 442 may request and/or receive identity information from user devices 402. For example, the request generator 442 may transmit a request to a user device 402 for data representing an identity of a user that operates the user device 402. The user device 402 may then prompt the user to provide one or more inputs that uniquely represent an identity of the user (for example, a multi-factor authentication factor, such as a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has). The user device 402 may convert the input(s) into one or more values (for example, an alphanumeric value, a hexadecimal value, a string value, etc.) and then apply a hash function to the value(s) to generate an identity hash code (also referred to as a “hash identity code”). In general, if the user device 402 or the contract authentication server 440 is attempting to apply a hash function to multiple inputs, the user device 402 or contract authentication server 440 can concatenate the inputs into a single string and apply a hash function to the single string, where each input may or may not be separated with a divider (for example, an underscore character, a number appended to the front or back of an input that identifies a length of the input, etc.). The user device 402 may then transmit the identity hash code to the request generator 442 to satisfy the request. Alternatively, the request generator 442 may receive the identity hash code without requesting such information (for example, the user device 402 prompts the user to provide one or more inputs that uniquely represent an identity of the user when the application retrieved from the application distribution server 420 is first installed, when a user makes a selection to provide the input(s), etc.). Once the identity hash code is received, the request generator 442 can store the identity hash code in the user identity data store 446 in an entry associated with the user operating the user device 402 and/or the user device 402 itself.”; see also Bettger: ¶ 152 “each time a transaction authorization request is received, the user device 402 may prompt the user to provide one or more inputs that uniquely represent the user and the user device 402 may perform the process described herein to generate a new copy of the first data”; and ¶ 157 “The first data generation routine 520 may be performed when the application retrieved from the application distribution server 420 is first initialized, when a user initiates an action to enter input(s) uniquely representing the user, and/or when the user device 402 is attempting to generate a hash contract to authorize a transaction (for example, in response to reaching block 510 when executing the hash contract generation routine 500) or a decline hash code to decline a transaction. The first data generation routine 520 begins at block 522”; see also Bettger: ¶ 172 “The user device 402 may generate the symmetric key based on a master key that is derived using a unique initialization key embedded in an application retrieved from the application distribution server 420. The contract authentication server 440 may have generated the unique initialization key that is embedded in the application retrieved from the application distribution server 420 and executed by the user device 402. Thus, the contract authentication server 440 may generate the symmetric key based on a master key that is derived from the generated unique initialization key. The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined). Additional details regarding the generation of the symmetric key are described below with respect to FIGS. 8A-8B.”; see also ¶ 365: “the identity hash and/or the authentication hash can, by themselves, be used to grant or deny a user and/or a user device 402 access to resources of a system. For example, a user device 402 can generate an identity hash in a manner as described herein and a system (for example, the contract authentication server 440 and/or any other system that provides users access to resources, such as secure or confidential content, data storage space, data processing capabilities, etc.) can compare the identity hash generated by the user device 402 to an identity hash previously received from the user device 402 (or another user device 402 operated by the user). If the comparison yields a match, the system can grant the user or the user device 402 access to the provided resource. If the comparison does not yield a match, the system can deny the user or the user device 402 access to the provided resource. Similarly, a user device 402 can generate an authentication hash in a manner as described herein and a system can compare the authentication hash generated by the user device 402 to an authentication hash previously received from the user device 402 (or another user device 402 operated by the user). If the comparison yields a match, the system can grant the user or the user device 402 access to the provided resource. If the comparison does not yield a match, the system can deny the user or the user device 402 access to the provided resource.”; see also Bettger: ¶ 207 “an initialization key is generated. For example, a sequential number generator, a random number generator, a pseudorandom number generator, a previous initialization key, and/or the like can be used to generate the initialization key.”).
Examiner notes that Bettger is automatically and in real-time processing a plurality of keys starting with the initialization key and then subsequently generating both a master key from that initialization key and a symmetric key all at once in order to authorize or validate the user for access to the provided resource, therefore, disclosing generating two or more keys at the same time (see at least Bettger: ¶ 138-140: key seeder generating a unique initialization key, the master key, and one or more symmetric keys at the same time).
receiving a transfer request associated with an authorization corresponding to a physical location, wherein the authorization is associated with a first computing device (see at least Bettger: ¶ 84: “In order to indicate that the sender has accepted the terms and conditions and/or consideration of the offer, the sender may digitally sign the document 202. For example, the computing device operated by the sender may apply a hash function 204 to the document 202 to form a hashed version of the document 202. The computing device may then encrypt the hashed version of the document 202 using a private key 206 to form a digital signature 208. This encryption may be important because it allows the sender computing device to securely transmit a verifiable digital signature over a network that can be used to determine whether a contract has been executed. Alternatively, the computing device can encrypt the document 202 using the private key 206 to form the digital signature 208… ”; see also Bettger: ¶ 104 “the receiver computing device can verify that an offer is unaltered and that the sender intends to accept and/or has accepted the terms and conditions of the offer 102 and/or the consideration 104 by comparing two hash codes (for example, the hash contract 120 and the hash contract 320) generated without the use of asymmetric encryption keys. Because asymmetric encryption keys are not necessary to verify or authenticate a legally enforceable contract using the process described herein, the process described herein can avoid the weaknesses associated with private and public keys described above”; see also Bettger ¶ 144 “the receiver computing device can verify that an offer is unaltered and that the sender intends to accept and/or has accepted the terms and conditions of the offer 102 and/or the consideration 104 by comparing two hash codes (for example, the hash contract 120 and the hash contract 320) generated without the use of asymmetric encryption keys. Because asymmetric encryption keys are not necessary to verify or authenticate a legally enforceable contract using the process described herein, the process described herein can avoid the weaknesses associated with private and public keys described above”); and
transmitting, in response to receiving the transfer request, a first communication requesting authentication of the transfer request and a second communication to a second computing device configured to process a portion of the transfer request;
Bettger discloses receiving a transfer request associated with an authorization corresponding to a transaction, wherein the authorization is associated with a first computing device and transmitting, in response to receiving the transfer request, a first communication requesting authentication of the transfer request and a second communication to a second computing device configured to process a portion of the transfer request (see at least Bettger: ¶ 122 “a user device 402 may communicate with the application distribution server 420 and/or the contract authentication server 440 to authorize transactions or otherwise enter into contracts. The application distribution server 420 can be a computing system (for example, with physical hardware, such as one or more processors, memory, graphical processing power, input/output devices, an internal bus, etc.) configured to distribute applications (for example, mobile applications, desktop and/or laptop applications, other stand-alone third party applications, etc.) to various user devices 402. For example, upon a request submitted by a user device 402 for an application, the application distribution server 420 may retrieve the requested application from the application data store 422 and transmit the requested application to the user device 402”; see also Bettger: ¶ 136 “The request generator 442 may request and/or receive identity information from user devices 402. For example, the request generator 442 may transmit a request to a user device 402 for data representing an identity of a user that operates the user device 402. The user device 402 may then prompt the user to provide one or more inputs that uniquely represent an identity of the user (for example, a multi-factor authentication factor, such as a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has). The user device 402 may convert the input(s) into one or more values (for example, an alphanumeric value, a hexadecimal value, a string value, etc.) and then apply a hash function to the value(s) to generate an identity hash code (also referred to as a “hash identity code”). In general, if the user device 402 or the contract authentication server 440 is attempting to apply a hash function to multiple inputs, the user device 402 or contract authentication server 440 can concatenate the inputs into a single string and apply a hash function to the single string, where each input may or may not be separated with a divider (for example, an underscore character, a number appended to the front or back of an input that identifies a length of the input, etc.). The user device 402 may then transmit the identity hash code to the request generator 442 to satisfy the request. Alternatively, the request generator 442 may receive the identity hash code without requesting such information (for example, the user device 402 prompts the user to provide one or more inputs that uniquely represent an identity of the user when the application retrieved from the application distribution server 420 is first installed, when a user makes a selection to provide the input(s), etc.). Once the identity hash code is received, the request generator 442 can store the identity hash code in the user identity data store 446 in an entry associated with the user operating the user device 402 and/or the user device 402 itself.”; see also Bettger: ¶ 152 “each time a transaction authorization request is received, the user device 402 may prompt the user to provide one or more inputs that uniquely represent the user and the user device 402 may perform the process described herein to generate a new copy of the first data”; and ¶ 157 “The first data generation routine 520 may be performed when the application retrieved from the application distribution server 420 is first initialized, when a user initiates an action to enter input(s) uniquely representing the user, and/or when the user device 402 is attempting to generate a hash contract to authorize a transaction (for example, in response to reaching block 510 when executing the hash contract generation routine 500) or a decline hash code to decline a transaction. The first data generation routine 520 begins at block 522”; see also Bettger: ¶ 172 “The user device 402 may generate the symmetric key based on a master key that is derived using a unique initialization key embedded in an application retrieved from the application distribution server 420. The contract authentication server 440 may have generated the unique initialization key that is embedded in the application retrieved from the application distribution server 420 and executed by the user device 402. Thus, the contract authentication server 440 may generate the symmetric key based on a master key that is derived from the generated unique initialization key. The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined). Additional details regarding the generation of the symmetric key are described below with respect to FIGS. 8A-8B.”; see also ¶ 365: “the identity hash and/or the authentication hash can, by themselves, be used to grant or deny a user and/or a user device 402 access to resources of a system. For example, a user device 402 can generate an identity hash in a manner as described herein and a system (for example, the contract authentication server 440 and/or any other system that provides users access to resources, such as secure or confidential content, data storage space, data processing capabilities, etc.) can compare the identity hash generated by the user device 402 to an identity hash previously received from the user device 402 (or another user device 402 operated by the user). If the comparison yields a match, the system can grant the user or the user device 402 access to the provided resource. If the comparison does not yield a match, the system can deny the user or the user device 402 access to the provided resource. Similarly, a user device 402 can generate an authentication hash in a manner as described herein and a system can compare the authentication hash generated by the user device 402 to an authentication hash previously received from the user device 402 (or another user device 402 operated by the user). If the comparison yields a match, the system can grant the user or the user device 402 access to the provided resource. If the comparison does not yield a match, the system can deny the user or the user device 402 access to the provided resource.”).
Examiner notes that Bettger further discloses that the consideration of the formed contract be corresponding or associated to a physical location (see at least Bettger: ¶ 245 “The merchant storefront 1302 can then transmit a transaction request to a merchant bank 1304 at (2). The merchant bank 1304 may be a bank that manages a bank account for the merchant storefront 1302. If the transaction is approved, then the user's credit card issuing bank, represented here as the contract authentication server 440, may pay the merchant bank 1304 the transaction amount (or some percentage thereof) and the merchant bank 1304 may credit the account of the merchant storefront 1302 with the transaction amount (or some percentage thereof). The transaction request may include transaction metadata, such as at least one of a date, an identification of one or more entities (for example, the merchant storefront 1302, a name of the entity that operates the contract authentication server 440, a name of the user associated with the user device 402, etc.), an amount (for example, zero or non-zero), a location at which the transaction was initiated, an item corresponding to the transaction, terms and conditions, and/or the like.”).
transmitting a third communication to one or more client devices via a uniform resource locator address, wherein the third communication includes instructions that cause the one or more client devices to generate a authentication object, wherein the authentication object includes a first user key of the two or more user keys, wherein the uniform resource locator includes a single-use encrypted string generated using an identifier of the first computing device, wherein the third communication is transmitted in response to receiving a response to the first communication that includes an indication that the transfer request is authentic, wherein the one or more client devices include the second computing device (see at least Bettger: ¶ 122-123 “a user device 402 may communicate with the application distribution server 420 and/or the contract authentication server 440 to authorize transactions or otherwise enter into contracts… The application distribution server 420 can be located local to the application data store 422 and/or the contract authentication server 440 (for example, in the same building or complex as the application data store 422 and/or the contract authentication server 440) or remote from the application data store 422 and/or the contract authentication server 440 (for example, located in a geographic location that is different than the location of the application data store 422 and/or the contract authentication server 440). In some embodiments, the application distribution server 420 may include additional components than illustrated in FIG. 4.”; see also Bettger: ¶ 125-128 “he application data store 422 may store applications generated by the contract authentication server 440 for distribution to user devices 402 (described below). The application data store 422 may store multiple versions of the same application. For example, as described in greater detail below, while the contract authentication server 440 may offer the same application to multiple user devices 402, each application may be embedded with a unique initialization key. Thus, each application version stored in the application data store 422 may include a unique initialization key. Alternatively, as described in greater detail below, the application data store 422 may store a single version of the same application, and a unique initialization key can be derived independently by the user device 402 and the contract authentication server 440 based on communications between the two.”; see at least Bettger: ¶ 136 “The request generator 442 may request and/or receive identity information from user devices 402. For example, the request generator 442 may transmit a request to a user device 402 for data representing an identity of a user that operates the user device 402”);
Bettger discloses transmitting a third communication to one or more client device configured to generate an authorization object in response to receiving a response to the first communication that includes an indication that the transfer request is authentic, wherein the one or more client devices include the second computing device (see at least Bettger: ¶ 122 “complex use cases, a user device 402 may communicate with the application distribution server 420 and/or the contract authentication server 440 to authorize transactions or otherwise enter into contracts. The application distribution server 420 can be a computing system (for example, with physical hardware, such as one or more processors, memory, graphical processing power, input/output devices, an internal bus, etc.) configured to distribute applications (for example, mobile applications, desktop and/or laptop applications, other stand-alone third party applications, etc.) to various user devices 402.” and ¶ 126; see also Bettger: ¶ 152 “each time a transaction authorization request is received, the user device 402 may prompt the user to provide one or more inputs that uniquely represent the user and the user device 402 may perform the process described herein to generate a new copy of the first data. Thus, if an unauthorized or malicious user attempts to authorize a transaction and cannot provide the one or more inputs that uniquely represent the user, then the new copy of the first data generated by the user device 402 would not match the first data originally received by the contract authentication server 440 and the transaction authorization would ultimately fail (for example, because the hash contract generated by the user device 402 would not match the hash contract generated by the contract authentication server 440 given that different inputs would be used by each device in generating the hash contracts)”; see also Bettger: ¶ 157 “The first data generation routine 520 may be performed when the application retrieved from the application distribution server 420 is first initialized, when a user initiates an action to enter input(s) uniquely representing the user, and/or when the user device 402 is attempting to generate a hash contract to authorize a transaction (for example, in response to reaching block 510 when executing the hash contract generation routine 500) or a decline hash code to decline a transaction. The first data generation routine 520 begins at block 522”; see also Bettger: ¶ 172 “The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined).”; see also Bettger: ¶ 183 “The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined).”; see also Bettger: ¶ 193 “The contract authentication server 440 may have generated the unique initialization key that is embedded in the application retrieved from the application distribution server 420 and executed by the user device 402. Thus, the contract authentication server 440 may generate the symmetric key based on a master key that is derived from the generated unique initialization key. The retrieved symmetric key may be a single-use key (for example, a new symmetric key is generated each time the user device 402 receives a transaction authorization request and/or each time the contract authentication server 440 verifies whether a transaction was authorized or declined). Additional details regard