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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 18, 2025 has been entered.
Response to Amendment
Applicant’s Amendments, filed November 18, 2025, have been entered. Claims 1, 4, 5, 7, 12, 15, 17 and 19 have been amended and claims 1-20 are currently pending.
Response to Arguments
Applicant’s arguments, see Remarks pp. 12-15, filed November 18, 2025, with respect to the rejections of claims 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Jonsson et al. (Pub. No. US 2017/0308606 A1, hereinafter “Jonsson”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 2, 5, 9, 10, 11, 12, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Harrison et al. (Patent No. US 9,886,483 B1, hereinafter “Harrison”) in view of Kalki (Patent No. US 9,244,971 B1, hereinafter “Kalki”) further in view of Jonsson.
Regarding claim 1, Harrison teaches:
one or more computer devices that implement a structured query language (SQL) database system, comprising: a SQL query engine configured to: dynamically load a multi-modal connector into memory, wherein the multi-modal connector is configured to fetch data from a non-SQL document store using a plurality of read modes, including: (Harrison – the database system includes a proxy layer, a SQL engine, and a storage engine including several plug-ins [Col. 4 lines 21-23]. The storage engine (i.e. multi-modal connector) can be a module that communicates with one or more back-end data stores, such as non-relational data stores. A storage engine interface of the storage engine can include an API that allows the SQL engine to communicate the execution plan instructions to the data stores. The storage engine also includes a storage engine client that provides access to configuration data about the data stores. Configuration data stored by the storage engine client can include connectivity information regarding how to connect (i.e. read mode) to a data store. The configuration data can reflect the data store(s) that each plug-in communicates with [Col. 4 lines 45-64]. A software module can reside in the RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, or any other form of non-transitory computer-readable storage medium [Col. 33 lines 60-67].)
a first read mode that treats data within an individual document in the non-SQL document store as multiple table rows, and a second read mode that treats individual documents in the non- SQL document store as individual table rows (Harrison –each plug-in can be designed to communicate with one or more different data stores. Some example non-relational data stores include Apache HBase and Cassandra (i.e. read mode that treats an individual document as multiple table rows) and Azure Table Services (i.e. treats individual documents as individual rows). Examiner interprets that the different plug-ins discloses different read modes.)
receive SQL queries directed to the non-SQL document store; and instruct the multi-modal connector to fetch data from the non-SQL document store in response to the SQL queries (Harrison - in Fig. 6, 602, the proxy layer of the database system receives an SQL query for a virtual table mapped to a non-relational data store. At block 604, the SQL engine generates a SQL execution plan for the SQL query. For each step in the SQL execution plan, at block 606, the query translator identifies one or more API calls or other calls for accessing the non-relational data store. The query translator then executes the API calls or other calls on the non-relational data store at block 608 [Col. 9 lines 7-28]. The query translation process can be implemented by the plug-ins [Col. 9 lines 4-6].)
of the SQL queries to the SQL query engine (Harrison – in Fig. 6, 610, the query translator receives data from the non-relational data store [Col. 9 lines 29-30].)
Harrison does not appear to teach:
the non-SQL document store, configured to: store a first document that include table data for a first table to be accessed using the first read mode[, wherein the first document stores multiple rows of the first table as an object array, each object in the object array representing one row in the first table]; store a second document that include table data for a second table to be accessed using the second read mode, [wherein the second document represents a single row in the second table]
, wherein the first document stores multiple rows of the first table as an object array, each object in the object array representing one row in the first table
wherein the second document represents a single row in the second table
and store a third document that include table metadata specifying respective read modes for the first and second tables
and the multi-modal connector, configured to: read the table metadata from the third document in response to SQL queries directed to the first or second table to determine which read mode to use for the first or second document
issue fetch calls to a data access interface of the non-SQL document store to fetch data from the first or second document using the first or second read mode according to the table metadata; and return data fetched from the first or second document as results
However, Kalki teaches:
the non-SQL document store, configured to: store a first document that include table data for a first table to be accessed using the first read mode[, wherein the first document stores multiple rows of the first table as an object array, each object in the object array representing one row in the first table]; store a second document that include table data for a second table to be accessed using the second read mode, [wherein the second document represents a single row in the second table] (Kalki – a datastore describes a data storage system storing any type of data in any type of storage format, using any type of data storage technology [Col. 2 lines 4-6]. A data attribute may correspond to a column in a table (e.g., in a relational database) or may correspond to a searchable data element in a non-relational datastore [Col. 2 lines 48-50]. The non-relational datastore(s) may include key-value datastores (i.e. a first document that includes table data for a first table, see Applicant’s Specification [0025-0026], where the type A connector is configured to treat data in a single document as a set of multiple table rows, and where each document may be associated with a key value), hash tables, flat files (i.e. a second document that include table data for a second table), associative arrays, or other types of data structures, or unstructured data storage [Col. 4 lines 40-57]. For each requested data attribute in the syntax tree of the data report request, the query compiler module may determine a datastore from which to retrieve data for the requested data attribute, and generate at least one query to retrieve the data. The at least one query may also include the requested conditions and ordering, may be generated in a query language that is supported by the datastore (i.e. first read mode and second read mode) that is supported by the datastore as indicated by the storage metadata [Col. 3 lines 58-65].)
and store a third document that include table metadata specifying respective read modes for the first and second tables (Kalki – the query compiler module may traverse the syntax tree of the data report request, and for each requested data attribute in the syntax tree, determine a datastore from which to retrieve data for the data attribute. This determination may be based on storage metadata that describes which datastores store data for which data attributes. The storage metadata may also include other information, including information regarding query languages supported by one or more datastores, and data quality information [Col. 3 lines 29-38]. The non-relational datastore(s) may store metadata describing data attributes or other aspects of the stored data [Col. 4 lines 48-50].)
and the multi-modal connector, configured to: read the table metadata from the third document in response to SQL queries directed to the first or second table to determine which read mode to use for the first or second document (Kalki – for each requested data attribute in the syntax tree of the data report request, the query compiler module (i.e. multi-modal connector) may determine a datastore from which to retrieve data for the requested data attribute, and generate at least one query to retrieve the data. The at least one query may also include the requested conditions and ordering, may be generated in a query language that is supported by the datastore (i.e. determine which read mode) as indicated by the storage metadata [Col. 3 lines 58-65].)
issue fetch calls to a data access interface of the non-SQL document store to fetch data from the first or second document using the first or second read mode according to the table metadata; and return data fetched from the first or second document as results (Kalki – the one or more queries generated to retrieve data requested in the data report request may be included in a query plan, which is executed (i.e. issue fetch calls) by a query execution module. The query execution module may execute one or more queries of the query plan to retrieve data from datastore(s) in one or more data warehouse(s) and receive the result(s) of the query plan execution [Col. 3 lines 65-67, Col. 4 lines 1-7].)
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 Harrison and Kalki before them, to modify the system of Harrison with the teachings of Kalki, as indicated above. One would have been motivated to make such a modification to enable the data consumer(s) or other users to access the large quantities of heterogeneously stored data in the data warehouse(s) without requiring the users to have any particular knowledge of the native query languages or the underlying structure of the datastores in the data warehouse(s) (Kalki - [Col. 5 lines 51-56]).
Harrison modified by Kalki does not appear to teach:
, wherein the first document stores multiple rows of the first table as an object array, each object in the object array representing one row in the first table
wherein the second document represents a single row in the second table
However, Jonsson teaches:
, wherein the first document stores multiple rows of the first table as an object array, each object in the object array representing one row in the first table (Jonsson – the term “document” generally refers to a document or record and its associated data within a database and may be any object that contains a list of key-value pairs, wherein each key is a string and the value is either another object, an array (i.e., a list of objects), or a simple value that may be a string or a number [0025].)
wherein the second document represents a single row in the second table (Jonsson – the term “document” generally refers to a document or record and its associated data within a database and may be any object that contains a list of key-value pairs, wherein each key is a string and the value is either another object, an array (i.e., a list of objects), or a simple value that be may be a string or a number [0025].)
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 Harrison, Kalki and Jonsson before them, to modify the system of Harrison and Kalki with the teachings of Jonsson, as indicated above. One would have been motivated to make such a medication to allow document databases to be queried using typical relational query languages to better combine query results from relational and document databases [0006].)
Claims 12 and 19 correspond to claim 1 and are rejected accordingly.
Regarding claim 2, Harrison does not appear to teach:
wherein the multi-modal connector is configured to: issue an update request to change the first read mode of the first table, wherein the update request causes the non-SQL document store to update the third document to change the first read mode of the first table
However, Kalki teaches:
wherein the multi-modal connector is configured to: issue an update request to change the first read mode of the first table, wherein the update request causes the non-SQL document store to update the third document to change the first read mode of the first table (Kalki – the storage metadata module may periodically poll the datastores of the data warehouse(s) to determine or update the storage metadata. The storage metadata module may also receive information from other modules executing on the report processing server device or elsewhere, and use that information to update the storage metadata [Col. 14 lines 16-22].)
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 Harrison, Kalki and Jonsson before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Kalki, as indicated above1. One would have been motivated to make such a modification to enable the data consumer(s) or other users to access the large quantities of heterogeneously stored data in the data warehouse(s) without requiring the users to have any particular knowledge of the native query languages or the underlying structure of the datastores in the data warehouse(s) (Kalki - [Col. 5 lines 51-56]).
Claims 13 corresponds to claim 2 and are rejected accordingly.
Regarding claim 5, Harrison does not appear to teach:
wherein the non-SQL document store implements a document data search engine configured to search one or more documents in the non-SQL document store based on object search predicates specified in the fetch calls
However, Kalki teaches:
wherein the non-SQL document store implements a document data search engine configured to search one or more documents in the non-SQL document store based on object search predicates specified in the fetch calls (Kalki – a data attribute may correspond to a column in a table (e.g., in a relational database) or may correspond to a searchable data element in a non-relational datastore (Col. 2 lines 44-50). Also see Fig. 3 306 (conditions, i.e. search predicates) and Col. 9 lines 34-52, where the user interface may enable a user to specify one or more conditions to be applied to the selected data attribute, and the conditions may indicate that data of a specified value, within a specified set of values, or within a specified range of values is to be retrieved (i.e. fetched) from the datastore(s) to generate the data report.)
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 Harrison, Kalki and Jonsson before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Kalki, as indicated above1. One would have been motivated to make such a modification to enable the data consumer(s) or other users to access the large quantities of heterogeneously stored data in the data warehouse(s) without requiring the users to have any particular knowledge of the native query languages or the underlying structure of the datastores in the data warehouse(s) (Kalki - [Col. 5 lines 51-56]).
Regarding claim 9, Harrison does not appear to teach:
wherein the first read mode of the first table is set in the third document when the first table is created
However, Kalki teaches:
wherein the first read mode of the first table is set in the third document when the first table is created (Kalki – for each requested data attribute in the syntax tree of the data report request, the query compiler module (i.e. multi-modal connector) may determine a datastore from which to retrieve data for the requested data attribute, and generate at least one query to retrieve the data. The at least one query may also include the requested conditions and ordering, may be generated in a query language that is supported by the datastore (i.e. determine which read mode) as indicated by the storage metadata [Col. 3 lines 58-65].)
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 Harrison, Kalki and Jonsson before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Kalki, as indicated above1. One would have been motivated to make such a modification to enable the data consumer(s) or other users to access the large quantities of heterogeneously stored data in the data warehouse(s) without requiring the users to have any particular knowledge of the native query languages or the underlying structure of the datastores in the data warehouse(s) (Kalki - [Col. 5 lines 51-56]).
Regarding claim 10, Harrison teaches:
wherein: the non-SQL document store is hosted by a platform-as-a-service provider; and to issue the fetch calls, the multi-model connector is configured to communicate with a service interface provided by the platform -as-a-service provider (Harrison – some example non-relational datastores include Apache Hadoop HBase, Amazon SimpleDB, Azure Table Services (i.e. platform-as-a-service provider) [Col. 5 lines 5-17]. The translator executes the API calls or other calls (i.e. one or more calls) on the non-relational data store at block 608 [Col. 9 lines 26-28, also see Col. 5 lines 1-4, where the plug-in translates instructions into one or more API calls, other remote procedure calls, web service calls, REST calls, or the like to one or more data stores]. The storage engine can be a module that communicates with one or more back-end data stores in Fig. 1, 130a, such as non-relational data stores (i.e. non-SQL document store). A storage engine interface of the storage engine can include an API that allows the SQL engine to communicate the execution plan instructions to the data stores. Configuration data stored by the storage engine client can include connectivity information regarding how to connect to a data store. The configuration data can reflect the data store(s) in Fig. 1, 130a, that each plug-in 120a communicates with. The storage engine receives the execution plan instructions from the storage engine interface and selects one or more plug-ins to send the instructions based on the configuration data [Col. 4 lines 45-67, Col. 5 lines 1-4].)
Regarding claim 11, Harrison teaches:
wherein the SQL query engine configured to perform SQL queries on another type of non-SQL document store using another type of connector adapted to communicate with the other type of non-SQL document store (Harrison – the storage engine can be a module that communicates with one or more back-end data stores in Fig. 1, 130a, such as non-relational data stores (i.e. non-SQL document store). A storage engine interface of the storage engine can include an API that allows the SQL engine to communicate the execution plan instructions to the data stores. Configuration data stored by the storage engine client can include connectivity information regarding how to connect to a data store. The configuration data can reflect the data store(s) in Fig. 1, 130a, that each plug-in 120a (i.e. different types of connectors for other types of non-SQL document stores) communicates with [Col. 4 lines 45-64].)
Claims 3, 4, 14, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Harrison in view of Kalki in view of Jonsson in view of Gillett et al. (Pub. No. US 2015/0227514 A1, hereinafter “Gillett”).
Regarding claim 3, Harrison does not appear to teach:
wherein the non-SQL document store is configured to: in response to the change of the first read mode of the first table,
convert the first document into one or more documents with a different storage format
However Kalki teaches:
wherein the non-SQL document store is configured to: in response to the change of the first read mode of the first table, (Kalki – the storage metadata module may periodically poll the datastores of the data warehouse(s) to determine or update the storage metadata. The storage metadata module may also receive information from other modules executing on the report processing server device or elsewhere, and use that information to update the storage metadata [Col. 14 lines 16-22].)
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 Harrison, Kalki and Jonsson before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Kalki of wherein the non-SQL document store is configured to: in response to the change of the first read mode of the first table. One would have been motivated to make such a modification to enable the data consumer(s) or other users to access the large quantities of heterogeneously stored data in the data warehouse(s) without requiring the users to have any particular knowledge of the native query languages or the underlying structure of the datastores in the data warehouse(s) (Kalki - [Col. 5 lines 51-56]).
Harrison modified by Kalki does not appear to teach:
wherein the non-SQL document store is configured to: in response to the change of the first read mode of the first table
However, Gillett teaches:
convert the first document into one or more documents with a different storage format (Gillett – the document management and collaboration system may then receive the document and corresponding information. For example, the document and corresponding information may be transmitted to the document management and collaboration system in an API call from the developer. The document management and collaboration system may then update metadata corresponding to the document in a database. For example, the document management and collaboration system may write the location of the document into the database as described above in connection to Fig. 4. Once the document is received it may be determined if the document is in an appropriate format. If the document is not in the appropriate format it may be converted to the appropriate format [0065].)
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 Harrison, Kalki, Jonsson and Gillett before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Gillett, as indicated above. One would have been motivated to make such a modification to allow for users to collaborate on documents of different file formats (Gillett - [0016]).
Claim 14 corresponds to claim 3 and is rejected accordingly.
Claim 20 corresponds to claims 2 and 3 and is rejected accordingly.
Regarding claim 4, Harrison modified by Kalki and Jonsson does not appear to teach:
wherein the conversion is performed via a running process, and the first document continues to be accessible during the conversion
However, Gillett teaches:
wherein the conversion is performed via a running process, and the first document continues to be accessible during the conversion (Gillett – see [0032], where a single document in the non-relational MongoDB may be converted to at least one table or several tables in a relational model (i.e. first document in MongoDB is still accessible).)
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 Harrison, Kalki, Jonsson and Gillett before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Gillett, as indicated above. One would have been motivated to make such a modification to allow for users to collaborate on documents of different file formats (Gillett - [0016]).
Claim 15 corresponds to claim 4 and is rejected accordingly.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Harrison in view of Kalki in view of Jonsson in view of Attaluri et al. (Patent No. US 11,615,083 B1, hereinafter “Attaluri”).
Regarding claim 6, Harrison teaches:
non-SQL document store (Harrison – the storage engine can be a module that communicates with one or more back-end data stores in Fig. 1, 130a, such as non-relational data stores (i.e. non-SQL document store). A storage engine interface of the storage engine can include an API that allows the SQL engine to communicate the execution plan instructions to the data stores. Configuration data stored by the storage engine client can include connectivity information regarding how to connect to a data store. The configuration data can reflect the data store(s) in Fig. 1, 130a, that each plug-in 120a (i. different types of connectors) communicates with [Col. 4 lines 45-64].)
Harrison modified by Kalki and Jonsson does not appear to teach:
wherein: the [non-SQL] document store stores objects in the first document in a compressed form; and the multi-modal connector is configured to decompress the objects in the compressed form
However, Attaluri teaches:
wherein: the [non-SQL] document store stores objects in the first document in a compressed form; and the multi-modal connector is configured to decompress the objects in the compressed form (Attaluri – the storage systems may organize data into volumes, where each logical volume may be segmented over a collection of storage nodes, and each segment may store a collection of one or more data pages and a change log for each data page that it stores [Col. 13 lines 62-67, Col. 14 lines 1-6]. A log page may be a type of page that is used to store log records, and log records may be of several different classes [Col. 15 lines 18-31]. Storage systems may be have various types of log records within each of these classes, and the type of a log record may correspond to a function that needs to be invoked to interpret the log record. For example, one type may represent all the data of a user page in compressed format using a specific compression format [Col. 15 lines 41-46]. Examiner interprets that the function that needs to be invoked to interpret a log record in compressed format requires decompression.)
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 Harrison, Kalki, Jonsson and Attaluri before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Attaluri, as indicated above. One would have been motivated to make such a modification to save storage space.
Claim 16 corresponds to claim 6 and is rejected accordingly.
Claims 7, 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Harrison in view of Kalki in view of Jonsson in view of Jain et al. (Patent No. US 11,755,620 B1, hereinafter “Jain”).
Regarding claim 7, Harrison modified by Kalki and Jonsson does not appear to teach:
wherein the multi-modal connector is configured to translate a query predicate of a SQL query into an object search predicate and instruct the non-SQL document store to search for data using the object search predicate
However, Jain teaches:
wherein the multi-modal connector is configured to translate a query predicate of a SQL query into an object search predicate and instruct the non-SQL document store to search for data using the object search predicate (Jain – client may send a query language request to the endpoint, which may be routed to the query language query engine (i.e. multi-modal connector). Query language query engine may determine what APIs to invoke and send the appropriate requests to storage nodes that store data for the targeted non-relational database in the request [Col. 11 lines 24-31]. The determined API(s) may be executed. For example, parameters for the API(s) may be recognized or determined from the request (e.g., identifiers for target objects, such as tables, values for predicates or other conditions, values for manipulating or adding data, etc.). Instructions, workflows, or other invocations of the API(s) may be generated with determined parameters and provided to the non-relational database component executing the API(s). As indicated in Fig. 8, 840, a result for the request based on the execution of the determined API(s) may be returned. For example, API(s) may be executed resulting in one or multiple portions of data, which may then be combined and returned as a result [Col. 13 lines 18-31].)
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 Harrison, Kalki, Jonsson and Jain before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Jain, as indicated above. One would have been motivated to make such a modification to expand the accessibility of non-relational databases (Jain - [Col. 1 lines 21-23]).
Claim 17 corresponds to claim 7 and is rejected accordingly.
Regarding claim 8, Harrison modified by Kalki and Jonsson does not appear to teach:
wherein: the non-SQL document store is configured to return a result token that allows the multi-modal connector to scroll through returned objects in successive pages; and the multi-modal connector is configured to scroll through the pages using the result token
However, Jain teaches:
wherein: the non-SQL document store is configured to return a result token that allows the multi-modal connector to scroll through returned objects in successive pages; and the multi-modal connector is configured to scroll through the pages using the result token (Jain –non-relational database service may include support for some or all of the following operations on data maintained by a table (or index) by the service on behalf of a storage service client: perform a transaction (inclusive of one or more operations on one or more items in one or more tables), query for items using an index, and scan (e.g. list items) over the whole table, optionally filtering the items returned, or conditional variations on the operations described above [Col. 8 lines 43-63].)
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 Harrison, Kalki, Jonsson and Jain before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Jain, as indicated above. One would have been motivated to make such a modification to expand the accessibility of non-relational databases (Jain - [Col. 1 lines 21-23]).
Regarding claim 18, Harrison modified by Kalki and Jonsson does not appear to teach:
wherein: the non-SQL document store is configured to return a result token that allows the multi-modal to scroll through returned objects in successive pages; and the method includes the multi-modal connector scrolling through the pages using the result token
However, Jain teaches:
wherein: the non-SQL document store is configured to return a result token that allows the multi-modal to scroll through returned objects in successive pages; and the method includes the multi-modal connector scrolling through the pages using the result token (Jain –non-relational database service may include support for some or all of the following operations on data maintained by a table (or index) by the service on behalf of a storage service client: perform a transaction (inclusive of one or more operations on one or more items in one or more tables), query for items using an index, and scan (e.g. list items) over the whole table, optionally filtering the items returned, or conditional variations on the operations described above [Col. 8 lines 43-63].)
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 Harrison, Kalki, Jonsson and Jain before them, to modify the system of Harrison, Kalki and Jonsson with the teachings of Jain, as indicated above. One would have been motivated to make such a modification to expand the accessibility of non-relational databases (Jain - [Col. 1 lines 21-23]).
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