DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
2. Claim 60 is objected to because of the following informalities:
Claim recites “transferring a dynamically changing variable form the host device …”, wherein underlined word “form” should be changed into “from”.
Appropriate correction is required.
Response to Arguments
3. Applicant filed the amendment on 12/18/2025. Claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 are pending. Claims 1, 7-8, 12, 23-24, 28, 33-35, 38, 50-51, 60, 65-66, and 81-82 are amended. Claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
4. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
5. Applicant is of the opinion that the claims do not direct to an abstract idea, and concludes that “Applicant’s claimed methods involve more than methods of organizing human activity”.
Examiner respectfully disagrees.
Claims as a whole are directed to authorizing a card not present transaction which is grouped under “Certain methods of organizing human activity is similar to commercial activities”.
The claims are not patent eligible.
Rejections under 35 U.S.C. § 112(b)
6. Rejection of claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 based on “Lack of antecedent basis”, “Means Plus Function”, and “Unclear Scope” due to amendments are withdrawn.
Rejections under 35 U.S.C. § 102
7. Rejection of claims 60, 65-67, 70, and 80-82 due to amendments are withdrawn.
Rejections under 35 U.S.C. § 103
8. Applicant arguments are not persuasive in view of revised claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 rejections with prior art references Mitra et al. in view of Poznansky et al. and Loh et al. Therefore, claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 rejections sustain.
Claim Rejections - 35 USC §101
9. 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.
10. Claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
11. In the instant case, claims 1, 28, and 60 are directed to “systems and a method for card not present transaction authorization”.
12. Claim 60 recites “authorizing a card not present transaction”. Specifically, the claim recites “… capturing … one or more current … features corresponding to a current user identity sample; comparing … the one or more current … features to a previously obtained … feature corresponding to a previously obtained user identity sample; generating… an authorization … that identifies the current user identity sample as belonging to an authorized user in response to the one or more current … features matching the previously obtained … feature, the authorization … corresponding to a user initiated successful … user authentication; transferring a dynamically changing variable form … generating … a temporary passcode in response to the generation of the authorization…, the temporary passcode being generated from a combination of the authorization … fixed information…, and the dynamically changing variable received…; and authorizing at least one transaction using the temporary passcode”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
13. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claim 60 such as “a communication link”, “a host device”, “a smart card”, “temporarily powering the smart card from the host device”, “capturing by the smart card one or more biometric features”, “biometric”, “an authorization signal”, and “previously stored securely on the smart card” do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “temporarily powering…” and “securely stored”, Applicant has not claimed technical details regarding how these functionalities are performed. As a result, the limitations are no more than “apply it” (MPEP 2106.05(f)(1)). With respect to “capturing by the smart card one or more current biometric features corresponding to a current user identity sample”, Applicant has not claimed technological details regarding how the capturing is performed, beyond mere automation. Therefore, it represents no more than receiving data and with respect to “transferring a dynamically changing variable [from] the host device to the smart card” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) does not integrate a judicial exception into a practical application or provide significantly more (MPEP 2106.05(f)(2)).
14. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of authorizing a card not present transaction using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
15. Hence, claim 60 is not patent eligible.
16. Claims 1 and 28 also recite “authorizing a card not present transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
17. As in the case of claim 60, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of the claims 1 and 28 such as “a smart card having a biometric sensor, a processor, and memory”, “the smart card having fixed information stored thereon”, “a host device”, “the host device configured to provide temporary power to the smart card”, “the biometric sensor configured to capture one or more current biometric features”, “an authorization signal”, “stored securely on the smart card”; and “a smart card having a biometric sensor”, “the card having fixed information stored thereon”, “a host device comprising a display, a processor, and memory”, “the host device configured to provide temporary power to the smart card”, “the biometric sensor configured to capture one or more current biometric features”, “an authorization signal”, “stored securely on the smart card” respectively, do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “provide temporary power…” and “securely stored”, Applicant has not claimed technical details regarding how these functionalities are performed. As a result, the limitations are no more than “apply it” (MPEP 2106.05(f)(1)). With respect to “capture one or more current biometric features corresponding to a current user identity sample”, Applicant has not claimed technological details regarding how the capturing is performed, beyond mere automation. Therefore, it represents no more than receiving data and according to the MPEP “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) does not integrate a judicial exception into a practical application or provide significantly more (MPEP 2106.05(f)(2)).
18. When analyzed under step 2B (MPEP 2106.04 II), the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of authorizing a card not present transaction using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
19. Hence, claims 1 and 28 are not patent eligible.
20. Dependent claim 2 further describes the abstract idea of authorizing a card not present transaction, as recites “further comprising … wherein … is configured to display the temporary passcode”. The additional elements such as “a display on the smart card” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 3 further describes the abstract idea of authorizing a card not present transaction, as recites “further comprising … wherein … is configured to display the temporary passcode”. The additional element such as “a display on the smart phone” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 7, 33, and 65 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein the temporary passcode is valid for a single or limited number of transactions”.
Dependent claims 8, 34, and 66 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein the temporary passcode is valid for a short or a preprogrammed time window”.
Dependent claims 9, 35, and 67 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein the temporary passcode comprises a dynamic CVV (DCVV) code”.
Dependent claims 12 and 38 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein the temporary passcode is generated multiple times by the authorized user”.
Dependent claims 22, 49, and 80 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein the at least one transaction comprises a single or limited number of transactions”.
Dependent claims 23 and 50 further describe the abstract idea of authorizing a card not present transaction, as each recites “further comprising …wherein the temporary passcode comprises a DCVV”. The additional element such as “an electronic transaction authorization system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claims 24 and 51 further describe the abstract idea of authorizing a card not present transaction, as each recites “wherein … is configured to compare the DCVV from the temporary passcode to an equivalent DCVV generated … and if the DCVV from the temporary passcode matches the equivalent DCVV … configured to authorize the CNP transaction”. The additional element such as “the transaction authorization system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 70 further describes the abstract idea of authorizing a card not present transaction, as recites “further comprising generating the temporary passcode multiple times by the authorized user”.
Dependent claim 81 further describe the abstract idea of authorizing a card not present transaction, as recites “wherein the temporary passcode comprises a DCVV, and further comprising entering the DCVV into … by authorized user”. The additional element such as “an electronic transaction authorization system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 82 further describes the abstract idea of authorizing a card not present transaction, as recites “wherein … compares the DCVV to an equivalent DCVV generated … and wherein … authorizes a CNP transaction in response to the DCVV matching the equivalent DCVV generated …”. The additional element such as “the transaction authorization system” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
21. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
22. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 112
23. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
24. Claims 1-3, 7-9, 12, 22-24, 28, 33-35, 38, 49-51 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim Rejections - 35 USC § 103
29. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
30. 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.
31. 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.
32. Claims 1-2, 7-9, 12, 22-24, 28, 33-35, 38, 49-51, 60, 65-67, 70, and 80-82 are rejected under 35 U.S.C. 103 as being unpatentable over US20160267486A1 to Mitra et al. in view of US20120153028A1 to Poznansky et al.
33. As per claim 1:
Mitra et al. discloses the following limitations:
a smart card having a biometric sensor, a processor, and memory (Fig.21, items 100, 140, 150; [0109] “… the smart-card 100 is shown as comprising … a controller 140… a finger print scanner 150… a memory for storing various types of data.”, [0115] “…a biometric scanner can comprise a retinal scanner, a face scanner, a DNA scanner…”), the smart card having fixed information stored thereon (fig.2, items 236, 244 [0052] “…The secure element 236 contains applets related to card account information… The payment card applets 244 contain the card account information, tokens and CVV generators…)
a host device configured to communicate with the smart card (fig.1, item 120; [0049] “…the smartjacket 120, is an electronic docking station for the universal smartcard…”, fig.2, items 210, 246; [0052] “…the smartjacket 210 and connected via a wired contact connection 246 … “), the host device configured to provide temporary power to the smart card ([0070] “the smartjacket includes … A battery for the charging of the smartcard and powering features…”, [0076] “…the smartjacket ISO connector is required to physically connect the smartjacket and smartcard … this would include voltage and GND access…”)
the biometric sensor ([0109] “…the smart-card 100 is shown as comprising… a finger print scanner 150…”) configured to capture one or more current biometric features corresponding to a current user identity sample ([0073] “… on first use the user places the finger on the scanner … read and store the scan as the default…”), compare the one or more current biometric features to a previously obtained biometric feature corresponding to a previously obtained user identity sample, and generate an authorization signal (interpreted as any signal generated after the biometric sensor detects the match) if the one or more current biometric features matches the previously obtained biometric feature, the authorization signal indicating a user initiated successful biometric user authentication, the authorization signal indicating the current user identity sample is from an authorized user ([0073] “…On future use, if there is a match, the card will wake up from sleep mode…”, [0074] “…the logical authorization is granted…”, [0121] “…biometric input is received … the smart-card is authenticated … authentication data is sent back … the smart-card is unlocked.”)
the host device configured to authorize at least on transaction using the temporary passcode (fig.4, items 418, 424; [0057] “…In step 418 the smartjacket unlocks the selected payment card applet on the card… In step 424, the user uses the universal card at a POS terminal for the selected credit card account…”, [0052] “…only allowing a selected payment card applet 244 to be used for one and only one use…”, [0126] “… transaction data is received by the POS device 210, where a transaction is initiated… Transaction data is sent to the bank server … where the transaction is processed…”)
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
the processor configured to generate a temporary passcode ([0054] “…During the identification of the user 2013 the Enable Unit … will switch on 2020 the CVV generator 714…”), and transmit the temporary passcode to the host device ([0053] “… sending a command to display 2026 the new CVV code on the CVV display 109…”), the temporary passcode configured to authorize at least one transaction ([0013] “…only valid for a single transaction…), the temporary passcode being generated from a combination of the [a first] signal, the fixed information previously stored securely on the smart card, and a dynamically changing variable received from the host device (fig.5, items 2107, 2108, 2112; [0056] “…FIG. 5 which illustrates the CVV generator diagram. During the card manufacturing, a random number … denoted the Private Key—marked: ‘R’ 2107 … the card ID 2108… the Pubic Key—a huge prime number marked: ‘P’… that will compose the new dynamic CVV code 2112 for the present time segment.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for generating the new dynamic CVV and sending the dynamic CVV, that might be used for a single transaction, and wherein the dynamic CVV is generated from multiple sources (‘028, [0013], [0053]-[0054], [0056]).
34. As per claim 2:
Mitra et al. discloses the following limitations:
further comprising a display on the smart card, wherein the display is configured to display the temporary passcode (Fig.2, items 234, 248; [0052] “…The universal smartcard 234 also includes a dynamic display 248 which is used for, among other functions, displaying the selected card account…”, fig.21, items 100, 105, 155; [0109] “… the smart-card 100 is shown as comprising a card body 105 that includes… a display 155…”, [0112] “…The display … can be configured to present text, images, video…”)
35. As per claims 7, 33, and 65:
Mitra et al. discloses the following limitations:
wherein the temporary passcode is valid for a single or limited number of transactions (Fig.2, items 236, 242; [0052] “…The secure element 236 also contains custom proprietary and pre-loaded PSE and PPSE applets 242… These PSE and PPSE applets 242 provide security features such as only allowing a selected payment card applet 244 to be used for one and only one use after which they are locked and cannot be unlocked and accessed by a POS terminal without a subsequent bio-metric identification…”, [0057] “… if the card was used at an EMV or NFC terminal the card is immediately locked after one use…”, [claim 1] “…for one time use after biometric identification…”)
36. As per claims 8, 34, and 66:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
wherein the temporary passcode is valid for a short or a preprogrammed time window ([0013] “…only valid for a short period of time…”, [0017] “…the transaction card's processor chip is activated for a predefined legitimate duration in which commercial CNP activities may take place. The defined legitimate time can be defined for one or more commercial transactions and/or for a limiting period of time. For example, after authentication the card can be defined as available for a single commercial transaction in the next 3 minutes…”, [0031] “…a newly generated CVV code is only valid for a limited, predefined amount of time after the CVV code has been generated.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for allowing the newly generated CVV code being valid a limited, predefined amount of time (‘028, [0031]).
37. As per claims 9, 35, and 67:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
wherein the temporary passcode comprises a dynamic CVV (DCVV) code ([0011] “… a transaction card enabling to generate a new CVV code for each transaction.”, [0018] “… the CVV generator unit will generate a new CVV code synchronized with a real time clock… The CVV number generated is different for each time interval…”, [0056] “… The 12 digits binary number will be translated to a 3 decimal digits that will compose the new dynamic CVV code 2112 for the present time segment.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for generating a new dynamic CVV code for each transaction or each time interval (‘028, [0018]).
38. As per claims 12, 38, and 70:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
wherein the temporary passcode is generated multiple times by the authorized user ([0014] “…a CVV generator unit that generates a new CVV code each time the card user is invited to enter his CVV code, typically in a remote transaction…”, [0011] “…a transaction card enabling to generate a new CVV code for each transaction.”, [0018] “… the CVV generator unit will generate a new CVV code synchronized with a real time clock…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for a CVV generator unit generating a new CVV code each time the card user is invited to enter his CVV code (‘028, [0014]).
39. As per claims 22, 49, and 80:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
wherein the at least one transaction comprises a single or limited number of transactions ([0013] “…any CVV code generated… is only valid for a single transaction…”, [0017] “… the card can be defined as available for a single commercial transaction…”, [0030] “…a newly generated CVV code is only valid for a single transaction.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for allowing, after authentication the card, one or more commercial transactions and/or for a limiting period of time (‘028, [0017]).
40. As per claims 23, 50, and 81:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
further comprising an electronic transaction authorization system and wherein the temporary passcode comprises a DCVV ([0020] “The clearing machine (or clearing software) will have possession of the time reading, the card ID number and the private and public keys and thus will be able to verify the dynamic CVV by regenerating the same…”, [0021] “…The clearing institution will verify the authenticity of the CVV code and will either approve or decline the financial transaction…”, [0057] “…the clearing software in a remote payment CNP scenario or the vendor at the clearing machine can calculate the exact new dynamic CVV code and authenticate the one received from the card 100…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for describing an authorization system that verifies the dynamic CVV, that is used as a code in a transaction (‘028, [0021], [0057]).
41. As per claims 24, 51, and 82:
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
wherein the electronic transaction authorization system is configured to compare the DCVV from the temporary passcode to an equivalent DCVV generated by the electronic transaction authorization system, and if the DCVV from the temporary passcode matches the equivalent DCVV, the electronic transaction authorization system configured to authorize the CNP transaction ([0020] “The clearing machine (or clearing software) will have possession of the time reading, the card ID number and the private and public keys and thus will be able to verify the dynamic CVV by regenerating the same, using the same method…”, [0021] “In a CNP transaction, the vendor or the clearing software transmits the CVV code that has been received from the customer to the clearing institution in a similar way to financial transactions with credit cards of the art. The clearing institution will verify the authenticity of the CVV code and will either approve or decline the financial transaction. The clearing institution compares the CVV code transmitted by the vendor to a CVV code generated internally, using similar methods to the CVV generator unit on the transaction card.”, [0057] “…the clearing software… can calculate the exact new dynamic CVV code and authenticate the one received from the card 100 when it matches the one calculated at the clearing house. This comparison can be achieved without a dependency on an external server or a huge database.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for describing an authorization system that verifies the dynamic CVV based on comparison of whether the calculated exact new dynamic CVV code matches to the code that is received from the card in order to authorize the transaction (‘028, [0021], [0057]).
42. As per claim 28:
Mitra et al. discloses the following limitations:
a smart card having a biometric sensor, the smart card having fixed information stored thereon (Fig.21, items 100, 150; [0109] “… the smart-card 100 is shown as comprising … a finger print scanner 150… a memory for storing various types of data.”, [0115] “…a biometric scanner can comprise a retinal scanner, a face scanner, a DNA scanner…”, fig.2, items 236, 244 [0052] “…The secure element 236 contains applets related to card account information… The payment card applets 244 contain the card account information, tokens and CVV generators…)
a host device comprising a display, a processor, and memory (Fig.2, 210, 270, 284; [0052] “…a dynamic display 248 which is used for, among other functions, displaying the selected card account in conjunction with the selector buttons on the smartjacket 210…”, [0070] “…the smartjacket includes … a Microprocessor or Microcontroller to control other components on the Smartcard and to transfer data between the ecosystem and external world”), the host device configured to communicate with the smart card (fig.1, item 120; [0049] “…the smartjacket 120, is an electronic docking station for the universal smartcard…”, fig.2, items 210, 246; [0052] “…the smartjacket 210 and connected via a wired contact connection 246 … “), the host device configured to provide temporary power to the smart card ([0070] “the smartjacket includes … A battery for the charging of the smartcard and powering features…”, [0076] “…the smartjacket ISO connector is required to physically connect the smartjacket and smartcard … this would include voltage and GND access…”)
the biometric sensor ([0109] “…the smart-card 100 is shown as comprising… a finger print scanner 150…”) configured to capture one or more current biometric features corresponding to a current user identity sample ([0073] “… on first use the user places the finger on the scanner … read and store the scan as the default…”), compare the one or more current biometric features to a previously obtained biometric feature corresponding to a previously obtained user identity sample, and generate an authorization signal if the one or more current biometric features matches the previously obtained biometric feature, the authorization signal indicating a user initiated successful biometric user authentication, the authorization signal indicating the current user identity sample is from an authorized user ([0073] “…On future use, if there is a match, the card will wake up from sleep mode…”, [0074] “…the logical authorization is granted…”, [0121] “…biometric input is received … the smart-card is authenticated … authentication data is sent back … the smart-card is unlocked.”)
the host device configured to authorize at least on transaction using the temporary passcode (fig.4, items 418, 424; [0057] “…In step 418 the smartjacket unlocks the selected payment card applet on the card… In step 424, the user uses the universal card at a POS terminal for the selected credit card account…”, [0052] “…only allowing a selected payment card applet 244 to be used for one and only one use…”, [0126] “… transaction data is received by the POS device 210, where a transaction is initiated… Transaction data is sent to the bank server … where the transaction is processed…”)
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
the processor configured to generate a temporary passcode ([0054] “…During the identification of the user 2013 the Enable Unit … will switch on 2020 the CVV generator 714…”), and transmit the temporary passcode to the host device ([0053] “… sending a command to display 2026 the new CVV code on the CVV display 109…”), the temporary passcode configured to authorize at least one transaction ([0013] “…only valid for a single transaction…), the temporary passcode being generated from a combination of the authorization signal, the fixed information previously stored securely on the smart card, and a dynamically changing variable received from the host device (fig.5, items 2107, 2108, 2112; [0056] “…FIG. 5 which illustrates the CVV generator diagram. During the card manufacturing, a random number … denoted the Private Key—marked: ‘R’ 2107 … the card ID 2108… the Pubic Key—a huge prime number marked: ‘P’… that will compose the new dynamic CVV code 2112 for the present time segment.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for generating the new dynamic CVV and sending the dynamic CVV, that might be used for a single transaction, and wherein the dynamic CVV is generated from multiple sources (‘028, [0013], [0053]-[0054], [0056]).
43. As per claim 60:
Mitra et al. discloses the following limitations:
establishing a communication link between a host device and a smart card (Fig.2, items 210, 246; [0052] “…the smartjacket 210 and connected via a wired contact connection 246 … “, [0076] “…the smartjacket ISO connector is required to physically connect the smartjacket and smartcard. In various embodiments, this would include voltage and GND access and access to the I/O interface.”)
temporarily powering the smart card from the host device, the host device communicating with the smart card (Fig.2, items 230, 234, 236; [0051] “…The power-management application 230 is used to extend the battery life on the universal smartcard 234, by powering off the secure element 236 of the universal smartcard 234 when not in use.”, [0070] “… the smartjacket includes… A battery for the charging of the smartcard and powering features such as the Microprocessor or any wireless communication systems… “, [0076] “…the smartjacket ISO connector is required to physically connect the smartjacket and smartcard… this would include voltage and GND access…”)
capturing by the smart card one or more current biometric features corresponding to a current user identity sample ([0109] “…the smart-card 100 is shown as comprising… a finger print scanner 150…”, [0115] “The smart-card 100 can comprise one or more suitable biometric scanner, which …can include a finger print scanner 150. In further embodiments, such a biometric scanner can comprise a retinal scanner, a face scanner, a DNA scanner…”, [0073] “…on first use the user places the finger on the scanner and follows a series of authentication protocols which would read and store the scan as the default…”)
comparing by the smart card the one or more current biometric features to a previously obtained biometric feature corresponding to a previously obtained user identity sample ([0073] “…on first use the user places the finger on the scanner and follows a series of authentication protocols which would read and store the scan as the default. On future use, if there is a match, the card will wake up from sleep mode; else it will stay in a sleep state until ‘n’ number of failures is reached…”, [0071] “The activation of the smartcard ecosystem includes the verification of the card and user using fingerprint identification…”)
generating by the smart card an authorization signal (interpreted as any signal generated after the biometric match, see [0073] “…On future use, if there is a match, the card will wake up from sleep mode…”) that identifies the current user identity sample as belonging to an authorized user in response to the one or more current biometric features ([0074] “…If the message is recognized by the Smartcard, the logical authorization is granted. At this point, the card may be removed from the jacket and used at POS…”) matching the previously obtained biometric feature, the authorization signal corresponding to a user initiated successful biometric user authentication ([0121] “…biometric input is received … the smart-card is authenticated … authentication data is sent back … the smart-card is unlocked.”)
transferring a dynamically changing variable form the host device to the smart card ([0085] “…the jacket verifies use of the card through random number generation using password verification between the card and the jacket…”, [0107] “…Jacket MCU generates a random number…Jacket MCU now sends the encrypted (Jacket-hash) along with random number to card SE…”)
authorizing at least one transaction using the temporary passcode ([0057] “…In step 418 the smartjacket unlocks the selected payment card applet on the card… the user uses the universal card at a POS terminal for the selected credit card account…”, [0052] “…only allowing a selected payment card applet 244 to be used for one and only one use after which they are locked and cannot be unlocked and accessed by a POS terminal without a subsequent bio-metric identification…”, [0126] “…transaction data is received by the POS device 210, where a transaction is initiated… Transaction data is sent to the bank server 240 … where the transaction is processed…”)
Mitra et al. does not disclose, however, Poznansky et al., as shown, teaches the following limitations:
generating by the smart card a temporary passcode ([0019] “The dynamic CVV will be generated by multiplying the time reading by the card number ID… and by multiplying the product by a public key which is usually a large prime number…”), in response to the generation of the authorization signal ([0054] “…During the identification of the user 2013 the Enable Unit … will switch on 2020 the CVV generator 714…”), the temporary passcode being generated from a combination of the [a first] signal, fixed information previously stored securely on the smart card, and the dynamically changing variable received by the smart card from the host device (fig.5, items 2107, 2108, 2112; [0056] “…FIG. 5 which illustrates the CVV generator diagram. During the card manufacturing, a random number … denoted the Private Key—marked: “R” 2107 … the card ID 2108… the Pubic Key—a huge prime number marked: ‘P’… that will compose the new dynamic CVV code 2112 for the present time segment.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) with teaching of Mitra et al. for providing a secure universal electronic transaction card-based payment system, which provides consumers the ability to conveniently, securely and safely use a single physical universal electronic transaction card (‘486, [0009]) for generating the new dynamic CVV and sending the dynamic CVV, and wherein the dynamic CVV is generated from multiple sources (‘028, [0019], [0054], [0056]).
44. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US20160267486A1 to Mitra et al. in view of US20120153028A1 to Poznansky et al. and US20090143104A1 to Loh et al.
45. As per claim 3:
Neither Mitra et al., nor Poznansky et al. disclose, however, Loh et al., as shown, teaches the following limitations:
further comprising a display on the smart phone, wherein the display is configured to display the temporary passcode (Fig.3, item 308; [0048] “… the display 308 can be used to display one time password (OTP) information … The OTP can also be provided through the use of a mobile phone …”, [0054] “…The OTP parameter and counter elements can be stored in the secure element and displayed by the wireless smart card or the mobile communication device …”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a transaction card for protection of remote credit card transactions that offers several levels of protection to make the transaction card more secure to own and use of Poznansky et al. (‘028, [0012]) and a method for receiving a request to activate a secure communication link at a secure element of a wireless smart card from a mobile device of Loh et al. (‘104, [0009]) with teaching of Mitra et al. for providing an e-ink display for displaying information of one or more card or coupon at a time (‘486, [0151]) for displaying a generated a One-Time-Password by the wireless smart card or the mobile communication device (‘104, [0054]).
Conclusion
46. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US11004074B1 - Hiccox et al. – Discloses a payment device that includes a biometric sensor configured to receive a biometric measurement from a user wherein the payment device also includes a display configured to selectively display sensitive payment account information for a payment account of the user wherein the payment account is associated with the payment device.
US20150127553A1 – Sundaram et al. – Discloses an intelligent payment card and a method for performing a financial transaction using the payment card wherein the payment card is activated when a primary user successfully authenticates himself by the way of providing valid finger print(s) to the biometric sensor of the payment card
US20200034830A1 – Ortiz et al. – Discloses a payment device comprising a secure element for storing payment tokens, each associated with a payment card; an input interface that enables a user to select from among the payment cards; a display interface; and a processor.
US20150262052A1 – Pahuja – Discloses a method comprising receiving, by an electronic processor of a smart card device, user inputs including unique user authentication information, wherein storing transaction instrument information associated with transaction instrument(s).
47. THIS ACTION IS MADE FINAL. 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.
48. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights