DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/01/2026 has been entered.
Status of the Claims
This is a Non-Final Office Action rejection prepared in response to Applicant’s amendments filed on 07/01/2026.
Claims 1-10, 13-18, 21-24 and 28-31 are cancelled.
Claims 11, 19-20, 25, 27, 32-40 and 42-43 are amended.
Claim 44 is new.
Claims 11-12, 19-20, 25-27 and 32-44 are pending.
Claim Objections
Claim 42 is objected to because of the following informalities:
Claim 42 recites the limitation "the specifically created plurality of cryptocurrency wallets ". There is insufficient antecedent basis for this limitation in the claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-12, 19-20, 25-27 and 32-44 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 11-12, 19, 33-35 and 42-43 are directed to an apparatus. Claims 20, 25-26 and 36-38 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Claims 27, 32, 39-41 and 44 are directed to a method (i.e., process). Therefore, these claims fall within the four statutory categories of invention and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 27, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method comprising:
receiving, using an interface circuit, a request for a cryptographic key service from a device associated with a requesting user,
identifying a cryptocurrency wallet associated with the request based on an identifier of the electronic message indicated in the request, wherein the identifier comprises a message identifier or a hash of the electronic message, and wherein identifying the cryptocurrency wallet comprises:
determining whether the cryptocurrency wallet exists for the identifier; and when no cryptocurrency wallet exists for the identifier, creating the cryptocurrency wallet for the electronic message and maintaining the cryptocurrency wallet in a database based on the identifier;
parsing the request for the cryptographic key service to determine a type of cryptographic key service requested and the cryptocurrency wallet associated with the request;
determining a status of the cryptocurrency wallet associated with the request, wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period; and if the status of the cryptocurrency wallet is active, then:
performing the cryptographic key service requested, wherein performing the cryptographic key service requested comprises encrypting the electronic message without the request including an identity of the requesting user; and
causing an electronic ledger associated with the cryptographic key service to be updated.
Claim 27 recites (i.e., sets forth or describes) a method for determining whether a requestor has an active account, and if the requestor does perform a requested service. The claim achieves this by receiving a request for a cryptographic key service; parsing the request to determine the type of cryptographic key service being requested and the wallet; identifying a wallet associated with the request, if no wallet exist create and store a wallet for the request; determine a status of the wallet; performing the cryptographic key service requested if the wallet is active and updating a ledger.
Claim 11 and 20 are significantly similar to claim 27. As such claims 11 and 20 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices and commercial or legal interactions).
Further, in regard to “wherein performing the cryptographic key service requested comprises encrypting the electronic message without the request including an identity of the requesting user” the examiner finds this to further recite an abstract idea of a mathematical concept. Claims 11 and 20 are significantly similar to claim 27. As such claims 11 and 20 also recite an abstract idea.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply
the abstract ideas using a computer, that recite insignificant extra-solution activities, or that generally
link the use of the abstract ideas to a particular technological environment or field of use are not
indicative of a practical application. Here, the additional elements of a processor, a non-transitory computer-readable data storage medium, an interface circuit, a device and a cryptocurrency wallet merely serve as tools to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 12, 19, 25-26 and 32-44 have also been analyzed for subject matter eligibility. The claims recite bolded claim elements as abstract ideas and non-bolded claim elements, if any, as additional elements according to MPEP 2106.04(a). Accordingly, claims 12, 19, 25-26 and 32-44 also fail to recite patent eligible subject matter for the following reasons:
Claim 12 recites:
the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 19 and 26 recite:
the cryptocurrency wallet is identified in a database based on the identifier of the electronic message.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of a cryptocurrency wallet fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 25 and 32 recite:
determining the cryptographic key service requested is encryption of the electronic message
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 33 and 36 recite:
the instructions, when executed, further cause the processor to transfer an as-encrypted electronic message to a recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the processor fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Furthermore, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 34, 37 and 40 recite:
the cryptographic key service requested comprises a request to decrypt the encrypted message, and wherein the instructions, when executed, further cause the processor to transfer an as-decrypted electronic message to the recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the processor fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Furthermore, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 35, 38 and 41 recite:
instructions, when executed, further cause the processor to: if the status of the cryptocurrency wallet is inactive, then send a request to renew authorization for the cryptocurrency wallet to the device.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 39 recites:
performing the cryptographic key service requested comprises transferring an as-encrypted electronic message to a recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 42 recites:
identify the cryptocurrency wallet associated with the request, the instructions further cause the processor to:
create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests; and
manage the specifically created plurality of cryptocurrency wallets to maintain an anonymity of the requesting user during performance of the requested cryptographic key service.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 43 recites:
identify the cryptocurrency wallet associated with the request, the instructions further cause the processor to one of:
encrypt the electronic message without revealing an identity of the requesting user; and
decrypt the electronic message without revealing an identity of the requesting user
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “crypto” and “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 44 recites:
clearing or resetting the cryptocurrency wallet to be inactive outside the designated time period.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of the cryptocurrency wallet fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
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.
Claims 11-12, 19-20, 25-27, and 32-41 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fountain (US 2006/0149962 A1) in view of Langschaedel (US 20150262176 A1), in view of Chou (US 2009/0210708 A1), in further view of Lee (US 20140046788 A1).
Regarding claims 11, 20 and 27, Fountain discloses:
receiving, using an interface circuit, a request for a cryptographic key service from a device associated with a requesting user; (Fountain ¶0019, The application server 14 provides requested services to the clients 12 via the computer network 18. Services requested by the clients 12 may specifically involve cryptographic services, or may precipitate the need for cryptographic services. For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. The cryptographic key server 16 is available to the application server 14 to perform cryptographic services, thus offloading the computational intensities of cryptographic services from the application server 14. Fountain ¶0056, Accordingly, in a step 206 the key server receives a request for cryptographic services via the secure channel. See claim 2.)
parsing the request for the cryptographic key service to determine a type of cryptographic key service requested and (Fountain ¶0056, In receiving the cryptographic service request, the key server will unmarshal the request from encrypted network format. As described above with reference to FIG. 2, in certain embodiments this may be performed by a secure network interface engine. In a step 208, the key server will perform an authorization analysis of the cryptographic service request. The authorization analysis of step 208 determines whether the requested services should be provided to the requesting client. Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
wherein performing the cryptographic key service requested comprises encrypting the electronic message without the request including an identity of the requesting user; (¶0031, The cryptographic functions exposed to the applications 60 would include those most likely desired by the remote clients. These cryptographic functions must be performed either at the application server 52, or more preferably at the cryptographic key server 54 in order to offload from the application server 52 the burden of performing cryptographic services. Thus, it is preferred that the cryptographic service engine 70 be capable of performing any exposed cryptographic services not provided at the application server 52. Typical exposed functionality would include, but is not limited to, functions such as encryption and decryption (e.g. DES, 3DES, AES, RSA, DSA, ECC, etc.), signing and verification (e.g. RSA, DSA, etc.), and hashing and verification (e.g. SHA-1, HMAC, etc.). Generally, encryption and decryption functions include: ¶0032, symmetric block ciphers, ¶0033, generic cipher modes, ¶0034, stream cipher modes, ¶0035, public-key cryptography, ¶0036, padding schemes for public-key systems, ¶0037, key agreement schemes, ¶0038, elliptic curve cryptography, ¶0039, one-way hash functions, ¶0040, message authentication codes, ¶0041, cipher constructions based on hash functions, ¶0042, pseudo random number generators, ¶0043, password based key derivation functions, ¶0044, Shamir's secret sharing scheme and Rabin's information dispersal algorithm (IDA), ¶0045, DEFLATE (RFC 1951) compression/decompression with gzip (RFC 1952) and zlib (RFC 1950) format support, ¶0046, fast multi-precision integer (bignum) and polynomial operations, ¶0047, finite field arithmetic, including GF(p) and GF(2.sup.n), and ¶0048, prime number generation and verification. ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
causing an electronic ledger associated with the cryptographic key service to be updated. (¶0003, SSL and TLS protect data while in transit by encrypting the data using a session-key, (i.e., a cryptographic key), known only to the web server and the client computer. According to these protocols, the data is decrypted upon arrival at the receiving web server. The receiving server processes the data (e.g., validating the credit card number) and then often stores the sensitive data in a server database. ¶0019, For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.) ¶0058, When step 208 determines that the request may not be performed for failure of the authorization step 208, a step 216 performs housekeeping functions related to a failed request for services. In certain embodiments, this includes maintaining a database related to cryptographic requests (time, client identity, service requested, etc.). This database can be used to evaluate whether an attack is being made, or to determine errors in the system.)
Fountain does not disclose, however Langschaedel teaches:
identifying the cryptocurrency wallet comprises: determining whether the cryptocurrency wallet exists for the identifier; and when no cryptocurrency wallet exists for the identifier, creating the cryptocurrency wallet for the electronic message and (Langschaedel ¶0086, The user interface 36 also includes a field for entering an amount in bitcoin (or an amount in local currency that is converted to bitcoin using an exchange rate) that is being transferred from the wallet (Wallet A) corresponding to the first user device 18 to a respective wallet among the wallets 42 corresponding to the second user device 20 that has not yet been established at this point in time. The user of the first user device 18 then uses the hosted email module 46 to send an email at 50 to the second user device 20. The hosted email module 46 simultaneously at 52 instructs the wallet establishment module 40 to establish a wallet corresponding to the email address within the wallets 42. ¶0150, If one or more of the additional email addresses are not associated with any accounts within the first host computer system 14, then the first host computer system 14, at 250, transmits an email to the additional email address that is not associated with an account to create an account. A user receiving the email transmitted at 250 can proceed at 252 to create an account with the second email address associated with the account. ¶0194, At 500, the session responder 498 checks all data for the button ID 460 that has been received in the session call 496. The data associated with the button ID 460 may include a bitcoin address 502, although no bitcoin address may be included within the cookies 472 of the session call 496. At 504, the session responder 498 determines whether a bitcoin address was received in the cookies 472 of the session call 496. If no bitcoin address was received, the first host computer system 14 executes a bitcoin address generator 506. The bitcoin address generator 506 then generates a bitcoin address and, at 508, stores the bitcoin address in association with the button ID 460.)
maintaining the cryptocurrency wallet in a database based on the identifier (Langschaedel ¶0086, The hosted email module 46 simultaneously instructs the wallet management module 44 to record the amount of bitcoin that is being transferred from the wallet (Wallet A) within the wallet corresponding to the email address. ¶0087, A second wallet (Wallet B) is established by the wallet establishment module 40 and the email address (email address B) of the second user device 20 is recorded as an identifier of the wallet (Wallet B).)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to have modified Fountain’s invention with Langschaedel’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide a system for identifying and maintaining wallets corresponding to a particular request based on an identifier (i.e. email) other than the wallet identifier or address while utilizing the cryptographic key service.
The combination of Fountain and Langschaedel do not disclose, however Chou teaches:
wherein the identifier comprises a message identifier or a hash of the electronic message, and wherein (Chou ¶0033, The sender's agent 104 encrypts the email with an encryption key and can assign the email a message ID, which is unique to that message. The encryption key and the message ID are sent to the server via a secured channel (e.g., HTTPS or SSL). The message ID, the sender's email address, the receiver's email address, and the encryption key are stored on the receiver ID server 106. ¶0035, The receiver ID server 106 determines whether the message ID matches its records, where each record can have the following fields: (1) the email address of the sender; (2) the email address of the intended receiver; (3) the message ID for the message; and (4) the decryption key. If there is a matching record, the server will determine whether the receiver 108 is the intended receiver by matching the receiver's 108 address with the intended receiver's address in the record. ¶0039, The sender's agent 204 encrypts the email using an encryption key and generates a unique message ID to identify that message. The encrypted message is sent to the receiver 206. ¶0046, The message ID is then sent to the server 306 so that the server 306 can look up the corresponding message key to decrypt the encrypted email. ¶0049, Note, the message ID is unique to each message. The receiver ID server can generate a message ID for each email. The message ID can also be coupled with the sender's email address and the receiver's email address to form a unique pairing. For instance, if a message ID is "1234", then "1234" can be followed by the sender's address and the receiver's address to form a unique combination. This can be advantageous when there are multiple recipients to whom an email is sent.)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to have modified the combination of Fountain and Langschaedel with Chou’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide a unique identifier for the message/request and utilize this identifier to identify or maintain the wallet rather than using a wallet identifier or address, therefore maintaining the anonymity of the user.
The combination of Fountain, Langschaedel and Chou do not disclose, however Lee teaches:
determining a status of the cryptocurrency wallet associated with the request, wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period; and (Lee ¶0123, The account verification unit 335 can verify status and balance of each electronic wallet account of a user. Lee ¶0124, For example, the account verification unit 335 i) verifies the electronic wallet account corresponding to (linked to) terminal information of the user terminal 110 with a payment request of the user terminal 110, ii) determines if the electronic wallet account is available (for example, if the electronic wallet account is a dormant account or if a balance is enough to make a payment, and so forth.), and iii) notifies the result to the user terminal 110. Lee ¶0165, The payment support server 120 verifies the status of the electronic wallet account corresponding to the virtual account according to the virtual account deposit notification from the financial institution system 140 in Step 715. Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it. Lee ¶0229, For example, the payment support server 120 determines the status and the balance of the user electronic wallet account and further determines if it is possible to process the payment amount according to the payment request. Lee ¶0230, The payment support server 120 also determines the status of the POS electronic wallet account and further determines if it is possible to reflect the deposit.)
if the status of the cryptocurrency wallet is active, then performing the cryptographic key service requested; (Lee ¶0166, If it is not possible to use the electronic wallet account (e.g., insufficient funds in account), the payment support server 120 transmits an information message for unavailable electronic wallet account to the user terminal 110 in Step 720. Lee ¶0168, If the electronic wallet account is available and usable (e.g., sufficient funds in account), the payment support server 120 identifies the limit amount of the electronic wallet account in Step 725. Here, the limit amount is the maximum amount to be deposited to the electronic wallet account. Lee ¶0170, if charging amount is within the limit, the payment support server 120 adds and deposits the charged amount to the balance of the electronic wallet account in Step 735.)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel and Chou with Lee’s teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s validation status.
Further, the claimed limitations “wherein the identifier comprises a message identifier or a hash of the electronic message” and “wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period” only describe characteristics of the identifier and the cryptocurrency wallet which are non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Furthermore, for the method claim, the claim limitation “creating the cryptocurrency wallet for the electronic message and maintaining the cryptocurrency wallet in a database based on the identifier” is a conditional limitation which means that the claim limitation is only required when no cryptocurrency wallet exists for the identifier. similarly, the claim limitation “if the status of the cryptocurrency wallet is active, then performing the cryptographic key service requested;” is also a conditional limitation which means that the claim limitation is only required when the status of the cryptocurrency wallet is active.
Finally, the claimed limitation “to…” in “parsing the request for the cryptographic key service to determine a type of cryptographic key service requested and the cryptocurrency wallet associated with the request;” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 12, the combination of Fountain, Langschaedel, Chou and Lee further disclose:
the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification. (Fountain ¶0030, The cryptographic service engine 70 is operable to provide cryptographic services requested by the application server 52 via the secure network interface engine 72. Cryptographic services may include: 1) hashing operations, and 2) signing and verification operations such as RSA and DSA. Fountain ¶0031, The cryptographic functions exposed to the applications 60 would include those most likely desired by the remote clients. These cryptographic functions must be performed either at the application server 52, or more preferably at the cryptographic key server 54 in order to offload from the application server 52 the burden of performing cryptographic services. Thus, it is preferred that the cryptographic service engine 70 be capable of performing any exposed cryptographic services not provided at the application server 52. Typical exposed functionality would include, but is not limited to, functions such as encryption and decryption (e.g. DES, 3DES, AES, RSA, DSA, ECC, etc.), signing and verification (e.g. RSA, DSA, etc.), and hashing and verification (e.g. SHA-1, HMAC, etc.). Generally, encryption and decryption functions include: [0032] symmetric block ciphers, [0033] generic cipher modes, [0034] stream cipher modes, [0035] public-key cryptography, [0036] padding schemes for public-key systems, [0037] key agreement schemes, [0038] elliptic curve cryptography, [0039] one-way hash functions, [0040] message authentication codes, [0041] cipher constructions based on hash functions, [0042] pseudo random number generators, [0043] password based key derivation functions, [0044] Shamir's secret sharing scheme and Rabin's information dispersal algorithm (IDA), [0045] DEFLATE (RFC 1951) compression/decompression with gzip (RFC 1952) and zlib (RFC 1950) format support, [0046] fast multi-precision integer (bignum) and polynomial operations, [0047] finite field arithmetic, including GF(p) and GF(2.sup.n), and [0048] prime number generation and verification.)
Furthermore, the claimed limitation “the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification” is non-functional material that does not move to distinguish over prior art as it does not affect the recited steps of in claim 11.
Regarding claims 19 and 26, the combination of Fountain, Langschaedel, Chou and Lee further disclose:
the cryptocurrency wallet is identified in a database based on the identifier of the electronic message. (Chou ¶0035, The receiver ID server 106 determines whether the message ID matches its records, where each record can have the following fields: (1) the email address of the sender; (2) the email address of the intended receiver; (3) the message ID for the message; and (4) the decryption key. If there is a matching record, the server will determine whether the receiver 108 is the intended receiver by matching the receiver's 108 address with the intended receiver's address in the record.)
Since Langschaedel teaches using an identifier (i.e. email address) to locate a wallet in the system and Chou teaches searching a database utilizing a message ID, it would have been obvious to one in ordinary skill in the art before the effective filling date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee teaching with Chou’s additional teaching in order to search for the wallet utilizing the specific request/message identifier rather than the actual wallet.
Regarding claims 25 and 32, the combination of Fountain, Langschaedel, Chou and Lee further disclose:
determining the cryptographic key service requested is encryption of the electronic message; and (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
Regarding claims 33, 36 and 39, the combination of Fountain, Langschaedel, Chou and Lee further teach:
transferring an as-encrypted electronic message to a recipient. (Chou ¶0014, Another object of this invention is to provide methods to combine receiver authentication protocols with encryption key services, such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0018, Another advantage of this invention is that methods to combine receiver authentication protocols with encryption key services are provided such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0041, The sender email client 302 first sends a plain email to the sender's agent 304 to encrypt it. The sender's agent 304 encrypts the message and attaches a message ID to the encrypted email, then sends it back to the sender email client 302. The sender's agent 304 sends the message ID and the encryption key used to encrypt the message to the receiver ID server 306. Shortly after encryption of the email, the encrypted email with the message ID embedded in the encrypted email is sent to the receiver email client 310. See claim 1.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee with Chou’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Regarding claims 34, 37 and 40, the combination of Fountain, Langschaedel, Chou and Lee further disclose:
the cryptographic key service requested comprises a request to decrypt the encrypted message, and wherein (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
performing the cryptographic key service requested comprises transferring an as-decrypted message to the recipient. (Chou ¶0034, The receiver 108 receives the encrypted email, but is not able to read it since the body of the email has been encrypted. The receiver 108 sends a request to read the email to the receiver's agent 110. The receiver's agent 110 then fetches a key, also referred to as a decryption key, from the receiver ID server 106 to decrypt the email. The receiver's agent 110 connects to the receiver ID server 106 using a secure channel. The receiver's agent 110 can then email the message ID to the receiver ID server 106. Chou ¶0039, The receiver's agent 208 decrypts the email for the receiver 206 to read and/or modify it.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee with Chou’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Regarding claims 35, 38 and 41, the combination of Fountain, Langschaedel, Chou and Lee further disclose:
the instructions further cause the processor to: if the status of the cryptocurrency wallet is inactive perform the cryptographic key service requested, then send a request to renew authorization for the cryptocurrency wallet the device. (Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it.)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee with Lee’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s threshold balance and send notifications messages to the user if balance is below the threshold to ensure that the user provides the required amount to process the request in a timely manner.
Claims 42-43 are rejected under 35 U.S.C. 103 as being unpatentable over Fountain, Langschaedel, Chou and Lee as applied to claims 11 and 18 above, and further in view of Haulotte (US 10380586 B2).
Regarding claim 42, the combination of Fountain, Langschaedel, Chou and Lee do not disclose, however Haulotte teaches:
create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests; and manage the specifically created plurality of cryptocurrency wallets to maintain an anonymity of the requesting user during performance of the requested cryptographic key service. (col 6 lines 13-26, The purse component 220 is configured to communicate with the interface component 210, and manage one or more purses associated with a cardholder account. Each purse includes or is associated with one or more parameters that allows funds for one or more financial transactions to be strategically managed based on the parameters. The parameters may include, for example, a purse balance (e.g., an amount of funds allocated to the purse), a purse category (e.g., housing, transportation, utilities, groceries, restaurants, health, hobbies, savings), a purse priority, and the like. In some embodiments, the purse priority may be associated with one or more permissions and/or restrictions that control access to at least some funds allocated to the corresponding purse. col 6 lines 66-67 & col 7 lines 1-2, In some embodiments, the attributes are analyzed and/or processed to generate and/or modify one or more purses and/or establish and/or modify one or more purse priorities for one or more purses. col 10 lines 4-18, One or more purses may be generated at 420. In some embodiments, the electronic funds manager 200 generates at least a first purse based on the attributes. For example, the electronic funds manager 200 may identify that a spending history includes transaction data for a housing-related expense (e.g., mortgage payment), a food-related expense (e.g., groceries, restaurants), and a hobbies-related expense (e.g., sports equipment, race registrations), and generate a housing purse, a food purse, and a hobbies purse based on the spending history. Additionally, or alternatively, the electronic funds manager 200 may identify that a spending history for one or more comparable cardholders includes transaction data for a transportation-related expense (e.g., car payment), and generate a transportation purse based on the comparable cardholders' spending history. Col 13 lines 41-60, receive a response to a prompt, and/or retrieve one or more attributes associated with a profile; the purse component 220, when executed by the processor 620, causes the processor 620 to generate a purse, establish one or more parameters associated with a purse, identify one or more parameters associated with a purse, and manage one or more purses; the profile component 230, when executed by the processor 620, causes the processor 620 to analyze one or more attributes associated with a profile, identify a purse associated with a cardholder account, and manage one or more profiles; and the transaction component 240, when executed by the processor 620, causes the processor 620 to compare a purse balance with a transaction amount to determine a difference between the purse balance and the transaction amount, determine whether to approve a request for authorization, determine whether a purse priority satisfies a predetermined threshold, determine whether a difference between a purse balance and a transaction amount satisfies a predetermined threshold, and transfer funds between a plurality of purses.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee with Haulotte’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to dynamically process requests and ensure that the services are performed even if a wallet does not exist for the request service.
Regarding claim 43, the combination of Fountain, Langschaedel, Chou, Lee and Haulotte further disclose:
one of: encrypt the electronic message without revealing an identity of the requesting user; and decrypt the electronic message without revealing an identity of the requesting user. (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
Claim 44 is rejected under 35 U.S.C. 103 as being unpatentable over Fountain, Langschaedel, Chou and Lee as applied to claim 27 above, and further in view of Yau (US 20160005032 A1).
Regarding claim 44, the combination of Fountain, Langschaedel, Chou, Lee and Haulotte do not disclose, however Yau teaches:
clearing or resetting the cryptocurrency wallet to be inactive outside the designated time period. (Yau ¶0024, Credentials may be stored either on the mobile device or, remotely, in the cloud. Cloud storage preferably has the following features: Protected credentials are always stored in the cloud and retrieved from the cloud before use Transparent local caching is possible but not meant as permanent storage—should be wiped after a specified time-out period If device or token is lost, credentials may be removed simply by removing the relevant files from the cloud storage service to avoid potential misuse Credential synchronisation is possible across devices for the same user, obviating the need for manual entry of the same credentials multiple times. ¶0308, If the token is lost, perform once by each associated device: ¶0309, The Hoverkey token not required Wipe authentication key from Hoverkey App Wipe all encrypted passwords Reset Hoverkey app to pre-activated state. ¶0398, … erase the cryptocurrency wallet. ¶0447, The token card device 1102 then transmits the signed payment instruction to the mobile computing device 1106 and discards the wallet 1112.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Fountain, Langschaedel, Chou and Lee with Yau’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to improve the system security by preventing the use of credentials when it is not authorized.
Further, the claimed limitation “to…” in “clearing or resetting the cryptocurrency wallet to be inactive outside the designated time period” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Response to Arguments
Claim Objections
Claim objections in the previous non-final action dated 04/01/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 (a) and (b) in the previous non-final action dated 04/01/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions/arguments regarding the 101 claim rejection in the previous final office action dated 04/01/2026. The basis of these assertions are based on the applicant’s argument on pages 2-4.
First, the applicant asserts that “the claim as a whole integrates the alleged abstract idea into a practical application” because the amended claim addresses the technological problem of how to authorize use of a cryptographic key service for an electronic message without requiring the key server to identify the requesting user or establish a conventional relationship or agreement with the requesting user while still maintaining machine-verifiable payment, wallet status, and ledger state for the requested cryptographic key service. The examiner finds this assertion not persuasive and respectfully disagrees. The alleged problem is not reflected in the claim as an improvement to the operation of the cryptographic key service, database, or any other computer technology. Rather, the claim recites information processing and decision-making steps for managing a cryptographic key service request. The amended claim merely recites receiving a request, identifying a wallet associated with the request, determining if the wallet exist, creating a wallet if the wallet does not exist and storing it in a database, parsing the request to determine the type of cryptographic key service requested, determining the status of the wallet and performing the requested cryptographic key service if the status of the wallet is active and finally updating a ledger. Therefore, the amended claim does not recite any technological improvement.
Second, the applicant asserts that the claimed process is substantially more than a person simply deciding whether an account is active because it must be implemented in a technical sense through the orchestration of an interface circuit, a crypto payment manager, a request receiver, a wallet manager, a key authorizer, a key server, a cryptocurrency system, wallet state data, electronic message identifiers, and electronic ledger updates. The examiner finds this assertion not persuasive and respectfully disagrees. The fact that the claimed steps are performed by computer components does not establish that the claim is not directed to an abstract idea and instead is directed to a technological improvement. Under Step 2A, Prong two the inquiry is whether the additional recited elements integrate the identified abstract idea into a practical application. Here, the recited additional elements are merely used to apply the abstract idea and the applying of the abstract idea does not improve upon the cryptographic key service, interface circuit or any other of the recited additional elements. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fails to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework.
Third, the applicant asserts that “the added additional language to amended claim 27 identifies the inventive concept explicitly by providing the practical implementation of the alleged abstract idea by requiring specific technical relationships between the electronic message identifier, the cryptocurrency wallet, the wallet database and/or wallet status, the cryptographic key service, and the electronic ledger. This is not merely using generic computer components to display or store a result. Rather, amended claim 27 now recites a particular computer-implemented architecture for improving cryptographic key service authorization under conditions in which conventional identity-based or account relationship-based authorization is not used”. The examiner finds this assertion not persuasive and respectfully disagrees. The alleged “specific relationship” required by the claim primarily defines how the information is associated, evaluated, stored and use to make decisions. Further, the assertion that the claims avoid conventional identity-based or account relationship-based authorization does not demonstrate a technological improvement. Using a message identifier to identify a wallet and perform a service merely changes the information being used to process the transaction and not a technological improvement.
Finally, the applicant asserts that “the human mind aided by pen and paper cannot practically implement the claimed operations in a real-world cryptographic key service system” and therefore the claim does not recite a mental process. The examiner finds this assertion not persuasive and respectfully disagrees. As mentioned on the previous office action, while certain steps of the claim cannot be performed by the human mind, the underlining concept of receiving a request, identifying a wallet, making a determination if a wallet exist, creating a wallet, managing the wallet, parsing the request, checking a condition and approving or denying the request based on the condition, and updating a ledger, fall within the “certain methods of organizing human activity” and “mental processes”. Under 101 analysis the focus is not on whether the user can feasibly implement the claim operations, but on whether a claim as a whole is directed towards an abstract idea and whether it recites a technological improvement or solution.
As such the claims remain within an abstract idea and rejection is maintained based on the newly amended claims.
Claim Rejections – 35 U.S.C. § 103
Applicant submits remarks and arguments geared toward the amendments. The examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the newly added claimed expression in the amendments.
Related Prior Art
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160344543 A1 to Alness discloses: A key ceremony application creates bundles for custodians encrypted with their passphrases. Each bundle includes master key share. The master key shares are combined to store an operational master key. The operational master key is used for private key encryption during a checkout process. The operational private key is used for private key decryption for transaction signing in a payment process. The bundles further include TLS keys for authenticated requests to create an API key for a web application to communicate with a service and to unfreeze the system after it has been frozen by an administrator.
US 2017-0032370 A1 to Beltramino et al. discloses: The method involves receiving an indication to conduct a purchase transaction. A secure mobile wallet application is initialized. A selection of a payment account is received from multiple stored payment accounts. A pre-loaded wallet single use key (W-SUK) is retrieved (512). A wallet session key (W-SK) utilizing the W-SUK is derived (514). The transaction data is encrypted (516) using the W-SK. A machine readable code utilizing the encrypted transaction data is generated (518). The machine readable code is displayed (520) for reading by merchant scanner to conduct a purchase transaction.
US 2016/0203477 A1 to Yang et al. discloses: Various embodiments include a wallet service that processes a cryptocurrency deposit into a cryptocurrency wallet account maintained in a wallet service system. The wallet service can receive an authentication parameter to authenticate the cryptocurrency deposit and record a transfer of a cryptocurrency amount from a first cryptocurrency address to a second cryptocurrency address. In response to and substantially immediately after authenticating the authentication parameter, the wallet service can exchange the cryptocurrency amount associated with the cryptocurrency deposit for fiat currency proceeds and deposit the fiat currency proceeds into a fiat reserve account. The wallet service can then associate exchangeable credit equal to the fiat currency proceeds to the cryptocurrency wallet account. In response to receiving a user-initiated request to spend a target portion of the exchangeable credit, the cryptocurrency wallet service can exchange, from the fiat reserve account, for cryptocurrency proceeds equal to the target portion.
US 7,668,093 B1 to Clubb discloses: A framework to transition and re-partition information for event processing and downstream processing can be used in a real time system comprising components such as a consumer server, a file control database, an event manager, an event store, and a configurable output stream. The event manager may be a process which can be enhanced through the use of tags which are inserted to provide information for various downstream systems. The configurable output stream can be defined through an application programming interface which is configured to receive a filter to be applied to the output.
US 8856045 B1 to Patel discloses: Described herein is a mobile-device-to-machine payment system and method for facilitating a cashless transaction for purchase of at least one product or service by a user from a payment accepting unit.
US 2020/0311725 A1 to Savolainen discloses: According to an example aspect of the present invention, there is provided an apparatus comprising memory configured to store a measurement device identifier, and at least one processing core configured to compile a measurement request, the measurement request comprising the measurement device identifier, a public key of the apparatus and cryptographic payment information, to cause transmission of the measurement request, and to decrypt measurement data using a private key of the apparatus.
US 2010/0037050 A1 to Karul discloses: An apparatus and method for exchanging encrypted messages or data. According to an embodiment, messages are encrypted according to credentials associated with a user and the encrypted messages are stored in memory. The credentials are encrypted and stored in a key services module. To retrieve a message, the user logs onto to a server with a password, and the server retrieves the encrypted credentials associated with the user from the key services and applies the user password to decrypt or recover the encrypted credentials. If the credentials are successfully recovered, the server uses the decrypted credentials to decrypt the message and the decrypted message is made available to the user.
US 2015/0019443 A1 to Sheet et al. discloses: Embodiments of the present invention are directed to methods, apparatuses, computer readable media and systems for securely processing remote transactions. One embodiment of the invention is directed to a method of processing a remote transaction initiated by a mobile device comprising a server computer receiving a payment request including encrypted payment information. The encrypted payment information being generated by a mobile payment application of the mobile device and being encrypted using a third party key. The method further comprises decrypting the encrypted payment information using the third party key, determining a transaction processor public key associated with the payment information, and re-encrypting the payment information using the transaction processor public key. The method further comprises sending a payment response including the re-encrypted payment information to a transaction processor. The transaction processor decrypts the re-encrypted payment information using a transaction processor private key and initiates a payment transaction.
CN 101334914 A to Sun discloses: The invention claims a method for prompting balance information of e-wallet, e-wallet storage card and mobile terminal. The method comprises inquiring the balance information of e-wallet according to the balance inquiry request information and comparing the balance information with the pre-set balance threshold value; sending prompt information of insufficient balance to the mobile terminal if said balance information is smaller than said pre-set balance threshold value. The mobile terminal would prompt the user to credit so as to improve the service quality after finishing a credit purchase and the balance information is smaller than said pre-set balance threshold value by comparing the e-wallet balance with the pre-set balance threshold value; the invention only needs to do some modification to the software of the SIM card with low cost and short development period.
US 6934664 B1 to Webb et el. discloses: A system and method for monitoring a security state of a portable electronic device (PED), such as a personal digital assistant (PDA), are provided. A security state may be determined by physical or electronic characteristics of the PED. The relative position of PED pieces, the position of a latch, and/or the status of a software application may determine a security state. Furthermore, a PED may have open, closed, and partially open security states. Information about a current security state of a PED may be transmitted to a point-of-sale device (POS), system processor, and/or financial institution. The PED or any of these other devices may use this information to determine whether to allow or restrict a financial transaction involving the PED. Additionally, a software program on the PED may be allowed or restricted from running depending on the information about the current security state.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (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 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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights