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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 3/27/2026 have been fully considered, but cannot be held as persuasive. After summarizing the status of the application, pending claims, and rejections on pages 8 – 9, on page 10 Applicant argues that Guichard, via their “network service header”, does not show the claim language related to “which security services have been applied to the data flow”. In response, the Examiner notes that cited [13] recites that network nodes apply service functions to traffic that passes through them, and that these packets are “encapsulated in a service header that includes information defining a variable set of context headers stacked into an association of metadata that is relevant to one or more service functions”; as cited [14] explains, the functions include those of a “firewall” - an exemplary security service. As cited [18] continues to explain, the context within this header contain “an association of metadata that is relevant to one or more of the service functions within the service chain”. Thus the metadata carried in the header is data regarding the service functions applied to the connected traffic, and these service functions include security service functions such as those provided by a firewall. This metadata / service header information is described in Guichard as containing the “forwarding state at the end of a service chain” (see [15]) and thus represents all the various services, such as the firewall security services, that have been applied to the traffic.
Continuing on page 10, Applicant argues that the claim language “denotes that the information reflects performed security processing, not merely routing or service chaining metadata” and that the citations to Guichard do “not to attest to completed security services” and does not “encode that a firewall, IDS, or other security function has already been applied to the traffic, nor does it provide information reflecting the outcome of such processing”. In response, the Examiner notes that Applicant’s arguments rely on features not positively recited in the claims, and thus cannot be held as persuasive.
Concluding on page 10, Applicant argues that Guichard “does not encode representations of upstream-applied security services”. In response, the Examiner notes that Applicant’s arguments continue to rely on features not positively recited in the claims (e.g., “encode representations of upstream-applied security services” is not claim language). Thus these arguments cannot be held as persuasive. In addition, such “encoding” is anticipated by the ”contexts” containing the metadata “relevant to one or more of the service functions within the service chain”, recited in [18] of Guichard and discussed in further detail in the above noted citations and the response to the preceding arguments.
Moving to page 11, Applicant notes that claim 1 recites “generating out-of-band information providing additional details of the one or more security services” and argues that this is not supported by the pending rejection, arguing that “There is no disclosure in Oswal that the out-of-band information comprises descriptions of applied firewall operations, intrusion detection outcomes, policy enforcement steps, or other security-service-specific details. Rather, Oswal concerns performance monitoring and traffic analysis”. In response, the Examiner notes that Oswal recites in cited [33] use of “determined meta data . . . “communicated . . . out of band”, which [32] describes as being “for a security service”. [43] elaborates on this process which is described as to “collect security information . . . for reporting”, and as [76] notes, the process is to “collect and send flow data with security context”. Thus, contrary to Applicant’s assertion, Oswal fully supports the cited claim language.
Applicant’s arguments continue on page 11 through page 12, and assert that the claimed ledger “denotes a record-keeping structure for storing information in an organized and retrievable manner” and that “The specification describes the ledger as a repository for recording security-service-related information in association with the data flow.” In response, the Examiner notes that unclaimed features described in the specification, such as an unclaimed example of how a ledger may behave, are not incorporated into the claims.
Applicant continues on page 12 to argue that “There is no disclosure that the cloud platform functions as a ledger storing records of applied security services in association with particular data flows.” In response, the Examiner notes that the above features are not positively recited in the pending claims, and thus arguments directed to such features cannot be held as persuasive. If Applicant desires a more specific definition of what may constitute a “ledger”, then Applicant is encouraged to positively recite the desired definition in their pending claims. Absent such a recitation, the broadest reasonable interpretation of Applicant’s claim language, which the Examiner is required to use, does not require such unclaimed details.
Next on page 12, while continuing to address claim 1, Applicant argues that Venkata “does not disclose a boundary node receiving analyzed out-of-band security-service details and using those results to determine whether to permit traffic into a workload.” In response, the Examiner notes that Venkata was not relied upon for addressing all of this claim language; these claim features were addressed by a combination of Guichard in view of Venkata and Oswal, and thus the arguments directed to Venkata alone cannot be held as persuasive.
Moving to page 13, Applicant argues that “The Office Action does not identify any teaching or suggesting showing that the boundary node accesses or relies upon results of out-of-band analysis when deciding whether to permit traffic into a workload. The combination therefore requires an unsupported assumption. . .”. In response, the Examiner notes that these claim features are addressed by the combination of Guichard in view of Venkata and Oswal; specifically the transmission of a data flow to a boundary node language is anticipated by Venkata, as is said boundary node making a determination. The permission decision is anticipated by Guichard, and the out-of-bound analysis is anticipated by Oswal. The pending 103 rejections provide details regarding which particular areas of each reference are relevant, as well as the analysis and motivation required to perform a valid 35 USC 103-based rejection.
Applicant’s remaining arguments rely on the rationale addressed above, and thus are similarly unpersuasive.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 4, 6, 12, 14 – 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Guichard (US-20140362857-A1) in view of Venkata (US-20200186465-A1) and Oswal (US-20220141184-A1).
Regarding claim 1, Guichard shows a method for communicating security service context within a network, the method comprising: processing a data flow at one or more intermediary nodes of a network ([13], see “apply one or more service functions to traffic that passes through the respective network node”), the processing of the data flow comprising applying one or more security services ([2], see “network services . . . such as security” and [14] discussing “firewall” services) to the data flow, and the data flow comprising data packets ([[13], see “A network node receives packets. . .”); generating in-band information representing the one or more security services, and combining the in-band information with the data packets ([20] discussing data headers “added to a packet”) of the data flow to traverse the network in-band with the data flow ([20] discussing use of an appended service header which “determines which packets require servicing, and correspondingly which service path to follow to apply the appropriate service” and [21] discussing a “data plane encapsulation that utilizes the network overlay topology to deliver packets to the requisite service”);
determining whether the data flow is permitted to pass into the workload based on one or more results of an analysis of the information ([31] discussing where “Data is classified, and if determined to require servicing, a service header is imposed” which is removed at “the end of a service chain; as [35,39-40] discusses, the added service header is processed to determine which service functions are applied to packets during traversal and how they are routed, and includes use of control mechanisms such as hop-limits). Guichard does not show: transmitting the data flow to a boundary node that is in front of a workload; and determining at the boundary node. Venkata shows transmitting the data flow to a boundary node that is in front of a workload and making a determination at the boundary node ([17-18,31-32,43-44] discussing “nodes at a boundary” of logical node groupings which process packets to determine which workloads to which packets should be routed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the packet routing mechanisms of Guichard with the in-band, boundary-based packet determinations of Venkata in order to enable collection of additional network statistics to facilitate improved load balancing among workloads (Venkata, [31-33,62]). The above combination does not show: generating out-of-band information providing additional details of the one or more security services, and sending the out-of-band information to a ledger; and performing an analysis of the out-of-band information.
Oswal shows: generating out-of-band information providing additional details of the one or more security services, and sending the out-of-band information to a ledger ([32-33,43,76] discussing collecting flow data and transmitting it to the cloud for analysis, a type of out-of-band communication as noted in [33]); and performing an analysis of the out-of-band information ([43,47] discussing ingestion and processing of the reported out-out-band information). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the in-band network traffic analysis and processing with additional the out-of-band processing of Oswal in order to facilitate additional traffic processing which avoiding performance problems when analyzing large amounts of traffic (Oswal, [33,36]). Regarding claim 2, the above combination further shows wherein the in-band information is generated at the one or more intermediary nodes (Venkata, [18], Fig. 7 steps 705, 730, 740) by a data processing unit (DPU) (Venkata, [92]), a Berkley packet filter (BPF), and/or an extended BPF (eBPF). Regarding claim 4, the above combination further shows wherein processing the data flow further comprises: applying, at a first node of the one or more intermediary nodes, a first security (Guichard, [14], discussing a firewall service) service of the one or more security services (Guichard, [13,19-21,31]); and applying, at a second node of the one or more intermediary nodes, a second security service (Guichard, [14], discussing an IDS service) of the one or more security services (Guichard, [13,19-21,31]).
Regarding claim 6, the above combination further shows wherein generating the out-of-band information further comprises: signaling, from the first node to the ledger, first additional details of the first security service (Venkata, [31,44] and Oswal, [32-33,42-43]) the first additional details comprising a list of security policies, deep packet inspections (Guichard, [14] discussing a DPI service), signature-based detections, packet filtering, behavioral-graph analyses, firewall functions, intrusion prevention function (Guichard, [14] discussing an intrusion detection service), malware or virus filtering, or source identification/authentication, and the first additional details further comprising a program trace, a log file, telemetry data of program instructions (Venkata, [18,20]) executing the first security service (Guichard, [14], e.g., a firewall service); and
signaling, from the second node to the ledger, second additional details of the second security service (Guichard, [14-18] where the signaling process is repeated to track the application of the required service chain).
Regarding claim 12, the above combination further shows wherein generating the out-of-band information comprises communicating the out-of-band information to the ledger via an out-of-band communication channel (Oswal, [32-33,43,76]), the out-of-band communication channel comprising an overlay network that uses Generic Routing Encapsulation (GRE), Generic UDP Encapsulation (GUE), Generic Network Virtualization Encapsulation (Geneve), or a metadata exchange mechanism (Oswal, [33,42-43], Figs. 5-6).
Regarding claim 14, Guichard shows a computing apparatus comprising: a processor (Fig. 7 item 420); and a memory storing instructions (Fig. 7 item 430) that, when executed by the processor, configure the apparatus to: process a data flow at one or more intermediary nodes of a network ([13], see “apply one or more service functions to traffic that passes through the respective network node”), the processing of the data flow comprising applying one or more security services ([2], see “network services . . . such as security” and [14] discussing “firewall” services) to the data flow, and the data flow comprising data packets ([[13], see “A network node receives packets. . .”); generate in-band information representing the one or more security services, and combining the in-band information with the data packets ([20] discussing data headers “added to a packet”) of the data flow to traverse the network in-band with the data flow ([20] discussing use of an appended service header which “determines which packets require servicing, and correspondingly which service path to follow to apply the appropriate service” and [21] discussing a “data plane encapsulation that utilizes the network overlay topology to deliver packets to the requisite service”);
determine whether the data flow is permitted to pass into the workload based on one or more results of an analysis of the information ([31] discussing where “Data is classified, and if determined to require servicing, a service header is imposed” which is removed at “the end of a service chain; as [35,39-40] discusses, the added service header is processed to determine which service functions are applied to packets during traversal and how they are routed, and includes use of control mechanisms such as hop-limits). Guichard does not show: transmit the data flow to a boundary node that is in front of a workload; and determine at the boundary node. Venkata shows transmitting the data flow to a boundary node that is in front of a workload and making a determination at the boundary node ([17-18,31-32,43-44] discussing “nodes at a boundary” of logical node groupings which process packets to determine which workloads to which packets should be routed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the packet routing mechanisms of Guichard with the boundary-based packet determinations of Venkata in order to enable collection of additional network statistics to facilitate improved load balancing among workloads (Venkata, [31-33,62]). The above combination does not show: generate out-of-band information providing additional details of the one or more security services, and sending the out-of-band information to a ledger; and perform an analysis of the out-of-band information.
Oswal shows: generating out-of-band information providing additional details of the one or more security services, and sending the out-of-band information to a ledger ([32-33,43,76] discussing collecting flow data and transmitting it to the cloud for analysis, a type of out-of-band communication as noted in [33]); and performing an analysis of the out-of-band information ([43,47] discussing ingestion and processing of the reported out-out-band information). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the in-band network traffic analysis and processing with additional the out-of-band processing of Oswal in order to facilitate additional traffic processing which avoiding performance problems when analyzing large amounts of traffic (Oswal, [33,36]).
Regarding claim 15, the limitations of said claim are addressed in the analysis of claim 2.
Regarding claim 20, the limitations of said claim are addressed in the analysis of claim 1.
Claims 3, 5, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Guichard in view of Venkata and Oswal, as applied to claim 1 above, further in view of Kelly (US-20200344265-A1).
Regarding claim 3, the above combination shows wherein the out-of-band information includes samples of the data packets from the data flow, and where the samples are analyzed (Oswal, [31-33,42]). The above combination does not show to: validate attestations of the in-band information, and/or ascertain an efficacy, a health, or a compromise of the one or more security services that is applied to the data flow Kelly shows to: validate attestations of the in-band information ([18]), and/or ascertain an efficacy, a health ([18]), or a compromise of the one or more security services that is applied to the data flow.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the attestation validation of Kelly in order to confirm the health of the various hosts interacting on the network, and thus ensure that the intended security features are being properly enforced (Kelly, [15,18]).
Regarding claim 5, the above combination shows wherein generating the in-band information further comprises: adding, at the first node, a first attestation to one or more headers of the data packets of the data flow, the first attestation (Venkata, [17-18]) indicating that the first security service was applied to the data flow (Guichard, [14-18], discussing multiple security services including firewall services); and adding, at the second node, a second attestation to the one or more headers of the data packets of the data flow (Venkata, [17-18, 31]), the second attestation indicating that the second security service was applied to the data flow (Guichard, [14-18], discussing multiple security services including IDS services). The above combination does not show where the attestations are cryptographical secure signatures. Kelly shows where the attestations are cryptographical secure signatures ([22,24]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the attestation validation of Kelly, including the verification and validation enhancements enabled via cryptographical security operations, in order to confirm the health of the various hosts interacting on the network, and thus ensure that the intended security features are being properly enforced (Kelly, [15,18]).
Regarding claim 16, the limitations of said claim are addressed in the analysis of claim 3.
Regarding claim 17, the above combination shows wherein, when executed by the processor, the instructions further configure the apparatus to: apply, at a first node of the one or more intermediary nodes, a first security (Guichard, [14], discussing a firewall service) service of the one or more security services (Guichard, [13,19-21,31]); and apply, at a second node of the one or more intermediary nodes, a second security service (Guichard, [14], discussing an IDS service) of the one or more security services (Guichard, [13,19-21,31]). add, at the first node, a first attestation to one or more headers of the data packets of the data flow, the first attestation (Venkata, [17-18]) indicating that the first security service was applied to the data flow (Guichard, [14-18], discussing multiple security services including firewall services); and add, at the second node, a second attestation to the one or more headers of the data packets of the data flow (Venkata, [17-18, 31]), the second attestation indicating that the second security service was applied to the data flow (Guichard, [14-18], discussing multiple security services including IDS services). signal, from the first node to the ledger, first additional details of the first security service (Venkata, [31,44] and Oswal, [32-33,42-43]) the first additional details comprising a list of security policies, deep packet inspections (Guichard, [14] discussing a DPI service), signature-based detections, packet filtering, behavioral-graph analyses, firewall functions, intrusion prevention function (Guichard, [14] discussing an intrusion detection service), malware or virus filtering, or source identification/authentication, and the first additional details further comprising a program trace, a log file, telemetry data of program instructions (Venkata, [18,20]) executing the first security service (Guichard, [14], e.g., a firewall service); and
signal, from the second node to the ledger, second additional details of the second security service (Guichard, [14-18] where the signaling process is repeated to track the application of the required service chain). The above combination does not show where the attestations are cryptographical secure signatures. Kelly shows where the attestations are cryptographical secure signatures ([22,24]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the attestation validation of Kelly, including the verification and validation enhancements enabled via cryptographical security operations, in order to confirm the health of the various hosts interacting on the network, and thus ensure that the intended security features are being properly enforced (Kelly, [15,18]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Guichard in view of Venkata and Oswal, as applied to claim 1 above, further in view of Clad (US-20200322266-A1).
Regarding claim 11, the above combination shows wherein generating the in-band information further comprises adding extension headers of the data packets (Guichard, [18-20,39-40] discussing optional service headers added to packets). The above combination does not show: adding attestations to optional Internet Protocol version 6 (IPv6) headers. Clad shows adding attestations (Abstract, Fig. 7) to optional Internet Protocol version 6 (IPv6) headers (Fig. 8, [14,16]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the use of optional IPv6 headers as suggested by Clad in order to leverage the extensibility inherent in a standardized implementation of IPv6, facilitating a reliable mechanism for relaying the attestation mechanism of the above combination.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Guichard in view of Venkata and Oswal, as applied to claim 1 above, further in view of Jain (US-20140376367-A1).
Regarding claim 13, the above combination shows wherein the boundary node (Venkata, [31-32]) is a last policy enforcement point (PEP) before the workload (Venkata, [35]); updating via the ledger (Venkata, [44,51] and Oswal, [32-33]), and where the PEP is last before the workload (Venkata, [31-32, 35] showing, e.g., a leaf node PEP prior to the workload). The above combination does not show a PEP collocated with a firewall. Jain shows a PEP collocated with a firewall ([1]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the PEP/firewall implementation in order to leverage common, industry standard hardware (such as a firewall) to support the desired policy enforcement, enabling reuse of existing assets and thus lowering implementation costs.
Claim Objections - Allowable Subject Matter
Claims 7 – 10 and 18 – 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 7 and 18 (along with claims 8 – 10, and 19, via their respective independent claim) recite particular verification operations utilizing the attestations discussed above in the rejections of, e.g., claims 1 and 14. The prior art anticipates where use of the in-band information comprises attestations identifying the one or more security services that are applied to the data flow (Venkata, [17-18,20-31], Guichard, [14-18], and Oswal, [41-43]; further discussion is provided in the rejections presented above). However, the prior art fails to teach, suggest, or otherwise anticipate the additional details regarding the attestation based security services recited in claims 17 and 18, which includes both verification of the in-band and out-of-band information, along with the particular PEP-based enforcement details utilization both of said in-band and out-of-band information in the manner recited in claims 7 and 18.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Prosecution Insights