Prosecution Insights
Last updated: July 17, 2026
Application No. 19/070,103

CENTRALIZED CLIENT INTERFACE FOR FACILITATING CREDENTIAL-LESS NETWORK-BASED COMMUNICATION EXCHANGES BETWEEN PARTICIPATING MEMBER PLATFORMS

Non-Final OA §103
Filed
Mar 04, 2025
Priority
Aug 03, 2022 — provisional 63/370,280 +4 more
Examiner
POPHAM, JEFFREY D
Art Unit
2432
Tech Center
2400 — Computer Networks
Assignee
1080 Network Inc.
OA Round
3 (Non-Final)
38%
Grant Probability
At Risk
3-4
OA Rounds
3y 3m
Est. Remaining
62%
With Interview

Examiner Intelligence

Grants only 38% of cases
38%
Career Allowance Rate
177 granted / 471 resolved
-20.4% vs TC avg
Strong +24% interview lift
Without
With
+24.2%
Interview Lift
resolved cases with interview
Typical timeline
4y 7m
Avg Prosecution
26 currently pending
Career history
504
Total Applications
across all art units

Statute-Specific Performance

§101
0.9%
-39.1% vs TC avg
§103
91.9%
+51.9% vs TC avg
§102
5.5%
-34.5% vs TC avg
§112
1.4%
-38.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 471 resolved cases

Office Action

