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 .
Drawings
The drawings are objected to because:
Different references numbers cited in the drawings and specification: paragraph 28 has reference number 102 as being servers or client computers. Paragraph 30 has reference number 102 as connection manager. However, Figure 1 of the drawing disclose reference number 102 as the system manager.
Paragraph 35 has reference number 130 as telemetry information; yet reference number 130 in Figure 1 of the Drawing is metric dataset.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Paragraph 28 has reference number 102 as being servers or client computers. Paragraph 30 has reference number 102 as connection manager. However, Figure 1 of the drawing disclose reference number 102 as the system manager.
Paragraph 35 has reference number 130 as telemetry information; yet reference number 130 in Figure 1 of the Drawing is metric dataset.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112 because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) is/are: “a filtering component verifying…”, “a telemetry processing component loading…”, “a compliance check component checking…” recited in claim 18. The examiner was unable to find specific structure material or acts corresponding to the filtering component, the telemetry processing component, and the compliance check component. Please see 35 USC 112(a) and 112(b) rejections.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f), it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f), applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 18-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Regarding the filtering component, the telemetry processing component, and the compliance check component, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No association between an algorithms/structure for the filtering component, the telemetry processing component, and the compliance check component and the respective function(s) can be found in the specification. Claim 18 purports to invoke 35 USC 112(f). However, regarding the filtering component, the telemetry processing component, and the compliance check component limitations in claim 18, the examiner finds no association between an algorithm/structure for the filtering component, the telemetry processing component, and the compliance check component and the respective functions in the specification. The specification must describe the claimed invention in sufficient detail such that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention at the time of filing.
Claims 19-20 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 18.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 18-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim 18, claim limitations ““a filtering component verifying…”, “a telemetry processing component loading…”, “a compliance check component checking…”, invoke 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure that performs the function in the claim and there is no association between the structure and the function can be found in the specification.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 19-20 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 18.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 18 recite(s) “verifying a datatype of telemetry data….as corresponding to processed data requiring compliance with a defined regulation; checking the telemetry data….against a respective compliance library to determine if the telemetry data is compliance or non-compliant”.
The limitations recited above pertaining to a method of processing telemetry data in cluster networks, as drafted, is a process that under its broadest reasonable interpretation covers performance of the limitations being an abstract idea that can be performed by a human using pencil and paper. If a claim limitation under its broadest reasonable interpretation covers performance in the mind, or by a human using pencil and paper but for recitation of generic computer components, then it falls within the mental processing grouping of abstract idea. Thus claim 1 recite an abstract idea.
This judicial exception is not integrated into a practical application and the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claim 1 recites additional elements of “loading data compliance rules….”, “installing the checklist in a compliance library….”, and “transmitting compliant data to a datastore for storage and collection by a telemetry collector”. These additional elements are determined to be extra solution activities that are well-understood, routine, and conventional (loading data, installing data, and transmitting data). Extra solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. These additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Thus, claim 1 is not patent eligible under 35 USC 101.
Claim 18 is rejected for the same reasons above but include generic processing components such as telemetry processing component, a compliance check component, a filtering component, and an interface. These additional elements amounts to no more than mere instructions to apply the exception using generic processing components. The limitations do not integrate the abstract idea into a practical application because the limitations do not impose meaningful limits on practicing the abstract idea. Thus, claim 18 is not patent eligible under 35 USC 101.
Claim 2 recites further recites the limitation of “allowing review and update of the checklist by a user or system administrator, as needed while the network is running and executing applications….” which is an mental process abstract idea that can be perform by the mind of a human with pencil and paper. Claim 2 does not recite additional elements that amounts to significantly more than the judicial exception. Thus, claim 2 is not patent eligible under 35 USC 101.
Claims 3 and 20 recites limitation of providing updated compliance regulation to the user through a regularly authority. This limitation is determined to be extra solution activities that are well-understood, routine, and conventional (transmission of data). Claim 3 also further narrow the telemetry data being generated periodically. For the same reason above, the limitation does not integrate the abstract idea into a practical application because the limitati0on does not impose meaningful limits on practicing the abstract idea. Thus, claims 3 and 20 are not patent eligible under 35 USC 101.
Claims 4-5 further narrow the compliance regulation limitations. For the same reason above, the limitation does not integrate the abstract idea into a practical application because the limitation does not impose meaningful limits on practicing the abstract idea. Thus, claims 4-5 are not patent eligible under 35 USC 101.
Claim 6 recites limitations of “formatting the received telemetry data…., defining one or more consumers of respective data of the telemetry data” which are steps that can be performed in the human mind using pencil and paper. The additional element of transmitting the respective data to the consumer is consider extra solution activities that are well-understood, routine, and conventional. For the same reason above, the limitations do not integrate the abstract idea into a practical application because the limitations do not impose meaningful limits on practicing the abstract idea. Thus, claim 6 is not patent eligible under 35 USC 101.
Claim 7 recites limitations of “ producing telemetry data in a telemetry handler…., performing the checklist step automatically upon production of the telemetry data…” which are steps that can be performed in the human mind using pencil and paper except for the additional elements of generalize processing components of pods, telemetry handler, and telemetry producer. These additional elements amounts to no more than mere instructions to apply the exception using generic processing components. Inputting data to the data store is determined to be extra solution activities that are well-understood, routine, and conventional. For the same reason above, the limitations do not integrate the abstract idea into a practical application because the limitations do not impose meaningful limits on practicing the abstract idea. Thus, claim 7 is not patent eligible under 35 USC 101.
Claim 8 recite elements of the telemetry pipeline implements an open telemetry protocol and comprise a collector receiving the telemetry data through a remote procedure call process. The limitations appear to be sufficient to amount to more than the abstract idea and it is recommended for Applicant to include the limitations in the independent claim.
Claim 9 further narrow the verifying step in claim 1. For the same reason above, the limitation does not integrate the abstract idea into a practical application because the limitation does not impose meaningful limits on practicing the abstract idea. Thus claim 9 is not patent eligible under 35 USC 101.
Claim 19 recite additional elements of the cluster network comprises a Santorini network processing containerized data utilizing a Kubernetes based framework. The limitations appear to be sufficient to amount to more than the abstract idea and it is recommended for Applicant to include the limitations in the independent claim.
Claim 10 recites “checking each metric dataset against a respective compliance library upon generation of the metric dataset….”. The limitations recited above pertaining to a method of processing telemetry data in cluster networks, as drafted, is a process that under its broadest reasonable interpretation covers performance of the limitations being an abstract idea that can be performed by a human using pencil and paper but for the recitation of generic telemetry producer component. Thus, other than reciting the generic computer component nothing in the claims element precludes the step from practically being performed by a human using pencil and paper. If a claim limitation under its broadest reasonable interpretation covers performance in the mind, then it falls within the mental processing grouping of abstract idea. According, claim 10 recite an abstract idea.
This judicial exception is not integrated into a practical application and the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claim 1 recites additional elements of “receiving a checklist…, distributing the checklist…., transmitting compliance metric datasets…” and telemetry producer component. These additional elements are determined to be extra solution activities that are well-understood, routine, and conventional (loading data, installing data, and transmitting data). Extra solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. The telemetry producer component amount to no more than mere instructions to apply the exception using generic processing components. These additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Thus, claim 10 is not patent eligible under 35 USC 101.
Claim 11 further narrow the telemetry data limitation and the consumer limitation. For the same reason above, the limitation does not integrate the abstract idea into a practical application because the limitation does not impose meaningful limits on practicing the abstract idea. Thus, claim 11 is not patent eligible under 35 USC 101.
Claims 12-14 further narrow the compliance regulation limitations. For the same reason above, the limitation does not integrate the abstract idea into a practical application because the limitation does not impose meaningful limits on practicing the abstract idea. Thus, claims 12-14 are not patent eligible under 35 USC 101.
Claim 15 recites further recites the limitation of “allowing review and update of the checklist by a user or system administrator, as needed while the network is running and executing applications….” which is an mental process abstract idea that can be perform by the mind of a human with pencil and paper. Claim 15 does not recite additional elements that amounts to significantly more than the judicial exception. Thus, claim 15 is not patent eligible under 35 USC 101.
Claim 16 recites additional elements of processing the telemetry data and inputting the telemetry data. These additional elements are determined to be extra solution activities that are well-understood, routine, and conventional. Extra solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. These additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Thus, claim 16 is not patent eligible under 35 USC 101.
Regarding claim 17, for the same reasons cited in claims 8 and 19. Claim 17 provides additional elements that amounts to more than the abstract idea. It is recommended for Applicant to include the limitations in the independent claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-7, 9-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saini et al US 20230379319 (hereinafter Saini), in further view of Balyan et al US 20250278348 (hereinafter Balyan), and in further view of Yannuzzi et al US 20240012921 (hereinafter Yannuzzi).
As to claim 1, Saini teaches a method of processing telemetry data in a cluster network having a plurality of nodes (Figure 1, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes), comprising:
verifying a datatype of telemetry data [published by a pod] as corresponding to processed data requiring compliance with a defined regulation (paragraphs 42-43 disclose the IoT operation center creates an application tag (thus define a datatype) for each device (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices) with details of what kind of traffic telemetry streams are supported for that particular telemetry exporter. The IoT-OC/pod creates/generates the telemetry configuration file. Telemetry configuration files push/verifies the different types of telemetry data. Paragraph 45 reveals that IoT security center applies dynamic security service/verification chain based on the configuration information to check/verify any specific information leaks that could be done before publishing to external/internal entities/consumers. Paragraph 59 further disclose operation controller IoT OC generates a telemetry configuration file for the telemetry exporter. The telemetry configuration file defines a policy for transmission of telemetry data from the telemetry exporter (thus, the policy defines compliance/regulation information. Figure 3 reveals in step three that the apps and devices published the telemetry data to the IoT secure center/security enforcer);
loading data compliance rules in a checklist of a telemetry transmitter (paragraph 60 reveals sharing/loading the policy/compliance with a security enforcer/telemetry enforcer. The policy for transmission of telemetry data from the telemetry exporter may comprise rules/checklist pertaining to one or more of: types of telemetry streams supported, priority, message frequency (cadence), and processing vantage point);
installing the checklist in a compliance library maintained in each pod of the plurality of pods (paragraph 61 reveals the operation controller sends/installs the telemetry configuration file (that defines a policy/rules/checklist) to the telemetry exporter and the security enforcer. Paragraphs 42 and 58 reveal a telemetry profile/ dynamic telemetry configuration files/library is generated from the telemetry configuration files (library is a collection of files) and these are shared/installed/sent to the SASE based IoT secure center. Paragraph 72 reveals the T-MUD/ telemetry profile/ dynamic telemetry configuration files/library are maintained in the SASE IoT secure center/security enforcer and the IoT-OC. The security enforcer and the IoT-OC center are also the pods that contains applications and modules. Paragraph 47 also reveals that policies pertaining to the data brokerage and destinations are defined in the IoT-OC and sent to the IoT secure center for further processing);
checking the telemetry data transmitted from the pod against a respective compliance library to determine if the telemetry data is compliant or non-compliant (paragraph 66 reveals the security enforcer processes the collected telemetry data based on a cloud access security broker. Paragraph 67 reveals the security enforcer detects violation incident pertaining to the telemetry data received from the telemetry exporter. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraph 47 discloses data is parsed and policies/compliance libraries are applied via security enforce IoT CASB); and
[publish] compliant data for collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data (Figure 3 and paragraph 61 reveal the security enforcer is caused to create a dynamic publish-subscribe stream for publishing the collected telemetry data received from the telemetry exporter based on the telemetry configuration file and the policy. The compliant data per the configuration file/policy is published for consumption via different consumers. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data).
Saini does not teach telemetry data generated by a pod as a telemetry producer; transmitting compliant data to a datastore for storage and collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data.
Balyan teaches a method of processing telemetry data (abstract and paragraph 1) and further teaches telemetry data generated by a pod as a telemetry producer (paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the published data from the pods in Saini’s teachings of processing telemetry data with Balyan’s teachings of processing log/telemetry data generated by clients/pods to provide a system that ensures improved data consumption and processing using an aggregation layer to deduplicate log data prior to storing the logs. The processing aid in reducing ingestion throughput and storage costs (paragraph 33 of Balyan).
The combination of Saini in view of Balyan does not teach but Yannuzzi teaches transmitting compliant data to a datastore for storage and collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data (paragraphs 70, 72, 145, 157-158, and 169-171 reveal sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint/collector complies with relevant data compliance regulations).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of transmitting compliant data to provide application service that accurately permits an endpoint to receive/obtain access to sensitive data when permitted by the data compliance policy (paragraph 14 of Yannuzzi).
As to claim 2, the combination of Saini in view of Balyan and Yannuzzi teaches allowing review and update of the checklist by a user or system administrator, as needed and while the network is running and executing applications, in order to dynamically maintain up-to-date compliance libraries in each pod (Saini: paragraphs 46-47 and 71-72 disclose dynamically updating the telemetry configuration files with new restrictions and share with policy servers like an identity services engine (ISE) to amend the access rules as needed based on violations. As shown in Figure 3, the telemetry MUD is shared with the different IoT devices. Paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices. Yannuzzi: paragraphs 110-111 reveal dynamically updating the compliance rules in real time as needed based on any deviations or potential issues. Paragraph 56 discloses a data team and/or application manager select and define data compliance requirement. Paragraphs 54-55 disclose the data compliance regulation repository maintains the data compliance rules and policies).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of updating the compliance rules/checklists to enhance management of the data compliance rules and desired states for various organizations across different regions (paragraph 114 of Yannuzzi).
As to claim 3, the combination of Saini in view of Balyan and Yannuzzi teaches wherein updated compliance regulations are provided to the user through a regulatory authority and affect at least a data security aspect of the telemetry data and content data associated with the telemetry data (Saini: paragraphs 46-53 and 71-72 disclose dynamically updating the telemetry configuration files with new restrictions and share with policy servers like an identity services engine (ISE) to amend the access rules as needed based on violations. The updates affect at least a data security aspect by blocking certain communication internal and with the cloud and updating the configuration file to certain actions (thus affecting content data associated with the telemetry data). Polices from the regulatory authority/IoT secure center are published for consumption via different consumers/users. Yannuzzi: paragraphs 110-111 reveal dynamically updating the compliance rules in real time as needed based on any deviations or potential issues. Paragraph 56 discloses a data team and/or application manager select and define data compliance requirement. Paragraphs 54-55 disclose the data compliance regulation repository maintains the data compliance rules and policies), and further wherein the telemetry data comprises data generated periodically by the producer upon operation in the cluster network (Saini: paragraph 30 reveals the telemetry data is collected at intervals via IoT devices communicates at different intervals with various consumers for use-cases such as telemetry collection for predictive maintenance or status collection), and wherein the telemetry data comprises performance data, topology information, alerts, security states, and service features (Saini: paragraph 30 reveals the telemetry data includes status data. Paragraph 62 also reveal the telemetry data/configuration file is updated based on alert/notification of violation incident/performance data. Paragraph 43 also reveal the telemetry data includes different attributes/service features. Balyan: paragraphs 42-43 disclose log data is based on performance data, security data (security states), data on connectivity issues (topology information); paragraph 47 discloses log data server logs, logs that records network traffic and usage data (performance data). Yannuzzi: paragraph 123 reveals the telemetry data includes metrics, logs, traces). Motivation similar to the motivation presented in claim 2.
As to claim 4, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations comprise at least one of governmental compliance regulations and corporate compliance (Yannuzzi: paragraph 2 reveals regulation involves national , federal, state, industry, and/or organizational level).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of compliance regulations to provide a dynamic resolution and enforcement of data compliance (paragraph 1 of Yannuzzi).
As to claim 5, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations comprise General Data Protection Regulation (GDPR) enforced by international regional authorities (Yannuzzi: paragraph 54 discloses the data compliance regulation may include national regulations such as GDPR), and wherein the compliance checklist comprises individual requirements related to lawful basis and transparency, data security, accountability and governance, and privacy rights (Yannuzzi: paragraph 2 reveals regulation involves national , federal, state, industry, and/or organizational level. Regulation at the industry and/or organization level reveal individual requirements). Motivation similar to the motivation presented in claim 4.
As to claim 6, the combination of Saini in view of Balyan and Yannuzzi teaches formatting the received telemetry data into a structured format for storage in a central datastore (Yannuzzi: paragraph 109 reveals data collection platform may format the telemetry data and feed the data to full stack observability tool. Paragraphs 70, 72, 145, 157-158, and 169-171 reveals sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint complies with relevant data compliance regulations) ; defining one or more consumers of respective data of the telemetry data in the network (Saini: paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data. Yannuzzi: paragraph 36 discloses application developers label/define data consumers); transmitting the respective data to the consumers through a selected transport mechanism (Saini: paragraphs 11 and 43 reveal selected data is passed on to the different consumers based on type of data via central function such as IoT cloud access security broker), 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 (Saini: paragraph 45 reveal external/internal entities are consumer. Paragraph 55 discloses type of consumers includes cloud or micro cloud. Paragraph 41 reveals applications and modules running as containers on the various devices of the truck, connected car, enterprise IoT devices. Yannuzzi: paragraph 172 reveals the consumer is data access requestor/endpoint/node).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of formatting the telemetry data to enable a system that provides a dynamic resolution and enforcement of data compliance (paragraph 1 of Yannuzzi).
As to claim 7, the combination of Saini in view of Balyan and Yannuzzi teaches further comprising: producing the telemetry data in a telemetry handler of a respective pod of the telemetry producer (Balyan: paragraph 40 discloses the clients generates telemetry data such as logs. The clients devices are telemetry producers/pods. Saini: paragraphs 42-43 disclose the IoT operation center creates an application tag (thus define a datatype) for each device (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices) with details of what kind of traffic telemetry streams are supported for that particular telemetry exporter. The IoT-OC/pod creates/generates the telemetry configuration file); performing the checking step automatically upon production of the telemetry data by the telemetry handler (Balyan: paragraph 47 reveals an ingestion system ingest the telemetry data generated from the client devices. The ingested data are analyzed/checked using the analytical applications); and inputting the telemetry data to the datastore through a telemetry pipeline (Balyan: paragraphs 46-47 reveal the telemetry/logging data are transmitted/streamed to a distributed data store via data stream pipeline by the logging platform).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify checking the telemetry data in Saini’s teachings of processing telemetry data in view of Yannuzzi’s teachings of transmitting compliant data with Balyan’s teachings of producing the telemetry data, checking/analyzing the data, and data stream pipeline to provide a system that ensures improved data consumption and processing using an aggregation layer to deduplicate log data prior to storing the logs. The processing aids in reducing ingestion throughput and storage costs (paragraph 33 of Balyan).
As to claim 9, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the datatype is verified through at least one of a type flag or an intelligent data recognition process (Saini: paragraphs 42-43 discloses the IoT operation center creates an application tag (thus define a datatype) for each device with details of what kind of traffic telemetry streams are supported for that particular telemetry exporter. The IoT-OC/pod creates/generates the telemetry configuration file. Telemetry configuration files push/verifies the different types of telemetry data. Paragraph 45 reveals that IoT security center applies dynamic security service chain/verification based on the configuration information to check/verify any specific information leaks (flags) that could be done before publishing to external/internal entities/consumers).
As to claim 10, Saini teaches a method of processing telemetry data in a cluster network having a plurality of telemetry producers (Figures 1 and 3, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 are the telemetry exporters/producers ) each periodically [published] metric datasets (paragraph 1 disclose the present disclosure relates generally to computer networks, and, more particularly, to a secure access service edge (SASE) function with configured metric collection (e.g., telemetry) intelligence. Paragraphs 42-43 disclose the IoT operation center creates an application tag (thus define a datatype) for each device with details of what kind of traffic telemetry streams are supported for that particular telemetry exporter. The IoT-OC/pod creates/generates the telemetry configuration file. Telemetry configuration files push/verifies the different types of telemetry data), comprising:
receiving a checklist of compliance regulations (paragraph 60 reveals sharing/loading the policy/compliance with a security enforcer/telemetry enforcer. The policy for transmission of telemetry data from the telemetry exporter may comprise rules/checklist pertaining to one or more of: types of telemetry streams supported, priority, message frequency (cadence), and processing vantage point. Thus, the security enforcer/telemetry enforcer receives a checklist of compliance regulations);
distributing the checklist to the telemetry producers to maintain in respective compliance libraries (paragraph 61 reveals the operation controller sends/installs the telemetry configuration file (that defines a policy/rules/checklist) to the telemetry exporter/producers and the security enforcer. Paragraphs 42 and 58 reveal a telemetry profile/ dynamic telemetry configuration files/library is generated from the telemetry configuration files (library is a collection of files) and these are shared/installed/sent to the SASE based IoT secure center. Paragraph 72 reveals the T-MUD/ telemetry profile/ dynamic telemetry configuration files/library are maintained in the SASE IoT secure center/security enforcer and the IoT-OC. Paragraph 47 also reveals that policies pertaining to the data brokerage and destinations are defined in the IoT-OC and sent to the IoT secure center for further processing);
checking each metric dataset against a respective compliance library upon generation of the metric dataset by a telemetry producer to determine if it is compliant (paragraph 66 reveals the security enforcer processes the collected telemetry data based on a cloud access security broker. Paragraph 67 reveals the security enforcer detects violation incident pertaining to the telemetry data/configuration file received from the telemetry exporter. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraph 47 discloses telemetry data/configuration file is parsed and policies/compliance libraries are applied via security enforce IoT CASB); and
[published] compliant metric datasets to a consumer through a selected transport mechanism (Figure 3 and paragraph 61 reveal the security enforcer is caused to create a dynamic publish-subscribe stream for publishing the collected telemetry data received from the telemetry exporter based on the telemetry configuration file and the policy. The compliant data per the configuration file/policy is published for consumption via different consumers. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data).
Saini does not teach a telemetry producers each periodically generating metric datasets and transmitting compliant metric datasets to a consumer through a selected transport mechanism.
Balyan teaches a method of processing telemetry data (abstract and paragraph 1) and further teaches a telemetry producers each periodically generating metric datasets (paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers. Abstract reveals the log data indicative of metrics associated with computing system(s)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the published data in Saini’s teachings of processing telemetry data with Balyan’s teachings of processing log/telemetry data generated by clients/pods to provide a system that ensures improved data consumption and processing using an aggregation layer to deduplicate log data prior to storing the logs. The processing aid in reducing ingestion throughput and storage costs (paragraph 33 of Balyan).
The combination of Saini in view of Balyan does not teach but Yannuzzi teaches transmitting compliant metric datasets to a consumer through a selected transport mechanism. (paragraphs 70, 72, 145, 157-158, and 169-171 reveal sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint complies with relevant data compliance regulations).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of transmitting compliant data to provide application service that accurately permits an endpoint to receive/obtain access to sensitive data when permitted by the data compliance policy (paragraph 14 of Yannuzzi).
As to claim 11, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network (Saini: paragraph 30 reveals the telemetry data is collected at intervals via IoT devices communicates at different intervals with various consumers for use-cases such as telemetry collection for predictive maintenance or status collection), and consists of performance data, topology information, alerts, security states, and service features (Saini: paragraph 30 reveals the telemetry data includes status data. Paragraph 62 also reveal the telemetry data/configuration file is updated based on alert/notification of violation incident/performance data. Paragraph 43 also reveal the telemetry data includes different attributes/service features. Balyan: paragraphs 42-43 disclose log data is based on performance data, security data (security states), data on connectivity issues (topology information); paragraph 47 discloses log data server logs, logs that records network traffic and usage data (performance data). Yannuzzi: paragraph 123 reveals the telemetry data includes metrics, logs, traces), 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 (Saini: paragraph 45 reveals external/internal entities are consumer. Paragraph 55 discloses type of consumers includes cloud or micro cloud. (paragraph 41 reveals applications and modules running as containers/pods on the various devices). Yannuzzi: paragraph 172 reveals the consumer is data access requestor/endpoint/node). Motivation similar to motivation presented in claim 10.
As to claim 12, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations are provided to the user through a regulatory authority and affect at least a data security aspect of the telemetry data and content data associated with the telemetry data (Saini: paragraphs 46-53 and 71-72 disclose dynamically updating the telemetry configuration files with new restrictions and share with policy servers like an identity services engine (ISE) to amend the access rules as needed based on violations. The updates affect at least a data security aspect by blocking certain communication internal and with the cloud and updating the configuration file to certain actions (thus affecting content data associated with the telemetry data). Polices from the regulatory authority/IoT secure center are published for consumption via different consumers/users. Yannuzzi: paragraphs 110-111 reveal dynamically updating the compliance rules in real time as needed based on any deviations or potential issues. Paragraph 56 discloses a data team and/or application manager select and define data compliance requirement. Paragraphs 54-55 disclose the data compliance regulation repository maintains the data compliance rules and policies), and further wherein the telemetry data comprises data generated periodically by the producer upon operation in the cluster network (Saini: paragraph 30 reveals the telemetry data is collected at intervals via IoT devices communicates at different intervals with various consumers for use-cases such as telemetry collection for predictive maintenance or status collection), and wherein the telemetry data comprises performance data, topology information, alerts, security states, and service features (Saini: paragraph 30 reveals the telemetry data includes status data. Paragraph 62 also reveal the telemetry data/configuration file is updated based on alert/notification of violation incident/performance data. Paragraph 43 also reveal the telemetry data includes different attributes/service features. Balyan: paragraphs 42-43 disclose log data is based on performance data, security data (security states), data on connectivity issues (topology information); paragraph 47 discloses log data server logs, logs that records network traffic and usage data (performance data). Yannuzzi: paragraph 123 reveals the telemetry data includes metrics, logs, traces), 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 (Saini: paragraph 45 reveals external/internal entities are consumer. Paragraph 55 discloses type of consumers includes cloud or micro cloud. Yannuzzi: paragraph 172 reveals the consumer is data access requestor/endpoint/node). Motivation similar to motivation presented in claim 10.
As to claim 13, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations comprise at least one of governmental compliance regulations and corporate compliance (Yannuzzi: paragraph 2 reveals regulation involves national , federal, state, industry, and/or organizational level).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of compliance regulations to provide a dynamic resolution and enforcement of data compliance (paragraph 1 of Yannuzzi).
As to claim 14, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations comprise General Data Protection Regulation (GDPR) enforced by international regional authorities (Yannuzzi: paragraph 54 discloses the data compliance regulation may include national regulations such as GDPR), and wherein the compliance checklist comprises individual requirements related to lawful basis and transparency, data security, accountability and governance, and privacy rights (Yannuzzi: paragraph 2 reveals regulation involves national , federal, state, industry, and/or organizational level. Regulation at the industry and/or organization level reveal individual requirements). Motivation similar to the motivation presented in claim 13.
As to claim 15, the combination of Saini in view of Balyan and Yannuzzi teaches allowing review and update of the checklist by a user or system administrator, as needed and while the network is running and executing applications, in order to dynamically maintain up-to-date compliance libraries in each pod (Saini: paragraphs 46-47 and 71-72 disclose dynamically updating the telemetry configuration files with new restrictions and share with policy servers like an identity services engine (ISE) to amend the access rules as needed based on violations. Yannuzzi: paragraphs 110-111 reveal dynamically updating the compliance rules in real time as needed based on any deviations or potential issues. Paragraph 56 discloses a data team and/or application manager select and define data compliance requirement. Paragraphs 54-55 disclose the data compliance regulation repository maintains the data compliance rules and policies).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of updating the compliance rules/checklists to enhance management of the data compliance rules and desired states for various organizations across different regions (paragraph 114 of Yannuzzi).
As to claim 16, the combination of Saini in view of Balyan and Yannuzzi teaches further comprising: processing the telemetry data in a telemetry handler of a respective telemetry producer in each node of the plurality of nodes (Balyan: paragraph 47 reveals an ingestion system ingests the telemetry data generated from the client devices. The ingested data are process using the analytical applications, thus a telemetry handler. Recall, paragraph 40 discloses the clients generates telemetry data such as logs. The clients devices are telemetry producers/pods); and inputting the telemetry data to the datastore through a telemetry pipeline (Balyan: paragraphs 46-47 reveal the telemetry/logging data are transmitted/streamed to a distributed data store via data stream pipeline by the logging platform).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify checking the telemetry data in Saini’s teachings of processing telemetry data in view of Yannuzzi’s teachings of transmitting compliant data with Balyan’s teachings of producing the telemetry data, checking/analyzing the data, and data stream pipeline to provide a system that ensures improved data consumption and processing using an aggregation layer to deduplicate log data prior to storing the logs. The processing aids in reducing ingestion throughput and storage costs (paragraph 33 of Balyan).
As to claim 18, Saini teaches a system processing telemetry data in a cluster network having nodes each containing a plurality of pods (Figure 1, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 are the telemetry exporters/producers/pods of the IoT nodes (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices)), the system comprising:
a filter component verifying a datatype of telemetry data generated by a pod as a telemetry producer as corresponding to processed data requiring compliance with a defined regulation (paragraphs 42-43 disclose the IoT operation center/filter component creates an application tag (thus define a datatype) for each device with details of what kind of traffic telemetry streams are supported for that particular telemetry exporter. The IoT-OC/pod creates/generates the telemetry configuration file. Telemetry configuration files push/verifies the different types of telemetry data. Paragraph 45 reveals that IoT security center applies dynamic security service/verification chain based on the configuration information to check/verify any specific information leaks that could be done before publishing to external/internal entities/consumers. Paragraph 59 further disclose operation controller IoT OC generates a telemetry configuration file for the telemetry exporter. The telemetry configuration file defines a policy for transmission of telemetry data from the telemetry exporter (thus, the policy defines compliance/regulation information. Figure 3 reveals in step three that the apps and devices published the telemetry data to the IoT secure center/security enforcer);
a telemetry processing component loading data compliance rules in a checklist of a telemetry transmitter (paragraph 60 reveals the operations controller/telemetry processing component shares/loads the policy/compliance with a security enforcer/telemetry enforcer. The policy for transmission of telemetry data from the telemetry exporter may comprise rules/checklist pertaining to one or more of: types of telemetry streams supported, priority, message frequency (cadence), and processing vantage point), and installing the checklist in a compliance library maintained in each pod of the plurality of pods (paragraph 61 reveals the operation controller sends/installs the telemetry configuration file (that defines a policy/rules/checklist) to the telemetry exporter and the security enforcer. Paragraphs 42 and 58 reveal a telemetry profile/ dynamic telemetry configuration files/library is generated from the telemetry configuration files (library is a collection of files) and these are shared/installed/sent to the SASE based IoT secure center. Paragraph 72 reveals the T-MUD/ telemetry profile/ dynamic telemetry configuration files/library are maintained in the SASE IoT secure center/security enforcer and the IoT-OC. The security enforcer and the IoT-OC center are the pods. Paragraph 47 also reveals that policies pertaining to the data brokerage and destinations are defined in the IoT-OC and sent to the IoT secure center for further processing);
a compliance check component checking the telemetry data transmitted from the pod against a respective compliance library to determine if the telemetry data is compliant or non-compliant (paragraph 66 reveals the security enforcer/compliance check component processes the collected telemetry data based on a cloud access security broker. Paragraph 67 reveals the security enforcer detects violation incident pertaining to the telemetry data received from the telemetry exporter. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraph 47 discloses data is parsed and policies/compliance libraries are applied via security enforce IoT CASB); and
an interface [publishing] compliant telemetry data to a datastore for storage and collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data (Figure 3 and paragraph 61 reveal the security enforcer is caused to create a dynamic publish-subscribe stream for publishing the collected telemetry data received from the telemetry exporter based on the telemetry configuration file and the policy. The compliant data per the configuration file/policy is published for consumption via different consumers. Paragraph 45 discloses the security enforcer invokes IoT CASB to check for specific information leaks that could be done before publishing to consumers or modifying the data before publishing according to configuration files/policies. Paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data. Paragraph 24 reveal the devices in Figure 1 and 3 comprise one or more network interfaces).
Saini does not teach telemetry data generated by a pod as a telemetry producer; transmitting compliant data to a datastore for storage and collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data.
Balyan teaches a method of processing telemetry data (abstract and paragraph 1) and further teaches telemetry data generated by a pod as a telemetry producer (paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the published data from the pods in Saini’s teachings of processing telemetry data with Balyan’s teachings of processing log/telemetry data generated by clients/pods to provide a system that ensures improved data consumption and processing using an aggregation layer to deduplicate log data prior to storing the logs. The processing aid in reducing ingestion throughput and storage costs (paragraph 33 of Balyan).
The combination of Saini in view of Balyan does not teach but Yannuzzi teaches transmitting compliant data to a datastore for storage and collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data (paragraphs 70, 72, 145, 157-158, and 169-171 reveal sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint complies with relevant data compliance regulations).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of transmitting compliant data to provide application service that accurately permits an endpoint to receive/obtain access to sensitive data when permitted by the data compliance policy (paragraph 14 of Yannuzzi).
As to claim 19, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the cluster network (Saini: figures 1 and 3, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 contains pods (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices) comprises a Santorini network processing containerized data utilizing a Kubernetes-based framework (Santorini is network is understood a type of cluster system that stores the file system in a distributed system (paragraph 3 of Applicant specification). Therefore, paragraph 15 of Saini , paragraph 41 of Balyan, and paragraphs 16 and 50 of Yannuzzi disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices. Paragraph 35 of Balyan also teaches distributed processing engine that receives log data including a plurality of log files. Paragraph 58 of Yannuzzi also discloses implementing the distributed service mesh (paragraph 185) using Kubernetes ), and further wherein the plurality of nodes each contain a plurality of pods performing network functions and generating the telemetry data for transmission to the subscribing consumers (Saini: figures 1 and 3, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 contains pods (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices). Paragraphs 42-43 disclose the IoT-OC/pod creates/generates the telemetry configuration file. Balyan: paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers), and yet further 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 (Saini: paragraph 30 reveals the telemetry data includes status data. Paragraph 62 also reveal the telemetry data/configuration file is updated based on alert/notification of violation incident/performance data. Paragraph 43 also reveal the telemetry data includes different attributes/service features. Balyan: paragraphs 42-43 disclose log data is based on performance data, security data (security states), data on connectivity issues (topology information); paragraph 47 discloses log data server logs, logs that records network traffic and usage data (performance data). Yannuzzi: paragraph 123 reveals the telemetry data includes metrics, logs, traces), 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 (Saini: paragraph 45 reveals external/internal entities are consumer. Paragraph 55 discloses type of consumers includes cloud or micro cloud. Paragraph 41 reveals applications and modules running as containers on the various devices of the truck, connected car, enterprise IoT devices. Yannuzzi: paragraph 172 reveals the consumer is data access requestor/endpoint/node).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the network in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods with Yannuzzi’s teachings of utilizing Kubernetes to enable a system that provides a dynamic resolution and enforcement of data compliance (paragraph 1 of Yannuzzi).
As to claim 20, the combination of Saini in view of Balyan and Yannuzzi teaches wherein the compliance regulations are provided to the user through a regulatory authority and affect at least a data security aspect of the telemetry data and content data associated with the telemetry data (Saini: paragraphs 46-53 and 71-72 disclose dynamically updating the telemetry configuration files with new restrictions and share with policy servers like an identity services engine (ISE) to amend the access rules as needed based on violations. The updates affect at least a data security aspect by blocking certain communication internal and with the cloud and updating the configuration file to certain actions (thus affecting content data associated with the telemetry data). Polices from the regulatory authority/IoT secure center are published for consumption via different consumers/users. Yannuzzi: paragraphs 110-111 reveal dynamically updating the compliance rules in real time as needed based on any deviations or potential issues. Paragraph 56 discloses a data team and/or application manager select and define data compliance requirement. Paragraphs 54-55 disclose the data compliance regulation repository maintains the data compliance rules and policies), and further wherein the telemetry data comprises data generated periodically by the producer upon operation in the cluster network (Saini: paragraph 30 reveals the telemetry data is collected at intervals via IoT devices communicates at different intervals with various consumers for use-cases such as telemetry collection for predictive maintenance or status collection). Motivation similar to the motivation of claim 18.
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saini et al US 20230379319 (hereinafter Saini), in view of Balyan et al US 20250278348 (hereinafter Balyan), in further view of Yannuzzi et al US 20240012921 (hereinafter Yannuzzi), and in further view of Hulick et al US 20250182051 (hereinafter Hulick).
As to claim 8, the combination of Saini in view of Balyan and Yannuzzi teaches all the limitations recited in claim 7 above and further teaches a collector receiving the telemetry data (Saini: Figure 3 and paragraph 61 reveal the security enforcer is caused to create a dynamic publish-subscribe stream for publishing the collected telemetry data received from the telemetry exporter based on the telemetry configuration file and the policy. The compliant data per the configuration file/policy is published for consumption via different consumers/collectors. Paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data. Yannuzzi: paragraphs 70, 72, 145, 157-158, and 169-171 reveal sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint/collector complies with relevant data compliance regulations) and wherein cluster network includes nodes each containing a plurality of pods performing network functions and generating the telemetry data for transmission to the consumers (Saini: figures 1 and 3, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 contains pods (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices). Paragraphs 42-43 disclose the IoT-OC/pod creates/generates the telemetry configuration file. Balyan: paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers).
The combination of Saini in view of Balyan and Yannuzzi does not teach, but Hulick teaches wherein the telemetry pipeline implements an Open Telemetry (OTEL) protocol, and receiving the telemetry data through a remote procedure call (RPC) process (paragraphs 56 and 61-62 reveal OTEL protocol to export telemetry data via telemetry pipeline/exporter) and receiving telemetry data through a remote process (paragraph 20 reveals using remote services to provide data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods and Yannuzzi’s teachings of transmitting compliant data with Hulick’s teachings of OTEL protocol to provide support/assistance in analyzing the performance and behavior of the software system, as well as applications that are executed by the software system (paragraph 56 of Hulick).
As to claim 17, the combination of Saini in view of Balyan and Yannuzzi teaches all the limitations recited in claim 16 above and further teaches a collector receiving the telemetry data (Saini: Figure 3 and paragraph 61 reveal the security enforcer is caused to create a dynamic publish-subscribe stream for publishing the collected telemetry data received from the telemetry exporter based on the telemetry configuration file and the policy. The compliant data per the configuration file/policy is published for consumption via different consumers/collectors. Paragraphs 11 and 43 reveal data is passed on to the different consumers based on type of data .Yannuzzi: paragraphs 70, 72, 145, 157-158, and 169-171 reveal sensitive data/compliant data is stored at a protected data resource and procedures are utilized to ensure that access/transmission of protected data resource by an endpoint/collector complies with relevant data compliance regulations) and further wherein the cluster network comprises a Santorini network processing containerized data utilizing a Kubernetes-based framework (Santorini is network is understood a type of cluster system that stores the file system in a distributed system (paragraph 3 of Applicant specification). Therefore, paragraph 15 of Saini , paragraph 41 of Balyan, and paragraphs 16 and 50 of Yannuzzi disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices. Paragraph 35 of Balyan also teaches distributed processing engine that receives log data including a plurality of log files. Paragraph 58 of Yannuzzi also discloses implementing the distributed service mesh (paragraph 185) using Kubernetes ) and wherein cluster network includes nodes each containing a plurality of pods performing network functions and generating the telemetry data for transmission to the consumers (Saini: figures 1 and 3, abstract, and paragraph 55 disclose data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveal the IoT nodes/device generate the telemetry data. In Figure 3, app 312, truck 311, connected car 313, and enterprise IoT 314 contains pods (paragraph 41 reveals applications and modules running as containers/pods on the various devices of the truck, connected car, enterprise IoT devices). Paragraphs 42-43 disclose the IoT-OC/pod creates/generates the telemetry configuration file. Balyan: paragraph 40 discloses the clients generates telemetry data such as logs. The clients are telemetry producers).
The combination of Saini in view of Balyan and Yannuzzi does not teach, but Hulick teaches wherein the telemetry pipeline implements an Open Telemetry (OTEL) protocol, and receiving the telemetry data through a remote procedure call (RPC) process (paragraphs 56 and 61-62 reveal OTEL protocol to export telemetry data via telemetry pipeline/exporter) and receiving telemetry data through a remote process (paragraph 20 reveals using remote services to provide data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the publishing of data to consumers in Saini’s teachings of processing telemetry data in view of Balyan’s teachings of processing log/telemetry data generated by clients/pods and Yannuzzi’s teachings of transmitting compliant data with Hulick’s teachings of OTEL protocol to provide support/assistance in analyzing the performance and behavior of the software system, as well as applications that are executed by the software system (paragraph 56 of Hulick).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (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, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437