DETAILED ACTION
This action is responsive to application filed on August 18, 2025.
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 .
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated August 18, 2025 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Claim Objections
Claim 18 is objected to because of the following informalities:
In claim 18, line 4 “into a data flow structure” should read “into the data flow structure”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6-9 and 14 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites “querying the initial property graph”. There is insufficient antecedent basis for this limitation in the claim. It is unclear which property graph is being referenced. For examination purposes, “the initial property graph” is interpreted as “an initial property graph”. Dependent claims 7-9 are also rejected for depending on claim 6.
Claim 14 recites “ based on the distributed storage node”. Claim 13, from which claim 14 depends, introduces “a distributed graph storage node”. There is insufficient antecedent basis for “the distributed storage node” and it is unclear whether the same node is intended. For examination purposes, it is interpreted as the distributed graph storage node of claim 13.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 6-7, 9-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Jong (US Patent Application Publication No. US 20210191932 A1), in view of Roth (US Patent Application Publication No. US 20190354526 A1), in view of Chen (US Patent Application Publication No. US 20240176792 A1).
Regarding claim 1, Jong teaches a graph query method, applied to a client, and comprising: parsing a sub-graph query statement sent by a user for an initial property graph, and generating a sub-graph structure corresponding to the sub-graph query statement; (See Jong [0030-0032, 0049] “Graph database access server 112 [e.g. client] is configured to provide access to graph database 110 [e.g. initial property graph], e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… graph database access server 112 include a query parser 202 configured to receive a query [e.g. sub-graph query statement] via a communication interface, e.g., from a client… and transform the query into an internal representation of the query [e.g. generating a sub-graph structure]… a query expressed in a graph database query language, such as Cypher, is received and parsed [e.g. parsing a sub-graph query statement sent by a user for an initial property graph].” See also Jong [0025-0026] “The query planner utilizes the cardinality estimator as part of the overall planning process, mixing in cardinality estimates for paths with other metadata like the cost of executing an operator… to determine how to execute a query from a user most effectively (lowest computational cost) given the current state of the underlying graph data… Path patterns—(:A)-[:X]->(:B)<-[:Y]-(:C) [e.g. generating a sub-graph structure corresponding to the sub-graph query statement]. Matches against nodes and relationships in a graph database”)
determining a target sub-graph query execution policy in a preset calculation manner based on sub-graph statistical information and the sub-graph structure, wherein the sub-graph statistical information is obtained from a graph data structure constructed based on a target property graph; (See Jong [0030-0032] “Graph database access server 112 is configured to provide access to graph database 110 [e.g. target property graph], e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… Query planner module 204 obtains an estimated cardinality from a cardinality estimation subsystem 206 and an operator cost model 208 [e.g. a preset calculation manner] to determine a best query plan [e.g. determining a target sub-graph query execution policy] to execute the query, e.g., a query plan determined within a prescribed time to be a lowest cost plan” See also Jong [0018-0021] “the term “bi-gram” refers to a path pattern that includes a node having a first relationship with a first node and a second relationship with a second node… graph metadata and statistics [e.g. sub-graph statistical information] such as degree, span, and so on… which are stored alongside the graph in the database [e.g. a graph data structure constructed based on a target property graph], are used in various embodiments to estimate cardinality.” See also Jong [0053-0054] “In order to support bi-gram estimation… metadata stores are added into the statistics database: TWO_GRAM_INCOMING_OUTGOING_COUNT (X, A, Y) Stores the count of the pattern ( . . . )-[:X]->(:A)-[:Y]->( . . . )”
Examiner notes that claim 1 does not require the “target property graph” to be a different graph from the “initial property graph”, thus, the graph of database 110 satisfies both recitations.)
encoding the target sub-graph query execution policy into a data flow structure, and sending the data flow structure to a service end; and (Jong [0032] teaches a query parser 202 that transform the query into an internal representation of the query, the query planner module 204 determine the query plan and a runtime 210 executes the plan at the same access system.)
Jong does not explicitly teach encoding the selected plan into a data flow structure that is sent to a separate service for execution.
However, Roth teaches encoding the target sub-graph query execution policy into a data flow structure, and sending the data flow structure to a service end in more details. (See Roth [0019, 0043-0044, 0063] “the system generates a query plan comprising a plurality of operators. The system determines an order for the plurality of operators. In an embodiment, the order is such that if an operator requires data generated by another operator, then the other operator is ordered before the operator in the query plan [e.g. encoding the policy into a data flow structure]… a query plan defines a list of operators that each perform an operation on the graph… and an order for performing the operators [e.g. encoding the target sub-graph query execution policy into a data flow structure]. Additionally, the query plan may indicate one or more particular partitions and/or computers on which to perform the operator [e.g. sending the data flow structure to the service end]… the system may determine, based on the graph partition loaded into the plurality of computers, which computer(s) should perform each operator… Each computer of the plurality of computers [e.g. the service end] performs one or more operators assigned to the computer. [Thus, Roth’s plan is as an ordered structure of operations in which each operator’s output data feeds subsequent operators (i.e. the plan is encoded as a data flow structure), and that operator structure is assigned/sent to the computers of the distributed graph data engine (e.g. service end) for execution]”)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to execute Jong’s statistics-optimized query plan on Roth’s distributed operator-based engine, since Roth [0004] expressly teaches that “one of the key challenges in graph pattern matching is to process increasingly large graphs that often do not fit in the memory of a single machine”, and Jong’s planner [Jong 0032] yields the “lowest cost plan”.
As both represent known techniques for processing graph pattern queries on a property graph, the combination merely applies each according to its established function, yielding predictable results of statistically optimized distributed graph query execution.
Jong further in view of Roth, [hereinafter Jong-Roth] additionally teach receiving a target sub-graph returned by the service end after the service end performs querying in the initial property graph based on the data flow structure, and returning the target sub-graph to the user. (Roth teaches the service end performing the query on the property graph per the operator (data flow) structure and producing the matched sub-graph. See Roth [0050-0051, 0061] “The query plan operators traverse the distributed graph and match graph data [e.g. the service end performs querying in the initial property graph based on the data flow structure]… A neighbor match operator determines which pairs of vertices and edges match a search pattern… The final operator produces any results [e.g. returning the target sub-graph] that comprise the solution set of a query. [Thus, the set of vertices/edges matching the pattern is the target sub-graph]”
Jong teaches client receiving and returning results. See Jeong [0049] “query results are received and returned, e.g., to a client from which the query was received [i.e. returning the target sub-graph to the user].”)
Jong-Roth lacks details on the distributed servers returning the result set to the client, which then outputs it to the requesting user device.
However Chen Fig. 3, [0022, 0040-0041] teaches “The user computing device may provide a query 175 to the query processing engine 110, and the query processing engine 110 may return a query response 195 [e.g. returned target sub-graph] to the user computing device 130… the server 220 sends the gathered data to the compute node 210 [e.g. receives the result from the service end] for computation of the response to the query 175… the compute node 210 analyzes the data received from the server 220 and generates and outputs a response to the query… provided to a user computing device”)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Jong-Roth system with Chen’s ([0022], Fig. 3 step 370) system in which the processing engine may return a query response to the user computing device after the servers holding the distributed graph send the gathered data to the compute node, since Jong’s access server 112 must receive the matched results from Roth’s distributed execution computers in order to return them to the querying user (Jong 0049).
As all three references describe known techniques for processing graph queries against a property graph, the combination merely applies Chen’s conventional result return flow according to its established function, yielding predictable results of delivering the matched sub-graph to the requesting user.
Regarding claim 2, Jong-Roth further in view of Chen, [hereinafter Jong-Roth-Chen] teaches all limitations and motivations of claim 1, wherein before determining the target sub-graph query execution policy in the preset calculation manner based on the sub-graph statistical information and the sub-graph structure, the graph query method further comprises: receiving the target property graph sent by the service end, and determining the sub-graph statistical information in the target property graph; and (Jong [0068] teaches determining the sub-graph statistical information in the target property graph by traversal: “all the relationships in the graph [i.e. in the target property graph] are traversed again. For every relationship encountered, a cache lookup occurs… the types of the adjacent relationships and the label(s) of the common node are determined. This constitutes a bi-gram which is stored for later processing [Thus, Jong performs the statistics constructions ahead of any planning, as the planner selects the lowest-cost plan using the statistics]” See also Roth [0025] “ computers 102-106 have access to graph 120. Graph 120 may be stored in a file, database, or other shared data store. [e.g. stored at the service end]” See also Chen [0026, 0041] “A graph database 180 is stored distributively among the servers 120… the server 220 sends the gathered data to the compute node 210 for computation of the response to the query 175.” Thus, Chen the servers gather the requested data and send the gathered data [e.g. the target property graph sent by the service end] to the compute node [thus, received] (Chen Fig. 3, step 370).)
constructing the graph data structure in a form of the target property graph based on the sub-graph statistical information, and storing the sub-graph statistical information in the graph data structure. (See Jong [0021, 0037-0046, 0054-0055] “graph metadata and statistics such as degree, span, and so… are stored alongside the graph in the database [i.e. the structure is in a form of the target property graph]… Statistics 218: A store of graph metadata which is kept strictly up to date with the underlying graph. In various embodiments, statistics maintained include… Bi-gram counts… metadata stores are added into the statistics database [e.g. constructing the graph data structure based on statistics]… Stores the count of the pattern [Thus, the counts store is constructed within/alongside the property-graph database (i.e. a graph data structure in the form of the target property graph) based on the determined pattern statistics and the statistics are stored in it.]”)
Regarding claim 3, Jong-Roth-Chen teaches all limitations and motivations of claim 1, wherein parsing the sub-graph query statement sent by the user for the initial property graph, and generating the sub-graph structure corresponding to the sub-graph query statement comprises: receiving the sub-graph query statement sent by the user, and parsing the sub-graph query statement; and when a parsing result satisfies a preset query condition, generating the sub-graph structure corresponding to the sub-graph query statement; (See Jong [0030-0032, 0049] “Graph database access server 112 is configured to provide access to graph database 110, e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… graph database access server 112 include a query parser 202 configured to receive a query via a communication interface, e.g., from a client… a query expressed in a graph database query language, such as Cypher, is received and parsed [e.g. receiving the sub-graph query statement sent by the user, and parsing the sub-graph query statement].” See also Jong [0034] “Query parser 202: Accepts the client's query as input and turns its textual query representation into a logical representation [Thus, satisfies a preset query condition] suitable for planning and optimization. [Thus, when the statement conforms to the grammar, the parsing results satisfies the preset condition, the sub-graph structure is generated]”
or when the parsing result does not satisfy the preset query condition, returning a preset query result to the user. (This sub-limitation is contingent on the alternative format that is mutually exclusive with the condition of sub-limitation (“when a parsing result satisfies a preset query condition, generating the sub-graph structure corresponding to the sub-graph query statement”). Under MPEP 2111.01(II) and Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016), in a method claim, contingent steps that are not triggered by the recited condition precedent are given no patentable weight in the broadest reasonable interpretation. Because Examiner has shown that the prior art teaches the method as performed under the sub-limitation (“ when a parsing result satisfies a preset query condition, generating the sub-graph structure corresponding to the sub-graph query statement”), the sub-limitation (“when the parsing result does not satisfy the preset query condition, returning a preset query result to the user”) need not be separately mapped to the prior art.)
Regarding claim 6, the claim recites the service end counterpart of the client side method of claim 1, the same client/service end interaction addressed at claim 1, viewed from the service end. Jong-Roth-Chen combination set forth at claim 1, and the supporting rationale for combining Roth and Chen, apply equally to claim 6, since the deficiencies these references cure (e.g. operator based distribution of the plan, distributed execution, and return of results, are the operations claim 6 recites from the service end perspective. Each limitation is addressed below.
receiving a data flow structure sent by a client, and sending the data flow structure to a target execution node of a distributed computing cluster, wherein the data flow structure is obtained through processing, by the client, a received sub-graph query statement; (Jong [0032] teaches that the plan comes from the access server 112 (e.g. client), which “transform the query into an internal representation” and determines the plan. See also Roth [0018, 0043, 0063] “a graph is partitioned among a plurality of computers executing the graph querying engine [e.g. the service end]… the query plan may indicate one or more particular partitions and/or computers on which to perform the operator [i.e. sending the data flow structure to a target execution node of a distributed computing cluster]… Each computer of the plurality of computers [e.g. each target execution node of the distributed computing cluster] performs one or more operators assigned to the computer.”)
obtaining the target sub-graph determined through performing, by the target execution node, querying in the initial property graph based on the decoding result obtained through decoding, by the target execution node, the data flow structure, and (See Roth [0061] “ the system executes the query by executing the plurality of operators specified by the query plan. During query execution, the system applies each operator of the query plan to the graph in the order specified by the query plan [i.e. each execution node interprets (e.g. decodes) the received operator specification and performs the specified querying based on that decoding result]… The final operator produces any results that comprise the solution set of a query [e.g. the target sub-graph].” See also Roth [0050] “The query plan operators traverse the distributed graph and match graph data [i.e. querying in the initial property graph]”)
returning the target sub-graph to the client. (See Chen [0041, 0022] “ the server 220 sends the gathered data to the compute node 210 [i.e. returning the results to the client]… the query processing engine 110 may return a query response 195 to the user computing device 130.”)
Regarding claim 7, Jong-Roth-Chen teaches all limitations and motivations of claim 6, wherein before receiving the data flow structure sent by the client, the graph query method further comprises: determining the initial property graph, splitting the initial property graph according to a preset splitting policy, and respectively storing, in the target execution node of the distributed computing cluster, split initial property graphs. (See Roth [0028-0029] “Prior to performing any analytics or queries, the system loads one or more graphs into memory [i.e. determining the initial property graph]… The graph data is partitioned across multiple computers [i.e. splitting and respectively storing the splits in the execution nodes] … any partitioning method may be used to divide the plurality of edges… and vertices… among the plurality of computers [e.g. the partitioning method applies the preset splitting policy]” See also Roth [0030-0032] further discloses a predetermined partitioning rule where vertices determined to be high degree exceeding a threshold are statically replicated across partitions as ghost vertices during the split [e.g. preset splitting policy]“)
Regarding claim 9, Jong-Roth-Chen teaches all limitations and motivations of claim 7, wherein decoding the data flow structure based on the target execution node, obtaining the target sub-graph determined through performing, by the target execution node, querying in the initial property graph based on the decoding result comprises: decoding the data flow structure based on the target execution node, and (See Roth [0063, 0061] “Each computer of the plurality of computers performs one or more operators assigned to the computer [i.e. each target execution node processes (e.g. decodes) the portion of the data flow structure assigned to it in order to determine and carry out the specified operations]… the system applies each operator of the query plan to the graph in the order specified by the query plan [i.e. execution proceeds according to what is read out (e.g. decoded) from the plan].”)
obtaining the target sub-graph determined through performing, by the target execution node, querying in a split initial property graph corresponding to the decoding result. (See Roth [0018, 0063], claim 1 “The partitions… are loaded in memory of the plurality of computers… each computer of the plurality of computers performs one or more operators assigned to the computer… that target the respective graph portion loaded into the memory of the computer [i.e. the querying decoded from the data flow structure is performed in the split graph corresponding to it (e.g. the partition at the node to which the operator was assigned)].” See also Roth [0061] “The final operator produces any results that comprise the solution set of a query. [i.e. obtaining the target sub-graph]”)
Regarding claim 10, the claim recites as a single method, the client side steps of claim 1 and the service end steps of claim 6, the Jong-Roth-Chen combination teaches all such elements as set forth in claims 1 and 6, and the supporting rationale of those rejections including the motivations for combining Roth and Chen applies equally to the corresponding elements of claim 10.
Jong-Roth-Chen teaches graph query method, applied to a graph query system, wherein the graph query system comprises a client and a service end, and the method comprises: the client parsing a sub-graph query statement sent by a user for an initial property graph, and generating a sub-graph structure corresponding to the sub-graph query statement; (See Jong [0030-0032, 0049] “Graph database access server 112 [e.g. client] is configured to provide access to graph database 110 [e.g. initial property graph], e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… graph database access server 112 include a query parser 202 configured to receive a query [e.g. sub-graph query statement] via a communication interface, e.g., from a client… and transform the query into an internal representation of the query [e.g. generating a sub-graph structure]… a query expressed in a graph database query language, such as Cypher, is received and parsed [e.g. parsing a sub-graph query statement sent by a user for an initial property graph].” See also Jong [0025-0026] “The query planner utilizes the cardinality estimator as part of the overall planning process, mixing in cardinality estimates for paths with other metadata like the cost of executing an operator… to determine how to execute a query from a user most effectively (lowest computational cost) given the current state of the underlying graph data… Path patterns—(:A)-[:X]->(:B)<-[:Y]-(:C) [e.g. generating a sub-graph structure corresponding to the sub-graph query statement]. Matches against nodes and relationships in a graph database [Thus, the parser’s internal representation (:A)-[:X]->(:B) – is the generated sub-graph structure corresponding to the statement]”)
determining a target sub-graph query execution policy in a preset calculation manner based on sub-graph statistical information and the sub-graph structure, wherein the sub-graph statistical information is obtained from a graph data structure constructed based on a target property graph; (See Jong [0030-0032] “Graph database access server 112 is configured to provide access to graph database 110 [e.g. target property graph], e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… Query planner module 204 obtains an estimated cardinality from a cardinality estimation subsystem 206 and an operator cost model 208 [e.g. a preset calculation manner] to determine a best query plan [e.g. determining a target sub-graph query execution policy] to execute the query, e.g., a query plan determined within a prescribed time to be a lowest cost plan” See also Jong [0018-0021] “the term “bi-gram” refers to a path pattern that includes a node having a first relationship with a first node and a second relationship with a second node… graph metadata and statistics [e.g. sub-graph statistical information] such as degree, span, and so on… which are stored alongside the graph in the database [e.g. a graph data structure constructed based on a target property graph], are used in various embodiments to estimate cardinality.” See also Jong [0053-0054] “In order to support bi-gram estimation… metadata stores are added into the statistics database: TWO_GRAM_INCOMING_OUTGOING_COUNT (X, A, Y) Stores the count of the pattern ( . . . )-[:X]->(:A)-[:Y]->( . . . )”)
and encoding the target sub-graph query execution policy into a data flow structure, and sending the data flow structure to the service end; (See Roth [0019, 0043-0044, 0063] “the system generates a query plan comprising a plurality of operators. The system determines an order for the plurality of operators. In an embodiment, the order is such that if an operator requires data generated by another operator, then the other operator is ordered before the operator in the query plan [e.g. encoding the policy into a data flow structure]… a query plan defines a list of operators that each perform an operation on the graph… and an order for performing the operators [e.g. encoding the target sub-graph query execution policy into a data flow structure]. Additionally, the query plan may indicate one or more particular partitions and/or computers on which to perform the operator [e.g. sending the data flow structure to the service end]… the system may determine, based on the graph partition loaded into the plurality of computers, which computer(s) should perform each operator… Each computer of the plurality of computers [e.g. the service end] performs one or more operators assigned to the computer. [Thus, Roth’s plan is as an ordered structure of operations in which each operator’s output data feeds subsequent operators (i.e. the plan is encoded as a data flow structure), and that operator structure is assigned/sent to the computers of the distributed graph data engine (e.g. service end) for execution]”)
the service end receiving the data flow structure sent by the client, and sending the data flow structure to a target execution node of a distributed computing cluster; and (See Roth [0018, 0043, 0063] “a graph is partitioned among a plurality of computers executing the graph querying engine [e.g. the service end]… the query plan may indicate one or more particular partitions and/or computers on which to perform the operator [Thus, the received plan (e.g. data flow structure) is directed the target execution node of a distributed computing cluster]… Each computer of the plurality of computers [e.g. each target execution node of the distributed computing cluster] performs one or more operators assigned to the computer.”)
obtaining a target sub-graph determined through performing, by the target execution node, querying in the initial property graph based on a decoding result obtained through decoding, by the target execution node, the data flow structure, and (See Roth [0061, 0063] disclosing that the nodes interpret and apply the plan’s operators [i.e. decoding, and querying based on the decoded result]. See also Roth [0050] “The query plan operators traverse the distributed graph and match graph data [i.e. querying in the initial property graph]”)
returning the target sub-graph to the client; and (See Chen [0041] “ the server 220 sends the gathered data to the compute node 210 [i.e. returning the target sub-graph to the client]”)
the client receiving the target sub-graph returned by the service end, and
returning the target sub-graph to the user. (See Jong [0049] “query results are received and returned, e.g., to a client from which the query was received [e.g. returns the results to a user]” See also Chen [0022] “the query processing engine 110 may return a query response 195 to the user computing device 130 [e.g. to the user]”)
Regarding claim 11, Jong-Roth-Chen teaches all limitations and motivations of claim 10, wherein the client comprises a graph pattern parsing node and a policy optimization node; and (See Jong [0032] “graph database access server 112 include a query parser 202 [e.g. graph pattern parsing node]… [and a] Query planner module 204 [i.e. policy optimization node]”)
correspondingly, the client parsing the sub-graph query statement sent by the user for the initial property graph, and generating the sub-graph structure corresponding to the sub-graph query statement; determining the target sub-graph query execution policy in the preset calculation manner based on sub-graph statistical information and the sub-graph structure, wherein the sub- graph statistical information is obtained from the graph data structure constructed based on the target property graph; and (These are restated steps from parent claim 10. See rejection of claim 10.)
encoding the target sub-graph query execution policy into the data flow structure, and sending the data flow structure to the service end comprises: the graph pattern parsing node parsing the sub-graph query statement sent by the user for the initial property graph, generating the sub-graph structure corresponding to the sub-graph query statement, and sending the sub-graph structure to the policy optimization node; (See Jong [0032] “a query parser 202 configured to receive a query [e.g. the sub-graph query statement] via a communication interface, e.g., from a client… and transform the query [i.e. the parsing node generating the sub-graph structure] into an internal representation of the query. The query parser 202 provides the parsed query [e.g. the sub-graph structure] to query planner module 204 [i.e. sending it to the policy optimization node].”)
the policy optimization node determining the target sub-graph query execution policy in the preset calculation manner based on the sub-graph statistical information and the sub-graph structure, wherein the sub-graph statistical information is obtained from the graph data structure constructed based on the target property graph; and (See Jong [0033] “Query planner module 204 obtains an estimated cardinality from a cardinality estimation subsystem 206 and an operator cost model 208 [i.e. the preset calculation manner] to determine a best query plan… a lowest cost plan [i.e. the policy optimization node determining the target sub-graph query execution policy]”
Thus, the cardinality estimates are calculated from the pattern counts [i.e. the sub-graph statistical information] held in the statistics store built from and kept with the property graph [i.e. obtained from the graph data structure constructed based on the target property graph].)
the policy optimization node encoding the target sub-graph query execution policy into the data flow structure, and sending the data flow structure to the service end. (See Roth [0019, 0043-0044, 0063] “the system generates a query plan comprising a plurality of operators. The system determines an order for the plurality of operators. In an embodiment, the order is such that if an operator requires data generated by another operator, then the other operator is ordered before the operator in the query plan [e.g. encoding the policy into the data flow structure]… a query plan defines a list of operators that each perform an operation on the graph… and an order for performing the operators [e.g. encoding the target sub-graph query execution policy into the data flow structure]. Additionally, the query plan may indicate one or more particular partitions and/or computers on which to perform the operator [e.g. sending the data flow structure to the service end]”)
Regarding claim 12, Jong-Roth-Chen teaches all limitations and motivations of claim 11, wherein the client further comprises a management node; and (See Jong [0033-0037] “graph database access system/server 112 [e.g. client] includes: … Statistics 218 [e.g. management node]: A store of graph metadata which is kept strictly up to date with the underlying graph.”)
correspondingly, before the policy optimization node determining the target sub-graph query execution policy in the preset calculation manner based on the sub-graph statistical information and the sub-graph structure, the method further comprises: (See Jong [0062-0063] “the bi-gram counts store is created/maintained… During a bulk import to the database (e.g. when initializing the database from other data sources [e.g. before determining the execution policy]) [Thus, the statistics are constructed ahead of any plan determination]” Thus, since query planner module 204 determines the lowest-cost plan using the already stored counts.)
the management node receiving the target property graph sent by the service end, and determining the sub-graph statistical information in the target property graph; and (Jong [0068] teaches that the statistic component determined the counts in the graph by traversing it “all the relationships in the graph [i.e. in the target property graph] are traversed again. For every relationship encountered, a cache lookup occurs… the types of the adjacent relationships and the label(s) of the common node are determined. This constitutes a bi-gram which is stored for later processing [i.e. the management determining the sub-graph statistical information in the target property graph]”)
Jong does not explicitly disclose that graph data being sent by a service end since Jong’s graph is local to the access server.
However, Roth and Chen teaches that the graph resides at the service end. (See Roth [0025] “computers 102-106 have access to graph 120. Graph 120 may be stored in a file, database, or other shared data store [e.g. at the service end]” See also Chen [0026, 0041] teaches the sending step “A graph database 180 is stored distributively among the servers 120… the server 220 sends the gathered data [i.e. the target property graph sent by the service end] to the compute node 210 [i.e. received at the client]”)
It would have been obvious to modify Jong’s system so that its statistics component receives the graph data from the service end before performing its traversal-based counting, because in the combine system the graph is held at the service end Roth teaches that large graphs often does not fit in the memory of a single machine (Roth 0004), and Chen server to compute node transmission is the known delivery path for stored graph data.
The modification merely applies Chen’s conventional data flow to supply Jong’s existing computing process, yielding the predictable result that the management node obtains the graph data it needs to determine statistics.
the management node constructing the graph data structure in a form of the target property graph based on the sub-graph statistical information, and storing the sub-graph statistical information in the graph data structure. (See Jong [0054] “three new metadata stores are added into the statistics database [i.e. the management node constructing the graph data structure based on the determined statistics]” See also Jong [0021, 0037] “statistics… are stored alongside the graph in the database [i.e. structure in a form of the target property graph based on statistical information]… Statistics 218: A store of graph metadata which is kept strictly up to date with the underlying graph [i.e. storing the sub-graph statistical information in the graph data structure].”)
Regarding claim 13, Jong-Roth-Chen teaches all limitations and motivations of claim 10, wherein the service end comprises a distributed flow engine processing node and a distributed graph storage node; and (See Chen [0076] “the coordinator node 810 (GPE coordinator) [e.g. distributed flow engine processing node] is coordinates the query processing computation(s) on multiple GPE servers 820, 830, 840.” See also Chen [0024, 0026] “ each server 120 a, 120 b, 120 c respectively comprises storage 125 a, 125 b, 125 c [e.g. distributed graph storage node]… the graph database is partitioned (i.e., distributed) among the storage 125 of the servers 120”)
correspondingly, the service end receiving the data flow structure sent by the client, and sending the data flow structure to the target execution node of the distributed computing cluster; and (These are restated steps from parent claim 10. See rejection of claim 10.)
obtaining the target sub-graph determined through performing, by the target execution node, querying in the initial property graph based on the decoding result obtained through decoding, by the target execution node, the data flow structure, and returning the target sub-graph to the client comprises: the distributed flow engine processing node receiving the data flow structure sent by the client, and sending the data flow structure to the target execution node of the distributed computing cluster, wherein the data flow structure is obtained through processing, by the client, the received sub-graph query statement; and (See Jong [0030-0034] discloses that the plan originates at the access server 112, which process the received query statement into the plan [i.e. the data flow structure is obtained through processing, by the client, the received sub-graph query statement]. See also Chen [0072-0082] disclose that the coordinator node receives the query work and dispatches it, instructing each GPE server to process the initial query step and each server will compute the data stored locally on them [i.e. distributed flow engine processing node receiving the data flow structure and sending it to the target execution nodes]. See also Roth [0043, 0063] disclose that the plan’s operators are assigned to particular computers, where “the query plan may indicate one or more particular partitions and/or computers on which to perform the operator… Each computer of the plurality of computers performs one or more operators assigned to the computer.”)
the distributed flow engine processing node obtaining the target sub-graph determined through performing, by the target execution node, querying in the initial property graph based on the decoding result obtained through decoding, by the target execution node, the data flow structure, and returning the target sub-graph to the client. (See Roth [0061, 0050] disclose that each execution node interprets/decodes its assigned operators and performs the specified querying, where “the system applies each operator of the query plan to the graph in the order specified by the query plan [i.e. querying based on decoding result]… The query plan operators traverse the distributed graph and match graph data [i.e. the target sub-graph].” See also Roth [0061] “The final operator produces any results that comprise the solution set of a query [i.e. the target sub-graph].” See also Chen [0041-0042] “the server 220 sends the gathered data to the compute node 210 [i.e. distributed flow engine processing node obtaining the target sub-graph from the execution/storage servers]… the compute node 210 analyzes the data received from the server 220 and generates and outputs a response to the query [i.e. returning the target sub-graph to the client]”)
Regarding claim 15, Jong-Roth-Chen teaches all limitations and motivations of claim 1, wherein parsing the sub-graph query statement sent by the user for the initial property graph comprises: parsing the sub-graph query statement sent by the user for the initial property graph of a target item, wherein the initial property graph of the target item is a set of vertexes and edges, where objects in the target item serve as the vertexes, and associations between the objects serve as the edges. (See Jong [0030-0032, 0049] “Graph database access server 112 [e.g. client] is configured to provide access to graph database 110 [e.g. initial property graph], e.g., by processor queries received from clients 102, 104, and/or 106 and returning results responsive to such queries… graph database access server 112 and/or graph database 110 comprise a computerized record management system that uses a network structure with nodes, edges, labels, and properties to represent data. A node may represent an entity such as a person, a business, an organization, or an account [i.e. objects in a target item serve as the vertexes]… Relationships connect nodes to create high fidelity data models [i.e. associations between the objects serve as the edges]… graph database access server 112 include a query parser 202 configured to receive a query [e.g. sub-graph query statement] via a communication interface, e.g., from a client… and transform the query into an internal representation of the query… a query expressed in a graph database query language, such as Cypher, is received and parsed [e.g. parsing a sub-graph query statement sent by a user for an initial property graph].”
See also Roth [0003] “ the underlying dataset is represented as a graph, where data entities become vertices, and relationships between them become edges of the graph.”)
Regarding claim 16, Jong-Roth-Chen teaches all limitations and motivations of claim 3, wherein when the parsing result satisfies the preset query condition, generating the sub-graph structure corresponding to the sub- graph query statement comprises: when determining, based on the parsing result, that the sub-graph query statement is valid, converting the sub-graph query statement into the sub-graph structure. (See Jong [0034, 0049] “ Query parser 202: Accepts the client's query as input and turns [i.e. converting] its textual query representation into a logical representation suitable for planning and optimization [i.e. a statement that parses under the language’s grammar (Thus, determined valid based on the parsing result, is converted into the sub-graph structure)]… query is received and parsed at 302. For example, a query expressed in a graph database query language, such as Cypher, is received and parsed.”)
Regarding claim 17, Jong-Roth-Chen teaches all limitations and motivations of claim 3, wherein when the parsing result does not satisfy the preset query condition, returning the preset query result to the user comprises: when determining, based on the parsing result, that the sub-graph query statement is invalid, returning the preset query result to the user, wherein the preset query result comprises an empty set. (This limitation further defines only the contingent “does not satisfy” sub-limitation branch of claim 3, a branch mutually exclusive with the branch parent claim 1 unconditionally requires. Under Ex parte Schulhauser (MPEP 2111.04(II)), the broadest reasonable interpretation of the claimed method does not require performance of a step whose condition need not occur; the invalid statement condition need not occur.)
Regarding claim 18, Jong-Roth-Chen teaches all limitations and motivations of claim 1, wherein encoding the target sub-graph query execution policy into the data flow structure, and sending the data flow structure to the service end comprises: encoding the target sub-graph query execution policy into a data flow structure comprising a target operator, and sending the data flow structure to a data flow processing engine of the service end, wherein the target operator is an operator associated with the data flow processing engine. (See Roth [0043-0045, 0019] “a query plan defines a list of operators [i.e. the data flow structure comprising a target operator] that each perform an operation on the graph… and an order for performing the operators. Additionally, the query plan may indicate one or more particular partitions and/or computers on which to perform the operator… the system determines a plurality of query plan operators corresponding to the received query [i.e. the target operators]… the system determines an order in which the plurality of operators should be executed [Thus, the query plan / policy is encoded into a structure comprising the target operator]… the order is such that if an operator requires data generated by another operator, then the other operator is ordered before the operator [Thus, data flows between the operators (e.g. data flow structure)] in the query plan.” See also Roth [0063, 0050] “ Each computer of the plurality of computers performs one or more operators assigned to the computer [i.e. the plan is sent to the engine that executes the operator data flow (e.g. the data flow processing engine of the service end)]… query plan operators include one or more of: neighbor match, edge match, traversal, and common neighbor match. Additionally, query plan operators may be implementation-specific operator types, such as a specialized output operator”)
Regarding claim 19, Jong-Roth-Chen teaches all limitations and motivations of claim 18, wherein receiving the target sub-graph returned by the service end after the service end performs querying in the initial property graph based on the data flow structure comprises: receiving the target sub-graph returned by the data flow processing engine of the service end after the data flow processing engine performs querying in the initial property graph based on the data flow structure. (See Roth [0050, 0061] “The query plan operators traverse the distributed graph and match graph data [i.e. the data flow processing engine performs querying in the initial property graph based on the data flow structure]… The final operator produces any results that comprise the solution set of a query. [i.e. the target sub-graph the engine returns]” See also Chen [0041, 0022] “the server 220 sends the gathered data to the compute node 210 [i.e. the client received the target sub-graph structure returned by the engine]… the query processing engine 110 may return a query response 195 to the user computing device 130”)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Jong-Roth-Chen in view of Bornea (US Patent Application Publication No. US 20160154850 A1).
Regarding claim 4, Jong-Roth-Chen teaches all limitations and motivations of claim 1, wherein determining the target sub-graph query execution policy in the preset calculation manner based on the sub-graph statistical information and the sub-graph structure comprises: determining, in the graph data structure based on the sub-graph structure, a target point corresponding to the sub-graph structure; and determining the sub-graph statistical information associated with the target point, and (See Jong [0048-0054] “Pattern cardinality calculator 216 uses the bi-gram counts, in various embodiments, to estimate the cardinality of bi-grams associated with the query [i.e. for the parsed pattern, the planner looks up to the matching entry in the statistics structure and reads its statistics]… In order to support bi-gram estimation, in various embodiments the design of the graph database system includes… three new metadata stores are added into the statistics database:
a. TWO_GRAM_INCOMING_OUTGOING_COUNT (X, A, Y) Stores the count of the pattern ( . . . )-[:X]->(:A)-[:Y]->( . . . ) and its reciprocal form ( . . . )-[:X]<-(:A)<-[:Y]-( . . . )
b. TWO_GRAM_INCOMING_INCOMING_COUNT (X, A, Y) Stores the count of the pattern ( . . . )-[:X]->(:A)<-[:Y]-( . . . )
c. TWO_GRAM_OUTGOING_OUTGOING_COUNT (X, A, Y) Stores the count of the pattern ( . . . )<-[:X]-(:A)-[:Y]->( . . . ) In a, b, and c above, x and Y are identifiers (IDs) of relationship types (e.g. KNOWS, WORKS_AT), while A represents the ID of a node label in the graph (e.g. Person, Company). For example, in (a) above a matching bi-gram would be a Person node that has an incoming KNOWS relationship (e.g. from another Person node) and an outgoing WORKS_AT relationship (e.g. to a Company node) as illustrated by the example shown in FIGS. 4A-4C.” Thus, the counts stores are keyed by pattern, for each pattern relationship of the parsed query graph, the planner locates the statistics data structure (e.g. the target point) keyed to that pattern (X, A, Y) – i.e. corresponding to the sub-graph structure, and retrieves the statistical information (count) associated with it.)
determining the target sub-graph query execution policy by using a shortest path algorithm. (Jong [0032] teaches that “Query planner module 204 obtains an estimated cardinality from a cardinality estimation subsystem 206 and an operator cost model 208 to determine a best query plan to execute the query, e.g., a query plan determined within a prescribed time to be a lowest cost plan to execute the query.”)
Jong-Roth-Chen does not explicitly disclose that the minimum-cost plan is determined by a shortest-path computation over a graph.
However, Bornea addresses planning for graph-pattern queries. (See Bornea [0032-0034] “ each query q is composed of a set of hierarchically nested graph patterns P … Each access method for a pattern P is annotated with a cost… The cost C may be derived from statistics maintained by the system about the characteristics of a particular dataset” See also Bornea [0063-0072] “ planning is the process of creating a plan, i.e., a series of plan steps, that covers all the sub-patterns in a single AND node… a solution to the planning problem is a graph G of which the nodes GN are pairs of N×M… A topological sort of this graph represents a plan… the cost of G [is] the sum of all node costs… A minimal solution is simply one in which no solution with lower cost exists. A minimal solution is an ideal solution in query planning… A minimal solution to the TSP planning problem for graph T is a solution to the original TSP problem, i.e., it denotes a lowest-cost path [Thus, using a shortest path algorithm] that covers all the nodes in the original graph exactly once.” Thus, Bornea determines the graph-pattern query execution plan by computing the lowest cost path (i.e. shortest, where edge/node weights are statistics derived costs) through a graph whose nodes are pattern evaluation steps.)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Jong’s system so that query planner 204 determines the lowest cost plan using Bornea’s lowest cost path search since Bornea identifies the shortcoming of cost-based planners like Jong’s select the cheapest plan from a constructed subset of candidate plans within a prescribed time, and provides the solution of determining the plan as a lowest cost path that covers all the nodes of the weighted pattern graph where no solution with lower cost exist.
The modification merely replaces Jong’s selection among constructed candidate plans with Bornea’s lowest cost path determination, yielding predictable results of a globally optimal execution policy.
Claims 5 and 20 is rejected under 35 U.S.C. 103 as being unpatentable over Jong-Roth-Chen in view of Ellis (US Patent Application Publication No. US 20050108199 A1).
Regarding claim 5, Jong-Roth-Chen teaches all limitations and motivations of claim 1, wherein after parsing the sub- graph query statement sent by the user for the initial property graph, and generating the sub-graph structure corresponding to the sub-graph query statement, the graph query method further comprises: determining a query count for a query sub-graph corresponding to the sub-graph structure; (See Chen [0104] “when the QPS [i.e. queries per second (Thus, determining a query count)] is too high (e.g., the request wait queue is long as compared to a threshold like 80 percent, then the system is overloaded and so it is too high) [Thus, the counted queries in the combined system are graph-pattern queries, each corresponding to a parsed sub-graph structure]”)
when the query count for the query sub-graph is greater than or equal to a query count threshold, and no sub-graph statistical information in the graph data structure corresponds to the query sub-graph, sending a statistical information update request to the service end; and (Examiner notes that this is a contingent limitation that need not occur and thus is not required by the broadest reasonable interpretation of the claim (see MPEP § 2111.04(II), citing Ex Parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016). However, for the purpose of compact prosecution only, Examiner has shown that this limitation is taught by the cited reference(s). However, for the purpose of compact prosecution only, Examiner has shown that this limitation is taught by the cited reference(s).
Jong-Roth-Cheng does not explicitly disclose a maintained count reaching a threshold combined with the absence of corresponding statistics.
However, Ellis teaches a maintained count reaching a threshold combined with the absence of corresponding statistics. (See Ellis [0022, 0064] “the DBMS recognizes that statistics have not been generated for some component of data accessed by an execution plan… the meta-data comprises a list of columns that need to be accessed but for which there have been no statistics generated [i.e. detecting that no statistical information corresponds to the data the query needs]” See also Ellis [0059] “When the row modification counter for a particular table reaches a threshold value [i.e. a maintained count reaching a threshold], the statistics related to that table are updated. [e.g. triggers a statistics update]” See also Ellis [0076] “At step 340, a request [i.e. sending a statistical information update request] is received to automatically generate statistics. In a preferred embodiment, requests to automatically generate statistics comprise the names of the specific columns… for which it is necessary to generate statistics.”)
Ellis identifies that relying on guesses rather than actual statistics can lead to the selection of a less optimal execution plan, while generating statistics for everything is impracticable due to overhead [Ellis 0005-0006], so statistics should be generated as needed.
Applying this strategy to Jong-Ruth-Chen system where statistics are generated based on the pattern’s query frequency ensures that Jong’s planner only builds statistics for queries where benefit outweighs the cost, a combination of known elements yielding the predictable result of better execution plans, improving database performance.
Regarding claim 20, Jong-Roth-Chen teaches all limitations and motivations of claim 5, wherein the query sub-graph is a graph pattern corresponding to the sub-graph structure. (See Jong [0026, 0032] “ Path patterns—(:A)-[:X]->(:B)<-[:Y]-(:C). Matches against nodes and relationships in a graph database [i.e. the queries are graph patterns]… and transform the query [i.e. parsed] into an internal representation of the query [i.e. the sub-graph structure].”)
Claims 8 and 14 is rejected under 35 U.S.C. 103 as being unpatentable over Jong-Roth-Chen in view of Faltin (US Patent Application Publication No. US 20240184780 A1).
Regarding claim 8, Jong-Roth-Chen teaches all limitations and motivations of claim 7, wherein after the respectively storing, in the target execution node of the distributed computing cluster, the split initial property graphs, the graph query method further comprises: determining the split initial property graphs from the target execution node of the distributed computing cluster in response to a system initialization request; and (Jong [0062-0063] disclose that the statistics construction process runs “during a bulk import to the database (e.g. when initializing the database from other data sources) [i.e. in response to a system initialization request]” See also Roth [0028-0029]” Prior to performing any analytics or queries, the system loads one or more graphs into memory of one or more computers in the system. The graph data is partitioned across multiple computers [i.e. the split initial property graphs are determined and placed at the target execution nodes]… the loading and partitioning only need to be performed once for each graph loaded in the lifetime of the system [i.e. at system initialization]” See also Roth [0018, 0063] “The partitions… are loaded in memory of the plurality of computers… each computer of the plurality of computers performs one or more operators assigned to the computer” Thus, the initialization request that loads and splits the graph (Roth) triggers the statistics process (Jong), which operates on the split graphs located at the execution nodes because, per Roth’s architecture, that is where the graph data exist.)
Jong-Roth-Chen does not explicitly disclose performing sampling on the split initial property graphs according to a preset sampling policy, to obtain the target property graph.
However, Faltin teaches performing sampling on the split initial property graphs according to a preset sampling policy, to obtain the target property graph and sending the target property graph to the client, wherein the target property graph is smaller than a split initial property graph, and sending the target property graph to the client, wherein the target property graph is smaller than a split initial property graph. (See Faltin [0019] “execution of a scouting query is limited by adding a random match filter on every element… to randomly choose elements used for pattern matching in each step [i.e. performing sampling according to a preset sampling policy (e.g. random selection rule)].” See also Faltin [0046] “ Vertex and edge matches do not traverse all potential elements, but the engine randomly chooses elements… the scouting queries are doing a random walk… rand_bool(a,40) returns TRUE in 40% of the calls [i.e. 40% probability is the preset policy, and randomly select subset of vertices and edges (e.g. the target property graph) is necessarily smaller than the graph sampled from]” See also Faltin [0020, 0018] “The scouting queries produce at least partial results [i.e. delivered to the planner (e.g. sending the target property graph to the client )].”)
Jong [0020] identifies that it is prohibitively expensive to process the whole graph in order to plan query execution, and Faltin provides a solution by teaching that random sampling bounds the work while keeping the collected data representative by choosing the vertex randomly, the collected statistics are more representative (Faltin 0044).
It would have been obvious to replace Jong’s traversal of the split graphs with Faltin’s random-sampled traversal within the initialization time statistics build, predictably reducing initialization cost while preserving estimate quality.
Regarding claim 14, Jong-Roth-Chen teaches all limitations and motivations of claim 13, wherein the service end further comprises a graph sparse node; and the method further comprises: the graph sparse node determining, based on the distributed storage node, the initial property graph from the target execution node of the distributed computing cluster in response to a system initialization request; and (See Chen [0024, 0026] discloses that the property graph resides at the service end’s storage nodes where “each server 120 a, 120 b, 120 c respectively comprises storage 125 a, 125 b, 125 c [i.e. the distributed graph storage node]… A graph database 180 is stored distributively among the servers 120, such that data of the graph database is partitioned (i.e., distributed) among the storage 125 of the servers 120. [Thus, the initial property graph is determined based on the distributed storage node]” See also Roth [0028-0029] “Prior to performing any analytics or queries, the system loads one or more graphs into memory of one or more computers in the system. The graph data is partitioned across multiple computers [i.e. initial property graph is at the target execution nodes]… the loading and partitioning only need to be performed once for each graph loaded in the lifetime of the system [i.e. at system initialization]” See also Jong [0062-0063] disclose that the statistics construction process runs “during a bulk import to the database (e.g. when initializing the database from other data sources) [i.e. in response to a system initialization request]” Thus, the initialization request that loads the graph to the storage/execution nodes (Roth, Chen) triggers the statistics process (Jong), which obtains the graph data from the storage nodes where it resides.)
Jong-Roth-Chen does not explicitly disclose graph sparse node performing sampling on the initial property graph according to a preset sampling policy, to obtain the target property graph.
However, Faltin teaches graph sparse node performing sampling on the initial property graph according to a preset sampling policy, to obtain the target property graph, and sending the target property graph to the client, wherein the target property graph is smaller than the initial property graph. (See Faltin [0022, 0019] “the graph query processing engine 120 is configured with scouting query creation service 121, a scouting query execution service 122 [e.g. graph sparse node]… execution of a scouting query is limited by adding a random match filter on every element… to randomly choose elements used for pattern matching in each step [i.e. performing sampling according to a preset sampling policy (e.g. random selection rule)].” See also Faltin [0046] “ Vertex and edge matches do not traverse all potential elements, but the engine randomly chooses elements… the scouting queries are doing a random walk… rand_bool(a,40) returns TRUE in 40% of the calls [i.e. 40% probability is the preset policy, and randomly select subset of vertices and edges (e.g. the target property graph) is necessarily smaller than the graph sampled from]” See also Faltin [0020, 0018] “The scouting queries produce at least partial results [i.e. the sampled graph portions]… The information is later used for selecting a query plan [i.e. delivered to the planner (e.g. client)].”)
Jong [0020] identifies that it is prohibitively expensive to process the whole graph in order to plan query execution, and Faltin provides a solution by teaching that random sampling bounds the work while keeping the collected data representative by choosing the vertex randomly, the collected statistics are more representative (Faltin 0044).
It would have been obvious to supplement Jong-Roth-Chen service end with Faltin scouting creation/execution services and to replace Jong’s traversal with Faltin’s random-sampled traversal within the initialization time statistics build, predictably reducing initialization cost while preserving estimate quality.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OSCAR WEHOVZ whose telephone number is (571)272-3362. The examiner can normally be reached 8:00am - 5:00pm ET.
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 M MOFIZ can be reached at (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 published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/OSCAR WEHOVZ/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights