Prosecution Insights
Last updated: October 25, 2026
Application No. 18/877,527

Method, System, and Non-Transitory Computer-Readable Recording Medium for Providing Messenger Service

Non-Final OA §102
Filed
Dec 20, 2024
Priority
Jun 29, 2022 — RE 10-2022-0080078 +1 more
Examiner
GILLESPIE, KAMRYN JORDAN
Art Unit
2408
Tech Center
2400 — Computer Networks
Assignee
Hopae Inc.
OA Round
1 (Non-Final)
76%
Grant Probability
Favorable
1-2
OA Rounds
8m
Est. Remaining
93%
With Interview

Examiner Intelligence

Grants 76% — above average
76%
Career Allowance Rate
25 granted / 33 resolved
+17.8% vs TC avg
Strong +17% interview lift
Without
With
+17.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
16 currently pending
Career history
51
Total Applications
across all art units

Statute-Specific Performance

§101
7.1%
-32.9% vs TC avg
§103
53.5%
+13.5% vs TC avg
§102
22.8%
-17.2% vs TC avg
§112
15.0%
-25.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 33 resolved cases

Office Action

§102
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 . Information Disclosure Statement The information disclosure statements (IDS) submitted on 05/02/2025 and 10/03/2025 appear to be in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a message receiving address management unit configured to” and “a message management unit configured to” in claim 7. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claim(s) 1-5, 6, 7-11 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by QUIRK (US 20230421399 A1). QUIRK provides, in regards to [Claim 1] A method (QUIRK [0042] “A method of verifying and generating metadata for blockchain (or wallet) addresses of various blockchains (e.g., via registration module 116, blockchain verification module 146, blockchain system 140, and server system 110 and/or client system 114) according to an embodiment of the present invention is illustrated”) for providing a messenger service, the method comprising the steps of: specifying a message receiving address of a recipient on the basis of an identifier for a first blockchain network associated with the recipient (QUIRK [0043] “the registration module may enable the user to add blockchain (or wallet) addresses of various blockchains to the user profile at operation 310. The user profile may contain or be updated with a blockchain address for a blockchain associated with distributed application (dApp) 148 or blockchain related application 160.”, [0047] “In particular, blockchain verification module 146 receives a request to verify the blockchain (or wallet) address from registration module 116 at operation 320.”); and transmitting, to the message receiving address, a message (QUIRK [0048] “Blockchain verification module 146 sends the message to the blockchain (or wallet) address of the target blockchain for the user to sign.”) that is encrypted on the basis of a public key of the recipient in the first blockchain network and decrypted on the basis of a private key of the recipient in the first blockchain network(QUIRK [0048] “The user logs in or otherwise accesses the wallet of the target blockchain (e.g., via a username and password, wallet verification, etc.) in order to sign the message and verify the user.”, [0049] “The signed message or digital signature is decrypted for verification by blockchain verification module 146 based on a public key corresponding to the wallet (e.g., blockchain (or wallet) address, etc.). Since the private key is unique to the wallet, successful decryption of the message with the corresponding public key verifies the message was signed by the user.” The message is encrypted on the basis of a public key in that it is encrypted in relation to the wallet public key used to decrypt it. The message is decrypted on the basis of a private key of the recipient in that the message is decrypted in relation to the unique private key used to encrypt it.). QUIRK provides, in regards to [Claim 2] The method of Claim 1, wherein the identifier for the first blockchain network is a wallet address of the recipient used in the first blockchain network (QUIRK [0047] In particular, blockchain verification module 146 receives a request to verify the blockchain (or wallet) address from registration module 116 at operation 320.:). QUIRK provides, in regards to [Claim 3] The method of Claim 1, wherein in the specifying step, the message receiving address is specified on the further basis of an identifier for the first blockchain network itself(QUIRK [0047] “In particular, blockchain verification module 146 receives a request to verify the blockchain (or wallet) address from registration module 116 at operation 320. The request may include information for the verification. …The message may include various information in the payload, including the name of the non-fungible token (NFT), a blockchain address for an owner wallet containing the non-fungible token (NFT), a target blockchain type, a target blockchain address, and a salt (e.g., a random nonce for enhanced encryption and recreating a signature).” The address is specified on the basis of the blockchain type, or identifier for the first blockchain network). QUIRK provides, in regards to [Claim 4] The method of Claim 3, wherein the specified message receiving address and the public key of the recipient in the first blockchain network are recorded on a second blockchain network(QUIRK [0023] “Blockchain systems 140 include a blockchain verification module 146 that enables verification of a user for various blockchains.” 0054] “In this case, the application accesses a blockchain 142 associated with the non-fungible token (NFT) (via a blockchain system 140) to obtain a blockchain (or wallet) address corresponding to the non-fungible token (NFT) provided by the user. The associated blockchain may be determined based on the name (e.g., a blockchain corresponding to an extension, etc.), a mapping of non-fungible tokens (NFTs) to blockchains, or a blockchain indication received from the user with the name of the non-fungible token (NFT). A transaction for the non-fungible token (NFT) may be identified on the associated blockchain based on the name of the non-fungible token (NFT), and the blockchain (or wallet) address for the non-fungible token (NFT) may be ascertained from information stored on the associated blockchain for the transaction.”), and the public key of the recipient is acquired on the basis of the recorded message receiving address(QUIRK [0038] “Each user is associated with their own private key (e.g., accessible only to the associated user, etc.) and a public key (e.g., typically an address on the blockchain). The private and public keys enable authentication of the user based on digital signatures in order to commence a transaction. The user account or wallet typically stores the private key.”, [0039] “For example, in order for the user to send cryptocurrency, a message for a transaction is encrypted with the private key of the user wallet. The private key enables only the user to control the user wallet. A digital signature is created by encrypting the message with the private key, where the digital signature is used to verify the user and transaction. The message may be decrypted with the corresponding public key of the user wallet. Since the private key is unique to the user, successful decryption of the message with the corresponding public key verifies the message was sent by the user. Once verified, the transaction may be posted to the blockchain, thereby adjusting the user wallet based on the transaction.” [). QUIRK provides, in regards to [Claim 5] The method of Claim 1, wherein the public key of the recipient is acquired on the basis of a transaction associated with the recipient in the first blockchain network (QUIRK [0038] “Users of transactions for the blockchain are authenticated based on cryptographic keys. These keys identify a user and provide access to a user account or wallet…The private and public keys enable authentication of the user based on digital signatures in order to commence a transaction. The user account or wallet typically stores the private key.”). Claims 6 and 7-11 recite substantially similar limitations and claims 1 and 1-5, respectively, in the forms of a non-transitory computer-readable medium and a system such as demonstrated by QUIRK([0079] QUIRK “The software of the present invention embodiments… may be available on a non-transitory computer useable or readable medium”, [AB] “The system verifies a non-fungible token of a first blockchain is owned by a user.”). Thus, claims 6 and 7-11 are rejected under similar rationale as claims 1 and 1-5, respectively. Conclusion The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure: James; Daniel William Halley US 20220253842 A1 disclose method, system and program product for modifying a supply of stable value digital asset tokens tied to a blockchain. [AB] OH; Jae Hoon US 20220058646 A1 disclose a method for mediating virtual asset transmission. The method comprises receiving a first information on virtual asset to be transmitted from a first user to a second user from a first virtual asset service provider (VASP) server managing virtual asset of the first user, transmitting a verification request as to whether information on the second user included in the received first information is correct to a second VASP server managing virtual asset of the second user, receiving a verification result indicating that the information on the second user is correct from the second VASP server as a response to the verification request, and transmitting the received verification result to the first VASP server. The method further comprises transmitting virtual asset update request of the second user to the second VASP server if it is determined that the transaction has been recorded in the blockchain. [AB] DeLuca; Lisa Seacat US 20230418979 A1 discloses a system for securing user data comprises one or more memories and at least one processor coupled to the one or more memories. The system receives a domain name provided by a user on a user interface in place of user data requested by the user interface to perform an operation. The system retrieves the user data requested by the user interface based on the domain name. The system provides the user data to perform the operation. Embodiments of the present invention further include a method and computer program product for securing user data in substantially the same manner described above. [AB] Jayakumar; Abhilash US 20230060447 A1 discloses methods and systems for authoritatively confirming that a recipient is an intended recipient to receive personal data, and to securely transmit the personal data to the intended recipient, when both the sender and receiver are operating in a trustless ecosystem such as that used with blockchain technology. A computing device may receive an indication of a blockchain address used, by a sender computing device and via a blockchain, to send one or more virtual assets. The computing device may store an association between the blockchain address and the recipient. The computing device may send, to the sender computing device and in response to a query comprising the blockchain address, an indication of the recipient. The indication may be configured to cause the sender computing device to send, to the recipient, personal data associated with an owner of the one or more virtual assets. [AB] Simu; Serban US 20220210061 A1 disclose examples of systems, apparatus, devices, computer program products, and methods implementing aspects of a decentralized content fabric. In some implementations, one or more processors are configured to provide fabric nodes of an overlay network, including one or more fabric nodes that receive a client's request to access digital content on the overlay network. The request includes an authorization token digitally signed by or on behalf of a user of the client. The fabric node(s) extract a user identifier (ID) from the authorization token, then determine that one or more rules maintained on the overlay network are satisfied. The one or more rules condition access to the digital content upon the extracted user ID matching an ID associated with an owner of a digital instrument. The digital instrument, which can be a non-fungible token, is stored in a blockchain ledger as a unique representation of the digital content. [AB] Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kamryn Gillespie whose telephone number is 703-756-5498. The examiner can normally be reached on Monday through Thursday from 9am to 6pm. 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, Linglan Edwards can be reached on (571) 270-5440. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /K.J.G./Examiner, Art Unit 2408 /TECHANE GERGISO/Primary Examiner, Art Unit 2408
Read full office action

Prosecution Timeline

Dec 20, 2024
Application Filed
Aug 18, 2026
Non-Final Rejection mailed — §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12664261
SYSTEMS AND METHODS FOR MONITORING A PLURALITY OF VEHICLES
2y 8m to grant Granted Jun 23, 2026
Patent 12645786
SUBSYSTEM PERMISSION ERROR DIAGNOSTIC AID
2y 9m to grant Granted Jun 02, 2026
Patent 12632548
CYBER THREAT INFORMATION PROCESSING APPARATUS, CYBER THREAT INFORMATION PROCESSING METHOD, AND STORAGE MEDIUM STORING CYBER THREAT INFORMATION PROCESSING PROGRAM
3y 3m to grant Granted May 19, 2026
Patent 12627488
HANDLING OF DATABASE ENCRYPTION KEY REVOCATION
3y 5m to grant Granted May 12, 2026
Patent 12619578
Encoding / Decoding System and Method
3y 7m to grant Granted May 05, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
76%
Grant Probability
93%
With Interview (+17.3%)
2y 7m (~8m remaining)
Median Time to Grant
Low
PTA Risk
Based on 33 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month