Prosecution Insights
Last updated: April 19, 2026
Application No. 17/243,494

IMPRESSION-TAILORED COMPUTER SEARCH RESULT PAGE VISUAL STRUCTURES

Non-Final OA §103
Filed
Apr 28, 2021
Examiner
CHEUNG, HUBERT G
Art Unit
2152
Tech Center
2100 — Computer Architecture & Software
Assignee
Microsoft Technology Licensing, LLC
OA Round
5 (Non-Final)
63%
Grant Probability
Moderate
5-6
OA Rounds
4y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 63% of resolved cases
63%
Career Allow Rate
246 granted / 390 resolved
+8.1% vs TC avg
Strong +49% interview lift
Without
With
+49.3%
Interview Lift
resolved cases with interview
Typical timeline
4y 6m
Avg Prosecution
23 currently pending
Career history
413
Total Applications
across all art units

Statute-Specific Performance

§101
11.6%
-28.4% vs TC avg
§103
47.9%
+7.9% vs TC avg
§102
17.3%
-22.7% vs TC avg
§112
13.4%
-26.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 390 resolved cases

Office Action

§103
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 . This Office action is in response to the RCE/amendments, arguments and remarks, filed on 12/11/2025, in which claim(s) 1-8, 10-18, 20 and 21 is/are presented for further examination. Claim(s) 1, 11, 20 and 21 has/have been amended. Claim(s) 9 and 19 has/have been previously cancelled. 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 12/11/2025 has been entered. Response to Amendment Applicant’s amendment(s) to claim(s) 21 has/have been accepted. The objection(s) to the claim(s) for informalities has/have been withdrawn. Applicant’s amendment(s) to claim(s) 1, 11 and 20 has/have been accepted. Note: The examiner requests that applicant cite where in the specification there is support for applicant’s amendment(s)/addition(s). It will quicken the prosecution if the examiner does not have to search the entire specification to ensure that applicant has not introduced new matter. Response to Arguments Applicant’s arguments with respect to claim(s) 1-8, 10-18, 20 and 21, filed on 12/11/2025, have been fully considered but they are not persuasive. Applicant’s arguments with respect to the rejection(s) of claim(s) 1-8, 10-18, 20 and 21, under 35 U.S.C. 103, see pages 10-13 of applicant’s remarks, filed on 12/11/2025, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Rejections - 35 USC § 103 The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action: (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. Claim(s) 1-8, 10-18, 20 and 21 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Levin et al., US 6,434,556 B1 (hereinafter “Levin”) in view of Daya et al., US 201/0109411 A1 (hereinafter “Daya”) in further view of Lehmann et al., US 2013/0238583 A1 (hereinafter “Lehmann”). Claims 1, 11 and 20 Levin discloses a computing system comprising: at least one processor (Levin, Col. 5, lines 34-46, see computer system, where computer systems have processors); and a memory (Levin, Col. 5, lines 34-46, see computer system, where computer systems have memory) comprising instructions that, when executed by the at least one processor, cause the at least one processor to perform acts comprising: in response to receipt of a query from a client computing device (Levin, Col. 8, lines 28-43, see the user inputs a search query; and Levin, Fig. 2, step 120 Input search query), constructing a search engine results page (SERP) based upon the query and the search engine user interface profile assigned to the query (Levin, Col. 8, line 44-Col. 9, line 44, see search conducted based upon the search query and the selected search engine, see effective visual representation of the search results and see visually positioning the results; and Levin, Fig. 2, step 150 Generated display of search results and step 160 Interactive navigation and customization of display), wherein the constructed SERP is configured to have the visual structure corresponding to the search engine user interface profile assigned to the query (Levin, Col. 7, lines 36-52; Note: Shows the ability to modify the look, the actual look is a design choice); and upon constructing the SERP, returning the SERP to the client computing device (Levin, Col. 9, lines 17-44, see user navigating the display space; and Levin, Fig. 2, step 160 Interactive navigation and customization of display). Levin does not appear to explicitly disclose assigning a search engine user interface profile to the query from amongst multiple predefined search engine user interface profiles, wherein the search engine user interface profile comprises one or more characteristics of a visual structure of search results, wherein the search engine user interface profile is assigned to the query based upon contextual data associated with the query, search engine user interface profiles assigned to previously received queries, and contextual data associated with the previously received queries, wherein assigning the search engine user interface profile to the query from amongst the multiple predefined search engine user interface profiles comprises: computing respective scores for the multiple search engine user interface profiles, wherein the search engine user interface profile is selected based upon a score computed for the search engine user interface profile being highest from amongst the respective scores computed for the multiple search engine user interface profiles. Daya discloses assigning a search engine user interface profile to the query from amongst multiple predefined search engine user interface profiles (Daya, [0116], see a system comprising: a query interface to present a contextual menu as a user enters a search query, the contextual menu including search-flow options [i.e., where the search-flow options correspond to the “multiple predefined search engine user interface profiles”] initialized to a portion of the query entered by the user), wherein the search engine user interface profile comprises one or more characteristics of a visual structure of search results (Daya, [0116], see replace the portion of the query with a graphical element in response to a user selection of a search-flow option, the graphical element summarizing the portion of the query entered; wherein the query interface is to modify an entry area for the search query with a prompt for additional query terms that are determined by the search-flow option selected; and a query engine to execute a complete search query using the portion of the query and the additional query terms, the complete search query organization defined by the search-flow option [i.e., corresponds to the “visual structure of search results” claimed] selected by the user), wherein the search engine user interface profile is assigned to the query based upon contextual data associated with the query (Daya, [0116], see a system comprising: a query interface to present a contextual menu as a user enters a search query, the contextual menu including search-flow options [i.e., where the search-flow options correspond to the “multiple predefined search engine user interface profiles”] initialized to a portion of the query entered by the user). Levin and Daya are analogous art because they are from the same field of endeavor of displaying/returning search results. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Levin and Daya before him/her, to modify the search engine interface of Levin to include the interface of Daya because it would guide a user through querying. The suggestion/motivation for doing so would have been to allow the user to spend less time learning how to search and actually searching, see Daya, [0011]. Therefore, it would have been obvious to combine Daya with Levin to obtain the invention as specified in the instant claim(s). The combination of Levin and Daya does not appear to explicitly disclose search engine user interface profiles assigned to previously received queries, and contextual data associated with the previously received queries, wherein assigning the search engine user interface profile to the query from amongst the multiple predefined search engine user interface profiles comprises: computing respective scores for the multiple search engine user interface profiles, wherein the search engine user interface profile is selected based upon a score computed for the search engine user interface profile being highest from amongst the respective scores computed for the multiple search engine user interface profiles. Lehmann discloses search engine user interface profiles assigned to previously received queries, and contextual data associated with the previously received queries (Lehmann, [0037], see “… the search monitor service 113 may rank and select a most suitable search engine [i.e., where each of the suitable search engines is being interpreted as a “search engine user interface profile”]. Search engines maintain metadata indicating which searches they may perform. This search engine metadata allows an application to decide whether a search engine is appropriate to make a search request of and the scope of possible search results that may be received. For example, if a first search engine reflects metadata that a search for “German Walldorf Breweries” is supported and a second search engine reflects metadata that a search for “European breweries” is supported, one determination that can be made is that the first search engine may return more focused and/or relevant results. By calculating which search engine's metadata correlates most closely to the metadata (i.e., context) of a specific navigation node 114 view, the application can select the most suitable search engine for a given search given the context of the navigation node 114 view. In some implementations, the closest correlation determination between metadata can be performed by a direct, statistical, Boolean, logical, or other suitable comparison of metadata. The search monitor service 113 may then rank and present search engine(s) in some determined order to the enterprise portal user based upon context data 116 (discussed below) and the compared metadata. In some implementations, additional ranking processing can be performed.”; and Lehmann, [0038], see “… during searches performed by enterprise portal users, the search monitor service 113 may record context data 116 identifying search engine(s) selected by the enterprise portal users and the associated enterprise portal user's navigation node 114 view(s). Following the selection of the search engine(s) by the enterprise portal users, the strength of a correlation between metadata of the search engines(s) and the navigation node 114 view(s) may be recorded as well as whether the enterprise portal user ran additional searches on the same navigation node 114 view and whether additional searches were associated with prior searches (i.e. narrowed and/or broadened the prior searches, etc.). By analyzing the context data 116, a correlation may be made that certain search providers return relevant content for specific navigation node 114 views that may be considered as a factor in a determination as to which search engine is most relevant for a specific navigation node 114 view. …”), wherein assigning the search engine user interface profile to the query from amongst the multiple predefined search engine user interface profiles comprises: computing respective scores for the multiple search engine user interface profiles, wherein the search engine user interface profile is selected based upon a score computed for the search engine user interface profile being highest from amongst the respective scores computed for the multiple search engine user interface profiles (Lehmann, [0037], see “… the search monitor service 113 may rank and select a most suitable search engine [i.e., where each of the suitable search engines is being interpreted as a “search engine user interface profile”]. Search engines maintain metadata indicating which searches they may perform. This search engine metadata allows an application to decide whether a search engine is appropriate to make a search request of and the scope of possible search results that may be received. For example, if a first search engine reflects metadata that a search for “German Walldorf Breweries” is supported and a second search engine reflects metadata that a search for “European breweries” is supported, one determination that can be made is that the first search engine may return more focused and/or relevant results. By calculating which search engine's metadata correlates most closely to the metadata (i.e., context) of a specific navigation node 114 view, the application can select the most suitable search engine for a given search given the context of the navigation node 114 view. In some implementations, the closest correlation determination between metadata can be performed by a direct, statistical, Boolean, logical, or other suitable comparison of metadata. The search monitor service 113 may then rank and present search engine(s) in some determined order to the enterprise portal user based upon context data 116 (discussed below) and the compared metadata. In some implementations, additional ranking processing can be performed.”, where the ranking of the search engines described is being interpreted as the “scoring”). Levin, Daya and Lehmann are analogous art because they are from the same field of endeavor of displaying/returning search results. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Levin, Daya and Lehmann before him/her, to modify the search engine interface of the combination of Levin and Daya to include the search engine scoring of Lehmann because it would allow selecting the most advantageous search engine. The suggestion/motivation for doing so would have been to provide more relevant search results to users, see Lehmann, [0012]. Therefore, it would have been obvious to combine Lehmann with the combination of Levin and Daya to obtain the invention as specified in the instant claim(s). Claim(s) 11 and 20 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale. With respect to claim 20, Levin discloses a non-transitory computer-readable memory having instructions stored thereon (Levin, Col. 5, lines 34-46, see computer system, where computer systems have memory). Claims 2, 12 and 21 With respect to claims 2, 12 and 21, the combination of Levin, Daya and Lehmann discloses wherein the contextual data comprises at least one of: time that the query was received from the client computing device; an identifier for the client computing device (Lehmann, [0019], see “… With only a Web browser, users can begin work once they have been authenticated in the portal which offers a single point of access to information, enterprise applications, and services both inside and outside an organization. …”); or an identifier of a browser application from which the query was received (Lehmann, [0043], see “… the client application 146 can be and/or include a Web browser. In some implementations, the client-application 146 can use parameters, metadata, and other information received at launch to access a particular set of data from the server 102. …”). Claims 3 and 13 With respect to claims 3 and 13, the combination of Levin, Daya and Lehmann discloses wherein the SERP is constructed such that user interface elements below a fold of the SERP are suppressed (Levin, Col. 7, lines 36-52; Levin, Col. 8, line 44-Col. 9, line 44; and Levin, Fig. 2, step 150). Claims 4 and 14 With respect to claims 4 and 14, the combination of Levin, Daya and Lehmann discloses wherein the SERP is constructed such that a font size of titles in the SERP is increased relative to a standard font size for SERPs constructed by the computing system (Levin, Col. 7, lines 36-52). Claims 5 and 15 With respect to claims 5 and 15, the combination of Levin, Daya and Lehmann discloses wherein the SERP is constructed such that a font color of captions of web results in the SERP is darker relative to a standard color for SERPs constructed by the computing system (Levin, Col. 7, lines 36-52). Claims 6 and 16 With respect to claims 6 and 16, the combination of Levin, Daya and Lehmann discloses the acts further comprising: in response to receipt of a second query from the client computing device (Levin, Col. 8, lines 28-43, see the user inputs a search query; and Levin, Fig. 2, step 120 Input search query; Note: Where it would be obvious to repeat previous steps), assigning a second search engine user interface profile to the second query from amongst the multiple predefined search engine user interface profiles (Levin, Col. 7, lines 36-52, see a selection of search engines to display, where the search engine and its corresponding interface is assigned by being selected; Levin, Fig. 2, step 110 Set preferences and select search engines; and Levin, Fig. 3A Set preferences and select search engines), wherein the second search engine user interface profile is assigned to the second query based upon second contextual data associated with the second query (Levin, Col. 7, lines 36-52, see a selection of search engines to display, where the search engine and its corresponding interface is assigned by being selected; Levin, Fig. 2, step 110 Set preferences and select search engines; and Levin, Fig. 3A Set preferences and select search engines, where the selection situation is being interpreted as the “context”), the user interface profiles assigned to the previously received queries, and the contextual data associated with the previously received queries (Lehmann, [0037], see “… the search monitor service 113 may rank and select a most suitable search engine [i.e., where each of the suitable search engines is being interpreted as a “search engine user interface profile”]. Search engines maintain metadata indicating which searches they may perform. This search engine metadata allows an application to decide whether a search engine is appropriate to make a search request of and the scope of possible search results that may be received. For example, if a first search engine reflects metadata that a search for “German Walldorf Breweries” is supported and a second search engine reflects metadata that a search for “European breweries” is supported, one determination that can be made is that the first search engine may return more focused and/or relevant results. By calculating which search engine's metadata correlates most closely to the metadata (i.e., context) of a specific navigation node 114 view, the application can select the most suitable search engine for a given search given the context of the navigation node 114 view. In some implementations, the closest correlation determination between metadata can be performed by a direct, statistical, Boolean, logical, or other suitable comparison of metadata. The search monitor service 113 may then rank and present search engine(s) in some determined order to the enterprise portal user based upon context data 116 (discussed below) and the compared metadata. In some implementations, additional ranking processing can be performed.”; and Lehmann, [0038], see “… during searches performed by enterprise portal users, the search monitor service 113 may record context data 116 identifying search engine(s) selected by the enterprise portal users and the associated enterprise portal user's navigation node 114 view(s). Following the selection of the search engine(s) by the enterprise portal users, the strength of a correlation between metadata of the search engines(s) and the navigation node 114 view(s) may be recorded as well as whether the enterprise portal user ran additional searches on the same navigation node 114 view and whether additional searches were associated with prior searches (i.e. narrowed and/or broadened the prior searches, etc.). By analyzing the context data 116, a correlation may be made that certain search providers return relevant content for specific navigation node 114 views that may be considered as a factor in a determination as to which search engine is most relevant for a specific navigation node 114 view. …”); constructing a second SERP based upon the second query and the second search engine user interface profile assigned to the second query (Levin, Col. 8, line 44-Col. 9, line 44; and Levin, Fig. 2, step 150), wherein the constructed second SERP is configured to have a second visual structure corresponding to the second search engine user interface profile assigned to the second query that is different from the visual structure corresponding to the search engine user interface search engine user interface profile assigned to the query (Levin, Col. 7, lines 36-52; Note: Shows the ability to modify the look, the actual look is a design choice); and upon constructing the second SERP, returning the second SERP to the client computing device (Levin, Col. 9, lines 17-44; and Levin, Fig. 2, step 160). Claims 7 and 17 With respect to claims 7 and 17, the combination of Levin, Daya and Lehmann discloses the acts further comprising: in response to receipt of a second query from a second client computing device (Levin, Col. 8, lines 28-43, see the user inputs a search query; and Levin, Fig. 2, step 120 Input search query; Note: Where it would be obvious to repeat previous steps), assigning a second search engine user interface profile to the second query from amongst the multiple predefined search engine user interface profiles (Levin, Col. 7, lines 36-52, see a selection of search engines to display, where the search engine and its corresponding interface is assigned by being selected; Levin, Fig. 2, step 110 Set preferences and select search engines; and Levin, Fig. 3A Set preferences and select search engines), wherein the second search engine user interface profile is assigned to the second query based upon second contextual data associated with the second query (Levin, Col. 7, lines 36-52, see a selection of search engines to display, where the search engine and its corresponding interface is assigned by being selected; Levin, Fig. 2, step 110 Set preferences and select search engines; and Levin, Fig. 3A Set preferences and select search engines, where the selection situation is being interpreted as the “context”), the user interface profiles assigned to the previously received queries, and the contextual data associated with the previously received queries (Lehmann, [0037], see “… the search monitor service 113 may rank and select a most suitable search engine [i.e., where each of the suitable search engines is being interpreted as a “search engine user interface profile”]. Search engines maintain metadata indicating which searches they may perform. This search engine metadata allows an application to decide whether a search engine is appropriate to make a search request of and the scope of possible search results that may be received. For example, if a first search engine reflects metadata that a search for “German Walldorf Breweries” is supported and a second search engine reflects metadata that a search for “European breweries” is supported, one determination that can be made is that the first search engine may return more focused and/or relevant results. By calculating which search engine's metadata correlates most closely to the metadata (i.e., context) of a specific navigation node 114 view, the application can select the most suitable search engine for a given search given the context of the navigation node 114 view. In some implementations, the closest correlation determination between metadata can be performed by a direct, statistical, Boolean, logical, or other suitable comparison of metadata. The search monitor service 113 may then rank and present search engine(s) in some determined order to the enterprise portal user based upon context data 116 (discussed below) and the compared metadata. In some implementations, additional ranking processing can be performed.”; and Lehmann, [0038], see “… during searches performed by enterprise portal users, the search monitor service 113 may record context data 116 identifying search engine(s) selected by the enterprise portal users and the associated enterprise portal user's navigation node 114 view(s). Following the selection of the search engine(s) by the enterprise portal users, the strength of a correlation between metadata of the search engines(s) and the navigation node 114 view(s) may be recorded as well as whether the enterprise portal user ran additional searches on the same navigation node 114 view and whether additional searches were associated with prior searches (i.e. narrowed and/or broadened the prior searches, etc.). By analyzing the context data 116, a correlation may be made that certain search providers return relevant content for specific navigation node 114 views that may be considered as a factor in a determination as to which search engine is most relevant for a specific navigation node 114 view. …”); constructing a second SERP based upon the second query and the second search engine user interface profile assigned to the second query, wherein the constructed second SERP is configured to have a second visual structure corresponding to the second search engine user interface profile assigned to the second query that is different from the visual structure corresponding to the search engine user interface search engine user interface profile assigned to the query (Levin, Col. 7, lines 36-52; Note: Shows the ability to modify the look, the actual look is a design choice); and upon constructing the second SERP, returning the second SERP to the second client computing device (Levin, Col. 9, lines 17-44; and Levin, Fig. 2, step 160). Claims 8 and 18 With respect to claims 8 and 18, the combination of Levin, Daya and Lehmann discloses wherein the contextual data comprise a preference of a user of the client computing device with respect to visual structures of SERPs, wherein the preference is retrieved from a user profile for the user, wherein the user profile is maintained by a search engine that provides the SERP (Levin, Col. 12, lines 8-23, see modification of the visual representation based on the display of the computing device; and Levin, Col. 12, lines 24-43, see display space relevance profile). Claim 10 With respect to claim 10, the combination of Levin, Daya and Lehmann discloses wherein assigning the search engine interface profile to the query from amongst the multiple predefined search engine user interface profiles further comprises: determining that the score assigned to the search engine user interface profile is above a predefined threshold, wherein the search engine user interface profile is assigned to the query due to the score being above the predefined threshold (Levin, Col. 11, lines 4-26, see search engine ranking factor, where the threshold is a weighting over 0; and Lehmann, [0037], see “… the search monitor service 113 may rank and select a most suitable search engine [i.e., where each of the suitable search engines is being interpreted as a “search engine user interface profile”]. Search engines maintain metadata indicating which searches they may perform. This search engine metadata allows an application to decide whether a search engine is appropriate to make a search request of and the scope of possible search results that may be received. For example, if a first search engine reflects metadata that a search for “German Walldorf Breweries” is supported and a second search engine reflects metadata that a search for “European breweries” is supported, one determination that can be made is that the first search engine may return more focused and/or relevant results. By calculating which search engine's metadata correlates most closely to the metadata (i.e., context) of a specific navigation node 114 view, the application can select the most suitable search engine for a given search given the context of the navigation node 114 view. In some implementations, the closest correlation determination between metadata can be performed by a direct, statistical, Boolean, logical, or other suitable comparison of metadata. The search monitor service 113 may then rank and present search engine(s) in some determined order to the enterprise portal user based upon context data 116 (discussed below) and the compared metadata. In some implementations, additional ranking processing can be performed.”, where the ranking of the search engines described is being interpreted as the “scoring”). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. – Denman et al., 2015/0370895 for generating contextual search presentation; – Brill, 2004/0260695 for to tune a general-purpose search engine for a search entry point; – Sivaraj, 2017/0102832 for displaying content based on selections of unlinked objects; – Kraynov et al., 10339191 for a system for processing a search query; and – Song et al., 8793265 for selecting personalized search engines for accessing information. Point of Contact Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P EST. 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, Neveen Abel-Jalil can be reached at (571) 270-0474. 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. HUBERT G. CHEUNG Assistant Examiner Art Unit 2152 Examiner: Hubert Cheung /Hubert Cheung/Assistant Examiner, Art Unit 2152Date: March 18, 2026 /NEVEEN ABEL JALIL/Supervisory Patent Examiner, Art Unit 2152
Read full office action

Prosecution Timeline

Apr 28, 2021
Application Filed
Feb 22, 2023
Non-Final Rejection — §103
Aug 28, 2023
Response Filed
Oct 24, 2023
Final Rejection — §103
Dec 19, 2023
Applicant Interview (Telephonic)
Dec 19, 2023
Examiner Interview Summary
Jan 31, 2024
Response after Non-Final Action
Feb 16, 2024
Applicant Interview (Telephonic)
Feb 16, 2024
Response after Non-Final Action
Mar 27, 2024
Request for Continued Examination
Apr 04, 2024
Response after Non-Final Action
Jun 12, 2024
Non-Final Rejection — §103
Dec 17, 2024
Response Filed
Mar 06, 2025
Final Rejection — §103
Aug 11, 2025
Notice of Allowance
Aug 11, 2025
Response after Non-Final Action
Aug 28, 2025
Response after Non-Final Action
Dec 11, 2025
Request for Continued Examination
Dec 20, 2025
Response after Non-Final Action
Mar 19, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596674
A SYSTEM FOR DATA ARCHIVAL IN A BLOCKCHAIN NETWORK AND A METHOD THEREOF
2y 5m to grant Granted Apr 07, 2026
Patent 12591611
EFFICIENT ACCESS MARKING APPROACH FOR EFFICIENT RETRIEVAL OF DOCUMENT ACCESS DATA
2y 5m to grant Granted Mar 31, 2026
Patent 12585731
APPARATUS AND METHODS FOR DETERMINING A PROBABILITY DATUM
2y 5m to grant Granted Mar 24, 2026
Patent 12561306
SYSTEMS AND METHODS FOR OPTIMIZING DATA PROCESSING IN A DISTRIBUTED COMPUTING ENVIRONMENT
2y 5m to grant Granted Feb 24, 2026
Patent 12547594
SPATIAL-TEMPORAL STORAGE
2y 5m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
63%
Grant Probability
99%
With Interview (+49.3%)
4y 6m
Median Time to Grant
High
PTA Risk
Based on 390 resolved cases by this examiner. Grant probability derived from career allow 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