DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 21 in application 17/699,306.
Claims 1-8, 12, and 17-20 are canceled.
Claim 9 is amended.
Claims 9-11, 13-16 and 21 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding 35 U.S.C. § 103:
Applicant's arguments filed 1/16/2026 with respect to claim(s) 9-11, 13-16 and 21 have been considered but are not persuasive because the rejection does not rely on a single isolated disclosure for each entire feature. Applicant’s arguments are based on the amended claims and therefore new prior art is applied to the amended claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 9-11, 13-16, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Prakash et al. (US20180330342A1) hereinafter Prakash, in view of Chen (US20170169405A1), and in further view of Durvasula et al. (US20210042758A1) hereinafter Durvasula in further view of Middleton (US20170187535A1) and in further view of Eller (US20200167791A1).
Regarding Claim 9. Prakash teaches (in BOLD): A computer executable method for tracing transfers of electronic currency, the method comprising extracting computer readable instructions stored on a non-transitory medium and executing the computer readable instructions on a processor, wherein execution of the computer readable instructions by the processor:
Prakash - A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation (¶ 0041).
receives a request from a source digital wallet to transfer the electronic currency to a destination digital wallet
Prakash - Systems and methods related to cryptocurrency system that enables transactions to be performed using digital assets corresponding to an amount of fiat currency. The cryptocurrency system includes a digital asset service provider computer that can host a digital asset account on behalf of an intended recipient of a transfer (e.g., an unbanked user). In some embodiments, a transfer recipient may elect to receive the transfer in the form of a digital asset. The digital asset service provider computer may facilitate a fund transfer by a financial institution to hold currency with which the digital asset is backed. The digital asset may be generated and managed by the digital asset service provider computer as a blockchain ledger of transactions that cryptographically secures data that is stores. In some embodiments, a payment method identifier may be generated for the digital asset and utilized by the transfer recipient to perform subsequent transactions (Abstract). In some embodiments, a settlement process may be performed for the transfer request in real-time. In this case, an amount associated with the digital asset may be available for use by the second user in real-time. The method may further comprise generating, by the server computer, a payment method identifier associated with the digital asset account of the second user. The method may further comprise receiving, by the server computer, an authorization request comprising the payment method identifier and a resource provider identifier. In some embodiments, the method may further comprise facilitating, by the server computer, an asset transfer between the digital asset account of the second user and a financial account associated with the resource provider identifier (¶ 0005-0006). In some embodiments, the functionality discussed herein may be embedded in an online banking application, a digital wallet application for managing digital assets, or any suitable type of application hosted by the digital asset service provider computer (or another computing device of the cryptocurrency system) (¶ 0042).
that is incompatible with the source digital wallet;
Prakash - As a non-limiting example, the extracted authentication information may be compared to banking account information maintained by the financial institution computer in order to perform know-your-customer authentication techniques. If the extracted authentication information matches stored information, the corresponding party may be considered authenticated and the transaction request may proceed. If the extracted authentication information does not match stored information, the transaction request may be terminated and a transaction response transmitted indicating that the request was unsuccessful (¶ 0093).
based on a value of the electronic currency and the destination digital wallet, determines a number of sub-amounts for the electronic currency, wherein a value of the sub-amounts is assigned for the transfer by an operator of the source digital wallet;
Prakash - In some embodiments, transmitting the transaction request message to the financial institution computer causes the financial institution computer to create a holding account on behalf of the second user and transfer the transfer amount from an electronic account of the first user to the holding account (¶ 0008). “Digital currency” may refer to units of value that may be used as a form of payment for transactions, including financial transactions. Digital currency may be currency that is electronically generated by and stored at a user computing device. Digital currency may be purchased using conventional forms of currency (e.g., fiat currency) and generated with a specific value. Typically, the digital currency may not have a physical form of tender but may be accessible through a user computing device (e.g., mobile device) using a software application such as a digital wallet or mobile application. A type of digital currency may be cryptocurrency, which utilizes cryptographic methods for verification (¶ 0021). A “ledger of transactions” may refer to a compilation of data from previous transactions. The ledger of transactions may be a database or other comparable file structure that may be configured to store data from all previous transactions performed using a digital currency, including the date and time of the transaction, the transaction amount, and identification information for the participants of the transaction (e.g., the sender and the receiver of the transaction amount). In some embodiments, the ledger of transactions may be in the form of an electronic ledger (e.g., a blockchain) in which data already stored in the electronic ledger is unalterable, or at least, tamper resistant. In some embodiments, a cryptocurrency system may operate multiple computing devices (e.g., computing nodes) that individually store a copy of the ledger of transactions. In some embodiments, only some computing devices of the cryptocurrency system may store a copy of the ledger of transactions (¶ 0026).
embeds a cryptographic public key in each sub-amount;
Prakash - A digital signature may be a unique value generated from a message and a private key using an encrypting algorithm. In some embodiments, a verification algorithm using a public key may be used to verify the signature. The digital signature may be a numeric value, an alphanumeric value, or any other type of data including a graphical representation (¶ 0028). A “key” may refer to a piece of data or information used for an algorithm. A key may be a unique piece of data and is typically part of a key pair where a first key may be used to encrypt a message, while a second key may be used to decrypt the encrypted message. The key may be a numeric or alphanumeric value and may be generated using an algorithm. A management system server computer in a cryptocurrency payment network may generate and assign a unique key pair for each node in the cryptocurrency payment network (¶ 0029).
Prakash does not teach; however, Chen teaches (in BOLD):
based on a value of the electronic currency and the destination digital wallet, determines a number of sub-amounts for the electronic currency, wherein a value of the sub-amounts is assigned for the transfer by an operator of the source digital wallet;
Chen - the electronic money in the user account is divided into one or more monetary units (¶ 0013). More preferably, the method further comprises: determining the unit division rule based on account output history record information corresponding to the user account. For example, the currency unit frequently used in the user account is determined based on a payment or transfer record of the user account, and the currency unit is determined as the monetary unit based on which the electronic money will be divided, so as to determine the unit division rule. Here, the account output history record information includes, but is not limited to, records such as payment and transfer of the corresponding user account (¶ 0036).
divides the electronic currency into the number of sub-amounts;
Chen - the electronic money in the user account is divided into one or more monetary units (¶ 0013).
embeds a cryptographic public key in each sub-amount; and
Chen - Chen - the electronic money in the user account is divided into one or more monetary units (¶ 0013).
initiates an automated quarantine routine that prevents each sub-amount from being transferred without authorization from a cryptographic private key paired to the cryptographic public key;
Chen - It should be understood by those skilled in the art that the above-described manner of dividing electronic money in a user account into one or more monetary units is by way of example only, other existing or future manners of dividing electronic money in a user account into one or more monetary units are included within the scope of the present application if they are applicable to this application, and are incorporated herein by reference. In Step S12, the encoding processing refers to encoding for the monetary units. The encoded data will contain identity information of the sender, and the encoding can be implemented through, e.g., digital signature, thereby ensuring the integrity of information transmission and the identity of the sender, and preventing the occurrence of denial in the transaction. The unit identifiers may be used to identify the monetary units after encoding processing, and may be represented in the form of numbers, characters or combinations thereof. It should be understood by those skilled in the art that the above-described encoding manners and unit identifiers are by way of example only, other existing or future encoding manners and unit identifiers are included within the scope of the present application if they are applicable to this application, and are incorporated herein by reference. With “encoding” for electronic money, payment and circulation of electronic money can be controlled, which can effectively curb the criminal acts, e.g., theft, on the electronic accounts and improve the security of the electronic accounts (¶ 0027).
prevents each of the number of sub-amounts from being further subdivided; and
Chen - dividing electronic money in a user account into one or more monetary units (Abstract). the monetary unit refers to a money amount of the electronic money which is inseparable in payment and circulation (¶ 0024). : determining an output unit combination including one or more of the monetary units (¶ 0058). outputting the output unit combination and updating the account status information (¶ 0059).
Therefore, it would have been obvious before the effective filing date of the claimed invention to modify the cryptocurrency system of Prakash with the dividing of electronic money Chen because doing so allows a flexible handling of digital currency for precise value transfers and efficient management of funds which addresses micro-transaction inefficiency.
The combination of Prakash and Chen does not teach, however, Durvasula teaches (in BOLD):
in response to detecting a fraud alert associated with the electronic currency,
Durvasula - Risk assessment system 108 may assess the likelihood of fraud for a transaction request and provide the assessment to the digital currency smart contract 112 of blockchain 110. Blockchain 110 may be configured to apply changes in response to an acceptable likelihood of fraud and roll the changes back in response to an unacceptable likelihood of fraud (¶ 0038).
initiates an automated quarantine routine that prevents each sub-amount from being transferred without authorization from a cryptographic private key paired to the cryptographic public key; and
Durvasula - the system may also include isolating and removing malicious code from electronic messages (e.g., email) to prevent a computer from being compromised, for example by being infected with a computer virus. The system may scan electronic communications for malicious computer code and clean the electronic communication before it may initiate malicious acts. The system operates by physically isolating a received electronic communication in a “quarantine” sector of the computer memory. A quarantine sector is a memory sector created by the computer's operating system such that files stored in that sector are not permitted to act on files outside that sector. When a communication containing malicious code is stored in the quarantine sector, the data contained within the communication is compared to malicious code-indicative patterns stored within a signature database. The presence of a particular malicious code-indicative pattern indicates the nature of the malicious code. The signature database further includes code markers that represent the beginning and end points of the malicious code. The malicious code is then extracted from malicious code-containing communication. An extraction routine is run by a file parsing component of the processing unit. The file parsing routine performs the following operations: scan the communication for the identified beginning malicious code marker; flag each scanned byte between the beginning marker and the successive end malicious code marker; continue scanning until no further beginning malicious code marker is found; and create a new data file by sequentially copying all non-flagged data bytes into the new file, which thus forms a sanitized communication file. The new, sanitized communication is transferred to a non-quarantine sector of the computer memory. Subsequently, all data on the quarantine sector is erased. More particularly, the system includes a method for protecting a computer from an electronic communication containing malicious code by receiving an electronic communication containing malicious code in a computer with a memory having a boot sector, a quarantine sector and a non-quarantine sector; storing the communication in the quarantine sector of the memory of the computer, wherein the quarantine sector is isolated from the boot and the non-quarantine sector in the computer memory, where code in the quarantine sector is prevented from performing write actions on other memory sectors; extracting, via file parsing, the malicious code from the electronic communication to create a sanitized electronic communication, wherein the extracting comprises scanning the communication for an identified beginning malicious code marker, flagging each scanned byte between the beginning marker and a successive end malicious code marker, continuing scanning until no further beginning malicious code marker is found, and creating a new data file by sequentially copying all non-flagged data bytes into a new file that forms a sanitized communication file; transferring the sanitized electronic communication to the non-quarantine sector of the memory; and deleting all data remaining in the quarantine sector (¶ 0064).
Therefore, it would have been obvious before the effective filing date of the claimed invention to modify the cryptocurrency system of Prakash and the dividing of electronic money Chen with the fraud assessment of Durvasula of because doing so allows a flexible handling of digital currency for precise value transfers and efficient management of funds which addresses micro-transaction inefficiency and enhances payment granularity and improving privacy and efficiency for small value transfers.
The combination of Prakash, Chen, and Durvasula does not teach however Middleton teaches (in BOLD):
allows each of the sub-amounts to be subdivided a threshold amount of time after being transferred out of the source digital wallet; and
Note – Middleton is not being used to create a different “sub-amount.” Instead, it teaches how the apportioned value portions from Chen may be implemented as controlled transaction outputs. The lock time/expiration structure teaches a threshold-time gate: before the threshold, action on the output is restricted; after the threshold, the value can be acted on through separate outputs/amounts.
Middleton - a lock time after the expiration timestamp…a first refund output comprising a first refund amount and a first condition requiring approval of the first party; and a second refund output comprising a second refund amount and a condition requiring approval of a second party (¶ 0102).
Therefore, it would have been obvious before the effective filing date of the claimed invention to modify the cryptocurrency system of Prakash and the dividing of electronic money Chen and the fraud assessment of Durvasula with the lock time and refund outputs of Middleton because doing so allows the same traced sub-amounts of electronic currency to be temporarily restricted during a fraud risk window and then either released for further subdivision after the threshold time.
The combination of Prakash, Chen, Durvasula, and Middleton does not teach, however Eller teaches (in BOLD):
in response to the destination digital wallet being associated with multiple fraud alerts, and detecting a transfer to the target destination digital wallet: automatically triggers a transfer of at least one of the sub-amounts back to the source digital wallet.
Note – Eller supplies the condition/trigger: a wallet or withdrawal request is risky based on suspicious activity, corresponding to a destination wallet associated with fraud alerts. Middleton supplies the thing being triggered: a refund/return output transaction. Thus, it would have been obvious to use Eller’s fraud-risk condition as the predefined condition that causes Middleton’s refund output mechanism to execute, thereby transferring at least one controlled portion/sub-amount back rather than allowing it to continue to a risky destination.
Eller - automatically flag risky withdrawal requests in real-time for further review before committing them to the blockchain. In some embodiments, the exchange can quarantine wallets at a certain Walletscore (¶ 0011).
Therefore, it would have been obvious before the effective filing date of the claimed invention to modify the cryptocurrency system of Prakash and the dividing of electronic money Chen and the fraud assessment of Durvasula and the lock time and refund outputs of Middleton with the indivisible token controls of Eller because doing so improves fraud containment, transfer authorization, traceability, and policy enforcement for wallet-managed electronic currency on a distributed ledger.
Regarding Claim 10. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 9 above. The combination further teaches: the method of claim 9 wherein execution of the computer readable instructions by the processor freezes transfer activity of any account that contains any one of the number of sub-amounts.
Prakash - In some embodiments, the date field 306 may be presented within the user interface 300. The date field 306 may be situated as depicted in FIG. 3, or the date field 306 may be provided elsewhere in the user interface 300. In at least one embodiment, the date field 306 may be user-editable and/or the date field may be automatically populated by the service provider computer 112 with a date corresponding to the current date. The service provider computer 112 may validate the date field 306 to ensure that the date provided conforms to standard date formats and acceptable field ranges (¶ 0074). In some embodiments, the payee field 310 may be presented within the user interface 300. The payee field 310 may be situated as depicted in FIG. 3, or the payee field 310 may be provided elsewhere in the user interface 300. In at least one embodiment, the payee field 310 may be user-editable. For example, the user may select an area relatively near the line corresponding to the payee field 310 to enter a payee identifier (e.g., a payee name). In some examples, selection of the area near the line may present the user with an option to search and select a user from a known set of users. If the payee cannot be found in the set of known users, the user may be provided the ability to enter in additional identification information (e.g., a phone number and/or email address of the payee). Upon selecting a payee or entering a payee identifier, the payee may be indicated within the payee field 310 (¶ 0075). In some embodiments, the amount field 308 may be presented within the user interface 300. The amount field 308 may be situated as depicted in FIG. 3, or the amount field 308 may be provided elsewhere in the user interface 300. In at least one embodiment, the amount field 308 may be editable by the user. By way of example, the user may select an area corresponding to the amount field 308 to input a currency amount. The service provider computer 112 may validate the amount field 308 to ensure that the currency amount provided conforms to standard currency formats. In some examples, the user may be provided the ability to select a currency type (e.g., U.S. Dollar, Yen, Lira, etc.). The currency amount inputted may be displayed within the amount field 308 and the currency type may be indicated within the user interface 300 (¶ 0076). If the received message is determined to be invalid, an optional notification may be provided the message initiator and further processing may be restricted or abandoned (¶ 0086).
Regarding Claim 11. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 9 above. The combination further teaches: the method of claim 9 wherein execution of the computer readable instructions by the processor embeds a smart contract into each of the number of sub-amounts, wherein the smart contract activates the automated quarantine routine in response to detecting the fraud alert in a target location on a distributed ledger within predetermined time after receiving the request.
Prakash - In some embodiments, the date field 306 may be presented within the user interface 300. The date field 306 may be situated as depicted in FIG. 3, or the date field 306 may be provided elsewhere in the user interface 300. In at least one embodiment, the date field 306 may be user-editable and/or the date field may be automatically populated by the service provider computer 112 with a date corresponding to the current date. The service provider computer 112 may validate the date field 306 to ensure that the date provided conforms to standard date formats and acceptable field ranges (¶ 0074). In some embodiments, the payee field 310 may be presented within the user interface 300. The payee field 310 may be situated as depicted in FIG. 3, or the payee field 310 may be provided elsewhere in the user interface 300. In at least one embodiment, the payee field 310 may be user-editable. For example, the user may select an area relatively near the line corresponding to the payee field 310 to enter a payee identifier (e.g., a payee name). In some examples, selection of the area near the line may present the user with an option to search and select a user from a known set of users. If the payee cannot be found in the set of known users, the user may be provided the ability to enter in additional identification information (e.g., a phone number and/or email address of the payee). Upon selecting a payee or entering a payee identifier, the payee may be indicated within the payee field 310 (¶ 0075). In some embodiments, the amount field 308 may be presented within the user interface 300. The amount field 308 may be situated as depicted in FIG. 3, or the amount field 308 may be provided elsewhere in the user interface 300. In at least one embodiment, the amount field 308 may be editable by the user. By way of example, the user may select an area corresponding to the amount field 308 to input a currency amount. The service provider computer 112 may validate the amount field 308 to ensure that the currency amount provided conforms to standard currency formats. In some examples, the user may be provided the ability to select a currency type (e.g., U.S. Dollar, Yen, Lira, etc.). The currency amount inputted may be displayed within the amount field 308 and the currency type may be indicated within the user interface 300 (¶ 0076).
Regarding Claim 13. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 11 above. The combination further teaches: the method of claim 12 wherein in response to detecting the fraud alert after the predetermined time, the smart contract stores a current location of each of the number of sub-amounts in a secure location on the distributed ledger.
Prakash - An authorization request may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction (¶ 0038).
Regarding Claim 14. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 9 above. The combination further teaches: the method of claim 12 wherein each sub-amount is determined based on a value of the electronic currency.
Prakash - In some embodiments, transmitting the transaction request message to the financial institution computer causes the financial institution computer to create a holding account on behalf of the second user and transfer the transfer amount from an electronic account of the first user to the holding account (¶ 0008). “Digital currency” may refer to units of value that may be used as a form of payment for transactions, including financial transactions. Digital currency may be currency that is electronically generated by and stored at a user computing device. Digital currency may be purchased using conventional forms of currency (e.g., fiat currency) and generated with a specific value. Typically, the digital currency may not have a physical form of tender but may be accessible through a user computing device (e.g., mobile device) using a software application such as a digital wallet or mobile application. A type of digital currency may be cryptocurrency, which utilizes cryptographic methods for verification (¶ 0021). A “ledger of transactions” may refer to a compilation of data from previous transactions. The ledger of transactions may be a database or other comparable file structure that may be configured to store data from all previous transactions performed using a digital currency, including the date and time of the transaction, the transaction amount, and identification information for the participants of the transaction (e.g., the sender and the receiver of the transaction amount). In some embodiments, the ledger of transactions may be in the form of an electronic ledger (e.g., a blockchain) in which data already stored in the electronic ledger is unalterable, or at least, tamper resistant. In some embodiments, a cryptocurrency system may operate multiple computing devices (e.g., computing nodes) that individually store a copy of the ledger of transactions. In some embodiments, only some computing devices of the cryptocurrency system may store a copy of the ledger of transactions (¶ 0026).
Regarding Claim 15. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 11 above. The combination further teaches: the method of claim 11 wherein the smart contract in response to detecting the fraud alert, initiates an automated return of the electronic currency to the source digital wallet.
Prakash - An authorization request may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction (¶ 0038).
Regarding Claim 16. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 11 above. The combination further teaches: the method of claim 11 wherein the smart contract in response to detecting the fraud alert, initiates a homing beacon that broadcasts a current location of each of the number of sub-amounts.
Prakash - An authorization request may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction (¶ 0038).
Regarding Claim 21. The combination of Parkash, Chen, Durvasula, Middleton, and Eller teaches all of the limitations of claim 9 above. The combination further teaches: the method of claim 9 wherein each sub-amount is determined based on one or more transaction attributes included in the request.
Prakash - In some embodiments, the transfer request may include a digital image. By way of example, the transfer request may include a digital image of a personal and/or business check. The digital image may conform to attributes (e.g., color, style, font, etc.) specified by the user 604 when initiating the transfer request via the user interface 300. The transferee, user 608, may elect to print or otherwise utilize the digital image to conduct a banking deposit into his bank account. If the user 608 elects to utilize the digital image, the flow may conclude. Alternatively, the user 608 may be provided with an option to elect that the transfer amount be provided to the user 608 as a digital asset (¶ 0115).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Shanmugam (US20190213584) - A method for tokenized cross-currency transacting includes: receiving a transaction request, the request including a source address, destination address, source currency, destination currency, and currency amount; generating an intermediate address associated with a transaction account issued in the source or destination currency; processing a first payment transaction for payment of the currency amount from a transaction account associated with the source address to the transaction account associated with the intermediate address; processing a second payment transaction for payment of the currency amount from the transaction account associated with the intermediate address to a transaction account associated with the destination address; storing a transaction record including at least the intermediate address, source currency, destination currency, the currency amount; and transmitting a notification in response to the received transaction request indicating completion of the second payment transaction.
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 CHRISTINA C STEVENSON whose telephone number is (571)270-7280 and whose email is christina.mention@uspto.gov. The examiner can normally be reached on Monday - Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee, can be reached at telephone number 571-272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights