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 .
Response to Amendment
The amendment filed 18 May 2026 has been entered. Applicant amended claims 1, 10, 17-19. Accordingly, claims 1-20 remain pending.
The amendment to the specification overcomes the specification and drawing objections of 18 February 2026. Therefore, the specification and drawing objections of 18 February 2026 are withdrawn.
Applicant’s amendment to the claims overcomes the 35 USC 112(a) and 112(b) rejections of 18 February 2026. Therefore, the35 USC 112(a) and 112(b) rejections of 18 February 2026 are withdrawn.
Applicant’s amendment to the claims results in the claim interpretation under 112(f) to be moot.
Applicant’s amendment to the claims overcome the 35 USC 101 rejection of 18 February 2026. Therefore, the 35 USC 101 rejection of 18 February 2026 is withdrawn.
Response to Arguments
Drawing and Specification Objections:
Applicant’s arguments, filed 18 May 2026, with respect to the drawing and specification objections of 18 February 2026 have been fully considered and are persuasive. The drawing and specification objections of 18 February 2026 have been withdrawn.
35 USC 112(a) and 112(b) Rejections:
Applicant’s arguments, filed 18 May 2026, with respect to the 35 USC 112(a) and 112(b) rejections of 18 February 2026 have been fully considered and are persuasive. The 35 USC 112(a) and 112(b) rejections of 18 February 2026 have been withdrawn.
35 USC 101 Rejection:
Applicant’s arguments, filed 18 May 2026, with respect to the 35 USC 101 rejection of 18 February 2026 have been fully considered and are persuasive. The 35 USC 101 rejection of 18 February 2026 has been withdrawn
35 USC 103 Rejection:
Applicant’s Remarks:
Saini does not teach or suggest a distributed network comprising a Santorini system as recited in the amended claims.
Examiner’s remarks:
A Santorini is network is understood as a type of cluster system that stores the file system in a distributed system (paragraph 3 of Applicant specification). Therefore, paragraph 15 of Saini disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices. Saini also disclose in figures 1 and 3, abstract, and paragraph 55 data collection and processing of telemetry data in a cluster network that comprises data center, fog nodes, IoT nodes. Paragraph 31 reveals the IoT nodes/device generates the telemetry data. Furthermore, 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).
Applicant’s remaining arguments with respect to the amended limitation in the independent claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 1-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.
Claim 1 recites the limitation “stateless independent Data Domain services”. The examiner does not find support for “stateless independent Data Domain services”; therefore, the claim is rejected under 35 USC 112(a) as being new matter. While the examiner did find support for Data Domain system, Data Domain protection storage, and Data Domain process, there was no support found in the original disclosure for stateless independent Data Domain services. It is requested for Applicant to pinpoint in the disclosure the support for stateless independent Data Domain services.
Claim 1 further recites new matter of “hardware-based telemetry transmitter”, “compliance library stored in storage” and “processor-based automatic security compliance checker”. These limitations were not disclosed in the original disclosure and are rejected under 35 USC 112(a) as new matter. It is requested for Applicant to pinpoint in the disclosure the support for these limitations.
Claims 2-9 are rejected to because said claims depend upon rejected claim 1.
Claim 10 recites the limitation “stateless independent Data Domain services”. The examiner does not find support for “stateless independent Data Domain services”; therefore, the claim is rejected under 35 USC 112(a) as being new matter. While the examiner did find support for Data Domain system, Data Domain protection storage, and Data Domain process, there was no support found in the original disclosure for stateless independent Data Domain services. It is requested for Applicant to pinpoint in the disclosure the support for stateless independent Data Domain services.
Claim 10 further recites new matter of “hardware-based telemetry transmitter”, “compliance library stored in storage”, and “processor-based automatic security compliance checker”. These limitations were not disclosed in the original disclosure and are rejected under 35 USC 112(a) as new matter. It is requested for Applicant to pinpoint in the disclosure the support for these limitations.
Claims 11-17 are rejected to because said claims depend upon rejected claim 10.
Claim 18 recites the limitation “stateless independent Data Domain services”. The examiner does not find support for “stateless independent Data Domain services”; therefore, the claim is rejected under 35 USC 112(a) as being new matter. While the examiner did find support for Data Domain system, Data Domain protection storage, and Data Domain process, there was no support found in the original disclosure for stateless independent Data Domain services. It is requested for Applicant to pinpoint in the disclosure the support for stateless independent Data Domain services.
Claim 18 further recites new matter of “hardware-based collector”, “hardware-based telemetry transmitter processor”, “processor-based automatic security compliance checker”, and “hardware-based interface”. These limitations were not disclosed in the original disclosure and are rejected under 35 USC 112(a) as new matter. t is requested for Applicant to pinpoint in the disclosure the support for these limitations.
Claims 19-20 are rejected to because said claims depend upon rejected 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 1-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.
Claim 1 recites the limitation "the namespace". There is insufficient antecedent basis for this limitation in the claim.
Claims 2-9 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 1.
Claim 10 recites the limitation "the namespace". There is insufficient antecedent basis for this limitation in the claim.
Claims 11-17 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 10.
Claim 18 recites the limitation "the namespace". There is insufficient antecedent basis for this limitation in the claim.
Claims 19-20 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 18.
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), in further view of Yannuzzi et al US 20240012921 (hereinafter Yannuzzi), and in further view of Vohra et al US 20230195444 (hereinafter Vohra).
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 hardware-based 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described);
installing the checklist in a compliance library stored in storage 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described);
checking, in a processor-based automatic security compliance checker, 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described); and
[publish] compliant data for collection by a telemetry collector of a telemetry transmitter, and preventing storage of non-compliant data so as to conform to compliance guidelines and regulations controlling access to the telemetry 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), 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 of the plurality of nodes (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 disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices).
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; wherein …the plurality of nodes, each having a log-structured file system implemented in a Data Domain Filesystem, and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises stateless independent Data Domain services processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
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) and wherein the cluster network comprises a Santorini network of the plurality of nodes each having a log-structured file system implemented in a Data Domain Filesystem (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 41 of Balyan, disclose a distributed collections of nodes. Paragraph 35 of Balyan also teaches distributed processing engine that receives log data including a plurality of log files. Paragraph 46 discloses the log data generated to a distributed data store (paragraph 52 discloses the distributed data store may be a storage system. Paragraph 47 discloses log data may be structured and paragraph 48 discloses the storage system may include a distributed file system. A data domain filesystem is a distributed filesystem) and further wherein the Santorini network (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 41 of Balyan, disclose a distributed collections of nodes) comprises stateless independent Data Domain services (paragraph 53 discloses the distributed file system (a data domain filesystem is a distributed filesystem) may be any computer network where data is stored on more than one node (e.g., virtual machine, cluster of virtual machines, servers, etc.). For instance, the distributed file system may include various types of nodes for storing data and segments with differing requirements (independent requirements/services)).
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 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; and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises … processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
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 so as to conform to compliance guidelines and regulations controlling access to the telemetry 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) and further wherein the Santorini network comprises … 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).Paragraphs 16 and 50 of Yannuzzi disclose a distributed collections of nodes. Paragraph 58 of Yannuzzi also discloses implementing the distributed service mesh (paragraph 185) using Kubernetes ).
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).
The combination of Saini in view of Balyan and Yannuzzi does not teach, but Vohra teaches wherein the cluster network comprises the plurality of nodes each having a log structured file system implemented in a data domain file system (paragraph 104 discloses UNIX-style file system which is a data domain file system and paragraph 107 reveals metadata may be stored using an ordered log structured index); wherein the namespace contains file metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms. Some of these layouts store file metadata ) implemented as a layered key-value store (KVS) (paragraphs 102 and 262 reveal the storage using key value store/database), and further wherein the Santorini network comprises data domain services (paragraph 202 discloses cluster network/Santorini network, wherein the file system is a distributed metadata architecture. The file system may include a plurality of metadata servers across which metadata is distributed, as well as components that include services for clients and storage servers) and the Santorini network comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes (paragraph 106 discloses a series of address-space transformations takes place across an entire storage system. At the top are the directory entries (file names) which link to an inode/node. Inodes point into medium address space, where data is logically stored. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Paragraph 138 discloses backup operations for the cloud services and storage systems. Paragraph 105 discloses restore operation) and stores file system metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms, some of these layouts store file metadata; and paragraphs 102 and 262 reveal the storage using key value store/database ) and a fingerprint index in the KVS (paragraph 87 reveals storing metadata such as indexes; paragraph 107 reveals metadata may be stored using an ordered log structured index; and paragraphs 102 and 262 reveal the storage using key value store/database).
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 cluster network 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 Vohra’s teachings of file metadata, key value store, and backup and restore operations to allow each component of the storage system to be replaced with ease over time without reconfiguration or disruptions of client request processing, i.e., the system supports non-disruptive upgrades and allows detection and prediction of failures due to faulty components and manufacturing details and to enable the proactive transfer of authorities and entities away from impacted devices before failure occurs by removing the component from the critical path in some embodiments (paragraphs 113-114 of Vohra).
As to claim 2, the combination of Saini in view of Balyan, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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 through a hardware-based telemetry transmitter 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described);
checking, in a processor-based automatic security compliance checker, 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described); and
[published] compliant metric datasets to a consumer through a selected transport mechanism so as to conform to compliance guidelines and regulations controlling access to the telemetry 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); 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 of the plurality of nodes (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 disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices).
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; wherein …the plurality of nodes, each having a log-structured file system implemented in a Data Domain Filesystem, and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises stateless independent Data Domain services processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
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)); and wherein the cluster network comprises a Santorini network of the plurality of nodes each having a log-structured file system implemented in a Data Domain Filesystem (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 41 of Balyan, disclose a distributed collections of nodes. Paragraph 35 of Balyan also teaches distributed processing engine that receives log data including a plurality of log files. Paragraph 46 discloses the log data generated to a distributed data store (paragraph 52 discloses the distributed data store may be a storage system. Paragraph 47 discloses log data may be structured and paragraph 48 discloses the storage system may include a distributed file system. A data domain filesystem is a distributed filesystem) and further wherein the Santorini network (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 41 of Balyan, disclose a distributed collections of nodes) comprises stateless independent Data Domain services (paragraph 53 discloses the distributed file system (a data domain filesystem is a distributed filesystem) may be any computer network where data is stored on more than one node (e.g., virtual machine, cluster of virtual machines, servers, etc.). For instance, the distributed file system may include various types of nodes for storing data and segments with differing requirements (independent requirements/services)).
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 transmitting compliant metric datasets to a consumer through a selected transport mechanism; and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises … processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
Yannuzzi teaches transmitting compliant metric datasets to a consumer through a selected transport mechanism so as to conform to compliance guidelines and regulations controlling access to the telemetry 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).
The combination of Saini in view of Balyan and Yannuzzi does not teach, but Vohra teaches wherein the cluster network comprises the plurality of nodes each having a log structured file system implemented in a data domain file system (paragraph 104 discloses UNIX-style file system which is a data domain file system and paragraph 107 reveals metadata may be stored using an ordered log structured index); wherein the namespace contains file metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms. Some of these layouts store file metadata ) implemented as a layered key-value store (KVS) (paragraphs 102 and 262 reveal the storage using key value store/database), and further wherein the Santorini network comprises data domain services (paragraph 202 discloses cluster network/Santorini network, wherein the file system is a distributed metadata architecture. The file system may include a plurality of metadata servers across which metadata is distributed, as well as components that include services for clients and storage servers) and the Santorini network comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes (paragraph 106 discloses a series of address-space transformations takes place across an entire storage system. At the top are the directory entries (file names) which link to an inode/node. Inodes point into medium address space, where data is logically stored. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Paragraph 138 discloses backup operations for the cloud services and storage systems. Paragraph 105 discloses restore operation) and stores file system metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms, some of these layouts store file metadata; and paragraphs 102 and 262 reveal the storage using key value store/database ) and a fingerprint index in the KVS (paragraph 87 reveals storing metadata such as indexes; paragraph 107 reveals metadata may be stored using an ordered log structured index; and paragraphs 102 and 262 reveal the storage using key value store/database).
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 cluster network 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 Vohra’s teachings of file metadata, key value store, and backup and restore operations to allow each component of the storage system to be replaced with ease over time without reconfiguration or disruptions of client request processing, i.e., the system supports non-disruptive upgrades and allows detection and prediction of failures due to faulty components and manufacturing details and to enable the proactive transfer of authorities and entities away from impacted devices before failure occurs by removing the component from the critical path in some embodiments (paragraphs 113-114 of Vohra).
As to claim 11, the combination of Saini in view of Balyan, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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 hardware-based collector 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described);
a hardware-based dynamic telemetry processor 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described);
a processor-based automatic security compliance checker 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. Paragraph 73 discloses the techniques described maybe performed by hardware such as in accordance with the illustrative telemetry configuration process, which may include computer executable instructions executed by the processor to perform functions relating to the techniques described); and
a hardware-based 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 so as to conform to compliance guidelines and regulations controlling access to the telemetry 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); 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 of the plurality of nodes (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 disclose a distributed collections of nodes. Paragraph 41 of Saini reveals applications and modules running as containers/pods on the various devices).
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; wherein …the plurality of nodes, each having a log-structured file system implemented in a Data Domain Filesystem, and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises stateless independent Data Domain services processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
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) and wherein the cluster network comprises a Santorini network of the plurality of nodes each having a log-structured file system implemented in a Data Domain Filesystem (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 41 of Balyan, disclose a distributed collections of nodes. Paragraph 35 of Balyan also teaches distributed processing engine that receives log data including a plurality of log files. Paragraph 46 discloses the log data generated to a distributed data store (paragraph 52 discloses the distributed data store may be a storage system. Paragraph 47 discloses log data may be structured and paragraph 48 discloses the storage system may include a distributed file system. A data domain filesystem is a distributed filesystem) and further wherein the Santorini network (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 41 of Balyan, disclose a distributed collections of nodes) comprises stateless independent Data Domain services (paragraph 53 discloses the distributed file system (a data domain filesystem is a distributed filesystem) may be any computer network where data is stored on more than one node (e.g., virtual machine, cluster of virtual machines, servers, etc.). For instance, the distributed file system may include various types of nodes for storing data and segments with differing requirements (independent requirements/services)).
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 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; and wherein the namespace contains file metadata implemented as a layered key-value store (KVS), and further wherein the Santorini network comprises … processing containerized data utilizing a Kubernetes-based framework, and comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes and stores file system metadata and a fingerprint index in the KVS.
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 so as to conform to compliance guidelines and regulations controlling access to the telemetry 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) and further wherein the Santorini network comprises … 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).Paragraphs 16 and 50 of Yannuzzi disclose a distributed collections of nodes. Paragraph 58 of Yannuzzi also discloses implementing the distributed service mesh (paragraph 185) using Kubernetes ).
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).
The combination of Saini in view of Balyan and Yannuzzi does not teach, but Vohra teaches wherein the cluster network comprises the plurality of nodes each having a log structured file system implemented in a data domain file system (paragraph 104 discloses UNIX-style file system which is a data domain file system and paragraph 107 reveals metadata may be stored using an ordered log structured index); wherein the namespace contains file metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms. Some of these layouts store file metadata ) implemented as a layered key-value store (KVS) (paragraphs 102 and 262 reveal the storage using key value store/database), and further wherein the Santorini network comprises data domain services (paragraph 202 discloses cluster network/Santorini network, wherein the file system is a distributed metadata architecture. The file system may include a plurality of metadata servers across which metadata is distributed, as well as components that include services for clients and storage servers) and the Santorini network comprises part of a Data Domain deduplication backup system performing backup and restore operations for the plurality of nodes (paragraph 106 discloses a series of address-space transformations takes place across an entire storage system. At the top are the directory entries (file names) which link to an inode/node. Inodes point into medium address space, where data is logically stored. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Paragraph 138 discloses backup operations for the cloud services and storage systems. Paragraph 105 discloses restore operation) and stores file system metadata (paragraph 107 discloses data and metadata is stored by a set of underlying storage layouts that are optimized for varying workload patterns and storage devices. These layouts incorporate multiple redundancy schemes, compression formats and index algorithms, some of these layouts store file metadata; and paragraphs 102 and 262 reveal the storage using key value store/database ) and a fingerprint index in the KVS (paragraph 87 reveals storing metadata such as indexes; paragraph 107 reveals metadata may be stored using an ordered log structured index; and paragraphs 102 and 262 reveal the storage using key value store/database).
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 cluster network 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 Vohra’s teachings of file metadata, key value store, and backup and restore operations to allow each component of the storage system to be replaced with ease over time without reconfiguration or disruptions of client request processing, i.e., the system supports non-disruptive upgrades and allows detection and prediction of failures due to faulty components and manufacturing details and to enable the proactive transfer of authorities and entities away from impacted devices before failure occurs by removing the component from the critical path in some embodiments (paragraphs 113-114 of Vohra).
As to claim 19, the combination of Saini in view of Balyan, Yannuzzi, and Vohra teaches 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, Yannuzzi, and Vohra 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), in further view of Vohra et al US 20230195444 (hereinafter Vohra), and in further view of Hulick et al US 20250182051 (hereinafter Hulick).
As to claim 8, the combination of Saini in view of Balyan, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi’s teachings of transmitting compliant data, and Vohra’s teachings of file metadata, key value store, and backup and restore operations 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, Yannuzzi, and Vohra 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, Yannuzzi, and Vohra 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, Yannuzzi’s teachings of transmitting compliant data, and Vohra’s teachings of file metadata, key value store, and backup and restore operations 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Prosecution Insights