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 .identif$4
DETAILED ACTION
This action is response to the applicant’s remarks and REC filed on 01/20/2026.
Claims 1-20 are pending in this Office Action. Claims 1, 9 and 15 are independent claims.
Response to Arguments
The Applicant's Remarks/arguments filed 01/20/2026 have been fully considered and respectfully reviewed. As per the Examiner’s responses, please refer to below discussions.
In the Remarks, the Applicant mainly argued that
“OraDBAdm fails to teach or suggest loading a plurality of in-memory datasets, recited in prior
claim 1…. the limitations of a plurality of in-memory
datasets, recited in prior claim 1, to the prioritized data being cached into the distributed
in-memory database, disclosed in Shekhar. See Office Action at pp. 5-6 (citing Shekhar
at ¶¶ [0061 ]). Based on this claim mapping, in order to teach or suggest the above
limitations of amended claim 1, Shekhar would need to disclose that the query manager
responds to a query or a validation of a query by loading the in-memory database into
the low-latency memory. Shekhar would also need to disclose that the query is
executed on the cached prioritized data included in the compressed tables to generate
a result. Importantly, Shekhar contains no such teachings”,
in view of the amendments made to the claims in the set of 1-20, the Examiner respectfully incorporated a new reference published to Hines which is dedicated to the implementation of in-memory data set of queries, database data, and query results to replace Shekhar in the instant action, excepting that Shekhar remained being cited for rejections made to claims 8, 14 and 20.
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 of this title, 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for
establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37CPR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 7, 9, 12-13, 15, and 18-19 are rejected under 35 U.S.C. § 103 as being unpatentable over
OraDBAdm: “Oracle® Database Administrator's Guide”, (11g Release 2 (11.2), May 2015, Hereafter “OraDBAdm”), in view of
Hines et al.: "NAVIGATION PATHWAY GENERATION", (U.S. Patent Application Publication US 20220078149 A1, DATE PUBLISHED 2022-03-10 and DATE FILED 2021-09-01, hereafter "Hines").
As per claim 1, OraDBAdm teaches a computer-implemented method comprising:
receiving a structured query identifying a plurality of source datasets (See Page 31-24, Distributed SQL Statements:
“A received distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the table emp of the schema scott is from local database by default and the table dept of the schema is from remote database sales.us.americas.example_auto.com and the local, the remote databases and/or its tables teaches source datasets);
retrieving a plurality of schemas from one or more data models associated with the plurality of source datasets (See Pages 31-24 and 31-36, below distributed SQL Statements accessing data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the schema scott at the local default database and the schema scott at the remote database sales.us.americas.example_auto.com are retrieved for selecting data ename and dname from respective tables emp and dept, respectively. Further, the database extends the hierarchical naming model with global database names to effectively create global object names and resolve references to the schema objects in a distributed database system, in which the hierarchical naming model with global database names reads on the data model for the databases because the naming globally defines the source of the database data, for example, data for column dname is under the hierarchical data model scott.dept[.dname]@sales.us.americas.example_auto.com),
wherein each schema included in the plurality of schemas defines a structure of a record included in a source dataset of the plurality of source datasets (See Pages 18-1 and 18-2,
“CREATE SCHEMA AUTHORIZATION scott
CREATE TABLE dept (
deptno NUMBER(3,0) PRIMARY KEY,
dname VARCHAR2(15),
loc VARCHAR2(25))
CREATE TABLE emp (
empno NUMBER(5,0) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
job VARCHAR2(10),
mgr NUMBER(5,0),
hiredate DATE DEFAULT (sysdate),
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno NUMBER(3,0) NOT NULL
CONSTRAINT dept_fkey REFERENCES dept)”,
Here “CREATE TABLE” teaches defining the structure of a record in the local database; and further at Page 32-19, Figure 32–3, the schema scott defines table scott.emp as a structure of a record included in a source dataset, the local database).
OraDBAdm does not explicitly teach validating, based on the plurality of schemas, one or more parameters of the structured query.
However, Hines teaches validating, based on the plurality of schemas, one or more parameters of the structured query (See Fig. 11, [0175], [0195] and [0257], receiving a first query, a middleware layer may be used to detect which databases will be accessed by a query and to validate a query, and the first query is being validated by a query parser and a query validator; and the set of parsed parameters may be used to perform operations such as selecting a set of values. Here query is constructed based on schemas and its validation is based on schemas accordingly while parsing and validating query reads on query validation).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Hines’ teaching with OraDBAdm because Hines is dedicated to deep linking invoking functionality of a remotely executing service and OraDBAdm is dedicated to computer languages which process data and in-memory database for continuous analytics and a combined teaching would have enabled user of OraDBAdm to launch a native application in a non-default state specified by the deep link providing links to such applications in various states specified by the links.
OraDBAdm in view of Hines further teaches:
upon validating the structured query, loading, into volatile memory, a plurality of in-memory datasets (See Hines: Fig. 11, [0179], [0196]-[0197] and [0200], a data store may include an in-memory data store, caching a query that causes the generation of a plurality of other database queries or caching data based on the query in an in-memory data store and the data may include an abstract syntax tree (AST) based on the query; and the AST validated by the query validator 1118 is provided to the planner subsystem to convert the query AST into a query of another database system and as query response, receiving the set of query results 1154 and storing the set of query results 1154 in the set of in-memory data stores. Here the parsed and validated query being cached to cause generation of other database queries and storing of query result into in-memory as a response to the query teaches the upon validating the structured query, loading, into volatile memory, a plurality of in-memory datasets),
wherein each in-memory dataset represents a source dataset in the plurality of source datasets (See Hines: Fig. 11 and [0200], after receiving the set of query results 1154, storing the set of query results 1154 in the set of in-memory data stores); and
executing the structured query on each in-memory dataset of the plurality of in-memory datasets by causing portions of the structured query to be applied to each in-memory dataset of the plurality of in-memory datasets to generate a query result (See Hines: Fig. 11, [0179], [0196]-[0197] and [0200], a data store may include an in-memory data store, caching a query that causes the generation of a plurality of other database queries or caching data based on the query in an in-memory data store and the data may include an abstract syntax tree (AST) based on the query; and the AST validated by the query validator 1118 is provided to the planner subsystem to convert the query AST into a query of another database system and as query response, receiving the set of query results 1154 and storing the set of query results 1154 in the set of in-memory data stores.).
As per claim 2, OraDBAdm in view of Hines teaches the computer-implemented method of claim 1, further comprising:
retrieving a first schema in the plurality of schemas (See OraDBAdm: Page 18-19, “Managing Object Name Resolution: Object names referenced in SQL statements can consist of several pieces, separated by periods. The following describes how the database resolves an object name. 1. Oracle Database attempts to qualify the first piece of the name referenced in the SQL statement. For example, in scott.emp, scott is the first piece”. Here the first piece of the name referenced in the SQL statement qualified teaches the first schema retrieved.),
wherein the first schema is associated with a first type of records included in the in-memory dataset (See OraDBAdm: Page 18-1,
“CREATE SCHEMA AUTHORIZATION scott
CREATE TABLE dept (
deptno NUMBER(3,0) PRIMARY KEY,
dname VARCHAR2(15),
loc VARCHAR2(25)).
Here the schema scott is associated with TABLE as the first type of records; and
Hines: [0179], the generation of a plurality of other database queries or caching data based on the query in an in-memory data store),
wherein the first schema defines a structure for:
a plurality of fields for a data type (See OraDBAdm: the schema defines the fields deptno, dname and loc for the table dept), and
metadata associated with one or more fields in the plurality of fields (See OraDBAdm: Page 18-1, the metadata NUMBER(3,0) PRIMARY KEY, VARCHAR2(15), and ARCHAR2(25) are associated with the fields deptno, dname and loc, respectively).
As per claim 3, OraDBAdm in view of Hines teaches the computer-implemented method of claim 2, further comprising:
providing a graphical user interface listing at least one of the plurality of fields specified by the first schema (See OraDBAdm: Page 31-23, Enterprise Manager: providing a graphical user interface (GUI) performing administrative functionality for distributed databases),
wherein receiving the structured query comprises:
receiving an input that includes the at least one of the plurality of fields (See OraDBAdm: Pages 31-23 and 18-1, Enterprise Manager: providing a graphical user interface (GUI) for entering, editing, and executing query statements, including CREATE TABLE with fields and its metadata), and
generating, based on the input, a query including the at least one of the plurality of fields (See OraDBAdm: Pages 31-23 and 18-1, Enterprise Manager: providing a graphical user interface (GUI) for entering, editing, and executing query statements, including executing the CREATE TABLE statement).
As per claim 4, OraDBAdm in view of Hines teaches the computer-implemented method of claim 1, identifying, in the structured query, a first field defined by a first schema in the plurality of schemas (See OraDBAdm: Page31-24, Distributed SQL Statements
A distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;
Here the query statement identifies ename as the first field defined by the first schema scott),
wherein a first source dataset of the plurality of source datasets includes the first field (See OraDBAdm: Page31-24, Distributed SQL Statements
A distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;
Here the default local database teaches the first dataset that includes ename as the first field).
As per claim 7, OraDBAdm in view of Hines teaches the computer-implemented method of claim 1, wherein executing the structured query on each in-memory dataset of the plurality of in-memory datasets comprises: identifying an aggregating operator in the structured query (See OraDBAdm: Page 14-49, Example 3: Displaying Statistics for Free Space (Extents) of Each Tablespace: To produce statistics about free extents and coalescing activity for each tablespace in the database, enter the following query:
SELECT TABLESPACE_NAME "TABLESPACE", FILE_ID,
COUNT(*) "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE",
SUM(blocks) "TOTAL"
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME, FILE_ID; Here aggregating operators include MAX, MIN, AVG, SUM and COUNT),
wherein the aggregating operator comprises an operator from a group consisting of:
a count operator, a minimum operator, and a maximum operator (See OraDBAdm: Page 14-49, Example 3: Displaying Statistics for Free Space (Extents) of Each Tablespace: To produce statistics about free extents and coalescing activity for each tablespace in the database, enter the following query:
SELECT TABLESPACE_NAME "TABLESPACE", FILE_ID,
COUNT(*) "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE",
SUM(blocks) "TOTAL"
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME, FILE_ID; Here aggregating operators include MAX, MIN, AVG, SUM and COUNT);
identifying at least two in-memory datasets in the plurality of in-memory datasets that are associated with the aggregating operator (See OraDBAdm: Page 31-24, Distributed SQL Statements:
“A received distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the schema scott at the local default database and the schema scott at the remote databases teaches the schemas; and Hines: [0179], the generation of a plurality of other database queries or caching data based on the query in an in-memory data store), and
performing an aggregating operation corresponding to the aggregating operator on the plurality of in-memory datasets (See OraDBAdm: Page 14-49,To produce statistics about free extents and coalescing activity for each tablespace in the database, enter the following query:
SELECT TABLESPACE_NAME "TABLESPACE", FILE_ID,
COUNT(*) "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE",
SUM(blocks) "TOTAL"
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME, FILE_ID;
TABLESPACE FILE_ID PIECES MAXIMUM MINIMUM AVERAGE TOTAL
---------- ------- ------ ------- ------- ------- ------
RBS 2 1 955 955 955 955
SYSTEM 1 1 119 119 119 119
TEMP 4 1 6399 6399 6399 6399
TESTTBS 5 5 6364 3 1278 6390
USERS 3 1 363 363 363 363; and
Hines: [0179], the generation of a plurality of other database queries or caching data based on the query in an in-memory data store.
Here the listed values teaches the SELECT statement executed; and
Hines: Fig. 11, [0179], [0196]-[0197] and [0200], a data store may include an in-memory data store, caching a query that causes the generation of a plurality of other database queries or caching data based on the query in an in-memory data store and the data may include an abstract syntax tree (AST) based on the query; and the AST validated by the query validator 1118 is provided to the planner subsystem to convert the query AST into a query of another database system and as query response, receiving the set of query results 1154 and storing the set of query results 1154 in the set of in-memory data stores. Here the parsed and validated query being cached to cause generation of other database queries and storing of query result into in-memory as a response to the query teaches the upon validating the structured query, loading, into volatile memory, a plurality of in-memory datasets).
As per claim 9, OraDBAdm teaches one or more non-transitory computer-readable media storing instructions that (See Page 1-3, memory is available to the instances of Oracle Database you will run), when executed by one or more processors, cause the one or more processors to perform the steps (See Page 5-20, the database selects an appropriate default setting for this initialization parameter or adjusts a user-specified setting based on the number of CPUs and the number of processor groups) of:
receiving a structured query identifying a first source dataset (See Page 31-24, Distributed SQL Statements:
“A received distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the table emp of the schema scott is from local database by default and the table dept of the schema is from remote database sales.us.americas.example_auto.com and the local and the remote databases teaches source datasets);
retrieving a plurality of schemas from one or more data models associated with the plurality of source datasets (See Pages 31-24 and 31-36, below distributed SQL Statements accessing data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the schema scott at the local default database and the schema scott at the remote database sales.us.americas.example_auto.com are retrieved for selecting data ename and dname from respective tables emp and dept, respectively. Further, the database extends the hierarchical naming model with global database names to effectively create global object names and resolve references to the schema objects in a distributed database system, in which the hierarchical naming model with global database names reads on the data model for the databases because the naming globally defines the source of the database data, for example, data for column dname is under the hierarchical data model scott.dept[.dname]@sales.us.americas.example_auto.com),
wherein each schema included in the plurality of schemas defines a structure of a record included in a source dataset of the plurality of source datasets (See Pages 18-1 and 18-2,
“CREATE SCHEMA AUTHORIZATION scott
CREATE TABLE dept (
deptno NUMBER(3,0) PRIMARY KEY,
dname VARCHAR2(15),
loc VARCHAR2(25))
CREATE TABLE emp (
empno NUMBER(5,0) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
job VARCHAR2(10),
mgr NUMBER(5,0),
hiredate DATE DEFAULT (sysdate),
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno NUMBER(3,0) NOT NULL
CONSTRAINT dept_fkey REFERENCES dept)”,
Here “CREATE TABLE” teaches defining the structure of a record in the local database; and further at Page 32-19, Figure 32–3, the schema scott defines table scott.emp as a structure of a record included in a source dataset, the local database).
OraDBAdm does not explicitly teach validating, based on the plurality of schemas, one or more parameters of the structured query.
However, Hines teaches validating, based on the plurality of schemas, one or more parameters of the structured query (See Fig. 11, [0175], [0195] and [0257], receiving a first query, a middleware layer may be used to detect which databases will be accessed by a query and to validate a query, and the first query is being validated by a query parser and a query validator; and the set of parsed parameters may be used to perform operations such as selecting a set of values. Here query is constructed based on schemas and its validation is based on schemas accordingly while parsing and validating query reads on query validation).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Hines’ teaching with OraDBAdm because Hines is dedicated to deep linking invoking functionality of a remotely executing service and OraDBAdm is dedicated to computer languages which process data and in-memory database for continuous analytics and a combined teaching would have enabled user of OraDBAdm to launch a native application in a non-default state specified by the deep link providing links to such applications in various states specified by the links.
OraDBAdm in view of Hines further teaches:
validating, based on the plurality of schemas, one or more parameters of the structured query (See Page 18-20, lines 14-18, When global object names are used in a distributed database, either explicitly or indirectly within a synonym, the local database resolves the reference locally. For example, it resolves a synonym to global object name of a remote table. The partially resolved statement is shipped to the remote database, and the remote database completes the resolution of the object as described here. Here the statement teaches query statement, resolving local or remote databases teaches validating the dataset);
determining that the structured query is associated with at least two versions of the first source dataset (See Figure 31-1 and Page 31-2, “An Oracle Database distributed database system can incorporate Oracle Databases of different versions.”. Here the databases MFG.EXAMPLE.COM, HQ.EXAMPLE.COM and SALES.EXAMPLE.COM teaches versions of a distributed database EXAMPLE.COM);
upon validating the structure query, loading, into volatile memory, each of the at least two versions of the first source dataset to memory as a first in-memory dataset and a second in-memory dataset in a plurality of in-memory datasets (See [0061], a portion of the low-latency data may represent a data model of an external enterprise database and may omit the data stored in the external enterprise database, or a portion thereof. For example, prioritized data may be cached in the distributed in-memory database 3300 and the other data may be omitted from storage in the distributed in-memory database 3300, which may be stored in the external enterprise database. Here caching prioritized data of external enterprise database in the distributed in-memory database teaches the loading; and further at Figure 31-1 and Page 31-2, “An Oracle Database distributed database system can incorporate Oracle Databases of different versions.”. Here the databases MFG.EXAMPLE.COM, HQ.EXAMPLE.COM and SALES.EXAMPLE.COM teaches versions of a distributed database EXAMPLE.COM);
executing the structured query on at least the first in-memory dataset and the second in-memory dataset to generate query result (See Hines: Fig. 11, [0179], [0196]-[0197] and [0200], a data store may include an in-memory data store, caching a query that causes the generation of a plurality of other database queries or caching data based on the query in an in-memory data store and the data may include an abstract syntax tree (AST) based on the query; and the AST validated by the query validator 1118 is provided to the planner subsystem to convert the query AST into a query of another database system and as query response, receiving the set of query results 1154 and storing the set of query results 1154 in the set of in-memory data stores.).
As per claim 15, the claim recites a computer-implemented method comprising the steps performed in the method of the claim 9 and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines above.
Accordingly, claim 15 is rejected along the same rationale that rejected claim 9.
As per claims 12-13, the claims recite the one or more non-transitory computer-readable media of claim 9, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the steps in the methods of the claims 2 and 3 above, respectively and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines above.
Accordingly, claims 12-13 are rejected along the same rationale that rejected claims 2 and 3 above, respectively.
As per claims 18-19, the claims recite the one or more non-transitory computer-readable media of claim 9, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the steps in the methods of the claims 2 and 3 above, respectively and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines above.
Accordingly, claims 18-19 are rejected along the same rationale that rejected claims 2 and 3 above, respectively.
Claims 8, 14 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over
OraDBAdm in view of Hines, as being applied to claims 1-4, 7, 9, 12-13, 15, and 18-19 above, and further in view of
Shekhar et al.: "QUERY EXECUTION ON COMPRESSED IN-MEMORY DATA", (U.S. Patent Application Publication US 20210109974 Al, DATE PUBLISHED 2021-04-15 and DATE FILED 2020-10-13, hereafter "Shekhar").
As per claim 8, OraDBAdm in view of Hines teaches the computer-implemented method of claim 1, further comprising:
identifying, based on the structured query, a plurality of tables included in a first in-memory dataset in the plurality of in-memory datasets (See OraDBAdm: Page 31-24, Distributed SQL Statements:
“A received distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the scott.emp and scott.dept@sales.us.americas.example_auto.com teaches the two table at local default and remote databases; and
Hines: [0179], the generation of a plurality of other database queries or caching data based on the query in an in-memory data store.
Here the listed values teaches the SELECT statement executed).
However, OraDBAdm in view of Hines does not explicitly teach generating, for each table in the plurality of tables: a first index of records that is in the table and is associated with at least one field value responsive to the structured query.
On the other hand, as an analogous art on distributed database, Shekhar teaches generating, for each table in the plurality of tables:
a first index of records that is in the table and is associated with at least one field value responsive to the structured query (See Shekhar: [0114], generating one or more indexes, such as one or more of an ontological index, a constituent data index, a control-word index, a numeral index, or a constant index, based on the low-latency data stored in the distributed in-memory database 3300, the low-latency database analysis system 3000, or both).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Shekhar’s teaching with OraDBAdm in view of Hines because Shekhar is dedicated to implementations of selectively compressing in-memory data of a distributed in-memory database of a low-latency database analysis system, Hines is dedicated to deep linking invoking functionality of a remotely executing service and OraDBAdm is dedicated to computer languages which process data and in-memory database for continuous analytics and a combined teaching would have enabled OraDBAdm in view of Hines to store the entire snapshot in RAM instead of storing the entire source dataset for efficiently accessing data in the same network.
OraDBAdm in view of Hines and further in view of Shekhar further teaches:
a second index of records that is in the table and is not associated with at least one field value responsive to the structured query (See Shekhar: [0114], generating one or more indexes, such as one or more of an ontological index, a constituent data index, a control-word index, a numeral index, or a constant index, based on the low-latency data stored in the distributed in-memory database 3300, the low-latency database analysis system 3000, or both),
wherein the first index and second index are usable to respond to subsequent queries (See Shekhar: [0119], the relational search unit 3700 may send, or otherwise communicate, a message or signal to the distributed in-memory database 3300 indicating a request to perform an indexing data-query, the relational search unit 3700 may receive response data from the distributed in-memory database 3300 in response to the requested indexing data-query, and the relational search unit 3700 may generate the constituent data index, or a portion thereof, based on the response data. For example, the constituent data index may index data-objects.).
As per claim 14, the claim recites the one or more non-transitory computer-readable media of claim 9, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the steps in the method of the claim 8, and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines and further in view of Shekhar above.
Accordingly, claim 14 is rejected along the same rationale that rejected claim 8.
As per claim 20, the claim recites the one or more non-transitory computer-readable media of claim 9, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the steps in the method of the claim 8 and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines and further in view of Shekhar above.
Accordingly, claim 20 is rejected along the same rationale that rejected claim 8.
Claims 5-6, 10 and 16 are rejected under 35 U.S.C. § 103 as being unpatentable over
OraDBAdm in view of Hines, as being applied to claims 1-4, 7, 9, 12-13, 15, and 18-19 above, and further in view of
KOSZEWNIK; John Andrew: " TECHNIQUES FOR GENERATING AND OPERATING ON IN-MEMORY DATASETS", (U.S. Patent Application Publication US 20130297654 A1, DATE PUBLISHED 2018-04-12 and DATE FILED 2017-10-04, hereafter "KOSZEWNIK").
As per claim 5, OraDBAdm in view of Hines does not explicitly teach the computer-implemented method of claim 1, wherein loading the plurality of source datasets into memory comprises:
copying a first snapshot associated with a first source dataset into the memory to generate a first in-memory dataset comprising compressed representations of the first source dataset.
However, as analogous art on in-memory database application, KOSZEWNIK teaches the computer-implemented method of claim 1, wherein loading the plurality of source datasets into memory comprises:
copying a first snapshot associated with a first source dataset into the memory to generate a first in-memory dataset comprising compressed representations of the first source dataset (See [0119], selecting a first snapshot included in one or more snapshots, wherein each snapshot is associated with a different version of a source dataset, and the first snapshot is associated with a first version of the source dataset; copying the first snapshot from a file store to a first random access memory (RAM) to generate a first in-memory dataset).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine KOSZEWNIK’s teaching with OraDBAdm in view of Hines because KOSZEWNIK is dedicated to generating and operating on in-memory datasets, Hines is dedicated to deep linking invoking functionality of a remotely executing service and OraDBAdm is dedicated to computer languages which process data and in-memory database for continuous analytics and a combined teaching would have enabled OraDBAdm in view of Hines to store the entire snapshot in RAM instead of storing the entire source dataset for efficiently accessing data in the same network.
OraDBAdm in view of Hines and further in view of KOSZEWNIK further teaches:
copying a second snapshot associated with a second source dataset into the memory to generate a second in-memory dataset comprising compressed representations of the second source dataset (See KOSZEWNIK: [0101], if the stored version 182 is less than the next version, then the plan includes one of the snapshots 152 and/or one or more delta files 154. If the stored version 182 is greater than the next version, then the plan includes one of the snapshots 152 and/or one or more of the reverse delta files 156. If the stored version 182 is equal to the next version, then the plan is empty).
As per claim 6, OraDBAdm in view of Hines and further in view of KOSZEWNIK teaches the computer-implemented method of claim 5, further comprising:
copying a first delta file to the memory (See KOSZEWNIK: [0118], sequentially apply a series of delta files or reverse delta files to the in-memory dataset); and
applying the first delta file to the first in-memory dataset to generate a third in-memory dataset (See KOSZEWNIK: [0101], the read state application 180 generates a plan to transition the in-memory dataset 184 from the stored version 182 to the next version. If the stored version 182 is less than the next version, then the plan includes one of the one or more delta files 154. If the stored version 182 is greater than the next version, then the plan includes one or more of the reverse delta files 156),
wherein the first in-memory dataset is associated with a first version of the first source dataset and the third in-memory dataset is associated with a second version of the first source dataset (See KOSZEWNIK: [0101], generating a plan to transition the in-memory dataset 184 from the stored version 182 to the next version).
As per claim 10, the claim recites the one or more non-transitory computer-readable media of claim 9, wherein loading each of the at least two versions of the source dataset to memory comprises the steps performed in the method of the claim 5 and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines and further in view of KOSZEWNIK above.
Accordingly, claim 10 is rejected along the same rationale that rejected claim 5.
As per claim 16, the claim recites the computer-implemented method of claim 15, wherein loading each of the at least two versions of the source dataset to memory comprises the steps performed in the methods of the claims 5 and 6 in combination and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines and further in view of KOSZEWNIK above.
Accordingly, claim 16 is rejected along the same rationale that rejected claims 5 and 6 in combination.
Claims 11 and 17 are rejected under 35 U.S.C. § 103 as being unpatentable over
OraDBAdm in view of Hines, as being applied to claims 1-4, 7, 9, 12-13, 15, and 18-19 above, and further in view of
KOSZEWNIK, as being applied to claims 5-6, 10 and 16 above, and further in view of
Chen et al.: "PIPELINE LEVEL OPTIMIZATION OF AGGREGATION OPERATORS IN A QUERY PLAN DURING RUNTIME", (U.S. Patent Application Publication US 20210089535 A1, DATE PUBLISHED 2021-03-25 and DATE FILED 2020-04-24, hereafter "Chen").
As per claim 11, OraDBAdm in view of Hines and further in view of KOSZEWNIK teaches the one or more non-transitory computer-readable media of claim 10, wherein executing the structured query on two or more of the plurality of in-memory datasets comprises:
identifying, in the structured query, a distinguishing operator (See OraDBAdm: Page 14-49, Example 3: Displaying Statistics for Free Space (Extents) of Each Tablespace: To produce statistics about free extents and coalescing activity for each tablespace in the database, enter the following query:
SELECT TABLESPACE_NAME "TABLESPACE", FILE_ID,
COUNT(*) "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE",
SUM(blocks) "TOTAL"
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME, FILE_ID; Here distinguishing operators identified include MAX, MIN, AVG, SUM and COUNT)).
With respect to “identifying the first in-memory dataset and the second in-memory dataset as associated with the distinguishing operator”, OraDBAdm in view of Hines and further in view of KOSZEWNIK teaches identifying the first in-memory dataset and the second in-memory dataset with the distinguishing operator (See OraDBAdm: Page 31-24, Distributed SQL Statements:
“A received distributed query statement retrieves information from two or more nodes. For example, the following query accesses data from the local database as well as the remote sales database:
SELECT ename, dname
FROM scott.emp e, scott.dept@sales.us.americas.example_auto.com d
WHERE e.deptno = d.deptno;”; and at Page 31-15, lines 17-19,
“SELECT * FROM scott.emp@sales.division3.example.com; # emp table in scott's schema
SELECT loc FROM scott.dept@sales.division3.example.com;”,
Here the schema scott at the local default database and the schema scott at the remote databases teaches the schemas; and Hines: [0004], querying for data from a table stored in the distributed in-memory database).
However, OraDBAdm in view of Hines and further in view of KOSZEWNIK does not explicitly teach identifying the datasets as associated with the distinguishing operator.
On the other hand, as an analogous art on querying database, Chen teaches identifying the datasets as associated with the distinguishing operator (See [0032], the adaptive aggregation operator removes database records (e.g., rows) having duplicative values for particular attributes (e.g., aggregation keys of the adaptive aggregation operator). In at least some embodiments, the adaptive aggregation operator selectively and adaptively turns on and off during query execution based on information observed (by, e.g., the operator itself) at runtime, such observed information including the reduction rate of the aggregation operator, the selectivity of an associated join operator, the explosiveness of the associated join operator. Here the aggregation operator removing database records (e.g., rows) having duplicative values for particular attributes teaches the database associated distinguishing operator).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Chen’s teaching with OraDBAdm in view of Hines and further in view of KOSZEWNIK because Chen is dedicated to query-plan-enhancement and adaptive aggregation-evaluation techniques in database environment, KOSZEWNIK is dedicated to generating and operating on in-memory datasets, Hines is dedicated to deep linking invoking functionality of a remotely executing service and OraDBAdm is dedicated to computer languages which process data and in-memory database for continuous analytics and a combined teaching would have enabled OraDBAdm in view of Hines and further in view of KOSZEWNIK to store the entire snapshot in RAM instead of storing the entire source dataset for efficiently accessing data in the same network.
OraDBAdm in view of Hines and further in view of KOSZEWNIK and Chen further teaches:
the distinguishing operator deduplicating one or more records that are present in both the first in-memory dataset and the second in-memory dataset (See Chen: [0032], the adaptive aggregation operator removes database records (e.g., rows) having duplicative values for particular attributes (e.g., aggregation keys of the adaptive aggregation operator). In at least some embodiments, the adaptive aggregation operator selectively and adaptively turns on and off during query execution based on information observed (by, e.g., the operator itself) at runtime, such observed information including the reduction rate of the aggregation operator, the selectivity of an associated join operator, the explosiveness of the associated join operator. Here the aggregation operator removing database records (e.g., rows) having duplicative values for particular attributes teaches the database associated distinguishing operator), and
performing a deduplication operation corresponding to the distinguishing operator on the first in-memory dataset and the second in-memory dataset (See Chen: [0120], deduplicate its input stream of records with respect to its duplicate-removal-operator key(s), which may also be referred to as its deduplication key(s)).
As per claim 17, the claim recites the computer-implemented method of claim 16, wherein executing the structured query on two or more of the plurality of in-memory datasets comprises the steps performed in the method of the claim 11 and rejected under 35 U.S.C. § 103 as being unpatentable over OraDBAdm in view of Hines and further in view of KOSZEWNIK above.
Accordingly, claim 17 is rejected along the same rationale that rejected claim 11.
Related Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of Reference Cited.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS: A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201, 73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Contact Information
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUEN S LU whose telephone number is (571)272-4114. The examiner can normally be reached on M-F, 8-19, Mid-Flex 2 hours.
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, Mr. Ajay Bhatia can be reached on 5712723906. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
KUEN S LU /Kuen S Lu/
Art Unit 2156
Primary Patent Examiner
February 5, 2026
Prosecution Insights