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 .
Status of Claims
This action is responsive to remarks filed 02/20/2026. Claims 1, 9, 13, and 19 are amended. No claims have been cancelled, and there are no new claims.
Claims 1–20 are pending for examination.
Response to Arguments
In reference to 35 USC § 101
Applicant’s arguments, filed on 02/20/2026, with respect to the § 101 rejections have been fully considered and, in light of the amendments, are persuasive.
Examiner notes that while the claims recite several limitations that are abstract ideas (mental processes), the claims as a whole are not directed to an abstract idea. Applicant amended the claims, which collectively now recite a detailed system directed toward scalable federated machine learning systems. The newly amended independent claims now include limitations that clearly tie the claimed subject matter to hardware such that the claim limitations are not abstract. These additional limitations are not abstract ideas (see MPEP 2106.04(a)). Thus, these limitations must be considered additional elements to the abstract idea. Examiner notes that these additional elements integrate the abstract idea into a practical application because the entire claim amounts to a detailed system that requires implementing a specific combination of hardware with the federated learning methods (as opposed to a broad recitation at a high level of generality), and the specific combination of hardware and instructions recited in the additional element amounts to an improvement to the functioning of a computer/field, as set forth by MPEP 2106.05(a)), which states “the claim must include the components or steps of the invention that provide the improvement described in the specification.” Pursuant to this requirement set forth by the MPEP, examiner points out that the Specification states in at least [0005, 0007, 0051, 0097]: “Further, the federated learning system comprises an aggregation configuration repository that contains parameters used by the hierarchical aggregators/stream processors. The policy engine may also make changes to the aggregation configuration repository based on the logs, for example to change the frequency of the aggregation cycle. Further, the federated learning system can use security signatures in communications to protect against malicious interference. As such, the federated learning system as described operates asynchronously, allows for massive scalability, is resilient to client variations and inconsistencies, is secure, adapts to changes, and maintains user privacy (client specific data may not leave the terminal), while still taking advantage of user hardware and user data to update model parameters to improve the model.” Therefore, the additional elements reflect the improvement set forth and explains what the resulting improvement is.
Thus, the additional limitations do amount to significantly more, and the § 101 rejections are withdrawn.
In reference to 35 USC § 103
Applicant’s arguments filed on 02/20/2026, with respect to the § 103 rejections have been fully considered but are not persuasive.
Applicant argues, beginning on pg. 7 of the Remarks, that “The combination of Siebel and Shear fails to render obvious claims 1-20 because the combination of Siebel and Shear fails to disclose (1) the plurality of clients are associated with user terminals outside direct control of the federated learning system; and (2) model update contributions containing updated model parameters without user data are used to generate the updated model parameters.” Examiner respectfully disagrees. With respect to (1), Examiner notes that the required limitation states the user terminals are associated with the clients. Examiner contends that Siebel indeed teaches user terminals outside direct control of the system because Siebel teaches in Figs. 8–9, 36–37, and at least paragraphs [¶0142, ¶0153, ¶0169–0170] “The data sources 208 may include systems, nodes, or devices in a computing network or other systems used by an enterprise, company, customer or client, or other entity. In one embodiment, the data sources 208 may include a database of customer or company information.” See § 103 rejections below for a more detailed analysis. Examiner notes the claim does not require that the clients are outside of the system’s control. Additionally and independent, Shear also teaches user terminals outside of the control of the system in at least paragraph [0247] which states “Users may also create, modify and/or delete Participants associated and controlled by them. A Participant is a PERCos Resource that represents information about a user within a PERCos system. The Participant is the Edge representation in the computational Domain of the behavior of a human user, group, or organization that is itself outside the computational Domain.”
Applicant argues, beginning on pg. 9 of the Remarks, that “claim 1 requires that model update contributions containing updated model parameters without user data are used to generate the updated model parameters. In contrast, Siebel employs a system configured to analyze all types of data and makes no provision for data privacy.” Examiner respectfully disagrees. Examiner notes that the claim language requires model update contributions with model parameters without user data used to generate the model parameters and is silent to data privacy. Examiner contends that Siebel indeed teaches model parameters that are not generated by user data in at least paragraph [0178] which states “In one embodiment, a model driven architecture for a distributed system may include a type system that is logically separated into three or more distinct layers including an entity layer, an application layer, and a UI layer. The entity layer may include definitions for base data types such as devices, entities, customers, or the like. The entity layer type definitions may define validation parameters for the base data or entity types. The validation parameters may indicate requiredness properties for fields or other properties of the type, such as a data type, return value type for one or more functions, or the like. The validation parameters may also indicate how the type or value in the type may be updated, such as by system update only.” See § 103 rejections below for a more detailed analysis. Siebel’s system includes parameters that are data agnostic, as pointed out by Applicant’s remarks, and that do not require user data contributions to update the system.
Thus, the § 103 rejections are maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1–20 are rejected under 35 U.S.C. 103 as being unpatentable over Siebel et al., (US 20180191867 A1), hereinafter “Siebel”, in view of Shear et al., (US 20140282586 A1), hereinafter “Shear”.
Regarding claim 1, Siebel teaches:
A plurality of data storage devices comprising (Siebel ¶0106,¶0157: “ In one embodiment, a server, such as a server that implements a portion of the system 200 may implement mapping between data stored in one or more databases and a type in the type system, such as data that corresponds to a specific customer type or other type” and “In one embodiment, the integration component 202 integrates data from the data sources 208 based on a canonical data model into a common format and/or into one or more data stores”):
scalable queues configured to receive model update contributions from a plurality of clients, the model update contributions containing updated model parameters without user data used to generate the updated model parameters (Siebel ¶0142, ¶0159–0170, ¶0178: “Abstraction of storage details can reduce the amount of code or knowledge required by a developer to develop powerful applications. Furthermore, with the abstraction of storage, type models, functions, or other details by the type system, customers or developers for a client of a PaaS system are insulated from any changes that are to be made over time. Rather, these changes may be made in the type system without any need for customers or developers to be made aware or any updates made to applications or associated business logic” and “The integration component 202 provides sensor/device to communicate with the data sources 208, such as any devices or systems that include the sensors/devices. The integration component 202 includes a message receiver, inbound queues, communication/retry logic, a message sender, and outbound queues … the message receiver may receive messages from one or more of the data sources 208 … The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message … The HDFS data store 408 may provide storage for unstructured data. HDFS is a Java-based file system that provides scalable and reliable data storage, and it was designed to span large clusters of commodity servers. HDFS is published by the Apache Software Foundation®. The HDFS data store 408 may be beneficial for parallel processing algorithms such as Map reduce” and “In one embodiment, a model driven architecture for a distributed system may include a type system that is logically separated into three or more distinct layers including an entity layer, an application layer, and a UI layer. The entity layer may include definitions for base data types such as devices, entities, customers, or the like. The entity layer type definitions may define validation parameters for the base data or entity types. The validation parameters may indicate requiredness properties for fields or other properties of the type, such as a data type, return value type for one or more functions, or the like. The validation parameters may also indicate how the type or value in the type may be updated, such as by system update only”—[wherein the BRI of scalable queues is any memory/storage capable of storing data for later use and wherein the system provides scalable and reliable data storage for unstructured data without any need for customers or developers to be made aware or any updates made to applications or associated business logic]);
the plurality of clients associated with user terminals outside direct control of the federated learning system (Siebel Figs. 8–9, 36–37, ¶0142, ¶0153, ¶0169–0170: “In one embodiment, the type system abstracts underlying storage details, including database type, database language, or storage format from the applications or other services. Abstraction of storage details can reduce the amount of code or knowledge required by a developer to develop powerful applications. Furthermore, with the abstraction of storage, type models, functions, or other details by the type system, customers or developers for a client of a PaaS system are insulated from any changes that are to be made over time. Rather, these changes may be made in the type system without any need for customers or developers to be made aware or any updates made to applications or associated business logic” and “The data sources 208 may include systems, nodes, or devices in a computing network or other systems used by an enterprise, company, customer or client, or other entity. In one embodiment, the data sources 208 may include a database of customer or company information” and “Although the data services layer may share some similarities with existing database design and implementation strategies, the data services component 204 also provides client services or applications with a simple data model that supports dynamic control over data layout and format. The HDFS data store 408 may provide storage for unstructured data. HDFS is a Java-based file system that provides scalable and reliable data storage, and it was designed to span large clusters of commodity servers. HDFS is published by the Apache Software Foundation®. The HDFS data store 408 may be beneficial for parallel processing algorithms such as Map reduce”—[emphasis added]),
a model repository configured to receive and store, from a terminal, a model for access by the plurality of clients (Siebel ¶0100, ¶0153: “ 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” and “The data sources 208 may include systems, nodes, or devices in a computing network or other systems used by an enterprise, company, customer or client, or other entity. In one embodiment, the data sources 208 may include a database of customer or company information”—[wherein the BRI of model repository is any memory/storage capable of storing models and the BRI of terminal is any computer or computing system that is not part of the main server (e.g., client computer), and wherein the platform includes social human-computer interaction models stored in the massive data storage and provided to clients by the product cloud]); and
a configuration repository configured to receive and store model polices including an update threshold, [the update threshold indicating how many responses need to be received from the plurality of clients to initiate an update of the model] (Siebel ¶0591: “The machine learning and predictions module 3217 can integrate back with the source systems to learn and update automatically … The user can prepare and send a work order to a work order system to investigate some (e.g., cases satisfying a threshold value) (or all) of the cases to determine whether any of the cases involve actual revenue theft. In some embodiments, the enterprise Internet-of-Things application development platform 3002 can provide a work order system for the user, or can be integrated with a work order system utilized by the user”—[wherein the BRI of configuration repository is any memory/storage capable of storing data, and wherein the machine learning and predictions module is configured to update automatically based in part on data from a user workorder including thresholds]); and
one or more processors comprising hierarchical aggregators configured to (Siebel Figs. 36–37, ¶0617, ¶0680: “The method 3800 may be performed by a system, such as the systems 200, 1600, 1900, and/or 3700 of FIGS. 2, 16, 19, and 37. The method 3800 includes receiving 3802 (for example, by a time-series data component 3704) time-series data from a plurality of time-series data sources. The method 3800 includes receiving 3804 (for example, by a relational data component 3706) relational data from a plurality of sources. The method 3800 includes persisting 3806 (for example, by the persistence component 3712) the time-series data in a key-value store and persisting the relational data in a relational database. The method 3800 includes providing 3808 (for example, by the data services component 3714) a type layer based on a type system over a plurality of data stores comprising the key-value store and the relational database, wherein providing the type layer comprises storing definitions for a plurality of types based on the plurality of data stores, and, 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” and “The system includes a data aggregation and integration component (which may include one or more of the data integration component 3708 and transformation components 3710) to collect and aggregate relational data from a diversity of enterprise system software applications and a diversity of extraprise and Internet data sources”—[wherein the BRI of hierarchical aggregators is any configurable processor capable of aggregating data and wherein the system uses processors to process component data]):
generate a model update based on the updated model parameters received from the plurality of clients and based on the update threshold (Siebel Table 21 “user-defined threshold”, ¶0159,¶0250, ¶0672: “The message receiver may receive messages from one or more of the data sources 208. The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message. Based on the message type, the communication/retry logic may place a message into an inbound queue, wherein the message will await processing. When data or messages need to be sent to one or more of the data sources 208, messages may be placed in the outbound queues. When available, the communication/reply logic may provide a message to the message sender for communication to a destination data source 208. For example, messages to data sources 208 may include a message for acknowledging receipt of a message, updating information or software on a data source 208, or the like” and “In one embodiment, a data flow event is a combination of an analytic defining what is being measured, a period defining the period of a time-series to be analyzed, and an interval that defines a granular for aggregation. In addition, analytics may specify a completeness threshold for a data flow event that defines how much of the potential data for a period has been collected so far” and “In Example 53, the method 4100 in any of Examples 46-52 further includes (for example, using a data services component 3714) detecting a change in data within one or more of the plurality of data stores and update the aggregate data in the multidimensional data store based on the change”—[wherein the system receives data from a data source (i.e., client) the data may include update information (i.e., based on the updated model parameters) based on the user-defined threshold]); and
output the model update to the model repository (Siebel ¶0584: “The outputs of these analytic processes may be alerts and calculations that are then stored in a database and made available to designated end users as analysis results”).
Siebel does not appear to explicitly teach:
[a configuration repository coupled to receive and store model polices including an update threshold,] the update threshold indicating how many responses need to be received from the plurality of clients to initiate an update of the model.
However, Shear teaches:
the update threshold indicating how many responses need to be received from the plurality of clients to initiate an update of the model (Shear ¶1700–1711: “Resource characteristics specifications (Rcs) comprise specifications that describe the characteristics of the resource. For example this may include functionality, variables, control and/or other specification sets. Resources may have sets of resource characteristics specification that may be arranged and organized in a variety of configurations, such as a single Rcs with sections for differing purposes and operating contexts, multiple resource control specifications with a single controls specification enabling selection of appropriate sets and the like … In one example embodiment, resource performance specifications, expressed as for example the upper and lower limits of resource performance, may be resource characteristics specifications (which may include, at a minimum, at least one value) with an optional set of minimum and/or maximum values defined for each resource descriptive specification elements … In some example embodiments, resource functional specifications may include differing types, such as: [1712] Requested resource functional specifications, which provide a defined resource functionality that may be required by one or more requesting resources. [1713] Published and/or persistent resource functional specifications, which in some embodiments, may be made available in the form of a designator. [1714] Operating agreement resource functional specifications which may include a specific set of specifications agreed between two or more resources regarding those resources and/or other resources. For example this may include specifications that describe an agreed upon set of service levels to be provided by one or more resources”—[wherein the system receives resource characteristics specifications (i.e., model policies) with parameters expressed as e.g., an upper limit (i.e., threshold) describing resource performance criteria (i.e., the number of responses needed to update the data)]).
The systems of Siebel, the teachings of Shear, and the instant application are analogous art because they pertain to analyzing large sets of federated data.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the systems of Siebel with the teachings of Shear to provide for a threshold value that indicates data quality for updating models. One would be motivated to do so to customize resources “within their operating capabilities for purpose operations” (Shear ¶1702).
Regarding claim 2, Siebel in view of Shear teaches all the limitations of claim 1.
Shear teaches:
wherein the configuration repository is further coupled to receive and store client configuration policies including client parameters affecting model operations at the plurality of clients (Shear ¶1700–1711: “Resource characteristics specifications (Rcs) comprise specifications that describe the characteristics of the resource. For example this may include functionality, variables, control and/or other specification sets. Resources may have sets of resource characteristics specification that may be arranged and organized in a variety of configurations, such as a single Rcs with sections for differing purposes and operating contexts, multiple resource control specifications with a single controls specification enabling selection of appropriate sets and the like … Rcs are by their nature, specific to the resources with which they are associated, where for example a common resource may have an initial resource control specifications, that specific resource may have undergone/been involved in multiple purpose operations, and as such the resource control specifications may have been modified to reflect optimizations, parameterizations and/or other manipulations the resource has undergone. Not all resources Rcs may vary in this way, some may be remain constant due to design and/or context … In some example embodiments, resource functional specifications may include differing types, such as: [1712] Requested resource functional specifications, which provide a defined resource functionality that may be required by one or more requesting resources. [1713] Published and/or persistent resource functional specifications, which in some embodiments, may be made available in the form of a designator. [1714] Operating agreement resource functional specifications which may include a specific set of specifications agreed between two or more resources regarding those resources and/or other resources. For example this may include specifications that describe an agreed upon set of service levels to be provided by one or more resources—[(emphasis added)]).
The same motivation that was utilized for combining Siebel with Shear, as set forth in claim 1, is equally applicable to claim 2.
Regarding claim 3, Siebel in view of Shear teaches all the limitations of claim 2.
Siebel teaches:
wherein the client parameters direct model download operations and the model update contributions at the plurality of clients (Siebel Fig. 15 ¶317–0318, ¶0337: “In one embodiment, the system 200 provides an analytics engine that operates on distributed computing resources providing an elastically scalable solution. The distributed computing process executes jobs synchronously and asynchronously where a master (a hardware node or a virtual machine) coordinates jobs across workers (hardware nodes or virtual machines). In one embodiment, workers pull requests from job queues (or clients), and execute on the jobs until completion … The master 1502 may also handle reconfiguration and updates of the workers 1504. The workers 1504 may process processes client requests and handles connections for corresponding queues. The workers 1504 are configured to process commands from the master 1502 and may be configured by the master 1502” and “The received data and/or the data stored in storage 1612 may be used in an IoT application phase for processing, analysis, or the like by one or more applications. Application servers 1616 may provide access to APIs for access to the data and/or to processing nodes 1610 to provide any data, processing, machine learning, or other services provided discussed in relation to the system 200 of FIG. 2. In one embodiment, the application servers 1616 may serve HTML5, JavaScript code, code for API calls, and/or the like to client web browsers to execute applications or provide interfaces for users to access applications”—[wherein the system is setup in a master/worker scheme where the client specification (e.g., api) directs the workers to pull jobs (i.e., downloads/updates) from queues (i.e., at the client)]).
Regarding claim 4, Siebel in view of Shear teaches all the limitations of claim 2.
Siebel teaches:
wherein the client parameters direct model analysis resume, model analysis stop, and model analysis exit at the plurality of clients (Siebel Fig. 1, ¶0089, ¶0094,¶0456: “FIG. 1, and the associated description below, provides one example definition and background information about cyber-physical systems based on information available on http://cyberpysicalsystems.org. “Cyber-Physical Systems (CPS) are integrations of computation, networking, and physical processes. Embedded computers and networks monitor and control the physical processes, with feedback loops where physical processes affect computations and vice versa” and “The type system may be used to interact with data and perform processing or analytics based on one or more type or function definitions within the type system” and “When using the workflow tool, a user may implement workers to perform tasks. You can create tasks that are long running, or that may fail, time out, or require restarts—or that may complete with varying throughput and latency.”—[wherein the system processing (i.e., resume, stop, exit, etc.) is directed by the function definitions (i.e., parameters)]).
Regarding claim 5, Siebel in view of Shear teaches all the limitations of claim 2.
Siebel teaches:
wherein the client parameters direct local optimization at the plurality of clients (Siebel ¶0379: “t 2120, the data is published or made available for online visualization. In one embodiment, users have the ability search and view customer and meter data from relational and key/value stores. The user experience should provide an optimal viewing experience, easy reading and navigation with a minimum of resizing, panning, and scrolling, across a wide range of devices (from mobile phones to desktop computer monitors). To enable this experience, modern UI frameworks may be used, such as Twitter Bootstrap™ or Foundation5™ may be used. In one embodiment, optimized online visualization is accomplished by making the system 1900 service enabled, with key services available as REST endpoints. Support for REST endpoints allow queries to access data by meter, concentrator, time window, and measurement type. Use of charting libraries such as Stockcharts™ and D3™ may be used to visualize time-series data”).
Regarding claim 6, Siebel in view of Shear teaches all the limitations of claim 1.
Siebel teaches:
wherein the model polices further include staleness policies (Siebel ¶0168, ¶0173, ¶0186: “The persistence layer component 402 may store data in a plurality of different data stores. The distributed key/value store 406 may store time-series data, such as data periodically measured or gathered by a sensor, meter, smart appliance, telemetry, or other device that periodically gathers and records data. One embodiment of a distributed key/value store 406 may include a NoSQL data store” and “The relational data store 414 is used to store and query business types with complex entity relationships. According to one embodiment, during integration, the persistence layer component 402 is configured to store received data in the distributed key-value store 406 or the relational data store 414. For example, time-series data may be stored in the distributed key-value store 406 while other customer, facility, or other non-time-series data is stored in the relational data store 414” and “Entity type definitions may include a variety of information, structures or code. For example, entity type definitions may include fields to track named values such as customer name, address, or the last time a meter reading was recorded. Fields may include a data type, array, reference, or function. Entity type definitions may include a data shape to track whether the data type for a field is a string, integer, float, double, decimal, date-time, or Boolean value”).
Regarding claim 7, Siebel in view of Shear teaches all the limitations of claim 1.
Siebel teaches:
further comprising a policy engine configured to set the model policies and client configuration policies (Siebel ¶0094, ¶0103–0106: “Model driven architecture is a term for a software design approach that provides models as a set of guidelines for structuring specifications. Model-driven architecture may be understood as a kind of domain engineering and supports model-driven engineering. The model driven architecture may include a type system that may be used as a domain-specific language (DSL) within a platform that may be used by developers, applications, or UIs to access data. In one embodiment, the model driven architecture disclosed herein uses a type system as a domain specific language within the platform. The type system may be used to interact with data and perform processing or analytics based on one or more type or function definitions within the type system” and “the applications 210 may be configured to operate or interface with the components 202-206 based on the type system. For example, the applications 210 may include business logic written in code and/or accessing types defined by a type system to leverages services provided by the system 200 … The types in the type system may include defined view configuration types used for rendering type data on a screen in a graphical, text, or other format. In one embodiment, a server, such as a server that implements a portion of the system 200 may implement mapping between data stored in one or more databases and a type in the type system, such as data that corresponds to a specific customer type or other type”—[wherein the model driven architecture includes a type system that is used to configure processing (i.e., model and configuration policies)]).
Regarding claim 8, Siebel in view of Shear teaches all the limitations of claim 7.
Siebel teaches:
wherein the policy engine is further configured to configure the hierarchical aggregators with hyper-parameters to scale aggregation weights (Siebel ¶0054, ¶0206, ¶0230, ¶0320: “They require a new class of enterprise applications that correlate, aggregate, and apply advanced machine learning to perform real-time analysis of data” and “Application developers may use the platform to interact with types of the following categories: persistable entity types which are persisted in a database and represent either abstract (resource.ResourceMetric) or concrete (facilitymgt.Facility) entities; non-entity types are not persisted in a database and represent non-entities such as services.billinginfo or metadata.Meta; data flow event (DFE) types represent data flow events in the process of the integration of canonical format data with data structures; analytic types represent analytics (facilitymgt.FacilityAggregate) that answer questions by fetching and performing calculations on specified combinations of data; and MapReduce types represent MapReduce processes for efficiently reading and writing large volumes of data” and “With the integration component 202 and the data services component 204, the system 200 is designed to aggregate, federate, and normalize significant volumes of disparate, real-time operational data” and “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 that, for example, exceed 1.5 million transactions per second”—[wherein the aggregators are configured with the parameters including weighted calculations that scale the data]).
Regarding claim 9, Siebel in view of Shear teaches all the limitations of claim 7.
Siebel teaches:
further comprising a participant monitoring repository configured to: receive monitoring logs indicating participant quality for the plurality of clients (Siebel ¶0053, ¶0149–0150: “These smart and real-time applications will be adaptive, continually evolving based on knowledge gained from machine learning. The integration of big data from IoT sensors, operational machine learning, and analytics can be used in a closed loop to control the devices being monitored. Real-time streaming with in-line or operationalized analytics and machine learning will enhance business operations and enable near-real-time decision making not possible by applying traditional business intelligence against batch-oriented data warehouses” and “The integration component 202 may perform initial data validation. In one embodiment, the integration component 202 examines the structure of incoming data to ensure that required fields are present and that the data is of the right data type. It may recognize when the format of the provided data does not match the expected format (e.g., it recognizes when a number value is erroneously provided as text), prevents the mismatched data from being loaded, and logs the issue for review and investigation. In this way, the integration component 202 may serve as a first line of defense in ensuring that incoming data can be accurately analyzed … The integration component 202 may monitor data as it flows in and performs a second round of data checks to eliminate duplicate data, and passes validated data to the data services component 204 to be stored. For example, the integration services may provide the following data management functions: duplicate handling, data validation, and data monitoring (see FIG. 6)”);
and transmit the monitoring logs to the policy engine to support setting the model policies and the client configuration policies (Siebel ¶0053, ¶0150–0152: “These smart and real-time applications will be adaptive, continually evolving based on knowledge gained from machine learning. The integration of big data from IoT sensors, operational machine learning, and analytics can be used in a closed loop to control the devices being monitored. Real-time streaming with in-line or operationalized analytics and machine learning will enhance business operations and enable near-real-time decision making not possible by applying traditional business intelligence against batch-oriented data warehouses” and “The integration component 202 may monitor data as it flows in and performs a second round of data checks to eliminate duplicate data, and passes validated data to the data services component 204 to be stored. For example, the integration services may provide the following data management functions: duplicate handling, data validation, and data monitoring (see FIG. 6) … For data monitoring, the integration component 202 provides end-to-end visibility throughout the entire data loading process. Users can monitor a data integration process as it progresses from duplicate detection through to data storage”).
Regarding claim 10, Siebel in view of Shear teaches all the limitations of claim 9.
Siebel teaches:
wherein the hierarchical aggregators are configured to transmit the monitoring logs to the participant monitoring repository (Siebel ¶0149, ¶0230, ¶0315: “The integration component 202 may perform initial data validation. In one embodiment, the integration component 202 examines the structure of incoming data to ensure that required fields are present and that the data is of the right data type” and “In one embodiment, the data services component 204 calculates data for the multi-dimensional data store 412 and/or keeps the value consistent with the distributed key-value store 406 and relational store 414 as it is updated by the integration component 202, applications 210, modular services component 206, or the like. In one embodiment, the multi-dimensional data store 412 stores aggregate data that has been aggregated based on information in one or more of the other data stores 406-410 and 414-416” and “The system 200 provides useful tools for information systems that include smart, connected products with embedded sensors, coupled with processors, software, and product connectivity, and elastic cloud-based software in which product data, sensor data, enterprise data, and Internet data are aggregated, stored, and analyzed and applications run. These information systems, combined with new social-human computer interaction models, may drive future improvements in productivity”—[wherein the integration component (i.e., participant monitoring repository) processes data from the stored data (i.e., monitoring logs) provided by the aggregators]).
Regarding claim 11, Siebel in view of Shear teaches all the limitations of claim 1.
Shear teaches:
wherein the scalable queues receive the model update contributions from the plurality of clients according to a hash function (Shear ¶1641: “ An identity specifies a unique resource and operational methods of obtaining its resource elements. Each resource is named by at least one identity. (In some embodiments, a resource's identities may be one of its resource elements.) In some embodiments, the apparatus or methods to get from a resource's UID to the value of one of its resource element (which could, e.g., be a direct pointer, an association list, a hash table, an entry in a database) may depend on the resource element. Wherever a resource may be required, any of its UIDs (or designators, see below) may be used as a method to reference, embed and/or interact with it”).
The same motivation that was utilized for combining Siebel with Shear, as set forth in claim 1, is equally applicable to claim 11.
Regarding claim 12, Siebel in view of Shear teaches all the limitations of claim 1.
Siebel teaches:
wherein the hierarchical aggregators are further configured to dequeue and aggregate the model update contributions from the scalable queues (Siebel ¶0318: “FIG. 15 illustrates a schematic diagram of one embodiment of an elastic distributed computing environment. The diagram illustrates a master 1502 and a plurality of workers 1504. The master 1502 and/or workers 1504 may represent separate hardware nodes and/or virtual machines. The workers 1504 may be configured to process messages in corresponding queues, which may include a Map reduce queue 1506, a batch queue 1508, an invalidation queue 1510, a calculation field queue 1512, a simple queue service (SQS) queue 1514, a data load queue 1516, and/or any other queues. Although FIG. 15 shows a single worker 1504 per queue, there may be more than one worker 1504 per queue or more than one queue per worker 1504 without departing from the scope of the disclosure. A master 1502 monitors a plurality of workers 1504, and manages the execution and completion of jobs. The master 1502 may also handle signals and notify workers 1504 to execute jobs. The master 1502 monitors logs for the workers 1504 and initiates and terminates workers 1504 based on a current computing or work load. The master 1502 may also handle reconfiguration and updates of the workers 1504. The workers 1504 may process processes client requests and handles connections for corresponding queues. The workers 1504 are configured to process commands from the master 1502 and may be configured by the master 1502”).
Regarding claim 13, Siebel teaches:
transferring a model to a plurality of clients from a model repository (Siebel Fig. 15, ¶0169, ¶0317–0318: “The data services component 204 manages a persistent state in the face of these failures and thereby provides reliability and scalability of the software systems relying on the data services component 204. Although the data services layer may share some similarities with existing database design and implementation strategies, the data services component 204 also provides client services or applications with a simple data model that supports dynamic control over data layout and format” and “In one embodiment, the system 200 provides an analytics engine that operates on distributed computing resources providing an elastically scalable solution. The distributed computing process executes jobs synchronously and asynchronously where a master (a hardware node or a virtual machine) coordinates jobs across workers (hardware nodes or virtual machines). In one embodiment, workers pull requests from job queues (or clients), and execute on the jobs until completion”);
the plurality of clients associated with user terminals outside direct control of the federated learning system (Siebel Figs. 8–9, ¶0142, ¶0169–0170: “In one embodiment, the type system abstracts underlying storage details, including database type, database language, or storage format from the applications or other services. Abstraction of storage details can reduce the amount of code or knowledge required by a developer to develop powerful applications. Furthermore, with the abstraction of storage, type models, functions, or other details by the type system, customers or developers for a client of a PaaS system are insulated from any changes that are to be made over time. Rather, these changes may be made in the type system without any need for customers or developers to be made aware or any updates made to applications or associated business logic” and “Although the data services layer may share some similarities with existing database design and implementation strategies, the data services component 204 also provides client services or applications with a simple data model that supports dynamic control over data layout and format. The HDFS data store 408 may provide storage for unstructured data. HDFS is a Java-based file system that provides scalable and reliable data storage, and it was designed to span large clusters of commodity servers. HDFS is published by the Apache Software Foundation®. The HDFS data store 408 may be beneficial for parallel processing algorithms such as Map reduce”—[emphasis added]):
receiving, by a plurality of data storage devices comprising scalable queues, model update contributions from the plurality of clients, the model update contributions containing updated model parameters without user data used to generate the updated model parameters (Siebel ¶0142, ¶0159–0170, ¶0178: “Abstraction of storage details can reduce the amount of code or knowledge required by a developer to develop powerful applications. Furthermore, with the abstraction of storage, type models, functions, or other details by the type system, customers or developers for a client of a PaaS system are insulated from any changes that are to be made over time. Rather, these changes may be made in the type system without any need for customers or developers to be made aware or any updates made to applications or associated business logic” and “The integration component 202 provides sensor/device to communicate with the data sources 208, such as any devices or systems that include the sensors/devices. The integration component 202 includes a message receiver, inbound queues, communication/retry logic, a message sender, and outbound queues … the message receiver may receive messages from one or more of the data sources 208 … The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message … The HDFS data store 408 may provide storage for unstructured data. HDFS is a Java-based file system that provides scalable and reliable data storage, and it was designed to span large clusters of commodity servers. HDFS is published by the Apache Software Foundation®. The HDFS data store 408 may be beneficial for parallel processing algorithms such as Map reduce” and “In one embodiment, a model driven architecture for a distributed system may include a type system that is logically separated into three or more distinct layers including an entity layer, an application layer, and a UI layer. The entity layer may include definitions for base data types such as devices, entities, customers, or the like. The entity layer type definitions may define validation parameters for the base data or entity types. The validation parameters may indicate requiredness properties for fields or other properties of the type, such as a data type, return value type for one or more functions, or the like. The validation parameters may also indicate how the type or value in the type may be updated, such as by system update only”—[wherein the BRI of scalable queues is any memory/storage capable of storing data for later use and wherein the system provides scalable and reliable data storage for unstructured data without any need for customers or developers to be made aware or any updates made to applications or associated business logic]); and
updating, by one or more processors comprising hierarchical aggregators, the model based on the updated model parameters from the plurality of clients (Siebel Figs. 36–37, ¶0159, ¶0617, ¶0672, ¶0680: “The message receiver may receive messages from one or more of the data sources 208. The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message. Based on the message type, the communication/retry logic may place a message into an inbound queue, wherein the message will await processing. When data or messages need to be sent to one or more of the data sources 208, messages may be placed in the outbound queues. When available, the communication/reply logic may provide a message to the message sender for communication to a destination data source 208. For example, messages to data sources 208 may include a message for acknowledging receipt of a message, updating information or software on a data source 208, or the like” and “The method 3800 may be performed by a system, such as the systems 200, 1600, 1900, and/or 3700 of FIGS. 2, 16, 19, and 37. The method 3800 includes receiving 3802 (for example, by a time-series data component 3704) time-series data from a plurality of time-series data sources. The method 3800 includes receiving 3804 (for example, by a relational data component 3706) relational data from a plurality of sources. The method 3800 includes persisting 3806 (for example, by the persistence component 3712) the time-series data in a key-value store and persisting the relational data in a relational database. The method 3800 includes providing 3808 (for example, by the data services component 3714) a type layer based on a type system over a plurality of data stores comprising the key-value store and the relational database, wherein providing the type layer comprises storing definitions for a plurality of types based on the plurality of data stores, and, 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” and “In Example 53, the method 4100 in any of Examples 46-52 further includes (for example, using a data services component 3714) detecting a change in data within one or more of the plurality of data stores and update the aggregate data in the multidimensional data store based on the change” and “The system includes a data aggregation and integration component (which may include one or more of the data integration component 3708 and transformation components 3710) to collect and aggregate relational data from a diversity of enterprise system software applications and a diversity of extraprise and Internet data sources”—[wherein the system receives data from a data source (i.e., client aggregators) the data may include update information (i.e., based on the updated model parameters).
Siebel does not appear to explicitly teach:
and based on model polices including an update threshold indicating how many responses need to be received from the plurality of clients to initiate an update of the model.
However, Shear teaches:
and based on model polices including an update threshold indicating how many responses need to be received from the plurality of clients to initiate an update of the model (Shear ¶1700–1711: “Resource characteristics specifications (Rcs) comprise specifications that describe the characteristics of the resource. For example this may include functionality, variables, control and/or other specification sets. Resources may have sets of resource characteristics specification that may be arranged and organized in a variety of configurations, such as a single Rcs with sections for differing purposes and operating contexts, multiple resource control specifications with a single controls specification enabling selection of appropriate sets and the like … In one example embodiment, resource performance specifications, expressed as for example the upper and lower limits of resource performance, may be resource characteristics specifications (which may include, at a minimum, at least one value) with an optional set of minimum and/or maximum values defined for each resource descriptive specification elements … In some example embodiments, resource functional specifications may include differing types, such as: [1712] Requested resource functional specifications, which provide a defined resource functionality that may be required by one or more requesting resources. [1713] Published and/or persistent resource functional specifications, which in some embodiments, may be made available in the form of a designator. [1714] Operating agreement resource functional specifications which may include a specific set of specifications agreed between two or more resources regarding those resources and/or other resources. For example this may include specifications that describe an agreed upon set of service levels to be provided by one or more resources”—[wherein the system receives resource characteristics specifications (i.e., model policies) with parameters expressed as e.g., an upper limit (i.e., threshold) describing resource performance criteria (i.e., the number of responses needed to update the data)]).
The systems of Siebel, the teachings of Shear, and the instant application are analogous art because they pertain to analyzing large sets of federated data.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the systems of Siebel with the teachings of Shear to provide for a threshold value that indicates data quality for updating models. One would be motivated to do so to customize resources “within their operating capabilities for purpose operations” (Shear ¶1702).
Regarding claim 14, Siebel in view of Shear teaches all the limitations of claim 13.
Siebel teaches:
wherein the model includes model parameters, a model sequence identifier for a version of the model, a system signature, or combinations thereof (Siebel ¶0174–0175, ¶0182, ¶0189: “In one embodiment, the relational data store 414 includes a fully integrated relational PostgreSQL database, a powerful, open source object-relational database management system. An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (save points), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance … The metadata store 416 stores information about data stored in any of the other stores 406-414. In one embodiment, the metadata store 416 stores type definitions or other information used by the type metadata component 404 to provide abstract types, or an abstraction layer, over the data stores 406-416” and “In one embodiment, each tenant or tag can have separate versions of the same types. For example, database tables may be created and/or altered to include metadata or data for types specific to a tenant or tag. A database table may be shared across all tenants or tags within a same environment. The tables may include a union of all columns needed by all versions from all tenants/tags” and “In one embodiment, all persistable entity types have the following fields: id, an identifier for the type; meta, an author/descriptor for the type; name, a recognizable type name; version, for comparison in version control, and/or versionEdits, for an audit trail as the version history changes, which makes reversion possible”—[(emphasis added)]).
Regarding claim 15, Siebel in view of Shear teaches all the limitations of claim 13.
Siebel teaches:
wherein the model update contributions include a model sequence identifier for a version of the model associated with the updated model parameters, training factors of a corresponding client, a client identifier associated with the corresponding client, a participant signature, or combinations thereof (Siebel ¶0174–0175, ¶0182, ¶0189: “In one embodiment, the relational data store 414 includes a fully integrated relational PostgreSQL database, a powerful, open source object-relational database management system. An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (save points), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance … The metadata store 416 stores information about data stored in any of the other stores 406-414. In one embodiment, the metadata store 416 stores type definitions or other information used by the type metadata component 404 to provide abstract types, or an abstraction layer, over the data stores 406-416” and “In one embodiment, each tenant or tag can have separate versions of the same types. For example, database tables may be created and/or altered to include metadata or data for types specific to a tenant or tag. A database table may be shared across all tenants or tags within a same environment. The tables may include a union of all columns needed by all versions from all tenants/tags” and “In one embodiment, all persistable entity types have the following fields: id, an identifier for the type; meta, an author/descriptor for the type; name, a recognizable type name; version, for comparison in version control, and/or versionEdits, for an audit trail as the version history changes, which makes reversion possible.”—[(emphasis added)]).
Regarding claim 16, Siebel in view of Shear teaches all the limitations of claim 13.
Siebel teaches:
further comprising transmitting, by the hierarchical aggregators, a monitoring log indicating participant quality to a participant monitoring repository (Siebel ¶0149, ¶0230, ¶0315: “The integration component 202 may perform initial data validation. In one embodiment, the integration component 202 examines the structure of incoming data to ensure that required fields are present and that the data is of the right data type” and “In one embodiment, the data services component 204 calculates data for the multi-dimensional data store 412 and/or keeps the value consistent with the distributed key-value store 406 and relational store 414 as it is updated by the integration component 202, applications 210, modular services component 206, or the like. In one embodiment, the multi-dimensional data store 412 stores aggregate data that has been aggregated based on information in one or more of the other data stores 406-410 and 414-416” and “The system 200 provides useful tools for information systems that include smart, connected products with embedded sensors, coupled with processors, software, and product connectivity, and elastic cloud-based software in which product data, sensor data, enterprise data, and Internet data are aggregated, stored, and analyzed and applications run. These information systems, combined with new social-human computer interaction models, may drive future improvements in productivity”—[(emphasis added) wherein the integration component (i.e., participant monitoring repository) processes data from the stored data (i.e., monitoring logs) provided by the aggregators]),
wherein the monitoring log includes a counter, a client identifier, a model sequence identifier, client staleness data, client speed data, client throughput data, or combinations thereof (Siebel ¶0189: “In one embodiment, entity types are made persistable and stored in a database by mixing into them a transient type. The transient type may form the basis for persistable entity types. In one embodiment, all persistable entity types have the following fields: id, an identifier for the type; meta, an author/descriptor for the type; name, a recognizable type name; version, for comparison in version control, and/or versionEdits, for an audit trail as the version history changes, which makes reversion possible. In one embodiment, persistable entity types have a base group of functions that enable fetching, removing, updating, or inserting information into a database.”—[(emphasis added)]).
Regarding claim 17, Siebel in view of Shear teaches all the limitations of claim 13.
Siebel teaches:
further comprising transmitting, by a policy engine, aggregation configuration of the hierarchical aggregators to a configuration repository (Siebel ¶0318, ¶0328: “The master 1502 may also handle reconfiguration and updates of the workers 1504. The workers 1504 may process processes client requests and handles connections for corresponding queues. The workers 1504 are configured to process commands from the master 1502 and may be configured by the master 1502” and “ In one embodiment, the distribute queues 1606 are configured to handle sequencing information in queuing messages and are configurable on a per queue basis. Per queue basis configuration settings enable operators to configure settings and easily modify queue parameters”),
wherein the aggregation configuration includes aggregation hyper-parameters including window sizes, discount rates, or combinations thereof (Siebel ¶0349, ¶0373: “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 1600 may provide a set of REST APIs that enable third party applications to query and access data by sensor, concentrator, time window, and data/measurement type. The REST API may support advanced modes or authentication such as OAuth 2.0 and token based authentication” and “At 2020, the data is sent to an external system. For example, the data may be sent right after processing, at a scheduling time, and/or in response to a specific request. The data may be sent in raw or aggregated (or processed) format to an external or third party system. A request from an external system may include a meter ID or concentrator ID, time window, and/or measurement type”—[(emphasis added)]).
Regarding claim 18, Siebel in view of Shear teaches all the limitations of claim 13.
Siebel teaches:
further comprising transmitting, by a policy engine, client configuration policies to a configuration repository (Siebel ¶0318, ¶0328: “The master 1502 may also handle reconfiguration and updates of the workers 1504. The workers 1504 may process processes client requests and handles connections for corresponding queues. The workers 1504 are configured to process commands from the master 1502 and may be configured by the master 1502” and “ In one embodiment, the distribute queues 1606 are configured to handle sequencing information in queuing messages and are configurable on a per queue basis. Per queue basis configuration settings enable operators to configure settings and easily modify queue parameters”),
wherein the client configuration policies include parameters affecting model operations at the plurality of clients including a model download policy, a model contribution policy, a resume command, a stop command, an exit command, a system signature, or combinations thereof (Siebel Fig. 1, ¶0089, ¶0094,¶0456: “FIG. 1, and the associated description below, provides one example definition and background information about cyber-physical systems based on information available on http://cyberpysicalsystems.org. “Cyber-Physical Systems (CPS) are integrations of computation, networking, and physical processes. Embedded computers and networks monitor and control the physical processes, with feedback loops where physical processes affect computations and vice versa” and “The type system may be used to interact with data and perform processing or analytics based on one or more type or function definitions within the type system” and “When using the workflow tool, a user may implement workers to perform tasks. You can create tasks that are long running, or that may fail, time out, or require restarts—or that may complete with varying throughput and latency.”—[wherein the system processing (i.e., resume, stop, exit, etc.) is directed by the function definitions (i.e., parameters)]).
Regarding claim 19, Siebel teaches:
one or more receivers operably coupled to receive model update contributions of a model from a plurality of clients, the plurality of clients associated with user terminals outside direct control of the federated learning system, the model update contributions containing updated model parameters without user data used to generate the updated model parameters (Siebel ¶0142, ¶0159–0170, ¶0178: “Abstraction of storage details can reduce the amount of code or knowledge required by a developer to develop powerful applications. Furthermore, with the abstraction of storage, type models, functions, or other details by the type system, customers or developers for a client of a PaaS system are insulated from any changes that are to be made over time. Rather, these changes may be made in the type system without any need for customers or developers to be made aware or any updates made to applications or associated business logic” and “The integration component 202 provides sensor/device to communicate with the data sources 208, such as any devices or systems that include the sensors/devices. The integration component 202 includes a message receiver, inbound queues, communication/retry logic, a message sender, and outbound queues … the message receiver may receive messages from one or more of the data sources 208 … The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message … The HDFS data store 408 may provide storage for unstructured data. HDFS is a Java-based file system that provides scalable and reliable data storage, and it was designed to span large clusters of commodity servers. HDFS is published by the Apache Software Foundation®. The HDFS data store 408 may be beneficial for parallel processing algorithms such as Map reduce” and “In one embodiment, a model driven architecture for a distributed system may include a type system that is logically separated into three or more distinct layers including an entity layer, an application layer, and a UI layer. The entity layer may include definitions for base data types such as devices, entities, customers, or the like. The entity layer type definitions may define validation parameters for the base data or entity types. The validation parameters may indicate requiredness properties for fields or other properties of the type, such as a data type, return value type for one or more functions, or the like. The validation parameters may also indicate how the type or value in the type may be updated, such as by system update only”—[wherein the BRI of scalable queues is any memory/storage capable of storing data for later use and wherein the system provides scalable and reliable data storage for unstructured data without any need for customers or developers to be made aware or any updates made to applications or associated business logic]); and
one or more processors operably coupled to the one or more receivers (Siebel Figs. 36–37, ¶0100, ¶0159, ¶0617: “The method 3800 may be performed by a system, such as the systems 200, 1600, 1900, and/or 3700 of FIGS. 2, 16, 19, and 37. The method 3800 includes receiving 3802 (for example, by a time-series data component 3704) time-series data from a plurality of time-series data sources. The method 3800 includes receiving 3804 (for example, by a relational data component 3706) relational data from a plurality of sources. The method 3800 includes persisting 3806 (for example, by the persistence component 3712) the time-series data in a key-value store and persisting the relational data in a relational database. The method 3800 includes providing 3808 (for example, by the data services component 3714) a type layer based on a type system over a plurality of data stores comprising the key-value store and the relational database, wherein providing the type layer comprises storing definitions for a plurality of types based on the plurality of data stores, and, 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” and “This technology stack may include products with embedded microprocessors and communication capabilities”),
the one or more processors configured to update the model based on the updated model parameters from the plurality of clients and based on model polices including an update threshold (Siebel Table 21 “user-defined threshold”, Figs. 36–37, ¶0159,¶0250, ¶0672, ¶0591: “The message receiver may receive messages from one or more of the data sources 208. The messages may include data (such as sensor data, time-series data, relational data, or any other type of data that may be provided by the data sources 208) and metadata to identify the type of message. Based on the message type, the communication/retry logic may place a message into an inbound queue, wherein the message will await processing. When data or messages need to be sent to one or more of the data sources 208, messages may be placed in the outbound queues. When available, the communication/reply logic may provide a message to the message sender for communication to a destination data source 208. For example, messages to data sources 208 may include a message for acknowledging receipt of a message, updating information or software on a data source 208, or the like” and “In one embodiment, a data flow event is a combination of an analytic defining what is being measured, a period defining the period of a time-series to be analyzed, and an interval that defines a granular for aggregation. In addition, analytics may specify a completeness threshold for a data flow event that defines how much of the potential data for a period has been collected so far” and “In Example 53, the method 4100 in any of Examples 46-52 further includes (for example, using a data services component 3714) detecting a change in data within one or more of the plurality of data stores and update the aggregate data in the multidimensional data store based on the change” and “The machine learning and predictions module 3217 can integrate back with the source systems to learn and update automatically … The user can prepare and send a work order to a work order system to investigate some (e.g., cases satisfying a threshold value) (or all) of the cases to determine whether any of the cases involve actual revenue theft. In some embodiments, the enterprise Internet-of-Things application development platform 3002 can provide a work order system for the user, or can be integrated with a work order system utilized by the user”—[wherein the machine learning and predictions module is configured to update automatically (i.e., via the processor) based in part on data from a user workorder including thresholds and wherein the system receives data from a data source (i.e., client) the data may include update information (i.e., based on the updated model parameters) based on the user-defined threshold]).
Siebel does not appear to explicitly teach:
indicating how many responses need to be received from the plurality of clients to initiate an update of the model.
However, Shear teaches:
indicating how many responses need to be received from the plurality of clients to initiate an update of the model (Shear ¶1700–1711: “Resource characteristics specifications (Rcs) comprise specifications that describe the characteristics of the resource. For example this may include functionality, variables, control and/or other specification sets. Resources may have sets of resource characteristics specification that may be arranged and organized in a variety of configurations, such as a single Rcs with sections for differing purposes and operating contexts, multiple resource control specifications with a single controls specification enabling selection of appropriate sets and the like … In one example embodiment, resource performance specifications, expressed as for example the upper and lower limits of resource performance, may be resource characteristics specifications (which may include, at a minimum, at least one value) with an optional set of minimum and/or maximum values defined for each resource descriptive specification elements … In some example embodiments, resource functional specifications may include differing types, such as: [1712] Requested resource functional specifications, which provide a defined resource functionality that may be required by one or more requesting resources. [1713] Published and/or persistent resource functional specifications, which in some embodiments, may be made available in the form of a designator. [1714] Operating agreement resource functional specifications which may include a specific set of specifications agreed between two or more resources regarding those resources and/or other resources. For example this may include specifications that describe an agreed upon set of service levels to be provided by one or more resources”—[wherein the system receives resource characteristics specifications (i.e., model policies) with parameters expressed as e.g., an upper limit (i.e., threshold) describing resource performance criteria (i.e., the number of responses needed to update the data)]).
The systems of Siebel, the teachings of Shear, and the instant application are analogous art because they pertain to analyzing large sets of federated data.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the systems of Siebel with the teachings of Shear to provide for a threshold value that indicates data quality for updating models. One would be motivated to do so to customize resources “within their operating capabilities for purpose operations” (Shear ¶1702).
Regarding claim 20, Siebel in view of Shear teaches all the limitations of claim 19.
Siebel teaches:
wherein the model includes model parameters, a model sequence identifier for a version of the model, a system signature, or combinations thereof (Siebel ¶0174–0175, ¶0182, ¶0189: “In one embodiment, the relational data store 414 includes a fully integrated relational PostgreSQL database, a powerful, open source object-relational database management system. An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (save points), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance … The metadata store 416 stores information about data stored in any of the other stores 406-414. In one embodiment, the metadata store 416 stores type definitions or other information used by the type metadata component 404 to provide abstract types, or an abstraction layer, over the data stores 406-416” and “In one embodiment, each tenant or tag can have separate versions of the same types. For example, database tables may be created and/or altered to include metadata or data for types specific to a tenant or tag. A database table may be shared across all tenants or tags within a same environment. The tables may include a union of all columns needed by all versions from all tenants/tags” and “In one embodiment, all persistable entity types have the following fields: id, an identifier for the type; meta, an author/descriptor for the type; name, a recognizable type name; version, for comparison in version control, and/or versionEdits, for an audit trail as the version history changes, which makes reversion possible”—[(emphasis added)]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS SHINE whose telephone number is (571)272-2512. The examiner can normally be reached M-F, 9a-5p ET.
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, David Yi can be reached on (571) 270-7519. 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.
/N.B.S./Examiner, Art Unit 2126
/DAVID YI/Supervisory Patent Examiner, Art Unit 2126
Prosecution Insights