DETAILED ACTION
This is office action on the merits in response to the application filed on 12/01/2025.
Claims 1-20 have been filed by the applicant.
Claims 5 and 15 were previously canceled.
Claims 1 and 11 are currently amended.
Claims 1-4, 6-14 and 16-20 are currently pending and have been examined.
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 .
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 12/01/2025 has been entered.
Response to Arguments
Rejection under 101:
The applicant argues that the claims recite improvement to the security by scrambling and truncating data. The examiner respectfully disagree. The examiner had responded to this argument in previous office action. Even to further consider the aspect of data security, such process is consistent with the abstract idea of mitigating risks by altering original data.
The applicant further argues that the altered data reduce the comparison process with truncated data. The examiner respectfully disagree. Although truncated data seems to require less process, the technology is not improved because the process would be the same whether the data is truncated or in original form.
Therefore, 101 rejection is maintained.
Rejection under 103:
The applicant argues that the rejection is combining multiple embodiment of Velur and the examiner does not provide the motivation to combine. However, Velur states that it is apparent to those skilled in the art upon review of the disclosure, features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention [0147, 0150- 0151]. Velur further states that it is to create a rapid searchable database by utilizing single embodiment or combination of embodiments of the disclosure [0036].
The examiner agrees the current prior arts do not teach the amended limitation. New prior art is provided, see 103 rejections below.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-10 are directed to a method, claims 11-20 are directed to a system comprising a memory and a processor. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claim 11, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
A computer-implemented method for enabling stand-in network services for one or more issuers based on truncated data, the computer-implemented method comprising:
receiving, by a computing device of a processing network, from an acquirer, an authorization request, the authorization request including an account number for an account, an expiration date associated with the account number, a physical address associated with the account, and a verification code specific to the account, the processing network separate from an issuer of the account;
in response to an issuer of account being unreachable, whereby the processing network stands in for the issuer:
scrambling, by the computing device, the account number;
retrieving, by the computing device, based on the scrambled account number, truncated data for the account from a memory;
truncating, by the computing device, the expiration date, the physical address associated with the account, and verification code from the authorization request;
comparing the truncated expiration date, the truncated address, and the truncated verification code to the retrieved truncated data; and
in response to a match between the truncated expiration date, the truncated verification code, and the retrieved truncated data, compiling and transmitting an authorization response.
Limitations A, B, D, F and G under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer hardware in limitation A through F, nothing in the claim element differentiates the limitation from processes of commercial interactions. Therefore, limitations A, B, E, G and H recite an abstract idea, as highlighted above, that is consistent with commercial interactions aspects of certain method of organizing human activities.
Furthermore, limitation D and F recites “scrambling…the account number” and “truncating….the expiration date and verification code” which is reciting the mathematical functions. The remaining highlighted portion of limitation C and F recites a generic computer used to implementing the mathematical functions.
Accordingly, claim 1, and by analogy similar claim 11, recite at least two abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
A computer-implemented method for enabling stand-in network services for one or more issuers based on truncated data, the computer-implemented method comprising:
receiving, by a computing device of a processing network, from an acquirer, an authorization request, the authorization request including an account number for an account, an expiration date associated with the account number, a physical address associated with the account, and a verification code specific to the account, the processing network separate from an issuer of the account;
in response to an issuer of account being unreachable, whereby the processing network stands in for the issuer:
scrambling, by the computing device, the account number;
retrieving, by the computing device, based on the scrambled account number, truncated data for the account from a memory;
truncating, by the computing device, the expiration date, the physical address associated with the account, and verification code from the authorization request;
comparing the truncated expiration date, the truncated address, and the truncated verification code to the retrieved truncated data; and
in response to a match between the truncated expiration date, the truncated verification code, and the retrieved truncated data, compiling and transmitting an authorization response.
The additional element(s) in limitation A through H merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). As such, when the additional elements are considered individually and as an ordered combination, the claim as a whole amounts to no more than or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept. Therefore, claims 1 and 11 are not patent eligible.
Dependent claims 2 and 12 further recite hashing account number via a one-way hash which is further reciting the abstract idea of mathematical concepts. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 3 and 13 further recite steps of truncating data which is further reciting the abstract idea of mathematical concepts. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 4 and 14 further recite CVC code. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 5 and 15 further recite truncating and comparing an address which is further reciting both abstract idea of mathematical concepts and commercial interactions. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 6 and 16 further recite steps of truncating address which is further reciting the abstract idea of mathematical concepts. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 7 and 17 further recite steps of treating data with cryptographic algorithm which is further reciting the abstract idea of mathematical concepts. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 8 and 18 further recite process of registering account information which involves receiving information, scrambling information, truncating information, and storing information which is further reciting both abstract idea of mathematical concepts and commercial interactions. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea because the additional element merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)).
Dependent claims 9 and 19 further recite steps of treating data with cryptographic algorithm which is further reciting the abstract idea of mathematical concepts. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
Dependent claims 10 and 20 further recite appending a value into the authorization response which is further reciting the abstract idea of commercial interaction. The claim does not recite additional elements that recite a practical application nor significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-4, 6, 8, 10-14, 16, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Velur et al. (US 20200272612 A1), and further in view of Brown (US 20030105688 A1) and Purves (US 20170024733 A1).
With respect to claim 1 and 11:
Velur teaches (in italic):
receiving, by a computing device of a processing network, from an acquirer, an authorization request, the authorization request including an account number for an account, an expiration date associated with the account number, […] and a verification code specific to the account, the processing network separate from an issuer of the account. (A user may conduct an interaction with a resource provider, which operates a resource provider computer 606, using a user device 602 at an access device 604. The interaction may be a payment transaction. the user may indicate interaction data to the resource provider computer 606 electronically, such as in an online interaction. In some embodiments, the user device 602 may transmit a credential to the access device 604. The credential can include, as an illustration, a primary account number, an expiration date, a verification value, etc. After generating the authorization request message, the resource provider computer 606 can transmit the authorization request message to the transport computer 608. At step 5, after receiving the authorization request message, the network processing computer 610 can determine whether or not the credential is associated with a data item of a plurality of data items stored in the database. [0119-0123] Fig. 6-606, 610)
scrambling, by the computing device, the account number. (The network processing computer 610 can perform any suitable altered data search method described herein. For example, the network processing computer 610 can hash the received credential to form an altered value. [0123] Fig. 6-610)
truncating, by the computing device, the expiration date […] and verification code from the authorization request; comparing the truncated expiration date […] and the truncated verification code to the retrieved truncated data. (After matching the altered value to a stored hashed value of the first plurality of hashed values, the network processing computer 610 can repeat the above process to create a third truncated credential, ... and compare the third truncated credential to stored hashed values of a second plurality of stored hashed values. The credential can include, as an illustration, a primary account number, an expiration date, a verification value, etc. [0119 0128-0129] Fig. 6-610)
in response to a match between the truncated expiration date, the truncated verification code, and the retrieved truncated data. (Thus, when the network processing computer 610 determines that a received credential when altered into the altered value matches a stored hashed value, the network processing computer 610 can determine the stored range by following an index between the matched value and the range. After determining the range, the network processing computer 610 can determine a data item associated with the range. For example, the network processing computer 610 can receive interaction data in the authorization request message from the transport computer 608. The network processing computer 610 can determine if interaction data satisfies the criteria of the data item. The credential can include, as an illustration, a primary account number, an expiration date, a verification value, etc. [0119 0133-0135] Fig. 6-610)
compiling and transmitting an authorization response back to the acquirer. (At step 8, the authorizing entity computer 612 can generate and transmit an authorization response message to the network processing computer 610. The network processing computer 610 can transmit the authorization response message to the transport computer 608. At step 10, the transport computer 608 can then send the authorization response message back to the resource provider computer 606. The authorization response message can comprise the indication of whether or not the interaction is authorized. In some embodiments, the authorization response message can further comprise the data item and/or the credentials. [0008 0143-0145] Fig. 6-610, step 9-10)
Velur does not explicitly teach the following limitations. However,
Brown teaches:
in response to an issuer of the account being unreachable, whereby the processing network stands in for the issuer. (It is also foreseeable that in some cases, when an issuer is unavailable for authorization, a proprietary network will authorize the escrow account transaction as a part of a stand-in processing service. The message is then switched, for example, through VisaNet, or other proprietary network to the card issuer. [0050-0055])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Velur to use processing network stands in for issuer with the technique as disclosed by Brown to enhance payment system efficiency as Brown suggested [0055].
Velur in view of Brown does not explicitly teach the following limitations. However,
Purves teaches:
retrieving, by the computing device, based on the scrambled account number, truncated data for the account from a memory. (Account data retrieval submodule 414A, in conjunction with data processor 408, may then compare the hashed user data and hashed enrollment data, determine hashed user data and hashed enrollment data that match, and obtain payment account data associated with the hashed enrollment data. [0092])
a physical address associated with the account. (“User data” may refer to any information surrounding a user conducting a transaction. User data may include alias identifiers (e.g., email address, phone number, etc.) associated with the user and device identifiers (e.g., cookies) associated with a mobile device operated by the user. In some cases, user data may also include a name, contact information, and a location associated with the user. [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Velur in view of Brown to retrieve account information based on scrambled user data with the technique as disclosed by Purves to protect user data using hash function as Purves suggested [0125].
Claim 11, a system with the same scope as claim 1, is rejected.
With respect to claim 2 and 12:
Velur further teaches a wherein scrambling the account number includes hashing the account number via a one-way hash. (A hashed value can be determined using a suitable hash function (e.g., HMAC SHA256, SHA384, SHA512, MD5, MD6, etc.). [0023])
Claim 12, a system with the same scope as claim 2, is rejected.
With respect to claim 3 and 13:
Velur further teaches wherein truncating the expiration date includes reserving only one digit of a month and a year of the expiration date; and wherein truncating the verification code includes reserving only a first digit and a last digit of the verification code. (then the network processing computer 610 can truncate the credential to a first predetermined number of digits (e.g., 4 digits, 8 digits, 9 digits, 13 digits, etc.). [0130]).
Velur suggested various length of truncated data. It would have been obvious to truncate data into any length as design choice and the result would expected to be the same.
Claim 13, a system with the same scope as claim 3, is rejected.
With respect to claim 4 and 14:
Velur further teaches wherein the verification code includes a card verification (CVC) code having three digits. (a CVV (card verification value), a dCW (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, etc. [0021]).
Claim 14, a system with the same scope as claim 4, is rejected.
With respect to claim 6 and 16:
Velur further teaches wherein truncating the address includes reserving only a house number of the address and a postal code of the address. (then the network processing computer 610 can truncate the credential to a first predetermined number of digits (e.g., 4 digits, 8 digits, 9 digits, 13 digits, etc.). [0130]).
Velur suggested various length of truncated data. It would have been obvious to truncate data into any length as design choice and the result would expected to be the same.
Claim 16, a system with the same scope as claim 6, is rejected.
With respect to claim 8 and 18:
Velur further teaches receiving, by the computing device, a prior authorization request, the prior authorization request including the account number for the account, the expiration date associated with the account number, and the verification code specific to the account; scrambling, by the computing device, the account number from the prior authorization request; truncating, by the computing device, the expiration date and verification code from the prior authorization request; and storing the truncated expiration date and the truncated verification code in the memory, in association with the scrambled account number, prior to receiving the authorization request. (In some embodiments, the method further comprises receiving, by the server computer prior to the transaction, the enrollment data from the mobile device and sending a request for the account data of the user to an authorization computer. The method further comprises receiving, by the server computer, the account data from the authorization computer and storing the account data in association with the enrollment data. [0007]).
Claim 18, a system with the same scope as claim 8, is rejected.
With respect to claim 10 and 20:
Velur further teaches wherein compiling the authorization response includes appending a value associated with a result of the comparison of the truncated expiration date and the truncated verification code to the retrieved truncated data. (The authorization response message can comprise the indication of whether or not the interaction is authorized. In some embodiments, the authorization response message can further comprise the data item and/or the credentials. It is understood that the data item can include any suitable data item described herein. For example, a data item can include data identifying a particular encryption process, data identifying a routing table that can determine to which computers a request message can be forwarded based on received value (e.g., a credential) associated with the data item, or data identifying a communication channel on which subsequent communications may occur. [0137 0143]).
Claim 20, a system with the same scope as claim 10, is rejected.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Velur" “Brown” and "Purves" as applied to claim 1 and 11 above, and further in view of Huxham (US 20170024729 A1).
With respect to claim 7 and 17:
Velur in view of Brown and Purves does not teach further comprising treating the truncated expiration data and truncated verification code, with a cryptographic algorithm, prior to comparing the treated, truncated expiration date and the treated, truncated verification code to the retrieved truncated data. However,
Huxham teaches further comprising treating the truncated expiration data and truncated verification code, with a cryptographic algorithm, prior to comparing the treated, truncated expiration date and the treated, truncated verification code to the retrieved truncated data. (encrypting the second payment credential portion using the payment credential encryption key, the second payment credential portion together with a first payment credential portion provided to the payment processor [0008])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Velur in view of Brown and Purves to set a waiting period with the technique as disclosed by Huxham to securely transmitting payment credentials as Huxham suggested [0008].
Claim 17, a system with the same scope as claim 7, is rejected.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Velur" “Brown” and "Purves" as applied to claim 8 and 18 above, and further in view of Huxham (US 20170024729 A1).
With respect to claim 9 and 19:
Velur in view of Brown and Purves does not teach further comprising treating the truncated expiration data and truncated verification code from the prior authorization request, with a cryptographic algorithm, prior to storing the treated, truncated expiration date and the treated, truncated verification code from the prior authorization. However,
Huxham teaches further comprising treating the truncated expiration data and truncated verification code from the prior authorization request, with a cryptographic algorithm, prior to storing the treated, truncated expiration date and the treated, truncated verification code from the prior authorization. (encrypting the second payment credential portion using the payment credential encryption key, the second payment credential portion together with a first payment credential portion provided to the payment processor [0008])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Velur in view of Brown and Purves to set a waiting period with the technique as disclosed by Huxham to securely transmitting payment credentials as Huxham suggested [0008].
Claim 19, a system with the same scope as claim 9, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20030191709 A1: When the payment system server receives transaction data with hashed account numbers the transaction manager (10) performs a lookup in the customer account (28) to retrieve the unencrypted payment account number (possibly using a reference indicator 1002 if more than one payment account is active). The actual payment account number is then used for processes such as transaction logging in the ledgers (32) and data warehouse (38) and settlement processes executed by the settlement manager (20).
US 20190052467 A1: Thus, if the user provided the correct information when approving the transaction (for example, accurate values for the input(s) that uniquely represent the user such that the identity hash code generated by the user device 402 matches the identity hash code stored in the user identity data store 446 that was previously provided by the user device 402), then the hash comparator 445 determines that the transaction is approved. Otherwise, if the user did not provide the correct information when approving the transaction, the hash comparator 445 determines that an error occurred and may suspend the user's account and/or notify the user device 402 of the issue. The hash comparator 445 can transmit the transaction result (for example, an approval) to the merchant storefront payment device 1302 at (17), which results in the merchant storefront payment device 1302 allowing the transaction to be completed.
US 20190197522 A1: At 706, the method 700 includes retrieving issuer account information associated with the issuer account based on at least a part of the payment string upon successful validation of the payment string. In one embodiment, the issuer account information may be retrieved by matching a predefined length alphanumeric code (chord 510) in a mapping table from a database. The predefined length alphanumeric code is a part of the payment string.
US 20200294043 A1: The lookup request 31a is enacted at the PSP 104, which decrypts the encrypted data received from the PED driver 126 and converts the PAN of the payment card to a hashed PAN using a predetermined algorithm via the PSP agent. Although not shown here, the hashed pan is then communicated, along with the merchant ID for identification of the correct loyalty programme, to the external exchange server 106, which compares the hashed PAN and merchant ID with pre-existing databases.
US 20210019061 A1: Further, in some embodiments, the processing of the input data via the physical memory area of temporary storage may include retrieving the cryptographic hash of the input data from the physical memory area (for example, memory area 302) and comparing the cryptographic hash of the input data to cryptographic hashes of other data (for example, credential data) stored in, for example, non-volatile memory 210, register 218, or cache 220. In some embodiments, the processing of the input data via the physical memory area of temporary storage may further include determining whether the cryptographic hash of the input data matches a cryptographic hash of the credential data and in response to the determination that the cryptographic hash of the input data matches the cryptographic hash of the credential data, authenticate a user, authorize (or causing other services to authorize) access (for example, access to the network device 104, access to network resources on a secure network, including access to email accounts, bank accounts, document repositories, network attached storage devices, and various other network-accessible services accessible on a secure network, access to the application via which the identification information is received, or access to another application accessed on one or more network devices 104 (for example, different from the network device 104 via which the identification information was obtained or the same network device 104 via which the identification information was obtained)), or approve a user's initiated action (for example, initiated action to change contact data, pin or password, payment data, etc.).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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, Patrick McAtee can be reached on (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698