§103
Remarks Claims 1-20 are pending. 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 3/30/2026 has been entered. Response to Arguments Applicant's arguments filed 3/30/2026 have been fully considered but they are not persuasive. With respect to Applicant’s first allegation, on pages 10-11 of the response, Osterkamp certainly discloses an intermediary platform that executes a plurality of services comprising a separate service for each of the plurality of member platforms, such as in Osterkamp’s disclosure of separate services may be as simple as providing services, such as settlement services, pre-settlement services, authorization services, or the like, to a member, such as a PoS, facilitating server, merchant server, acquiring bank server, or the like, all of which are members/member platforms, and separate services, such as anonymous token generation, 2FA, and the like, for the user, which is also a member and has a member platform (e.g., the device the user uses to access the digital transactions server), for example. The Examiner also notes that this subject matter has no bearing on the scope of the claim, since the claim limitation is directed to a step being performed by one or more processors of a client device, and the intermediary device is separate therefrom. Therefore, what services the intermediary device may or may not execute has no effect on the scope of the claim. Moreover, if Applicant is simply going for VMs being instantiated for various third parties, this is done all over the place. Please look simply at AWS (Amazon Web Services). If the claim were to be amended to require separate computing instances for each third party, a reference would be readily cited for this. With respect to Applicant’s second allegation, on pages 11-12 of the response, Osterkamp does, indeed, disclose partitions, such as lines 64-65 of column 10: “the anonymous payment token may begin with the number ‘4’, indicating the identity of the facilitating server”. This clearly shows a partition including just the first number and another partition including the rest of the token. It is also noted that newly cited Angara discloses partitions as well, and is cited against the next limitation being argued by Applicant, but is also readily citable against this limitation, since Angara discloses a variety of partitions in anonymous identifiers. Please see cited sections below. Figure 4 includes a few clear examples as well. With respect to Applicant’s third allegation, on page12 of the response, Applicant’s argument is moot in view of the new ground(s) of rejection provided below. With respect to claim 8, Applicant appears to provide a copy of 13 lines of the claim, provides Applicant’s understanding of a portion of Osterkamp, alleges that “Osterkamp does not describe authenticating a user by” and copies in 3 of the limitations in the claim, and alleges “Even if the claimed matching code or matching code input is compared to the authentication credentials of Osterkamp, Osterkamp receives the authentication credentials once and from the user – not a second member platform. Osterkamp does not receive the authentication credentials from a second member platform and then user, as recited by the claims.” To the contrary, as in Osterkamp, the PoS type device 110 may be the user’s phone (e.g., top of column 7), and may be a further intermediary for the transactions, including authentication of the user. Claim Interpretation As Applicant notes, for example, on page 8 of the response dated 9/29/2025, “The claims have been amended herein to recite the physical components (i.e., an intermediary platform; a network of member platforms associated with the intermediary platform; and a client device comprising one or more processors; and one or more memories storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations) of the computing system as a elements outside of the preamble.” Thus, the following are considered physical components: an intermediary platform; a network of member platforms associated with the intermediary platform; a client device; one or more processors; and one or more memories Moreover, all non-transitory computer-readable storage media are construed as being limited to statutory storage media. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1, 4-11, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Osterkamp (U.S. Patent 12,333,533) in view of Angara (U.S. Patent Application Publication 2019/0180053). Regarding Claim 1, Osterkamp discloses a computer implemented method comprising: Receiving, by one or more processors of a client device, user input to an icon corresponding to a software container within a central interface repository, wherein the software container corresponds to a first member platform of a plurality of member platforms associated with an intermediary platform and the intermediary platform executes a plurality of services comprising a separate service for each of the plurality of member platforms (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; receiving user input (e.g., an application with a user interface component including a command to request tokens for a wallet), with wallet on the client device, temporary authorization file on server, account in database, all associated with the user/client as well as the server, for example. These separate services may be as simple as providing services, such as settlement services, pre-settlement services, authorization services, or the like, to a member, such as a PoS, facilitating server, merchant server, acquiring bank server, or the like, all of which are members/member platforms, and separate services, such as anonymous token generation, 2FA, and the like, for the user, which is also a member and has a member platform (e.g., the device the user uses to access the digital transactions server), for example); Providing, by the one or more processors and using a member client interface and to the first member platform, a container activation request based on the user input (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; sending request to server to generate wallet/token(s), for example); Receiving, by the one or more processors and using the member client interface and from the first member platform, a UUEK for the software container (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; receiving token(s), which is associated with the user’s account identifier and is associated therewith for later server lookup, and is also associated with the user’s credentials, such as user identifier, including the exchange identifier (e.g., the whole thing, or any portion thereof), partitions, such as facilitating server partition (e.g., first digit), rest of token, etc., as examples), wherein The UUEK is issued to the first member platform from the intermediary platform and comprises a UUID and a member partition corresponding to the first member platform that is positioned in accordance with a key format (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; receiving token(s), which is associated with the user’s account identifier and is associated therewith for later server lookup, and is also associated with the user’s credentials, such as user identifier, including the exchange identifier (e.g., the whole thing, or any portion thereof), partitions, such as facilitating server partition (e.g., first digit), rest of token, etc., as examples); and Storing, by the one or more processors, the UUEK within the software container for a temporary time period (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; storing token(s) in wallet for a time, for example); and Providing, by the one or more processors, a message transmission that identifies the UUEK and initiates an exchange request from a receiving device associated with a second member platform of the plurality of member platforms, wherein the exchange request comprises the UUEK and is provided by the receiving device to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, lines 35-51; Column 6, line 4 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 10, lines 21-42; Column 12, lines 50-63; Column 14, lines 14-30; and associated figures; sending token to PoS and on for a transaction, for example); But does not appear to explicitly disclose that the member partition is one of a plurality of member partitions respectively corresponding to the plurality of member platforms and the plurality of services executed within the intermediary platform. Angara, however, discloses that the member partition is one of a plurality of member partitions respectively corresponding to the plurality of member platforms and the plurality of services executed within the intermediary platform (Exemplary Citations: for example, Abstract, Paragraphs 31, 40, 43-47, and associated figures; member partitions may be the member’s name, such as Netflix, email.com (or either/both email and/or .com as they are each domains), city, state, zip code, company partition of a credit card number (e.g., the first number is the MMI (e.g., Visa, MasterCard, etc.), IIN/BIN (e.g., Chase Signature Visa, Bank of America Visa Gold, etc.)) included in the next few numbers, and the user’s individual number in the following numbers), as well as anonymous user identifier (e.g., 567), for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the account anonymizing techniques of Angara into the digital wallet system of Osterkamp in order to allow for anonymization of additional pieces of information, to allow for scheduled (re)anonymization of personally identifiable information, to provide for secure storage (e.g., via encryption) of anonymized values, and/or to increase security in the system. Regarding Claim 11, Claim 11 is a system claim that corresponds to method claim 1 and is rejected for the same reasons. Regarding Claim 18, Claim 18 is a medium claim that corresponds to method claim 1 and is rejected for the same reasons. Regarding Claim 4, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the message transmission comprises a NFC message and the receiving device comprises an NFC terminal (Exemplary Citations: for example, Abstract, Column 3, line 60 to Column 4, line 9; Column 4, lines 35-51; Column 6, line 4 to Column 7, line 13; Column 7, line 44 to Column 8, line 10; Column 10, lines 21-42; Column 12, lines 50-63; Column 14, lines 14-30; and associated figures). Regarding Claim 14, Claim 14 is a system claim that corresponds to method claim 4 and is rejected for the same reasons. Regarding Claim 5, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the central interface repository comprises a plurality of software containers that respectively correspond to a subset of the plurality of member platforms (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; multiple wallets, temporary authorization files, and the like, for example). Regarding Claim 15, Claim 15 is a system claim that corresponds to method claim 5 and is rejected for the same reasons. Regarding Claim 6, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the container activation request is provided based on an activation status of the software container and the computer implemented method further comprises (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; status, such as whether or not the token has been used, expiration time for the token, etc., as examples): Modifying the activation status of the software container to indicate that the UUEK is stored within the software container (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; storing expiration time, or storing token making it available for use, as examples); Receiving a subsequent user input to the icon (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; using a token, for example); and In response to the subsequent user input, providing the message transmission (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures). Regarding Claim 16, Claim 16 is a system claim that corresponds to method claim 6 and is rejected for the same reasons. Regarding Claim 7, Osterkamp as modified by Angara discloses the method of claim 6, in addition, Osterkamp discloses responsive to a determination that the temporary time period has lapsed (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; time expired, for example): Removing the UUEK from the software container (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; expiring the token, removing the account, removing the token, etc., as examples); and Modifying the activation status of the software container to indicate that the software container is empty (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 11, lines 29-53; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; expiring the token, removing the account, removing the token, deleting a temporary wallet, deleting a temporary authorization file, etc., as examples). Regarding Claim 17, Claim 17 is a system claim that corresponds to method claim 7 and is rejected for the same reasons. Regarding Claim 8, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the software container is previously generated according to an initialization protocol comprising (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures): Receiving, via an enrollment user interface overlayed to a member user interface or a central user interface, enrollment user input comprising selection data that identifies a service provider instrument of the second member platform, wherein the enrollment user input is provided directly to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; user requesting wallet generation for a particular account, for example); Receiving, using the member client interface, a matching code from the second member platform, wherein the matching code originates from the intermediary platform and is provided to the second member platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 6, line 52 to Column 7, line 13; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; authenticating user, for example); Providing, via a member user interface corresponding to the second member platform, the matching code to a user (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 6, line 52 to Column 7, line 13; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; authenticating user, for example); Receiving, via the enrollment user interface, a matching code input, wherein the matching code input is provided directly to the intermediary platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; authenticating user, for example); and Generating the software container in response to a match between the matching code input and the matching code (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 22-49; Column 14, lines 1-13; and associated figures; generating wallet and temporary authorization file, for example). Regarding Claim 19, Claim 19 is a medium claim that is broader than method claim 8 and is rejected for the same reasons. Regarding Claim 9, Osterkamp as modified by Angara discloses the method of claim 8, in addition, Osterkamp discloses that the icon corresponding to the software container is rendered within the central user interface and the enrollment user interface is overlayed to the central user interface in response to an initial user input to an initialization icon within the central user interface (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-49; Column 13, lines 53-67; Column 14, lines 1-13; and associated figures; command within application within phone’s UI, for example). Regarding Claim 20, Claim 20 is a medium claim that corresponds to method claim 9 and is rejected for the same reasons. Regarding Claim 10, Osterkamp as modified by Angara discloses the method of claim 9, in addition, Osterkamp discloses that the enrollment user interface is overlayed to the member user interface in response to the initial user input to the initialization icon within the member user interface and the initialization icon is rendered within the member user interface using the member client interface (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 12, lines 4-49; Column 13, lines 53-67; Column 14, lines 1-13; and associated figures; requesting wallet as above using command in application in phone’s UI and/or authentication UI within application and phone’s UI, as examples). 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 2, 3, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Osterkamp in view of Angara and RestCase (RestCase, “Internal vs External APIs”, 3/25/2017, 14 pages, retrieved from https://blog.restcase.com/internal-vs-external-apis/). Regarding Claim 2, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the member client interface is an external interface that defines one or more endpoints within a software application hosted by the first member platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 10, line 43 to Column 11, line 5; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures; endpoints, such as servers; identifying facilitating server or digital transactions server, as examples); But does not explicitly disclose that the interface comprises an application programming interface. RestCase, however, discloses that the interface comprises an external application programming interface (Exemplary Citations: for example, Pages 1-2, 5-6, 9-11, external APIs, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the APIs of RestCase into the digital wallet system of Osterkamp as modified by Angara in order to allow for use of both public and private APIs, to increase efficiency, to speed up application development, to reduce required resources, to make interfaces accessible by a wider population, and/or to increase the production of new ideas and decrease costs. Regarding Claim 12, Claim 12 is a system claim that corresponds to method claim 2 and is rejected for the same reasons. Regarding Claim 3, Osterkamp as modified by Angara discloses the method of claim 1, in addition, Osterkamp discloses that the member client interface is an internal interface that defines one or more endpoints within a client side application corresponding to a software application hosted by the first member platform (Exemplary Citations: for example, Abstract, Column 4, line 52 to Column 5, line 11; Column 8 line 47 to Column 9, line 22; Column 9, line 33 to Column 10, line 20; Column 10, line 43 to Column 11, line 5; Column 12, lines 4-21; Column 13, lines 53-67; and associated figures). But does not explicitly disclose that the interface comprises an application programming interface. RestCase, however, discloses that the interface comprises an internal application programming interface (Exemplary Citations: for example, Pages 2-4, 6-9, 11-12, internal APIs, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the APIs of RestCase into the digital wallet system of Osterkamp as modified by Angara in order to allow for use of both public and private APIs, to increase efficiency, to speed up application development, to reduce required resources, to make interfaces accessible by a wider population, and/or to increase the production of new ideas and decrease costs. Regarding Claim 13, Claim 13 is a system claim that corresponds to method claim 3 and is rejected for the same reasons. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30. 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, Jeffrey Nickerson can be reached at (469) 295-9235. 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. /Jeffrey D. Popham/Primary Examiner, Art Unit 2432
Read full office action

