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 .
DETAILED ACTION
This Office Action is in response to the U.S. patent application 18410191 filed on January 11, 2024.
Of original claims 1-20: claims 1, 11 and 20 were independent claims; no claims were amended, added or canceled. Accordingly, claims 1-20 remain pending, and have been examined in this application.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on January 11, 2024, and September 30, 2025, comply with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-19 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Regarding claim 11, the claim calls for a system. However, the claimed system does not include any hardware embodiments. As recited in the body of the claim, the claimed system contains only: “a server.” The specification does not explicitly define the claimed server is implemented only in hardware. One of ordinary skill in the art would understand that a “server” could be implemented in software (see the Authoritative Dictionary of IEEE, Seventh Edition, published in Dec. 2000). The nominal recitation to a "system" in the preamble does not limit the body of the claim as it only states the invention' s purpose or intended use; see Catalina Marketing Int'l, Inc., v. Coolsavings.com Inc., 289 F.3d 801,808 (Fed. Cir. 2002). The Examiner respectfully suggests that the claim be further amended to positively recite at least one hardware element within the body of the claim to make the claim statutory subject matter under 35 U.S.C. 101.
Regarding claims 12-19; Claims 12-19 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter for the same reasons.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rule et al. (“Rule”; US20200184462A1).
Per claim 1: Rule discloses a method for personalizing a contactless card (Rule para. [0002], “system and methods for reissuing or otherwise altering information stored on contactless cards”), comprising:
preinstalling, by a server, an applet on the contactless card (Rule para. [0045], “payment applet may come pre-loaded (e.g., at the time the card is issued) with predefined PANs”; Rule claim 2, “the first applet is preloaded … at the time that the contactless card is issued”);
assigning, by the server, a first unique identifier to the contactless card (Rule Abstract, ”contactless card includes a chip that stores encrypted authentication information, including a primary account number (PAN) that identifies the card”; Rule claim 2, “the first applet is preloaded with a plurality of PANs at the time that the contactless card is issued”);
pre-provisioning, by the server, a first unique derived key to the contactless card (Rule para. [0079], “As illustrated in FIG. 3, at block 310, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card. …The UDKs (AUTKEY and ENCKEY) may be stored on the card”);
generating, by the server a first nonce (Rule para. [0034],”server 116 …may provide seed numbers to be used in the generation of the new PAN”; Rule para. [0079], “an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification”; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
generating, by the server, a data file containing script for updating the contactless card (Rule para. [0034], “server 116 may provide instructions relating to how to derive the new PAN”) and further containing a message authentication code (MAC) (Rule FIG. 2D, see “Message 230, Message Plaintext 234 and Encrypted MAC 242; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
transmitting, by the server, the data file and the first nonce to the contactless card (Rule para. [0034], ”server 116 may provide instructions relating to how to derive the new PAN or may provide seed numbers to be used in the generation of the new PAN”);
validating, by the contactless card, the MAC based on the first unique derived key and the first nonce (Rule para. [0096], “The UID field may be used to look up the shared secret of the contactless card which, along with the Ver, UID, and pATC fields of the message, may be processed through the cryptographic MAC using the re-created Aut-Session-Key to create a MAC output, such as MAC′. If MAC′ is the same as cryptogram A 955, then this indicates that the message decryption and MAC checking have all passed.”); and
personalizing the contactless card by the preinstalled applet executing the script (Rule Abstract, “A rewrite of the PAN may be triggered by issuing a write command to the second applet, or by interacting with the chip in a predetermined manner (e.g., tapping the card on an interactable element a predetermined number of times)”).
Per claim 2: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein the first unique derived key is derived by diversifying the first unique identifier by the server (Rule para. [0079], “As illustrated in FIG. 3, at block 310, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card. In some examples, a bank identifier number may comprise one number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.”).
Per claim 3: Rule disclosed the method according to claim 1. Rule further discloses an arrangement further comprising assigning, by the server, a second unique identifier to the contactless card (Rule para. [0083], “the first and the second keys may be created by diversifying the issuer master keys by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of a payment apple”; Rule Abstract, “exemplary contactless card includes a chip that stores encrypted authentication information, including a primary account number (PAN) that identifies the card”; [Note: the “card’s unique ID number (pUID)”, and “primary account number (PAN)” are being interpreted as two unique ID numbers of the cards]).
Per claim 4: Rule disclosed the method according to claim 1. Rule further discloses an arrangement further comprising tapping, by a user, the contactless card to a mobile phone of the user to receive the data file and the first nonce (Rule para. [0023], “user may tap their contactless card to an NFC reader five times in less than a minute. Because tapping the card to the NFC reader triggers the authentication and encryption operations of the second applet, the second applet can be preconfigured to recognize this predefined pattern and issue the rewrite command in response”; Rule para. [0035], “write request may include information received from the server (e.g., the new PAN, the number of PANs in the list to skip, the generation technique for deriving the new PAN, or the seed for the new PAN).”).
Per claim 5: Rule disclosed the method according to claim 1. Rule further discloses an arrangement further comprising authenticating, by the server, a user of the contactless card through the user logging into a card application installed on a mobile phone of the user (Rule para. [0022], “the chip may include a second encryption and authorization applet responsible for communicating card information to and from external sources. The second applet may perform authentication and may ensure that information transmitted from the payment applet is done so in a secure way (e.g., using encryption). The second applet may also be responsible for performing validation functions (e.g., validating the counter stored on the card), as described in more detail below. According to exemplary embodiments, this second applet may be made to serve as a bridge between the external source and the payment applet, causing the number on the payment applet to be rewritten based on secure, internal (to the chip) communications.”; Rule para. [0147], “the application outputs a display requesting that payee tap his contactless card. Once payee taps his contactless card against the screen of his smartphone with the application enabled, the contactless card is read and verified.”).
Per claim 6: Rule disclosed the method according to claim 5. Rule further discloses an arrangement further comprising retrieving, by the server, the first unique identifier from the contactless card by the user tapping the contactless card to the mobile phone (Rule para. [000145], “data may be collected on tap behaviors as biometric/gestural authentication. For example, a unique identifier that is cryptographically secure and not susceptible to interception may be transmitted to one or more backend services.”).
Per claim 7: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein the script containing interpreted byte codes (Rule para. [0154], “Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code,”).
Per claim 8: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein the MAC is generated by the server using the first unique derived key (Rule para. [0088], “to increase the security of the solution, a session key may be derived (such as a unique key per session) but rather than using the master key, the unique card-derived keys and the counter may be used as diversification data, as explained above. For example, each time the card is used in operation, a different key may be used for creating the message authentication code (MAC)”).
Per claim 9: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein the MAC is generated by the server using the first nonce (Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”; Rule para. [0074], “Using the first diversified key 250 and the combined shared secret/plaintext, the MAC algorithm 236 may generate MAC output 238”; Rule para. [0097], “some examples, the shared secret may be generated by one or more random number generators”).
Per claim 10: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein the action of personalizing the contactless card includes generating a second unique derived key for the contactless card to replace the first unique derived key (Rule para. [0116], “Thereafter, the two derived session keys may be discarded, and the next iteration of data exchange will update the counter value (returning to block 602) and a new set of session keys may be created (at block 604)”).
Per claim 11: Rule discloses a system for personalizing a contactless card (Rule para. [0002], “system and methods for reissuing or otherwise altering information stored on contactless cards”), comprising a server, the server configured to:
preinstall an applet on the contactless card (Rule para. [0045], “payment applet may come pre-loaded (e.g., at the time the card is issued) with predefined PANs”; Rule claim 2, “the first applet is preloaded … at the time that the contactless card is issued”);
assign a first unique identifier to the contactless card (Rule Abstract, ”contactless card includes a chip that stores encrypted authentication information, including a primary account number (PAN) that identifies the card”; Rule claim 2, “the first applet is preloaded with a plurality of PANs at the time that the contactless card is issued”);
pre-provision a first unique derived key to the contactless card (Rule para. [0079], “As illustrated in FIG. 3, at block 310, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card. …The UDKs (AUTKEY and ENCKEY) may be stored on the card”);
generate a first nonce (Rule para. [0034],”server 116 …may provide seed numbers to be used in the generation of the new PAN”; Rule para. [0079], “an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification”; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
generate a data file containing script for updating the contactless card (Rule para. [0034], “server 116 may provide instructions relating to how to derive the new PAN”) and further containing a message authentication code (MAC) (Rule FIG. 2D, see “Message 230, Message Plaintext 234 and Encrypted MAC 242; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
transmit the data file and the first nonce to the contactless card (Rule para. [0034], ”server 116 may provide instructions relating to how to derive the new PAN or may provide seed numbers to be used in the generation of the new PAN”);
cause the contactless card to validate the MAC based on the first unique derived key and the first nonce (Rule para. [0096], “The UID field of the received message may be extracted to derive, from master keys Iss-Key-AUTH 405 and Iss-Key-DEK 410, the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430) for that particular card. Using the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430), the counter (pATC) field of the received message may be used to derive the session keys (Aut-Session-Key 435 and DEK-Session-Key 440) for that particular card. Cryptogram B 460 may be decrypted using the DEK-Session-KEY, which yields cryptogram A 455 and RND, and RND may be discarded. The UID field may be used to look up the shared secret of the contactless card which, along with the Ver, UID, and pATC fields of the message, may be processed through the cryptographic MAC using the re-created Aut-Session-Key to create a MAC output, such as MAC′. If MAC′ is the same as cryptogram A 955, then this indicates that the message decryption and MAC checking have all passed.”); and
cause the preinstalled applet to execute the script for personalizing the contactless card (Rule Abstract, “A rewrite of the PAN may be triggered by issuing a write command to the second applet, or by interacting with the chip in a predetermined manner (e.g., tapping the card on an interactable element a predetermined number of times)”).
Per claim 12: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the action of personalizing the contactless card includes generating a second unique identifier for the contactless card to replace the first unique identifier (Rule para. [0116], “Thereafter, the two derived session keys may be discarded, and the next iteration of data exchange will update the counter value (returning to block 602) and a new set of session keys may be created (at block 604)”).
Per claim 13: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the first unique derived key is derived by diversifying the first unique identifier by the server (Rule para. [0079], “As illustrated in FIG. 3, at block 310, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card. In some examples, a bank identifier number may comprise one number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.”).
Per claim 14: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the action of personalizing the contactless card includes generating a second unique derived key for the contactless card to replace the first unique derived key (Rule para. [0116], “Thereafter, the two derived session keys may be discarded, and the next iteration of data exchange will update the counter value (returning to block 602) and a new set of session keys may be created (at block 604)”).
Per claim 15: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the server is further configured to authenticate a user of the contactless card through the user logging into a card application installed on a mobile phone of the user (Rule para. [0022], “the chip may include a second encryption and authorization applet responsible for communicating card information to and from external sources. The second applet may perform authentication and may ensure that information transmitted from the payment applet is done so in a secure way (e.g., using encryption). The second applet may also be responsible for performing validation functions (e.g., validating the counter stored on the card), as described in more detail below. According to exemplary embodiments, this second applet may be made to serve as a bridge between the external source and the payment applet, causing the number on the payment applet to be rewritten based on secure, internal (to the chip) communications.”; Rule para. [0147], “the application outputs a display requesting that payee tap his contactless card. Once payee taps his contactless card against the screen of his smartphone with the application enabled, the contactless card is read and verified.”).
Per claim 16: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the server is further configured to retrieve the first unique identifier from the contactless card by a user tapping the contactless card to a mobile phone of the user (Rule para. [000145], “data may be collected on tap behaviors as biometric/gestural authentication. For example, a unique identifier that is cryptographically secure and not susceptible to interception may be transmitted to one or more backend services.”).
Per claim 17: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the MAC is generated by the server using the first nonce (Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”).
Per claim 18: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the script containing interpreted byte codes (Rule para. [0154], “Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code,”)
Per claim 19: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the MAC is generated by the server using the first unique derived key (Rule para. [0088], “to increase the security of the solution, a session key may be derived (such as a unique key per session) but rather than using the master key, the unique card-derived keys and the counter may be used as diversification data, as explained above. For example, each time the card is used in operation, a different key may be used for creating the message authentication code (MAC)”).
Per claim 20: Rule discloses a non-transitory, computer-readable medium comprising instructions for personalizing a contactless card (Rule para. [0002], “system and methods for reissuing or otherwise altering information stored on contactless cards”) that, when executed on a computer arrangement, causes the computer arrangement to perform actions comprising:
preinstalling an applet on the contactless card (Rule para. [0045], “payment applet may come pre-loaded (e.g., at the time the card is issued) with predefined PANs”; Rule claim 2, “the first applet is preloaded … at the time that the contactless card is issued”);
assigning a first unique identifier to the contactless card (Rule Abstract, ”contactless card includes a chip that stores encrypted authentication information, including a primary account number (PAN) that identifies the card”; Rule claim 2, “the first applet is preloaded with a plurality of PANs at the time that the contactless card is issued”);
pre-provisioning a first unique derived key to the contactless card (Rule para. [0079], “As illustrated in FIG. 3, at block 310, two bank identifier number (BIN) level master keys may be used in conjunction with the account identifier and card sequence number to produce two unique derived keys (UDKs) per card. …The UDKs (AUTKEY and ENCKEY) may be stored on the card”);
generating a first nonce (Rule para. [0034],”server 116 …may provide seed numbers to be used in the generation of the new PAN”; Rule para. [0079], “an unpredictable number provided by one or more servers, may be used for session key generation and/or diversification”; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
generating a data file containing script for updating the contactless card (Rule para. [0034], “server 116 may provide instructions relating to how to derive the new PAN”) and further containing a message authentication code (MAC) (Rule FIG. 2D, see “Message 230, Message Plaintext 234 and Encrypted MAC 242; Rule para. [0070], “the message plaintext 234 may be encoded in a format so that it can be multiplied by the shared secret 232. The resulting product may then be applied to the MAC algorithm.”);
transmitting the data file and the first nonce to the contactless card (Rule para. [0034], ”server 116 may provide instructions relating to how to derive the new PAN or may provide seed numbers to be used in the generation of the new PAN”);
causing the contactless card to validate the MAC based on the first unique derived key and the first nonce (Rule para. [0096], “The UID field of the received message may be extracted to derive, from master keys Iss-Key-AUTH 405 and Iss-Key-DEK 410, the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430) for that particular card. Using the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430), the counter (pATC) field of the received message may be used to derive the session keys (Aut-Session-Key 435 and DEK-Session-Key 440) for that particular card. Cryptogram B 460 may be decrypted using the DEK-Session-KEY, which yields cryptogram A 455 and RND, and RND may be discarded. The UID field may be used to look up the shared secret of the contactless card which, along with the Ver, UID, and pATC fields of the message, may be processed through the cryptographic MAC using the re-created Aut-Session-Key to create a MAC output, such as MAC′. If MAC′ is the same as cryptogram A 955, then this indicates that the message decryption and MAC checking have all passed.”); and
causing the preinstalled applet to execute the script for personalizing the contactless card (Rule Abstract, “A rewrite of the PAN may be triggered by issuing a write command to the second applet, or by interacting with the chip in a predetermined manner (e.g., tapping the card on an interactable element a predetermined number of times)”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul J Skwierawski whose telephone number is (571)272-2642. The examiner can normally be reached 6:00am-3:30pm weekdays.
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 supervisory primary examiner (SPE) Luu Pham can be reached on (571) 270-5002. 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.
/Paul Skwierawski/
Patent Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439