DETAILED ACTION
This is office action on the merits in response to the application filed on 04/27/2026.
Claims 1-20 have been filed by the applicant.
Claims 5 and 15 were previously canceled.
Claims 2 and 12 are presently canceled.
Claims 1, 4, 8-9, 11 and 18-19 are currently amended.
Claims 1, 3-4, 6-11, 13-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 .
Response to Arguments
Rejection under 101:
The claims now recite a process of receiving an authorization request, retrieving previously stored data, comparing received and stored data, authorizing the request, which is an abstract idea of commercial interaction to authorize a transaction. The claims also involve scrambling and truncating the data which is an abstract idea of mathematical concept.
In the previous office action, the examiner responded that scrambling and truncating data can also be considered as the abstract idea of mitigating risks in respect to data security. The applicant traverses to the response and argues that scrambling and truncating data does not fit the category of mitigating risks because the claims does not recite a financial process. The examiner respectfully disagrees. The claims involve payment processing network authorizing request which is a financial activity. In addition, the applicant also states that scrambling and truncating data provides data security [0012], so it fits mitigating risks. Not only that, scrambling and truncating data can also be considered as mental process because a person can easily perform these by using pen and paper.
In the previous office action, the examiner responded that “scrambling data and comparing truncating data” does not provide technical improvement. The applicant further argues that processing less data results in resource savings. The examiner agrees that this will result in resource savings. However, there is no technical improvement by doing so because the computer functionality is not improved technologically, instead it works generically to compare data. In addition, although comparing less data results in resource savings, it is also understood by person in the art that additional steps of scrambling and truncation will require additional computer resource. As discussed during the interview and disclosed in specification [0014], using altered data is to comply with laws and regulations, which could potentially be an abstract idea of legal obligation.
The applicant further cites Example 40 of PEG and argues that the claims provides efficiency and integrate the abstract idea into a practical application. The examiner respectfully disagrees. As discussed above, comparing truncated data itself is an abstract idea. Therefore, by combining multiple abstract ideas, the claims as a whole is still an abstract idea.
The applicant further cites McRO, Inc. and argues that the claims provides a different way to verify. The examiner respectfully disagrees. The present claims are dealing with distinct field of endeavor and as discussed above, the process still verify the same by comparing. Additional steps of altering data does not change the data still needs to be matched to authorize.
Therefore, 101 rejection is maintained.
Rejection under 103:
The applicant argues that Purves is deficient because Purves discloses retrieving account data based on hashed data but the hashed data is not an account identifier as recited in the claims. The examiner respectfully disagrees. Velur discloses comparing hashed account identifier and based on that further comparing truncated user data [0119 0123 0128-0129]. Velur does not discloses retrieving user data based on hashed account identifier. Purves is introduced to disclose retrieving user data based on hashed data, Purves does not need to specifically disclose account identifier.
The applicant further argues that Velur discloses hashing and/or truncation is specific to one credential instead of separating steps. The examiner respectfully disagrees. Velur discloses various embodiments of how data is being processed and compared, Velur clearly discloses separate process to match a hashed credential then to further compare truncated credential based on matched hashed data [0128]. Although Velur has minor different on which data point is hashed/truncated, the Velur still teach the same process as recited in the claims as Velur hashes/truncates all the data points. It would have been understood that switching around data points would result the same.
The applicant further argues that there is no motivation for combining different embodiments of Velur. The examiner respectfully disagrees. It clearly states that the system is for creating rapid searchable databased which includes combination of disclosed embodiments [0036].
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, 3-4, 6-11, 13-14 and 16-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, 3-4 and 6-10 are directed to a method, claims 11, 13-14 and 16-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, via a hashing algorithm, the account number;
retrieving, by the computing device, based on the scrambled account number, truncated data for the account previously stored in a memory, based on a prior authorization response from the issuer, and linked to the scrambled account number, the truncated data including a prior truncated expiration date, a prior truncated physical address, and a prior truncated verification code, the truncated data including reduced data, as compared to original data for the truncated data;
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, via a hashing algorithm, the account number;
retrieving, by the computing device, based on the scrambled account number, truncated data for the account previously stored in a memory, based on a prior authorization response from the issuer, and linked to the scrambled account number, the truncated data including a prior truncated expiration date, a prior truncated physical address, and a prior truncated verification code, the truncated data including reduced data, as compared to original data for the truncated data;
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 3 and 13 further recite steps of truncating data of reserving digits of 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 and truncated CVC which are data used in abstract idea. 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, 3-4, 6, 8, 10, 13-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, via a hashing algorithm, 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. A hashed value can be determined using a suitable hash function (e.g., HMAC SHA256, SHA384, SHA512, MD5, MD6, etc. [0023 0123] Fig. 6-610)
truncated data for the account previously stored in a memory, […], and linked to the scrambled account number, the truncated data including a prior truncated expiration date, […], and a prior truncated verification code, the truncated data including reduced data, as compared to original data for the truncated data. (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)
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 for the account previously stored in a memory, based on a prior authorization response from the issuer. (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 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; and wherein the truncated CVC includes only two 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:
Purves further teaches receiving, by the computing device, the prior authorization response, the prior authorization response including the account number for the account, the expiration date associated with the account number, and the verification code specific to the account, as an indication of validation of the account number, the expiration date, and the verification code by the at least one issuer; scrambling, by the computing device, via the hashing algorithm, the account number from the prior authorization response; truncating, by the computing device, the expiration date and verification code from the prior authorization response to form the prior truncated expiration date and the prior truncated verification code; and storing the prior truncated expiration date and the prior 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. Further, the intermediary server computer may conduct an enrollment process for one or more accounts of the user, where the accounts may be hosted by different entities. For example, the one more accounts may each be issued by a different issuer. Accordingly, the intermediary server computer may enable the user to utilize account data originating from different account issuers for a transaction, even when the user may not enter any account information during the transaction. [0007 0026]).
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 to store altered user information prior to authorization request with the technique as disclosed by Purves to protect user data as Purves suggested [0125].
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 response, with a cryptographic algorithm, prior to storing the treated, truncated expiration date and the treated, truncated verification code from the prior authorization request. However,
Huxham teaches further comprising treating the truncated expiration data and truncated verification code from the prior authorization response, with a cryptographic algorithm, prior to storing the treated, truncated expiration date and the treated, truncated verification code from the prior authorization request. (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.).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights