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 .
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 extension fee 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.
Status of the Application
The following is a Final Office Action in response to Examiner's communication of 12/29/2025, Applicant, on 06/25/2026.
Status of Claims
Claims 1 and 10-12, are currently amended.
Claim 13 is canceled.
Claims 14-16 are new.
Claims 1-12 and 14-16 are currently pending following this response.
New matter
No new matter has been added to the amended claims.
Response to Arguments - 35 USC § 101
The arguments have been fully considered and found to be persuasive.
Accordingly, the Examiner withdraws the rejections of the pending claims under 35 USC § 101 in the present office action.
Response to Arguments - 35 USC § 112(f)
The arguments have been fully considered and found to be persuasive.
Response to Arguments - 35 USC § 112(d)
The arguments have been fully considered and found to be persuasive.
Accordingly, the Examiner withdraws the rejections of claims 10 and 12 under 35 USC § 112(d) in the present office action.
Response to Arguments - 35 USC § 102/103
The arguments have been fully considered but they are not persuasive.
The Examiner respectfully disagrees. Seibel, para. 0676, Seibel teaches “the method 4100 in any of Examples 46-56 further includes integrating (for example, using a tool integration component 3746) non-native components into a platform, wherein the non-native components comprise components implemented in code written in a language that is not native to the platform” wherein integrating non-native components into a platform, wherein the non-native components comprise components implemented in code written in a language that is not native to the platform is equivalent to translate legacy communication protocols of a database to up-to-date communication protocols
Accordingly, the Examiner maintains the rejections of the pending claims under 35 USC § 102/103 in the present office action.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a) (1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 8-12, and 14-16 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Seibel et al. (US 20180191867 A1)
Regarding claim 1. Seibel teaches A system for accessing production data of one or more production plants, wherein the production data is stored on a plurality of databases, [Seibel, para. 0005 and 0164, Seibel teaches “a system for integrating, processing, and abstracting data related to an enterprise Internet-of-Things application development platform” and “For example, the relational data store may be designed to manage structured data, such as organization and customer data. Furthermore, the key/value store may be designed to manage very large volumes of interval (or time-series) data from other types of sensors, monitoring systems, or devices. Relational databases are generally designed for random access updates, while key/value store databases are designed for large streams of “append only” data that are usually read in a particular order (“append only” means that new data is simply added to the end of the file). By using a dedicated key/value store for interval data, the data services component 204 ensures that this type of data is stored efficiently and can be accessed quickly” wherein a system accessing production data stored in databases] wherein the system comprises: an abstraction layer adapted to access each of the plurality of databases for retrieving production data from a respective database and for providing the retrieved data for further processing, [Seibel, para. 0100, Seibel teaches “Some embodiments may include a product cloud that includes software running on a hosted elastic cloud technology infrastructure that stores or processes product data, customer data, enterprise data, and Internet data. The product cloud may provide one or more of: a platform for building and processing software applications; massive data storage capacity; a data abstraction layer that implements a type system; a rules engine and analytics platform; a machine learning engine; smart product applications; and social human-computer interaction models. One or more of the layers or services may depend on the data abstraction layer for accessing stored or managed data, communicating data between layers or applications, or otherwise store, access, or communicate data” wherein abstraction layer to store, access, or communicate data (provide/retrieve data)] wherein the abstraction layer is adapted to translate legacy communication protocols of a database to up-to-date communication protocols for communication with the respective database, [Seibel, para. 0676, Seibel teaches “the method 4100 in any of Examples 46-56 further includes integrating (for example, using a tool integration component 3746) non-native components into a platform, wherein the non-native components comprise components implemented in code written in a language that is not native to the platform” wherein integrating non-native components into a platform, wherein the non-native components comprise components implemented in code written in a language that is not native to the platform is equivalent to translate legacy communication protocols of a database to up-to-date communication protocols] and a model interface implemented on a computing system and adapted to run analytic workloads requiring predetermined production data from the one or more of the plurality of databases, [Seibel, para. 0147, Seibel teaches “the integration component 202 is configured to integrate disparate data from a wide range of data sources 208. IoT applications need a reliable, efficient, and simple interface to load customer, asset, sensor, billing, and/or other data into the storage in an accessible manner. In one embodiment, the integration component 202 provides the following features: a set of canonical types that act as the public interfaces to applications, analytic, or other solutions; support for operational data sources, such as customer billing and customer management systems, asset management systems, workforce management systems, distribution management systems, outage management systems, meter or sensor data management systems, and/or the like;” wherein the integration component 202 is equivalent to the claimed model interface] and further adapted to cause the abstraction layer to retrieve the required predetermined production data from one or more of the plurality of databases and to provide the retrieved required predetermined production data to the analytic workload running on the model interface [Seibel, para. 0100, Seibel teaches “The product cloud may provide one or more of: a platform for building and processing software applications; massive data storage capacity; a data abstraction layer that implements a type system; a rules engine and analytics platform; a machine learning engine; smart product applications; and social human-computer interaction models. One or more of the layers or services may depend on the data abstraction layer for accessing stored or managed data, communicating data between layers or applications, or otherwise store, access, or communicate data.” wherein abstraction layer to store, access, or communicate data (provide/retrieve data). Also, see para. 0320 “The enterprise Internet-of-Things application development platform can integrate production data from hundreds of independent data sources and tens of millions of sensors aggregated into petabyte scale data sets using highly scalable elastic computation and storage architectures to provide processing capabilities” wherein production data providing data for processing].
Regarding claim 2. wherein the abstraction layer further comprises a mapping layer comprising a mapping of production data locations on the plurality of databases to production data identifications utilized by the model interface for indicating the required predetermined production data to the abstraction layer, wherein the abstraction layer is adapted to utilize the mapping for retrieving the required predetermined production data [Seibel, para. 0191, Seibel teaches “in one embodiment, the data abstraction layer provided by the type metadata component 404 is a metadata-based data mapping and persistence framework spanning relational, multi-dimensional, and NoSQL data stores. In metadata, developers define type definitions, including attributes and functions. The data abstraction layer allows developers to define extensible type models where new properties, relationships and functions can be added dynamically without requiring costly development cycles” wherein mapping layer comprising a mapping of production data locations on the plurality of databases to production data].
Regarding claim 3. wherein the abstraction layer comprises a harmonization model, wherein the harmonization model is adapted such that requests and responses are based on programming analytic workloads which are harmonized across the plurality of databases [Seibel, para. 0199, Seibel teaches “in one embodiment, the type metadata component 404 may also define a plurality of canonical types, which may be used by the integration component 202 to receive and transform data from data sources 208 into a standard format. As with a standard type definition, a canonical type is declared in metadata using syntax similar to that used by types persisted in the relational or NoSQL data store. Unlike a standard type, canonical types are comprised of two parts, the canonical type definition and one or more transformation types. The canonical type definition defines the interface used for integration and the transformation type is responsible for transforming the canonical type to a corresponding type. Using the transformation types, the integration layer may transform a canonical type to the appropriate type (such as a type defined by a developer)” wherein the canonical types are a form of harmonization].
Regarding claim 4. wherein the analytic workloads can refer to active or passive analytic workloads, wherein active analytic workloads are adapted to run automatically on the model interface when not instructed otherwise and passive analytic workloads are explicitly invoked by an external invocation service to run on the model interface by an external command [Seibel, para. 0687, Seibel teaches “The components, systems, modules, or layers may be passive or active, including agents operable to perform desired functions”].
Regarding claim 5. wherein the system further comprises a model management unit communicatively coupled with the invocation service, wherein the model management unit is adapted to manage the invocation of the passive analytic workloads on the model interface by causing the invocation service to invoke an analytic workload based in predetermined rules [Seibel, para. 0687, Seibel teaches “The components, systems, modules, or layers may be passive or active, including agents operable to perform desired functions”. Also see para. 0100 “The product cloud may provide one or more of: a platform for building and processing software applications; massive data storage capacity; a data abstraction layer that implements a type system; a rules engine and analytics platform;” wherein processing based-rules].
Regarding claim 8. wherein the abstraction layer comprises an access management layer adapted to manage a user access to one or more of the plurality of databases such that for each of the one or more database to which a user has access an access token for the user is generated allowing for the access to the respective database [Seibel, para. 0384, Seibel teaches “The data may be published to an external or third-party system, or be capable of providing them upon request with response times compatible with interactive web applications. The system 1900 may provide a set of REST APIs that enable third party applications to query and access data by meter, concentrator, time window, and measurement type. The REST API may support advanced modes or authentication such as OAuth 2.0 and token-based authentication” wherein token-based authentication].
Regarding claim 9. wherein the abstraction layer is adapted to provide a supertoken for a user for providing access to the access management layer, wherein the supertoken is encrypted and comprises all access tokens of the user and allows for a centralized access to the respective databases [Seibel, para. 0384, Seibel teaches “The data may be published to an external or third-party system, or be capable of providing them upon request with response times compatible with interactive web applications. The system 1900 may provide a set of REST APIs that enable third party applications to query and access data by meter, concentrator, time window, and measurement type. The REST API may support advanced modes or authentication such as OAuth 2.0 and token-based authentication” wherein advanced modes or authentication is equivalent to super token].
Regarding claim 10. A system for implementing a user model interaction environment, wherein the environment comprises: a user interface allowing a user to access the model interface of the system according to claim 1 for providing, adapting and/or controlling one or more analytic workloads [The BRI interpretation of the subject matter of claim 10 is a user interface. Seibel, para. 0081].
Regarding claim 11, the claim recites analogous limitations to claim 1 above, and is therefore rejected on the same premise. Claim 1 is a system claim while claim 11 is directed to a method which is anticipated by Seibel claim 1.
Regarding claim 12, the claim recites analogous limitations to claim 1 above, and is therefore rejected on the same premise. Claim 1 is a system claim while claim 12 is directed to a computer program product which is anticipated by Seibel para. 0684.
Regarding claim 14. wherein the abstraction layer is adapted for a parallel access of two or more of the plurality of databases for retrieving production data in parallel from the at least two respective databases and for translating all responses into a common, shared data model [Seibel, para. 0214, Seibel teaches “FIG. 7 illustrates how data can be transformed between different data formats based on data sources, canonical models, and/or applications. Data may be formatted or stored based on a canonical data model 702. A first data handler 704a, a second data handler 704b, a third data handler 704c, and a fourth data handler 704d may use or provide data corresponding to the canonical model 702, but may store, process, or provide the data in a format different than the canonical data model 702. A first data model 706a, a second data model 706b, a third data model 706c, and a fourth data model 706d represent data formats used by respective data handlers 704a-704d” wherein parallel translation of multiple database].
Regarding claim 15. wherein the abstraction layer is based on protocol buffers or gRPC remote procedure calls and is configured to provide a translation function translating data requests to specific database commands [Seibel, para. 0617, Seibel teaches “in response to a request for data, providing a type of the plurality of types comprising information in accordance with a definition corresponding to the type. The method 3800 includes accessing or processing data 3810 (for example, by a component of the system 3700) in the plurality of data stores via the type layer.” wherein providing a type of the plurality of types comprising information in accordance with a definition corresponding to the type… accessing or processing data 3810 (for example, by a component of the system 3700) in the plurality of data stores via the type layer is equivalent to translating data requests to specific database commands].
Regarding claim 16. wherein the access management layer is non- persistent such that user access data is not stored persistently, and wherein the supertoken comprises a plurality of heterogeneous subtokens each associated with a unique backend system identifier and having an expiry time [Seibel, para. 0167, Seibel teaches “The persistence layer component 402 is configured to persist (store) large volumes of data, while also making data readily available for access and/or analytical calculations by any other services or components. In one embodiment, the persistence layer component 402 partitions data into relational, non-relational (key/value store), and online analytical processing (OLAP) databases and provides common database operations such as create, read, update, and delete” wherein while also making data readily available for access and/or analytical calculations by any other services or components is equivalent to user access data is not stored persistently].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 6-7 are rejected under 35 U.S.C. 103 as being un-patentable over Seibel.
Regarding claim 6. wherein the analytic workloads are hosted container-based Although the invention is not identically disclosed or described as set forth in 35 U.S.C. 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 designer having ordinary skill in the art to which the claimed invention pertains, the invention is not patentable.
In the instant case, workloads hosted and run on container environment, are design choice that would have been obvious to a skilled in the art to modify/combine with the teaching of Seibel. Implement workloads as container based is a common knowledge of a skilled person in the art to arrive to the subject matter of claim 6 with the benefit of allowing to access production data of any type from anywhere at any scale while requiring less computational resources.
Regarding claim 7. wherein the analytic workloads are containerized by running analytic workloads that have the same data scheduling within the same container environment the invention is not identically disclosed or described as set forth in 35 U.S.C. 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 designer having ordinary skill in the art to which the claimed invention pertains, the invention is not patentable.
In the instant case, workloads hosted and run on container environment, are design choice that would have been obvious to a skilled in the art to modify/combine with the teaching of Seibel. Implement workloads as container based (harmonization or scheduling within the same container environment) is a common knowledge of a skilled person in the art to arrive to the subject matter of claim 7 with the benefit of allowing to access production data of any type from anywhere at any scale while requiring less computational resources.
Conclusion
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. Scott et al. (US 20130132140 A1). Scott teaches Systems and methods for evaluating elements of a computer network using deidentified production data are described. The production data can include a set of alias records, which include deidentified data, and can be generated from corresponding real records of actual users. Evaluating elements can include passing the production data to the elements as messages for processing.
Applicant's amendments and arguments dated 02/21/2022 necessitated the updating of the 35 USC § 101 and the 35 USC § 103 rejections of the pending claims presented in the present Office Action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication from the Examiner should be directed to Abdallah El-Hagehassan whose contact information is (571) 272-0819 and Abdallah.el-hagehassan@uspto.gov The Examiner can normally be reached on Monday- Friday 8 am to 5 pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Rutao Wu can be reached on (571) 272-6045. 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 of published applications may be obtained from either private PAIR or public PAIR. Status information of unpublished applications is available through private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have any questions on access to the private PAIR system, contact the electronic business center (EBC) at (866) 271-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 US or Canada) or (571) 272-1000.
/ABDALLAH A EL-HAGE HASSAN/
Primary Examiner, Art Unit 3623
Prosecution Insights