DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This Office Action is in response Applicant communication filed on 1/27/2026.
Claims
Claims 10, 11, 19, and 20 have been amended.
Claims 1-9 has been cancelled.
Claims 21-29 have been newly added.
Claims 10-29 are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statement (IDS) that was filed on 9/25/2025 has been considered.
Response to Arguments
101
The examiner withdraws the 101 rejection based on the applicant’s amendments. The claims require the use of technology to provision an encrypted crypto wallet which is not an abstract idea.
103
In Applicant’s arguments with respect to claim 10 have been considered but are moot because the arguments are directed to the newly added limitations. New references have been added as necessitated by the applicant’s amendments to the claims.
Objections
The examiner withdraws the previous claim objections due to the claim amendments.
Rejections under 35 § U.S.C. 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.
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.
Claims 10, 14-17, 19, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over US 9450763 B2 (“Fu”) and US 20130232083 A1 to (“Smith”) and US 20250086616 A1 (“Li”) and US 9,183,554 B1 (“Courtright”).
Per claims 10, 19, and 21 Fu discloses:
receiving, by an administrator processor, a request to generate a private key, a public key, and a key-encrypted-key (KEK) (e.g. TPS 205 may receive an enrollment request and the CID from the security client 130 because the user has inserted a new token in the security device 125, in step 305. The TPS 205 may determine that the inserted token requires serverside key generation and key archiving based on configuration policies set up by the system administrator. Alternatively, in other embodiments, the user of the token may request serverside key generation and/or key archiving) (Column 3, Ln 8-18 and Column 7, Ln 42-51 and Fig. 3);
receiving, by the administrator processor over a network, a user datum from a card (e.g. TPS 205 may receive an enrollment request and the CID from the security client 130 because the user has inserted a new token in the security device 125, in step 305) (Column 3, Ln 37-49 and Column 7, Ln 42-51 and Fig. 3);
transmitting, by the administrator processor over the network, the user datum to a server (e.g. Subsequently, the TPS 205 may forward the CID to the TKS module 210, in step 310) (Column 7, Ln 42-51 and Fig. 3);
wherein the server has… encrypted the private and public keys over the KEK (e.g. One of the derived keys is the key encryption key, KEK, which is configured to encrypt other secret keys) (Column 3, Ln 8-18 and Ln 37-49).
Note: the limitation “wherein the server has… encrypted the private and public keys over the KEK” does not distinguish over the prior art because it is not positively recited as a step/function of the claims. Instead it is describing the steps/functions of the server which is outside the scope of the claims that are directed to the steps/functions of the administrator processor and user device.
Although Fu discloses receiving a request to generate encryption keys, receiving user datum from a card, using a KEK to encrypt encryption keys, and sending the encrypted encryption keys and KEK back to as security token to be stored on a card, Fu does not specifically disclose:
transmitting, by the administrator processor to a user device, an authentication request;
receiving, by the administrator processor from the user device, an authentication credential distinct from the private key, the public key, and the KEK;
receiving, by the administrator processor from the server, an encrypted private key, an encrypted public key, and a KEK from the server, wherein the server has generated the private key and public key over the user datum…;
transmitting, by the administrator processor to the card, the encrypted private key, the encrypted public, and the KEK.
However Smith, in analogous art of provisioning card accounts, teaches:
receiving, by the administrator processor from the server, an encrypted private key, an encrypted public key, and a KEK from the server… (e.g. In step 1002, an integrated circuit card (ICC) RSA key pair including an ICC public key and an ICC private key may be generated by a generating device (e.g., included in the service provider 110). In step 1004, the generating device may generate an ICC master key based on at least a master key identifier (e.g., the master key identifier 706)) (Section [0089] and [0090]);
transmitting, by the administrator processor to the card, the encrypted private key, the encrypted public, and the KEK (e.g. In step 1006, a transmitting device may transmit at least the ICC public key, the ICC private key, the ICC master key, and the master key identifier to a mobile device (e.g., the mobile device 102) for storage in a secure element (e.g., the secure element 210)) (Section [0089] and [0090]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the encryption keys of Fu to include a private key, public key, and KEK, as taught by Wells, in order to achieve the predictable result of increasing the security of the card transactions by ensuring that only the intended user can encrypt/decrypt data and provide digital signatures.
Although Fu/Smith teaches sending user datum received from a card to a server and generating a private key and public key for the card, Fu/Smith do not specifically disclose:
transmitting, by the administrator processor to a user device, an authentication request;
receiving, by the administrator processor from the user device, an authentication credential distinct from the private key, the public key, and the KEK;
…wherein the server has generated the private key and public key over the user datum….
However Li, in analogous art of digital wallets, teaches:
…wherein the server has generated the private key and public key over the user datum… (e.g. In FIG. 15, operations 1501-1504 and 1512-1513 may be performed by the electronic device of a user and operations 1505-1511 may be performed by a node/server of the blockchain network. The user's fingerprints images may be received, and the fingerprint feature codes may be generated (at block 1501) by fuzzy code algorithm. The fingerprint feature codes are used to generate (at block 1502) digital wallet's private key, public key, and commitment) (Section [0158]).
Note: the limitation “wherein the server has generated the private key and public key over the user datum” does not distinguish over the prior art because it is not positively recited as a step/function of the claims. Instead it is describing the steps/functions of the server which is outside the scope of the claims that are directed to the steps/functions of the administrator processor and user device.
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the card provisioning system/method of Fu/Smith to include the generation of the private/public keys using the user datum, as taught by Li, in order to achieve the predictable result of increasing the security of the card provisioning by using biometric information that only the user has to generate the public/private keys of the user account.
Although Fu/Smith/Li teaches sending user datum received from a card to a server and generating a private key and public key for the card over the user datum, Fu/Smith/Li do not specifically disclose:
transmitting, by the administrator processor to a user device, an authentication request;
receiving, by the administrator processor from the user device, an authentication credential distinct from the private key, the public key, and the KEK.
However Courtright, in analogous art of authentication at an ATM, teaches:
transmitting, by the administrator processor to a user device, an authentication request (e.g. The user may receive a request to authenticate on the mobile device from the ATM or POS over an appropriate communications channel. The user may provide a gesture in response to the request. The gesture may be input by the user on the touchscreen of the mobile device, in an implementation, and may be transmitted to the ATM/POS where it is received) (Column 3, Ln 39-67 and Column 9, Ln 20-26);
receiving, by the administrator processor from the user device, an authentication credential distinct from the private key, the public key, and the KEK (e.g. The user may receive a request to authenticate on the mobile device from the ATM or POS over an appropriate communications channel. The user may provide a gesture in response to the request. The gesture may be input by the user on the touchscreen of the mobile device, in an implementation, and may be transmitted to the ATM/POS where it is received) (Column 3, Ln 39-67 and Column 9, Ln 20-26).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the card provisioning system/method of Fu/Smith/Li to include transmitting an authentication request and receiving an authentication credential in response, as taught by Courtright, in order to achieve the predictable result of increasing the security of the card provisioning by ensuring that the user is authorized before proceeding.
Per claims 14 and 22, Fu/Smith/Li/Courtright disclose all the limitations of claims 10 and 21 above. Fu further discloses:
wherein the user datum comprises at least one selected from the group of a unique customer identifier and a counter value (e.g. Accordingly, the security client may transmit a serial number, card unique identification, or card identification (CID) to the TPS of the TMS. The TPS may be configured to forward the CID of the token to the TKS module. The TKS module may be configured to derive a series of keys based on the server master key and the CID) (Column 3, Ln 37-49 and Column 7, Ln 42-62).
Note: the limitation “wherein the user datum comprises at least one selected from the group of a unique customer identifier and a counter value” does not distinguish over the prior art because it is simply describing the data and does not affect the steps/functions of the claims in a manipulative sense.
Per claims 15 and 23, Fu/Smith/Li/Courtright disclose all the limitations of claims 10 and 21 above. Fu further discloses:
wherein the user datum comprises at least one selected from the group of a primary account number (PAN) and a card verification value (CVV) (e.g. Accordingly, the security client may transmit a serial number, card unique identification, or card identification (CID) to the TPS of the TMS. The TPS may be configured to forward the CID of the token to the TKS module. The TKS module may be configured to derive a series of keys based on the server master key and the CID) (Column 3, Ln 37-49 and Column 7, Ln 42-62).
Note: the limitation “wherein the user datum comprises at least one selected from the group of a primary account number (PAN) and a card verification value (CVV)” does not distinguish over the prior art because it is simply describing the data and does not affect the steps/functions of the claims in a manipulative sense.
Per claim 16, Fu/Smith/Li/Courtright disclose all the limitations of claim 10 above. Li further discloses:
wherein the steps further comprise deriving, upon receiving a lost key notification from the user, the private key and public key from the user datum (e.g. The objective of the recovery process is to retrieve the user's account identifier (e.g., the account identifier 1211 of FIG. 12), the private key 1206 and the public key 1207 by user's biometric information (e.g., and without limitations, the fingerprints). The user's electronic device providers the user's biometric information (e.g., by scanning the user's fingerprints) and generates (at block 1601) the feature codes by fuzzy code algorithm. The private key, the public key, and the proof of commitment (e.g., the values a and z, as described below with reference to FIG. 25) are generated (at block 1602) based on those feature codes) (Section [0162] and [0163]).
The motivation to combine Li with Fu/Smith/Courtright is disclosed above with reference to claims 10, 19, and 21.
Per claim 17, Fu/Smith/Li/Courtright disclose all the limitations of claim 10 above. Fu further discloses:
wherein a user device transmits the user datum to the administrator processor over a card reader (e.g. The security client may detect the presence of an inserted token in an associated card reader and inform TPS of the token) (Column 3, Ln 8-18).
Per claim 24, Fu/Smith/Li/Courtright disclose all the limitations of claim 21 above. Li further discloses:
wherein the private key and the public key are associated with a cryptocurrency wallet (e.g. The fingerprint feature codes are used to generate (at block 1502) digital wallet's private key, public key, and commitment) (Section [0125] and [0158]).
The motivation to combine Li with Fu/Smith/Courtright is disclosed above with reference to claims 10, 19, and 21.
Per claim 25, Fu/Smith/Li/Courtright disclose all the limitations of claim 21 above. Fu further discloses:
receive a second user datum from a user device (e.g. TPS 205 may receive an enrollment request and the CID from the security client 130 because the user has inserted a new token in the security device 125, in step 305) (Column 3, Ln 37-49 and Column 7, Ln 42-51 and Fig. 3).
Smith further discloses:
send, to the user device, a second private key, a second public key, and a second KEK (e.g. In step 1006, a transmitting device may transmit at least the ICC public key, the ICC private key, the ICC master key, and the master key identifier to a mobile device (e.g., the mobile device 102) for storage in a secure element (e.g., the secure element 210)) (Section [0089] and [0090]).
The motivation to combine Smith with Fu/Li/Courtright is disclosed above with reference to claims 10, 19, and 21.
Per claim 28, Fu/Smith/Li/Courtright disclose all the limitations of claim 21 above. Fu further discloses:
wherein a user device transmits the user datum to the administrator processor over a card reader (e.g. The security client may detect the presence of an inserted token in an associated card reader) (Column 3, Ln 8-18 and Column 3, Ln 37-49 and Column 7, Ln 42-51 and Fig. 3).
Claims 11, 12, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fu/Smith/Li/Courtright, as applied to claims 10 and 19 above, in further view of US 20220321340 A1 (“Tsitrin”).
Per claims 11 and 20, Although Fu/Smith/Li/Courtright discloses the use of a private key, public key, and KEK to provision a card/wallet account, Fu/Smith/Li/Courtright do not specifically disclose:
transmitting, by the user device application to the administrator processor, a request to retrieve the first private key, first public key, and first KEK;
receiving, by the user device from the administrator processor, the authentication request;
transmitting, by the user device to the administrator processor, the authentication credential;
receiving, by the user device from the administrator processor, the first private key, first public key, and first KEK, wherein the administrator processor has transmitted the authentication credential to the server and, in response, received the first encrypted private key, first encrypted public key, and first KEK.
However Tsitrin, in analogous art of recovering cryptocurrency wallets, teaches:
transmitting, by the user device application to the administrator processor, a request to retrieve the first private key, first public key, and first KEK (e.g. In FIG. 20, a key recovery request may be obtained at 2001. For example, the key recovery request may be obtained as a result of a user utilizing a UI of a recovery utility to initiate key recovery of a master key associated with a hierarchical deterministic wallet) (Section [0244]);
receiving, by the user device from the administrator processor, the authentication request (e.g. A RSA public key may be requested from a hosting HSM at 2009. In one implementation, a public key request message may be sent to the hosting HSM to request the RSA public key) (Section [0246]);
transmitting, by the user device to the administrator processor, the authentication credential (e.g. A determination may be made at 2011 whether the obtained RSA public key is valid. For example, the recovery utility may be configured to work with a specified set of hosting HSMs, and the obtained RSA public key may have to be associated with one of the specified hosting HSMs to be valid) (Section [0246]-[0249]);
receiving, by the user device from the administrator processor, the first private key, first public key, and first KEK, wherein the administrator processor has transmitted the authentication credential to the server and, in response, received the first encrypted private key, first encrypted public key, and first KEK (e.g. The encrypted master key may be provided to the hosting HSM at 2029. For example, the hosting HSM may decrypt and/or store the recovered master key for the specified wallet) (Section [0251]-[0253]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the card/wallet provisioning system/method of Fu/Smith/Li/Courtright to include the capability of retrieving/recovering card/wallet keys, as taught by Tsitrin, in order to achieve the predictable result of providing convenience to the user so that they will not lose all of the funds in their wallet if they forget/lose their keys.
Per claim 12, Fu/Smith/Li/Courtright/Tsitrin discloses all the limitations of claim 11 above. Li further teaches:
wherein the authentication credential comprises at least one selected from the group of a unique customer identifier, a digital signature, and a message authentication code (MAC) (e.g. The objective of the recovery process is to retrieve the user's account identifier (e.g., the account identifier 1211 of FIG. 12), the private key 1206 and the public key 1207 by user's biometric information (e.g., and without limitations, the fingerprints). The user's electronic device providers the user's biometric information (e.g., by scanning the user's fingerprints) and generates (at block 1601) the feature codes by fuzzy code algorithm) (Section [0162] and [0163]).
Note: the limitation “wherein the authentication credential comprises at least one selected from the group of a unique customer identifier, a digital signature, and a message authentication code (MAC)” does not distinguish over the prior art because it is simply describing the data and does not affect the steps/functions of the claims in a manipulative sense.
The motivation to combine Li with Fu/Smith/Courtright/Tsitrin is disclosed above with reference to claims 10 and 19.
Per claim 13, Fu/Smith/Li/Courtright/Tsitrin discloses all the limitations of claim 11 above. Li further teaches:
wherein the authentication credential is a biometric comprising at least one selected from the group of a fingerprint scan, face scan, and voice scan (e.g. The objective of the recovery process is to retrieve the user's account identifier (e.g., the account identifier 1211 of FIG. 12), the private key 1206 and the public key 1207 by user's biometric information (e.g., and without limitations, the fingerprints). The user's electronic device providers the user's biometric information (e.g., by scanning the user's fingerprints) and generates (at block 1601) the feature codes by fuzzy code algorithm) (Section [0162] and [0163]).
Note: the limitation “wherein the authentication credential is a biometric comprising at least one selected from the group of a fingerprint scan, face scan, and voice scan” does not distinguish over the prior art because it is simply describing the data and does not affect the steps/functions of the claims in a manipulative sense.
The motivation to combine Li with Fu/Smith/Courtright/Tsitrin is disclosed above with reference to claims 10 and 19.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Fu/Smith/Li/Courtright, as applied to claim 10 above, in further view of US 20210090044 A1 (“Edwards”).
Per claim 18, Although Fu/Smith/Li/Courtright discloses the use of an administrator processor to provision a card/wallet account, Fu/Smith/Li/Courtright do not specifically disclose:
wherein the administrator processor is an automated teller machine (ATM).
However Edwards, in analogous art of ATMs, teaches:
wherein the administrator processor is an automated teller machine (ATM) (e.g. In an example embodiment, an ATM can include a processing unit. The processing unit can include a processor, a memory (and/or hard drive), a transmitter and a receiver. The processor can execute and run an operating system software stored on the memory (and/or hard drive) of the processing unit. Using the transceivers (i.e., transmitters and receivers), the processor can connect to a network, such as the Internet, and transmit and receive signals form a server. For example, the ATM can respond to polling requests received from the server, and in response to receiving messages from the server, the processor can cause a speaker or display of the ATM to emit sounds or display visual cues. The transceivers can use APIs for communications with the server. Additionally, the transceivers can communicate with a client device such as a cellphone, tablet or other wireless devices. The transceivers can use standard wireless communication protocols for these communications, e.g., Wi-Fi, Bluetooth, NFC, etc. In certain instances, the communications can be encrypted) (Section [0018]-[0024]).
Note: the limitation “wherein the administrator processor is an automated teller machine (ATM)” does not distinguish over the prior art because it is describing the administrator processor which does not affect the steps/functions of the claim in a manipulative sense.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself that is in the substitution of the ATM computing device of Edwards for the computer/server devices of Fu/Smith/Li/Courtright. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Fu/Smith/Li/Courtright, as applied to claim 21 above, in further view of US 20220239509 A1 (“Jang”).
Per claim 26, Although Fu/Smith/Li/Courtright discloses the generation of a private key over the user datum, Fu/Smith/Li/Courtright do not specifically disclose:
wherein the private key is generated by hashing the user datum.
However Jang, in analogous art of recovering blockchain keys, teaches:
wherein the private key is generated by hashing the user datum (e.g. The electronic device 210 may generate a key used to perform a digital signature based on a root key value. For example, the electronic device may generate a private key used to perform a digital signature using a hash function from a root key value and may generate a public key making up a key pair with the private key. The root key value may include, for example, a seed value (e.g., a root seed) or mnemonic information for obtaining the seed value) (Section [0078]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the private key generation of Fu/Smith/Li/Courtright to use a hashing algorithm, as taught by Jang, in order to achieve the predictable result of increasing security of the system by providing data integrity and irreversible key creation.
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Fu/Smith/Li/Courtright, as applied to claim 21 above, in further view of US 20230188340 A1 (“Osborn”).
Per claim 27, Although Fu/Smith/Li/Courtright discloses a user blockchain wallet address associated with a private and public key, Fu/Smith/Li/Courtright do not specifically disclose:
wherein the server has generated a wallet address associated with the private key and the public key.
However Osborn, in analogous art of recovering keys, teaches:
wherein the server has generated a wallet address associated with the private key and the public key (e.g. The server may then create a public key corresponding to the private key and generate a wallet address for the digital wallet based on the public key) (Section [0022]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the blockchain key generation system of Fu/Smith/Li/Courtright to generate a blockchain wallet address, as taught by Osborn, in order to achieve the predictable result of increasing security by ensuring the user has full control of their digital assets and enhanced privacy.
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Fu/Smith/Li/Courtright, as applied to claim 21 above, in further view of US 20090143104 A1 (“Loh”).
Per claim 29, Although Fu/Smith/Li/Courtright discloses a computing device that transmits the encrypted private key, the encrypted public key, and the KEK to the user device, Fu/Smith/Li/Courtright do not specifically disclose:
wherein the computing device transmits the encrypted private key, encrypted public key, and KEK to the card via the user device.
However Loh, in analogous art of smart payment cards, teaches:
wherein the computing device transmits the encrypted private key, encrypted public key, and KEK to the card via the user device (e.g. The service server 256 then establishes a secure link to the mobile communication device 108. On request of the service server 256, the interface of the mobile communication device 108 prompts the user to activate the wireless smart card 104 (e.g., by pushing an activation button of the smart wireless transponder). Upon user activation, the smart wireless transponder establishes a secure link to the mobile communication device 108 through the PAN (Bluetooth) wireless connection via the PAN transceiver 124. The control interface of the mobile communication device 108 then requests to establish a communication link with the secure element 132. Once all links are established, the mobile communication device 108 indicates to the financial transaction server(s) 264 through the service server 256 that communication to the secure element 132 is ready. The financial transaction server(s) 264 interacts directly with the secure element 132 through the secure communications established through the mobile communication device 108, and loads the appropriate applet to the secure element 132, provisions the applet with the user credentials and activates them for future use) (Section [0070]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the card provisioning of Fu/Smith/Li/Courtright to send the wallet keys to the card via the user device, as taught by Loh, in order to achieve the predictable result of increasing security by allowing the card to receive the keys without requiring an internet connection which helps makes the card more secure.
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698