Prosecution Insights
Last updated: July 17, 2026
Application No. 18/438,173

TRANSACTION SYSTEM, TRANSACTION METHOD, AND INFORMATION RECORDING MEDIUM

Final Rejection §103§112
Filed
Feb 09, 2024
Priority
Jun 03, 2014 — JP PCT/JP2014/064757 +3 more
Examiner
STRAUB, D'ARCY WINSTON
Art Unit
2491
Tech Center
2400 — Computer Networks
Assignee
Passlogy Co. Ltd.
OA Round
4 (Final)
77%
Grant Probability
Favorable
5-6
OA Rounds
6m
Est. Remaining
96%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
176 granted / 228 resolved
+19.2% vs TC avg
Strong +19% interview lift
Without
With
+18.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
26 currently pending
Career history
251
Total Applications
across all art units

Statute-Specific Performance

§101
1.9%
-38.1% vs TC avg
§103
91.9%
+51.9% vs TC avg
§102
2.3%
-37.7% vs TC avg
§112
3.1%
-36.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 228 resolved cases

Office Action

§103 §112
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 . Response to Amendments This office action responds to the amendments filed on February 24, 2026 for application 18/438,173. Claims 1-2 and 4-7 are amended, and claims 1-7 remain pending in the application. The Examiner notes, however, that the amendments are not entered because they include a significant amount of new matter (see the most recent § 112(a) rejection below). Frequently, claims are examined in spite of the presence of new matter. See MPEP § 608.04 (stating “While amendments to the specification and claims involving new matter are ordinarily entered, …”). Here, however, the amount of time that would be required to examine these claims for limitations that comprise new matter and ultimately will not be entered cannot be justified. Accordingly, the most recent claim amendments are not entered. Response to Arguments The Examiner has fully considered the Applicant’s arguments filed on February 24, 2026, and the Examiner responds as provided below. Regarding the Applicant’s response at page 8 of the Remarks that concerns the § 112(a) rejection, the arguments are moot because the arguments are directed towards non-entered amendments. Regarding the Applicant’s response at pages 8-12 of the Remarks that concerns the § 103 rejection, the arguments are moot because the arguments are directed towards non-entered amendments. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Independent claims 1, 6, and 7 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Each of the independent claims recite a “second one of the one or more second terminals.” However, the Applicant failed to provide a citation to the disclosure that discloses a “second one of the one or more second terminals” or even the “one or more second terminals” (i.e., a plurality of second terminals). The Examiner reviewed the specification and drawings, which failed to support the claim amendments. Due to the extensive introduction of new matter, the claim amendments are not entered. A significant amount of examination time would be required to examine the claims as amended, and the time commitment cannot be justified for amendments that ultimately will not be entered. Accordingly, the Examiner elects the less frequently taken option of not entering the amendments. See MPEP § 608.04. 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 following conventions apply to the mapping of the prior art to the claims: Italicized text – claim language. Parenthetical plain text – Examiner’s citation and explanation. Citation without an explanation – an explanation has been previously provided for the respective limitation(s). Quotation marks – language quoted from a prior art reference. Underlining – language quoted from a claim. Brackets – material altered from either a prior art reference or a claim, which includes the Examiner’s explanation that relates a claim limitation to the quoted material of a reference. Braces – a limitation taught by another reference, but the limitation is presented with the mapping of the instant reference for context. Numbered superscript – a first phrase to be moved upwards to the primary reference analysis. Lettered superscript – a second phrase to be moved after the movement of the first phrase from which it was lifted, or more succinctly, move numbered material first, lettered material last. A. Claims 1, 3, and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Ozzie et al. (US 2010/0100725, “Ozzie”) in view of Pharris (US 2009/0254479, “Pharris”), and further in view of Chermside (US 10,432,598, “Chermside”). Ozzie discloses A system (Fig. 6, abstract) comprising a first terminal, a second terminal, and a server (Fig. 5, ¶ [0045], “This exemplary embodiment 500 illustrates information flow between elements in example elements of a user authentication, including, a browser page 506 [of a first terminal such as a desktop personal computer] (e.g., a webpage accessed by a user to log onto a secure site); a host server 508 (e.g., a website host server); a user authentication service 510; a user authentication service database 512; and a user's designated mobile device [second terminal] 514.”), both the first terminal and the second terminal being assigned to a same user name (¶ [0039], “For example, when a user registers with the website [via the first terminal], they can register [using a user name] a mobile device [second terminal] for use during authentication [and therefore the two terminals are assigned to the same user name].”), 1 …, the first terminal has a login password input by a user using the first terminal, and sends, to the server, a login request specifying the input login password (¶ [0025], “In the exemplary method 300, at 306, integration code can be provided for utilization by an application programming interface (API) on a host server, for notifying the user authentication service to initiate user authentication. In one embodiment, when a user logs on to the host server [via a sent login request with the input login password], for example, by inputting a username and password, an API on the host server can allow the host server to automatically notify the user authentication service that additional authentication (e.g., a second factor) may be needed.”; and Fig. 6, ¶ [0042], “In this example, a browser page [associated with the first terminal] 602 comprises a first authentication factor 604 in the form of a user log in, using a username and password. When a user 608 initiates authentication by entering [inputting] their username and password into the login box 604, …”), and when the server receives the login request from the first terminal (¶ [0025], “In one embodiment, when a user logs on to the host server [via the received login request], for example, by inputting a username and password, an API on the host server can allow the host server to automatically notify the user authentication service that additional authentication (e.g., a second factor) may be needed.”), {when the connection has already been established and is still alive so that the server can transmit data to the application running on the second terminal via the alive connection after receiving the login request (Pharris ¶ [0057])}, and the login password specified in the login request is correct for the same user name, the server successfully authenticates the user using the first terminal (¶ [0044], “In this embodiment, the website [on the first terminal] may ask a user to log in using a pre-registered username and password, which can be used by a user authentication service to identify authentication information on the user from a database [to successfully authenticate the user].”), and 2 …, and {when the connection has not yet been established (Pharris ¶ [0057])}, or the connection was established but is not alive, or the login password specified in the login request is not correct for the same user name, the server fails to authenticate the user using the first terminal (¶ [0044], i.e., “In this embodiment, the website [on the first terminal] may ask a user to log in using a pre-registered username and password, which can be used by a user authentication service to identify authentication information on the user from a database.” i.e., authentication fails when the log in information such as the user name and password do not match). Ozzie doesn’t disclose 1 wherein when an application is started on the second terminal, the application notifies the server of a notification that: the application is running on the second terminal, and the application is ready to receive data from the server, when the server receives the notification from the application running on the second terminal, the server establishes a connection for data transmission with the application running on the second terminal, 2 the server transmits a notice to the application running in the second terminal via the alive connection, Pharris, however, discloses 1 wherein when an application is started on the second terminal, the application notifies the server of a notification (¶ [0057], “In one embodiment, mobile phone [second terminal] payment application 330 may be used [after starting] to initiate a payment transaction using the mobile phone as the payment device. Once initiated, the mobile phone payment application 330 may communicate [via a notification] with the transaction server 127 to request a payment code (e.g., a barcode and/or a pay code).”; see also Chermside Fig. 3, ¶ [0041], i.e., the step to “Invoke [via an app] service to issue a Customer Key” that serves as a notification) that: the application is running on the second terminal, and the application is ready to receive data from the server (¶ [0057], “In one embodiment, mobile phone payment application 330 may be used to initiate a payment transaction using the mobile phone as the payment device [via the application running on the second terminal]. Once initiated, the mobile phone payment application 330 may communicate with the transaction server 127 to request a payment code (e.g., a barcode and/or a pay code) [with the request demonstrating that the application is ready to receive data from the server].” see also Chermside Fig. 3, ¶ [0041], i.e., the “App/Service 320” receives a “Customer key: YY” because the application is ready to receive data from the server), when the server receives the notification from the application running on the second terminal (¶ [0057]), the server establishes a connection for data transmission with the application running on the second terminal (¶ [0057], “In response, the transaction server 127 may then generate a barcode unique to a given transaction and transmit [via an established connection for data transmission] it to the mobile phone [with the application running on the second terminal] 105.”’ see also Chermside Fig. 3, ¶ [0041], i.e., the server/”Provider API” establishes a connection for data transmission by creating an encrypted communication channel to transmit the “Customer key: YY”), Regarding the rationale to combine Ozzie and Pharris, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction system of Ozzie to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the transaction system of Ozzie, upon which the claimed invention can be seen as an “improvement” through the use of an application feature; 2) the prior art contained a “comparable” system, namely the authentication system of Pharris, that has been improved in the same way as the claimed invention through the application feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the application feature to the base transaction system of Ozzie, and the results would have been predictable to one of ordinary skill in the art. Chermside, however, discloses 2 the server transmits a notice to the application running in the second terminal via the alive connection (Fig. 3, ¶ [0041], “The provider 330 of the API, generally the respective institution, may then create a new customer key at step 332 and send [transmit via the encrypted communication channel as the alive connection] the same [as a notice] to the application [on the second terminal] or service 320 using a processor, server or the like.”), Regarding the rationale to combine Ozzie-Pharris and Chermside, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction system of Ozzie-Pharris to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the transaction system of Ozzie-Pharris, upon which the claimed invention can be seen as an “improvement” through the use of a second terminal-connection feature; 2) the prior art contained a “comparable” system, namely the authentication system of Chermside, that has been improved in the same way as the claimed invention through the second terminal-connection feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the second terminal-connection feature to the base transaction system of Ozzie-Pharris, and the results would have been predictable to one of ordinary skill in the art. Regarding Claim 3 Ozzie in view of Pharris, and further in view of Chermside (“Ozzie-Pharris-Chermside”) discloses the system according to claim 1, and Ozzie further discloses wherein the user inputs, to the first terminal, fixed data as the login password to be specified in the login request (¶ [0042], “In this example, a browser page 602 comprises a first authentication factor 604 in the form of a user log in, using a username and password [as fixed data, i.e., passwords are typically fixed to enable the user to use the password, as a password that is not fixed and changes would frustrate the user because it would prevent the user from consistently logging in with certainty].”). Regarding Independent Claims 6 and 7 With respect to independent claims 6 and 7, a corresponding reasoning as given earlier for independent claim 1 applies, mutatis mutandis, to the subject matter of claims 6 and 7. Therefore, claims 6 and 7 are rejected, for similar reasons, under the grounds set forth for claim 1. B. Claims 2 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Ozzie in view of Pharris and Chermside, and further in view of Skinner et al. (US 2011/0213711, “Skinner”). Regarding Claim 2 Ozzie-Pharris-Chermside discloses the system according to claim 1, and Ozzie further discloses wherein the login request further specifies a user name input to the first terminal (Fig. 6, ¶ [0025], “In the exemplary method 300, at 306, integration code can be provided for utilization by an application programming interface (API) on a host server, for notifying the user authentication service to initiate user authentication. In one embodiment, when a user logs on to the host server, for example, by inputting a username and password,…”), the server regards the user name specified in the login request as the same user name (¶ [0044], i.e., “In this embodiment, the website may ask a user to log in using a pre-registered username and password, which can be used by a user authentication service to identify authentication information [i.e., the user names are the same] on the user from a database.”), and 1 …. Ozzie-Pharris-Chermside doesn’t disclose 1 when the authenticated user inputs transaction information using the first terminal and sends a transaction request regarding the transaction information to the server from the first terminal, the server transmits the notice specifying the transaction information to the application running on the second terminal via the alive connection, the application receives the notice from the server via the alive connection, and the application displays, on the second terminal, the transaction information specified in the notice. Skinner, however, discloses 1 when the authenticated user inputs transaction information using the first terminal and sends a transaction request regarding the transaction information to the server from the first terminal (Fig. 1, ¶ [0021], “The transaction is initiated if the user authenticates properly with the server 104 using known techniques. The secure electronic transaction is then initiated via the web browser [of the first terminal]. In the example of a banking transaction a user may identify an account from which to transfer funds to another account and the dollar amount [by inputting transaction information]. As such, the method includes initiating an electronic transaction by a first unit [terminal] 102 and server 104 using, for example, a first channel such as an internet connection or any other suitable channel via a web browser or other suitable interface by way of example.”), the server transmits the notice specifying the transaction information to the application running on the second terminal via the alive connection (¶ [0022], “As shown in block 202, during the electronic transaction, the second [terminal] unit [and associated application] 106 receives a transaction confirmation request [as a notice] for the transaction and transaction information 136 from [transmitted from] the server 104 via a back channel [alive connection] such as a mobile phone data network or wi-fi internet channel, based on the transaction.”), the application receives the notice from the server via the alive connection (¶ [0022]), and the application displays, on the second terminal, the transaction information specified in the notice (Fig. 4, ¶ [0023], “The server 104 then sends the same transaction information [notice] 136 a to the second unit 106 via a different channel along with a transaction confirmation request 136 b (translated into an “OK” request GUI button) so that a user of the second [terminal] device can confirm that the [displayed] transaction should be carried out.”). Regarding the rationale to combine Ozzie-Pharris-Chermside and Skinner, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction system of Ozzie-Pharris-Chermside to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the transaction system of Ozzie-Pharris-Chermside, upon which the claimed invention can be seen as an “improvement” through the use of a transaction confirmation feature; 2) the prior art contained a “comparable” system, namely the transaction system of Skinner, that has been improved in the same way as the claimed invention through the transaction confirmation feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the transaction confirmation feature to the base transaction system of Ozzie-Pharris-Chermside, and the results would have been predictable to one of ordinary skill in the art. Regarding Claim 5 Ozzie-Pharris-Chermside discloses the system according to claim 1, and Ozzie further discloses wherein the {application (Pharris ¶ [0057])} further displays, on the second terminal,…1 (Fig. 5, ¶ [0045]), 2 …. Ozzie-Pharris-Chermside doesn’t disclose 1 … a cancellation button with the transaction information, 2 when the user operates the cancellation button in the second terminal, the application transmits a cancellation message to the server via the alive connection, and when the server receives the cancellation message from the application via the alive connection, the server cancels the transaction request sent from the first terminal. Skinner, however, discloses 1 … a cancellation button with the transaction information (Fig. 4, ¶ [0024], “Noticing that the second unit displays transaction information which does not accurately reflect the intended transaction terms, the user may for example activate a ‘Cancel’ button to cancel the transaction (labeled in FIG. 4 as “Concern”), or alternatively may simply elect not to proceed with the transaction on unit 1 now that he is aware of the tampered transaction attempt.”), 2 when the user operates the cancellation button in the second terminal, the application transmits a cancellation message to the server via the alive connection (Fig. 4, ¶ [0024], “Noticing that the second [terminal with the established connection] unit displays transaction information which does not accurately reflect the intended transaction terms, the user may for example activate [operate] a ‘Cancel’ button to cancel the transaction [by transmitting a cancellation message] (labeled in FIG. 4 as “Concern”), or alternatively may simply elect not to proceed with the transaction on unit 1 now that he is aware of the tampered transaction attempt.”), and when the server receives the cancellation message from the application via the alive connection, the server cancels the transaction request sent from the first terminal (¶¶ [0029]-[0030], “The method may also include sending a transaction cancellation message to [received by] the server from the second unit in response to a user cancellation of the transaction [that enables the server to cancel the transaction request for the associated transaction] via a cancellation indication entered by the user. The user may select for the transaction to be cancelled using a cancellation button also labeled in FIG. 4 as concern button 150 which will cancel the transaction by the first unit although it is sent by the second unit.”). Regarding the rationale to combine Ozzie-Pharris-Chermside and Skinner, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the transaction system of Ozzie-Pharris-Chermside to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the transaction system of Ozzie-Pharris-Chermside, upon which the claimed invention can be seen as an “improvement” through the use of a transaction cancellation feature; 2) the prior art contained a “comparable” system, namely the transaction system of Skinner, that has been improved in the same way as the claimed invention through the transaction cancellation feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the transaction cancellation feature to the base transaction system of Ozzie-Pharris-Chermside, and the results would have been predictable to one of ordinary skill in the art. C. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Ozzie in view of Pharris and Chermside, and further in view of Sipman et al. (US 6,889,325, “Sipman”) and Chenna (US 2014/0351589, “Chenna”). Regarding Claim 4 Ozzie-Pharris-Chermside discloses the system according to claim 1, and Ozzie further discloses wherein when the server is accessed from the {application (Pharris ¶ [0057])} running on the second terminal (Fig. 5, ¶ [0045]), the {server transmits…1 to the application running on the second terminal via the alive connection (Pharris ¶ [0057])}, 2 …. Ozzie-Pharris-Chermside doesn’t disclose 1 …a random table… 2 the user inputs, to the first terminal, an extracted content of cells from the transmitted random table based on an extraction rule assigned to the user as a login password to be specified in the login request, and the server authenticates the user with the login password specified in the login request. Sipman, however, discloses 1 …{the server transmits} a random table… (Fig. 6, Col. 8:25-41, “Assume a table 46 of random numbers.”) 2 the user inputs, to the first terminal, an extracted content of cells from the transmitted random table based on an extraction rule assigned to the user as a login password to be specified in the login request,…a (Fig. 6, Col. 8:25-41, i.e., illustrated in Fig. 6, “In the example the digital signature becomes the string: 128, 27, 5, 99, 38 [as extracted content of cells from the transmitted random table based on an extraction rule].”, i.e., the numbers 128, 27, 5, 99, and 38, which are extracted based upon their position in the random table, serve as a login password for the login request), Regarding the rationale to combine Ozzie-Pharris-Chermside and Sipman, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the authentication system of Ozzie-Pharris-Chermside to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the authentication system of Ozzie-Pharris-Chermside, upon which the claimed invention can be seen as an “improvement” through the use of a random table authentication feature; 2) the prior art contained a “comparable” system, namely the authentication system of Sipman, that has been improved in the same way as the claimed invention through the random table authentication feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the random table authentication feature to the base authentication system of Ozzie-Pharris-Chermside, and the results would have been predictable to one of ordinary skill in the art. Chenna, however, discloses a …, and the server authenticates the user with the login password specified in the login request. Regarding the rationale to combine Ozzie-Pharris-Chermside-Sipman and Chenna, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the authentication system of Ozzie-Pharris-Chermside-Sipman to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C). To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C): 1) the prior art contained a base system, namely the authentication system of Ozzie-Pharris-Chermside-Sipman, upon which the claimed invention can be seen as an “improvement” through the use of a login authentication feature; 2) the prior art contained a “comparable” system, namely the authentication system of Sipman, that has been improved in the same way as the claimed invention through the login authentication feature; and 3) one of ordinary skill in the art could have applied the known improvement technique of applying the login authentication feature to the base authentication system of Ozzie-Pharris-Chermside-Sipman, and the results would have been predictable to one of ordinary skill in the art. Conclusion THIS ACTION IS MADE FINAL. 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 D'ARCY WINSTON STRAUB whose telephone number is (303)297-4405. The examiner can normally be reached Monday-Friday 9:00-5:00 Mountain Time. 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, WILLIAM KORZUCH can be reached at (571)272-7589. 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. /D'Arcy Winston Straub/Primary Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

Show 1 earlier event
Jan 02, 2025
Non-Final Rejection mailed — §103, §112
Jun 02, 2025
Response Filed
Jul 16, 2025
Final Rejection mailed — §103, §112
Sep 12, 2025
Request for Continued Examination
Oct 02, 2025
Response after Non-Final Action
Nov 26, 2025
Non-Final Rejection mailed — §103, §112
Feb 24, 2026
Response Filed
May 11, 2026
Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12683790
A PROTOCOL FOR TRUSTWORTHY, PRIVACY PRESERVING GENOMIC DATABASE DISCOVERY
3y 11m to grant Granted Jul 14, 2026
Patent 12682107
SYSTEM AND METHOD FOR PROCESSING INSTRUCTIONS ASSOCIATED WITH ONE OR MORE DATA TRANSFERS
2y 4m to grant Granted Jul 14, 2026
Patent 12659734
METHOD, APPARATUS, AND SYSTEM FOR VEHICLE-TO-VEHICLE COMMUNICATIONS
3y 9m to grant Granted Jun 16, 2026
Patent 12619772
SENSITIVE INFORMATION DISCLOSURE PREDICTION SYSTEM FOR SOCIAL MEDIA USERS AND METHOD THEREOF
2y 8m to grant Granted May 05, 2026
Patent 12619755
ARTIFICIAL DATA GENERATION FOR DIFFERENTIAL PRIVACY
2y 6m 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

5-6
Expected OA Rounds
77%
Grant Probability
96%
With Interview (+18.7%)
2y 11m (~6m remaining)
Median Time to Grant
High
PTA Risk
Based on 228 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