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 .
Response to Amendment
Applicant’s Pre-Appeal Brief Conference Request and Pre-Appeal Brief, filed February 03, 2025, has been entered. Claims 4 and 18 were previously canceled, and claims 1-3, 5-17, and 19-21 are currently pending.
Response to Pre-Appeal Brief
This Non-Final Rejection is filed in response to Applicant’s Pre-Appeal Brief Conference Request and Pre-Appeal Brief, filed February 03, 2025. Examiner participated in the Pre-Appeal Conference on March 6, 2026 and identified that claim 20, rejected under 35 U.S.C. 102(a)(1) in the Final Rejection, dated January 12, 2026, should have been rejected under 35 U.S.C. 103. As such, this Non-Final Rejection has been issued, and is based on the Amendment filed on November 24, 2025.
Examiner notes that all referrals made to Applicant’s Specification are to the numbered paragraphs in the PGPub version, US 20240273103A1.
Applicant’s Pre-Appeal Brief, filed February 3, 2026, has been fully considered and is not persuasive. Applicant makes several arguments related to claim 19. Applicant argues that the key:value pairs in cited prior art Haprian et al. (Pub. No. US 2022/0129465 A1, hereinafter “Haprian”) refer to the format of the data source rather than the recited “query patterns” in the first limitation of claim 19 (Remarks pp. 1-3). In response, examiner respectfully submits that Applicant refers to Table 2 in Haprian paragraph [0035], where an example DDL statement is provided that creates a graph from the relational tables, however the Final Rejection cited Table 3 in Haprian paragraph [0039] as teaching “query patterns” (Final Rejection, dated 1/12/26, pp. 5-6).
Applicant argues that Haprian has to do with SQL, which is different from claim 19 (Remarks p. 2). In response, examiner respectfully submits that Applicant has made a general argument that is not directed to the claims.
Applicant argues that the “WHERE” clause in Haprian does not require key-value pairs (Remarks pp. 2-3). In response, examiner respectfully submits that the key-value pair in Haprian, p1.age, is disclosed in Table 3 (see Final Rejection, dated 1/12/26, pp. 5-6).
Applicant argues that p1 of p1.age in Haprian does not represent a key, and the SELECT statement in Table 3 simply enumerates the names of columns to be included in the tuple set returned by the query (Remarks p. 3). In response, examiner respectfully submits that Haprian paragraph [0037] provides that “the one or more columns to use a key can be specified in the DDL statement…” and therefore teaches that p1 is a key.
Applicant argues that, referring to Table 4 in Haprian (which is the SQL translation of Table 3, see Haprian paragraph [0040]), p1.id is not a key:value pair, where p1.name and p1.id simply refers to an attribute of the person p1 (Remarks pp. 3-4). In response, examiner respectfully refers to the discussion above where Haprian teaches that p1 is a key.
Applicant argues that in claim 19, there is (i) no query pattern and (ii) no “constraint to be applied to a column named…” (Remarks pp. 3-4). In response, examiner respectfully submits that Haprian teaches (i) in paragraph [0148] that “The main SQL query is generated from a graph pattern query that includes a query pattern” and (ii) Table 2’s “WHERE” clause is interpreted as a constraint (see Final Rejection, dated 1/12/26, pp. 6-7).
Regarding claims 1, 5, 13, 17 and 21, Applicant argues that (i) Haprian does not disclose a key for key:value pairs and (ii) Haprian and Argawal et al. (Patent No. US 6,965,903 B1, hereinafter “Argawal”) cannot be combined without changing the principle of operation because Haprian queries would not work querying the Agarwal schema (Remarks p. 4).
In response, examiner respectfully submits that (i) Applicant is referred to the discussion above where Haprian teaches that p1 is a key and discloses key:value pairs are taught and (ii) Haprian produced an SQL query (see Table 3 and Table 4 [0039-0040]) and Agarwal receives an SQL statement (see Fig. 4, 410, Col. 10 lines 30-41). They are in the same field of endeavor (see MPEP 2141.01(a)(I.)).
Regarding claim 2, 3, 15 and 16, Applicant argues that (i) the query gateway in Sutrave et al. (Pub. No. US 2024/0220486 A1, hereinafter “Sutrave”) is not a query Interpreter and (ii) Sutrave generally does not teach claim 3 (Remarks p. 3). In response, examiner respectfully submits that Sutrave teaches that the graphical user interface may be generated in accordance with a Javascript or other web-enabled protocol that is produced by a backend application operating on a host server or host services (Sutrave [0080]). Sutrave also teaches that the query gateway may be configured to adapt (i.e. interpret) the query formulated by the expression evaluation service into a schema compatible with the external platform service, which may include GraphQL, SQL, JQL, or other structured programming language interface schema (Sutrave [0050-0051]).
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim 19 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Haprian.
Regarding claim 19, Haprian teaches:
providing a query comprising at least a find- and a where-clause, wherein the where- clause comprises one or more query patterns expressing constraints, in the form of key:value pairs, (Haprian – see [0030-0031], where a property graph data model allows vertices and edges in a graph to have arbitrary properties as key-value pairs. Conceptually, a RDBMS may be interpreted in a graph model. For example, all vertices and their properties may be grouped in a vertex table, while all relationships and their properties may be grouped in an edge table. Also see [0039] and Table 3, where the user wants to run a graph pattern query (i.e. one or more query patterns), and where examiner interprets the select statement, “SELECT * FROM GRAPH_TABLE…”, discloses a “find” clause, and the where statement, “WHERE p1.age + 3 < p2.age…” discloses a “where” clause. Also see [0088-0089] and Table 18, where the compilation pipeline supports user-defined vertex and edge identifiers. A RDBMS is configured to recognize and compute a vertex_id and edge_id as native operators references in statements similar to other functions and operators such as MAX, SUM, LTRIM, row_id and CONCAT. A JSON datatype is used to support a graph global id by leveraging native JSON datatype support from RDBMS. A set of primary key columns used for a local vertex/edge id is grouped as a JSON object (i.e. one query object, for example see SELECT statement in Table 18).)
each constraint to be applied to a column named by the attribute identified in the key, and the value being in the form of a predicate expression (Haprian – see [0036-0037], where the DDL statement in Table 2 classifies data tables into vertex tables and edge tables. Every vertex and edge table exposes a set of columns (called properties) which are grouped into a label. A key of a vertex table identifies a unique vertex in the graph. The one or more columns to use as a key can be specified in the DDL statement; the one or more columns specified need not be defined as a primary vertex table. If no vertex table column is specified as a key, then the default key is the primary key of the vertex table. A key of an edge table uniquely identifies an edge in the KEY clause when specifying source and destination vertices and uniquely identifies the source and destination vertices. A key of an edge table can be defined in similar manner as for a vertex table. See [0039-0040] and conversion from Table 3 graph pattern query to Table 4 SQL. Examiner refers to Table 4 conversion to further clarify the graph pattern query in Table 3, where examiner interprets that the in Table 4 the “WHERE” clause discloses a conversion of the Table 3 “WHERE” clause constraint, where the Table 4 “SELECT P1.name as P1_NAME,…” identifies the key P1 and the “WHERE” clause “(P1.id = E1.e_src AND E.id = E1.e_dst AND P2.id – E2.e_src…)” discloses the predicate expression, with “P1.id” discloses the value.)
and wherein the find-clause specifies a subset of attributes optionally identified by aliases thereof (Haprian – see Table 4, where the “SELECT P1.name AS P1_NAME, P2.name AS P2_NAME, P1.sal + P2.sal AS TOTAL_SAL” discloses the find clause with attributes “.name” and “.sal”.)
executing the query by; applying predicate expressions in the one or more query patterns to identify, for each pattern, a subset of records having elements in the named column matching, or not matching, the pattern; performing one or more of the following set operations: intersection, corresponding to conjunction, union, corresponding to disjunction, and complement, corresponding to negation, forming the intersection of the subsets of records so obtained; in accordance with the find-clause, selecting a subset of attributes, as specified, and applying aliases, if any; and thereby identifying the subset of records satisfying the constraints expressed in the query patterns (Haprian – see [0148-0154], and Fig. 6, where the main SQL query is generated from a graph pattern query that includes a query pattern. The graph pattern query is issues against a heterogenous graph having either vertices or edges stored in a plurality of tables. At least two tables of the plurality of tables each store either vertices of the graph or edges of the graph. The graph is defined by a database dictionary of a relational database system. At block 604, the query pattern is split at a particular variable of the variables, into two sub-patterns. The two sub-patterns include a first sub-pattern and a second sub-pattern. At block 606, pattern generalizations for a respective sub-pattern are generated. Each of the pattern specializations is a mapping of each variable in the respective sub-pattern to a respective table of the plurality of tables. At 608, individual SQL query blocks for the pattern specializations are generated. At block 610, a sub-pattern view that includes a UNION ALL condition (i.e. set operation) between the individual SQL query blocks is generated for the respective sub-pattern. Also see [0158], where the main SQL query is executable by a relational database system to generate a result for the graph pattern query.)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5, 13, 17 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal.
Regarding claim 1, Haprian teaches:
a single collection of records, each record having a user-set number of elements identified by user-named attributes, the collection representing the content of one or more hierarchically structured or unstructured primary data sources (Haprian – see [0177], where data is stored in a database in one or more data containers, each container contains records, and the data within each record is organized into one or more fields. In relational database systems, the data containers are typically referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented databases, the data containers are typically referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Also see [0034], where graph data is stored in a set of relational tables inside the RDBMS and that there may be in-memory graph representation of the data. For purposes of discussion of these techniques, assume a user has defined a table schema as shown in table 1. Examiner interprets that the table schema in Table 1 discloses a user-set number of elements and discloses user-named attributes (see “CREATE TABLE person (id NUMBER(5) PRIMARY KEY, name VARCHAR(100), age NUMBER(5), sal NUMBER(5));”). Also see [0036-0038], where the DDL statement in Table 2, classified data tables into vertex tables and edge tables. Every vertex and edge table exposes a set of columns (called properties) which are grouped into a label. The DDL statement allows the user to define the graph as a first class citizen inside the database, which enables a compilation mechanism of graph pattern queries to use graph specific optimizations.)
providing at least one query object comprising at least a find- and a where-clause, wherein the where- clause comprises one or more query patterns expressing constraints, in the form of key:value pairs, (Haprian – see [0030-0031], where a property graph data model allows vertices and edges in a graph to have arbitrary properties as key-value pairs. Conceptually, a RDBMS may be interpreted in a graph model. For example, all vertices and their properties may be grouped in a vertex table, while all relationships and their properties may be grouped in an edge table. Also see [0039] and Table 3, where the user wants to run a graph pattern query (i.e. one or more query patterns), and where examiner interprets the select statement, “SELECT * FROM GRAPH_TABLE…”, discloses a “find” clause, and the where statement, “WHERE p1.age + 3 < p2.age…” discloses a “where” clause. Also see [0088-0089] and Table 18, where the compilation pipeline supports user-defined vertex and edge identifiers. A RDBMS is configured to recognize and compute a vertex_id and edge_id as native operators references in statements similar to other functions and operators such as MAX, SUM, LTRIM, row_id and CONCAT. A JSON datatype is used to support a graph global id by leveraging native JSON datatype support from RDBMS. A set of primary key columns used for a local vertex/edge id is grouped as a JSON object (i.e. one query object, for example see SELECT statement in Table 18).)
each constraint to be applied to elements of columns named by the attribute identified in the key, and the value being in the form of a predicate expression in the form of key:value pairs, (Haprian – see [0036-0037], where the DDL statement in Table 2 classifies data tables into vertex tables and edge tables. Every vertex and edge table exposes a set of columns (called properties) which are grouped into a label. A key of a vertex table identifies a unique vertex in the graph. The one or more columns to use as a key can be specified in the DDL statement; the one or more columns specified need not be defined as a primary vertex table. If no vertex table column is specified as a key, then the default key is the primary key of the vertex table. A key of an edge table uniquely identifies an edge in the KEY clause when specifying source and destination vertices and uniquely identifies the source and destination vertices. A key of an edge table can be defined in similar manner as for a vertex table. See [0039-0040] and conversion from Table 3 graph pattern query to Table 4 SQL. Examiner refers to Table 4 conversion to further clarify the graph pattern query in Table 3, where examiner interprets that the in Table 4 the “WHERE” clause discloses a conversion of the Table 3 “WHERE” clause constraint, where the Table 4 “SELECT P1.name as P1_NAME,…” identifies the key P1 and the “WHERE” clause “(P1.id = E1.e_src AND E.id = E1.e_dst AND P2.id – E2.e_src…)” discloses the predicate expression, with “P1.id” discloses the value.)
and wherein the find-clause specifies the subset of attributes optionally identified by aliases thereof, to be reported at the completion of the query (Haprian – see Table 4, where the “SELECT P1.name AS P1_NAME, P2.name AS P2_NAME, P1.sal + P2.sal AS TOTAL_SAL” discloses the find clause with attributes “.name” and “.sal”.)
executing the query by: applying predicate expressions in the one or more query patterns to identify, for each pattern, a subset of records in the named columns matching, or not matching, the pattern; combining the subsets of records so obtained by performing one or more of the following set operations: intersection, corresponding to conjunction, union, corresponding to disjunction, and complement, corresponding to negation; in accordance with the find-clause, selecting specified attributes and applying the aliases, if any; and thereby identifying the subset of records satisfying the constraints expressed in the query patterns (Haprian – see [0148-0154], and Fig. 6, where the main SQL query is generated from a graph pattern query that includes a query pattern. The graph pattern query is issues against a heterogenous graph having either vertices or edges stored in a plurality of tables. At least two tables of the plurality of tables each store either vertices of the graph or edges of the graph. The graph is defined by a database dictionary of a relational database system. At block 604, the query pattern is split at a particular variable of the variables, into two sub-patterns. The two sub-patterns include a first sub-pattern and a second sub-pattern. At block 606, pattern generalizations for a respective sub-pattern are generated. Each of the pattern specializations is a mapping of each variable in the respective sub-pattern to a respective table of the plurality of tables. At 608, individual SQL query blocks for the pattern specializations are generated. At block 610, a sub-pattern view that includes a UNION ALL condition (i.e. set operation) between the individual SQL query blocks is generated for the respective sub-pattern. Also see [0158], where the main SQL query is executable by a relational database system to generate a result for the graph pattern query.)
Haprian does not appear to teach:
wherein the representation also encodes the structure of each said primary data source in the form of relative or absolute node paths, the method comprising:
However, Argawal teaches:
wherein the representation also encodes the structure of each said primary data source in the form of relative or absolute node paths, the method comprising: (Argawal – see Col. 2 lines 33-50, where nodes in a hierarchy are stored in a node table in relational database, and the parent0child relationships are stored in a hierarchical index that lists the child nodes from a given parent node. IN systems that maintain a node table and a hierarchical index, SQL commands can be used to list the nodes that satisfy certain criteria. The nodes can be searched, or results can be presented, in an order based on the relationships in the hierarchical index.) A path name for the selected file or folder can be constructed by searching the hierarchical index for the parent that lists the found node, or its ancestor, as a child.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Argawal before them, to modify the system of Haprian with the teachings of Argawal, as indicated above. One would have been motivated to make such a modification to manage hierarchical data in a relational database (Argawal - [Col. 1 lines 24-29]).
Regarding claim 5, Haprian teaches:
wherein the predicate expressions represent a negation of a predicate, or the conjunction or disjunction of two or more predicates (Haprian – see [0040] and Table 4, “WHERE (P1.id = E1.e_src AND E.id = E1.e_dst…”. Examiner interprets that “AND” in the “WHERE” statements discloses conjunction of two or more predicates.)
Regarding claim 13, Haprian teaches:
wherein, for queries directed to the relational data store, a function implementing a join operation is provided for combining the corresponding two or more record subsets on a specified PredicateExpression (Haprian – see [0064], where as shown in Table 13, the JOIN condition between the data tables is added and it is concatenated with the rest of the WHERE clause (i.e. PredicateExpression). The primary keys and foreign keys columns for each JOIN are looked up in the graph metadata that stores information. Also see [0085] where the WHERE clause further includes a JOIN condition between particular tables of the plurality of tables associated with the respective pattern specializations.)
Regarding claim 17, Haprian does not appear to teach:
at least one query for identifying relationship primitives
However, Agarwal teaches:
at least one query for identifying relationship primitives (Agarwal – to make more efficient the construction of paths to resources for results of searches that satisfy SQL statements, a path view relational database object is generated. A path view includes links and paths for a hierarchy [Col. 7 lines 35-42]. See Applicant’s Specification p. 18, where RelationshipPrimitives provide a fundamental set of relations for navigating the GenericTabularRepresentation of a hierarchically structured original data source with reference to a pre-selected node context.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Argawal before them, to modify the system of Haprian with the teachings of Argawal, as indicated above. One would have been motivated to make such a modification to manage hierarchical data in a relational database (Argawal - [Col. 1 lines 24-29]).
Regarding claim 21, Haprian does not appear to teach:
wherein queries identifying relationship primitives are implemented by specifying predicate expressions referencing the encoding of hierarchical source content in accordance with a GenericTabularRepresentation
However, Agarwal teaches:
wherein queries identifying relationship primitives are implemented by specifying predicate expressions referencing the encoding of hierarchical source content in accordance with a GenericTabularRepresentation (Agarwal – to make more efficient the construction of paths to resources for results of searches that satisfy SQL statements, a path view relational database object is generated. A path view includes links and paths for a hierarchy [Col. 7 lines 35-42]. See Applicant’s Specification p. 18, where RelationshipPrimitives provide a fundamental set of relations for navigating the GenericTabularRepresentation of a hierarchically structured original data source with reference to a pre-selected node context.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Argawal before them, to modify the system of Haprian with the teachings of Argawal, as indicated above. One would have been motivated to make such a modification to manage hierarchical data in a relational database (Argawal - [Col. 1 lines 24-29]).
Claims 2, 3, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal further in view of Sutrave.
Regarding claim 2, Haprian modified by Argawal does not appear to teach:
wherein the query is executed by a query Interpreter, comprising a QueryEvaluator, and the query is an object in the language of the query Interpreter
However, Sutrave teaches:
wherein the query is executed by a query Interpreter, comprising a QueryEvaluator, and the query is an object in the language of the query Interpreter (Sutrave – the query gateway may be configured to adapt the query formulated by the expression evaluation service into a schema compatible with the external platform service, which may include GraphQL, Sequel Query Language, Jira Query Language or other structured programming interface schema. The provider registry may include a resolver or command interpreter module that is configured to translate or adapt requests from the object-creation service into an API call that is supported by the external platform service [0051].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Sutrave before them, to modify the system of Haprian with the teachings of Sutrave, as indicated above. One would have been motivated to make such a modification to provide efficient compilation of queries on top of a relational engine (Sutrave - [0002]).
Regarding claim 3, Haprian modified by Argawal does not appear to teach:
wherein the query Interpreter is a JavaScript program, and the object is a JavaScript object
However, Sutrave teaches:
wherein the query Interpreter is a JavaScript program, and the object is a JavaScript object (Sutrave – the graphical user interface may be generated in accordance with a Javascript or other web-enabled protocol that is produced by a backend application operating on a host server or host services [0080].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Sutrave before them, to modify the system of Haprian with the teachings of Sutrave, as indicated above. One would have been motivated to make such a modification to provide efficient compilation of queries on top of a relational engine (Sutrave - [0002]).
Regarding claim 15, Haprian modified by Argawal does not appear to teach:
wherein the query object is programmatically formed, transformed or instantiated
However, Sutrave teaches:
wherein the query object is programmatically formed, transformed or instantiated (Sutrave – the query gateway may be configured to adapt the query formulated by the expression evaluation service into a schema compatible with the external platform service, which may include GraphQL, Sequel Query Language, Jira Query Language or other structured programming interface schema. The provider registry may include a resolver or command interpreter module that is configured to translate or adapt requests from the object-creation service into an API call that is supported by the external platform service [0051].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Sutrave before them, to modify the system of Haprian with the teachings of Sutrave, as indicated above. One would have been motivated to make such a modification to provide efficient compilation of queries on top of a relational engine (Sutrave - [0002]).
Regarding claim 16, Haprian modified by Argawal does not appear to teach:
wherein the query object is interactively assembled and submitted for execution using a graphical user interface
However, Sutrave teaches:
wherein the query object is interactively assembled and submitted for execution using a graphical user interface (Sutrave – the query gateway may be configured to adapt the query formulated by the expression evaluation service into a schema compatible with the external platform service, which may include GraphQL, Sequel Query Language, Jira Query Language or other structured programming interface schema. The provider registry may include a resolver or command interpreter module that is configured to translate or adapt requests from the object-creation service into an API call that is supported by the external platform service [0051]. The hosted platform services may also include an object-creation service (also referred to herein as an object-discovery tool or link-creation service) that can be used to create custom selectable graphical objects without leaving the context or current view of the graphical user interface of the client device [0045, also see 0083].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Sutrave before them, to modify the system of Haprian with the teachings of Sutrave, as indicated above. One would have been motivated to make such a modification to provide efficient compilation of queries on top of a relational engine (Sutrave - [0002]).
Claims 6, 7, 8, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal further in view of Wilton (Wilton, Paul, and John Colby. Beginning SQL, John Wiley & Sons, Incorporated, Chapter 3, 2005. ProQuest Ebook Central, https://ebookcentral.proquest.com/lib/uspto-ebooks/detail.action?docID=226434, accessed on December 13, 2024. (Year: 2005), hereinafter “Wilton”).
Regarding claim 6, Haprian modified by Argawal does not appear to teach:
wherein the query also has an in-clause comprising variables that match variables in the query patterns of the where-clause
However, Wilton teaches:
wherein the query also has an in-clause comprising variables that match variables in the query patterns of the where-clause (Wilton – the IN operator functions exactly like the OR operator. The IN operator checks the database to see if the specified column matches one or more of the values listed inside the brackets [pp. 73-75]. See first SQL statement in the “IN Operator” section on p. 73, and WHERE clause with multiple OR operators, and the second SQL statement with the IN operator on pp. 73-74. Examiner interprets that the IN operator in the second SQL statement discloses the in-clause, matching the query pattern of the WHERE statement in the first SQL statement. Also see Applicant’s Specification p. 12, where “more generally, as with the SQL IN clause, the in-clause accommodates a list of arguments.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Wilton before them, to modify the system of Haprian with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Regarding claim 7, Haprian modified by Argawal does not appear to teach:
wherein the in-clause comprises a named pattern group for instantiating query patterns in the where-clause
However, Wilton teaches:
wherein the in-clause comprises a named pattern group for instantiating query patterns in the where-clause (Wilton – the IN operator functions exactly like the OR operator. The IN operator checks the database to see if the specified column matches one or more of the values listed inside the brackets [pp. 73-75]. See first SQL statement in the “IN Operator” section on p. 73, and WHERE clause with multiple OR operators, and the second SQL statement with the IN operator on pp. 73-74. Examiner interprets that the IN operator in the second SQL statement discloses the in-clause, matching the query pattern of the WHERE statement in the first SQL statement. Also see Applicant’s Specification p. 12, where “more generally, as with the SQL IN clause, the in-clause accommodates a list of arguments.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Wilton before them, to modify the system of Haprian with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Regarding claim 8, Haprian modified by Argawal does not appear to teach:
wherein the variables of the in-clause are instantiated by additional arguments provided to a QueryEvaluator
However, Wilton teaches:
wherein the variables of the in-clause are instantiated by additional arguments provided to a QueryEvaluator (Wilton – the IN operator functions exactly like the OR operator. The IN operator checks the database to see if the specified column matches one or more of the values listed inside the brackets [pp. 73-75]. See first SQL statement in the “IN Operator” section on p. 73, and WHERE clause with multiple OR operators, and the second SQL statement with the IN operator on pp. 73-74. Examiner interprets that the IN operator in the second SQL statement discloses the in-clause, matching the query pattern of the WHERE statement in the first SQL statement. Also see Applicant’s Specification p. 12, where “more generally, as with the SQL IN clause, the in-clause accommodates a list of arguments.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Wilton before them, to modify the system of Haprian with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Regarding claim 9, Haprian modified by Argawal does not appear to teach:
wherein the query also has a whereFurther-clause comprising query patterns to be applied to the record subset returned by execution of the where-clause
However, Wilton teaches:
wherein the query also has a whereFurther-clause comprising query patterns to be applied to the record subset returned by execution of the where-clause (Wilton – see pp. 66-70, where the BETWEEN clause is used in relation to the WHERE clause and allows the user to specify a range for the WHERE clause, where the range is between one value and another.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Wilton before them, to modify the system of Haprian with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Regarding claim 10, Haprian modified by Argawal does not appear to teach:
wherein the query also has a whereNext-clause comprising query patterns referencing the record subset returned by execution of the where-clause
However, Wilton teaches:
wherein the query also has a whereNext-clause comprising query patterns referencing the record subset returned by execution of the where-clause (Wilton – see pp. 72-73, where the LIKE clause is ideal to filter records from the WHERE clause results. Examiner interprets that the LIKE clause discloses the whereNext clause.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Wilton before them, to modify the system of Haprian with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Claims 11 is rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal further in view of Wilton further in view of Verbaere et al. (Pub. No. US 2009/0177640 A1, hereinafter “Verbaere”).
Regarding claim 11, Haprian modified by Argawal does not appear to teach:
wherein the query also has a [recursive] whereNext-clause comprising query patterns referencing, [in a first cycle of recursive query execution,] the record subset returned by execution of the where-clause, [and in subsequent cycles the record subset returned by execution of the preceding instance of] the [recursive] whereNext-clause
recursive clause
in a first cycle of a recursive query execution
and in subsequent cycles the record subset returned by execution of the preceding instance of
recursive clause
However, Wilton teaches:
wherein the query also has a [recursive] whereNext-clause comprising query patterns referencing, [in a first cycle of recursive query execution,] the record subset returned by execution of the where-clause, [and in subsequent cycles the record subset returned by execution of the preceding instance of] the [recursive] whereNext-clause (Wilton – see pp. 72-73, where the LIKE clause is ideal to filter records from the WHERE clause results. Examiner interprets that the LIKE clause discloses the whereNext clause.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian, Argawal and Wilton before them, to modify the system of Haprian and Argawal with the teachings of Wilton, as indicated above. One would have been motivated to make such a modification to incorporate the functionality and syntax of SQL clauses.
Haprian modified by Argawal and Wilton does not appear to teach:
recursive clause
in a first cycle of a recursive query execution
and in subsequent cycles the record subset returned by execution of the preceding instance of
recursive clause
However, Verbaere teaches:
recursive clause (Verbaere – a datalog program is a set of predicates defining logical relations. These predicates may be recursive, which in particular allows the transitive closure operations to be implemented [0085], where a Datalog program includes a query, which is a Datalog predicate defining the relation that we wish to compute, and includes a set of user-defined, or intensional predicates which represent user-defined relations to be computed to evaluate the query [0092-0094]. The meaning of a Datalog program can be defined as follows. First, break the program up into components, where each component represents a recursive cycle between predicates. Evaluation proceeds bottom-up, starting with extensional predicates and computing each layer as a least fixed point above [0105].)
in a first cycle of a recursive query execution (Verbaere – a datalog program is a set of predicates defining logical relations. These predicates may be recursive, which in particular allows the transitive closure operations to be implemented [0085], where a Datalog program includes a query, which is a Datalog predicate defining the relation that we wish to compute, and includes a set of user-defined, or intensional predicates which represent user-defined relations to be computed to evaluate the query [0092-0094]. The meaning of a Datalog program can be defined as follows. First, break the program up into components, where each component represents a recursive cycle (i.e. first cycle) between predicates. Evaluation proceeds bottom-up, starting with extensional predicates and computing each layer as a least fixed point above [0105].)
and in subsequent cycles the record subset returned by execution of the preceding instance of (Verbaere – a datalog program is a set of predicates defining logical relations. These predicates may be recursive, which in particular allows the transitive closure operations to be implemented [0085], where a Datalog program includes a query, which is a Datalog predicate defining the relation that we wish to compute, and includes a set of user-defined, or intensional predicates which represent user-defined relations to be computed to evaluate the query [0092-0094]. The meaning of a Datalog program can be defined as follows. First, break the program up into components, where each component represents a recursive cycle between predicates. Evaluation proceeds bottom-up, starting with extensional predicates and computing each layer (i.e. subsequent cycles) as a least fixed point above [0105].)
recursive clause (Verbaere – a datalog program is a set of predicates defining logical relations. These predicates may be recursive, which in particular allows the transitive closure operations to be implemented [0085], where a Datalog program includes a query, which is a Datalog predicate defining the relation that we wish to compute, and includes a set of user-defined, or intensional predicates which represent user-defined relations to be computed to evaluate the query [0092-0094]. The meaning of a Datalog program can be defined as follows. First, break the program up into components, where each component represents a recursive cycle between predicates. Evaluation proceeds bottom-up, starting with extensional predicates and computing each layer as a least fixed point above [0105].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian, Argawal, Wilton and Verbaere before them, to modify the system of Haprian, Argawal and Wilton with the teachings of Verbaere, as indicated above. One would have been motivated to make such a modification to allow for the construction of reusable queries (Verbaere [0007].
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal further in view of Meijer et al. (Pub. No. US 2008/0189277 A1, hereinafter “Meijer”).
Regarding claim 12, Haprian modified by Argawal does not appear to teach:
wherein the query also has a method-clause comprising one or more key-value pairs wherein the key references a preceding where-, whereNext-, recursive whereNext- or whereFurther-clause and the value is a PredicateExpression for aggregating or otherwise transforming record subsets returned by execution of the referenced preceding where-, whereNext-, recursive whereNext- or whereFurther-clause
However, Meijer teaches:
wherein the query also has a method-clause comprising one or more key-value pairs wherein the key references a preceding where-, whereNext-, recursive whereNext- or whereFurther-clause and the value is a PredicateExpression for aggregating or otherwise transforming record subsets returned by execution of the referenced preceding where-, whereNext-, recursive whereNext- or whereFurther-clause (Meijer – the query operators associated with patterns 318-322 can be employed in conjunction with an AGGREGATE operator (i.e. method clause). Within an Aggregate query clause, the set of standard AGGREGATE operators can be applied to the grouped control variable in scope. The AGGREGATE operators can include but are not limited to: ANY, ALL, COUNT, LONGCOUNT, SUM, MIN, MAX, AVERAGE, and/or GROUP [0097] (see Applicant’s Specification p. 14, where the method clause comprises a function expression specifying an aggregate function to be applied to the record set returned by the preceding clause specified in the clause, and provides the means for implement additional aggregate functions such as min, max, average and sum). The query expression can be an expression that applies a series of query operators to a particular collection. A query operator is an operator (e.g., FROM, WHERE, SELECT…) that can be applied to a collection of values across the entire collection at once. The query expression can include a first query clause and any number of next query clauses, each of which contains one of the query operators [0030]. The RETURN and the SELECT operators can specify the shape of the output collection. In some cases, the SELECT operator can introduce new control variables. The WHERE and DISTINCT operators can restrict the values of the collection [0030-0034]. The result of the first query clause flows to the next query clause (i.e. references preceding) such that a known relationship can exist between adjacent query clauses [0049]. If the query expression in Fig. 6, 606, terminated after any of the clauses 704-708 (where in each case there are two control variables in scope, C and O), it can be inferred that the desired output should exist as a collection of name-value (i.e. key-value) pairs [0170].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian, Argawal and Meijer before them, to modify the system of Haprian and Argawal with the teachings of Meijer, as indicated above. One would have been motivated to make such a modification to facilitating type flow and constraining operators to conform to the operator patterns, and to incrementally infer the element types for each clause of the expression (Meijer [0008].
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Argawal further in view of Meijer further in view of Sutrave.
Regarding claim 14, Haprian modified by Argawal does not appear to teach:
an alternating sequence of queries and joins for executing chained self-joins, to cumulatively aggregate content selected from said relational data store
in a summary tabular representation, each join adding to said tabular representation a column named by an attribute
identified in the corresponding join-constituent query
However, Meijer teaches:
an alternating sequence of queries and joins for executing chained self-joins, to cumulatively aggregate content selected from said relational data store (Meijer – query operator pattern 326 can include a query operator that is an accessible instance method named GROUPJOIN. The GROUPJOIN operator can create a grouped join of two collections based on matching keys extracted from the elements. The operator can produce hierarchical results (e.g., outer elements paired with collections of matching inner elements, i.e. alternating sequence) and requires no direct equivalence in relational database terms [0106-0107].)
identified in the corresponding join-constituent query (Meijer – query operator pattern 326 can include a query operator that is an accessible instance method named GROUPJOIN. The GROUPJOIN operator can create a grouped join of two collections based on matching keys extracted from the elements. The operator can produce hierarchical results (e.g., outer elements paired with collections of matching inner elements, i.e. alternating sequence) and requires no direct equivalence in relational database terms [0106-0107].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian, Argawal and Meijer before them, to modify the system of Haprian and Argawal with the teachings of Meijer, as indicated above. One would have been motivated to make such a modification to facilitating type flow and constraining operators to conform to the operator patterns, and to incrementally infer the element types for each clause of the expression (Meijer [0008].
Haprian modified by Argawal and Meijer does not appear to teach:
in a summary tabular representation, each join adding to said tabular representation a column named by an attribute
However, Sutrave teaches:
in a summary tabular representation, each join adding to said tabular representation a column named by an attribute (Sutrave – see [0132], where the table object may be displayed with additional issue data or content that is extracted from the corresponding issue object of the issue tracking system. The issue data displayed in the table object is rendered in accordance with data obtained form the issue tracking platform and should reflect the current state of the data.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian, Argawal, Meijer and Sutrave before them, to modify the system of Haprian, Argawal and Meijer with the teachings of Sutrave, as indicated above. One would have been motivated to make such a modification to provide efficient compilation of queries on top of a relational engine (Sutrave - [0002]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Haprian in view of Meijer.
Regarding claim 20, Haprian does not appear to teach:
wherein the query optionally comprises a clause which is an in-, a whereNext-, or recursive whereNext-, whereFurther- or a method clause
However, Meijer teaches:
wherein the query optionally comprises a clause which is an in-, a whereNext-, or recursive whereNext-, whereFurther- or a method clause (Meijer – the query operators associated with patterns 318-322 can be employed in conjunction with an AGGREGATE operator (i.e. method clause). Within an Aggregate query clause, the set of standard AGGREGATE operators can be applied to the grouped control variable in scope. The AGGREGATE operators can include but are not limited to: ANY, ALL, COUNT, LONGCOUNT, SUM, MIN, MAX, AVERAGE, and/or GROUP [0097] (see Applicant’s Specification p. 14, where the method clause comprises a function expression specifying an aggregate function to be applied to the record set returned by the preceding clause specified in the clause, and provides the means for implement additional aggregate functions such as min, max, average and sum). The query expression can be an expression that applies a series of query operators to a particular collection. A query operator is an operator (e.g., FROM, WHERE, SELECT…) that can be applied to a collection of values across the entire collection at once. The query expression can include a first query clause and any number of next query clauses, each of which contains one of the query operators [0030]. The RETURN and the SELECT operators can specify the shape of the output collection. In some cases, the SELECT operator can introduce new control variables. The WHERE and DISTINCT operators can restrict the values of the collection [0030-0034]. The result of the first query clause flows to the next query clause (i.e. references preceding) such that a known relationship can exist between adjacent query clauses [0049]. If the query expression in Fig. 6, 606, terminated after any of the clauses 704-708 (where in each case there are two control variables in scope, C and O), it can be inferred that the desired output should exist as a collection of name-value (i.e. key-value) pairs [0170].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Haprian and Meijer before them, to modify the system of Haprian with the teachings of Meijer, as indicated above. One would have been motivated to make such a modification to facilitating type flow and constraining operators to conform to the operator patterns, and to incrementally infer the element types for each clause of the expression (Meijer [0008].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM.
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, Sanjiv Shah can be reached at (571) 272-4098. 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.
/RANJIT P DORAISWAMY/ Examiner, Art Unit 2166
/SANJIV SHAH/ Supervisory Patent Examiner, Art Unit 2166