DETAILED ACTION
Status of Claims
Claims 1, 5-7, 21, and 23-24 have been amended.
Claims 1-24 are currently pending and have been considered by the examiner.
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 13 November 2025 has been entered.
Response to Arguments
101 Rejection:
Applicant asserts that the claims recite “a sequence of steps in which contextual information is continuously updated during authentication, the server recalculates verification information in response to each update, and the recalculated verification information is compared to the transaction identifier to determine validity” and that “This iterative recalculation and comparison process integrates the abstract into a concrete, non-conventional authentication method that improves fraud detection and reduces complexity in a way no taught or suggested by conventional systems” on pg. 11 of the remarks received 7 October 2025.
The examiner respectfully disagrees. When considering the BRI of the independent claims, neither claims 1, 23, or 24 recite any steps or functionality directed towards either the invention updating contextual information, a server recalculating verification information, or comparing recalculated information. The claims merely broadly recite the step of authenticating, by a generic server, first transaction data based on one or more data types and one or more data characteristics. The independent claims make no mention about how said data types and data characteristics are used in the claimed step of authentication, merely describing the data used without sufficiently linking the recited descriptive material to the claimed step of authentication (i.e. “the contextual information being continuously updated during authentication of the first transaction data by the server” merely describes the contextual information at the moment in time that the authentication is performed by the server and makes no mention of how the server interacts with, influences, or utilizes the contextual information. The limitation constitutes nonfunctional descriptive material) and thus the claimed step of authentication cannot be considered to include the functionality described by applicant above as it is not present within the scope of the claimed invention. Thus, as these additional elements are not recited in the claims, these additional elements, regardless of any potential benefit provided by them, cannot be considered to integrate the recited abstract idea into practical application, nor amount to significantly more than simply generally linking the use of a generic computer to the recited abstract idea. Therefore, the examiner must maintain the previously issued 101 rejection. Applicant’s additional arguments have been considered and have been deemed unpersuasive by the examiner based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant’s arguments have been considered and have been deemed unpersuasive regarding independent claims 1 and 23-24 based on the rationale provided in the following prior art rejection. Additionally, applicant’s arguments with regard to claims 5-7 have been considered and have been deemed unpersuasive based on the rationale provided in the following prior art rejection.
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-24 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, claim 1-22 are directed towards a method, claims 23 is directed to a system/apparatus, and claim 24 is directed towards a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method comprising:
providing, by a first device associated with a user, first transaction data to a second device, wherein the first transaction data corresponds to a transaction identifier, wherein the transaction identifier comprises one or more data types and one or more data characteristics, and wherein the second device is configured to permit an electronic transaction of the first device;
providing, by the first device or the second device, the first transaction data to a server based on a routing identifier; and
authenticating, by the server, the first transaction data based on the one or more data types and the one or more data characteristics, wherein:
the one or more data types comprise: dynamically generated and continuously updated contextual information, the contextual information being continuously updated during authentication of the first transaction data by the server and comprising one or more parameters associated with a generation of the transaction identifier,
the dynamically generated and the continuously updated contextual information is configured to reduce authentication complexity, and
the dynamically generated and the continuously updated contextual information corresponds to verification information comprised in the transaction identifier.
Regarding Step 2A Prong One, the claims recite the abstract idea of risk mitigation. Specifically, the claims recite the limitations underlined above which recite the process of mitigating risk in an economic transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of mitigating risk in an economic transaction. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “first device”, “second device”, and “server” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “first device”, “second device”, and “server” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “first device”, “second device”, and “server” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “first device”, “second device”, and “server” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite risk mitigation. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-22 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claims 2, 9-12, 16-18, and 20-22 merely further describe the data used to perform recited abstract idea.
Claims 3-4, 14-15, and 19 recite additional limitations which are either directed towards the recited abstract idea of risk mitigation or constitute steps required to perform the recited abstract idea using a computer.
Claim 5 recites additional limitations directed towards further description of the claimed method step of authenticating, specifically towards the recalculation of verification information and comparison of recalculated information to determine authentication validity. However, the additional elements do not appear to provide any technical improvement to the functioning of a generic computer, but rather an improvement to the recited abstract idea itself. I.e. the functionality of the computer which performs the recited abstract idea does not exceed the typical function and capabilities of a generic computing device and thus any improvement derived from the sequence of steps that does not clearly provide a technical improvement to the functioning of a generic computer cannot be considered to be anything more than simply linking the recited abstract idea to the technical field of generic computing devices. Thus, the claim is not patent eligible under 35 USC 101.
Claim 6 recites additional limitations directed towards further description of the claimed method step of authenticating, specifically towards the detecting of a change in the contextual information and recalculating verification information to determine authentication validity. However, the additional elements do not appear to provide any technical improvement to the functioning of a generic computer, but rather an improvement to the recited abstract idea itself. I.e. the functionality of the computer which performs the recited abstract idea does not exceed the typical function and capabilities of a generic computing device and thus any improvement derived from the sequence of steps that does not clearly provide a technical improvement to the functioning of a generic computer cannot be considered to be anything more than simply linking the recited abstract idea to the technical field of generic computing devices. Thus, the claim is not patent eligible under 35 USC 101.
Claim 7 recites additional limitations directed towards further description of the claimed method step of authenticating, specifically towards generation of a single recalculated verification value as a substitute for several authentication factors (generic data consolidation). However, the additional elements do not appear to provide any technical improvement to the functioning of a generic computer, but rather an improvement to the recited abstract idea itself. I.e. the functionality of the computer which performs the recited abstract idea does not exceed the typical function and capabilities of a generic computing device and thus any improvement derived from the sequence of steps that does not clearly provide a technical improvement to the functioning of a generic computer cannot be considered to be anything more than simply linking the recited abstract idea to the technical field of generic computing devices. Thus, the claim is not patent eligible under 35 USC 101.
Claim 8 merely further describes limitations which are directed towards the abstract idea of risk mitigation.
Claim 13 recites additional elements which do not place the recited abstract idea into practical application nor amount to significantly more.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
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.
Claim(s) 1, 5, 7-11, 13-14, 17-19, 21-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Franklin et al. (US 6000832) in view of Wedekind et al. (US 20150032636 A1)..
In regards to Claims 1 and 23-24, Franklin discloses:
a method (Figs. 1-3) comprising: providing, by a first device (customer computer 28) associated with a user (customer), first transaction data (transaction numbers in Figs. 4-6) to a second device (merchant computer 30),
wherein the first transaction data corresponds to a transaction identifier, wherein the transaction identifier comprises one or more data types (private key and customer-specific data, e.g. cardholder name, account number; see abstract) and one or more data characteristics (transaction specific data, e.g. amount, merchant ID, goods ID, time, transaction date and etc.; see abstract, See Franklin: col. 9, lines 59-67 – “FIG. 4 shows the code number generation in more detail. The input parameters 68 are entered to the MAC coding unit 58, which then computes a MAC or code number as a function of the private key, the transaction-specific data, and the customer-specific data”), and
wherein the second device is configured to permit an electronic transaction of the first device; providinq by the first device or the second device, the first transaction data to a server (computing unit 30 implemented in the form of a computer server and computer 32…may be implemented such as a PC server; see col. 4 lines 15-21)
based on a routing identifier (the registration module 56 contains the necessary routing information to direct the application over the internet 34 to the bank computing center 32, see col. 7 lines 44-47; Prefix); and
authenticating, by the server, the first transaction data based on the one or more data types and the one or more data characteristics (See Franklin: col. 11, lines 33-38 – “The merchant computer 30 submits a request for authorization over a payment network 36 to the bank computing center 32 (flow arrow 1 in FIG. 7). The authorization request contains the transaction number and the transaction-specific data, such as the amount, time, date, merchant ID, goods ID, and so forth”)
wherein the one or more data types comprise: contextual information comprising one or more parameters associated with a generation of the transaction identifier (See Frankling: Fig. 4 and See Franklin: col. 11, lines 33-38 – “The merchant computer 30 submits a request for authorization over a payment network 36 to the bank computing center 32 (flow arrow 1 in FIG. 7). The authorization request contains the transaction number and the transaction-specific data, such as the amount, time, date, merchant ID, goods ID, and so forth” – Franklin discloses a transaction number/identifier used for authentication containing a transformed data representation of contextual information associated with its generation (transaction-specific data, customer-specific data, etc) in the form of an encoded MAC),
the contextual information being continuously updated during authentication of the first transaction data by the server (The examiner has determined that this limitations appears to constitute a recitation of nonfunctional descriptive material. Specifically, the limitation is directed towards a further description of the claimed contextual information which does not impart any functional limitation on any of the claimed method steps recited in the claim, merely describing the state of the contextual information at the same time as the claimed step of authenticating occurs without describing how the contextual information interacts with, influences, or further limits the claimed step of authentication. Thus, as the limitation constitutes non-functional descriptive material, the limitation cannot be given patentable weight. See MPEP 2114. For purposes of compact prosecution, the examiner will continue examination of this limitation as if it was given patentable weight)
the contextual information is configured to reduce authentication complexity (See Franklin: col. 9, lines 49-58 – “The transaction wizard calls the MAC coding unit 58 and inputs the private key (or other customer-related secret), the transaction-specific data, and any customer-specific data. The transaction-specific data and the customer-specific data both enhance the ability to generate a code number that is unique to one specific transaction between a particular customer and a particular merchant. It is noted, however, that these input parameters are pre-known or made available to both the customer and the merchant, without the customer and merchant communicating during the transaction” – Franklin discloses the condensing of multiple authentication factors into a singular data element. It is clear to one of ordinary skill in the art that such data compression would reduce authentication complexity)
wherein the contextual information is configured to increase a level of security (See Franklin: col. 12, lines 21-26 – “The MAC coding and comparator unit 82 compares the test MAC with the embedded MAC from the transaction number. If the two MACs match, the bank has a very high degree of certainty that the transaction number is valid and originated from the customer.”)
the contextual information corresponds to verification information comprised in the transaction identifier (See Franklin: col. 9, lines 49-58 – “The transaction wizard calls the MAC coding unit 58 and inputs the private key (or other customer-related secret), the transaction-specific data, and any customer-specific data. The transaction-specific data and the customer-specific data both enhance the ability to generate a code number that is unique to one specific transaction between a particular customer and a particular merchant. It is noted, however, that these input parameters are pre-known or made available to both the customer and the merchant, without the customer and merchant communicating during the transaction” – Franklin discloses contextual information (transaction-specific data, customer-specific data, etc) which is corresponds to a MAC contained within the transaction identifier)
However, Franklin fails to explicitly disclose:
Wherein the contextual information is dynamically generated and continuously updated and
the contextual information being continuously updated during authentication of the first transaction data by the server (If the limitation was given patentable weight)
However, in a similar field of endeavor, Wedekind discloses a method of generating payment credentials utilizing a random or pseudo-random hash algorithm the dynamically generate a unique transaction identifier (See Wedekind: Claim 19). It is understood by one of ordinary skill in the art that, within the context of computer algorithms, the output of a random or pseudo-random hash algorithm is a dynamically generated value (dynamically generated contextual information) which is then used to generated said unique transaction identifier. Additionally, when considering the BRI of the claimed term “continuously updated”, the examiner asserts that Wedekind’s disclosure of outputting dynamically generated values repeatedly is functionally equivalent to the BRI of “continuously updated” contextual information. Additionally, as the updating is being performed continuously, during the performance of a transaction, it can be reasonably concluded by one of ordinary skill in the art that said updating would necessarily occur at some time limit which would overlap with the claimed authentication process assuming the transaction was eventually executed.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the generic contextual information disclosed by Franklin for the dynamically generated contextual information obtained using a hash algorithm as disclosed by Wedekind yielding the predictable result of an increase in the security strength of the invention by ensuring that the transaction identifier is unique and cannot be reproduced due to the random nature of the employed hash algorithm.
In regards to Claim 5, the combination of Franklin and Wedekind discloses the method of claim 1, further comprising:
wherein authenticating by the server comprises recalculating verification information in response to each continuous update of the contextual information during authentication of the first transaction data, and comparing the recalculated verification information with the transaction identifier to determine authentication validity (See Franklin: col. 2, lines 55-64 – “he issuing institution then computes its own test code number using the same function utilized by the customer computer and the same input parameters (i.e., the private key, the customer-specific data from the account record, and the transaction-specific data received in the authorization request) … The issuing institution compares the test code number with the code number embedded in the transaction number. If the two numbers match, the issuing institution accepts the transaction number as valid and authentic.”), and
obtaining, by the first device, a transaction identifier generator; generating by the transaction identifier generator to generate at least one of one or more serial numbers and one or more transaction identifiers to initiate one or more electronic transactions. (See Franklin: Column 8, lines 43-48 & 60-64: floppy disk 64 is provided to the customer…customer loads the diskette and enters the password. If the password is correct… The MAC coding unit 58 and …are installed on the customer computer & Column 9 lines 59-67: “MAC coding unit 58, which then computes a MAC or code number” in Franklin et al.).
In regards to Claim 7, Franklin discloses:
wherein authenticating by the server comprises generating a single recalculated verification value from the continuously updated contextual information, the recalculated verification value replacing multiple separate authentication factors, and using the recalculated verification value to determine authentication validity (See Franklin: col. 2, lines 55-64 – “he issuing institution then computes its own test code number using the same function utilized by the customer computer and the same input parameters (i.e., the private key, the customer-specific data from the account record, and the transaction-specific data received in the authorization request) … The issuing institution compares the test code number with the code number embedded in the transaction number. If the two numbers match, the issuing institution accepts the transaction number as valid and authentic.”)
indirectly associating a serial number with the user (See Franklin: Column 8, lines 43-48 & 60-64: floppy disk 64 is provided to the customer…customer loads the diskette and enters the password. If the password is correct… The MAC coding unit 58 and …are installed on the customer computer & Column 9 lines 59-67: “MAC coding unit 58, which then computes a MAC or code number” in Franklin et al.).
In regards to Claim 8, Franklin discloses:
The method of claim 7, wherein the indirect association comprises: issuing one of a serial number and the transaction identifier to the user; providing the serial number and the transaction identifier available for use in one or more financial transaction by the user (col. 8, lines 43-48 “bank supplies…MAC coding unit 58”); accepting the transaction identifier for authentication by the server following use by the user in a financial transaction; authenticating the transaction identifier for authentication by the server following use by the user in the financial transaction; and or any combination thereof (Fig. 7: authorization phase).
In regards to Claim 9, Franklin discloses:
The method of claim 1, wherein the second device is configured and arranged to process the transaction identifier as a standard-compliant transaction identifier; the transaction identifier is standard-compliant; the routing identifier is the standard-compliant; and the standard is the International Organization for Standardization JISOJ-7812, Europay, MasterCard and Visa (EMVj, or any combination thereof (col. 10, lines 12-36: “Credit card numbers comply with a standardized format having four spaced sets of numbers, is represented by the number “XXXX XXXX XXXX XXXX” and col. 11, lines 19-23: “the merchant computer 30 treats the transaction number of the online commerce card no differently than it treats a standard credit card number” & proxy number in Figs. 5 and 6).
In regards to Claim 10, Franklin discloses:
The method of claim 9, wherein: at least one of the serial number and verification information are not compliant with the standard (the code number or MAC is not compliant to ISO-7812 since these digits/values cannot be located or accessed for further interpretation as defined in Paras. 0075-0082 of the specification of the instant application).
In regards to Claim 11, Franklin discloses:
The method of claim 1, wherein: the transaction identifier is similar to a primary account number (Figs. 5 and 6).
In regards to Claim 13, Franklin discloses:
The method of claim 1, wherein: the second device comprises a third device having a processor, and programmed to receive and transmit the transaction identifier and further comprising: providing by the first device, the transaction identifier to the third device, directly or through an intermediary, to initiate the electronic transaction. (Column 4, lines 14-16 computing unit 30 & merchant computer 30 in Fig. 3).
In regards to Claim 14, Franklin discloses:
The method of claim 1, wherein: initiatinq an electronic transaction if the authentication is valid, wherein at least one of the one or more data types and the one or more data characteristics are configured to be made unavailable for use after the initiation. (See Franklin: Claim 8).
In regards to Claim 17, Franklin discloses:
wherein the transaction identifier comprises a maximum of nineteen digits (See Franklin: Fig. 4-6).
In regards to Claim 18, Franklin discloses:
wherein the one or more data characteristics comprises a serial number, and wherein the serial number comprises a maximum of nine digits (See Frankling: col. 7-8, lines 65-67 and 1-4 – “For example, suppose the bank is issuing a credit card-like online commerce card having a 16-digit number. The account number assigned to the customer account might comprise the 16-digit number. The first five-to-seven digits are a bank related prefix, the next four digits are a customer identification number, the next four-to-six digits are reserved for a MAC number”).
In regards to Claim 19, Franklin discloses:
The method of claim 1, further comprising: after receiving the transaction identifier by the server, evaluating one or more parameters associated with at least one of the generation and use of the transaction identifier in the electronic transaction; and allowing initiation of the electronic transaction based on the evaluation of the parameters are evaluated to be acceptable.(See Franklin: Fig. 7: authorization phase).
In regards to Claim 21, Franklin discloses:
an algorithm used to generate the respective transaction identifier, a hardware used to generate the respective transaction identifier, a software used to generate the transaction identifier, or any combination thereof (column 10, lines 9-19: “This process creates a transaction number with an embedded code number (or MAC) that is specific to the online commerce transaction with the merchant… “the transaction number 70 has a seven-digit that is used for processing purposes. It identifies the issuing bank, the card type, and so forth”).
In regards to Claim 22, Franklin discloses:
The method of claim 1, wherein: the transaction identifier comprises: a network identifier associated with the server; a generator identifier associated with a generator of the transaction identifier; a processing indicator used by the server to processes the transaction identifier; a mapping server identifier for indicating to the server a second server to be used for the authentication; and or any combination thereof.
(See Franklin: Column 10, lines 17-19: “the transaction number 70 has a seven-digit that is used for processing purposes. It identifies the issuing bank, the card type, and so forth” and in Column 10, lines 32-35: “The four-digit MAC follows the customer ID. This number is generated by the customer computer based on a unique set of input parameters, some of which are known only to customer and bank & 70 &72 in Figs 5 & 6).
Claim(s) 6 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Franklin in view of Wedekind, in further view of Grassadonia et al. (US 9741036).
In regards to Claim 6, the combination of Franklin and Wedekind discloses:
The method of claim 1, wherein authenticating by the server comprises detecting a change in contextual information including at least one of transaction type, merchant category, transaction location, point-of-sale entry mode, or currency type, and in response recalculating verification information to determine authentication validity (See Franklin: col. 5, lines 24-40 – “During the transaction phase, the customer 22 invokes the software module and enters a weak password to gain access to the secure storage location. If the password is correct, the customer computer retrieves the private key and customer account number from storage. The customer computer generates a code number as a function of the private key, customer-specific data (e.g., card-holder's name, account number, etc.) and transaction-specific data (e.g., transaction amount, merchant ID, goods ID, time, transaction date, etc.). Preferably, the customer computer uses a cryptographic hashing function to create a unique, multi-digit MAC (message authentication code) from the various input parameters. The customer computer embeds the code number (or MAC) in the reserved digits of the customer account number to create a temporary transaction number that is specific to a single transaction. It may also be necessary to produce a "check sum" consistent with a proper credit card number.”)
The combination fails to explicitly disclose:
verification information comprising a value computed deterministically using the serial number and the dynamically generated contextual information.
However, in a similar field of endeavor, Grassadonia discloses:
verification information comprising a value computed deterministically using the serial number and the contextual information (See Grassadonia: Column 11, lines 43-48, a payment card including Luhn check digits to determine whether the randomly generated number portion of the card number is unique).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Grassadonia’s teaching to provide a verification identifier to the transaction identifier of the combination of Franklin and Wedekind’s method for the purpose of determining whether the serial number and the contextual information (MAC) randomly generated number is unique.
In regards to Claim 12, the combination of Franklin and Wedekind discloses the method of claim 1. Franklin further discloses that the transaction identifier comprises a sum check digit (Figs. 5 and 6) but fails to explicitly disclose that the sum check is a Luhn check digit.
However, Grassadonia discloses:
the transaction identifier comprises a Luhn check digit (See Grassadonia: Column 11, lines 57-62: Luhn check digits).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing date to incorporate Grassadonia’s teaching of Luhn’s algorithm or digit to the transaction identifier of the combination of Franklin and Wedekind’s method for the purpose of determining whether the payment card number is unique and the accuracy of the payment card as a whole (col. 11, lines 26-36).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Franklin in view of Wedekind in further view of Brudnicki et al. (US 20140040139).
In regards to Claim 15, the combination of Franklin and Wedekind fails to explicitly disclose:
initiatinq an electronic transaction if the authentication is valid, wherein at least one of the one or more data types and the one or more data characteristics are confiqured to be made available for use after the initiation.
However, in a similar field of endeavor, Brudnicki discloses in Para. [0091] that the randomized card data may have a configurable usage frequency (e.g., use up to 3 times).
Therefore, it would have been obvious to one of ordinary skill in the art before the earliest filing date to incorporate Brudnicki’s disclosure of having the temporary payment card being use for subsequent time to the method of the combination of Franklin and Wedekind for purpose of meeting the business rules of the financial account provider (See Brudnicki: Para. [0090]).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Franklin in view of Wedekind, in further view of Park et al. (US 20140258135).
In regards to Claim 16, the combination of Franklin and Wedekind fails to explicitly disclose:
wherein the transaction identifier comprises a non-alphanumeric representation.
However, in a similar field of endeavor, Park discloses in Para. [0077] that the one-time card information can be wirelessly transmitted to the card reader using a one-dimensional bar code or QR code.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the method of using non-alphanumeric representation, e.g. QR code as disclosed by Park to the combination of Franklin and Wedekind allowing the user to access information instantly.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Franklin in view of Wedekind, in further view of Singh et al. (20190228408).
In regards Claim 20, Franklin fails to explicitly disclose:
wherein the transaction identifier comprises a mode identifier for conveying one or more parameters to the server, the one or more parameters correspond to: the server configured to generate one or more values in the the-transaction identifier; the first device confiqured to generate one or more values in the transaction identifier; a user authentication before a generation of one or more values in the transaction identifier; an amount for generating the one or more data types, wherein the one or more data types comprise verification information; a storage register for the transaction identifier; or any combination thereof.
However, in a similar field of endeavor, Singh discloses in Para. [0030] a one-time number(s) may include at least an identification value (equivalent to the mode identifier in the claim of instant application) that corresponds to or may otherwise identify or reference the processing server 102 and in Para. 0032 that the one-time number(s) may include a second identification value (equivalent to the mode identifier in the claim of instant application) that is associated with the wallet provider 106 on the user’s computing device 104.
Therefore, it would been obvious to one of ordinary skill in the art before the effective filing date to provide a mode identifier in the one-time number(s) as disclosed by Singh to the combination of Franklin and Wedekind for the desirable purpose of having additional transaction identifier possibilities to enhance authentication.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Gueh (US 20140358777 A1) generally discloses an application providing a transaction-processing system for performing multi-factor verification of transactions sugin unique ID’s and serial numbers.
Guo (US 20070101122 A1) generally discloses an approach for securely generation application session keys within a secure module of a user terminal, wherein said keys are used as unique session identifiers to facilitate transactions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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, Neha Patel can be reached on 571-270-1492. 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699 /NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699