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, and Applicant’s Response filed on July 1, 2026.
Re prior claims 1-20: claims 1, 11 and 20 were independent claims; claims 1, 10-12 and 20 were amended; claims 3 and 14 were cancelled; and new claims 20-21 were added. Accordingly, claims 1-2, 4-13 and 15-22 are now pending, and have been examined in this application. This Action is made FINAL.
Response to Arguments
The rejection of claims 11-19 under 35 U.S.C. § 101 are withdrawn in view of Applicant’s claim amendments.
Applicants’ arguments in the instant Amendment, filed on July 1, 2026, with respect to limitations listed below, have been fully considered but they are not persuasive as follows.
Applicant’s arguments: “Applicant submits that Rule does not teach all features of claims 1, 2, 4-13, and 15-20.2 For example, claim 1 has been amended to recite, inter alia, that ''executing the script causes the preinstalled applet to: assign a second unique identifier to the contactless card, derive a second unique key based on the second unique identifier, and write, to a memory of the contactless card, additional information." Applicant submits that Rule does not teach or suggest at least these features of claim 1.”
The Examiner disagrees with the Applicants. More particularly, regarding these newly-added features/limitations, attention is directed to the revised rejections ahead, wherein newly-added (responsive) claim mapping is provided showing that such features/limitations were indeed taught or suggested by the applied Rule reference.
The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 272-2642 to schedule an interview.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-2, 4-13, 15-20 and 22 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)”);
wherein executing the script causes the preinstalled applet to:
assign a second unique identifier to the contactless card, derive a second unique key based on the second unique identifier (Rule para. [0083], “For the contactless card, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card. The key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card. In some examples, these diversified keys may comprise a first key and a second key. … In some examples, 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 applet.”), and
write, to a memory of the contactless card, additional information (Rule para. [0145], “The secondary information may comprise personally identifiable information about the user. In some examples, the secondary information may be stored within the contactless card.”).
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 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 second unique derived key for the contactless card replaces 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 comprising a processor coupled to memory, wherein the server is 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)”);
wherein executing the script causes the preinstalled applet to:
assign a second unique identifier to the contactless card, derive a second unique key based on the second unique identifier (Rule para. [0083], “For the contactless card, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card. The key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card. In some examples, these diversified keys may comprise a first key and a second key. … In some examples, 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 applet.”), and
write, to a memory of the contactless card, additional information (Rule para. [0145], “The secondary information may comprise personally identifiable information about the user. In some examples, the secondary information may be stored within the contactless card.”).
Per claim 12: Rule disclosed the system according to claim 11. Rule further discloses an arrangement wherein the second unique identifier for the contactless card replaces 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 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)”);
wherein executing the script causes the preinstalled applet to:
assign a second unique identifier to the contactless card, derive a second unique key based on the second unique identifier (Rule para. [0083], “For the contactless card, a different unique identifier is derived which may be related to the application primary account number (PAN) and PAN sequence number, which is encoded in the card. The key diversification may be configured to receive the identifier as input with the master key such that one or more keys may be created for each contactless card. In some examples, these diversified keys may comprise a first key and a second key. … In some examples, 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 applet.”), and
write, to a memory of the contactless card, additional information (Rule para. [0145], “The secondary information may comprise personally identifiable information about the user. In some examples, the secondary information may be stored within the contactless card.”).
Per claim 22: Rule disclosed the method according to claim 1. Rule further discloses an arrangement wherein executing the script further causes the preinstalled applet to discard the first unique identifier (Rule para. [0130], “applet (or other suitable logic on the card) may cause the display to be rewritten with the new card identifier”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Rule et al. (“Rule”; US20200184462A1) in view of Srivastava et al. (“Srivastava”; WO2017184840A1).
Per claim 21: Rule disclosed the non-statutory, computer-readable medium according to claim 20. Rule further discloses an arrangement wherein the additional information comprises information about a financial institution issuing the contactless card (Srivastava page 35, lines 15-18. “the issuing financial institution 802 may be identified by the primary account number stored in the authorization request, such as by using a portion of the primary account number (e.g., a bank identification number) for identification”).
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 extension fee 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 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
Prosecution Insights