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 action is responsive to communication filed on 29 January 2026. Claims 1-14 and 21-25 are pending in the case. Claims 1, 7, 8, 14, 21, and 25 were amended. Claims 1, 8, and 21 are the independent claims. This action is non-final.
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 January 29th, 2026 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1-14, and 21-25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Potter (US 2018/0032571 A1) in view of Wan et al. (US 2022/0188104 A1).
Regarding claim 1, Potter teaches a method comprising:
providing a graphical user interface configured to allow for defining (i) a custom data object type used within a first microservice of a plurality of microservices and (ii) a first plurality of attributes for the custom data object type, wherein the custom data object type is not found in a plurality of base data object types being used within the plurality of microservices (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0036], [0057]-[0071], “a data object may represent any collection of information as part of a data object model. For example, a data object model representing information about a particular company may include data objects corresponding to employees, organizational units, inventory items, purchase orders, etc. A data object may be associated with a data object type (e.g., employee, inventory item, etc.) and may additionally include one or more data object properties (e.g., first name, cost, etc.). A data object type and any associated properties define a particular data object within a data object collection. … FIG. 2A illustrates an example graphical user interface display 200 enabling a user to create and modify a visual query. … graph node 204 represents a Person data object type as indicated by the graphic displayed in conjunction with the graph node. Similarly, graph node 206 represents a Payment data object type, and graph node 208 represents a Phone Call data object type. … a user may add one or more graph elements to a visual query graph by using any number of interface elements including a selection of a button displayed the graphical user interface, drop-down menu selections, clicking on the interface with an input device, input device gestures, etc. … interface element 214 illustrates an example graphical interface button enabling a user to add a new graph node. … if a user adds a new graph node that is connected by a graph edge to another graph node representing a Payment data object type, then the selectable data object types presented for the new graph node may include only those data object types that have an association with any Payment data object type in a data object collection under examination. … Data object types represented by graph nodes in a visual query may additionally comprise one or more data object properties. Each data object property may be associated with one or more property values. For example, a Person data object type represented by a graph node may include one or more data object properties (e.g., an age, gender, and occupation), and a user may specify values for the properties (e.g, “38,” “male,” and “insurance agent”).” [The data object types may correspond to employees, organizational units, inventory items, purchase orders, etc. The graphical user interface allows the user to define graph nodes that represents a person data object type (i.e., base data object type), payment or phone call data object type (i.e., custom object data type within a first data-related process), and properties (i.e., attributes) associated with the data object types. The data object types (i.e., custom object data type) for a newly add graph node may be defined through a graphical user interface.]);
However, Potter does not explicitly teach:
providing a graphical user interface configured to allow for defining (i) a custom data object type used within a first microservice of a plurality of microservices and (ii) a first plurality of attributes for the custom data object type, wherein the custom data object type is not found in a plurality of base data object types being used within the plurality of microservices;
Wan teaches:
providing a graphical user interface configured to allow for defining (i) a custom data object type used within a first microservice of a plurality of microservices and (ii) a first plurality of attributes for the custom data object type, wherein the custom data object type is not found in a plurality of base data object types being used within the plurality of microservices (see Wan, Paragraph [0022], “FIG. 1 shows a diagram 100 of a microservice architecture, according to an embodiment. In this example, the application includes a first microservice 110, a second microservice 120, a third microservice 130, a fourth microservice 140, a fifth microservice 150, and a sixth microservice 160. Each of these microservices may be an independent process.” [Figure 1 shows a first microservice of a plurality of microservices.]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Potter (teaching search around visual queries) in view of Wan (teaching microservices graph generation), and arrived at a method that incorporates microservices. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of improving software quality (see Wan, Paragraph [0023]). In addition, both the references (Potter and Wan) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as graphs. The close relation between both the references highly suggests an expectation of success.
The combination of Potter, and Wan further teaches:
receiving, by computing hardware, the custom data object type, the first plurality of attributes, and a relationship type that can exist between the custom data object type and a base data object type of the plurality of base data object types, wherein the base data object type is used within a second microservice of the plurality of microservices, wherein the first microservice and the second microservice are self-contained and autonomous processes (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0071], “a user creates a visual query as a graph by using one or more graphical user interfaces that enable the user to add, remove, and modify the particular graph nodes, graph edges, and properties included in the graph in order to specify a desired pattern of interest. … FIG. 2B additionally includes new graph edge 222 representing a data object link between graph node 208 and new graph node 218. As described above, graph edge 222 … may also be manually added by the user using any other interface element. … a user may specify one or more data object property values using an interface element similar to interface element 310” Also, see Wan, Paragraph [0022], “FIG. 1 shows a diagram 100 of a microservice architecture, according to an embodiment. In this example, the application includes a first microservice 110, a second microservice 120, a third microservice 130, a fourth microservice 140, a fifth microservice 150, and a sixth microservice 160. Each of these microservices may be an independent process.” [The graphical user interface allows the user to input data object types (i.e., custom and base data object types), graph edges (i.e., relationship type), and properties (i.e., attributes).]);
generating, by the computing hardware, a first data object type node and an edge in a graph data representation, wherein the graph data representation is maintained independent of the plurality of microservices, wherein the first data object type node represents the custom data object type and is associated with the first plurality of attributes and the edge represents the relationship type that can exist between the custom data object type used within the first microservice and the base data object type used within the second microservice and connects the first data object type node with a second data object type node representing the base data object type and wherein the edge further represents a relationship between the first microservice and the second microservice; and generating, by the computing hardware, a visual representation for display on the graphical user interface, wherein the visual representation comprises at least a portion of the graph data representation showing the first data object type node, the second data object type node, and the edge (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user creates a visual query as a graph by using one or more graphical user interfaces that enable the user to add, remove, and modify the particular graph nodes, graph edges, and properties included in the graph in order to specify a desired pattern of interest. … FIG. 2B additionally includes new graph edge 222 representing a data object link between graph node 208 and new graph node 218. As described above, graph edge 222 … may also be manually added by the user using any other interface element. … a user may specify one or more data object property values using an interface element similar to interface element 310” [Figures 2A, 2B, 3, 4, show a graphical user interface that displays the data object types (i.e., custom and base data object types), graph edges (i.e., relationship type), and property values (i.e., attribute values).] Also, see Wan, Paragraphs [0022], [0026]-[0027], [0047], “FIG. 1 shows a diagram 100 of a microservice architecture, according to an embodiment. In this example, the application includes a first microservice 110, a second microservice 120, a third microservice 130, a fourth microservice 140, a fifth microservice 150, and a sixth microservice 160. Each of these microservices may be an independent process. … The graph database may be used to store the microservices information, including the microservice applications and all the services provided. … FIG. 9 shows a graph 900 of method dependencies, according to an embodiment.” [Figure 9 shows microservices graph representation that includes relationships between different microservices. The graph database may be used to store the microservices information, which is separate from the microservices (i.e., wherein the graph data representation is maintained independent of the plurality of microservices).]).
Regarding claim 2, Potter in view of Wan teaches all the limitations of claim 1. Potter further teaches:
receiving data, originating from the graphical user interface, wherein the data comprises: a selection of the custom data object type, a first property defined for a first attribute of the first plurality of attributes, a selection of the base data object type, a second property defined for a second attribute of a second plurality of attributes for the base data object type, and a selection of the relationship type (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user creates a visual query as a graph by using one or more graphical user interfaces that enable the user to add, remove, and modify the particular graph nodes, graph edges, and properties included in the graph in order to specify a desired pattern of interest. … FIG. 2B additionally includes new graph edge 222 representing a data object link between graph node 208 and new graph node 218. As described above, graph edge 222 … may also be manually added by the user using any other interface element. … a user may specify one or more data object property values using an interface element similar to interface element 310” [The graphical user interface allows the user to input data object types (i.e., custom and base data object types), graph edges (i.e., relationship type), and properties (i.e., attributes).]);
generating, by the computing hardware, a first instance node, a second instance node, and an instance edge in a second graph data representation, wherein the first instance node represents an instance of the custom data object type and is associated with the first property, the second instance node represents an instance of the base data object type and is associated with the second property, and the instance edge represents the relationship type existing between the instance of the custom data object type and the instance of the base data object type; and generating, by the computing hardware, a second visual representation for display on the graphical user interface, wherein the second visual representation comprises at least a portion of the second graph data representation showing the first instance node, the second instance node, and the instance edge (see Potter, Paragraph [0048]-[0053], “Each result returned by a search around is referred to herein as an “instance,” and includes a collection of data objects and data object links that satisfy the search conditions at each stage in the query template. Thus, the result of a search around on a particular data object collection is the union of all instances of a pattern specified by the query template. In an embodiment, each search around result instance may be represented visually by a graph that displays the particular data objects and data object links for the particular instance arranged according to the specified pattern.” [An instance is returned, and visualized for the data object types (i.e., custom and base data object types), graph edges (i.e., relationship type), and properties (i.e., attributes).]).
Regarding claim 3, Potter in view of Wan teaches all the limitations of claim 2. Potter further teaches:
providing, by the computing hardware, a third visual representation for display on the graphical user interface, wherein the third visual representation comprises at least a portion of the graph data representation showing the first data object type node as selectable, the second data object type node as selectable, and the edge as selectable (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user creates a visual query as a graph by using one or more graphical user interfaces that enable the user to add, remove, and modify the particular graph nodes, graph edges, and properties included in the graph in order to specify a desired pattern of interest. … FIG. 2B additionally includes new graph edge 222 representing a data object link between graph node 208 and new graph node 218. As described above, graph edge 222 … may also be manually added by the user using any other interface element. … a user may specify one or more data object property values using an interface element similar to interface element 310” [Figures 2A, 2B, 3, 4, show a graphical user interface that displays selectable data object types, and edges.]);
receiving, by the computing hardware, data originating from the graphical user interface, wherein the data comprises: a selection of the first data object type node, the first property defined for the first attribute, a selection of the second data object type node, a selection of the second attribute, and a selection of the edge; responsive to receiving the data, conducting, by the computing hardware, a traversal of the second graph data representation to retrieve the second property, wherein the traversal of the second graph data representation comprises: identifying the first instance node in the second graph data representation based on the first property, traversing the instance edge in the second graph data representation based on the edge to identify the second instance node, and identifying the second property; and providing, by the computing hardware, the second property for display in the graphical user interface (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user creates a visual query as a graph by using one or more graphical user interfaces that enable the user to add, remove, and modify the particular graph nodes, graph edges, and properties included in the graph in order to specify a desired pattern of interest. … FIG. 2B additionally includes new graph edge 222 representing a data object link between graph node 208 and new graph node 218. As described above, graph edge 222 … may also be manually added by the user using any other interface element. … a user may specify one or more data object property values using an interface element similar to interface element 310” [The graphical user interface allows the user to input data object types (i.e., custom and base data object types), graph edges (i.e., relationship type), and properties (i.e., attributes).]).
Regarding claim 4, Potter in view of Wan teaches all the limitations of claim 1. Potter further teaches:
populating, by the computing hardware, at least one placeholder field in a data schema for the first microservice with data identifying the custom data object type and the first plurality of attributes (see Potter, Paragraph [0099]-[0101], “a user may specify one or more placeholder graph elements in a visual query, referred to herein as blank graph elements.” Also, see Wan, Paragraph [0022], “FIG. 1 shows a diagram 100 of a microservice architecture, according to an embodiment. In this example, the application includes a first microservice 110, a second microservice 120, a third microservice 130, a fourth microservice 140, a fifth microservice 150, and a sixth microservice 160. Each of these microservices may be an independent process.” [The placeholder graph elements (i.e., placeholder field) for the data object types (i.e., custom data object types), and properties (i.e., attributes) may be specified (i.e., populated).]).
Regarding claim 5, Potter in view of Wan teaches all the limitations of claim 1. Potter further teaches:
providing a second graphical user interface configured to allow for defining (i) a custom relationship type and (ii) a third plurality of attributes for the custom relationship type; receiving, by the computing hardware, the custom relationship type, the third plurality of attributes, and an indication that the custom relationship type can exist between the custom data object type and the base data object type; generating, by the computing hardware, a second edge in the graph data representation, wherein the second edge represents the custom relationship type that can exist between the custom data object type and the base data object type, connects the first data object type node with the second data object type node, and is associated with the third plurality of attributes; and providing, by the computing hardware, the second edge for display in the visual representation (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “FIG. 4 illustrates an example graphical user interface 400 including interface elements enabling specification of a data object link type to be associated with a graph edge. Graph 402 includes graph node 404 and graph node 406, each representing a Person data object type. Graph node 404 and graph node 406 are connected by graph edge 408. In an embodiment, in response to a user selecting graph edge 408, a user may be presented with interface element 410 enabling the user to specify a data object link type to be associated with graph edge 408. A user may select a particular link type by selecting a link type option presented in a drop-down list, by searching for a link type in a search box, or any other similar means of selecting a desired link type.” [Figure 4 displays a graphical user interface that allows the user to specify a data object link type (i.e., custom relationship type and third plurality of attributes), which connects the data object types (i.e., custom and base data object types)).]).
Regarding claim 6, Potter in view of Wan teaches all the limitations of claim 1. Wan further teaches:
wherein the custom data object type represents a first particular processing activity defined within the first microservice and the base data object type represents second particular processing activity defined within the second microservice, and the edge represents a common data element between the custom data object type (see Wan, Paragraph [0047], “FIG. 9 shows a graph 900 of method dependencies, according to an embodiment.” [Figure 9 shows microservices graph representation that includes relationships between different microservices.]).
Regarding claim 7, Potter in view of Wan teaches all the limitations of claim 1. Wan further teaches:
wherein the plurality of microservices supports an enterprise software application, and wherein the independently maintained graph data representation is configured to allow the plurality of microservices to remain independent of each other while persisting relationships between data objects across the plurality of microservices (see Wan, Paragraph [0022]-[0023], [0026]-[0027], “FIG. 1 shows a diagram 100 of a microservice architecture, according to an embodiment. In this example, the application includes a first microservice 110, a second microservice 120, a third microservice 130, a fourth microservice 140, a fifth microservice 150, and a sixth microservice 160. Each of these microservices may be an independent process. … implementing the microservice architecture in designing a software application may enable smaller teams of specialized software developers to focus on a specific set of related services, thereby improving software quality. … The graph database may be used to store the microservices information, including the microservice applications and all the services provided.” [The microservices architecture is implemented in designing a software application (i.e., enterprise software application). The graph database may be used to store the microservices information, which is separate from the microservices (i.e., wherein the graph data representation is maintained independent of the plurality of microservices).]).
Regarding claims 8-14, 21, and 25, Potter in view of Wan teaches all of the elements of claims 1-7 in method form. Therefore, the supporting rationale of the rejection to claims 1-7 applies equally as well to those elements of claims 8-14, 21, and 25.
Regarding claim 22, Potter in view of Wan teaches all the limitations of claim 21. Potter further teaches:
wherein the portion of the schema graph representation is based on a particular workflow (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user may select a user interface option indicating the creation of a new graph, resulting in the display of a graphical user interface without pre-existing graph elements on the display. In another embodiment, a user may identify a pre-existing graph pattern generated as a result of another search around or other system operation. For example, a user may select a graph or a portion of a graph displayed as search around result instance generated by the execution of another visual query. The selected graph or graph portion may serve as a starting point for the design of a new visual query.” [The graphical user interface allows the user to create a new graph (i.e., particular workflow).]).
Regarding claim 23, Potter in view of Wan teaches all the limitations of claim 22. Potter further teaches:
wherein the graphical user interface further displays a plurality of workflows, and the method further comprises receiving a selection of the particular workflow (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user may select a user interface option indicating the creation of a new graph, resulting in the display of a graphical user interface without pre-existing graph elements on the display. In another embodiment, a user may identify a pre-existing graph pattern generated as a result of another search around or other system operation. For example, a user may select a graph or a portion of a graph displayed as search around result instance generated by the execution of another visual query. The selected graph or graph portion may serve as a starting point for the design of a new visual query.” [The graphical user interface allows the user to create a new graph (i.e., particular workflow) and choose (i.e., select) whether to use a previous graph or start a new graph.]).
Regarding claim 24, Potter in view of Wan teaches all the limitations of claim 22. Potter further teaches:
wherein at least one of the plurality of data object types or the plurality of relationship type edges is based on the particular workflow (see Potter, Figures 2A, 2B, 3, 4, Paragraphs [0057]-[0079], “a user may select a user interface option indicating the creation of a new graph, resulting in the display of a graphical user interface without pre-existing graph elements on the display. In another embodiment, a user may identify a pre-existing graph pattern generated as a result of another search around or other system operation. For example, a user may select a graph or a portion of a graph displayed as search around result instance generated by the execution of another visual query. The selected graph or graph portion may serve as a starting point for the design of a new visual query.” [The graphical user interface allows the user to create a new graph (i.e., particular workflow), in which the user can input the data object types and edges.]).
Response to Arguments
Applicant’s Arguments, filed January 29th, 2026 have been fully considered, but are not persuasive.
Applicant argues on pages 13-14 of Applicant's Remarks that the cited references do not teach or suggest “maintaining a graph data representation independently of a plurality of microservices.” The Examiner respectfully disagrees.
Wan discloses in paragraphs [0026]-[0027], “The graph database may be used to store the microservices information, including the microservice applications and all the services provided. … In order to store the microservice information in the graph database, a computer system must obtain the source code for the software application including the source code for each of the microservices of the software application. Then the system may parse the microservices application's code and extract application data, method data, and application programming interface (API) end point data. The parsed information may then be stored into a graph database as node properties and edge relationships.” As shown, the microservices information is extracted in order to store the information in a graph database, therefore, the graph database is separate from the microservices, which indicates the graph database is maintained independently of a plurality of microservices.
Applicant argues on pages 15-16 of Applicant's Remarks that the cited references do not teach or suggest “providing, by a computing hardware, a graphical user interface for display on a computing device, wherein the graphical user interface displays a visual representation of at least a portion of a schema graph representation, wherein the schema graph representation is maintained independently of the plurality of microservices.” The Examiner respectfully disagrees.
As mentioned above, Wan discloses storing microservices information in a graph database that is independent from the microservices. Accordingly, Wan discloses in paragraph [0028], “In some embodiments of the graph database, the graph represented by the graph database is a set of vertices (also called “nodes”) and a set of edges. Each edge connects two vertices. One vertex may be denoted as the source and the other as the target. Edges may be directed. Any number of edges may connect the same two vertices. Vertices and edges can have an arbitrary number of attributes. An attribute consists of a name that is associated with a data type and a value.” As shown, the graph database is represented by vertices, edges, and attributes, which is a schema graph representation because it shows how the information is stored and organized.
Applicant argues on pages 17-18 of Applicant's Remarks that there is no suggestion or motivation to combine the cited references. The Examiner respectfully disagrees.
Potter discloses in paragraph [0002], “The present disclosure generally relates to the techniques for exploring large data sets using visual queries,” and paragraph [0038], “a data analysis system uses one or more graphical user interfaces comprising various interface elements that enable users to create visual queries as graphs that represent a data object pattern. The system may transform the graph into a query template based at least on the one or more graph nodes and one or more graph edges included in the graph. A query engine may execute a query template to search a data object collection for result instances corresponding to the specified pattern.” As shown, Potter discloses a technique that involves graph searching.
Accordingly, Wan discloses in paragraph [0026], “The graph database may be used to store the microservices information, including the microservice applications and all the services provided. Features and advantages of this technique is that the microservice information may be easily queried or searched in order to find out information that may be useful for developers of the microservices application.” As shown, Wan also teaches searching graph information.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wan into Potter for the purposes of easily querying or searching information (see Wan, Paragraph [0026]). In addition, both the references (Potter and Wan) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as graphs. The close relation between both the references highly suggests an expectation of success.
For the above reasons, it is believed that the rejections should be sustained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUSAM TURKI SAMARA whose telephone number is (571)272-6803. The examiner can normally be reached on Monday - Thursday, Alternate Fridays.
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, Apu Mofiz can be reached on (571)-272-4080. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUSAM TURKI SAMARA/
Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161