DETAILED ACTION
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 .
Examiner Note Regarding Non-Compliant Amendment (37 CFR 1.121)
Claim 1 filed 8 December 2025 recites “on receipt of said command,” in the first line of the fifth paragraph. This language was not in the preceding claims and should have been marked with underline because CFR 1.121 (c) (2) states, in part:
The text of any added subject matter must be shown by underlining the added text.
For purposes of examination, the phrase “on receipt of said command,” is being interpreted as if the text is underlined; and, in the interest of compact prosecution, the claim amendment filed 8 December 2025 is entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-6 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over MITRA (US 20160267486 A1 to Mitra; Rajeshwar D. et al.) in view of REMERY (US 20050161503 A1 to Remery, Patrick et al.)
Regarding claim(s) 1,
MITRA discloses:
A method for controlling a smart card allocated to a user (MITRA: ¶[0048]: used for pairing a user with their smartjacket 120 and universal smartcard; ¶[0064]: The security is maintained between the smartjacket and smartcard by placing multiple safety features to verify user ownership) comprising the steps of:
establishing a wireless communication channel between the smart card and a portable apparatus (MITRA: ¶[0009]: system and method that provides 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, in a standard ISO-7810 credit card form factor, that will be accepted at any standard POS device; [0049]: the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124; ¶[0016]: ““smartjacket” refers to a complement to the smartcard and transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFI”; ¶[0050]: The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, a rechargeable battery 274, a BLE (Bluetooth Low Energy) chip 276 and a Wi-Fi chip 278 and a controller 284.);
[…]
determining by the smart card that control of authentication of said user depends on the portable apparatus and requesting accordingly a permission data reflecting a specific right allocated to a function provided by the smart card (MITRA: [0049] Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections.; [0050]: Now referring to FIG. 2, FIG. 2 is an overview block diagram of the smartjacket and universal smartcard and components contained therein according to one embodiment of the present disclosure. The smartjacket 210 contains a secure element 212 in which applets are stored including but not limited to the smartjacket-mobile pairing applet 214, the smartjacket-card pairing applet 216, and the CID-AID mapping table 218. The AID is the Network generated name given to a card account applet. The CID is a corresponding identifier generated by the smartjacket 210 in one embodiment of the present disclosure. The AID is used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244 for use at a POS terminal. The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, a rechargeable battery 274, a BLE (Bluetooth Low Energy) chip 276 and a Wi-Fi chip 278 and a controller 284.);
capturing an input data from the user through an interface embedded in the portable apparatus; performing, by the portable apparatus, an authentication of the user based on said input data (MITRA: ¶[0049]: Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections.);
depending on a result of said authentication, identifying said permission data by the portable apparatus and sending the permission data to the smart card (MITRA: ¶[0049]: The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120; ¶[0050]: The A-ID is used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244 for use at a POS terminal; ¶[0074]: the smartjacket then decrypts the code using its internal software and sends back the decrypted message to the Smartcard. If the message is recognized by the Smartcard, the logical authorization is granted.)
activating or deactivating said specific right in the smart card according to the permission data (MITRA: ¶[0049] Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections; [0050]: used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244 for use at a POS terminal. The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, [...]; [0178]: FIG. 16 outlines one non-limiting example of SmartCard usage at retail outlets in accordance with an embodiment. The process includes User activating card at Retail outlet using his fingerprint; the SmartCard can wait for the correct PIN to be entered;).
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
starting a transaction between said smart card and a terminal distinct from the portable apparatus, said transaction having at least one applicative parameter sent to the smart card by the terminal and requesting authentication of said user (REMERY: [0025]: The transaction begins with an initialization of the chip card instigated by the reading terminal; [0026]: The card, in response, sends its identification to the reading terminal (step 2). An identifier amount is stored on the chip card. Next, the reading terminal requests the operator (i.e., retailer) to input the amount M of the transaction (step 3). It sends this amount M to the card. The latter implements a test 4 on the value of this amount M. If this amount M is below a ceiling value VP1, the card increments a counter COMPT by the value of this amount M (step 5).; [0027] The card then compares the value of this counter COMPT with a threshold VP2, which may be different from the threshold VP1. If the counter COMPT is below VP2, the microprocessor of the card calculates the signature ST of the transaction (step 7) and sends it to the reading terminal which verifies it and archives the amount of the transaction, as well as the details of the latter (steps 8 and 9). The signature includes VP1, VP12, VP22, CPT1, and CPT2. It should be noted that the signature can also include a transaction number, transaction amount (M), card number, date, time, etc.; [0028] If, conversely, the value of the counter COMPT is greater than VP2, the card requests the reading terminal for presentation of the bearer's code step 10). The bearer inputs his code (step 11). The code is sent by the reading terminal to the card which verifies it (step 12). The code can include a user code and/or a personal identification number (PIN). The bearer enters the code on the terminal keypad. Verification includes comparison of the entered code and a value stored on the chip card.; [0029]: The bearer's code is also requested by the card when the amount M is greater than the threshold value VP1 ("yes" response to test 4).);
sending by the terminal to the smart card a command which aims at getting the authorization to continue the transaction (REMERY: ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold, […] and in that a procedure for authenticating the bearer of the card is instigated by said card as a function of the result of this comparison; ¶[0014]: the card increments by the value of the amount of the transaction);
on receipt of said command, determining by the smart card […] said determining being performed by using said at least applicative parameter of the transaction (REMERY: ¶[0027]: The card then compares the value of this counter COMPT with a threshold VP2, […]. If the counter COMPT is below VP2, the microprocessor of the card calculates the signature ST of the transaction (step 7); [0028]: If, conversely, the value of the counter COMPT is greater than VP2, the card requests the reading terminal for presentation of the bearer's code; ¶[0029]: The bearer's code is also requested by the card when the amount M is greater than the threshold value VP1);
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
Regarding claim(s) 2,
MITRA and REMERY teach the limitations of claim 1.
MITRA further discloses:
wherein the specific right is a permission to use said function (MITRA: ¶[0050]: used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet; ¶[0052]: allow or disallow a POS terminal to access payment card applets 244 depending on whether a payment card applet is unlocked or locked; ¶[0049]: multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked)..
Regarding claim(s) 3,
MITRA and REMERY teach the limitations of claim 1.
MITRA further discloses:
wherein the specific right is an authorization to use or activate a parameter of said function (MITRA: ¶[0050]: “unlock a specific payment card applet”; ¶[0052]: allow or disallow a POS terminal to access payment card applets 244 depending on whether a payment card applet is unlocked or locked; ¶[0049]: multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked; ¶[0179]: After activation of card user selects and locks one rewards card; ¶[0178]: prompt for “best card” to use; User selects and locks card and hands over to the billing clerk. The specific card is swiped or used for contactless EMV payment).
Regarding claim(s) 4,
MITRA and REMERY teach the limitations of claim 1.
MITRA further discloses:
wherein said function is an exchange of data through a communication channel established between the smart card and the terminal (MITRA: figure 23: transaction data and transaction receipt, smart card 100 and POS device 210; [0039]: FIG. 23 is an example data-flow diagram illustrating communications that occur during a transaction using the smartcard payment system according to one embodiment of the present disclosure.; ¶[0039]: FIG. 23 is an example data-flow diagram illustrating communications that occur during a transaction using the smartcard payment system according to one embodiment of the present disclosure; figure 28: payment terminal request payment information, payment information is transmitted.) .
Regarding claim(s) 5,
MITRA and REMERY teach the limitations of claim 1.
MITRA further discloses:
wherein said function is a provisioning of a credential authorizing said transaction (MITRA: ¶[0002]: . A multiplicity of transaction account numbers, applets and or tokens are stored in a secure element and from which the consumer can transact from any of their credit, debit, pre-paid, club access cards, gift cards, rewards and loyalty cards accounts, using either, Mag Stripe, EMV, or NFC at existing POS terminals, in such a way that only the legitimate owner of the electronic transaction card can activate, provision and unlock the electronic transaction card for use via biometric identification; ¶[0049]: securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections; ¶[0052]: There is at least one payment card applet 244 per card account. The payment card applets 244 contain the card account information, tokens and CVV generators required by the various networks; ¶[0055]: the mobile app requests tokens for this credit card account from the network that issued the original credit card (e.g. MasterCard, Visa, Discover, American Express). In step 340 the network forwards request to the issuing bank for approval. If approved in step 342 the bank returns approval and the T&Cs are displayed for the user to accept. Once T&Cs are accepted in step 344 the network provides tokens and CVV generator to a trusted service manager. The trusted service manager uses these to create an add-card script which is returned to the mobile app in step 346. The add-card script is encrypted with keys that are available only to the smartcard. In step 348 the mobile app transfers the add-card script to the smartjacket. In step 350 the smartjacket securely transfers the add-card script to the card. In step 352 the add-card script in conjunction with the appropriate network applet create the payment card applet for this credit card account.).
Regarding claim(s) 6,
MITRA and REMERY teach the limitations of claims 1 and 5.
MITRA further discloses:
wherein said terminal is a Point-Of-Sale terminal (MITRA: ¶[0002]: activating, provisioning and unlocking the electronic transaction card for use via biometric identification at POS terminals)
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
wherein the transaction is a payment for an amount higher than a preset threshold and wherein the specific right is an authorization given to the smart card to provide its agreement for the transaction to the terminal (REMERY: ¶[0004]:In particular, the terminal of the reading terminal routinely requests the bearer of the card to indicate thereto his/her authentication code. Also, if the amount of the transaction exceeds a certain threshold, the reading terminal can decide to interrogate an external authorization center; ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold; a procedure for authenticating the bearer of the card is instigated by said card as a function of the result of the threshold comparison.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
Regarding claim(s) 8,
MITRA and REMERY teach the limitations of claim 1.
MITRA further discloses:
wherein said input data comprises at least one of the following: a PIN code, a password, a passphrase, a One-Time- Password, a biometric data, a drawn pattern or behavior data like a gait, movements or rhythm of the user (MITRA: ¶[067]: 4-digit PIN; ¶[0049]: biometric scanner; ¶[0050]: biometric sensor; ¶[0066]: biometric authorization; ¶[0074]: passcode; ¶[0085] and ¶[0125]: password; ¶[0107]: fingerprint; ¶[0050]: fingerprint scanner).
Claim(s) 7 and 9-15 are rejected under 35 U.S.C. 103 as being unpatentable over MITRA (US 20160267486 A1 to Mitra; Rajeshwar D. et al.) in view of REMERY (US 20050161503 A1 to Remery, Patrick et al.) in further view of GARDINER (US 20190205575 A1 to Gardiner; Michael et al.)
Regarding claim(s) 7,
MITRA and REMERY teach the limitations of claim 1.
MITRA discloses a payment transaction and an access request transaction (MITRA: ¶[0002]: the consumer can transact from any of their […] club access cards […], in such a way that only the legitimate owner of the electronic transaction card can activate, provision and unlock the electronic transaction card for use via biometric identification) and where the transaction is a payment transaction; ¶[0002]: system and method that “provides a secure universal electronic transaction card-based payment system”; ¶[0044]: interaction with payment terminals; ¶[0104]: The process begins with the payment terminal requesting payment information from the user.);
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
wherein either said at least applicative parameter is an amount and said transaction is a payment transaction, (REMERY: ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold; ¶[0031]: the payment card aggregates on the internal counter COMPT the amount of the transactions which are below a certain threshold and requests authentication of the bearer only when the amount M is above this threshold).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
MITRA and REMERY do not teach the following limitations which GARDINER, however, teaches:
or said at least applicative parameter is an area security level and said transaction is an access request transaction (GARDINER: ¶[0003]: high-security access-control cards for granting access to a building; ¶[0011]: a smart card carrier and a smart card with an additional security layer; ¶[0040]: additional components, additional layers of transactional security; ¶[0040]: card 210 having an additional security layer of a biometric authentication unit included; ¶[0068]: other types of layered security may be used, such as a PIN or a password, in lieu of or in addition to the biometric authentication.; ¶[0071]: The particular level of similarity or the metrics used to determine if a biometric signature is the same or similar enough to the template to qualify as authentic may vary; ¶[0079]: the network administrator may send out a request for reauthentication to ensure that the person has access to the area in which they are located; ¶[0079]: the holder may be required to verify his or her identity each time access is requested to an area within the facility; Carriers 140 or 340 may be used with the issued card to allow for wireless communication with the internal network of the facility controlling access to different areas).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA ¶[0002]) with the technique of GARDINER, which relates to smart cards (GARDINER ¶[0002]), in order to enhance the capability of conducting transactions in a cost effective manner (GARDINER ¶[0061] ) and allow for additional security and compatibility with different systems (GARDINER ¶[0062]).
Regarding claim(s) 9,
MITRA discloses:
A system comprising a smart card and a portable apparatus embedding an interface able to capture an input data, said smart card being allocated to a user and able to establish a wireless communication channel with the portable apparatus (MITRA: ¶[0009]: system and method that provides 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, in a standard ISO-7810 credit card form factor, that will be accepted at any standard POS device; [0049]: the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124; ¶[0016]: ““smartjacket” refers to a complement to the smartcard and transmits data from the smartcard to the mobile device or cloud wirelessly following using wireless protocols such as Bluetooth Smart (BLE) and WiFI”; ¶[0050]: The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, a rechargeable battery 274, a BLE (Bluetooth Low Energy) chip 276 and a Wi-Fi chip 278 and a controller 284.; MITRA: ¶[0048]: used for pairing a user with their smartjacket 120 and universal smartcard; ¶[0064]: The security is maintained between the smartjacket and smartcard by placing multiple safety features to verify user ownership),
wherein the smart card is configured to start a transaction with a terminal distinct from the portable apparatus (MITRA: ¶[0057]: the user uses the universal card at a POS terminal; ¶[0002]: card “accepted at any standard POS device”; ¶[0003]: provides consumers with convenience, security and universal acceptance at existing POS terminals),
[…]
in that the smart card is configured to […] determine that control of authentication of said user depends on the portable apparatus and to request accordingly a permission data reflecting a specific right allocated to a function provided by the smart card (MITRA: [0049] Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections.; [0050] Now referring to FIG. 2, FIG. 2 is an overview block diagram of the smartjacket and universal smartcard and components contained therein according to one embodiment of the present disclosure. The smartjacket 210 contains a secure element 212 in which applets are stored including but not limited to the smartjacket-mobile pairing applet 214, the smartjacket-card pairing applet 216, and the CID-AID mapping table 218. The AID is the Network generated name given to a card account applet. The CID is a corresponding identifier generated by the smartjacket 210 in one embodiment of the present disclosure. The AID is used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244 for use at a POS terminal. The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, a rechargeable battery 274, a BLE (Bluetooth Low Energy) chip 276 and a Wi-Fi chip 278 and a controller 284.);
in that the smart card is configured to activate or deactivate said specific right according to a permission data received from the portable apparatus (MITRA: ¶[0049] Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 […]. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 […]; [0050]: used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244 for use at a POS terminal. The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner, [...]; [0178]: FIG. 16 outlines one non-limiting example of SmartCard usage at retail outlets in accordance with an embodiment. The process includes User activating card at Retail outlet using his fingerprint; the SmartCard can wait for the correct PIN to be entered;) ;
in that the portable apparatus is configured to perform an authentication of the user based on said input data (MITRA: ¶[0049]: Still referring to FIG. 1 the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122 for use at any standard POS terminal 124. The universal smartcard 122 securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections; ¶[0050]: The smartjacket 210 also has selector buttons 270, a biometric sensor 272, which in one embodiment is a fingerprint scanner; )
and, depending on a result of said authentication, to identify the permission data reflecting a specific right allocated to a function provided by the smart card and to send the permission data to the smart card (MITRA: ¶[0049]: the smartjacket 120, is an electronic docking station for the universal smartcard which contains a biometric scanner and related software for securely selecting and unlocking a card account applet on the smartcard 122; ¶[0050]: The A-ID is used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet 244; The smartjacket 210 has a biometric sensor 272, which in one embodiment is a fingerprint scanner); [0074]: working in parallel with the physical fingerprint verification is a logical verification. The logical verification is a communication between the smartcard and the smartjacket in which the smartcard provides a passcode in an encrypted code to the smartjacket. Each smartcard and smartjacket pairing have a unique code setting which allows them to receive and read information provided by the other. In this process, the smartjacket then decrypts the code using its internal software and sends back the decrypted message to the Smartcard. If the message is recognized by the Smartcard, the logical authorization is granted.)
[…]
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
said transaction requesting authentication of said user and having at least one applicative parameter (REMERY: [0025]: The transaction begins with an initialization of the chip card instigated by the reading terminal; [0026]: The card, in response, sends its identification to the reading terminal (step 2). An identifier amount is stored on the chip card. Next, the reading terminal requests the operator (i.e., retailer) to input the amount M of the transaction (step 3). It sends this amount M to the card. The latter implements a test 4 on the value of this amount M. If this amount M is below a ceiling value VP1, the card increments a counter COMPT by the value of this amount M (step 5).; [0027] The card then compares the value of this counter COMPT with a threshold VP2, which may be different from the threshold VP1. If the counter COMPT is below VP2, the microprocessor of the card calculates the signature ST of the transaction (step 7) and sends it to the reading terminal which verifies it and archives the amount of the transaction, as well as the details of the latter (steps 8 and 9). The signature includes VP1, VP12, VP22, CPT1, and CPT2. It should be noted that the signature can also include a transaction number, transaction amount (M), card number, date, time, etc.; [0028] If, conversely, the value of the counter COMPT is greater than VP2, the card requests the reading terminal for presentation of the bearer's code step 10). The bearer inputs his code (step 11). The code is sent by the reading terminal to the card which verifies it (step 12). The code can include a user code and/or a personal identification number (PIN). The bearer enters the code on the terminal keypad. Verification includes comparison of the entered code and a value stored on the chip card.; [0029]: The bearer's code is also requested by the card when the amount M is greater than the threshold value VP1 ("yes" response to test 4).);
in that the smart card is configured to receive from the terminal a command which aims at getting the authorization to continue the transaction and to determine, using said at least applicative parameter of the transaction (REMERY: ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold; ¶[0026]: the reading terminal requests the operator (i.e., retailer) to input the amount M of the transaction (step 3). It sends this amount M to the card. The latter implements a test 4 on the value of this amount M ; ¶[0028]: If, conversely, the value of the counter COMPT is greater than VP2, the card requests the reading terminal for presentation of the bearer's code step 10). The bearer inputs his code (step 11). The code is sent by the reading terminal to the card which verifies it (step 12). The code can include a user code and/or a personal identification number (PIN).; ¶[0029]: The bearer's code is also requested by the card when the amount M is greater than the threshold value VP1.),
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
MITRA does not expressly disclose the following limitations, which GARDINER however, teaches:
sent to the smart card by the portable apparatus (GARDINER: ¶[0006]: According to various embodiments of the disclosed technology, a smart card carrier is provided comprising a housing having an opening configured to accept a smart card; a smart card interface configured to be coupled to the smart card when the smart card is accepted into the opening and configured to provide a data communication link with one or more processors in the smart card; a wireless transceiver configured to engage in wireless data communication with a transaction terminal when the smart card interface is coupled to the smart card; and a power source configured to supply power to the wireless transceiver and the smart card interface; ¶[0007]: a method for facilitating wireless transactions with a smart card through a smart card carrier is provided receiving from a transaction terminal a request related to a transaction involving the smart card; engaging in data communication related to the request with one or more processors in the smart card through a smart card interface coupled to an interface on the smart card; and transmitting a response to the request to the transaction terminal through the wireless transceiver; ¶[0068]: the smartjacket can have a synch button to exchange data with the cloud and/or mobile applications; ¶[0060]: Wireless transceiver module 142 then transfers the request message to card interface 146, which is communicatively coupled to carrier interface 116 of card 210. In this way, the message from terminal 1010 is communicated to processing module 112 of card 210 without card 210 physically in contact with terminal 1010.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of GARDINER, which relates to smart cards (GARDINER ¶[0002]), in order to enhance the capability of conducting transactions in a cost effective manner (GARDINER ¶[0061] ) and allow for additional security and compatibility with different systems (GARDINER ¶[0062]).
Regarding claim(s) 10,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA further discloses:
wherein the specific right is a permission to use said function (MITRA: ¶[0050]: used by the smartjacket 210 in sending commands to the universal smartcard 234 in order to select and unlock a specific payment card applet; ¶[0052]: allow or disallow a POS terminal to access payment card applets 244 depending on whether a payment card applet is unlocked or locked; ¶[0049]: multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked).
Regarding claim(s) 11,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA further discloses:
wherein the specific right is an authorization to use or activate a parameter of said function (MITRA: ¶[0050]: “unlock a specific payment card applet”; ¶[0052]: allow or disallow a POS terminal to access payment card applets 244 depending on whether a payment card applet is unlocked or locked; ¶[0049]: multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked; ¶[0179]: After activation of card user selects and locks one rewards card; ¶[0178]: prompt for “best card” to use; User selects and locks card and hands over to the billing clerk. The specific card is swiped or used for contactless EMV payment).
Regarding claim(s) 12,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA further discloses:
wherein said function is an exchange of data through a communication channel established between the smart card and the terminal (MITRA: figure 23: transaction data and transaction receipt, smart card 100 and POS device 210; [0039]: FIG. 23 is an example data-flow diagram illustrating communications that occur during a transaction using the smartcard payment system according to one embodiment of the present disclosure.; ¶[0039]: FIG. 23 is an example data-flow diagram illustrating communications that occur during a transaction using the smartcard payment system according to one embodiment of the present disclosure; figure 28: payment terminal request payment information, payment information is transmitted.) .
Regarding claim(s) 13,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA further discloses:
wherein said function is a provisioning of a credential authorizing said transaction (MITRA: ¶[0002]: . A multiplicity of transaction account numbers, applets and or tokens are stored in a secure element and from which the consumer can transact from any of their credit, debit, pre-paid, club access cards, gift cards, rewards and loyalty cards accounts, using either, Mag Stripe, EMV, or NFC at existing POS terminals, in such a way that only the legitimate owner of the electronic transaction card can activate, provision and unlock the electronic transaction card for use via biometric identification; ¶[0049]: securely stores multiple account applets inside a secure element 234 on the universal smartcard 122 for use once it is bio-metrically unlocked via the smartjacket 120 at any standard POS terminal using either mag-stripe, EMV or NFC contact or contactless connections; ¶[0052]: There is at least one payment card applet 244 per card account. The payment card applets 244 contain the card account information, tokens and CVV generators required by the various networks; ¶[0055]: the mobile app requests tokens for this credit card account from the network that issued the original credit card (e.g. MasterCard, Visa, Discover, American Express). In step 340 the network forwards request to the issuing bank for approval. If approved in step 342 the bank returns approval and the T&Cs are displayed for the user to accept. Once T&Cs are accepted in step 344 the network provides tokens and CVV generator to a trusted service manger. The trusted service manager uses these to create an add-card script which is returned to the mobile app in step 346. The add-card script is encrypted with keys that are available only to the smartcard. In step 348 the mobile app transfers the add-card script to the smartjacket. In step 350 the smartjacket securely transfers the add-card script to the card. In step 352 the add-card script in conjunction with the appropriate network applet create the payment card applet for this credit card account.).
Regarding claim(s) 14,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA further discloses:
wherein said terminal is a Point-Of-Sale terminal (MITRA: ¶[0002]: activating, provisioning and unlocking the electronic transaction card for use via biometric identification at POS terminals).
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
wherein the transaction is a payment for an amount higher than a preset threshold and wherein the specific right is an authorization given to the smart card to provide the terminal with its own agreement for the transaction (REMERY: ¶[0004]:In particular, the terminal of the reading terminal routinely requests the bearer of the card to indicate thereto his/her authentication code. Also, if the amount of the transaction exceeds a certain threshold, the reading terminal can decide to interrogate an external authorization center; ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold; a procedure for authenticating the bearer of the card is instigated by said card as a function of the result of the threshold comparison.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
Regarding claim(s) 15,
MITRA, REMERY, and GARDINER teaches the system according to claim 9.
MITRA discloses a payment transaction and a transaction aiming at getting access to an area (MITRA: ¶[0002]: the consumer can transact from any of their […] club access cards […], in such a way that only the legitimate owner of the electronic transaction card can activate, provision and unlock the electronic transaction card for use via biometric identification) and where the transaction is a payment transaction (¶[0002]: system and method that “provides a secure universal electronic transaction card-based payment system”; ¶[0044]: interaction with payment terminals; ¶[0104]: The process begins with the payment terminal requesting payment information from the user.);
MITRA does not expressly disclose the following limitations, which REMERY however, teaches:
wherein either said at least applicative parameter is an amount and the transaction is a payment transaction (REMERY: ¶[0011]: the reading terminal sends a signal to said card which indicates thereto the amount of the transaction and in which said card compares this amount with a threshold transaction amount value and instigates a bearer authentication procedure when this amount is above said threshold; ¶[0031]: the payment card aggregates on the internal counter COMPT the amount of the transactions which are below a certain threshold and requests authentication of the bearer only when the amount M is above this threshold)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of REMERY, which also relates to electronic transactions carried out by means of a card (REMERY ¶[0002]), in order to improve security and convenience in card transactions (REMERY ¶[0012]) and reduction cost and processing of transactions (REMERY ¶[0042] ).
MITRA and REMERY do not teach the following limitations which GARDINER, however, teaches:
or said at least applicative parameter is an area security level and the transaction is an access request transaction aiming at getting access to said area (GARDINER: ¶[0003]: high-security access-control cards for granting access to a building; ¶[0011]: a smart card carrier and a smart card with an additional security layer; ¶[0040]: additional components, additional layers of transactional security; ¶[0040]: card 210 having an additional security layer of a biometric authentication unit included; ¶[0068]: other types of layered security may be used, such as a PIN or a password, in lieu of or in addition to the biometric authentication.; ¶[071]: The particular level of similarity or the metrics used to determine if a biometric signature is the same or similar enough to the template to qualify as authentic may vary; ¶[0079]: the network administrator may send out a request for reauthentication to ensure that the person has access to the area in which they are located; ¶[0079]: the holder may be required to verify his or her identity each time access is requested to an area within the facility; Carriers 140 or 340 may be used with the issued card to allow for wireless communication with the internal network of the facility controlling access to different areas)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of MITRA, which discloses systems and methods of a secure universal electronic transaction card-based system (MITRA [0002]) with the technique of GARDINER, which relates to smart cards (GARDINER ¶[0002]), in order to enhance the capability of conducting transactions in a cost effective manner (GARDINER ¶[0061] ) and allow for additional security and compatibility with different systems (GARDINER ¶[0062]).
Response to Arguments
Applicant's arguments filed 12/08/2025 have been fully considered but they are not persuasive. At page 4-5 applicant argues that the primary reference, MITRA, discloses a way to unlock a smart card before the transaction start and the smart card has no access to applicative data specific to the transaction like a money amount or area security level and that REMERY does not teach using the applicative parameter of the transaction for authentication that depends on the portable apparatus of the cardholder. This argument has been considered but is unpersuasive. MITRA alone may perform authentication prior to the transaction, but the rejection relies on REMRY to teach the timing and use of the parameters and the rejection relies on a combination of references and not the single references individually considered.
At page 5, fourth complete paragraph, Applicant argues that REMERY does not teach a smart card which on receipt of a command of the terminal dynamically determines that control of authentication of the card holder depends on a portable apparatus of the cardholder and request permission data reflecting a right allocated to function provided by the smart card. This argument has been considered but is unpersuasive. Applicant argues the references individually rather than addressing the combination as MITRA expressly teaches configuring a smart card such that control of authentication depends on a portable apparatus (the smart jacket) via wireless communication which is combined with REMERY’s parameter threshold.
At page 6, Applicant argues that GARDINER does not teach certain limitations involving the smart card. This argument has been considered but is unpersuasive. GARDINER is used in the rejection to teach sending to the smart card by the portable apparatus and is combined with MITRA and REMERY so that all of the limitations are taught by the combination.
Conclusion
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 BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights