DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response Applicant communication filed on 6/17/2026.
Claims
Claims 1,9, 12, and 20 have been amended.
Claims 5 and 13-19 has been cancelled.
Claims 1-4, 6-12, and 20-28 are currently pending in the application.
Response to Arguments
103
In Applicant’s arguments with respect to claims 1, 12, and 20 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
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 1-4, 6-8, 10, 12, 20-22, and 24-28 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200242588 A1 (“Rule”) and US 20240257097 A1 (“Arora”) and US 20170195298 A1 (“Brand”) and US 20210182853 A1 (“Camenares”).
Per claims 1, 12, and 20, Rule discloses:
a processor in a user device (e.g. As used in this application, the terms “system” and “component” and “module” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component can be, but is not limited to being, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer) (Section [0098]-[0100] and Fig. 1A);;
a memory in the user device storing a software application that, when executed by the processor, causes the processor to: (e.g. As used in this application, the terms “system” and “component” and “module” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component can be, but is not limited to being, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer) (Section [0098]-[0100] and Fig. 1A);
receive a payload from a card via the communication field, the payload comprising encrypted user identification data (e.g. The contactless card 101 may then encrypt the customer identifier 107 using the diversified key 106 to generate the encrypted customer ID 109. The contactless card 101 may then transmit the encrypted customer ID 109 to the account application 113 of the mobile device 110 (e.g., via an NFC connection, Bluetooth connection, etc.)) and a first authentication credential (e.g. Applets 440 may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., of the mobile device 110), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag) (Section [0026], [0037], and [0060]);
decrypt the encrypted user identification data using the private key (e.g. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107)) (Section [0038]);
match, upon decrypting the encrypted user identification data, the decrypted user identification data with a user account (e.g. Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the encrypted data received from the contactless card 101) (Section [0038]);
retrieve, upon matching the decrypted user identification data with the user account, checkout data, wherein the checkout data, wherein the checkout data comprises a virtual card number (VCN) of a virtual payment card… for satisfying the checkout request (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address. In one embodiment, the account number of the card data 103 is the virtual card number generated subsequent to the verification of the encrypted customer ID 109 by the management application 123) (Section [0039], [0040], and [0043]).
Note: Although Rule discloses both a “software application on a mobile device” that receives a payload from a card via the communication field and a “server” that decrypts the encrypted user identification data, matches the decrypted user identification data with a user account, and retrieves checkout data to satisfy the checkout request. Rule fails to explicitly disclose that they are integrated. However, it would have been an obvious matter of design choice to integrate them into a single computing device, and it appears that Rule would perform equally well with a single computing device. Such a modification would have achieved predictable benefits from economies of scale in addition to offering increased security, improved data management, fast response, and room for expansion while reducing both operating and capital costs. It is the examiner’s position that when the difference between the claimed invention and the prior art is that the prior art does not disclose particular elements as integral, as a matter of law, it would have been obvious to one having ordinary skill in the art to make the elements integral. See MPEP §2144.04 V. B. and In re Larson, 340 F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965).
Although Rule discloses receiving a payload from a card via a communication field to perform a payment process during an e-commerce checkout. Rule does not specifically disclose:
receive, over a network, a checkout request from a first server;
open, in response to receiving the checkout request, a communication field;
…the payload further comprising a private key;
…restricted to a predetermined geographical area...;
limit the use of the virtual card number to the predetermined geographical area by causing the virtual payment card to expire upon the user device being located beyond the geographical area;
However Arora, in analogous art of NFC card transactions with mobile devices, discloses:
receive, over a network, a checkout request from a first server (e.g. Further, at step 510, based on the user details received, the transaction server 120 may provide an NFC transaction request including an NFC transaction link via an SMS, email, and/or a push notification to the user mobile device 105 in order to initiate the NFC transaction) (Section [0053]);
open, in response to receiving the checkout request, a communication field (e.g. At step 515, in response to the user clicking on or selecting the NFC transaction link, the BNS 260 may in turn provide the recipient information to the transaction server 120. At step 520, the transaction server 120 may verify the recipient based on the recipient information and provide a transaction approval to the BNS 260. Based on the transaction approval, at step 525, the BNS 260 may prompt, such as by visual and/or auditory means, the user to bring the NFC card 110 in predefined proximity to the user mobile device 105) (Section [0041] and [0053]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the checkout process of Rule to include the opening of a communication field when a checkout request is received, as taught by Arora, in order to achieve the predictable result of increasing the security of the payment system by only allowing the user to use the communication field with their card when they intend to.
Although Rule/Arora discloses opening a communication field in response to receiving a checkout request, receiving a payload from a card via a communication field to perform a payment process during an e-commerce checkout, and decrypting user identification data included in the payload, Rule/Arora does not specifically disclose:
…the payload further comprising a private key;
…restricted to a predetermined geographical area...;
limit the use of the virtual card number to the predetermined geographical area by causing the virtual payment card to expire upon the user device being located beyond the geographical area.
However Brand, in analogous art of secure computer communication, discloses:
…the payload further comprising a private key (e.g. If communications are server-initiated, the seed may already have a value such that a symmetric key is calculated and included in the first asymmetrically encrypted payload transmitted to the mobile handset) (Section [0034], [0038], and [0081]-[0085]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the data payload of Rule/Arora to include a private encryption key, as taught by Brand, in order to achieve the predictable result of increasing the security of the payment system by allowing the computing devices to more securely communicate and protect against attackers trying to steal the data (See Brand paragraph [0003]).
Although Rule/Arora/Brand discloses retrieving checkout data comprising a virtual card number of a virtual payment card to perform a checkout, Rule/Arora/Brand does not specifically disclose:
…restricted to a predetermined geographical area...;
limit the use of the virtual card number to the predetermined geographical area by causing the virtual payment card to expire upon the user device being located beyond the geographical area.
However Camenares, in analogous art of card payments, discloses:
…restricted to a predetermined geographical area... (e.g. In some embodiments, the method may include determining, by the processor, whether the location of the credit card is outside of a predefined geographical area, and deactivating, by the processor, the credit card for use when the location of the credit card is outside of the predefined geographical area) (Section [0069], [0070], and [0104]);
limit the use of the virtual card number to the predetermined geographical area by causing the virtual payment card to expire upon the user device being located beyond the geographical area (e.g. However, in the event that location tracking circuitry 130 reports to processor 102 and/or processor 125 that credit card 110 has left geographic area 360 (e.g., as shown by an arrow 355), authentication module 175, authentication circuitry 135 (e.g., hardware) and/or authentication module 127 (e.g., software) may deactivate credit card 110 for use) and (e.g. In some embodiments, the credit card may be deactivated permanently) (Section [0069], [0070], and [0104]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the virtual payment card of Rule/Arora/Brand to include card deactivation when the user device leaves a predefined geographic area, as disclosed by Camenares, in order to achieve the predictable result of increasing the security of the virtual payment card by preventing payments by others who may get access to the virtual card details.
Per claims 2 and 28, Rule/Arora/Brand/Camenares discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the first authentication credential comprises a unique customer identifier associated with the card (e.g. In some examples, the contactless card 101 and server 120 may include certain data such that the card may be properly identified. The contactless card 101 may comprise one or more unique identifiers (not pictured)) (Section [0063]).
Per claim 3, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 1 above. Arora further discloses:
wherein the user identification data comprises a number associated with a user device (e.g. In some embodiments, the transaction server 120 may assign the PTIDs dynamically using multiple techniques including, but not limited to, using additional information related to the user mobile device 105 such as, but not limited to, a mobile number of the user and a location of the user mobile device 105 detected and/or identified. In another embodiment, the acquirer 125 or the transaction processor 130 may also assign different terminal identifications (TIDs) to the multiple mobile and/or electronic devices and the transaction server 120 may not be configured to implement the dynamic assigning of the PTIDs. In some embodiments, the transaction server 120 may be configured to combine the PTID assigned to the user mobile device 105 with the recipient information, such as the recipient ID, to uniquely identify each recipient identified based on the recipient information received corresponding to each application) (Section [0048]).
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 identifiers of Arora for the identification data of Rule/Brand/Camenares. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Per claims 4 and 26, Rule/Arora/Brand/Camenares discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the first authentication credential comprises a one-time password (OTP) (e.g. Applets 440 may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets 440 may be configured to respond to one or more requests, such as near field data exchange requests, from a reader, such as a mobile NFC reader (e.g., of the mobile device 110), and produce an NDEF message that comprises a cryptographically secure OTP encoded as an NDEF text tag) (Section [0060]).
Per claim 6, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the checkout data comprises at least one selected from the group of an address associated with the user account, a phone number associated with the user account, and an email associated with the user account (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address) (Section [0039] and [0043]).
Per claims 7 and 27, Rule/Arora/Brand/Camenares discloses all of the limitations of claims 1 and 12 above. Rule further discloses:
wherein the checkout data comprises at least one selected from the group of a card number, a card verification value (CVV), and a card expiration date associated with the card (e.g. In at least one embodiment, the management application 123 encrypts the card data 103 before sending to the account application 113. As stated, the card data 103 may include the account number, CVV, and/or expiration date of the contactless card 101. The card data 103 may further include the account holder's first name, last name, shipping address, and billing address) (Section [0039] and [0043]).
Per claim 8, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the checkout data is retrieved from a second server (e.g. after verifying the encrypted customer ID 109 of FIG. 1A, the management application 123 of the server 120 transmits the card data 103 from the server 120 to the mobile device 110) (Section [0038]-[0040]).
Per claim 10, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 1 above. Rule further discloses:
the first authentication credential is a message authentication code (MAC) (e.g. After communication has been established between mobile device 110 and contactless card 101, the contactless card 101 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 101 is read by the account application 113) (Section [0025]);
the card has generated the MAC over a counter value a unique customer identifier, and a session key (e.g. At this point, the counter value 104 maintained by the contactless card 101 may be updated or incremented, which may be followed by “Read NDEF file.” At this point, the message may be generated which may include a header and a shared secret. Session keys may then be generated. The MAC cryptogram may be created from the message, which may include the header and the shared secret. The MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with the session key) (Section [0025]).
the software application has caused the processor to decrypt the MAC using the private key… (e.g. As stated, the counter value 104 may be specified in the data received from the mobile device 110, or a counter value 104 maintained by the server 120 to implement key diversification for the contactless card 101. The output of the encryption may be the same diversified key value 106 that was created by the contactless card 101. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107). Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account) (Section [0027]).
Brand further discloses:
…private key received in the payload (e.g. If communications are server-initiated, the seed may already have a value such that a symmetric key is calculated and included in the first asymmetrically encrypted payload transmitted to the mobile handset) (Section [0034], [0038], and [0081]-[0085]).
The motivation to combine Brand with Rule/Arora/Camenares is disclosed above with reference to claims 1, 12, and 20.
Per claim 21, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 1 above. Rule further discloses:
wherein the encrypted user identification data is encrypted using a hash function (e.g. More generally, when preparing to send data (e.g., to the server 120 and/or the mobile device 110), the contactless card 101 may increment the counter value 104. The contactless card 101 may then provide the master key 105 and counter value 104 as input to a cryptographic algorithm, which produces a diversified key 106 as output. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of the cryptographic algorithm may include a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm, such as HMAC-SHA-256; and a symmetric CMAC algorithm such as AES-CMAC) (Section [0026] and [0028]).
Per claim 22, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 12 above. Rule further discloses:
wherein the checkout data is retrieved from the user device (e.g. In another embodiment, the account number of the card data 103 is a record from the account numbers 108. In one embodiment, the first and last names are stored in the account application 113 (or another element of the OS). In such embodiments, the account application 113 may provide the locally stored names to the autofill service 114 with the card data 103. Furthermore, as stated, the account number may comprise a virtual account number. The account application 113 may then receive the card data 103 and decrypt the received card data 103 (if the card data 103 has been encrypted). The account application 113 may then provide the card data 103 to an API of the autofill service 114 (and/or the accessibility service 117)) (Section [0039]).
Per claim 24, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 12 above. Arora further discloses:
wherein the software application is a mobile application (e.g. The user mobile device 105 may have one or more applications installed or stored in the user mobile device 105. The applications may include system applications that may be pre-installed by a device manufacturer and/or installed applications that may downloaded from an application distribution platform and/or installed by the user in the user mobile device 105 via the network 115. Examples of the applications include, but are not limited to, merchant applications, ecommerce applications, financial applications such as banking applications and/or payment or fund transfer applications, travel, transit tickets and toll applications, donation collection applications, loyalty applications and service provider applications such as, short service message (SMS), email, and/or push notifications, that facilitate and/or aid financial transactions) (Section [0022]).
The motivation to combine Arora with Rule/Brand is disclosed above with reference to claims 1, 12, and 20.
Per claim 25, Rule/Arora/Brand/Camenares discloses all of the limitations of claim 12 above. Rule further discloses:
transmitting, by the software application, the decrypted user identification data to a second server (e.g. the account application 113 of the mobile device 110 may then transmit the encrypted customer ID 109 to the server 120 via the network 130. In at least one embodiment, the contactless card 101 transmits the counter value 104 along with the encrypted customer ID 109) (Section [0037]-[0038]);
receiving, by the software application, checkout data from the second server wherein the second server has matched the decrypted user identification data with a user account, the user account comprising at least the checkout data (e.g. The management application 123 may then decrypt the encrypted customer ID 109 received via the network 130 using the diversified key 106, which reveals the data transmitted by the contactless card 101 (e.g., at least the customer identifier 107). Doing so allows the management application 123 to verify the data transmitted by the contactless card 101 via the mobile device 110, e.g., by comparing the decrypted customer ID 107 to a customer ID in the account data 124 for the account, where a match of the customer ID values verifies the encrypted data received from the contactless card 101. In some embodiments, once the management application 123 verifies the encrypted customer ID 109, the management application 123 generates a virtual card number for the associated account, or causes a virtual card number for the associated account to be generated). (e.g. As shown in FIG. 1B, after verifying the encrypted customer ID 109 of FIG. 1A, the management application 123 of the server 120 transmits the card data 103 from the server 120 to the mobile device 110) (Section [0038]-[0039]);
Note: Although Rule discloses both a “software application on a mobile device” that receives a payload from a card via the communication field and a “server” that decrypts the encrypted user identification data, matches the decrypted user identification data with a user account, and retrieves checkout data to satisfy the checkout request. Rule fails to explicitly disclose that they are integrated. However, it would have been an obvious matter of design choice to integrate them into a single computing device, and it appears that Rule would perform equally well with a single computing device. Such a modification would have achieved predictable benefits from economies of scale in addition to offering increased security, improved data management, fast response, and room for expansion while reducing both operating and capital costs. It is the examiner’s position that when the difference between the claimed invention and the prior art is that the prior art does not disclose particular elements as integral, as a matter of law, it would have been obvious to one having ordinary skill in the art to make the elements integral. See MPEP §2144.04 V. B. and In re Larson, 340 F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rule/Arora/Brand/Camenares, as applied to claim 1 above, in further view of US 20250348870 A1 (“Deshpande”).
Per claim 9, Rule/Arora/Brand/Camenares discloses all the limitations of claim 1 above. Rule further discloses:
the software application is associated with a merchant mobile application configured to perform one or more mobile transactions (e.g. The user mobile device 105 may have one or more applications installed or stored in the user mobile device 105. The applications may include system applications that may be pre-installed by a device manufacturer and/or installed applications that may downloaded from an application distribution platform and/or installed by the user in the user mobile device 105 via the network 115. Examples of the applications include, but are not limited to, merchant applications, ecommerce applications, financial applications such as banking applications and/or payment or fund transfer applications, travel, transit tickets and toll applications, donation collection applications, loyalty applications and service provider applications such as, short service message (SMS), email, and/or push notifications, that facilitate and/or aid financial transactions) (Section [0022]);
the checkout request is associated with a merchant (e.g. In some examples the POS device can be affiliated with an authorized merchant or other entity familiar with certain contactless cards or accustomed to performing certain contactless card transactions) (Section [0090]);
Although Rule/Arora/Brand/Camenares discloses a mobile application that gets checkout data for a transaction with a merchant, Rule/Arora/Brand/Camenares do not specifically disclose:
the predetermined geographical area is based on a location of the merchant.
However Deshpande, in analogous art of digital card transactions, discloses:
the predetermined geographical area is based on a location of the merchant (e.g. Furthermore, the single-use financing solution may, in some embodiments, only be used with a single (or designated) merchant or for a single (or designated) item. The single or designated merchant may be the entity at the unique geographic location. A geographic location may include a particular position on Earth and may be designated by, for example, an address or a combination of longitude and latitude of a particular place) (Sections [0021], [0032], and [0033]) (See provisional application 63/485,150 specification of Deshpande reference);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the payment card geographical area of Rule/Arora/Brand/Camenares to be based on the location of the merchant, as taught by Deshpande, in order to achieve the predictable result of increasing the security of the payment transaction by only allowing the virtual card to be used in the same area as the intended merchant.
Claims 11 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Rule/Arora/Brand/Camenares, as applied to claims 1 and 12 above, in further view of US 20190095989 A1 (“Archer”).
Per claims 11 and 23, although Rule/Arora/Brand/Camenares discloses a software application that gets checkout data based on receiving a payload from a card, Rule/Arora/Brand/Camenares do not specifically disclose:
receiving an account creation request, the account creation request further comprising the checkout data;
generate, in response to receiving the account creation request, a second user account.
However Archer, in analogous art of online transactions, discloses:
receiving an account creation request, the account creation request further comprising the checkout data (e.g. The process 300 receives (305) a request from a client to create a new account. Clients can include (but are not limited to) merchant POS terminals, mobile applications, and websites. Requests can include a variety of information, including (but not limited to) information about a consumer to be associated with the card, information about the account set up, and/or information about a merchant or retailer that initiated the request for the new account. Such information can include (but is not limited to) credit scores, credit history, pre-load amounts, geographic locations, a number of previous requests for new accounts, and/or an amount of funds that have been loaded into other new accounts) (Section [0045]);
generate, in response to receiving the account creation request, a second user account (e.g. The process provides (335) the proxy and retrieved account information to the client that initiated the request. Clients in accordance with many embodiments use a proxy and associated account information to initialize a card (e.g., a pre-paid card), and to associate the card with the newly created account. In many embodiments, consumers can use such cards to transfer funds, withdraw funds, make purchases at various retailers, and/or to add additional funds to the associated account) (Section [0049]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the NFC checkout process of Rule/Arora/Brand/Camenares to include the account creation process, as taught by Archer, in order to achieve the predictable result of providing convenience to the user so that they can easily perform transactions in the future using the same account.
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
Prosecution Insights