Detailed Action
Claims 1-20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
Figure 4 is objected to because of the typographical error “componentv” in step 404.
Specification
The specification is objected to because of the typographical error “statics” instead of “statistics” in [0022], [0032] and [0042].
Claim Objections
Claims 4 and 16 are objected to because of the typographical error “statics” instead of “statistics”.
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.
Claims 4-5, 8-12, 16-17 and 19 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.
Claims 5, 8-12, 17 and 19 recite the term “and/or” and it is not clear whether the features that following are required or not. For the purpose of examination, these claims are interpreted as reciting “one or more” of the features joined by “and/or”.
Claims 4 and 16 recite the term “the measured data flows” without antecedent basis. For the purpose of examination, these claims are interpreted as reciting “the measured data”.
Claims 9 and 19 recite the terms “can include a field for a connection state” therefore it is not clear whether this is required or not. For the purpose of examination, these claims are interpreted as reciting “
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-7, 10-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miriyala (US Pub. No. 2024/0223454) in view of Huang et al (US Pub. No. 2012/0047492).
Re Claim 1. Miriyala discloses a method of testing versions of a network components, the method comprising: obtaining a first flow table based on measured data, the first flow table having been generated using a first version of a network component (i.e. obtaining flow records indicative of packet flows among workloads deployed to a cluster of one or more computing devices configured with a network policy, wherein each flow record of the flow records indicates a corresponding packet flow was allowed or denied by the cluster) [Miriyala, para.0014]; generating, for respective entries in the first flow table, corresponding entries in a second flow table (i.e. determining whether a corresponding packet flow for a flow record of the flow records has a discrepancy with the updated network policy) [Miriyala, para.0014], the corresponding entries being identified by header information (i.e. The term “packet flow,” “traffic flow,” or simply “flow” refers to a set of packets originating from a particular source device or endpoint and sent to a particular destination device or endpoint. A single flow of packets may be identified by the 5-tuple: <source network address, destination network address, source port, destination port, protocol>, for example. This 5-tuple generally identifies a packet flow to which a received packet corresponds) [Miriyala, para.0067],
Mirayala does not explicitly disclose whereas Huang discloses: and the corresponding entries representing a response of a second version of the network component to simulated traffic comprising data flows having the header information of the corresponding entries; comparing the first flow table with the second flow table to generate comparison results (i.e. A replay tool 122 obtains the to-be-replayed traffic 112 from the storage 110 (with the modifications that the modification and comparison tool 116 may have made). It replays this to-be-replayed traffic for the target system 120 and thus to run the migrated application 108. Thus, it simulates the role that the users and other systems 105 played for the source system 100 For example, requests captured from the running of the application 106 in the production system are used (replayed) as requests to the migrated application 108. Responses from the migrated application 108 responding to the replayed requests are extracted and stored in correct sequence with the requests. The modification and comparison tool 116 compares these replay results 114 with the captured traffic 107. It takes into account modifications it made, e.g., IP address changes) [Huang, para.0026, 0030];
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Miriyala with Huang because it provides minimally intrusive tools for testing migrated servers and/or applications or the like are presented. The system and methodology of the present disclosure presents a tool that SAs might be more prone to approve and use on their systems, by relying as much as possible on existing capabilities of the source servers, and only requiring additional running of small scripts. The benefit is that the smaller and the more readable the additional software used is, the easier it is for SAs or an audit, security, or compliance team to validate that the software does not harm the production systems [Huang, para.0012].
Miriyala further discloses: and evaluating whether the second version of the network component can be deployed based on the comparison results (i.e. validation system 60 may validate the one or more updated policies with respect to the blocked set of flow records (1142) and move to step 1144. If validation system 60 determines the value of the counter is not equal to the number of flow records (NO branch of 1138), validation system 60 may output the flagged traffic and policy (1140) and subsequently output an indication of an error. If validation system 60 has validated both the allowed and blocked sets of flow records (YES branch of 1144), validation system 60 may consider the updated network policies as validated and output an indication of validation that causes network controller 24 to push the updated network policies to vRouters) [Miriyala, para.0144-0145].
Re Claim 2. Miriyala in view of Huang discloses the method of claim 1, wherein: the header information includes a pair of a source address and a destination address (i.e. The term “packet flow,” “traffic flow,” or simply “flow” refers to a set of packets originating from a particular source device or endpoint and sent to a particular destination device or endpoint. A single flow of packets may be identified by the 5-tuple: <source network address, destination network address, source port, destination port, protocol>, for example. This 5-tuple generally identifies a packet flow to which a received packet corresponds) [Miriyala, para.0067],
Huang further discloses: and the simulated traffic is [randomly] sampled from the measured data and is sampled based on a statistical profile of the measured data (i.e. The script 104 or the like may also include commands to compress a part of all of the collected data, whether to encrypt a part or all of the collected data, whether to edit the collected data (for example, remove privacy or sensitive information). Data compression helps in reducing the volume of data collected. Features such as data encryption and removing sensitive information help in preserving the security of the system whose data is being collected. For instance, data such as passwords being communicated may be extracted and substituted with tags. Note that if tagging is done, then later before replay the modification and comparison tool 116 replaces these tags with other passwords or the like to be used in the test system) [Huang, para.0022]
The same motivation to modify with Huang, as in claim 1, applies.
Huang, does not explicitly disclose that the traffic is randomly sampled, however it would have been obvious to a person having ordinary skill in the art that to modify Miriyala in view of Huang to use randomly sampled traffic because, besides compression, random sampling facilitates generating traffic without sensitive information, as taught by Huang, as opposed to detecting and omitting such data.
Re Claim 3. Miriyala in view of Huang discloses the method of claim 1, wherein comparing the first flow table with the second flow table includes that each of the comparison results is a comparison result of an entry of the respective entries in the first flow table with a corresponding entry in the second flow table (i.e. Validation system 60 flags inconsistencies by comparing whether a flow record of the golden traffic profile indicating flows between endpoints as being allowed (denied) would instead be denied (allowed) according to the rules of the updated network policies. For example, validation system 60 may flag an inconsistency in response to determining that a flow record of the traffic profile is marked as allowed but that applying the rules of the updated network policies would cause a flow between the endpoints of the flow record of the traffic profile to instead be denied) [Miriyala, para.0140].
Re Claim 4. Miriyala in view of Huang discloses the method of claim 1, Huang further discloses: further comprising: acquiring the measured data flows from a production environment (i.e. The script 104 is executed or run on a source system 100, and monitors the application 106 or the like on the source system 100 to capture traffic data) [Huang, para.0023];
The same motivation to modify with Huang, as in claim 1, applies.
Miriyala in view of Huang further discloses: obtaining an acquired flow table that includes the respective entries corresponding to the header information in the measured data identifying types of data flows; generating the respective entries of the first flow table using the simulated traffic for an entry, and generating first statistics and first metadata for the entry based on a response of the first version of the network component to the simulated traffic (i.e. The flow metadata is for packet flows among workloads of the distributed application. In some examples, the flow metadata may be session records of traffic statistics for packet flows processed by virtual routers 21 (e.g., for forwarding among workloads). Policy controller 54 may correlate the session records of traffic statistics for the packet flows into session records of traffic statistics for the workloads. The flow metadata indicates packet flows from workloads to other workloads. Policy controller 54 may store the flow metadata as flow records, which include a tag or label indicating whether the packet flow specified in the flow metadata was allowed or denied. Each of flow records 56 may include packet flow identifying information for identifying a packet flow originated within system 200 and data indicating whether the packet flow was allowed or denied by vRouters 21. As noted above, the data indicating whether the packet flow was allowed or denied may be a tag or label (e.g., “allowed”), an integer, a Boolean, or some other data. Packet flow identifying information may include overlay and/or underlay source or destination network addresses, source/destination ports, protocol information, other packet header field data, tags, application IDs, or other data for identifying a packet flow originated by one of the deployed workloads) [Miriyala, para.0135]; and generating the corresponding entries in the second flow table by generating second statics and second metadata for the corresponding entries based on the response of the second version of the network component to the simulated traffic (i.e. Validation system 60 may process the flow records of the traffic profile to determine whether the updated network policies would cause system 200 to allow or deny the traffic. Validation system 60 applies the updated network policies to the traffic profile and flags any inconsistencies. Validation system 60 flags inconsistencies by comparing whether a flow record of the golden traffic profile indicating flows between endpoints as being allowed (denied) would instead be denied (allowed) according to the rules of the updated network policies. For example, validation system 60 may flag an inconsistency in response to determining that a flow record of the traffic profile is marked as allowed but that applying the rules of the updated network policies would cause a flow between the endpoints of the flow record of the traffic profile to instead be denied) [Miriyala, para.0140].
Re Claim 5. Miriyala in view of Huang discloses the method of claim 1, wherein generating the corresponding entries in the second flow table further includes ensuring correctness of the corresponding entries using additional data collected from the network component (i.e. The captured response of the application running in the source system are compared with responses from the migrated application running on the target system to determine and/or ensure that the migrated application in the target system behaves the same or substantial the same way, e.g., correctly………………….. the state of the source system 100 at the end of the traffic capturing period and the state of the target system 120 at the end of the traffic replaying period are also compared. This is particularly useful if the source system contains many state updates that might not immediately be visible by other requests, e.g., if there are multiple databases and many write operations are made and the read requests made during the traffic capturing period might not fully reflect whether the writes work correctly) [Huang, para.0030-0031], wherein the additional data includes DNS cache data mapping symbolic names to IP addresses (i.e. a modification and comparison tool 116 may modify the captured traffic 107 on the secure storage 110 before replay. It may change IP addresses or DNS names in the traffic if the placement and wave plan indicates that the software components belonging to the current wave (such as application 106, when migrated into application 108) change their IP addresses and/or DNS names) [Huang, para.0024] and/or operations performed at open systems interconnection (OSI) layer seven (L7).
The same motivation to modify with Huang, as in claim 1, applies.
Re Claim 6. Miriyala in view of Huang discloses the method of claim 1, wherein the first flow table and the second flow table include entries for both allowed packets and denied packets (i.e. Validation system 60 may process the flow records of the traffic profile to determine whether the updated network policies would cause system 200 to allow or deny the traffic. Validation system 60 applies the updated network policies to the traffic profile and flags any inconsistencies. Validation system 60 flags inconsistencies by comparing whether a flow record of the golden traffic profile indicating flows between endpoints as being allowed (denied) would instead be denied (allowed) according to the rules of the updated network policies. For example, validation system 60 may flag an inconsistency in response to determining that a flow record of the traffic profile is marked as allowed but that applying the rules of the updated network policies would cause a flow between the endpoints of the flow record of the traffic profile to instead be denied) [Miriyala, para.0140].
Re Claim 7. Miriyala in view of Huang discloses the method of claim 1, wherein each entry in the first flow table and the second flow table includes fields for a source, a destination, whether data packets were allowed or denied, metadata, and statistics (i.e. The flow metadata is for packet flows among workloads of the distributed application. In some examples, the flow metadata may be session records of traffic statistics for packet flows processed by virtual routers 21 (e.g., for forwarding among workloads). Policy controller 54 may correlate the session records of traffic statistics for the packet flows into session records of traffic statistics for the workloads. ……………………..Each of flow records 56 may include packet flow identifying information for identifying a packet flow originated within system 200 and data indicating whether the packet flow was allowed or denied by vRouters 21. As noted above, the data indicating whether the packet flow was allowed or denied may be a tag or label (e.g., “allowed”), an integer, a Boolean, or some other data. Packet flow identifying information may include overlay and/or underlay source or destination network addresses, source/destination ports, protocol information, other packet header field data, tags, application IDs, or other data for identifying a packet flow originated by one of the deployed workloads) [Miriyala, para.0135].
Re Claim 10. Miriyala in view of Huang discloses the method of claim 1, wherein comparing the first flow table with the second flow table includes: comparing whether decisions made for a flow-table entry are consistent between the first flow table and the second flow table, comparing processing resources used for the decisions between the first flow table and the second flow table (i.e. Validation system 60 applies the updated network policies to the traffic profile and flags any inconsistencies. Validation system 60 flags inconsistencies by comparing whether a flow record of the golden traffic profile indicating flows between endpoints as being allowed (denied) would instead be denied (allowed) according to the rules of the updated network policies. For example, validation system 60 may flag an inconsistency in response to determining that a flow record of the traffic profile is marked as allowed but that applying the rules of the updated network policies would cause a flow between the endpoints of the flow record of the traffic profile to instead be denied) [Miriyala, para.0140], and/or comparing performance statistics between the first flow table and the second flow table (i.e. validation system 60 may increment a counter to track instances where flow records of the allowed set and the updated network policy agree (1114) and returns to step 1110. After all the policies of the one or more updated policies have been checked for discrepancies, validation system 60 may validate the one or more updated network policies as a whole with respect to the allowed set of flow records by determining whether the value of the counter is equal to the number of flow records in the allowed set) [Miriyala, para.0143].
Re Claim 11. Miriyala in view of Huang discloses the method of claim 1, evaluating whether the second version of the network component can be deployed includes: preventing the second version of the network component from being deployed when the comparison results indicate a degradation in performance statistics of the second version of the network component relative to the first version of the network component, and/or preventing the second version of the network component from being deployed when one or more inconsistencies between an expected characteristic of egress packets from the second version of the network component relative to an actual characteristic of egress packets from the second version of the network component (i.e. validation system 60 may validate the one or more updated network policies as a whole with respect to the blocked set of flow records by determining whether the value of the counter is equal to the number of flow records in the blocked set (1138). If validation system 60 determines the value of the counter is equal to the number of flow records in the blocked set (YES branch of 1138), validation system 60 may validate the one or more updated policies with respect to the blocked set of flow records (1142) and move to step 1144. If validation system 60 determines the value of the counter is not equal to the number of flow records (NO branch of 1138), validation system 60 may output the flagged traffic and policy (1140) and subsequently output an indication of an error. If validation system 60 has validated both the allowed and blocked sets of flow records (YES branch of 1144), validation system 60 may consider the updated network policies as validated and output an indication of validation that causes network controller 24 to push the updated network policies to vRouters……………………….. validation system 60 may conduct a similar analysis with egress rules 1204 to determine whether the network policy associated with egress rules 1204 would allow or block flow records corresponding to allowed flow records 1206 and blocked flow records 1208 respectively (e.g., based on destination address, destination port, protocol, etc.)) [Miriyala, para.0144-0145, 151. Note: updated policies are pushed only if validated, therefore they are not pushed when there is an error indication].
Re Claim 12. Miriyala in view of Huang discloses the method of claim 1, wherein the network component is one or more devices and/or circuitry executing instructions that perform a network function (i.e. validation system 60 may validate whether network components (nodes, virtual routers, or controllers) are properly configured to enforce the network policies associated with the traffic profile. Validation system 60 may identify configuration anomalies of the network components by continuously or periodically validating flow records with network policies [Miriyala, para.0147], the instructions being executed in a control plane and/or a data plane, and the instructions including policies, software, and/or firmware (i.e. configuration plane is implemented with horizontally scalable configuration nodes 230, the control plane is implemented with horizontally scalable control nodes 232, and the data plane is implemented with compute nodes ……………..Control nodes 232 may include component microservice control 320. Control 320 performs configuration distribution and route learning and distribution, as described above with respect to FIG. 2. Compute nodes are represented by servers 12. Each compute node includes a virtual router agent 316 and virtual router forwarding component (vRouter) 318. Either or both of virtual router agent 316 and vRouter 318 may be component microservices. In general, virtual router agent 316 performs control related functions. Virtual router agent 316 receives configuration data from control nodes 232 and converts the configuration data to forwarding information for vRouter 318. Virtual router agent 316 may also perform firewall rule processing, set up flows for vRouter 318) [Miriyala, para.0156, 0166-0167].
Re Claim 13-17. These claims recite features similar to those in claims 1-5 respectively, therefore it is rejected in a similar manner.
Re Claim 18. Miriyala in view of Huang discloses the apparatus of claim 13, wherein the first flow table and the second flow table include entries for both allowed packets and denied packets (i.e. Validation system 60 applies the updated network policies to the traffic profile and flags any inconsistencies. Validation system 60 flags inconsistencies by comparing whether a flow record of the golden traffic profile indicating flows between endpoints as being allowed (denied) would instead be denied (allowed) according to the rules of the updated network policies. For example, validation system 60 may flag an inconsistency in response to determining that a flow record of the traffic profile is marked as allowed but that applying the rules of the updated network policies would cause a flow between the endpoints of the flow record of the traffic profile to instead be denied) [Miriyala, para.0140]
Re Claim 20. This claim recites features similar to those in claim 1, therefore it is rejected in a similar manner.
Claims 8-9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Miriyala (US Pub. No. 2024/0223454) in view of Huang et al (US Pub. No. 2012/0047492) and further in view of Huang et al (US Pub. No. 2018/0115470), hereinafter Huang2.
Re Claim 8. Miriyala in view of Huang discloses the method of claim 1, Miriyala in view of Huang does not explicitly disclose whereas Huang2 discloses: wherein the first flow table and the second flow table include entries for dropped packets, blocked packets, and/or restricted packets (i.e. The actions that can be applied on a match include forwarding to specific ports on the switch, flooding the packet, changing its QoS levels, dropping the packet, encapsulating, encrypting, rate limiting) [Huang2, para.0059].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Miriyala in view of Huang with Huang2 because it allows for extending firewall rule conflict classification from a traditional environment to SDN flow rule conflicts by recognizing and classifying conflicts stemming from cross-layer conflicts, and providing strategies for unassisted resolution of these conflicts [Huang2, Abstract, see also 0072].
Re Claim 9. Miriyala in view of Huang discloses the method of claim 1, Miriyala in view of Huang does not explicitly disclose whereas Huang2 discloses: wherein: when the network component operates at open systems interconnection (OSI) layer two (L2), the header information includes a source address and a destination address that are media access control (MAC) addresses, when the network component operates at OSI layer three (L3), the header information includes that the source address and the destination address are internet protocol (IP) addresses, and/or when the network component operates at OSI layer four (L4), the header information includes that the source address and destination address are MAC addresses and/or IP addresses, (i.e. Flow rules where not all OSI addresses layers have match conditions could result in cases where, a) only layer-3 header is used as a condition (rule 1-7); b) only layer-2 header is used as a condition for decision (rule 8); and c) only layer-4 header is used as a condition (rule 9). Address space overlaps between rules are classified as imbrication. Imbrication conflicts are more complex than the other conflict classifications, since they are temporal in nature. For example, the mapping between a layer-2 MAC address and layer-3 IP addresses might result in a conflict between two flow rules at time t.sub.1 in the layer-3 address space) [Huang2, para.0084, and para.0056 TABLE 1],
The same motivation to modify with Huang2, as in claim 8, applies.
Miriyali further discloses: and the first flow table and the second flow table can include a field for a connection state (i.e. A network policy acts on connections rather than individual packets. For example, if traffic from pod A to pod B is allowed by the configured policy, then the return packets for that connection from pod B to pod A are also allowed, even if the policy in place does not allow pod B to initiate a connection to pod A) [Miriyali, para.0039].
Re Claim 19. This claim recites features similar to those in claim 9, therefore it is rejected in a similar manner.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights