DETAILED ACTION
This communication is in responsive to Application 18/315599 filed on 5/11/2023. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims:
Claims 1-20 are presented for examination.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation is:
Claim 9 recites “management service computing system” which invokes 112 (f) because the claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “system” as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “system” is modified by functional language, “configured to”; and
(C) the generic placeholder “management service computing system” is not modified by sufficient structure, material, or acts for performing the claimed function. The “management service computing” does not connote sufficient structure for performing the claimed function.
Figs. 3-5 and related paragraphs provide structure and step by step algorithm to perform the claimed function.
Because this claim limitation is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 17 is objected to because of the following informalities: the limitation “in the nodes, communicating the multicast statistical information to a management service
in the management service,” is missing “;” at the end of the limitation line 9. It should be “in the nodes, communicating the multicast statistical information to a management service; in the management service,” Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
A. Independent Claims 1, 9 and 17:
Claim 1 recites receiving information about quantities of packets received in relation to a container group. The claim then aggregates this information and display it. This is abstract because the claim falls under the mental process of abstract ideas.
In summary, the concept of receiving information about quantities of packets received in relation to a container group then displaying that information is similar to observation, evaluation, judgment and opinion about the data (definition of mental processes abstract idea). The recitation also of generic computer components in the claim (ingress, egress, nodes, packets and container groups) does not necessarily preclude claim 1 from reciting an abstract idea. This is also abstract under old guidelines electric power group where the court held that collecting or gathering data then displaying that data is abstract.
Analysis: the limitation of “receiving” multicast statistical information from nodes, this information is about quantities of ingress and egress packets executed on the nodes collected from monitoring network traffic is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer or generic computer components. That is, other than reciting “a method comprising in a management service… where packets executing on the nodes collected from monitoring network traffic at the nodes”, nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the above language, “receiving” in the context of this claim encompasses the user being provided with information on a sheet of paper then reading the information about the received ingress or egress packets, etc. This is similar to observation and evaluation of mental processes.
Similarly, the limitations of aggregating the multicast information and generating a summary for display, are directed to process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. For example, “management service,” “aggregating”, “generating a summary”, and “display” in the context of this claim encompasses the user sort the information on a piece of paper, collecting the information, making observation and conclusion about the information. This is similar to evaluation and judgment of mental processes.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim recites additional elements – using a management service to receive packets, aggregate the data and generating a summary where the data is quantity of ingress and egress multicast with container groups and nodes steps. The management service/method for performing the steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of analyzing information of two entities and inferring a relationship between the two entities) such that it amounts no more than mere instructions to apply the exception using a generic computer. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim includes additional elements like nodes, computing environment, ingress and egress multicast packets, and display that are not sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a management service to perform the steps of “receiving”, “aggregating”, and “generating a summary” amounts to no more than mere instructions to apply the exception using a generic computer. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. The claim is not patent eligible.
Similar rationales apply to independent claims 9 and 17 because claims 9 and 17 are not substantially different from independent claim 1. Claim 17 recite additionally IGMP packets or MLD packets. The additional element of using IGMP packets or MLD packets for packet type falls under additional elements which are not sufficient to amount to significantly more than the judicial exception and still amounts to no more than mere instructions to apply the exception using a generic computer. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. The claim is not patent eligible.
B. Dependent claims:
a. The dependent claims 2-8, 10-16 and 18-20 are also rejected under 35 U.S.C 101 as being directed to non-statutory subject matter for the same reasons addressed above as the claims do not contain any additional element or combination of elements which amount to significantly more than the abstract idea itself.
Claims 2, 10 and 18 recite additional elements of “physical computers or virtual machines”, are to further limiting the nodes which can be performed by human mind or on paper. The additional elements also are not sufficient to amount to significantly more than the judicial exception because using a generic computer components or mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Furthermore, the recitation of generic computer components in the claim (physical computers or VM) does not necessarily preclude claims 2, 10 and 18 from reciting an abstract idea. The claim is not patent eligible.
Claims 3, 11 and 20 recite additional elements of “IP address”, are to further limiting packets received by the multicast group which can be performed by human mind or on paper. The additional elements also are not sufficient to amount to significantly more than the judicial exception because using a generic computer components or mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Furthermore, the recitation of generic computer components in the claim (IP address) does not necessarily preclude claims 3, 11 and 20 from reciting an abstract idea. The claim is not patent eligible.
Claims 4 and 12 do not recite additional elements instead the claims focus on a first node to further limiting the nodes. The rationale in the independent claims applies here too which can be performed by human mind or on paper.
Claims 5-6, 13-14 and 19 recite additional elements of “ingress…egress…packets”, are to further limiting the type of packets. The rationale in the independent claims applies here too which can be performed by human mind or on paper.
Claims 7-8 and 15-16 recite additional elements of “identifier”, is directed to further limiting the information. The rationale in the independent claims applies here too which can be performed by human mind or on paper.
The dependent claims 2-8, 10-16 and 18-20 are not patent eligible because they do not contain any additional element or combination of elements which amount to significantly more than the abstract idea itself.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (hereinafter Li) US 2023/0261962 A1 in view of Thyamagundalu et al. (hereinafter Thyamagundalu) US 2016/0285932 A1 and further in view of Bresalu et al. (hereinafter Bresalu) US 7180856 B1.
Regarding Claim 1, Li teaches a method comprising:
in a management service, receiving multicast statistical information from nodes in a computing environment (Fig. 3, ¶0003, ¶0011 & ¶0062; the method further includes that the first node receives and collects statistics about first quantity information and first time information, where the first quantity information is a quantity of data packets in the multicast service flow that are received in a preset period), wherein the multicast statistical information comprises quantities of ingress and egress multicast packets (¶0074 & ¶0089; node in the multicast detection domain further sends detection information to a control node, where the detection information sent by an ingress of the node to the control node includes an ingress identifier, a first detection identifier, a quantity of data packets received in a preset period, and a timestamp of each data packet received in the preset period, and the detection information sent by an egress of the node to the control node includes an egress identifier, the first detection identifier, the quantity of data packets sent in the preset period, and a timestamp of each data packet sent in the preset period) associated with container groups executing on the nodes collected from monitoring network traffic at the nodes (Fig. 3 & ¶0086-¶0090; head node 304A & B is further configured to collect statistics about detection information of an incoming service flow, and upload the detection information to the control node 302);
in the management service, aggregating the multicast statistical information from the nodes (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]);
Li does not teach that the information collected is for “…associated with container groups …” & “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information.”
As to “…associated with container groups …” limitation, Thyamagundalu is analogous art because Thyamagundalu is directed to monitoring multicast traffic in a multi-pod network environment [plurality of container groups container]. See ¶0018 & Fig. 1.
Thyamagundalu also teaches “…associated with container groups …” (Fig. 1 & ¶0018-¶0019; BD1 (with member nodes in pods A, C and D) and BD2 (with member nodes in pods A, B and D). Merely as an example and not as a limitation, endpoints H1, H2 in pod A, endpoint H3 in pod C, and endpoint H4 in pod D may be members of BD1 that spans across pods A, C and D in network 12)).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Thyamagundalu that includes multi-pod network into the system of Li that monitors ingress and egress packets for multicast groups in order to derive a global multicast group identical for the broadcast domain across the plurality of pods, and associating a local multicast group at the translator with the derived global multicast group (abstract).
Li in view of Thyamagundalu does not expressly teach “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information.”
Bresalu teaches “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information” (Figs. 2-6; Fig. 2 request to start a multicast traffic monitoring. Figs. 3-6 illustrate proactive multicast summary based on the request).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Bresalu into the system of Li in view of Thyamagundalu in order to monitor traffic in a multicast network (abstract). Utilizing such teachings enable the system to initiate an alarm in response to detecting a specific status being less than a predetermined value (abstract).
Regarding Claim 2, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 1, Li further teaches wherein the nodes comprise physical computers or virtual machines (¶0080; physical device. ¶0092; physical computers).
Regarding Claim 3, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 1, Li further teaches wherein the summary request indicates a multicast group comprising a set of container groups from the container groups, and wherein the summary indicates a quantity of packets received by the multicast group with a multicast IP address associated with the multicast group (Fig. 3 & ¶0086-¶0090 & ¶0102; quantities of packets of plurality of nodes. ¶0089; IP address. ¶0012-¶0013; multicast source address and multicast group address).
Regarding Claim 4, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 1 Li further teaches further comprising: in a first node of the nodes, monitoring the network traffic associated with one or more container groups of the container groups on the first node (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]);
in the first node, identifying one or more multicast packets in the network traffic associated with the one or more container groups (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]);
in the first node, identifying multicast statistical information for the first node based on the identified one or more multicast packets (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]);
and in the first node, communicating the multicast statistical information for the first node to the management service (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]).
Li does not expressly disclose that the collection of data with respect to containers. Thyamagundalu teaches “…container groups …” (Fig. 1 & ¶0018-¶0019; BD1 (with member nodes in pods A, C and D) and BD2 (with member nodes in pods A, B and D). Merely as an example and not as a limitation, endpoints H1, H2 in pod A, endpoint H3 in pod C, and endpoint H4 in pod D may be members of BD1 that spans across pods A, C and D in network 12)).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Thyamagundalu that includes multi-pod network into the system of Li that monitors ingress and egress packets for multicast groups in order to derive a global multicast group identical for the broadcast domain across the plurality of pods, and associating a local multicast group at the translator with the derived global multicast group (abstract).
Regarding Claim 5, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 4, Li further teaches wherein the one or more multicast packets comprise one or more ingress multicast packets directed to the one or more container groups, or one or more egress packets communicated from the one or more container groups (Fig. 3 & ¶0086-¶0090 & ¶0102; quantities of packets of plurality of nodes. Thyamagundalu teaches pods in ¶0018-¶0019).
Regarding Claim 6, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 1, Li further teaches wherein the quantities of ingress and egress multicast packets associated with the container groups on the nodes comprises quantities of permitted or dropped multicast packets associated with the container groups on the nodes (obvious from ¶0066 because quantity of packets with a period of time is limited. For example, the detection result sent by the ingress 1 of the head node may be a quantity and timestamps of data packets received according to a preset period. The detection result sent by the egress 2 of the head node may be a quantity and timestamps of data packets encapsulated with the second detection identifier 100:100 that are sent according to the preset period. The detection result sent by the egress 3 of the head node may be a quantity and timestamps of data packets encapsulated with the second detection identifier 100:200 that are sent according to the preset period. The control node (not shown in the figure) receives information sent by the head node 201. Because the sent information includes the first detection identifier 100, the control node (not shown in the figure) may identify that the reported information is a multicast service flow carrying the same first detection identifier 100, and may perform hop-by-hop packet loss detection on the multicast service flow, which is {the detection result of the ingress 1−the detection result of the ingress 2 or the detection result of the ingress 1−the detection result of the ingress 3}).
Regarding Claim 7, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 1, Thyamagundalu further teaches wherein the multicast statistical information comprises identifiers for one or more container groups of the container groups registered in association with each multicast group of a plurality of multicast groups (Fig. 1 & ¶0018-¶0019; BD1 (with member nodes in pods A, C and D) and BD2 (with member nodes in pods A, B and D). Merely as an example and not as a limitation, endpoints H1, H2 in pod A, endpoint H3 in pod C, and endpoint H4 in pod D may be members of BD1 that spans across pods A, C and D in network 12)).
Regarding Claim 8, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 7, Thyamagundalu further teaches wherein the summary indicates, for at least one multicast group of the multicast groups, the one or more container groups associated the at least one multicast group (Fig. 1 & ¶0018-¶0019; BD1 (with member nodes in pods A, C and D) and BD2 (with member nodes in pods A, B and D). Merely as an example and not as a limitation, endpoints H1, H2 in pod A, endpoint H3 in pod C, and endpoint H4 in pod D may be members of BD1 that spans across pods A, C and D in network 12)).
Claim 9-16 are substantially similar to claims 1-8 and 17, thus the same rationale applies.
Regarding Claim 17, Li teaches a method comprising:
in nodes of a computing network, monitoring network traffic associated with a plurality of container groups to identify multicast statistical information (Fig. 3, ¶0003, ¶0011 & ¶0062; the method further includes that the first node monitors and collects statistics about first quantity information and first time information, where the first quantity information is a quantity of data packets in the multicast service flow that are received in a preset period, and the first time information is a timestamp of each data packet in the multicast service flow that is received at a time point in the preset period, and sends first detection information to the control node, where the first detection information includes one or more of the first quantity information, the first time information, an ingress identifier of the first node, and the first detection identifier, and the first detection information is used by the control node to perform packet loss detection or delay detection on the multicast service flow),
wherein the multicast statistical information comprises identifiers for one or more container groups of the plurality of container groups registered via Internet Group Management Protocol (IGMP) packets or Multicast Listener Discovery (MLD) packets in association with each multicast group of a plurality of multicast groups (¶0074 & ¶0089; node in the multicast detection domain further sends detection information to a control node, where the detection information sent by an ingress of the node to the control node includes an ingress identifier, a first detection identifier, a quantity of data packets received in a preset period, and a timestamp of each data packet received in the preset period, and the detection information sent by an egress of the node to the control node includes an egress identifier, the first detection identifier, the quantity of data packets sent in the preset period, and a timestamp of each data packet sent in the preset period. ¶0108; Protocols used in the multicast detection domain include a multicast group management protocol and a multicast routing protocol. The used multicast group management protocol is the Internet Multicast Management Protocol (IGMP), which is a basic signaling protocol for IP multicast);
in the nodes, communicating the multicast statistical information to a management service in the management service, receiving the multicast statistical information from the nodes (Fig. 3 & ¶0086-¶0090; head node 304A & B is further configured to collect statistics about detection information of an incoming service flow, and upload the detection information to the control node 302);
in the management service, aggregating the multicast statistical information from the nodes (Fig. 3 & ¶0086-¶0090 & ¶0102; head node 304A, intermediate node 304B and tail node 304C, all uploads the detection information/statistics information on service flow to control node 302 which is the same as aggregating the information. It should be noted that the detection information collected by the head node, the intermediate node, and the tail node includes one or more of an ingress identifiers and an egress identifier of each node, a quantity and timestamps of data packets that are received and sent by each node, a first detection identifier, a multicast source address, a multicast group address, a multicast source port, a receive end port, and a multicast protocol number. The receive end 305 is configured to receive the data packet sent by the tail node 304C. It should be noted that the receive end 205 may also join a multicast group including the head node 304A, the intermediate node 304B, and the tail node 304C [aggregation]);
“and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information, wherein the summary indicates, for at least one multicast group of the plurality of multicast groups, the one or more container groups associated the at least one multicast group (see previous limitation for aggregation information of multicast statistical information).”
Li does not teach that the information collected is for “…plurality of container groups…” & “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information, wherein the summary indicates, for at least one multicast group of the plurality of multicast groups, the one or more container groups associated the at least one multicast group.”
As to “…plurality of container groups…” limitation, Thyamagundalu is analogous art because Thyamagundalu is directed to monitoring multicast traffic in a multi-pod network environment [plurality of container groups container]. See ¶0018 & Fig. 1.
Thyamagundalu also teaches “…plurality of container groups…” Fig. 1 & ¶0018-¶0019; BD1 (with member nodes in pods A, C and D) and BD2 (with member nodes in pods A, B and D). Merely as an example and not as a limitation, endpoints H1, H2 in pod A, endpoint H3 in pod C, and endpoint H4 in pod D may be members of BD1 that spans across pods A, C and D in network 12).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Thyamagundalu that includes multi-pod network into the system of Li that monitors ingress and egress packets for multicast groups in order to derive a global multicast group identical for the broadcast domain across the plurality of pods, and associating a local multicast group at the translator with the derived global multicast group (abstract).
Li in view of Thyamagundalu does not expressly teach “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information, wherein the summary indicates, for at least one multicast group of the plurality of multicast groups, the one or more container groups associated the at least one multicast group.”
Bresalu teaches “and in the management service and in response to a summary request, generating a summary for display based on the aggregated multicast statistical information, wherein the summary indicates, for at least one multicast group of the plurality of multicast groups, the one or more container groups associated the at least one multicast group” (Figs. 2-6; Fig. 2 request to start a multicast traffic monitoring. Figs. 3-6 illustrate proactive multicast summary based on the request).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Bresalu into the system of Li in view of Thyamagundalu in order to monitor traffic in a multicast network (abstract). Utilizing such teachings enable the system to initiate an alarm in response to detecting a specific status being less than a predetermined value (abstract).
Regarding Claim 18, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 17, Li further teaches wherein the plurality of nodes comprises a plurality of physical computers or a plurality of virtual machines executing on one or more physical computers (¶0080; physical device. ¶0092; physical computers).
Regarding Claim 19, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 17, Li further teaches wherein the multicast statistical information comprises quantities of ingress and egress multicast packets associated with the plurality of container groups on the nodes (Fig. 3 & ¶0086-¶0090 & ¶0102; quantities of packets of plurality of nodes. Thyamagundalu teaches pods in ¶0018-¶0019).
Regarding Claim 20, Li in view of Thyamagundalu and further in view of Bresalu teaches the method of claim 19, Li further teaches wherein the summary request indicates a multicast group of the plurality of multicast groups, and wherein the summary indicates a quantity of packets received by the multicast group with a multicast IP address associated with the multicast group (Fig. 3 & ¶0086-¶0090 & ¶0102; quantities of packets of plurality of nodes. ¶0089; IP address. ¶0012-¶0013; multicast source address and multicast group address).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHRAN ABU ROUMI whose telephone number is (469)295-9170. The examiner can normally be reached Monday-Thursday 6AM-5PM.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
MAHRAN ABU ROUMI
Primary Examiner
Art Unit 2455
/MAHRAN Y ABU ROUMI/Primary Examiner, Art Unit 2455