DETAILED ACTION
1. 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 Amendment
2. Receipt of Applicant’s Amendment filed on 01/13/2026 is acknowledged. The amendment includes the amending of claims 1, 5, 8, 12, 15, and 19.
Claim Rejections - 35 USC § 103
3. 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.
4. 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.
5. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 1-4, 8-11, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kallman et al. (U.S. PGPUB 2024/0419749) in view of Zhao et al. (U.S. PGPUB 2021/0248376), and further in view of Deshpande et al. (Article entitled “Learning Deep Representation Using a Fully Convolutional Autoencoder for Automated Floor Plan Image Retrieval”, dated 2023), and further in view of Ingold et al. (U.S. PGPUB 2025/0190425), and further in view of McElvain et al. (U.S. PGPUB 2019/0340172).
7. Regarding claims 1, 8, and 15, Kallman teaches a method, non-transitory computer-readable medium, and system comprising:
A) receiving, at a server over a network, a query for a building information model (Paragraphs 28-29);
B) determining, by the server, a query context (Paragraph 30);
C) generating, by the server, an embedding in a vector space for each of the query, and data from a vector database comprising a plurality of building information models (Paragraphs 28, 41-42, 47, and 50);
D) retrieving, by the server searching into the vector space, information from the building information model of the plurality of building information models that is responsive to the query (Paragraphs 28, 41-42, 47, and 50); and
E) providing, by the server, the information responsive to the query (Paragraphs 28, 41-42, 47, 50, and 61, Figure 7);
F) wherein information responsive to the query is part of the building information model (Paragraphs 28, 41-42, 47, 50, and 61, Figure 7);
I) wherein determining the query context comprises using a knowledge graph to gather contextual data from the building information model (Paragraphs 28, 46, 48, 49, and 53-54);
J) the knowledge graph storing relationships between various data that comprise the building information model (Paragraphs 28-29, 37, 49, and 53-54).
The examiner notes that Kallman teaches “receiving, at a server over a network, a query for a building information model” as “In commercial applications, various entities can also use a robust geospatial online search system to look for answers to questions that relate to a location. For example, real-estate businesses can utilize a geospatial online search system to research queries that inform real estate investment or development activities. A sample query for a real estate development firm, for example, can be “What are undeveloped areas in the State of Vermont with commercial zoning allowance that are near residential apartment buildings?” Similarly, individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”. FIG. 1 illustrates an environment 100 of a geospatial online search system 108 according to an embodiment. The user 102 can use a variety of computing devices 104 to access the system 108 via the Internet 106, pose a query and receive results” (Paragraphs 28-29). The examiner further notes that the example query of “how old is the roof at 123 Main St.?” teaches the claimed query for a building information model. The examiner notes that Kallman teaches “determining, by the server, a query context” as “In some embodiments, the geospatial online search system 108 utilizes a spider engine 114 to build an index 116. The index 116 can be prepared prior to receiving a query from the user 102, concurrently, or can be further improved in relation to one or more past queries from the users 102. The query processing module 118 can include a plurality of submodules to receive a user query and perform operations to extract semantics, context, timelines, and other attributes of the query and find one or more relevant indexes to provide to the user 102. A results services module 120 can generate the UI elements of the UI 100 and provide the results of the user query to the user 102” (Paragraph 30). The examiner further notes that the extraction of a context of a query teaches the claimed determining. The examiner further notes that Kallman teaches “generating, by the server, an embedding in a vector space for each of the query, and data from a vector database comprising a plurality of building information models” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “the geospatial online search system 108 can receive an unstructured query. The query preprocessing module 402 receives the unstructured user query and generates a structured user query” (Paragraph 39), “the query understanding module 408 can map the structured query to a root query using vector space embeddings for the queries. Queries having similar vector space embeddings can be mapped to a shared root query” (Paragraph 41), “A query planner module 410 can receive the structured query and/or the root query and can generate various query pathways for the query. For example, the query planner module 410 can plan query pathways for the query to be sent to graph query clients 404 interfacing with the knowledge graph 406, private and/or public relational or vector-space embedding databases and/or indexes” (Paragraph 42), “the structured query with a first set of labels can be run through the knowledge graph 406, and/or queried against a variety of sources, such as the document storage 416, and if applicable/authorized against private indexes 418. When a root query is generated, the root query associated with the structured query can be searched against a vector embedding database/index 420. At the end of the first phase, a first set of results can be generated and stored in the results services 434” (Paragraph 47), and “The root query can be searched in a vector-space embedding database and/or index, where a vector embedding of the root query is searched in the vector-space embedding database and/or index. Milvus is one example of a vector-space database that can be searched” (Paragraph 50). The examiner further notes that received user queries (such example of the query directed towards “building information models” such as “how old is the roof at 123 Main St.?”) are vectorized (i.e. have embeddings generated) and executed against a database of embeddings (i.e. a vector database) of building information model data (i.e. returning results corresponding to the example building information query of “how old is the roof at 123 Main St.?” entails querying data related to building information models). The examiner further notes that Kallman teaches “retrieving, by the server searching into the vector space, information from the building information model of the plurality of building information models that is responsive to the query” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “the geospatial online search system 108 can receive an unstructured query. The query preprocessing module 402 receives the unstructured user query and generates a structured user query” (Paragraph 39), “the query understanding module 408 can map the structured query to a root query using vector space embeddings for the queries. Queries having similar vector space embeddings can be mapped to a shared root query” (Paragraph 41), “A query planner module 410 can receive the structured query and/or the root query and can generate various query pathways for the query. For example, the query planner module 410 can plan query pathways for the query to be sent to graph query clients 404 interfacing with the knowledge graph 406, private and/or public relational or vector-space embedding databases and/or indexes” (Paragraph 42), “the structured query with a first set of labels can be run through the knowledge graph 406, and/or queried against a variety of sources, such as the document storage 416, and if applicable/authorized against private indexes 418. When a root query is generated, the root query associated with the structured query can be searched against a vector embedding database/index 420. At the end of the first phase, a first set of results can be generated and stored in the results services 434” (Paragraph 47), and “The root query can be searched in a vector-space embedding database and/or index, where a vector embedding of the root query is searched in the vector-space embedding database and/or index. Milvus is one example of a vector-space database that can be searched” (Paragraph 50). The examiner further notes that received user queries (such example of the query directed towards “building information models” such as “how old is the roof at 123 Main St.?”) are vectorized (i.e. have embeddings generated) and executed against a database of embeddings (i.e. a vector database) of building information model data (i.e. returning results corresponding to the example building information query of “how old is the roof at 123 Main St.?” entails querying data related to building information models) for subsequent generation of query results. The examiner further notes that Kallman teaches “providing, by the server, the information responsive to the query” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “the geospatial online search system 108 can receive an unstructured query. The query preprocessing module 402 receives the unstructured user query and generates a structured user query” (Paragraph 39), “the query understanding module 408 can map the structured query to a root query using vector space embeddings for the queries. Queries having similar vector space embeddings can be mapped to a shared root query” (Paragraph 41), “A query planner module 410 can receive the structured query and/or the root query and can generate various query pathways for the query. For example, the query planner module 410 can plan query pathways for the query to be sent to graph query clients 404 interfacing with the knowledge graph 406, private and/or public relational or vector-space embedding databases and/or indexes” (Paragraph 42), “the structured query with a first set of labels can be run through the knowledge graph 406, and/or queried against a variety of sources, such as the document storage 416, and if applicable/authorized against private indexes 418. When a root query is generated, the root query associated with the structured query can be searched against a vector embedding database/index 420. At the end of the first phase, a first set of results can be generated and stored in the results services 434” (Paragraph 47), “The root query can be searched in a vector-space embedding database and/or index, where a vector embedding of the root query is searched in the vector-space embedding database and/or index. Milvus is one example of a vector-space database that can be searched” (Paragraph 50), and “The result of a query can be used to generate various user interfaces, including for example, user interfaces that display geospatial data in a convenient or easy-to-digest format” (Paragraph 61). The examiner further notes that received user queries (such example of the query directed towards “building information models” such as “how old is the roof at 123 Main St.?”) are vectorized (i.e. have embeddings generated) and executed against a database of embeddings of building information model data (i.e. returning results corresponding to the example building information query of “how old is the roof at 123 Main St.?” entails querying data related to building information models) for subsequent generation of query results that are displayed (i.e. provided) to a querying user. The examiner further notes that Kallman teaches “wherein information responsive to the query is part of the building information model” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “the geospatial online search system 108 can receive an unstructured query. The query preprocessing module 402 receives the unstructured user query and generates a structured user query” (Paragraph 39), “the query understanding module 408 can map the structured query to a root query using vector space embeddings for the queries. Queries having similar vector space embeddings can be mapped to a shared root query” (Paragraph 41), “A query planner module 410 can receive the structured query and/or the root query and can generate various query pathways for the query. For example, the query planner module 410 can plan query pathways for the query to be sent to graph query clients 404 interfacing with the knowledge graph 406, private and/or public relational or vector-space embedding databases and/or indexes” (Paragraph 42), “the structured query with a first set of labels can be run through the knowledge graph 406, and/or queried against a variety of sources, such as the document storage 416, and if applicable/authorized against private indexes 418. When a root query is generated, the root query associated with the structured query can be searched against a vector embedding database/index 420. At the end of the first phase, a first set of results can be generated and stored in the results services 434” (Paragraph 47), “The root query can be searched in a vector-space embedding database and/or index, where a vector embedding of the root query is searched in the vector-space embedding database and/or index. Milvus is one example of a vector-space database that can be searched” (Paragraph 50), and “The result of a query can be used to generate various user interfaces, including for example, user interfaces that display geospatial data in a convenient or easy-to-digest format” (Paragraph 61). The examiner further notes that received user queries (such example of the query directed towards “building information models” such as “how old is the roof at 123 Main St.?”) are vectorized (i.e. have embeddings generated) and executed against a database of embeddings of building information model data (i.e. returning results corresponding to the example building information query of “how old is the roof at 123 Main St.?” entails querying data related to building information models) for subsequent generation of query results that are displayed (i.e. provided) to a querying user. The examiner further notes that Kallman teaches “wherein determining the query context comprises using a knowledge graph to gather contextual data from the building information model” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “The enrichment and indexing pipeline 424 can run the data visited or retrieved by the spider engine 422 through the graph query clients 404 and the knowledge graph 406 to enrich the index with semantic, relationships, types, formats, contextual or any other enrichment data returned by the knowledge graph 406” (Paragraph 46), “the query planner module 410 can determine query pathways to further enrich the query in semantics, context, timelines, and/or other attributes. In this manner, a more featured or feature-rich query can be queried against the various sources, such as the knowledge graph 406. The query and/or the root query can be run against the knowledge graph 406 to hydrate the structured query” (Paragraph 48), “For example, a user query can be “Is there a build-up of tanks in the Eastern Ukraine?”…the query can be hydrated with semantics, context, relationships, and timing information. The knowledge graph 406 can be used to enrich, hydrate, or augment the query. In the example above, the query includes a timeline of interest (e.g., “Is there . . . ” indicating “current,” or “now”), and a named entity (“Ukraine”). Furthermore, the knowledge graph 406 can include embeddings from data sources 426 related to an ongoing or current war in Ukraine” (Paragraph 49), and The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field. A relationship builder 524 can traverse the subject feature graph 518 and the source feature graph 522 to detect and build relationships between these graphs, into the knowledge graph 510. In other words, the relationship builder 524 generates pairings and mappings between the query graphs (e.g., subject feature graph 518) and the source graphs (e.g., source feature graph 522). In some embodiments, the relationship builder 524 can be implemented with asynchronous analytics or other techniques. As an example, if a subject feature graph 518 encodes the physical dimension of a particular military tank, and a source feature graph 522 encodes the resolution of an EO sensor, the relationship builder 524 can create a pairing between the two as a structure in the knowledge graph 510” (Paragraphs 53-54). The examiner further notes that query context can be ascertained via a knowledge graph that houses data embeddings (which can be embeddings regarding building information). Specifically, Kallman teaches that searchable data also includes building information model(s) (See example query of “how old is the roof at 123 Main St.?”). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors). Thus, the building model context data from a knowledge graph housing building information model data is used to enrich a query (such as an example building information query of “how old is the roof at 123 Main St.?”). The examiner further notes that Kallman teaches “the knowledge graph storing relationships between various data that comprise the building information model” as “In commercial applications, various entities can also use a robust geospatial online search system to look for answers to questions that relate to a location. For example, real-estate businesses can utilize a geospatial online search system to research queries that inform real estate investment or development activities. A sample query for a real estate development firm, for example, can be “What are undeveloped areas in the State of Vermont with commercial zoning allowance that are near residential apartment buildings?” Similarly, individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”. FIG. 1 illustrates an environment 100 of a geospatial online search system 108 according to an embodiment. The user 102 can use a variety of computing devices 104 to access the system 108 via the Internet 106, pose a query and receive results” (Paragraphs 28-29), “The geospatial online search system 108 can include a core 312, which allows a user to search for data about any location, via a user interface element, such as the UI element 314. The core 312 can access several sources to build one or more knowledge graphs and indexes against which a user query can be executed. For example, the core 312 can interface with multiple data providers 322 via data crawlers 324 to build one or more knowledge graphs and/or index databases” (Paragraph 37), “For example, a user query can be “Is there a build-up of tanks in the Eastern Ukraine?”…the query can be hydrated with semantics, context, relationships, and timing information. The knowledge graph 406 can be used to enrich, hydrate, or augment the query. In the example above, the query includes a timeline of interest (e.g., “Is there . . . ” indicating “current,” or “now”), and a named entity (“Ukraine”). Furthermore, the knowledge graph 406 can include embeddings from data sources 426 related to an ongoing or current war in Ukraine” (Paragraph 49), “one subject feature graph 518 can be directed to a type of military tank and its various physical features and/or other characteristics. Various models 520 can be used to build one or more source feature graphs 522, directed to attributes and characteristics of the available sources of content for searching a query. As an example, a source feature graph 522 can encode attributes and characteristics of a type of remote sensor generating imagery data for an image database… The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field. A relationship builder 524 can traverse the subject feature graph 518 and the source feature graph 522 to detect and build relationships between these graphs, into the knowledge graph 510. In other words, the relationship builder 524 generates pairings and mappings between the query graphs (e.g., subject feature graph 518) and the source graphs (e.g., source feature graph 522). In some embodiments, the relationship builder 524 can be implemented with asynchronous analytics or other techniques. As an example, if a subject feature graph 518 encodes the physical dimension of a particular military tank, and a source feature graph 522 encodes the resolution of an EO sensor, the relationship builder 524 can create a pairing between the two as a structure in the knowledge graph 510” (Paragraphs 53-54). The examiner further notes that the system of Kallman includes a knowledge graph that stores relationships between various types of data (see example of tanks and sensors). Moreover, Kallman teaches that searchable data also includes building information model(s) (See example query of “how old is the roof at 123 Main St.?”). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors).
Kallman does not explicitly teach:
C) generating, by the server, an embedding in a vector space for the query context.
Zhao, however, teaches “generating, by the server, an embedding in a vector space for the query context” as “the disclosed systems generate (i) a query-context vector based on the query vector and the context vectors, and (ii) candidate-response vectors representing candidate responses to the question from a domain-knowledge base or other source. To respond to a user's question, the disclosed systems further select a response from the candidate responses based on a comparison of the query-context vector and the candidate-response vectors” (Abstract) and “the term “query-context vector” refers to a combination, extraction, or portions of a query vector and one or more context vectors. In particular, in some cases, the query-context vector can include a concatenation of a query vector and one or more of context vectors” (Paragraph 46).
The examiner further notes that although the primary reference of Kallman teaches the determination of a query context, there is no explicit teaching of vectorizing (i.e. generating an embedding) of such a query context when executing the query. Nevertheless, the secondary reference of Zhao teaches the concept of using query vectors and context vectors for executing user queries. The combination would result in vectorizing the query context of Kallman in order to expand its querying process.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Zhao’s would have allowed Kallman’s to provide a method for avoiding ambiguous responses to user queries, as noted by Zhao (Paragraph 4).
Kallman and Zhao do not explicitly teach:
G) wherein each of the plurality of building information models comprises a digital building portfolio, the digital building portfolio comprises at least one set of building plans that is converted into image embeddings; and
H) the image embeddings are stored in the vector database.
Deshpande, however, teaches “wherein each of the plurality of building information models comprises a digital building portfolio, the digital building portfolio comprises at least one set of building plans that is converted into image embeddings” as “We propose an unsupervised deep representation learning technique for transforming the floor plan images into a more compact form, suitable for querying and retrieval. A fully convolutional autoencoder is used for this purpose. We conduct our experiments on the BRIDGE and ROBIN datasets” (Section 17.1), “the raw dataset images are first preprocessed to make them uniform and suitable for training. These preprocessed images are used for training the autoencoder. After the model has been trained, it is used for feature extraction in the second phase. The feature vectors thus obtained are stored for future use. The third phase is the retrieval of the most similar floor plans from the dataset, given a query image. Whenever a query image is provided, it is first preprocessed using the preprocessing method used in phase one. Then, features are extracted from this image using the trained autoencoder. Thus, we obtain the query feature vector. The distance between the query feature vector and each of the feature vectors stored in the database is calculated” (Section 17.2.1), and “a novel dataset named BRIDGE was introduced. It contains 13k unlabeled, unstructured, and complex floor plan images. All the images are web-scraped and compiled together” (Section 17.3.1) and “the image embeddings are stored in the vector database” as “We propose an unsupervised deep representation learning technique for transforming the floor plan images into a more compact form, suitable for querying and retrieval. A fully convolutional autoencoder is used for this purpose. We conduct our experiments on the BRIDGE and ROBIN datasets” (Section 17.1), “the raw dataset images are first preprocessed to make them uniform and suitable for training. These preprocessed images are used for training the autoencoder. After the model has been trained, it is used for feature extraction in the second phase. The feature vectors thus obtained are stored for future use. The third phase is the retrieval of the most similar floor plans from the dataset, given a query image. Whenever a query image is provided, it is first preprocessed using the preprocessing method used in phase one. Then, features are extracted from this image using the trained autoencoder. Thus, we obtain the query feature vector. The distance between the query feature vector and each of the feature vectors stored in the database is calculated” (Section 17.2.1), and “a novel dataset named BRIDGE was introduced. It contains 13k unlabeled, unstructured, and complex floor plan images. All the images are web-scraped and compiled together” (Section 17.3.1).
The examiner further notes that the secondary reference of Deshpande teaches the concept of generating vectors (i.e. embeddings) of images of floorplans (i.e. examples of building plans) that are then stored in a database. The combination would result in the buildings of Kallman to have images of such floorplans that are vectorized and stored in its vector database(s) (Such as Milvus).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Deshpande’s would have allowed Kallman’s and Zhao’s to provide a method for avoiding the cumbersome process of manually searching through floorplans, as noted by Deshpande (Abstract).
Kallman, Zhao, and Deshpande do not explicitly teach:
K) wherein providing the information responsive to the query comprises: generating, using one or more machine learning (ML) systems, a summary of the information response to the query from the information responsive to the query; and
M) wherein the ML system is trained to generate responses to building information model queries.
Ingold, however, teaches “wherein providing the information responsive to the query comprises: generating, using one or more machine learning (ML) systems, a summary of the information response to the query from the information responsive to the query” as “This application claims priority to Provisional Patent Application No. 63/606,818entitled “Interactive Multi-Mode Human-Machine Interface for Enhanced Product Searches Using Large Language Models” filed on Ser. No. 12/0612,023 and incorporated herein in its entirety” (Paragraph 01), “Our invention introduces an innovative Human-Machine Interface (HMI) system that leverages a sophisticated network of large language models (LLMs), each enhanced by hardware GPU modules. This system is designed to revolutionize how users engage in product searches, particularly in complex and under-served markets like the semi-custom home industry” (Page 02 of 63/606818), “In the concluding phase, an LLM synthesizes the processed search findings into a succinct human-language summary. Concurrently, another LLM prepares follow-up questions and additional information, aiming to refine future system responses. These summaries and questions are communicated back to the user” (Page 03 of 63/606818), “An internal-processing LLM (115) examines the combined results (113) and summarizes them into concise human language to reduce the textual volume and cognitive load of information relayed to the user” (Page 05 of 63/606818), and “The summarized results, follow-up statements, and questions, if any, are combined and prepared for presentation (117) back to the user (100)” (Page 05 of 63/606818) and “wherein the ML system is trained to generate responses to building information model queries” as “This application claims priority to Provisional Patent Application No. 63/606,818entitled “Interactive Multi-Mode Human-Machine Interface for Enhanced Product Searches Using Large Language Models” filed on Ser. No. 12/0612,023 and incorporated herein in its entirety” (Paragraph 01), “Our invention introduces an innovative Human-Machine Interface (HMI) system that leverages a sophisticated network of large language models (LLMs), each enhanced by hardware GPU modules. This system is designed to revolutionize how users engage in product searches, particularly in complex and under-served markets like the semi-custom home industry” (Page 02 of 63/606818), “In the concluding phase, an LLM synthesizes the processed search findings into a succinct human-language summary. Concurrently, another LLM prepares follow-up questions and additional information, aiming to refine future system responses. These summaries and questions are communicated back to the user” (Page 03 of 63/606818), “The LLMs described herein may be implemented as multiple distinct models or as a single model provided with distinct contexts at run time. The diagram makes illustrations of these instances distinct to clarify the information flow. Without changing the substance of this invention, any of these models may be internal or external constructs of differing dimensionality as suited to the context and required processing power for the embodied domain” (Page 04 of 63/606818), “An internal-processing LLM (115) examines the combined results (113) and summarizes them into concise human language to reduce the textual volume and cognitive load of information relayed to the user” (Page 05 of 63/606818), and “The summarized results, follow-up statements, and questions, if any, are combined and prepared for presentation (117) back to the user (100)” (Page 05 of 63/606818).
The examiner further notes that although Kallman clearly processes real estate queries (amongst multiple different types of queries) and produces summaries of query results (See example in Figure 7), there is no explicit teaching of using a trained ML model to produce such summaries of query results. Nevertheless, the secondary reference of Ingold teaches the concept of an LLM (i.e. a trained ML model) that produces a displayed generates a summary from query results. The combination would result in the use of a trained LLM to produce the summaries of Kallman.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Ingold’s would have allowed Kallman’s, Zhao’s, and Deshpande’s to provide a method for enabling real-time refinement and expansion of real estate query results via a bi-directional interaction in order to reduce the load of information presented to a user, as noted by Ingold (Pages 01 and 05 of 63/606818).
Kallman, Zhao, Deshpande, and Ingold do not explicitly teach:
L) generating a response context from the summary of the information responsive to the query.
McElvain, however, teaches “generating a response context from the summary of the information responsive to the query” as “the contextually and grammatically correct answers may be identified, obtained and/or generated from a database of pre-generated summaries, which are herein referred to as headnotes. In a particular implementation, headnotes may refer to editorially created summaries of the law addressed in court opinions. As such, a conversationally fluid, contextually and grammatically correct answer to an input question may be provided as a short passage obtained from a headnote identified in accordance with aspects of the present disclosure. In some aspects, headnotes may be restricted to a single sentence” (Paragraph 84).
The examiner further notes that although Ingold clearly teaches LLMs that generate contextually appropriate summaries (See Pages 02, 03, and 05), there is no explicit teaching of generating a context from such summaries. Nevertheless, McElvain teaches the concept of generating answers (that includes context) from summaries. Moreover, the claimed response context is utterly undefined in the instant specification (See “generate an answer with context 232 which is responsive to the initial question 220. This answer with context 232 may then be provided to a user interface for providing to a user, or to any other intended target of the results from the question 220” (Paragraph 42)) and is thus interpreted in the broadest reasonable interpretation as simply an answer with context. Thus, the generated answers with context from McElvain teach the claimed response context in the broadest reasonable interpretation. The combination would result in the generation of context from the generated summaries of Ingold.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching McElvain’s would have allowed Kallman’s, Zhao’s, Deshpande’s, and Ingold’s to provide a method for generating contextually relevant answers, as noted by McElvain (Paragraph 05).
Regarding claims 2, 9, and 16, Kallman does not explicitly teach a method, non-transitory computer-readable medium, and system comprising:
A) wherein the query is a multi-modal query.
Zhao, however, teaches “wherein the query is a multi-modal query” as “the user can interact with the client application 110 to provide user input to, for example, type or verbally dictate a question associated with the video” (Paragraph 53).
The examiner further notes that the secondary reference of Zhao teaches the concept of multi-modal queries via written (i.e. textual) and verbal (i.e. audio) formats. The combination would result in expanding the type of inputs for the queries of Kallman.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Zhao’s would have allowed Kallman’s to provide a method for avoiding ambiguous responses to user queries, as noted by Zhao (Paragraph 4).
Regarding claims 3, 10, and 17, Kallman further teaches a method, non-transitory computer-readable medium, and system comprising:
A) wherein retrieving information responsive to the query from the building information model comprises using the information retrieved from the vector space to query into the vector database (Paragraphs 28, 48, 49, and 50).
The examiner notes that Kallman teaches “wherein retrieving information responsive to the query from the building information model comprises using the information retrieved from the vector space to query into the vector database” as “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “In a second phase, happening in parallel to the first phase, or occurring after the first phase, the query planner module 410 can determine query pathways to further enrich the query in semantics, context, timelines, and/or other attributes. In this manner, a more featured or feature-rich query can be queried against the various sources, such as the knowledge graph 406. The query and/or the root query can be run against the knowledge graph 406 to hydrate the structured query. “Hydrating” the query refers to querying the knowledge graph 406 with previously determined query labels to generate improved query labels. An augmented or hydrated structured query with improved query labels can be searched in the query sources (e.g., document storage 416, private indexes 418), or more efficiently in the first set of results” (Paragraph 48), “For example, a user query can be “Is there a build-up of tanks in the Eastern Ukraine?” The unstructured user query can be vague for a search system. For example, the text “tank” taken in isolation can refer to many types of tanks, such as propane tanks, irrigation tanks, and military, only one of which may be relevant to the intention of the user sending the query. In the first phase, the first set of results can be numerous, as the document storage 416 and private indexes 418 can be efficient in “recall,” but not efficient in “precision,” in matching the context of the query. In the second phase, the query can be hydrated with semantics, context, relationships, and timing information. The knowledge graph 406 can be used to enrich, hydrate, or augment the query. In the example above, the query includes a timeline of interest (e.g., “Is there . . . ” indicating “current,” or “now”), and a named entity (“Ukraine”). Furthermore, the knowledge graph 406 can include embeddings from data sources 426 related to an ongoing or current war in Ukraine. Consequently, the term “tank,” in the query likely refers to “military tank.” The hydrated query can be queried against the first set of results to return a more refined second set of results, better matching the context, semantics and the user intention behind the query. The second set of results can be stored in a results queue 436 and displayed to the user 102. In some embodiments, the hydrated query can also be queried against the previously queried sources, such as the document storage 416, the private indexes 418, and/or the vector embedding database/index 420” (Paragraph 49), and “The root query can be searched in a vector-space embedding database and/or index, where a vector embedding of the root query is searched in the vector-space embedding database and/or index. Milvus is one example of a vector-space database that can be searched” (Paragraph 50). The examiner further notes that information resultant from building-related user queries (See example of “how old is the roof at 123 Main St.?”) against embedding (i.e. vector) spaces are used to subsequently search databases (including vector databases) to retrieve information (See how an augmented query that is augmented via the initial information from the embedding search is then searched against databases).
Regarding claims 4, 11, and 18, Kallman does not explicitly teach a method, non-transitory computer-readable medium, and system comprising:
A) wherein generating the embedding in the vector space comprises processing the query, the query context, and the information from the building information model through one or more machine learning models.
Zhao, however, teaches “wherein generating the embedding in the vector space comprises processing the query, the query context, and the information from the building information model through one or more machine learning models” as “This disclosure describes one or more embodiments of a query-response system that utilizes a query-response-neural network for contextualizing and responding to a user question received during display or playback of a video segment, such as a screencast-tutorial segment. The query-response-neural network can include neural-network layers and mechanisms for generating representations of questions, transcript text, visual cues, and answer candidates” (Paragraph 21) and “the term “neural network” refers to a machine learning model that can be tuned (e.g., trained) based on inputs to approximate unknown functions. In particular, the term neural network can include a model of interconnected artificial neurons (e.g., organized in layers) that communicate and learn to approximate complex functions and generate outputs based on a plurality of inputs provided to the model. For instance, the term neural network includes one or more machine learning algorithms” (Paragraph 42).
The examiner further notes that although the primary reference of Kallman teaches the generation of vectors of queries and building information data, there is no explicit teaching of how such vectors are generated (i.e. via the use of a machine learning model). Nevertheless, the secondary reference of Zhao teaches the concept of using a machine learning model to generate query vectors, context vectors, and answer candidate vectors (which can be any type of data including the building information data of Kallman). The combination would result in using such a machine learning model to generate the vectors of Kallman.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Zhao’s would have allowed Kallman’s to provide a method for avoiding ambiguous responses to user queries, as noted by Zhao (Paragraph 4).
8. Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kallman et al. (U.S. PGPUB 2024/0419749) in view of Zhao et al. (U.S. PGPUB 2021/0248376), and further in view of Deshpande et al. (Article entitled “Learning Deep Representation Using a Fully Convolutional Autoencoder for Automated Floor Plan Image Retrieval”, dated 2023), and further in view of Ingold et al. (U.S. PGPUB 2025/0190425), and further in view of McElvain et al. (U.S. PGPUB 2019/0340172) as applied to claims 1-4, 8-11, and 15-18, and further in view of Hader et al. (U.S. PGPUB 2022/0051111).
9. Regarding claims 5, 12, and 19, Kallman, Zhao, Deshpande, Ingold, and McElvain do not explicitly teach a method, non-transitory computer-readable medium, and system comprising:
A) wherein the one or more machine learning models further generate the knowledge graph.
Hader, however, teaches “wherein the one or more machine learning models further generate a knowledge graph” as “the knowledge graph generation engine 136 can use one or more machine learning models to generate the knowledge graph based on the data in the discovery database 134” (Paragraph 24).
The examiner further notes that although the primary reference of Kallman clearly generates a knowledge graph via a core (See Paragraph 37), there is no explicit teaching that such a core is a machine learning model. Nevertheless, the secondary reference of Hader teaches the concept of using a machine learning model to generate a knowledge graph. The combination would result in Kallman using machine learning models to generate its knowledge graph.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Hader’s would have allowed Kallman’s, Zhao’s, Deshpande’s, Ingold’s, and McElvain’s to provide a method for providing advantages in building knowledge graphs directed towards structured, unstructured, images, and/or video data, as noted by Hader (Paragraph 24).
10. Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kallman et al. (U.S. PGPUB 2024/0419749) in view of Zhao et al. (U.S. PGPUB 2021/0248376), and further in view of Deshpande et al. (Article entitled “Learning Deep Representation Using a Fully Convolutional Autoencoder for Automated Floor Plan Image Retrieval”, dated 2023), and further in view of Ingold et al. (U.S. PGPUB 2025/0190425), and further in view of McElvain et al. (U.S. PGPUB 2019/0340172) as applied to claims 1-4, 8-11, and 15-18, and further in view of Hader et al. (U.S. PGPUB 2022/0051111) as applied to claims 5, 12, and 19, and further in view of Kurian et al. (U.S. PGPUB 2018/0040020).
11. Regarding claims 6, 13, and 20, Kallman, Zhao, Deshpande, Ingold, McElvain, and Hader do not explicitly teach:
A) wherein the query context further comprises user browsing data, previous user queries, and information responsive to the previous user queries.
Kurian, however, teaches “wherein the query context further comprises user browsing data, previous user queries, and information responsive to the previous user queries” as “Contextual Search information across one or more applications configured on computing device can be extracted from the system of the present invention in a search editor of one or more applications. It comprises of contextual information derived from current and historic information of search results across applications derived on the computing device and/or server, historic information of selection of search results, search results obtained among multiple search editors, recent trending search strings provided by the present invention, dynamic learning of context relation between word and phrase, dynamic learning of interaction between word frequency/phrase context, erroneous input, search context database on computing device and/or server, search context associations, ontological classification of search queries, language dictionary, adwords dictionary, user-defined dictionary, content of received message, previous text entered in any editor, phonetic input, language of input as dynamically deciphered or specified by user, voice input, emoticons input, relative keywords used in the search editor. The database can be any dynamic learning structure to hold information about search query associations, affinities, ontological classification, temporal and spatial insights, user profiling and search behaviour identified based on search input across one or more search applications or the applications having search field” (Paragraph 56).
The examiner further notes that the secondary reference of Kurian teaches the concept of contextual search information (i.e. query context data) including historic selection of search results (i.e. the claimed undefined user browsing data in the broadest reasonable interpretation), previous entered text & relative search keywords (i.e. examples of previous user queries), and historic information of search results (i.e. the claimed information response to previous user queries). The combination would result in expanding the query context data of Kallman to include such information.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Kurian’s would have allowed Kallman’s, Zhao’s, Deshpande’s, Ingold’s, McElvain’s, and Hader’s to provide a method for returning search results more quickly, as noted by Kurian (Paragraph 127).
Response to Arguments
12. Applicant's arguments filed on 01/13/2026 have been fully considered but they are not persuasive.
Applicants argue on Page 09 that “the amended language requires gathering the contextual data from the building information model. Kallman fails to teach this limitation. Rather, Kallman discloses that data visited or retrieved by a spider engine may be run through a knowledge graph to enrich the index. There is no teaching or suggestion that the knowledge graph itself is affected by the visited/retrieved data; rather, it is only the index that is enrichened. Thus, there is no teaching or suggestion in Kallman that the knowledge graph provides any contextual information from the building information model”. However, the examiner wishes to refer to Kallman which states “individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”” (Paragraph 28), “The enrichment and indexing pipeline 424 can run the data visited or retrieved by the spider engine 422 through the graph query clients 404 and the knowledge graph 406 to enrich the index with semantic, relationships, types, formats, contextual or any other enrichment data returned by the knowledge graph 406” (Paragraph 46), “the query planner module 410 can determine query pathways to further enrich the query in semantics, context, timelines, and/or other attributes. In this manner, a more featured or feature-rich query can be queried against the various sources, such as the knowledge graph 406. The query and/or the root query can be run against the knowledge graph 406 to hydrate the structured query” (Paragraph 48), “For example, a user query can be “Is there a build-up of tanks in the Eastern Ukraine?”…the query can be hydrated with semantics, context, relationships, and timing information. The knowledge graph 406 can be used to enrich, hydrate, or augment the query. In the example above, the query includes a timeline of interest (e.g., “Is there . . . ” indicating “current,” or “now”), and a named entity (“Ukraine”). Furthermore, the knowledge graph 406 can include embeddings from data sources 426 related to an ongoing or current war in Ukraine” (Paragraph 49), and The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field. A relationship builder 524 can traverse the subject feature graph 518 and the source feature graph 522 to detect and build relationships between these graphs, into the knowledge graph 510. In other words, the relationship builder 524 generates pairings and mappings between the query graphs (e.g., subject feature graph 518) and the source graphs (e.g., source feature graph 522). In some embodiments, the relationship builder 524 can be implemented with asynchronous analytics or other techniques. As an example, if a subject feature graph 518 encodes the physical dimension of a particular military tank, and a source feature graph 522 encodes the resolution of an EO sensor, the relationship builder 524 can create a pairing between the two as a structure in the knowledge graph 510” (Paragraphs 53-54). The examiner further notes that query context can be ascertained via a knowledge graph that houses data embeddings (which can be embeddings regarding building information). Specifically, Kallman teaches that searchable data also includes building information model(s) (See example query of “how old is the roof at 123 Main St.?”). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors). Thus, the building model context data from a knowledge graph housing building information model data is used to enrich a query (such as an example building information query of “how old is the roof at 123 Main St.?”).
Applicants argue on Page 09 that “the amended language requires that the knowledge graph store relationships between various data that comprise the building information model. Kallman is silent as to how the knowledge graph is constructed, let alone whether the knowledge graph store relationships between data that comprise the building information model”. However, the examiner wishes to refer to Kallman which states “In commercial applications, various entities can also use a robust geospatial online search system to look for answers to questions that relate to a location. For example, real-estate businesses can utilize a geospatial online search system to research queries that inform real estate investment or development activities. A sample query for a real estate development firm, for example, can be “What are undeveloped areas in the State of Vermont with commercial zoning allowance that are near residential apartment buildings?” Similarly, individuals or small businesses can also benefit from a robust geospatial online search system. A sample query for a renovation property investor can be “how old is the roof at 123 Main St.?”. FIG. 1 illustrates an environment 100 of a geospatial online search system 108 according to an embodiment. The user 102 can use a variety of computing devices 104 to access the system 108 via the Internet 106, pose a query and receive results” (Paragraphs 28-29), “The geospatial online search system 108 can include a core 312, which allows a user to search for data about any location, via a user interface element, such as the UI element 314. The core 312 can access several sources to build one or more knowledge graphs and indexes against which a user query can be executed. For example, the core 312 can interface with multiple data providers 322 via data crawlers 324 to build one or more knowledge graphs and/or index databases” (Paragraph 37), “For example, a user query can be “Is there a build-up of tanks in the Eastern Ukraine?”…the query can be hydrated with semantics, context, relationships, and timing information. The knowledge graph 406 can be used to enrich, hydrate, or augment the query. In the example above, the query includes a timeline of interest (e.g., “Is there . . . ” indicating “current,” or “now”), and a named entity (“Ukraine”). Furthermore, the knowledge graph 406 can include embeddings from data sources 426 related to an ongoing or current war in Ukraine” (Paragraph 49), “one subject feature graph 518 can be directed to a type of military tank and its various physical features and/or other characteristics. Various models 520 can be used to build one or more source feature graphs 522, directed to attributes and characteristics of the available sources of content for searching a query. As an example, a source feature graph 522 can encode attributes and characteristics of a type of remote sensor generating imagery data for an image database… The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field. A relationship builder 524 can traverse the subject feature graph 518 and the source feature graph 522 to detect and build relationships between these graphs, into the knowledge graph 510. In other words, the relationship builder 524 generates pairings and mappings between the query graphs (e.g., subject feature graph 518) and the source graphs (e.g., source feature graph 522). In some embodiments, the relationship builder 524 can be implemented with asynchronous analytics or other techniques. As an example, if a subject feature graph 518 encodes the physical dimension of a particular military tank, and a source feature graph 522 encodes the resolution of an EO sensor, the relationship builder 524 can create a pairing between the two as a structure in the knowledge graph 510” (Paragraphs 53-54). The examiner further notes that the system of Kallman includes a knowledge graph that stores relationships between various types of data (see example of tanks and sensors). Moreover, Kallman teaches that searchable data also includes building information model(s) (See example query of “how old is the roof at 123 Main St.?”). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors).
Applicants argue on Pages 09-10 that “Although the Office argues that "query context can be ascertained via a knowledge graph that houses data embeddings (which can be embeddings regarding building information)" (Office Action, p. 18, emphasis added), this is impermissible hindsight. Simply because a knowledge graph could contain information - indeed, a knowledge graph could be used to store a vast array of types of information - this does not mean that Kallman teaches, or that a person skilled in the art would understand, that the knowledge graph mentioned in Kallman specifically stores information about relationships between data that comprise a building information model. The mere fact that a knowledge graph could store information does not mean that a person skilled in the art would understand that it does, and does so in the context of a geospatial search”. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Rather, as explained above, Kallman teaches that searchable data also includes building information model(s) (See example query of “how old is the roof at 123 Main St.?”). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors). Thus, just like there is a knowledge graph housing relationships for tanks and sensors that is used for the example query of “Is there a build-up of tanks in the Eastern Ukraine?”, there is also a knowledge graph housing relationships between various data that comprises the building information model for the example building information model query of “how old is the roof at 123 Main St.?”) (See also “The subject feature graphs 518 and the source feature graphs 522 are provided as examples. More types of graphs encoding various attributes and characteristics of potential queries and search sources can also be added depending on the domain and search field” that does not limit the knowledge graph to tanks and sensors). Therefore, there was no impermissible use of hindsight as the applicants assert because Kallman itself does not limit the knowledge graph to tanks & sensors and includes example building information queries such as “how old is the roof at 123 Main St.?”.
Conclusion
13. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPUB 2024/0111794 issued to Osuala et al. on 04 April 2024. The subject matter disclosed therein is pertinent to that of claims 1-6, 8-13, and 15-20 (e.g., methods to perform querying via query embeddings).
U.S. Patent 8,732,219 issued to Ferries et al. on 14 October 2021. The subject matter disclosed therein is pertinent to that of claims 1-6, 8-13, and 15-20 (e.g., methods to perform querying against real property).
U.S. PGPUB 2025/0245262 issued to Harrison et al. on 31 July 2025. The subject matter disclosed therein is pertinent to that of claims 1-6, 8-13, and 15-20 (e.g., methods to perform querying against real property).
14. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contact Information
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mahesh Dwivedi whose telephone number is (571) 272-2731. The examiner can normally be reached on Monday to Friday 8:20 am – 4:40 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached (571) 272-4085. The fax number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Mahesh Dwivedi
Primary Examiner
Art Unit 2168
November 02, 2025
/MAHESH H DWIVEDI/Primary Examiner, Art Unit 2168