Acknowledgements
This communication is in response to applicant’s response filed on 02/02/2026.
Claims 1, 3, 11, 13, and 20 have been amended.
Claims 1-20 are pending and have been examined.
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 .
Response to Arguments
Regarding the applicant’s arguments:
Regarding applicant’s arguments, see pgs. 8-9, filed 02/02/2026, with respect to the rejection(s) of claim(s) 1, 11, and 20 under Claim Rejections - 35 USC § 103 that the combination of Desmarais in view of Chen does not teach the private cryptographic key is accessed only during a temporary offline connection to generate one or more pre-authorized transaction requests that fully encode predetermined transaction parameters, including a recipient address, and that satisfy all protocol requirements for acceptance by a blockchain validating node have been fully considered and are persuasive. In addition, the combination does not teach once generated, these pre-authorized transaction requests are cryptographically complete and require no additional signing, payload completion, or key retrieval at the time of broadcast have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Goroff (US 20190325408).
Claim Rejections - 35 USC § 102(a)(1)
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3, 7, 10-11, 13, 17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Goroff (US 20190325408).
Regarding Claims 1, 11, and 20, Goroff teaches storing, in an offline storage, a private cryptographic key that corresponds to a public cryptographic key that corresponds to a blockchain address of a blockchain (Paragraphs 0026 and 0033 teach FIGS. 3A-3F illustrate a hardware encryption device according to the present invention; the hardware encryption device generates and stores the private key in a secure microcontroller (secure element), and FIGS. 3A-3F show various features involved in generating and storing the private key, as well as other aspects involved in confirming a cryptocurrency transaction or other activity; the present hardware encryption device uses hierarchical deterministic key generation to derive a theoretically infinite number of cryptographic secrets from a single master seed; in this way, the cryptocurrency private keys, passwords, and other cryptographic secret data can all be determined and intrinsically stored in a single master seed; the hardware encryption device can use the BIP39 industry standard for creating the master seed, and uses BIP32 industry standard for HD key generation and BIP44 for the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain, which allows the creation of an infinite number of wallets and private keys for cryptocurrency coins); connecting temporarily to the offline storage to generate one or more pre-authorized transaction requests using the private cryptographic key stored in the offline storage (Paragraphs 0035, 0038, and 0046-0047 teach the hardware encryption device does not have any port, and uses wireless data transfer protocols to sign the transactions; the smartphone application automatically detects the surrounding for the hardware encryption device; all transactions are signed by the hardware encryption device via an API in which the application sends the requested transaction to be signed to the hardware encryption device; a display on the hardware encryption device displays all the parameters of the requested transaction and requests user confirmation; the user confirms the transaction by a successful fingerprint match at which point the hardware encryption device signs the transaction with the users embedded private key and returns the signed transaction to the application for sending to the blockchain; a user opens a cryptocurrency application on their smartphone or smart computing device; the process requests that the user enter transaction parameters and insert the hardware encryption device into the smartphone; note that the hardware encryption device can be attached before or after initiating transaction; it is to be further noted that when the hardware encryption device is unplugged or removed from the smartphone, this is a “cold” cryptocurrency wallet, whereas the hardware encryption device becomes a “hot” wallet when coupled to the smartphone for executing cryptocurrency transactions (or performing other activities requiring authentication); the transaction parameters are sent to the hardware encryption device to be displayed on the touchscreen display configured thereon; the process then verifies transaction parameters, for example by requesting that the user enter a yes or no via the touchscreen display, and proceeds with confirming the verification using the biometric authentical element(s) on the hardware encryption device; the user may utilize the application on the smartphone or smart computing device to perform a wide array of cryptocurrency transactions); disconnecting from the offline storage (Paragraph 0050 teaches referring to FIG. 4C the user signs out, and optionally the process may request further biometric confirmation from the user; regardless, after signing out the user may unplug the hardware encryption device from the smartphone, and the process is reinitialized for new transaction parameters to be entered); and storing the one or more pre-authorized transaction requests in a computing device, wherein the one or more pre-authorized transaction requests include pre-determined parameters that include a recipient address (Paragraph 0050 teaches final confirmation of the transaction is performed using the private key signature of hardware encryption device; once this is accomplished, confirmation of the transaction is sent to the cryptocurrency application on the smartphone or other smart computing device, and the transaction parameters are then communicated on to a blockchain for recordation of the transaction), and wherein generating such that the one or more pre-authorized transaction requests comprises generating, using the private cryptographic key while the computing device is temporarily connected to the offline storage, a complete, blockchain-valid transaction payload that encodes the recipient address and the pre-authorized transaction requests are broadcastable to the blockchain without further retrieving the private cryptographic key stored in the disconnected storage (Paragraph 0025 teaches the user decides to which address to send the funds, which can be entered into the user interface displayed on the smartphone, without the hardware encryption device connected; the application installed on the smartphone receives the user in destination cryptocurrency address and the amount of funds to be sent to that address; the hardware encryption device stores the cryptocurrency private key or keys, and includes a stored amount of funds in token form (such as n number of Bitcoins); the application on the smartphone and/or the application installed on the hardware encryption device detects when the hardware encryption device is in data communication with the smartphone; the application installed on the smartphone receives an authorization to perform the transaction, as defined by the user, from the hardware encryption device, and the funds to be transferred are sent to the hardware wallet on the smartphone, while the remaining funds remain on the hardware encryption device; the transaction is confirmed by the user and signed by the private key on the hardware encryption device; the application installed on the smartphone, then broadcasts the signed transaction to the network, where the miner computer(s) verify the transaction; the hardware encryption device may be optionally detached or disconnected from the smartphone after it send the authorization to the smartphone).
Regarding Claim 1, Goroff teaches a system comprising: an offline storage configured to store a private cryptographic key that corresponds to a public cryptographic key that corresponds to a blockchain address of a blockchain; and a computing device comprising memory and one or more processors, the memory storing executable instructions, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform operations (Paragraph 0024 teaches the hard drive of the user smartphone and the hardware encryption device are encoded with executable instructions, that when executed by a processor (in each device) causes the processor to perform acts as outlined in FIGS. 2, 4 and 5; in an example embodiment, the user interacts with the smartphone to access and interact with the graphical user interface through either a web application running on a mobile web browser or a mobile application (commonly called an “app”) installed on the smartphone and displayed on the screen; the application installed on the smartphone communicates and sends/receives data to/from the hardware encryption device, when the device connector is inserted into and in data communication with the smartphone, through the smartphone connector).
Regarding Claim 11, Goroff teaches a computer-implemented method (Paragraphs 0025 and 0046 teach referring now to FIG. 2, which broadly describes one example embodiment of the present method; FIGS. 4-4C illustrate the method of FIG. 2 in greater detail, showing a flow chart of the present method; FIGS. 4A-4C generally set forth a process of steps involved in a user's interaction with the hardware encryption device).
Regarding Claim 20, Goroff teaches a non-transitory computer-readable medium configured to store code comprising executable instructions, wherein the instructions, when executed by one or more processors, cause the one or more processors to perform operations (Paragraph 0020 teaches an exemplary system illustrates an exemplary server (acting as a miner computer) with associated database, an optional second computer device, and the local computing device (a smartphone, in this example) are generally known to a person of ordinary skill in the art, and each may include a processor, a bus for communicating information, a main memory coupled to the bus for storing information and instructions to be executed by the processor and for storing temporary variables or other intermediate information during the execution of instructions by processor, a static storage device or other non-transitory computer readable medium for storing static information and instructions for the processor, and a storage device, such as a hard disk, may also be provided and coupled to the bus for storing information and instructions).
Regarding Claims 3 and 13, Goroff teaches all the limitations of claims 1 and 11 above; and Goroff further teaches wherein the pre-determined parameters further include a nonce that is a counter specific to the blockchain address, and a predefined quantity of a blockchain unit (Paragraphs 0043 and 0025 teach a true random number generator in the ARM processor can be used to generate a unique salt for each hardware encryption device that is used in the BIP39 initialization; this would produce a mnemonic phrase that's unique to this hardware encryption device; the system knows the mapping between each hardware encryption device and that unique salt; the user decides to which address to send the funds, which can be entered into the user interface displayed on the smartphone, without the hardware encryption device connected; the application installed on the smartphone receives the user in destination cryptocurrency address and the amount of funds to be sent to that address).
Regarding Claims 7 and 17, Goroff teaches all the limitations of claims 1 and 11 above; and Goroff further teaches wherein at least one of the pre-authorized transaction requests is stored by the computing device in an encrypted form (Paragraph 0050 teaches final confirmation of the transaction is performed using the private key signature of hardware encryption device; once this is accomplished, confirmation of the transaction is sent to the cryptocurrency application on the smartphone or other smart computing device, and the transaction parameters are then communicated on to a blockchain for recordation of the transaction).
Regarding Claim 10, the combination of Goroff teaches all the limitations of claim 1 above; and Goroff further teaches a blockchain node configured to receive a quantity of blockchain unit and broadcast, in response to receiving the quantity, one of the pre-authorized transaction requests to the blockchain without further retrieving the private cryptographic key for signing (Paragraphs 0025 and 0054 teach the application installed on the smartphone, then broadcasts the signed transaction to the network, where the miner computer(s) verify the transaction; the present invention initiates a broadcast of the signed cryptocurrency transaction to a cryptocurrency network for verification by a miner computer, execution of the desired signed transaction, and writing of the transaction to a blockchain).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 4, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Goroff (US 20190325408) in view of Chen (US 20210119807).
Regarding Claims 2 and 12, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein the one or more pre-authorized transaction requests comprises a staking request to stake a predefined quantity of a blockchain unit to the blockchain.
Chen from same or similar field of endeavor teaches wherein the one or more pre-authorized transaction requests comprises a staking request to stake a predefined quantity of a blockchain unit to the blockchain (Paragraphs 0112 and 0157 teach an issuer may create and sign a blockchain transaction to transfer control of an asset in exchange for other assets (e.g., price in Bitcoins) and stores it locally rather than broadcasting to the blockchain; as a result, the pre-generated transaction is held locally and when an exchange is to be made to a counterparty, the pre-generated transaction is provided to the counterparty off-chain and the counterparty contributes other digital assets and signs it, and the resulting transaction—signed by both parties and attesting to a transfer of a token from the issuer and digital assets to the issuer—is broadcasted in its entirety to the blockchain; a coordinator may be required to stake an amount of value of digital assets t which may be used to help resolve disputes in which the coordinator does not act in accordance with a prescribed protocol; the stake cannot be withdrawn by the coordinator unless certain conditions are met—for example, there may be a configurable threshold after the last tether is successfully withdraw that the coordinator's stake is returned, the threshold allowing for clients that utilize coordinator in cross-chain transactions to initiate protocol disputes, such as those discussed in connection with FIGS. 22-24; the time threshold is 30 days, after which withdrawal of the stake may be allowed by the blockchain network).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Chen for the one or more pre-authorized transaction requests to comprise a staking request to stake a predefined quantity of a blockchain unit to the blockchain.
There is motivation to combine Chen into Goroff because the Proof of Stake (PoS) consensus algorithm provides energy efficiency, improved scalability, and faster transaction speeds.
Regarding Claims 4 and 14, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein the one or more pre-authorized transaction requests comprises an unstaking request that requests a quantity of blockchain unit be returned to the blockchain address corresponding to the public cryptographic key.
Chen from same or similar field of endeavor teaches wherein the one or more pre-authorized transaction requests comprises an unstaking request that requests a quantity of blockchain unit be returned to the blockchain address corresponding to the public cryptographic key (Paragraphs 157, 0216, and 0222-0223 teach the stake cannot be withdrawn by the coordinator unless certain conditions are met—for example, there may be a configurable threshold after the last tether is successfully withdraw that the coordinator's stake is returned, the threshold allowing for clients that utilize coordinator in cross-chain transactions to initiate protocol disputes, such as those discussed in connection with FIGS. 22-24; approve withdraw blockchain transaction may include a sender field corresponding to coordinator; the approve withdraw blockchain transaction includes a nonce and may include a blockchain identifier for the blockchain network; approve withdraw blockchain transaction may encode a public key of coordinator corresponding to a private key that is used to digitally sign approve withdraw blockchain transaction; the user may elect to perform a revocation at any point in time, but successful revocation may be subject to conditions: first, a revocation may not be accepted if it is requested prior to the end of the lock time specified in a deposit tether blockchain transaction; and second, the tether must still be available (e.g., it has not been redeemed, which may indicate that the protocol was successfully completed); the current block time is compared against the lock time to determine whether revocation is allowed yet; user may broadcast revoke tether blockchain transaction to reclaim tethered digital assets from a deposit tether blockchain transaction that the user had previously broadcasted; if the tether has not been redeemed (e.g., by user or a counterparty), the user is the same user that deposited the tether, and the lock time has elapsed, then the revoke tether blockchain transaction may be accepted by blockchain; deposit tether blockchain transaction includes a deposit of digital assets x, y, and z which are respectively, the value, commission, and charge; control of digital assets x, y, and z are non-fungible tokens, control of which is subject to a tether that allows user to perform a revocation in which digital assets x and y are returned to user but digital asset z is given to coordinator such that it is no longer subject to a tether (this may be considered a penalty to user to discourage excessive revocations)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Chen for the one or more pre-authorized transaction requests to comprise an unstaking request that requests a quantity of blockchain unit be returned to the blockchain address corresponding to the public cryptographic key.
There is motivation to combine Chen into Goroff because of the same reasons listed above for claim 2.
Claims 5-6, 8, 15-16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Goroff (US 20190325408) in view of Desmarais (US 20240333500).
Regarding Claims 5 and 15, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein the offline storage is part of an offline multi-party computation node.
Desmarais from same or similar field of endeavor teaches wherein the offline storage is part of an offline multi-party computation node (Paragraph 0284 teaches having received the partially signed transaction, the system provider server requests signatures from other authenticating parties according to the multi-signature authentication process (for example, the multi-signature authentication process of method 700); the other authenticating parties include the system provider and may include one or more trusted third parties or service provider(s); the other authenticating parties (system/service provider/third party) provide a signature of the blockchain asset selected; their respective cold storage transfers the signed transaction back to the terminal).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Desmarais for the offline storage to be part of an offline multi-party computation node.
There is motivation to combine Desmarais into Goroff because the system’s security is increased by including a plurality of entities connected by the system to form a trust group. The trust group is a group of vetted participants contributing to the making of a secure blockchain transaction by a user (Desmarais Paragraph 0105).
Regarding Claims 6 and 16, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein at least one of the pre-authorized transaction requests is separated into multiple shards that are stored in multi-party computation nodes.
Desmarais from same or similar field of endeavor teaches wherein at least one of the pre-authorized transaction requests is separated into multiple shards that are stored in multi-party computation nodes (Paragraphs 0081 and 0184 teach the present disclosure provides a method a secure blockchain transaction that may mitigate the risk of loss, theft, destruction of an end-user wallet by distributing shares of the secret of the seed to various parties involved in the multi-signature account without the possibility of one party unilaterally taking over; the system creates a fragmented secret including a number of shares of the secret, S, equal to or greater than the number of involved parties (here, three)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Desmarais for at least one of the pre-authorized transaction requests to be separated into multiple shards that are stored in multi-party computation nodes.
There is motivation to combine Desmarais into Goroff because by creating the fragmented secret, the system provides multiple mechanisms of recovery. For example, in the eventuality that the user loses the digital wallet, the user forgets the master seed, the wall (Desmarais Paragraph 0184).
Regarding Claims 8 and 18, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein the offline storage is disconnected permanently from the Internet.
Desmarais from same or similar field of endeavor teaches wherein the offline storage is disconnected permanently from the Internet (Paragraph 0151 teaches the cold storage device is permanently offline; the wallet data that the user wants to keep protected (e.g. private keys), and does not want transferred over the network, is stored in the memory of the cold storage device).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Desmarais for the offline storage to be disconnected permanently from the Internet.
There is motivation to combine Desmarais into Goroff because the system is configured to ensure that the cold storage device never exposes the sensitive wallet data (e.g. private keys) while the terminal is connected to the network (Desmarais Paragraph 0151).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Goroff (US 20190325408) in view of in further view of Shamai (US 20220051240).
Regarding Claims 9 and 19, Goroff teaches all the limitations of claims 1 and 11 above; however, Goroff does not explicitly teach wherein generating one or more pre-authorized transaction requests comprise: generating two or more alternative versions of transaction requests that correspond to a same nonce.
Shamai from the same or similar field of endeavor teaches wherein generating one or more pre-authorized transaction requests comprise: generating two or more alternative versions of transaction requests that correspond to a same nonce (Paragraphs 0153-0154 and 0173 teach one or more intermediate transactions may be transmitted for transferring cryptocurrency from the 2-2 multisig account to the receiving account to replace previously transmitted intermediate transaction(s) which are not recorded in the blockchain; this may be done by using a current intermediate transaction having the same identification (ID) data as that of a preceding previously transmitted intermediate transaction; the identification data which is similar in the current and in the preceding previous transactions may vary between different cryptocurrencies and may include, for example, same transaction ID, same nonce in account based cryptocurrencies such as, for example, Ethereum, same input(s) ID(s) in transaction based cryptocurrencies such as, for example, Bitcoin and/or the like; the limited access cryptocurrency wallet may therefore generate the plurality of signed transactions to include multiple signed transactions which cannot co-exist, i.e. have the same ID data (e.g., nonce) with gradually increasing partial values of cryptocurrency; as such, one or more of those transactions may be transmitted, as described herein after, as intermediate transactions replacing preceding previously transmitted intermediate transactions having lower cryptocurrency partial values; the predefined granularity may define a plurality of partial values 1 through N which summed together do not exceed the predefined overall value of cryptocurrency initially transferred by the limited access cryptocurrency wallet to the respective provisional account; in order to support flexibility in the value if cryptocurrency partial values transmitted from the respective provisional account to the respective receiving account, the limited access cryptocurrency wallet may generate the plurality of signed transactions to include multiple subsets of signed transactions all comprising the same nonce but each comprising a respective predefined partial value where the nonce defines the order of each signed transaction and the respective partial value defines the value transferred by the respective signed transaction).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Goroff to incorporate the teachings of Shamai for generating one or more pre-authorized transaction requests to comprise: generating two or more alternative versions of transaction requests that correspond to a same nonce.
There is motivation to combine Shamai into Goroff because techniques described herein support nonce management by the wallet service, which removes complexities from the client and reduces transaction errors on blockchain networks. Accordingly, the MPC transaction service may perform nonce management for the generated transaction. Nonce management may include the wallet service using techniques to maintain documentation of pending transactions for an address, such as an address associated with the client (Shamai Paragraph 0052). This functionality may be provided to implement transaction replacement and cancellation. Further, this option may allow the client to self-correct internal state of the service in rare cases the service is out of sync with the blockchain network (Shamai Paragraph 0082).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Silvestre et al. (US 20210383376) teaches multiple microprocessor architecture for cold storage of digital currency. A hardware wallet may include a first microprocessor configured to establish a secure connection with a mobile device connected to a network having access to a blockchain and a second microprocessor configured to generate a private key and a public key for communication of transaction data onto the blockchain. The second microprocessor may initially use a hash function and the private key to encrypt the transaction data and produce a digital signature independent from the first microprocessor and subsequently provide the digital signature and the public key to the first microprocessor for communication onto the blockchain via the secure wireless connection with the mobile device. The second microprocessor may also encrypt and store the private key securely within the wallet's memory such that the private key is readable only by the second microprocessor.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699