Prosecution Timeline

Mar 04, 2025
Application Filed
Jun 27, 2025
Non-Final Rejection mailed — §103
Sep 29, 2025
Response Filed
Jan 20, 2026
Final Rejection mailed — §103
Mar 27, 2026
Interview Requested
Mar 30, 2026
Request for Continued Examination
Apr 12, 2026
Response after Non-Final Action
Jun 17, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12671985
ACCESS AND MOBILITY MANAGEMENT FUNCTION RELOCATION DUE TO SECURITY GATEWAY OVERLOAD/FAILURE
3y 10m to grant Granted Jun 30, 2026
Patent 12481750
A METHOD OF PROCESSING TRANSACTIONS FROM AN UNTRUSTED SOURCE
5y 2m to grant Granted Nov 25, 2025
Patent 12425407
Identity And Access Management Using A Decentralized Gateway Computing System
2y 10m to grant Granted Sep 23, 2025
Patent 12380240
PROTECTING SENSITIVE DATA IN DOCUMENTS
4y 10m to grant Granted Aug 05, 2025
Patent 12326934
DETECTING SUSPICIOUS ACTIVATION OF AN APPLICATION IN A COMPUTER DEVICE
4y 5m to grant Granted Jun 10, 2025
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

3-4
Expected OA Rounds
38%
Grant Probability
62%
With Interview (+24.2%)
4y 7m (~3y 3m remaining)
Median Time to Grant
High
PTA Risk
Based on 471 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