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 .
Election/Restrictions
Applicants indicate the election of Group I: claims 1-10 without traverse. Claims 1-10 are examined based on applicant’s election.
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.
Claims 1 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Dalgaard et al. (US 12,321,250), hereinafter Dalgaard in view of Degen et al. (US 2020/0364647), hereinafter Degen.
As for claim 1, Dalgaard teaches a method of processing telemetry data in a cluster network having a plurality of nodes (col. 2, lines 58-65 describe methods of collecting telemetry data from cloud-based resources (e.g. containers) and processing and forwarding the processed data via use of observability pipelines; Fig. 1, Container Instances 150; col. 8, lines 9-13 describe a provider network that host container instances), comprising:
storing schema of telemetry data generated as metric datasets by telemetry producers in the network in a telemetry catalog (Fig. 1; Configuration data 140; col. 13, lines 8-56 describe the creating of pipeline configuration data (i.e. construed as schema). A user provides data to configure an observability pipeline by specifying one or more sources of telemetry data (e.g., an identifier of a cluster, an identifier of a specific container instance), one or more types of telemetry data to be collected from the one or more sources (e.g., logs, metrics, traces, etc.). A configuration engine provides some of the pipeline configuration data to the ingestion servers for use identifying, for particular telemetry data, which observability pipelines are to be used (e.g. in the form of data structure “mapping information” associating a source with one or more pipelines. Fig 2 illustrates Mapping Information 204 which is a pipeline configuration data that is created using telemetry data (i.e. logs, metrics, traces));
receiving, by a telemetry transmitter component, a list of other producers in addition to an original producer of a metric dataset from the original producer (col. 15, lines 60 and col. 16, lines 1-37 describe an ingestion server receives telemetry data originated from a collector agent, which operates as part of a cluster of container instances, the ingestion server determines that the collector agent operates as part of a cluster referred to as “CLUSTER -1” (i.e. a list of telemetry data providers/container instances). The collector agents sends the telemetry data in the form of metrics);
first validating the other producers to allow them to store and transmit the metric dataset (col. 16, lines 18- 56 describe the ingestion server identifies the collector agents operates as part of “CLUSTER-1”, the ingestion server performs a lookup via a mapping information data structure identify which one or multiple observability pipelines are enabled for this telemetry data. The mapping information data structure includes several entries, each mapping a combination of telemetry data type (e.g. Logs, Metrics, Traces, etc.) and a source identifier (e.g. Cluster-1, App1, a tag or “DEV”, etc.) with a corresponding set of one or more pipeline identifiers; col. 20, lines 54-67 further describe a step of validating that the source is configured to provide the type of telemetry data identified in the configuration data)
transmitting a validation to an endpoint of the original and other producers (col. 14, lines 20-67 describe the ingestion server analyzes the telemetry data to determine which one or more of all registered observability pipelines are to be used to process the data. The ingestion server performs a lookup into the mapping structure using the identified source identifier to identify one or more endpoints of one or more processors of one or more corresponding observability pipelines, as well as one or more exporters of these pipelines and identifies a single endpoint for each associated observability pipeline, and sends the telemetry to that endpoint; Fig. 6, Block 608; col. 21, lines 4-21 describe the above process); and
accepting the metric dataset from the original and other producers for storage and transmission to telemetry consumers (Dalgaard: (62) (65); Fig. 6, Block 610; col. 21, lines 17-29 describe the step of sending the telemetry data to the one or more processing functions associated with the observability pipeline, resulting in processed telemetry data and the step further includes send the processed telemetry data to the destination system associated with the observability pipeline. The destination system comprises an analytics service, an object storage service, a metrics repository service, or a third-party system outside the provider network).
Dalgaard fails to teach
transmitting a validation to a telemetry library of an original and other producers.
Degen discloses
transmitting a validation to a telemetry library of an original and other producers (paragraphs [0050]-[0053] and [0071] describe environment data received by a given computing device are vetted for their integrity. The validation is performed by the given computing device that receives the environment data. The validation yields that the received environmental data confirms the integrity of the received environmental data, the data is recorded in the ledger of the corresponding validating computing device as a block (i.e. construed as a telemetry library). That block is linked to a previous record of environmental data (i.e. original producer(s)). The ledge is thus updated to include an additional block of validated environmental data to create an updated blockchain).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Degen for storing validation result that confirms the integrity of received environmental data. The teachings of Degen, when implemented in the Dalgaard system, will allow one of ordinary skill in the art to verify the authenticity of sensor data. One of ordinary skill in the art would be motivated to utilize the teachings of Degen in the Dalgaard system in order to enable a consumer to access the public ledgers to directly check the integrity of sensor data.
As for claim 6, the combined system of Dalgaard and Degen teaches wherein the telemetry library is connected to the original and other producers through an application programming interface (API) in the telemetry transmitter for registering the new metric schema and validating the list of other producers (Dalgaard: col. 2, lines 40-52 describes developers utilize APIs and associated tooling of a telemetry system to create telemetry data and forward it to a variety of analysis tools; col. 13, lines 15-33 describe a user provides data to configure an observability pipeline by specifying one or more sources of telemetry. The observability pipeline uses configuration data to identify, for particular telemetry data, which observability pipelines are to be used; col. 16, lines 18-56 describe telemetry data in the form of metrics that belong to a cluster are provided, the ingestion server receives the telemetry data and performs lookup via mapping information data structure to identify which one or multiple observability pipelines are enabled for this telemetry data).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Dalgaard (US 12,321,250) in view of Degen (US 2020/0364647) further in view of Mohan et al. (US 2020/0004837), hereinafter Mohan.
As for claim 2, the combined system of Dalgaard and Degen fails to teach wherein a first validating step comprises sending an accept or reject message to an original producer.
Mohan discloses
wherein a first validating step comprises sending an accept or reject message to an original producer (paragraphs [0051], [0054] and [0064]/[0069] describe data file provider entity provides data file, a data processing entity provides for validation results to be communicated to the data file provider entity. A validation application includes a data file provider notification generator and communicator that is configured to generate and initiate communication of notifications to the data file provider in response to completing the validation process. The notification indicates that the data file has been successfully validated (i.e. accept) or the notification indicate that errors/failures occurred in the validation resulting in the data file being invalid (i.e. reject)).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Mohan for provide notifications to a data file provider in response to completing a validation process. The teachings of Mohan, when implemented in the Dalgaard and Degen system, will allow one of ordinary skill in the art to convert a data file that was validated as having error/failure into a proper format. One of ordinary skill in the art would be motivated to utilize the teachings of Mohan in the Dalgaard and Degen system in order to provide the originator of the data file immediate notification in the event that the data file is determined not meet validation requirements of any one of the multiple computing systems that are required to process the data file (Mohan: paragraph [0005]).
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Dalgaard (US 12,321,250) in view of Degen (US 2020/0364647) and Mohan (US 2020/0004837) further in view of Valilala et al. (US 2022/0247786), hereinafter Valilala.
As for claim 3, the combined system of Dalgaard, Degen and Mohan teaches
sending a reject message if the telemetry transmitter component does not validate the list (Mohan: paragraph [0069] describes in the event that validation results in an error/failure, the originator/sender of the data file can be notified of the error failure; Dalgaard: col. 16, lines 20-24 describe collector agent is operating as part of a specific cluster (e.g. CLUSTER-1) and sends telemetry data in the form of metrics);
wherein data providers are on the list (Dalgaard: col. 7, lines 63 and col. 8, lines 1-10 describe clusters comprise container instances; col. 16, lines 20-24 describe a cluster that a collector agent collects telemetry data).
The combined system of Dalgaard, Degen and Mohan fails to teach
blocking any attempted transmission of the metric dataset from any other producer.
Valilala discloses
blocking any attempted transmission of the metric dataset from any other producer (paragraphs [0032]-[0033] describes a security manager obtains information about malicious viruses or malware from a third-party security service and stores data flow attributes, and corresponding policy indications (such as a policy preventing transmission of the data flow to deny a device transmitting the data flow access to the system) in a data repository. A data flow evaluation logic detects a new data flow, identifies a device cluster associated with the new data flow, and applies ML model to the data flow to generate a policy (e.g. allow or deny transmission of the data flow to an intended destination) for the device cluster; paragraphs [0048]-[0049] describe the security manager clusters the devices into device clusters according to similarities in behavior patterns among devices in each respective device cluster).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Valilala for storing policy that provides indications in a data repository. The teachings of Valilala, when implemented in the Dalgaard, Degen and Mohan system, will allow one of ordinary skill in the art to enforce security policies for device clusters. One of ordinary skill in the art would be motivated to utilize the teachings of Valilala in the Dalgaard, Degen and Mohan system in order to prevent data that fails to be validated by security policies to be distributed to an intended destination.
As for claim 4, the combined system of Dalgaard, Degen, Mohan and Valilala teaches wherein the metric dataset comprises a new telemetry metric generated by the original producer (Dalgaard: col. 9, lines 55 and col. 10, lines 1-7 describe a computing device of a user transmits a request message to a container service indicating a request to create a cluster configuration. Responsive to receiving the request, the container service generates or updates configuration data corresponding to the task or service definition), the method further comprising:
second validating schema of the new telemetry metric in a schema validator component of the telemetry transmitter (Dalgaard: col. 19, lines 30-50 describe a GUI that a user uses to provide additional “advanced” configuration data to be more broadly applicable (e.g.to more than just one pipeline));
storing the validated new metric schema in the telemetry catalog (Dalgaard: Fig. 1, Configuration data 121; col. 10, lines 2-4 describe the container service generates or updates configuration data which is construed as being stored at the container service); and
storing a new telemetry metric dataset for the new telemetry metric in the datastore for transmission to appropriate telemetry consumers (Dalgaard: col. 10, lines 60-64 describe the collector agent collects and distributes one type of telemetry data; col. 11, lines 30-34 describe the collector agent receives the telemetry data and sends the data to ingestion server(s)).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Dalgaard (US 12,321,250) in view of Degen (US 2020/0364647) and Mohan (US 2020/0004837) further in view of Valilala (US 2022/0247786) and further in view of Guim Bernat et al. (US 2018/0097743), hereinafter Guim Bernat.
As for claim 5, the combined system of Dalgaard, Degen, Mohan and Valilala fails to teach
sending a notification from the telemetry transmitter to a plurality of telemetry consumers;
receiving a request by the appropriate telemetry consumers to receive the new telemetry metric; and
sending the new telemetry metric and previous telemetry metrics to the appropriate telemetry consumers.
Guim Bernat discloses
sending a notification from the telemetry transmitter to a plurality of telemetry consumers (paragraph [0034] describes the metrics publication circuitry looks up the metrics subscription repository to find out the subscribers of the metric and responsively send the metric along with any associated information to the subscribers);
receiving a request by the appropriate telemetry consumers to receive the new telemetry metric (paragraphs [0032]-[0033] describe a metrics subscription circuitry generates subscription requests to obtain desired metrics from one or more other fabric entities); and
sending the new telemetry metric and previous telemetry metrics to the appropriate telemetry consumers (paragraphs [0034] and [0047]-[0048] describe the metrics publication circuitry prepares various metrics and sends a message containing the metric to each of the subscribers of the metric).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Guim Bernat for delivering metrics to metric subscribers. The teachings of Guim Bernat, when implemented in the Dalgaard, Degen, Mohan and Valilala system, will allow one of ordinary skill in the art to perform smart distribution of data and tasks across a multitude of resources in a cluster. One of ordinary skill in the art would be motivated to utilize the teachings of Guim Bernat in the Dalgaard, Degen, Mohan and Valilala system in order to distribute large and complex sets of data that provide information to timely discover and notify of failures and imbalance occurring in a cluster.
Allowable Subject Matter
Claims 7-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: prior art fails to teach all the limitations recited in each of the claims.
The method of claim 3 further comprising:
performing the first validating step and second validating step automatically upon production of the new telemetry metric dataset by the telemetry handler and identification of the other producers; and
inputting the telemetry data to the datastore through a telemetry pipeline.
8. The method of claim 7 wherein the telemetry pipeline implements an Open Telemetry (OTEL) protocol, and comprises a collector receiving the telemetry data through a remote procedure call (RPC) process, and further wherein cluster network includes nodes each containing a plurality of pods performing network functions and generating the telemetry data for transmission to the consumers, and further wherein the OTEL pipeline dynamically adds the new telemetry metric dataset to a data stream of the telemetry data in the pipeline, the method further comprising creating a new time-series table for the new telemetry metric for use by the pipeline.
9. The method of claim 7 wherein the first validating and second validating steps are performed while the network is running and executing applications, in order to maintain up-to-date new metrics generated by the original producer, and an up-to-date list of other producers.
10. The method of claim 1 wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features, and further wherein the one or more consumers comprises at least one of: pod components of the nodes, storage users, graphical user interfaces (GUI), and storage vendors.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
McAllister et al. (US 2022/0262469) teach data abstraction system architecture not requiring interoperability between data providers
Sainanee et al. (US 11,086,827) teach dataset schema and metadata management service
EE et al. (US 2022/0351260) teach method and system for managing data contracts
Sharma et al. (US 2021/0224245) teach data configuration, management and testing
EE et al. (US 2022/0351260) teach method for managing data contracts
Parla et al. (US 2025/0300914) teach hardware acceleration of processing using decentralized processing unit systems
Hulick JR et al. (US 2025/0182051) teach software bill of material telemetry extensions for full stack observability.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to L. T N. whose telephone number is (571)272-1013. The examiner can normally be reached M & Th 5:30 am - 2:30 pm EST.
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, TONIA DOLLINGER can be reached at 571-272-4170. 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.
/L. T. N/
Examiner, Art Unit 2459
/TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459