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 .
Claim Rejections - 35 USC§ 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is claiming a computer-readable storage medium.
It is suggested to add a non-transitory computer-readable storage medium to the claim device for statutory subject matter.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claims recite a process of receiving a query, calling data, performing an operation on the query, and outputting a result, as recited in claim 1.
The claimed process is similar to a method of mental processes, particularly concepts performed in the human minds (including an observation, evaluation, judgement, opinion), which is one of the groupings of abstract ideas according to Prong One in Step 2A of the 2019 Patent Subject Matter Eligibility Guidance since the steps of outputting data, which allows processes such as sharing information--are directed to a series of thought processes (i.e. mental processes).
Also, this judicial exception is not integrated into a practical application because outputting data is merely indicating allowing processes (e.g. sharing process) to happen, which does not mean the process of sharing will actually occur and result in a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Additional elements (e.g. vertex record includes an ID field, a label field, etc.) are directed to types of information being manipulated. The types of information being manipulated do not impose a meaningful limit on the judicial exception, such that the claims are more than a drafting effort design to monopolize the exception, because the claimed steps could be performed in a same manner to achieve the same outcome with other types of information other than the ones being used in the claims.
The additional processes (e.g. processing update requests, traversal, join, and mapping operations, extracting a graph) are not integrated into a practical application.
Hence, the claims do not include additional elements or the combination of the elements are sufficient to amount to significantly more than the judicial exception and fail to integrate the judicial exception into practical application according to Prong Two in Step 2A of the 2019 Patent Subject Matter Eligibility Guidance because the claimed elements or the combination do not impose any meaningful limits on practicing the abstract idea.
Further, in view of Step 2B of the 2019 Patent Subject Matter Eligibility Guidance, it is determined that the computing elements (such as a query processing device comprising: at least one memory… and at least one processor) in the claim amount to no more than usage of a generic computing system having a generic computing components, such as processor of a generic network, which fails to provide an inventive concept or significantly more than an abstract idea because the elements do not necessary improve the functioning of a computing system or an improvement to a technical field since network computing is well known.
Thus, for at least the reasoning above, the pending claims are not patent eligible.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Blalock (US 20200357507 A1) in view of Zhuang (US 20190121810 A1).
Regarding Claim 1, Blalock discloses a query processing device (Fig. 1; [0030]: In one or more embodiments, a data repository 102 is any type of storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data; [0176]: FIG. 8 is a block diagram that illustrates a computer system 800) comprising:
at least one memory including a plurality of instructions (Fig. 8; [0177]: Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804);
a first storage device in which property information for vertices and edges is stored in relational tables (Fig. 1; [0034]: Insurance claim records 104 are stored in a data repository 102 in any of a variety of data structures. One data structure suitable for storing insurance claim records is a columnar data storage format, such as Apache Hadoop's Parquet, RCFile, and ORC);
a second storage device in which a vertex record including connection information of the vertices in a graph and an edge record including connection information of edges in the graph are stored (Fig. 1; [0039]: In one or more embodiments, a graph data structure (such as any of visit path graph data structure 108, physician network graph data structure 110, and/or provider network graph data structure 112) stores a set of objects in which some pairs of objects are connected or related. An object in a graph data structure may be referred to as a “vertex.” A connection between two vertices may be referred to as an “edge.”); and
at least one processor electrically connected to the at least one memory and configured to execute the plurality of instructions, wherein, when the plurality of instructions are executed by the at least one processor, the at least one processor performs a plurality of operations (Fig. 8; [0177]: Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804),
the plurality of operations include an operation of receiving a query for a property graph stored separately in the first storage device and the second storage device ([0166]: FIG. 7A illustrates an example of a graph, presented on a user interface… A system receives a request to determine which physicians are influential in getting a patient to ultimately see a particular physician of interest 702);
an operation of calling data required for execution of the query from the first storage device and the second storage device (Fig. 7A; [0166]: In response to the request, the system selects referred visit paths and inferred visit paths, of a particular patient, that include a visit record associated with the physician of interest 702… Based on the visit paths of interest, the system determines a graph data structure representing a physician network. The system causes display of graph 700 representing the physician network);
However, Blalock does not explicitly teach, “an operation of performing an operation on the query using a single integrated operator that performs at least one of traversal, join, and mapping operations depending on data types of a first operand and a second operand based on the called data; and an operation of outputting a result of executing the query, and the called data includes operands and operation relationship information between the operands defined by the query.”
On the other hand, in the same field of endeavor, Zhuang teaches
an operation of performing an operation on the query using a single integrated operator that performs at least one of traversal (Fig. 5; [0413]: As shown in Table 24-9, from any previous query block 540, a one-step traversal on the vertex-set-flow graph 500 can produce an output vertex set mid-query (that is, midway during the graph query 510)),
join ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator), and
mapping operations ([0159] Turning to FIG. 2, in order to load data into the graph model 100 (shown in FIG. 1), a loading job 200 can specify mappings from source data 220 to the graph model 100; [0170]: In FIG. 4, optionally, the loading job 200 that maps the source data 220 to the graph model 100 is obtained, at 1010) depending on data types of a first operand and a second operand based on the called data; and
an operation of outputting a result of executing the query, and the called data includes operands and operation relationship information between the operands defined by the query ([0315]-[0317]: Turning to FIG. 17… The one or more query blocks 540 are executed, at 1220, to generate respective output vertex sets 520. The output vertex sets 520 and/or the initial vertex set 520A can be enabled to interconnect in the vertex-set-flow graph 500 based on the query blocks 540).
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 modified the teaching of Blalock to incorporate the teachings of Zhuang to include performing an operation on the query using a single integrated operator and outputting a result of executing the query.
The motivation for doing so would be to provide a structure that enables a query to be capable of performing various functions to meet real-life graph query needs, as recognized by Zhuang ([0317] Zhuang: The method 1200 provides a DAG-based query structure. Such a structure can offer great flexibility and power for the query; so, the query can be capable of performing various functions to meet real-life graph query needs).
Regarding Claim 2, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 1.
Blalock further teaches wherein the vertex record includes an ID field, a label field
an output edge pointer field, an input edge pointer field, and a property-tuple pointer field, the edge record includes an ID field, a label field, a source vertex pointer field, a destination vertex pointer field, a next output edge pointer field, a next input edge pointer field, and a property-tuple pointer field, the output edge pointer field stores an address of at least one edge output from the vertex, the input edge pointer field stores an address of at least one edge input to the vertex, the property-tuple pointer field of the vertex record stores an address of the relational table connected to the vertex record, the next output edge pointer field stores an address of a next edge output from a source vertex stored in the source vertex pointer field, the next input edge pointer field stores an address of a next edge input to a destination vertex stored in the destination vertex pointer field, and the property-tuple pointer field of the edge record stores an address of the relational table connected to the edge record (Fig. 1; [0023]-[0039]: A graph data structure stores a set of objects in which some pairs of objects are connected or related… schema for insurance claim records 104 may include fields such as a patient identifier (ID), patient name… A schema for insurance claim records 104 may include using codes for certain fields… a graph data structure (such as any of visit path graph data structure 108, physician network graph data structure 110, and/or provider network graph data structure 112) stores a set of objects in which some pairs of objects are connected or related; Table 13 shows exemplary contents of the data structure 160 represented via Java List).
[This is nonfunctional descriptive material, which are merely types of data fields that describe different types of information elements that are not functionally involved in the steps recited. None of the claimed steps are depending on any of the information being described. All steps in the claims would be performed the same to achieve a same outcome regardless of the type of fields that are being described]).
Regarding Claim 3, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 2.
Blalock further teaches wherein the output edge pointer field includes one subfield for each label type of edges included in the graph, and the input edge pointer field includes one subfield for each label type of edges included in the graph (Fig. 1; [0043]-[0046]: A vertex list may store additional information about vertices in a graph… A visit path graph data structure 108 includes vertices 110 representing visits. Additionally, a visit path graph data structure 108 includes edges 112 representing an explicit referral and/or implicit referral between two visits. An edge 112 is a directed edge, such that the edge 112 indicates one visit is a referral source and another visit is a referral destination).
Regarding Claim 4, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 1.
Zhuang further teaches, wherein the plurality of operations further include an operation of processing update requests corresponding to the first storage device and the second storage device in one transaction ([Abstract]: Edges and/or vertices of the graph model can be updated during querying; [0039]-[0043]: In some embodiments of the disclosed method, the executing includes updating a vertex and/or an edge associated with the graph model).
Regarding Claim 5, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 4.
Zhuang further teaches wherein the operation of processing the update requests in one transaction includes: an operation of receiving a label and a property of a graph element to be inserted into the first storage device and the second storage device ([0380]-[0385]: Exemplary updating can include changing attributes of the vertex set 520, inserting and/or deleting the vertex set 520, or a combination thereof);
a first storage device update operation of storing the property of the graph element to be inserted in the relational table of the first storage device; and a second storage device update operation of storing the label of the graph element to be inserted into a label field of the vertex record or the edge record of the second storage device, and storing the address of the relational table in which the graph element to be inserted is stored in the property-tuple pointer field of the vertex record or edge record (Fig. 1; [0229] Optionally, the graph model 100 can be stored in a graph store (not shown). The graph store can include a data storage system for storing data organized in the graph model 100; [0266]: Further, updating of the target schema 140 can include updating vertex types, edge types, and attributes thereof. Stated somewhat differently, the target schema 140 can be updated at a vertex type level, edge type level, and/or attribute level).
Regarding Claim 6, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 4.
Zhuang further teaches wherein the operation of processing the update requests in one transaction includes an operation of recording content of the update requests for the first storage device and the second storage device (Fig. 2; [0241]: In another example, the system 300 can deserialize the source data 220, and put tokens into a line buffer of the buffer 243 and assign a token position mapping. Starting position of each token in the buffer 243 can thus be recorded using the token position mapping; [0270]: Each version of the target schema 140 and/or each of the delta lists 142 can be represented (or recorded, or archived) in any uniform and/or different forms.); and
an operation of restoring all changes reflected in the first storage device and the second storage device to original states based on the recorded content of update requests when an error occurs in the update operation of the first storage device or the second storage device ([0278]: An exemplary storage device can include an external and/or internal drive. Advantageously, in the event that updating fails and/or need to be cancelled, the target schema 140 with no updates is not lost and can be retrieved).
Regarding Claim 7, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 1.
Zhuang further teaches wherein the integrated operator selectively performs traversal, join, and mapping operations within a single query processing layer ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator, an INTERSECT operator, and/or a MINUS operator on the initial vertex set, the output vertex sets, or a combination thereof).
Regarding Claim 8, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 1.
Zhuang further teaches wherein the operation of performing an operation on the query using the integrated operator includes an operation of performing a traversal operation on the first operand and the second operand when both the first operand and the second operand are graph elements including at least one of a set of vertices stored in the second storage device and a set of edges stored in the second storage device ([Abstract]: A selected query block can generate an output vertex set based on an input vertex set with or without traversal over an edge; [0413]: As shown in Table 24-9, from any previous query block 540, a one-step traversal on the vertex-set-flow graph 500 can produce an output vertex set mid-query (that is, midway during the graph query 510));
an operation of performing a join operation on the first operand and the second operand when both the first operand and the second operand are relational data stored in the relational table of the first storage device ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator; [0389] In Table 22, T3 is the union of T1 output vertex set and T2 output vertex set);
an operation of performing a first mapping operation between the graph element of the first operand and the relational database of the second operand when the first operand is the graph element and the second operand is the relational data ([0159]: Turning to FIG. 2, in order to load data into the graph model 100 (shown in FIG. 1), a loading job 200 can specify mappings from source data 220 to the graph model 100. The source data 220 and the graph model 100 can have a source schema and a target schema, respectively); and
an operation of performing a second mapping operation between the relational database of the first operand and the graph element of the second operand when the first operand is the relational database and the second operand is the graph element ([0161]: Exemplary source data 220 can be in a fixed tabular row (or line) format. An exemplary format can include “.csv” format. For example, a mapping can be created from the source column “UserName” to the attribute “Name,” and another mapping can be created from the source column “UserAge” to the attribute “Age.”).
Regarding Claim 9, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 8.
Zhuang further teaches wherein the plurality of operations further include an operation of generating a query processing plan based on the called data ([0133]: FIG. 6 is an exemplary diagram illustrating an embodiment of a loading plan based on the loading job of FIG. 2; [0162]-[0164]: Based on the loading job 200, a loading plan 230 can be generated),
the operation of generating the query processing plan includes an operation of calculating a cost for each possible operation order combination between the operands; and an operation of selecting an optimal subplan requiring the lowest cost in the possible operation order combinations, the operation of calculating the cost includes an operation of calculating a cost of the traversal operation using the integrated operator based on the number of traversal start points, disc I/O cost, CPU operation cost, and buffer cache effect ([0240]: The loading engine 240 can advantageously optimize processing of the encoded loading statements in the loading plan 230… … Therefore, by grouping the loading statements based on source, cost of the deserialization of the same source file can advantageously be saved);
an operation of calculating a cost of the join operation using the integrated operator based on a size of a participating table, disc I/O cost, CPU operation cost, and intermediate result size; and an operation of calculating a cost of the mapping operation using the integrated operator based on a pointer traversal cost, disc I/O cost, and CPU operation cost, and the operation of calculating the cost of the traversal operation includes weighting disc access and operation costs by reflecting an average connection degree of the vertices when a traversal direction of the traversal operation proceeds from the vertex to the edge ([0334]: Additionally and/or alternatively, the query block 540 can include a runtime attribute operation 548 for performing calculation and/or other processes based on one or more runtime attributes).
Regarding Claim 10, the combined teachings of Blalock and Zhuang disclose the query processing device of claim 1.
Zhuang further teaches wherein the plurality of operations further include an operation of extracting at least one graph from the relational table stored in the first storage device ([0227]-[0233]: The reader 241 can read the source data 220 to extract lines and tokenize each line…The writer 242 can transmit the tokens and/or lines to the graph model 100); and
an operation of storing data of the extracted graph in the second storage device ([0229]: Optionally, the graph model 100 can be stored in a graph store (not shown). The graph store can include a data storage system for storing data organized in the graph model 100),
the operation of calling the required data includes an operation of calling data related to the at least one graph from the second storage device, and the operation of performing an operation on the query includes an operation of performing an operation on data related to a plurality of graphs ([0231]: During loading, the loading engine 240 can invoke the reader 241 to traverse line by line in the source data 220. For each line, the reader 241 can be instructed by, and/or can consult, the loading plan 230 for schema mapping, and/or can dynamically loading UDFs from the library 250 (shown in FIG. 5) to do token transformation, data filtering and/or data validation).
Regarding Claim 11, Blalock discloses a method of processing a query in a query processing device (Fig. 1; [0030]: In one or more embodiments, a data repository 102 is any type of storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data; [0176]: FIG. 8 is a block diagram that illustrates a computer system 800) including at least one memory including a plurality of instructions (Fig. 8; [0177]: Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804),
a first storage device in which property information for vertices and edges is stored in relational tables (Fig. 1; [0034]: Insurance claim records 104 are stored in a data repository 102 in any of a variety of data structures. One data structure suitable for storing insurance claim records is a columnar data storage format, such as Apache Hadoop's Parquet, RCFile, and ORC),
a second storage device in which a vertex record including connection information of the vertices in a graph and an edge record including connection information of edges in the graph are stored (Fig. 1; [0039]: In one or more embodiments, a graph data structure (such as any of visit path graph data structure 108, physician network graph data structure 110, and/or provider network graph data structure 112) stores a set of objects in which some pairs of objects are connected or related. An object in a graph data structure may be referred to as a “vertex.” A connection between two vertices may be referred to as an “edge.”), and
at least one processor electrically connected to the at least one memory and configured to execute the plurality of instructions (Fig. 8; [0177]: Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804), the method comprising:
an operation of receiving a query for a property graph stored separately in the first storage device and the second storage device ([0166]: FIG. 7A illustrates an example of a graph, presented on a user interface… A system receives a request to determine which physicians are influential in getting a patient to ultimately see a particular physician of interest 702);
an operation of calling data required for execution of the query from the first storage device and the second storage device (Fig. 7A; [0166]: In response to the request, the system selects referred visit paths and inferred visit paths, of a particular patient, that include a visit record associated with the physician of interest 702… Based on the visit paths of interest, the system determines a graph data structure representing a physician network. The system causes display of graph 700 representing the physician network);
However, Blalock does not explicitly teach “an operation of performing an operation on the query using a single integrated operator that performs at least one of traversal, join, and mapping operations depending on data types of a first operand and a second operand based on the called data; and an operation of outputting a result of executing the query, and the called data includes operands and operation relationship information between the operands defined by the query.”
On the other hand, in the same field of endeavor, Zhuang teaches
an operation of performing an operation on the query using a single integrated operator that performs at least one of traversal (Fig. 5; [0413]: As shown in Table 24-9, from any previous query block 540, a one-step traversal on the vertex-set-flow graph 500 can produce an output vertex set mid-query (that is, midway during the graph query 510)),
join ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator), and
mapping operations depending on data types of a first operand and a second operand based on the called data ([0159] Turning to FIG. 2, in order to load data into the graph model 100 (shown in FIG. 1), a loading job 200 can specify mappings from source data 220 to the graph model 100; [0170]: In FIG. 4, optionally, the loading job 200 that maps the source data 220 to the graph model 100 is obtained, at 1010); and
an operation of outputting a result of executing the query, and the called data includes operands and operation relationship information between the operands defined by the query ([0315]-[0317]: Turning to FIG. 17… The one or more query blocks 540 are executed, at 1220, to generate respective output vertex sets 520. The output vertex sets 520 and/or the initial vertex set 520A can be enabled to interconnect in the vertex-set-flow graph 500 based on the query blocks 540).
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 modified the teaching of Blalock to incorporate the teachings of Zhuang to include performing an operation on the query using a single integrated operator and outputting a result of executing the query.
The motivation for doing so would be to provide a structure that enables a query to be capable of performing various functions to meet real-life graph query needs, as recognized by Zhuang ([0317] Zhuang: The method 1200 provides a DAG-based query structure. Such a structure can offer great flexibility and power for the query; so, the query can be capable of performing various functions to meet real-life graph query needs).
Regarding Claim 12, the combined teachings of Blalock and Zhuang disclose the method of claim 11.
Blalock further teaches wherein the vertex record includes an ID field, a label field, an output edge pointer field, an input edge pointer field, and a property-tuple pointer field, the edge record includes an ID field, a label field, a source vertex pointer field, a destination vertex pointer field, a next output edge pointer field, a next input edge pointer field, and a property-tuple pointer field, the output edge pointer field includes one subfield for each label type of edges included in the graph, and stores an address of at least one edge output from the vertex, the input edge pointer field includes one subfield for each label type of edges included in the graph, and stores an address of at least one edge input to the vertex, the property-tuple pointer field of the vertex record stores an address of the relational table connected to the vertex record, the next output edge pointer field stores an address of a next edge output from a source vertex stored in the source vertex pointer field, the next input edge pointer field stores an address of a next edge input to a destination vertex stored in the destination vertex pointer field, and the property-tuple pointer field of the edge record stores an address of the relational table connected to the edge record (Fig. 1; [0023]-[0039]: A graph data structure stores a set of objects in which some pairs of objects are connected or related… schema for insurance claim records 104 may include fields such as a patient identifier (ID), patient name… A schema for insurance claim records 104 may include using codes for certain fields… a graph data structure (such as any of visit path graph data structure 108, physician network graph data structure 110, and/or provider network graph data structure 112) stores a set of objects in which some pairs of objects are connected or related; Table 13 shows exemplary contents of the data structure 160 represented via Java List).
[This is nonfunctional descriptive material, which are merely types of data fields that describe different types of information elements that are not functionally involved in the steps recited. None of the claimed steps are depending on any of the information being described. All steps in the claims would be performed the same to achieve a same outcome regardless of the type of fields that are being described]).
Regarding Claim 13, the combined teachings of Blalock and Zhuang disclose the method of claim 11.
Zhuang further teaches further comprising an operation of processing update requests corresponding to the first storage device and the second storage device in one transaction ([Abstract]: Edges and/or vertices of the graph model can be updated during querying; [0039]-[0043]: In some embodiments of the disclosed method, the executing includes updating a vertex and/or an edge associated with the graph model).
Regarding Claim 14, , the combined teachings of Blalock and Zhuang disclose the method of claim 13.
Zhuang further teaches wherein the operation of processing the update requests in one transaction includes: an operation of receiving a label and a property of a graph element to be inserted into the first storage device and the second storage device ([0380]-[0385]: Exemplary updating can include changing attributes of the vertex set 520, inserting and/or deleting the vertex set 520, or a combination thereof);
a first storage device update operation of storing the property of the graph element to be inserted in the relational table of the first storage device; and a second storage device update operation of storing the label of the graph element to be inserted into a label field of the vertex record or the edge record of the second storage device, and storing the address of the relational table in which the graph element to be inserted is stored in the property-tuple pointer field of the vertex record or edge record (Fig. 1; [0229]: Optionally, the graph model 100 can be stored in a graph store (not shown). The graph store can include a data storage system for storing data organized in the graph model 100; [0266]: Further, updating of the target schema 140 can include updating vertex types, edge types, and attributes thereof. Stated somewhat differently, the target schema 140 can be updated at a vertex type level, edge type level, and/or attribute level).
Regarding Claim 15, , the combined teachings of Blalock and Zhuang disclose the method of claim 13.
Zhuang further teaches wherein the operation of processing the update requests in one transaction includes an operation of recording content of the update requests for the first storage device and the second storage device (Fig. 2; [0241]: In another example, the system 300 can deserialize the source data 220, and put tokens into a line buffer of the buffer 243 and assign a token position mapping. Starting position of each token in the buffer 243 can thus be recorded using the token position mapping; [0270]: Each version of the target schema 140 and/or each of the delta lists 142 can be represented (or recorded, or archived) in any uniform and/or different forms); and
an operation of restoring all changes reflected in the first storage device and the second storage device to original states based on the recorded content of update requests when an error occurs in the update operation of the first storage device or the second storage device ([0278]: An exemplary storage device can include an external and/or internal drive. Advantageously, in the event that updating fails and/or need to be cancelled, the target schema 140 with no updates is not lost and can be retrieved).
Regarding Claim 16, , the combined teachings of Blalock and Zhuang disclose the method of claim 11.
Zhuang further teaches wherein the integrated operator selectively performs the traversal, join, and mapping operations within a single query processing layer ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator, an INTERSECT operator, and/or a MINUS operator on the initial vertex set, the output vertex sets, or a combination thereof).
Regarding Claim 17, the combined teachings of Blalock and Zhuang disclose the method of claim 11.
Zhuang further teaches wherein the operation of performing an operation on the query using the integrated operator includes an operation of performing a traversal operation on the first operand and the second operand when both the first operand and the second operand are graph elements including at least one of a set of vertices stored in the second storage device and a set of edges stored in the second storage device ([Abstract]: A selected query block can generate an output vertex set based on an input vertex set with or without traversal over an edge; [0413]: As shown in Table 24-9, from any previous query block 540, a one-step traversal on the vertex-set-flow graph 500 can produce an output vertex set mid-query (that is, midway during the graph query 510));
an operation of performing a join operation on the first operand and the second operand when both the first operand and the second operand are relational data stored in the relational table of the first storage device ([0045]: In some embodiments of the disclosed method, the performing the set operation includes performing the set operation by applying a UNION operator; [0389]; In Table 22, T3 is the union of T1 output vertex set and T2 output vertex set);
an operation of performing a first mapping operation between the graph element of the first operand and the relational database of the second operand when the first operand is the graph element and the second operand is the relational data ([0159]: Turning to FIG. 2, in order to load data into the graph model 100 (shown in FIG. 1), a loading job 200 can specify mappings from source data 220 to the graph model 100. The source data 220 and the graph model 100 can have a source schema and a target schema, respectively); and
an operation of performing a second mapping operation between the relational database of the first operand and the graph element of the second operand when the first operand is the relational database and the second operand is the graph element ([0161]: Exemplary source data 220 can be in a fixed tabular row (or line) format. An exemplary format can include “.csv” format. For example, a mapping can be created from the source column “UserName” to the attribute “Name,” and another mapping can be created from the source column “UserAge” to the attribute “Age.”).
Regarding Claim 18, , the combined teachings of Blalock and Zhuang disclose the method of claim 17.
Zhuang further teaches further comprising: an operation of generating a query processing plan based on the called data ([0133]: FIG. 6 is an exemplary diagram illustrating an embodiment of a loading plan based on the loading job of FIG. 2; [0162]-[0164]: Based on the loading job 200, a loading plan 230 can be generated),
wherein the operation of generating the query processing plan includes an operation of calculating a cost for each possible operation order combination between the operands; and an operation of selecting an optimal subplan requiring the lowest cost in the possible operation order combinations, the operation of calculating the cost includes an operation of calculating a cost of the traversal operation using the integrated operator based on the number of traversal start points, disc I/O cost, CPU operation cost, and buffer cache effect ([0240]: The loading engine 240 can advantageously optimize processing of the encoded loading statements in the loading plan 230… … Therefore, by grouping the loading statements based on source, cost of the deserialization of the same source file can advantageously be saved);
an operation of calculating a cost of the join operation using the integrated operator based on a size of a participating table, disc I/O cost, CPU operation cost, and intermediate result size; and an operation of calculating a cost of the mapping operation using the integrated operator based on a pointer traversal cost, disc I/O cost, and CPU operation cost, and the operation of calculating the cost of the traversal operation includes weighting disc access and operation costs by reflecting an average connection degree of the vertices when a traversal direction of the traversal operation proceeds from the vertex to the edge ([0334]: Additionally and/or alternatively, the query block 540 can include a runtime attribute operation 548 for performing calculation and/or other processes based on one or more runtime attributes).
Regarding Claim 19, the combined teachings of Blalock and Zhuang disclose the method of claim 11.
Zhuang further teaches further comprising: an operation of extracting at least one graph from the relational table stored in the first storage device ([0227]-[0233]: The reader 241 can read the source data 220 to extract lines and tokenize each line…The writer 242 can transmit the tokens and/or lines to the graph model 100); and
wherein the operation of calling the required data includes an operation of calling data related to the at least one graph from the second storage device, and the operation of performing an operation on the query includes an operation of performing an operation on data related to a plurality of graphs ([0231]: During loading, the loading engine 240 can invoke the reader 241 to traverse line by line in the source data 220. For each line, the reader 241 can be instructed by, and/or can consult, the loading plan 230 for schema mapping, and/or can dynamically loading UDFs from the library 250 (shown in FIG. 5) to do token transformation, data filtering and/or data validation).
Regarding Claim 20, the combined teachings of Blalock and Zhuang disclose a computer program stored on a computer-readable recording medium.
Blalock further teaches execute the method according to any one of claims 11 to 19 in conjunction with hardware (Fig. 8; [0177]: Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804. Such instructions, when stored in non-transitory storage media accessible to processor 804, render computer system 800 into a special-purpose machine that is customized to perform the operations specified in the instructions).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY D. HICKS whose telephone number is (571)272-3304. The examiner can normally be reached Mon - Fri 7:30 - 4:00.
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, Charles Rones can be reached on (571) 272-4085. 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.
/S.D.H./Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
