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 .
DETAILED ACTION
The Action is responsive to the Remarks filed on 2/5/2026. Claims 1-22 are pending claims. Claims 1, 8, and 15 are written in independent form.
Claim Interpretation
Claims 1, 8, and 15 recite the phrase “configured to deserialize” which is not being given patentable weight because it merely means that the library structure has the configuration to perform a deserializing step, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “configured to deserialize” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 1, 8, and 15 recite the limitation “the data ecosystem comprising a library structure configured to deserialize the first model structure” which is being interpreted to have a scope of “a data ecosystem comprising a library structure”. It is noted that a later limitation does actively recite “using the library structure at the uploader to deserialize…”.
Claims 1, 8, and 15 recite the phrase “configured to initiate a transfer” which is not being given patentable weight because it merely means that the item has the configuration to perform an initiating step, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “configured to initiate” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 1, 8, and 15 recite the limitation “receiving a command signal configured to initiate a transfer of at least a part of the one or more results sets from the database to a cloud-based storage service” which is being interpreted to have a scope of “receiving a command signal”. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 1, 8, and 15 recite the phrase “to return” which is not being given patentable weight because it merely means an intent to perform a returning step, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “to return” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 1, 8, and 15 recite the limitation “an interface that invokes the library structure to return deserialized data to an outside requester” which is being interpreted to have a scope of “an interface that invokes the library structure”. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 1, 8, and 15 recite the phrase “to transfer” which is not being given patentable weight because it merely means the intent to perform a transfer step at a future time, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “to transfer” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 1, 8, and 15 recite the limitation “calling an uploader…to transfer the part of the one or more results sets to the cloud-based storage service” which is being interpreted to have a scope of “calling the uploader”. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 2, 9, and 16 recite the phrase “configured to interface…to copy…” which is not being given patentable weight because it merely means that the item has the configuration to perform an interfacing and then copying step, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “configured to interface…to copy…” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 2, 9, and 16 recite the limitation “the uploader device configured to interface with the legacy data storage device to copy the database from a shared storage location” which is being interpreted to have a scope of “receiving a command signal”. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 4, 11, and 18 recite the phrase “performing a handshake process…to download a certificate…” which is not being given patentable weight because it merely means the intent to perform a downloading step at a future time, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “to download” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 4, 11, and 18 recite the limitation “performing a handshake process between the uploader and the cloud-based storage service to download a certificate” which is being interpreted to have a scope of “performing a handshake process between the uploader and the cloud-based storage service”. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 7 and 14 recite the phrase “the uploader configured to listen for the API call…” which is not being given patentable weight because it merely means the uploader is capable of listening, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “configured to listen” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 7 and 14 recite the limitation “the uploader configured to listen for the API call to initiate the transfer” which is being interpreted to have no meaningful scope. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
Claims 7 and 14 recite the phrase “the API call to initiate the transfer” which is not being given patentable weight because it merely means the intent to initiate the transfer step at a future time, but is not actively performing any step/limitation. Therefore, any step being referred to by the term “the API call to initiate the transfer” is also not being given patentable weight as the step(s) are not actively being performed. Examiner suggests to amend the claim limitations to recite all of the steps in a positive manner.
Claims 7 and 14 recite the limitation “the uploader configured to listen for the API call to initiate the transfer” which is being interpreted to have no meaningful scope. For the purpose of compact prosecution, the limitation is being addressed herein as if all of the steps are recited in a positive manner.
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.
Claim(s) 1-3, 5, 7-10, 12, 14-17, 19, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Yamato et al. (U.S. Pre-Grant Publication No. 2021/0303586, hereinafter referred to as Yamato), and further in view of Elkabetz et al. (U.S. Pre-Grant Publication No. 2021/0165129, hereinafter referred to as Elkabetz) and Gilder et al. (U.S. Pre-Grant Publication No. 2014/0040182, hereinafter referred to as Gilder).
Regarding Claim 1:
Yamato teaches a computer-implemented method comprising:
Accessing a database for a data ecosystem storing one or more results sets according a first model structure,
Yamato teaches a data processing service 100 accessing sensing data DB 200 that “stores various items of sensing data (an example of real data)” (Para. [0038]) and “the ETL server 400 extracts (E) data from the sensing data DB 200, transforms (T) the extracted data into a form suitable for analysis, and loads (L) the resultant data into the analysis data DB 300” (Para. [0052]).
Yamato further teaches storing data according to a first model structure by teaching:
“FIG. 3 is a diagram describing the data formats of the data items stored in the sensing data DB 200. As shown in FIG. 3, a first data format includes sensing data (real data) (with no metadata). In the first data format, the sensing data includes a value V11 generated by a sensor.
A second data format includes sensing data and metadata in different data units. In the second data format, the sensing data includes an ID and a value V21 generated by a sensor. The ID is determined in the manner described in detail later. The metadata includes an ID and a value V22 indicating the attribute of the sensing data. The sensing data and the metadata are associated with each other with a common ID included in the sensing data and the metadata.
A third data format includes sensing data and metadata that together form a single data unit. In the third data format, the data unit includes a value V31 generated by a sensor and metadata stored in the header.” (Paras. [0049]-[0051]).
the data ecosystem comprising:
a library structure configured to deserialize the first model structure, and
Yamato further teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching a library structure configured to deserialize a first data format.
An interface that invokes the library structure to return deserialized data to an outside requester,
Yamato further teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching a library structure configured to deserialize a first data format, the data format determiner 110 part of the data processing apparatus 100.
Yamato further teaches using the data format determiner 110 to normalize the data, whether it’s in the first data format or the third data format, into the second data format (Paras. [0075]-[0077]) and transforming the data based on “a transformation rule predefined for each type of sensing data” (Para. [0068]).
Yamato also teaches an interface by teaching the data processing server 100 includes a controller 170, a communication interface (I/F) 190, and a storage 180. The components are electrically connected to one another with a bus 195. (Para. [0057]) and “The communication I/F 190 communicates with external devices external to the data processing server 100” (Para. [0059]).
Receiving a command signal configured to initiate a transfer of at least a part of the one or more results sets from the database to an extract, transform, and load (ETL) service provided in a storage service;
Yamato teaches “The software modules start the processing in response to the data extractor 402 included in the ETL server 400 requesting the sensing data DB 200 to transmit data [to the ETL as shown in the flow of data in Fig. 5]. More specifically, the data extractor 402 transmits an application programming interface (API) command for requesting the sensing data DB 200 to transmit data. This causes transmission of a data item stored in the sensing data DB 200 to the data format converter 102. The processing is started in this manner.” (Para. [0064]).Yamato further teaches a storage service by teaching “The storage 180 is, for example, an auxiliary storage device such as a hard disk drive or a solid state drive.” (Para.[0057]) and “The storage 180 stores, for example, a control program 181” (Para. [0060]).
It is noted that a an ETL provided in a cloud-based storage service is also merely a design choice of where to store and process the data.
Calling an uploader provided in a local data service upstream of the ETL service to transfer the part of the one or more results sets to the storage service, wherein the uploader includes a copy of the library structure of the data ecosystem;
Yamato teaches “the data extractor 402 transmits an application programming interface (API) command for requesting the sensing data DB 200 to transmit data” (Para. [0064]) where the extractor 402 is part of ETL server 400 (Fig. 13) thereby teaching calling an uploader to extract data from sensing data DB 200. Yamato further teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching that the extractor includes a copy of the library structure in order to determine the different formats of the data.
Yamato teaches a data processing apparatus 100 upstream from an ETL tool 400 (Figs. 1, 5, & 13). A “local data service” is merely a service that is provided at a local location. It is noted that an uploader provided in a local data service is also merely a design choice of where to perform the uploader function. It is also noted that “a local data service” does not specify local to what, and therefore any data service can be considered a local data service given its broadest reasonable interpretation.
Retrieving, by the uploader, the part of the one or more results sets from the database for the data ecosystem, and
Yamato further teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) and using the data format determiner 110 to normalize the data, whether it’s in the first data format or the third data format, into the second data format (Paras. [0075]-[0077]) and transforming the data based on “a transformation rule predefined for each type of sensing data” (Para. [0068]).Yamato teaches the data format determiner 110 retrieving the result sets by teaching the data being sent from Sensing data DB 200 to the Data format determiner 110 of Data format converter 102 (Fig. 6).Yamato further explicitly teaches retrieval of requested sensing data as a way to obtain the sensing data by teaching “The system allows the user to refer to metadata and retrieve sensing data that meets the user's requests” (Para. [0003]).
Using the library structure at the uploader to deserialize the part of the one or more results sets into a second model structure without using the interface of the data ecosystem and without running the at least one of the security system or the auditing protocol associated with the interface; and
Yamato further teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching a library structure configured to deserialize a first data format, the data format determiner 110 part of the data processing apparatus 100.
Yamato further teaches using the data format determiner 110 to normalize the data, whether it’s in the first data format or the third data format, into the second data format (Paras. [0075]-[0077]) and transforming the data based on “a transformation rule predefined for each type of sensing data” (Para. [0068]).
Yamato teaches the data format determiner 110 without the use or mentioning of an interface or running any security system or auditing protocol (Paras. [0074]-[0077]).
Storing the part of the one or more results sets with the storage service according to the second model structure.
Yamato teaches “the ETL server 400 extracts (E) data from the sensing data DB 200, transforms (T) the extracted data into a form suitable for analysis, and loads (L) the resultant data into the analysis data DB 300” (Para. [0052]) thereby teaching storing the transformed data into the target database according to the transformed data structure.
Yamato explicitly teaches all of the elements of the claimed invention as recited above except:
a cloud-based storage service, and
However, in the related field of endeavor of collecting and processing data from data sources, Elkabetz explicitly teaches:
a cloud-based storage service, and
Elkabetz teaches “ In some implementations, the servers may be physically located together, or they may be distributed in remote locations, such as in shared hosting facilities or in virtualized facilities (e.g. “the cloud”).” (Para.[0047]) and “The system database may also include an external database server or database service such as a cloud-based data storage service” (Para. [0067]).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Elkabetz and Yamato at the time that the claimed invention was effectively filed, to have modified the systems and methods for performing an ETL process, as taught by Yamato, with the use of derived data, as taught by Elkabetz.
One would have been motivated to make such modification because Elkabetz teaches “the system updates only the previously determined forecasts and derived data that are affected by the subset of forecast data that was determined to be inaccurate in light of newly collected data. In this manner, computations become significantly faster and more efficient, reducing computing resource requirements and computing time” (Para. [0131]).
Elkabetz and Yamato explicitly teach all of the elements of the claimed invention as recited above except:
wherein the interface runs at least one of a security system or an auditing protocol associated with the interface;
However, in the related field of endeavor of collecting and consolidating heterogeneous remote data, Gilder explicitly teaches:
wherein the interface runs at least one of a security system or an auditing protocol associated with the interface;
Gilder teaches running an “auditing system enabled by the present invention’s ETL capability” (Para. [0040]) where “Utilizing the unique properties of the data replication and ETL system, a unique and automated "Automatic Royalty Generation" system with "built-in auditing" can be operated” (Para. [0179]) thereby teaching “an auditing protocol associated with the interface”.It is noted that auditing is understood as a form of security, and therefore Gilder also teaches a security system in the form of an auditing system.
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Gilder, Elkabeetz, and Yamato at the time that the claimed invention was effectively filed, to have modified the use of derived data, as taught by Elkabetz, and the systems and methods for performing an ETL process, as taught by Yamato, with the use of scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs, as taught by Gilder.
One would have been motivated to make such a modification because Gilder teaches additional types of interpretable or executable code mechanisms that can be used for data collection and ETL (Abstract & Para. [0151]) not taught by Yamato, and it would have been obvious to have included the different interpretable or executable code mechanisms to broaden the data collection and ETL abilities taught by Yamato.
Regarding Claim 2:
Gilder, Elkabetz, and Yamato further teach:
Wherein the database is provided on a legacy data storage device and
The broadest reasonable interpretation of a legacy data storage device is a storage device that stores data that is outdated. Yamato further teaches storing data in sensing data DB 200 generated by a sensor that may include “an image sensor (camera), a temperature sensor, a humidity sensor, an illumination sensor, a force sensor, a sound sensor, a radio frequency identification (RFID) sensor, an infrared sensor, a posture sensor, a rain sensor, a radiation sensor, and a gas sensor” (Para. [0047]). Therefore, the sensor data being stored may be outdated within seconds or minutes of storage when sensed data such as temperature and humidity can change quickly, thus making it legacy data under BRI.
It is noted that Yamato also teaches:
“In the first and second embodiments, data stored in the sensing data DB 200 and data processed by the data processing server 100 or 100A are sensing data. In some embodiments, the sensing data DB 200 and the data processing server 100 or 100A may store or process data other than sensing data. For example, the sensing data DB 200 and the data processing server 100 or 100A may store or process data indicating the purchase history of a user at a shopping site, data indicating a score of a user at a game site, or any data other than sensing data.” (Para. [0124])
wherein the uploader is provided on an uploader device separate from the legacy data storage device, the uploader device configured to interface with the legacy data storage device to copy the database from a shared storage location.
Yamato teaches “The communication I/F 190 communicates with external devices external to the data processing server 100 (e.g., the sensing data DB 200, the analysis data DB 300, the ETL server 400, and the ID management server 500 shown in FIG. 2) through the Internet. The communication I/F 190 includes, for example, a wired local area network (LAN) module and a wireless LAN module.” (Para. [0059]). Yamato also teaches “the software modules start the processing in response to the data extractor 402 included in the ETL server 400 requesting the sensing data DB 200 to transmit data” (Para. [0064]). Therefore, Yamato teaches the ETL device separate from at least the sensing data DB 200 and configured to interface with the sensing data DB 200 for extracting data from the sensing data DB 200.
Regarding Claim 3:
Gilder, Elkabetz, and Yamato further teach:
Wherein the database is associated with one or more derived channels,
Yamato teaches “the sensing data DB 200 stores sensing data items generated by such various sensors. Thus, the data items stored in the sensing data DB 200 may not be in the same data format. For example, the sensing data DB 200 stores data items in different data formats.” (Para. [0048]).
The one more derived channels comprising data that is not directly measured by the data ecosystem but derived from directly measured data or another derived channel,
Elkabetz teaches “the data that is generated and stored includes collected data, data derived or calculated from the collected data, forecast data generated during the forecast cycles of the cadence instance, and information that is further generated or derived from the forecast data” (Para. [0072]) thereby teaching a database storing derived data from directly measured data.
Wherein the uploader users the library structure to generate information for the derived channels.
Yamato teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching using a library structure to generate information for each of the different data formats from the various sensors.
Regarding Claim 5:
Gilder, Elkabetz, and Yamato further teach:
Wherein the command signal is received:
In response to a database trigger executed automatically when the one or more results sets are created or modified;
Elkabetz teaches “input and output is processed and modeled in real time, in a time delayed mode, in batch mode, respectively, either simultaneously or asynchronously, and shared between system components on various servers using network communications, notifications, messages, common storage, or other means in common use for such purposes. The described architecture segregates programs and processes that have different attributes, including the programs and processes that are periodically performed on a scheduled routine or basis, batch collection and loading of data, computation intensive and parallel processing modeling, and user interface, onto separate servers for purposes of clarity of presentation. Alternatively, or in addition, other processing arrangements may be used to implement the system of the present invention.” (Para. [0046]) thereby teaching a database trigger to be executed for batch collection and loading of data when result sets are created or modified.
Regarding Claim 7:
Gilder, Elkabetz, and Yamato further teach:
In response to receiving the command signal, running a stored procedure within the database configured to send an application programming interface (API) call to the uploader, the uploader configured to listen for the API call to initiate the transfer.
Yamato teaches “The software modules start the processing in response to the data extractor 402 included in the ETL server 400 requesting the sensing data DB 200 to transmit data. More specifically, the data extractor 402 transmits an application programming interface (API) command for requesting the sensing data DB 200 to transmit data. This causes transmission of a data item stored in the sensing data DB 200 to the data format converter 102. The processing is started in this manner.” (Para. [0064]). Therefore, Yamato teaches using API calls to request data to be uploaded and thus a listener to listen for the API requesting to upload data.
Regarding Claim 8:
Some of the limitations herein are similar to some or all of the limitations of Claim 1.
Gilder, Elkabetz, and Yamato further teach:
A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium including instructions that when executed by a computer, cause the computer to perform operations (Yamato – Para. [0111]) & Claim 6).
Regarding Claim 9:
All of the limitations herein are similar to some or all of the limitations of Claim 2.
Regarding Claim 10:
All of the limitations herein are similar to some or all of the limitations of Claim 3.
Regarding Claim 12:
All of the limitations herein are similar to some or all of the limitations of Claim 5.
Regarding Claim 14:
All of the limitations herein are similar to some or all of the limitations of Claim 7.
Regarding Claim 15:
Some of the limitations herein are similar to some or all of the limitations of Claim 1.
Gilder, Elkabetz, and Yamato further teach a computing apparatus comprising:
A processor (Yamato – Para. [0111]) & Claim 6); and
A memory storing instructions that, when executed by the processor, configure the apparatus to perform operations (Yamato – Para. [0111]) & Claim 6).
Regarding Claim 16:
All of the limitations herein are similar to some or all of the limitations of Claim 2.
Regarding Claim 17:
All of the limitations herein are similar to some or all of the limitations of Claim 3.
Regarding Claim 19:
All of the limitations herein are similar to some or all of the limitations of Claim 5.
Regarding Claim 21:
Gilder, Elkabetz, and Yamato further teach:
Wherein the library comprises one or more dynamic link libraries (DLLs).
Gilder teaches retrieving and processing data from a remote data source (abstract) where “The computer code devices of the present invention may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs. Moreover, parts of the processing of the present invention may be distributed for better performance, reliability, and/or cost.” (Para. [0151]).It is further noted that the claims do not recite necessarily or actively using the DLL files to necessarily perform any steps, just that the library comprises one or more dynamic link libraries.
Regarding Claim 22:
Gilder, Elkabetz, and Yamato further teach:
Storing the second data structure in a relational data store optimized for read access.
Yamato teaches “the data format determiner 110 is a software module that determines the data format of input data” and “determines whether the input data is in the first, second, or third data format described above” (Para. [0074]) thereby teaching a library structure configured to deserialize a first data format, the data format determiner 110 part of the data processing apparatus 100.
Yamato further teaches using the data format determiner 110 to normalize the data, whether it’s in the first data format or the third data format, into the second data format (Paras. [0075]-[0077]), transforming the data based on “a transformation rule predefined for each type of sensing data” (Para. [0068]) and “the ETL server 400 extracts (E) data from the sensing data DB 200, transforms (T) the extracted data into a form suitable for analysis, and loads (L) the resultant data into the analysis data DB 300” (Para. [0052]) thereby teaching storing the transformed data into the target database according to the transformed data structure.
Elkabetz further teaches the data store being optimized for read access by teaching “It should be noted that the physical processing and storage system have the data being read and written directly to one or more system databases, and organized within those databases so that the subsequent data access steps are efficient.” (Para. [0068]).
It is also noted that Applicant’s specification states that “Relational databases are generally optimized to perform data reads” (Specification Para. [0015]) thereby teaching a relational data store optimized for read access was generally/well known to a person having ordinary skill in the art at the time that the application was effectively filed.
Claim(s) 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gilder, Elkabetz, and Yamato, and further in view of Schmitt et al. (U.S. Pre-Grant Publication No. 2022/0174096, hereinafter referred to as Schmitt).
Regarding Claim 4:
Gilder, Elkabetz, and Yamato explicitly teach all of the elements of the claimed invention as recited above except:
Performing a handshake process between the uploader and the cloud-based storage service to download a certificate,
The certificate linked to a tenancy on the cloud-based storage service;
Prior to storing the part of the one or more results sets with the cloud-based storage service, authenticating the uploader with the cloud-based storage service using the certificate; and
Isolating the part of the one or more results sets in the cloud-based storage service based on the tenancy associated with the certificate.
However, in the related field of endeavor of storage migration, Schmitt teaches:
Performing a handshake process between the uploader and the cloud-based storage service to download a certificate, the certificate linked to a tenancy on the cloud-based storage service;
Schmitt teaches a challenge-handshake authentication protocol (CHAP) for authenticating remote storage where a controller “cane either pull the storage credential information from a database or the compute resource can ask the controller for it by performing a database query or an API call that makes a database query” follow by “the compute resource then connects to, logs on to, or communicates with the storage resource using the storage credentials” (Para. [0381]). Therefore, Schmitt teaches performing a handshake to download a certificate linked to a remote storage that enables a connection to the remote storage.
Prior to storing the part of the one or more results sets with the cloud-based storage service, authenticating the uploader with the cloud-based storage service using the certificate; and
Schmitt teaches a challenge-handshake authentication protocol (CHAP) for authenticating remote storage where a controller “can either pull the storage credential information from a database or the compute resource can ask the controller for it by performing a database query or an API call that makes a database query” follow by “the compute resource then connects to, logs on to, or communicates with the storage resource using the storage credentials” (Para. [0381]). Therefore, Schmitt teaches performing a handshake to download a certificate linked to a remote storage, thus performing authentication, prior to storing data using the established connection to the remote storage.
Isolating the part of the one or more results sets in the cloud-based storage service based on the tenancy associated with the certificate.
Schmitt teaches isolating/provisioning cloud storage resource for storing data connected to a compute resource and using credentials or certificates to “facilitate a connection to the [isolated/provisioned] storage resource” (Para. [0417])
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Schmitt, Gilder, Elkabetz, and Yamato at the time that the claimed invention was effectively filed, to have modified the use of scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs, as taught by Gilder, the use of derived data, as taught by Elkabetz, and the systems and methods for performing an ETL process, as taught by Yamato, with the enhanced security used in storage migration, as taught by Schmitt.
One would have been motivated to make such combination because Schmitt teaches “the automation reduces security flaws due to human error or misconfigurations. In addition, the disclosed infrastructure provides introspection between services and may allow rule based access and limit communications between services to only those that actually need to have it.” (Para. [0090]). It would have been obvious to a person having ordinary skill in the art that limiting communications between services to only those that actually need to have it, would create a more controlled system and reduce the potential for erroneous communications between services that were not intended to communicate.
Regarding Claim 11:
All of the limitations herein are similar to some or all of the limitations of Claim 4.
Regarding Claim 18:
All of the limitations herein are similar to some or all of the limitations of Claim 4.
Claim(s) 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gilder, Elkabetz, and Yamato, and further in view of Erickson et al. (U.S. Patent No. 11,734,236, hereinafter referred to as Erickson).
Regarding Claim 6:
Gilder, Elkabetz, and Yamato explicitly teach all of the elements of the claimed invention as recited above except:
Wherein the database stores the one or more results sets in a materialized view.
However, in the related field of endeavor of database migration, Erickson teaches:
Wherein the database stores the one or more results sets in a materialized view.
Eriskon teaches migrating data between databases including “modifying the data to match [the source environment schema to] the destination environment’s schema” where “non-limiting examples of relational database schema…include schema that define…materialized views” (Col. 3 Lines 47-62).
Thus, it would have been obvious to one of ordinary skill in the art, having the teachings of Erickson, Gilder, Elkabetz, and Yamato at the time that the claimed invention was effectively filed, to have modified the use of scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs, as taught by Gilder, the use of derived data, as taught by Elkabetz, and the systems and methods for performing an ETL process, as taught by Yamato, with the use of modifying data to match a destination environment’s schema, as taught by Erickson.
One would have been motivated to make such modification because Erickson teaches “improvements in data migration between databases of different relational database environments” (Col. 2 Lines 46-48) by “reducing migration time of data between environments and improving accuracy of the migrated data” using executable database management scripts that adapt the schema of the data to be compatible with the destination environment (Col. 3 Line 63 – Col. 4 Line 29).
Regarding Claim 13:
All of the limitations herein are similar to some or all of the limitations of Claim 6.
Regarding Claim 20:
All of the limitations herein are similar to some or all of the limitations of Claim 6.
Response to Arguments
On pages 8-9 of the Remarks filed on 2/5/2026, Applicant argues that “the Examiner’s reliance on Yamato is Internally contradictory” because “The Examiner cites Yamato paragraphs 74-77 for teaching the use of the library structure (data format determiner 110) to deserialize data "without the use or mentioning of an interface or running any security system or auditing protocol." However, the Examiner separately cites these same Yamato paragraphs 74-77, along with paragraph 59, for teaching the "interface" element itself specifically citing the data format determiner 110 and the communication I/F 190 as satisfying the claimed interface.” and “This creates a logical contradiction. The Examiner cannot reasonably rely on the same passages of Yamato to simultaneously teach: (1) the existence and use of an interface (data format determiner 110 and communication I/F 190); and (2) the absence of an interface such that deserialization occurs "without using the interface." If Yamato's data format determiner 110 and communication I/F 190 constitute the claimed "interface," then Yamato cannot also teach bypassing or operating "without using" that same interface.”Applicant’s argument is not convincing because one limitation is related to using an interface to invoke a library structure, such as can be done through an interface that communicates with external devices (Yamato [0059]), and the other limitation is stating that the act of deserializing, using the library structure at the uploader, is performed without using the interface during the deserializing (Yamato Paras. [0068] & [0074]-[0077]). The deserializing using the library structure itself is not understood as using the interface.
On page 10 of the Remarks filed on 2/5/2026, Applicant argues that “the Examiner’s treatment of the Security/auditing protocol bypass limitation is flawed” because “The Examiner acknowledges that Yamato does not mention a security system or auditing protocol in paragraphs 74-77, and separately cites Gilder for teaching "wherein the interface runs at least one of a security system or an auditing protocol associated with the interface." The Examiner then cites Yamato's silence regarding security/auditing protocols as teaching the "without running" limitation. However, there is a critical distinction between: (1) a system that lacks a security system or auditing protocol entirely; and (2) a system that has a security system or auditing protocol but operates without running it (i.e., bypassing it). Under the Examiner's interpretation, Yamato teaches the former-a system with no security or auditing protocol present. The claims require the latter-a system that affirmatively bypasses existing security/auditing functionality.” and “The claim language requires an environment "wherein the interface runs at least one of a security system or an auditing protocol," followed by deserialization that occurs "without running" that security system or auditing protocol. This describes an active bypass of an existing capability, not the mere absence of such capability. A person of ordinary skill in the art would understand that bypassing security protocols (i.e., deliberately circumventing existing security measures) is technologically and conceptually distinct from simply not having security protocols in the first place.”Applicant’s argument is not convincing because one limitation is related “the interface runs at least one of a security system or an auditing protocol associated with the interface” and the other limitation is stating that the act of deserializing, using the library structure at the uploader, is performed without using the interface and without running the at least one of the security system or the auditing protocol associated with the interface during the deserializing (Yamato Paras. [0068] & [0074]-[0077]). The deserializing using the library structure itself is not understood as running any security system or auditing protocol, even if a security system or auditing protocol might exist when Elkabetz and Yamato are combined with Gilder.
On pages 9-10 of the Remarks filed on 2/5/2026, Applicant argues that “Examiner's combination rationale lacks logical coherence. Gilder is cited for teaching an auditing protocol that is actively used in the ETL system, with the stated motivation being to incorporate Gilder's "scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs" to "broaden the data collection and ETL abilities taught by Yamato." Yet the Examiner simultaneously relies on Yamato/Elkabetz-which admittedly have no security or auditing protocols-to teach the "without running" the security/auditing protocol limitation.” because “One of ordinary skill in the art would not be motivated to combine: (1) Yamato/Elkabetz, which lack security/auditing protocols entirely; with (2) Gilder, which teaches security/auditing protocols that are actively employed; to arrive at (3) the claimed invention, which requires bypassing existing security/auditing protocols during deserialization. The proposed combination would require taking Gilder's system (which uses security/auditing) and modifying it to bypass that security based on Yamato's teaching-but Yamato provides no such teaching because it has no security to bypass. The combination rationale fails to explain why one skilled in the art would be motivated to introduce a security bypass feature when neither Yamato nor Elkabetz suggest such functionality.Applicant’s argument is not convincing or agreed upon that the combination rationale lacks logical coherence. Further, it is noted that just because Yamato/Elkabetz do not teach security/auditing protocols, it does not mean that their teachings are incompatible with security/auditing protocols and there is no evidence that they teach away from benefiting from the security/auditing protocols taught by Gilder.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Banerji et al. (U.S. Pre-Grant Publication No. 2007/0239858) teaches “Extract, transform and load (ETL) tools generally enable companies to move data from multiple sources, reformat and cleanse it, and load it into another database, a data mart, or a data warehouse for analysis, or on another operational system to support a business process. Such tools generally provide graphical user interfaces to map the source and destination data visually and provide runtime components that can make the transformation according to these maps” (Para. [0030]) and “Software as a Service (SaaS) generally refers to a concept regarding services relating to the delivery and remote access of software applications via the internet. This concept is often referred to as On-Demand Applications or On-Demand Software. Characteristics of SaaS desirably include: [0024] Network-based access. [0025] Management of software. [0026] Activities that are managed from central locations rather than at each customer's site, thereby enabling customers to access applications remotely via the Internet. [0027] Application delivery that is usually closer to a one-to-many model (e.g., single instance, multi-tenant architecture) than to a one-to-one model, including architecture, pricing, partnering, and management characteristics.” (Paras. [0023] – [0027])
Siebel et al. (U.S. Pre-Grant Publication No. 2017/0006135) teaches “An enterprise Internet-of-Things application development platform system, the system comprising: a time-series data component to receive time-series data from a plurality of time-series data sources; a relational data component to receive relational data from a plurality of relational data sources; a persistence component to store the time-series data in a key-value store and store the relational data in a relational database; and a data services component to: extract, transform, and load aggregate data into a multi-dimensional data store; and implement a type layer over a plurality of data stores comprising the key-value store, the relational database, and the multi-dimensional data store, wherein the data services component comprises definitions for a plurality of types based on the plurality of data stores.” (Claim 194).
Buehne et al. (U.S. Pre-Grant Publication No. 2015/0019479) teaches “The migration of a database may be accomplished, at least in part, by careful preparation and analysis of the database objects prior to migration. Migration may be performed more timely, efficiently, and reliably if the source database and its objects are first analyzed to determine the properties of the data, relationships, dependencies, and the like. The length of time of the copying and installation is reduced may selecting appropriate operations for different object types.” where “objects such as indexes, foreign key constraints, primary key constraints, materialized views may be derived from other objects in the database” (Para. [0016]).
Kumar et al. (U.S. Patent No. 10,909,094) teaches systems and methods are provided to implement a metadata record migration system that schedules the migrations of metadata records that are frequently mutated. In embodiments, the scheduler collects timing data of jobs that modify the metadata records, including the timing of various mutation operations within the jobs. In embodiments, when it is determined that a metadata record is to be migrated to a different storage location, the scheduler determines a time to migrate the metadata record. The migration time may lie within a migration window, selected based on an expected migration time needed for the metadata record and the collected time data in order to reduce a probability that record mutations will occur during the migration. In embodiments, the jobs may be snapshot jobs that modify a snapshot record, and the migration may be performed as a result of a cell partitioning operation occurring within the snapshotting system.The reference further teaches “in some embodiments, the metadata record migration manager may implement a number of materialized views of the data stores. In that case, the metadata records may contain processed data that are part of the materialized views, such as for example aggregated data items, etc.” (Col. 6 Lines 32 – 56).
Bhide et al. (U.S. Pre-Grant Publication No. 2013/0073515) teaches “executing a plurality of transform stages in an extract, transform and load (ETL) job, the ETL job including an extract stage and a load stage in addition to the plurality of transform stages, and the ETL job configured to access a source database table that includes data organized into source database table rows and source database table columns, the executing comprising for each transform stage: receiving, from an upstream stage,” (Claim 1).
Hankins et al. (U.S. Pre-Grant Publication No. 2014/0180961) teaches “ETL (extract, transform, and/or loading) processes 32 may be responsible for extracting and/or transforming data from one or more upstream data sources 33, and pushing the data into one or more BI data sources” (Para. [0092]).
Strelitz et al. (U.S. Pre-Grant Publication No. 2011/0167033) teaches “An upstream ETL component 16 may extract, transform and load data from one or more data sources 12 to data warehouse 14 in a normalized form” (Para. [0012]) and “Allocation engine 24 ultimately may provide final allocated resources to a downstream ETL process 36 that may write the data into a revised table of resources 38 of the data warehouse 14. Revised table of resources 38 may be available to various analytics applications 40.” (Para. [0018]) and “data from records of the working allocation table that were created in a final stage of a series of stages in a scenario may be written back to a data warehouse by the downstream ETL component 36” (Para. [0026]).
Ticehurst et al. (U.S. Pre-Grant Publication No. 2022/0350813) teaches implementing a federated database system are presented herein. One or more source databases may store changed data to a target database. Each update of a record in a source database can result in an audit log entry written with the before and after image, a timestamp, and an identifier for the log entry. Using the audit log, the database implementation herein can consolidate updates to any record for a batching event to be processed in an Extract, Transform, and Load (ETL) process for export of updates to the target database.
Demaree (U.S. Pre-Grant Publication No. 2015/0020212) teaches “The environment 100 further depicts one or more service providers 110, configured to communicate with computing device 102 over a network 112, such as the Internet, to provide a "cloud-based" computing environment. Generally speaking, a service provider 110 is configured to make various resources 114 available over the network 112 to clients. In some scenarios, users may sign up for accounts that are employed to access corresponding resources from a provider. The provider may authenticate credentials of a user (e.g., username and password) before granting access to an account and corresponding resources 114. Other resources 114 may be made freely available, (e.g., without authentication or account-based access). The resources 114 can include any suitable combination of services and/or content typically made available over a network by one or more providers.” (Para. [0020])
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 ROBERT F MAY whose telephone number is (571)272-3195. The examiner can normally be reached Monday-Friday 9:30am to 6pm.
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, Boris Gorney can be reached on 571-270-5626. 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.
/ROBERT F MAY/Examiner, Art Unit 2154 4/27/2026
/SYED H HASAN/Primary Examiner, Art Unit 2154
Prosecution Insights