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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Specification
The disclosure is objected to because of the following informalities: Paragraph [0055], line 5, recites “intelligent log driver 240”. However, the intelligent log driver is labeled with reference numeral 245 in the drawings.
Appropriate correction is required.
Claim Objections
Claims 7, 17, and 20 are objected to because of the following informalities:
In claim 7, line 4, “as producer” should recite “as a producer”.
In claim 17, line 5, “as producer” should recite “as a producer”.
In claim 20, line 1, “The common communication channel of claim 1” should recite “The common communication channel of claim 11”. Claim 1 is not directed to a common communication channel, but rather is directed a method of using a common communication channel, whereas claim 11 is directed to the common communication channel itself.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the applications" in lines 14-15. There is insufficient antecedent basis for this limitation in the claim.
Claims 2-10 and 20 depend from claim 1, and therefore inherit the same deficiency of claim 1.
Claim 11 recites the limitation "the applications" in lines 16-17. There is insufficient antecedent basis for this limitation in the claim.
Claims 12-19 depend from claim 11, and therefore inherit the same deficiency of claim 11.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 8, 11-12, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki et al. (U.S. Pub. No. 2022/0247803), hereinafter Trocki, in view of Habel et al. (U.S. Pub. 2024/0126636), hereinafter Habel.
Regarding claim 1, Trocki teaches A method of using a common communication channel for inter-node, inter-application, and intra-application communication within a storage system, the method comprising:
creating, by an intelligent log driver (data streaming platform (DSP) 132), a set of communication topics on a distributed event store ([0024] – “the DSP 132A may connect to a stream processor registry 220 (herein after referred to as "SPR 220") via the connect module 133.”; [0014] – “The stream processor registry may read one or more topics provided by a data streaming platform to obtain data relevant to the data stream based on the one or more mutations and generate a user-specific topic comprising the data relevant to the data stream.”; [0022] – “The DSP 132A may comprise a connection module 133 (e.g., Kafka Connect) for connecting the DSP 132A with external systems such as stream processing tools, databases, key-value stores, search indexes, and file systems. The connection module 133 may allow data to be streamed to and from any such external systems. The connection module 133 may run with streaming and batch-oriented systems on a single node/computing device 130 (standalone), or may be scaled to organization-wide service (distributed). As shown in FIG. 2A, the connection module 133 may connect the DSP 132A to a database 180, where the underlying data of topics 134 may be streamed from.”);
subscribing, by the intelligent log driver to the set of communication topics as a consumer, producer, or both ([0020] – “The DSP 132A may publish, subscribe to, store, and process streams of records in real time. The DSP 132A may handle data streams from multiple sources and deliver them to multiple clients. The DSP 132A may be built into streaming data pipelines that share data between systems and/or applications of the container host 214”); […]
publishing messages containing events, logs, or commands, on individual communication topics of the respective first subsets of communication topics by the applications ([0021] – “Computing device 130A may host the DSP 132A, which may be organized into a plurality of topics 134A-134D. A topic may be a data pipeline that represents a category/feed name to which records are stored and published. The records of the DSP 132A may be organized into the topics 134A-134D Producer applications may write data to topics 134 and consumer applications 170 may read data from topics 134. Applications may connect to the DSP 132A and transfer a record onto a topic 134. A record can include any kind of information such as information about an event that has happened on a website, or an event that is supposed to trigger another event. Another application may connect to the DSP 132A and process or re-process records from a topic 134.”);
receiving the messages containing the events, logs, or commands, from the individual communication topics of the respective first subsets of communication topics by the intelligent log driver ([0021] – “Computing device 130A may host the DSP 132A, which may be organized into a plurality of topics 134A-134D. A topic may be a data pipeline that represents a category/feed name to which records are stored and published. The records of the DSP 132A may be organized into the topics 134A-134D. Producer applications 160 may write data to topics 134 and consumer applications 170 may read data from topics 134. Applications may connect to the DSP 132A and transfer a record onto a topic 134.”); […].
Trocki fails to expressly teach selectively subscribing, by each application, to a respective first subset of the communication topics as a producer on the respective first subset of communication topics, and selectively subscribing, by each application, to a respective second subset of the communication topics as a consumer on the respective second subset of communication topics; and implementing commands on the storage system, by the intelligent log driver, in response to messages received from the applications on first subsets of communication topics.
However, Habel teaches selectively subscribing, by each application, to a respective first subset of the communication topics as a producer on the respective first subset of communication topics, and selectively subscribing, by each application, to a respective second subset of the communication topics as a consumer on the respective second subset of communication topics ([0057] – “a "publisher/subscriber bus," a "publisher-subscriber bus," a "pub/sub bus," a "pub-sub bus" and the like generally refer to a messaging queue system that facilitates communication among publishers and subscribers. Publishers generally represent systems, components, or applications that produce or generate events or data and subscribers generally represent systems, components, or applications that desire to be made aware of the availability of data produced by one or more publishers or the occurrence of certain events or data relating to one or more publishers […] subscribers may subscribe to the data or topic(s) of interest (e.g., the occurrence of a particular event or type of event within a data storage management solution) generated by or otherwise associated with one or more publishers.”; [0142] – “a topic may be specified by the source component when it publishes a message and subscribers may specify the topic(s) (e.g., pub/sub/EMS topic 930 and/or pub/sub/auto-heal topic 950) for which they want to receive publications”) and implementing commands on the storage system, by the intelligent log driver, in response to messages received from the applications on first subsets of communication topics ([0144] – “The pub/sub/EMS topic 930 may be used to listen for (e.g., register to be notified regarding) key EMS messages (e.g., those to which the rule/remediation coordinator is subscribed) and used to trigger execution of rule(s) and/or remediations by the rules evaluator 960 and the task execution engine 970, respectively.”; [0154] – “the task execution engine 970 is also shown including a logic controller 971”; [0155] – “logic controller 971 may also take care of executing remediation actions (e.g., issuing storage commands, using an ML model to make predictions, and/or executing a remediation script)”; [0055] – “Non-limiting examples of remediation actions include configuration recommendations for a data management storage solution or node thereof, command recommendations to be issued to a data management storage solution or node thereof”; [0271] – “responsive to receipt of a remediation execution request via a pub/sub bus (e.g., pub/sub/auto-heal topic 950) the task execution engine may execute the set of one or more remediation actions to implement the remediation”).
Trocki and Habel are considered to be analogous art to the claimed invention because they are in the same field of computing systems implementing a topic-based messaging system to enable communication between a plurality of software applications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Trocki to incorporate the teachings of Habel such that each application may select the topics to which it is subscribed as a producer and/or consumer and to implement commands on the storage system in response to messages published by the applications. Trocki suggests applications may be producers or consumers to the topics (Trocki: [0021]), and that topics may be specified in a subscription defined by the application to narrow the data to relevant topics or events from the topics (Trocki: [0029], [0032], and [0037]-[0038]). Further, incorporating the methods of Habel would allow applications to subscribe to data or topics of interest (Habel: [0057]) and would facilitate monitoring and automatic remediation of issues in a computing system, e.g., a data management storage system, in response to event messages published to topics (Habel: [0002]-[0003],[0035], and [0040]-[0041]).
Regarding claim 2, the combination of Trocki in view of Habel teaches The method of claim 1. Trocki further teaches wherein the distributed event store is a Kafka server ([0015] – “each of the computing devices 110 and 130 may comprise a single machine or may include multiple interconnected machines (e.g., multiple servers configured in a cluster).”; [0020] – “a data streaming platform 132A (hereinafter referred to as "DSP 132A"), such as Apache Kafka™. The DSP 132A may publish, subscribe to, store, and process streams of records in real time.”; [0021] – “Computing device 130A may host the DSP 132A, which may be organized into a plurality of topics 134A-134D. […] The records of the DSP 132A may be organized into the topics 134A-134D.”).
Regarding claim 5, the combination of Trocki in view of Habel teaches The method of claim 1. Trocki teaches wherein the set of communication topics created by the intelligent log driver on the distributed event store includes an events topic ([0021] – “Applications may connect to the DSP 132A and transfer a record onto a topic 134. A record can include any kind of information such as information about an event that has happened on a website, or an event that is supposed to trigger another event. Another application may connect to the DSP 132A and process or re-process records from a topic 134.”).
Trocki does not, however Habel further teaches an events topic ([0054] – “a "risk" may identify an issue within a cluster of nodes and/or individual nodes of a distributed computing system (e.g., data management storage solution). A risk may be communicated to an auto-heal system as an alert (e.g., an EMS event that contains state information (an EMS stateful event)). In some embodiments, the state information contained within an EMS stateful event may include an associated corrective action (e.g., a remediation).”; [0136] – “the EMS topics corresponding to the key EMS events; [0142] – “pub/sub/EMS topic 930 may be used to listen for (e.g., register to be notified regarding) key EMS messages”); wherein selectively subscribing, by each application, to the respective first subset of the communication topics as producers comprises subscribing to the events topic as producers and publishing messages on the events topic related to occurrence of events at the respective applications ([0057] – “Publishers generally represent systems, components, or applications that produce or generate events or data […] subscribers may subscribe to the data or topic(s) of interest (e.g., the occurrence of a particular event or type of event within a data storage management solution) generated by or otherwise associated with one or more publishers”; [0143] – “a topic may be specified by the source component when it publishes a message”; [0203] – “an event indicative of a type of message published to the pub/sub bus is determined.”); and wherein selectively subscribing, by each application, to the respective second subset of the communication topics as consumers comprises subscribing to the events topic as consumers, reading the messages published to the events topic, and using the content of the messages published to the events topic to update respective user interface displays in accordance with the content of the messages read from the events topic ([0057] – “subscribers generally represent systems, components, or applications that desire to be made aware of the availability of data produced by one or more publishers or the occurrence of certain events or data relating to one or more publishers. […] A subscribers may subscribe to the data or topic(s) of interest (e.g., the occurrence of a particular event or type of event within a data storage management solution)”; [0204] – “Responsive to a subscription request, processing continues with block 1220 at which the requester is added as a subscriber to a topic specified by the subscription request. For example, a coordinator (e.g., rule/remediation coordinator 940) may subscribe to particular EMS events of which it would like to be notified by making a subscription request to the pub/sub bus for a corresponding EMS topic (e.g., pub/sub/EMS topic 930).”; [0211]-[0212] – “the coordinator may upon initialization subscribe to desired EMS events. For example, the coordinator may post a subscription request message specifying the pub/sub EMS topic so as to be automatically notified by the pub/sub bus of subsequent messages posted to this topic. At decision block 1310, it is determined whether a new EMS event has been received.”; [0214] – “the coordinator may determine the rule ID to which the event ID of the EMS event at issue maps”; [0217] – “the event and the associated corrective action may be brought to the attention of an administrative user of the cluster by creating an EMS alert that is displayed via a user interface of a system manager dashboard”).
It would have been obvious to one of ordinary skill in the art to have modified the intelligent log driver of Trocki which creates topics to incorporate the teachings of Habel such that the topics created include an events topic as used by the applications in Habel. Doing so would facilitate pro-active monitoring of issues (i.e., events), presentation of the issues to a user, and remediation of the issues in a computing system, e.g., a data management storage system (Habel: [0002]-[0003],[0035], and [0040]-[0041]).
Regarding claim 8, the combination of Trocki in view of Habel teaches The method of claim 1. Habel further teaches wherein the set of communication topics created by the intelligent log driver on the distributed event store includes a command topic ([0200] – “responsive to receipt of a remediation execution request via a pub/sub bus (e.g., pub/sub/auto-heal topic 950)”; [0204] – “auto-heal topics (e.g., pub/sub/auto-heal topic 950”); and
wherein selectively subscribing, by each application, to a respective first subset of the communication topics as producers comprises subscribing to the command topic as producers ([0057] – “Publishers generally represent systems, components, or applications that produce or generate events or data”; [0143] – “a topic may be specified by the source component when it publishes a message and subscribers may specify the topic(s) (e.g., pub/sub/EMS topic 930 and/or pub/sub/auto-heal topic 950) for which they want to receive publications.”; [0152] – “functions to subscribe or publish to auto-heal topics via pub/sub auto-heal topic 950.”) and publishing commands to be executed by the intelligent log driver on the command topic ([0207]-[0208] – “cause the task execution engine to execute a remediation action or script, for example, by publishing a remediation execution request to the pub/sub bus. Responsive to a remediation execution request message published (e.g., to the pub/sub/auto-heal topic 950 of FIG. 9A) by the coordinator, processing continues with block 1260 to trigger remediation execution by the task execution engine.”; [0221] – “execution of the remediation(s) may be requested, for example, by posting a remediation execution request message (including the remediation ID, and optionally the node ID to which the remediation execution is being delegated if the remediation execution is not to be performed by the primary node) may be posted to a pub/sub topic (e.g., a pub/sub "remediate" topic) to trigger execution of the remediation actions associated with the remediation ID by a task execution engine (e.g., the task execution engine 970”; [0155] – “executing remediation actions ( e.g., issuing storage commands, using an ML model to make predictions, and/or executing a remediation script)”).
It would have been obvious to one of ordinary skill in the art to have modified the topics created by the intelligent log driver as taught by Trocki to incorporate the teachings of Habel such that the topics created by the intelligent log driver include a command topic as used in Habel. Doing so would facilitate pro-active monitoring and remediation of issues in a computing system, e.g., a data management storage system (Habel: [0002]-[0003],[0035], and [0040]-[0041]).
Regarding claim 11, the combination of Trocki in view of Habel teaches A common communication channel for inter-node, inter-application, and intra-application communication within a storage system, comprising: one or more processors and one or more storage devices storing instructions that are operable, when executed by the one or more processors, to cause the one or more processors to perform operations (see Trocki: FIG. 6, processing device 602 and data storage device 618; [0045]-[0049]) comprising: the method of claim 1. Accordingly claim 11 is rejected as being unpatentable over Trocki in view of Habel for the same reasons presented with respect to claim 1.
Claims 12, 15, and 18 recite substantially the same additional limitations as claims 2, 5, and 8, respectively, applied to the common communication channel of claim 11. Accordingly, claims 12, 15, and 18 are rejected as being unpatentable over Trocki in view of Habel for the same reasons presented with respect to claims 2, 5, and 8.
Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki in view of Habel as applied to claims 1 and 11 above, and further in view of Chawla et al. (U.S. Pub. No. 2021/0288970), hereinafter Chawla.
Regarding claim 3, the combination of Trocki in view of Habel teaches The method of claim 1, but fails to expressly teach wherein the first subset of communication topics and the second subset of communication topics at least partially overlap.
However, Chawla teaches wherein the first subset of communication topics and the second subset of communication topics at least partially overlap ([0049] – “The publication/subscription service 150 comprises messages 155, message topics and/or queues 160, subscriptions 165, and publishers and/or subscribers 170. […] The message topics and/or queues 160 are named entities that each represent a feed of messages 155. A publisher 170 (e.g., administration and provisioning 120) creates and sends messages 155 to a message topic and/or queue 160. A subscriber 170 generates subscriptions 165 to obtain the messages 155 from the message topic and/or queue 160. A publisher 170 creates messages 155 and sends (publishes) them to the messaging service on a specified message topic and/or queue 160. A subscriber 170 (also called a consumer) obtains or receives messages 155 on a specified subscription 165. The subscription 165 is a named entity that represents an interest of the subscriber 170 in receiving messages on a particular message topic and/or from a particular message queue 160. In some instances, a computing node or application can be both a publisher and a subscriber 170.”; [0077] – “client microservice 360.sub.1 (MS1) and client microservice 360.sub.2 (MS2) both publish to a topic, as indicated by the respective arrows from MS1 and MS2 to request topic queue 710, and subscribe to the topic, as indicated by the arrow from bucket 740.sub.1 within response topic queue 730 to MS1 and as indicated by the arrow from bucket 740.sub.2 within response topic queue 730 to MS2.”).
Chawla is considered to be analogous art to the claimed invention because it is in the same field of computing systems implementing a topic-based messaging system to enable communication between a plurality of software applications. Therefore, it would have been obvious to one of ordinary skill in the art that the first subset of communication topics to which each application selectively subscribes as a producer and the second subset of communication topics to which each application selectively subscribes as a consumer at least partially overlap as taught by Chawla. A message topic/queue for which applications are both a producer and consumer would enable the applications to communicate bi-directionally via the topic, e.g., an application can receive and process (i.e., consume) a message published to the topic by another producer application and send (i.e., publish) an acknowledgement back to the topic to be relayed to the producer (see Chawla: [0063]). Further, incorporating the methods of Chawla would provide the advantages of consistent performance of the computing system even during times of peak loads since virtual machines can be dynamically added (and/or removed) using auto-scaling, e.g., on a number of virtual machines acting as subscribers which process published messages (see Chawla: [0037], [0050] and [0061]).
Regarding claim 4, the combination of Trocki in view of Habel and Chawla teaches The method of claim 3. Trocki further teaches wherein at least some of the applications are instantiated in different [containers] ([0016] – “The container host module 214 may be a platform for developing and running containerized applications and may allow applications and the data centers that support them to expand from just a few machines and applications to thousands of machines that serve millions of clients. Container host 214 may provide an image-based deployment module for creating containers and may store one or more image files for creating container instances. Many application instances can be running in containers on a single host without visibility into each other's processes, files, network, and so on.”) […];
the method further comprising using the communication topics to enable communication between the instances of the applications instantiated in the different [containers] ([0020] –“ The DSP 132A may be built into streaming data pipelines that share data between systems and/or applications of the container host 214 and may also be built into the systems and applications of the container host 214 that consume that data.”; [0021] – “Producer applications 160 may write data to topics 134 and consumer applications 170 may read data from topics 134. Applications may connect to the DSP 132A and transfer a record onto a topic 134. A record can include any kind of information such as information about an event that has happened on a website, or an event that is supposed to trigger another event. Another application may connect to the DSP 132A and process or re process records from a topic 134.”).
Trocki does not, however Habel further teaches the applications instantiated in different virtual machines on the storage system ([0002] – “generally relate to monitoring and remediation of the health of information technology (IT) equipment, clusters thereof, and/or services deployed within a private or public cloud, for example, running on virtual machines (VMs) or containers (or pods) managed by a container orchestration platform. In particular, some embodiments relate to an auto-healing feature that monitors events within a cluster of nodes representing a distributed data management storage system”; [0107] – “virtual storage system 410a, which may be considered exemplary of virtual storage systems 410b-c, may be run ( e.g., within a VM or in the form of one or more containerized instances, as the case may be) […] a cluster including one or more of virtual storage systems 410a-c may be analogous to data management storage solution 130 of FIG. 1”; [0109] – “The virtual storage system 410a (which may be analogous to a node of data management storage solution 130, one of nodes 202, and/or one of nodes 336a-n) may present storage over a network”; [0133] – “components of an auto-healing service 900 that may be implemented within a node (e.g., node 202, 336a-n, or one of virtual storage systems 410a-c) of a cluster (e.g., cluster 201, cluster 335, or a cluster of one or more of virtual storage systems 410a-c)”).
It would have been obvious to one of ordinary skill in the art that the different containers in which applications were instantiated as taught by Trocki could alternatively be virtual machines as taught by Habel, as Habel expressly teaches virtual machines as an alternative to containers (see Habel: [0002] and [0107]). Additionally, virtualizing the storage system, e.g. with virtual machines, provides advantages of flexibility and the ability to aggregates different portions of physical devices for improved performance and/or data redundancy (see Habel: [0107]-[0108], [0111] and [0257]).
Claims 13-14 recite substantially the same additional limitations as claims 3-4, respectively, applied to the common communication channel of claim 11. Accordingly, claims 13-14 are rejected as being unpatentable over Trocki in view of Habel and Chawla for the same reasons presented with respect to claims 3-4.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki in view of Habel as applied to claims 5 and 15 above, and further in view of Madani (U.S. Pub. No. 2019/0327297).
Regarding claim 6, the combination of Trocki in view of Habel teaches The method of claim 5. Trocki further teaches wherein subscribing, by the intelligent log driver to the set of communication topics as a consumer comprises subscribing to the events topic both as a consumer and as a producer ([0014] – “The stream processor registry may read one or more topics provided by a data streaming platform to obtain data relevant to the data stream based on the one or more mutations and generate a user-specific topic comprising the data relevant to the data stream.”; [0020] – “The DSP 132A may publish, subscribe to, store, and process streams of records in real time.”; [0021] – “A topic may be a data pipeline that represents a category/feed name to which records are stored and published. The records of the DSP 132A may be organized into the topics 134A-134D. […] Applications may connect to the DSP 132A and transfer a record onto a topic 134. A record can include any kind of information such as information about an event that has happened on a website, or an event that is supposed to trigger another event.” The DSP (analogous to the “intelligent log driver”) publishes and subscribes to data streams of event records corresponding to topics (i.e., an “events topic”).) […] publishing [messages] on the events topic ([0020] – “The DSP 132A may publish, subscribe to, store, and process streams of records in real time. The DSP 132A may handle data streams from multiple sources and deliver them to multiple clients. The DSP 132A may be built into streaming data pipelines that share data between systems and/or applications of the container host 214”).
Trocki in view of Habel fails to expressly teach the method further comprising: determining from the messages published to the events topic that one of two instances of a given application needs to be elected as master application; and in response to determining that one of the two instances of the given application needs to be elected as the master application, publishing an election decision on the events topic to notify the two instances of the application which of the two instances has been elected the master application.
However, Madani teaches determining from the messages published to the events topic that one of two instances of a given application needs to be elected as master application; and in response to determining that one of the two instances of the given application needs to be elected as the master application, publishing an election decision […] to notify the two instances of the application which of the two instances has been elected the master application ([0006] – “Publish-subscribe is an implementation method that can be used to subscribe event streams as topics. Each topic represents a type of event.”; [0018] – “registering, in a manager node, each node of a cluster of nodes in which each node receives a stream of events, the stream of events being common to each node in the cluster; maintaining, in the manager node, a data structure for each node of the cluster that identifies each respective node as a leader node or a follower node with the cluster having one leader node at a given time; receiving, in the manager node, a published output event topic from the leader node; and changing leadership status, in the manager node, from the leader node to another node of the cluster based on a performance criterion of the leader node.”; [0040] – “A cluster mechanism for providing an event streaming based service application can be structured to generate a highly available event stream processing service. The highly available characteristic of the clustering mechanism can be achieved by structuring each node of a cluster of nodes to receive the same event stream. A node, herein, is an entity that can subscribe and process topic based data event streams. The entity can be a software application responsible for a particular service task. […] With the event stream common to all nodes of the cluster, when processing of the event stream by one node is slowed down or terminated, the processing can be continued at another node of the cluster.”; [0045] – “An election process can be executed to elect node 105-2 as the leader node. The manager entity can track and manage election of a leader node from among nodes 105-1, 105-2, and 105-3”; [0046] – “Nodes 205-1, 205-2, and 205-3 can operate with bidirectional communication between nodes 205-1, 205-2, and 205-3 and manager node 215.”; [0062] – “the representative node may also cache the sequence number of the current leader obtained from communication with the manager node”; [0065] – “the representative node is elected leader of the cluster. The representative node transits from its functions at 325 to be the leader of the cluster. As leader of the cluster, the representative node processes the event stream and outputs the result of the processing.”; [0066] – “the representative node as current leader continues its leadership role unless some other performance criterion terminates this role before the associated TTL. Such performance criterion can include termination of the leader node in the cluster either as a failure or affirmative removal. The performance criterion can also include terminating the leader node as leader due to slowed execution of one or more events of one or more event streams input to the leader node. The representative node, as leader node, publishes a control event stream to each follower node of the cluster for inter-cluster node synchronization. This publication to each follower node allows the leader node to synchronize with the follower nodes for each event processed by the leader.”; [0067] – “another node of the cluster with the query at 320 has a lowest sequence number in the sequence maintained by the manager node and is elected as leader at 330.”; [0087] – “communication may be through eventually consistent asynchronous publish-subscribe communication”).
Madani is considered to be analogous art to the claimed invention because it is in the same field of computing systems implementing a topic-based publish/subscribe messaging system to enable communication between a plurality of software applications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Trocki in view of Habel to incorporate the teachings of Madani such that based on messages published to an events topic, a determination of one of multiple application instances is made to elect a master application, and that the applications are notified of the election decision. Doing so would improve availability and reliability of the application while avoiding split control by different instances of the application or deadlocking (see Madani: [0040] and [0053]).
Claim 16 recites substantially the same additional limitations as claim 6, applied to the common communication channel of claim 15, and is therefore rejected as being unpatentable over Trocki in view of Habel and Madani for the same reasons presented with respect to claim 6.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki in view of Habel as applied to claims 1 and 11 above, and further in view of Yu et al. (U.S. Pub. No. 2020/0201699), hereinafter Yu, and Eck et al. (U.S. Pub. No. 2013/0013953), hereinafter Eck.
Regarding claim 7, the combination of Trocki in view of Habel teaches The method of claim 1. Trocki teaches wherein the set of communication topics created by the intelligent log driver on the distributed event store includes a […] topic; […] and wherein subscribing, by the intelligent log driver to the set of communication topics as a consumer comprises subscribing to the […] topic as a consumer ([0014] – “The stream processor registry may read one or more topics provided by a data streaming platform to obtain data relevant to the data stream based on the one or more mutations and generate a user-specific topic comprising the data relevant to the data stream.” [0020] – “The DSP 132A may publish, subscribe to, store, and process streams of records in real time. The DSP 132A may handle data streams from multiple sources and deliver them to multiple clients. The DSP 132A may be built into streaming data pipelines that share data between systems and/or applications of the container host 214.”).
Trocki does not, however Habel further teaches a logs topic, wherein selectively subscribing, by each application, to the respective first subset of the communication topics as producer comprises subscribing to the logs topic as producers and publishing messages containing logs related to […] errors to the logs topic ([0040] – “an EMS of the issue (e.g., a risk, an error, or a failure) and potential corrective action (e.g., a remediation).”; [0056] – “a publisher/subscriber bus message, for example, identifying the occurrence of a key EMS event”; [0057] – “a "publisher/subscriber bus," a "publisher-subscriber bus," a "pub/sub bus," a "pub-sub bus" and the like generally refer to a messaging queue system that facilitates communication among publishers and subscribers. Publishers generally represent systems, components, or applications that produce or generate events or data”; [0066] – “key event management system (EMS) events may be used as trigger events to evaluate corresponding sets of one or more rules to confirm or refute the existence of potential risks, application performance, and/or availability issues to which the given data management storage solution 130 may be exposed.”; [0134] – “a publisher/subscriber (pub/sub)/EMS topic”; [0143] – “a pub/sub bus (including, for example, pub/sub/EMS topic 930 and pub/sub/auto-heal topic 950) is provided to facilitate the exchange of messages among components of the auto-healing service 900. In one embodiment, a topic may be specified by the source component when it publishes a message and subscribers may specify the topic(s) (e.g., pub/sub/EMS topic 930”; [0144] – “The pub/sub/EMS topic 930 may be used to listen for (e.g., register to be notified regarding) key EMS messages (e.g., those to which the rule/remediation coordinator is subscribed) and used to trigger execution of rule(s) and/or remediations by the rules evaluator 960 and the task execution engine 970”); and a storage system operating system [controls] physical resources made available to the applications by the storage system ([0058] – “Each of the data management solutions may have different configurations (e.g., number of nodes, software versions, software, hardware, cloud-based storage, hybrid storage, on-prem storage, etc.) and run different applications.”; [0100] – “at least a portion of physical storage 208 is distributed across nodes 202, which may connect with physical storage 208 via respective controllers (not shown). The controllers may be implemented using hardware, software, firmware, or a combination thereof. In one or more embodiments, the controllers are implemented in an operating system within the nodes 202. The operating system may be, for example, a storage operating system (OS) that is hosted by the distributed storage system. Physical storage 208 may be comprised of any number of physical data storage devices.”; [0133] – “components of an auto-healing service 900 that may be implemented within a node (e.g., node 202, 336a-n, or one of virtual storage systems 410a-c) of a cluster (e.g., cluster 201, cluster 335, or a cluster of one or more of virtual storage systems 410a-c), for example, representing a data management storage solution (e.g., data management storage solution 130)”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Trocki such that the intelligent log driver of Trocki which creates topics and subscribes to topics to incorporate the teachings of Habel such that the topics created include a logs topic as used by the applications in the storage system of Habel. Doing so would facilitate pro-active monitoring of issues (i.e., errors) in the storage system, presentation of the issues to a user, and remediation of the issues in a computing system, e.g., a data management storage system (Habel: [0002]-[0003],[0035], and [0040]-[0041]).
The combination of Trocki in view of Habel fails to expressly teach the logs related to application execution errors; reading the published messages containing the logs related to application execution errors by the intelligent log driver; and in response to reading the published messages, interacting by the intelligent log driver with the storage system operating system to adjust physical resources made available to the applications.
However, Yu teaches logs related to application execution errors ([0020] – “monitor a number of event streams 200 for records of errors 112 within the distributed system. Errors 112 may be represented by exceptions, logged errors, segmentation faults, fatal errors, crashes, core dumps, and/or other anomalies associated with components in the distributed system. Errors 112 may also be generated by different sources in the distributed system, such as different applications, processes, and/or programming language platforms in which the components are written and/or execute.”; [0024] – “aggregation apparatus 202 aggregates log entries 212 related to errors 112 into contextual logs 114 for errors 112.”); reading the published messages containing the logs related to application execution errors by the intelligent log driver ([0022] – “event streams 200 are generated and/or maintained using a distributed streaming platform such as Apache Kafka (Kafka™ is a registered trademark of the Apache Software Foundation). When a service call, transaction, error, and/or other recent activity occurs within a distributed system, a publisher in the distributed streaming platform writes a record of the activity to one or more event streams 200. […] The distributed streaming platform may then propagate the record to components subscribing to event streams 200, such as aggregation apparatus 202.”; [0041] – “logs of activity within a distributed system are received over event streams in a distributed streaming platform (operation 302). For example, hosts in the distributed system may write the logs to one or more topics in an Apache Kafka distributed streaming platform, and subscribers to the topic(s) may read the logs from one or more partitions associated with each topic.”).
Yu is considered to be analogous art to the claimed invention because it is in the in the same field of computing systems implementing a topic-based publish/subscribe messaging system to enable communication between a plurality of software applications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the logs topics created by the intelligent log driver as taught by Trocki in view of Habel to which producer applications publish messages and the intelligent log driver subscribes as a consumer, such that the published messages contain logs related to application execution errors, and that the intelligent log driver, as a subscriber of the logs topic, reads the published messages container applications execution errors as taught by Yu. The methods of Yu, including using Kafka event streams for logs containing application execution errors, enable improved monitoring, management and mitigation of the effects of errors on distributed systems, and require less storage space on machines of the system compared to conventional logging methods (see Yu: [0016] and [0018]).
The combination of Trocki in view of Habel and Yu fails to expressly teach in response to reading the published messages, interacting by the intelligent log driver with the storage system operating system to adjust physical resources made available to the applications by the storage system.
However, Eck teaches in response to reading the published messages [containing the logs related to application execution errors], interacting by the intelligent log driver with the storage system operating system to adjust physical resources made available to the applications by the storage system ([0024] – “Each guest partition 102 may have a guest operating system 108, one or more applications 112a-112n (collectively 112) [...] A guest partition 102 is configured by a virtualization platform 104 that provides each guest partition 102 with a set of virtual resources and access to the devices in the hardware layer 106. The virtual resources may include virtual processors and virtual memory that are under the control of the virtualization platform 104. […] each guest partition 102 has access to the hardware resources through a virtualization service client in the guest partition (not shown) that requests services from the hardware layer 106 through the virtualization platform 104.”; [0031] – “The host partition 122 may include a host operating system 126, […] The hardware devices in the hardware layer 106 are categorized by device types, such as, […] storage” [0050] – “The host integration component 120 receives data pertaining to anomalous events for both the guest operating system 108 and the applications 112 and forwards the anomalous event data to the respective monitor and recovery engine.”; [0056] – “The event log 306 stores the significant events that occur during the execution of an application 112 running in the guest partition 102. An event log 306 may contain the anomalous events […] The application 112 logs the events into the event log 306 at various points in the execution of the application 112.”; [0058] – “The event log may be read […] The events or health monitoring data 310 are forwarded to the application health monitor and recovery engine 136 for analysis. Based on the nature of the event, the application health monitor and recovery engine 136 determines a remedial action 312 to remedy the event”; [0065] – “The application health monitor and recovery engine 136 may then devise another remedial action which may be implemented by a component in the virtualization platform 104 depending on the type of anomalous event. For example, the remedial action may include restarting the guest partition, moving the guest partition to another virtualization platform on another system, allocate additional resources to the guest partition, release resources from other guest partitions in order to allocate additional resources to a guest partition, or reconfigure the allocation of resources for one or more of the guest partitions on the system. Based on the type of remedial action, the remedial action may require the service of the hypervisor 128, the host operating system 126, or other components on the virtualization platform 104”).
Eck is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of quickly resolving application execution errors. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the intelligent log driver taught by the teachings of Trocki in view of Habel and Yu such that in response to reading the messages containing application execution errors published to the logs topic as taught by Yu, it interacts with the operating system (e.g., the storage system operating system of Habel, where the applications are executing in the storage system) to adjust resources made available to the applications as taught by Eck. Doing so would ensure the application is able to execute continuously without long delays for diagnosing and remedying the error, and improves the overall performance of the application (see Eck: [0022]).
Claim 17 recites substantially the same additional limitations as claim 7, applied to the common communication channel of claim 11, and is therefore rejected as being unpatentable over Trocki in view of Habel, Yu and Eck for the same reasons presented with respect to claim 7.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki in view of Habel as applied to claims 1 and 11 above, and further in view of Lambros et al. (GB 2,354,349 A), hereinafter Lambros.
Regarding claim 9, the combination of Trocki in view of Habel teaches The method of claim 1, but fails to expressly teach wherein the set of communication topics created by the intelligent log driver on the distributed event store includes a command topic; wherein selectively subscribing, by each application, to the respective first subset of the communication topics as producers comprises subscribing to the command topic as producers and publishing commands to be executed by other applications on the command topic; and wherein selectively subscribing, by each application, to the respective second subset of the communication topics as consumers comprises subscribing to the command topic as consumers and receiving commands to be executed from the other applications on the command topic.
However, Lambros teaches a command topic (Abstract – “a publish/subscribe broker system 404 on a stream called "command issuance".”); wherein selectively subscribing, by each application, to the respective first subset of the communication topics as producers comprises subscribing to the command topic as producers and publishing commands to be executed by other applications on the command topic (Abstract – “When command issuing application 402 determines (501 fig 5) that a command is to be sent to command receiving application 403, it 402 publishes a message (encircled numeral 1) to a publish/subscribe broker system 404 on a stream called "command issuance".”; Page Col. 2, lines 34-39 – “publishers provide the root distribution agent 21 with the name of a distribution stream for each published message. A distribution stream (called hereinafter a "stream") is an ordered sequence of messages having a name (e.g., 11 stock 11 for a stream of stock market quotes) to distinguish the stream from other streams (this is known as "topic based" publish/subscribe”); and wherein selectively subscribing, by each application, to the respective second subset of the communication topics as consumers comprises subscribing to the command topic as consumers and receiving commands to be executed from the other applications on the command topic (Abstract – “The broker system 404 then forwards on the published message to both the command receiving application 403 and a system management tool 401 (encircled numeral 2), because both 403 and 401 have previously registered subscriptions on the stream "command issuance" with the broker system 404. Upon receiving the published message, the command receiving application 403 interprets the command as a command. […] When the application 403 has finished carrying out the work instructed by the command it publishes a message on the stream "work completed"”; Col. 2, line 42-Col. 3, line 1 – “Likewise, subscribers provide the leaf distribution agents 31 through 34 with the name of the streams to which they would like to subscribe. In this way, the broker network 2 keeps track of which subscribers are interested in which streams so that when publishers publish messages to such streams, the messages can be distributed to the corresponding subscribers.”).
Lambros is considered to be analogous art to the claimed invention because it is in the same field of computing systems implementing a topic-based publish/subscribe messaging system to enable communication between a plurality of software applications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the topics created by the intelligent log driver as taught by Trocki in view of Habel to include a command topic to which producer applications publish commands to be executed by other consumer applications subscribed to the command topic as taught by Lambros. Using a command topic would provide an efficient way of enabling the tracking of work (i.e., commands) requested and executed in a system comprising a plurality of applications which would allow for improvement to the quality of the system by managing the system based on the tracked work (see Lambros: Col. 5, line 9-14 and Col. 6, lines 10-21).
Claim 19 recites substantially the same additional limitations as claim 9, applied to the common communication channel of claim 11, and is therefore rejected as being unpatentable over Trocki in view of Habel and Lambros for the same reasons presented with respect to claim 9.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Trocki in view of Habel as applied to claim 1 above, and further in view of Thoelke (U.S. Pub. No. 2007/0266392).
Regarding claim 10, the combination of Trocki in view of Habel teaches The method of claim 1. Habel further teaches wherein the intelligent log driver and the distributed events store are implemented [to interface with] an operating system of the storage system ([0040] – “auto heal functionality may be enabled by monitoring a data management storage solution or a data storage system thereof (e.g., the Data ONTAP storage operating system available from NetApp, Inc. of San Jose, CA) for key events via a publisher/subscriber pattern (e.g., a Pub/Sub bus)”; [0100] – “The operating system may be, for example, a storage operating system (OS) that is hosted by the distributed storage system.”; [0110] – “These layers may represent components of data management software or storage operating system (not shown) of the virtual storage system 410”; [0133] – “components of an auto-healing service 900 that may be implemented within a node (e.g., node 202, 336a-n, or one of virtual storage systems 410a-c) of a cluster (e.g., cluster 201, cluster 335, or a cluster of one or more of virtual storage systems 410a-c), for example, representing a data management storage solution (e.g., data management storage solution 130)”; [0134] – “the major components that make up the auto-healing service 900 include, a rule/remediation coordinator 940, a cluster-wide task table 912, an auto-healing REST API 910, an event management system (EMS) service 920, a publisher/subscriber (pub/sub)/EMS topic 930, a rules table 911, a pub/sub/auto-heal topic 950, a rules evaluator 960, and a task execution engine 970.”; [0136] – “utilize the event digest 942 to communicate with a pub/sub bus. For example, the event digest 942 may include functions to subscribe to one or more pub/sub/EMS topics ( e.g., pub/sub/EMS topic 930) and/or publish to one or more pub/sub/auto-heal topics ( e.g., pub/sub/auto-heal topic 950).”; [0142] – “EMS service 920 may collect and log event data from different parts of the storage operating system kernel and provide event forwarding mechanisms to allow the events to be reported as EMS events . For example the EMS service 920 may be used to create and modify EMS messages”; [0143] – “a pub/sub bus (including, for example, pub/sub/EMS topic 930 and pub/sub/auto-heal topic 950) is provided to facilitate the exchange of messages” The auto-healing service comprising a pub/sub bus comprising topics (analogous to the “distributed event store”) and the task execution engine, which implements commands in response to messages published on topic(s) by applications (analogous to the “intelligent log driver”), is implemented within nodes of the storage system comprising an operating system, and interfaces with the operating system of the storage system.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Trocki to incorporate the teachings of Habel such that the intelligent log driver and distributed event store are implemented to interface with an operating system of the storage system. Doing so would facilitate monitoring and automatic remediation of issues in a computing system, e.g., a data management storage system (Habel: [0002]-[0003],[0035], and [0040]-[0041]).
The combination of Trocki in view of Habel fails to expressly teach the intelligent log driver and distributed event store are implemented as part of an application programming interface to the operating system
However, Thoelke teaches implementing the intelligent log driver and distributed event store as part of an application programming interface to an operating system ([0025] – “It is also possible for one application running on a computing device to communicate directly with another application running on the device using a mechanism known as `publish and subscribe`. With this known publish and subscribe mechanism, a first application (the publisher) establishes a property and a second application (the subscriber) is able to subscribe to that property as established by the first application.”; [0031] – “`P&S`provides both a means to store system-wide `global variables` and a new inter process communication (IPC) mechanism for peer to peer communication between threads in an operating system”; [0043] – “In the present invention, P&S is provided as a kernel API that can be used by both user and kernel programs”; [0055] – “The proposal of the present invention is, therefore, to provide a new form of publish and subscribe mechanism that is implemented in the operating system kernel. Such a P&S mechanism has many benefits over all of the above described publish and subscribe mechanisms, […] This provides a very efficient mechanism for event notification and it can be appreciated that this results in a novel method of IPC in a computing device operating system.”; [0093] – “A message queue facility may also be provided as part of the P&S API. […] With the provision of this facility, the P&S mechanism can enable a publisher to send messages to a number of subscribing interested parties”; [0094] – “A single queue can be shared between many message readers (subscribers) and message writers (publishers).”; [0096]-[0101] – “There are five basic operations that need to be supported by such a P&S API having a message queue mechanism: Creating/opening a message queue[;] Sending a message[;] Receiving a message[;] Waiting for space in the queue[;] Waiting for data in the queue.”)
Thoelke is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between a plurality of producer and consumer applications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the intelligent log driver and distributed event store taught by the combination of Trocki in view of Habel to be implemented as part of an API to the operating system as taught by Thoelke. Doing so would enable communication between applications (inter-process communication), as well as between user and kernel code, via a publish and subscribe mechanism which is more efficient, is usable for real-time systems, and has improved security (see Thoelke: [0026], [0055], and [0115]]).
Claim 20 recites substantially the same additional limitations as claim 10, and is therefore rejected as being unpatentable over Trocki in view of Habel and Thoelke for the same reasons presented with respect to claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Synytskyy (U.S. Patent No. 10,887,253) teaches applications are frequently both a publisher, i.e., producer, and subscriber, i.e., consumer, of topics of content (see Col. 3, lines 29-59).
Noble et al. (U.S. Pub. No. 2003/0046479) teaches a topic based, publish/subscribe data communication mechanism, implemented in a data storage system having a unified container layer for an active data storage, where the data communication mechanism enables communication between applications local to the data storage system or remote in other connected data storage system (see Abstract, [0032], and [0037]-[0039]).
Handa et al. (U.S. Pub. No. 2019/0079818) teaches a log management system which communications with a log message system for creating, retrieving, reading, updating, and/or deleting a Kafka topic, where components, e.g. applications, in execution, generate and write messages comprising log data, error messages, etc. to topics of the log message system (see [0056] and [0069]-[0070]).
Tripathi et al. (U.S. Pub. No. 2022/0318208) teaches a distributed file storage system comprising a virtualized file server that publishes event data records using a Kafka connector to topics for consumption by other services, e.g., an analytics virtual machine (see [0014], [0055], [0113]-[0114], and [0120]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights