DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. This communication is in response to amendments filed on 02/24/2026.
Claims 1 and 11 have been amended. Claims 1-20 remain pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Specifically, for the following reasons:
2. Applicant’s arguments in response to the previously raised rejection of claims 1-10 under 35 U.S.C. 112(b) for insufficient description of a particular structure or algorithm corresponding to the claimed “configuration subsystem to”, “a monitoring subsystem to” and “an operator-interface subsystem to”, limitations invoking 35 U.S.C. 112(f), have been considered, however after careful consideration it is maintained that these limitations should be interpreted under 35 U.S.C. § 112(f) for the reasons set forth below.
Under current Federal Circuit precedent and USPTO guidance (see, e.g., Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015); MPEP § 2181), a claim limitation is interpreted under § 112(f) when:
The claim uses a generic, non-structural term (such as “means,” “module,” “unit,” or similar placeholders) in association with functional language.
The claim does not recite sufficient structure for performing the recited function.
The term “subsystem,” as used in the present claims, is not recognized in the art as denoting a specific structure. Rather, it is analogous to other generic placeholders such as “module” or “component,” which have been found to invoke § 112(f) when coupled with functional language. See Williamson, 792 F.3d at 1350.
The claims recite, for example, “a configuration subsystem to generate the plurality of communication flows based on a planned configuration,” “a monitoring subsystem to monitor information … to identify a change,” and “an operator-interface subsystem to generate an alert … and to receive a confirmation….” These limitations recite functions to be performed by the generic placeholder terms, but do not provide any corresponding structure for performing those functions and there is no indication in the claims as to the physical or structural nature of these “subsystems.”
Applicant argues that the specification and drawings provide support for the identified elements. However, as explained in the prior Office Action and consistent with Aristocrat Techs. v. Int’l Game Tech., 521 F.3d 1328 (Fed. Cir. 2008), when a claim is interpreted under § 112(f), the specification must disclose corresponding structure (or, for software, a specific algorithm) for performing the entirety of the claimed function. Merely identifying a “subsystem” in a block diagram or stating that it performs the claimed function is insufficient. The specification must describe the structure or acts that perform the function, and must clearly link or associate that structure to the function.
In this case, as previously noted, paragraphs [0012] and [0039]-[0041] of the specification reference the subsystems and repeat the claimed functions, but do not set forth any particular structure, nor do they describe a specific algorithm for performing the recited functions. The references to a “monitoring subsystem,” “configuration subsystem,” and “operator-interface subsystem” are generic and do not provide the necessary structural detail. There is no disclosure of the internal components, circuitry, or software routines that would enable one of ordinary skill in the art to understand how these subsystems perform their respective functions.
Applicant further contends that the Office has not explained the significance of the § 112(f) interpretation or identified the level of skill in the art. The Office notes that the application of § 112(f) is based on the claim language and the disclosure as understood by one of ordinary skill in the art. The presumption that claim terms are given their plain and ordinary meaning may be overcome when the claim term is a generic placeholder and is recited functionally without corresponding structure. The Office has applied the standard articulated in Williamson and MPEP § 2181, which does not require the explicit use of the word “means” to invoke § 112(f). Rather, the focus is on whether the term is used as a substitute for “means” and whether the claim recites sufficient structure. As the Federal Circuit has noted, if the term is not understood by those skilled in the art to connote structure, or if it is used as a black box for performing the recited function, § 112(f) applies.
Applicant cites Zeroclick, LLC v. Apple Inc., 891 F.3d 1003 (Fed. Cir. 2018), to argue that the terms have a sufficiently definite meaning. However, in Zeroclick, the court found that the claim terms “program” and “user interface code” were understood by those skilled in the art to connote structure. In contrast, here, Applicant has not provided evidence or argument that “subsystem” is recognized in the art as a specific structure, nor has the specification provided any structural detail.
For the reasons above, the Office maintains that the limitations reciting “a configuration subsystem to:”, “a monitoring subsystem to”, and “an operator-interface subsystem to” are properly interpreted under 35 U.S.C. § 112(f). The specification does not provide sufficient structure or algorithm for performing the entirety of the claimed functions, and the claims therefore remain indefinite under 35 U.S.C. § 112(b).
Applicant is advised to specify in the claim language that these elements are software stored on a memory and executed by a processor of the SDN controller to overcome the rejection, if this is in fact what is intended.
The rejection is currently maintained.
3. Claims 1 and 11 have been amended to recite “the confirmation from the operator of the change” at the end of the claims. There is improper antecedent basis for this limitation in the claims. Specifically, the claims only previously disclose a confirmation approving a change, which can be distinct from a confirmation of the change itself.
For purposes of examination, these recitations at the end of claims 1 and 11 are interpreted as referring to “the confirmation from the operator approving the change”.
Claims 2-10 and 12-20 are rejected in view of their respective dependencies from claims 1 and 11.
Response to Arguments
4. Applicant’s arguments asserting that the Mulka and Evans references fail to teach the amended limitations of independent claims 1 and 11 have been considered but are moot because the new ground of rejection relies on the Kirner reference, previously relied upon for teaching claims 6 and 16, for teaching the matter specifically challenged in the argument.
Specifically, Applicant’s arguments are directed to detecting a change and confirming the change with an operator prior to implementation. Although the newly applied Kirner reference explicitly teaches notifying an administrator of an alert and receiving administrator’s approval before implementing a change, unambiguously within the scope of the claim language, in response to Applicant’s remarks regarding Mulka and Evans being directed an automated network, it is noted that Mulka expressly recites a network architecture that allows network administrators to manage network services and allowing network administrators to dynamically adjust network-wide traffic flow to meet changing needs. Similarly, Evans teaches providing a graphical user interface (GUI) that provides a network administrator with access to control or observe operation of an internal network domain and, in some embodiments, inputting policies via the network management device that may be communicated to the control devices.
It is submitted that these teachings make evident administrator involvement in all of the applied prior art, and provide support for the combination with Kirner for notifying and receiving administrator approval for a change, as similarly recited in the amended claim language.
The rejection is therefore maintained.
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries 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.
5. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mulka et al. (US 2018/0191679) in view of Evans et al. (US 2019/0036816) and in further view of Kirner et al. (US 2015/0128211).
Regarding claim 1, Mulka teaches a system to monitor and configure a software-defined network (SDN), comprising:
a communication interface (OpenFlow™ is a vendor-neutral standard communications interface defined between the control and forwarding layers of an SDN architecture, [0013]; The I/O interface 1022 may include a network interface that may communicate with networks, such as the Internet, an intranet, a cellular telephone network, a wide area network (WAN), a local area network (LAN), a metropolitan area network (MAN), or other networks, [0054]) to:
communicate a plurality of communication flows to a plurality of network devices in the SDN (The SDN controller may maintain a table of the flow rules that are distributed to the respective NDs, [0013]; instructions can be communicated in the form of rules (also referred to herein as “flow rules”) that are computed, or otherwise determined, by the SDN controller that are downloaded (or otherwise communicated) to the NDs for execution, [0015]; the SDN controller 102 may employ one or more suitable protocols (e.g., the OpenFlow™ protocol, the network configuration protocol (NETCONF), and/or the like) for communicating with other devices of the SDN control system 101, such as the NDs 104, [0025]; distributing the one or more data flow rules to network devices (block 306), [0034); and
receive information related to traffic in the SDN between a plurality of hosts (if malicious data is detected in the first data flow path by the firewall, the firewall may generate and send to the SDN controller (and/or an SDN application associated therewith), an alert message indicating the malicious activity and including alert data indicative of the potentially malicious data, [0023]; a firewall network security system 108 may send alert messages to an SDN application 103 that indicate malicious activity occurring on a data flow path 110 of the SDN control system 101, [0029]; receiving an indication of malicious activity associated with the data flow path (block 402) can include the SDN controller 102 and/or an SDN application 103 receiving an indication of malicious activity associated with a data flow path 110, [0039]);
a configuration subsystem to generate the plurality of communication flows based on a planned configuration (In such a routing configuration, the first host device may be referred to as the “source host device” for the data flow, and the second host device may be referred to as a “destination host device” for the data flow. The SDN controller may generate a corresponding flow rule (or flow rules) for each ND in the data flow path, [0016]; the SDN controller 102 can include programs or other logic for generating flow rules 124, generating flow rules tables 126, generating mappings of flow IDs to flow rules tables 128, [0025]; Method 300 can generally include determining a data flow path (block 302), generating one or more data flow rules corresponding to the data flow path (block 304), [0034]; generating one or more data flow rules corresponding to the data flow path (block 304) can include the SDN controller 102 generating a corresponding flow rule (or flow rules) 124 for each ND 104 in the data flow path 110, [0036]);
a monitoring subsystem to monitor information related to traffic in the SDN (An SDN application 103 may include, for example, a program for network virtualization, network monitoring, [0026]); and
an operator-interface subsystem to generate an alert regarding the change (a firewall network security system 108 may send alert messages to an SDN application 103 that indicate malicious activity occurring on a data flow path 110 of the SDN control system 101. As further described herein, such alert messages can be processed by the SDN application 103, [0029]; if malicious data is detected in the first data flow path 110a by a network security system 108, the network security system 108 may generate and send an alert message to an SDN application 103, [0039]);
wherein the configuration subsystem is further configured to implement an update to the planned configuration based on the change (the SDN controller may generate a flow rules table that includes the flow rules for the second flow path, and may download the updated flow rules to the respective NDs to configure them to provide the updated data flow path, [0018]; distributing the updated data flow rule to the source network device (block 408), [0038]).
However, Mulka does not explicitly disclose that the information related to traffic in the SDN between the plurality of hosts is received from the plurality of network devices, or the monitoring subsystem monitoring information from the plurality of network devices to identify a change to at least one aspect of the planned configuration.
Evans teaches a communication interface to:
receive information from a plurality of network devices related to traffic in a SDN between a plurality of hosts (one or more of the edge network devices 410 may communicate the determined performance metrics with one or more components of the system 400. For example, the edge network devices 410 may communicate the performance metrics to the control device 420, [0081] At block 715, the processing logic may receive monitor data via the control plane from at least one device of the set of devices in the SDN, the monitor data being based on the at least one device of the set of devices in the SDN monitoring of the set of characteristics substantially in real-time, [0108]); and
a monitoring subsystem to monitor information from the plurality of network devices related to traffic in the SDN to identify a change to at least one aspect of a planned configuration (The control device 120 may periodically analyze the monitor data for irregularities and/or anomalies. For example, the control device 120 may use anomaly detection of applications at each site in the network for enforcing security related use-cases or to enforce improved planning, [0033]; At block 725, the processing logic may determine a change for at least one device of the set of devices in the SDN based on the data model. In at least some embodiments, the change for at least one device of the set of devices in the SDN includes a change to at least one data route path, [0110]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for a controller to receive traffic flow data directly from network devices in the system/method of Mulka as suggested by Evans to maintain functionality absent of a firewall security device. One would be motivated to combine these teachings in order for a SDN controller to more thoroughly monitor all relevant SDN traffic characteristics and parameters.
However, Mulka-Evans do not explicitly disclose the operator-interface subsystem receiving confirmation from an operator approving the change, or the configuration subsystem implementing the update based on the confirmation from the operator of the change.
Kirner teaches an operator-interface subsystem to generate an alert regarding a change (The ACR creation interface 960 may notify the administrator about alerts obtained by the alert processing module 950, [0214]) and to receive a confirmation from an operator approving the change (The ACR creation interface 960 may receive the administrator's approval, modification, or denial of the auto-generated access control rule, [0214]);
wherein a configuration subsystem is further configured to implement an update to a planned configuration based on the change and the confirmation from the operator of the change (The flow processing module 940 adds the (possibly modified) auto-generated access control rule to the set of access control rules 335 in response to receiving approval or modification from an administrator, [0214]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to notify an administrator of alerts in the system/method of Mulka-Evans as suggested by Kirner in order to receive administrator approval for any network changes. One would be motivated to combine these teachings to verify that any actions to change the configuration of network traffic are appropriate and desirable before they are implemented.
Regarding claim 2, Mulka teaches the system of claim 1, wherein the change to at least one aspect of the planned configuration comprises a change to an identifier of a device in communication with the SDN (the firewall may generate a message indicating malicious activity associated with the flow ID. The SDN controller can identify the corresponding data flow path (and associated flow rules table and/or flow rules) using the flow ID, [0017]).
Regarding claim 3, Mulka teaches the system of claim 2, wherein the identifier comprises an Internet protocol (IP) address (the flow ID for the first flow path may include a MAC address for the first host device (e.g., fa:16:3e:01:61:e8), a MAC address for the second host device (e.g., fa:16:3e:01:54:a3), an IP address for the first host device (e.g., 10.0.0.10), and an IP address for the second host device (e.g., 10.0.0.20), [0017]).
Regarding claim 4, Mulka teaches the system of claim 2, wherein the identifier comprises a media access control (MAC) address (the flow ID for the first flow path may include a MAC address for the first host device (e.g., fa:16:3e:01:61:e8), a MAC address for the second host device (e.g., fa:16:3e:01:54:a3), an IP address for the first host device (e.g., 10.0.0.10), and an IP address for the second host device (e.g., 10.0.0.20), [0017]).
Regarding claim 5, Mulka teaches the system of claim 1, wherein the configuration subsystem is further configured to update at least one of the plurality of communication flows based on the change (if the SDN controller determines that the data flow path from the first host device to the second host device should include ND3 as opposed to ND4 (e.g., if ND3 is determined to be unreliable or inoperable), the SDN controller may generate an updated set of flow rules for a second data flow path that is similar to the above described flow path, but that provides for routing of the data through ND3, [0018]; generating one or more updated data flow rules for the source network device to inhibit flow of data associated with malicious activity (block 406), [0038]).
Regarding claim 6, Mulka-Evans do not explicitly disclose the system of claim 1, wherein the operator-interface subsystem is further configured to receive approval of the update prior to implementation of the update.
Kirner teaches wherein an operator-interface subsystem is further configured to receive approval of an update prior to implementation of the update (the ACR creation interface 960 presents an administrator with an access control rule automatically generated by the flow processing module 940. The ACR creation interface 960 may receive the administrator's approval, modification, or denial of the auto-generated access control rule. The flow processing module 940 adds the (possibly modified) auto-generated access control rule to the set of access control rules 335 in response to receiving approval or modification from an administrator, [0214]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to present an administrator with an auto-generated rule change in the system/method of Mulka-Evans as suggested by Kirner in order to ensure administrator approval before applying system modifications. One would be motivated to combine these teachings to verify that any changes to a configuration are desirable.
Regarding claim 7, Mulka teaches the system of claim 1, wherein the configuration subsystem is further configured to update a setting of a host based on the change (if the SDN controller determines that the first host device is sending malicious data to the second host device, then the SDN controller can generate a “blocking” flow rule to cause ND1 (the source ND) to block (or drop) data from the first host device that is destined for the second host device, [0019]; In response to identifying the ND1 as the source ND for the first data flow path, the SDN controller may generate a flow rule to cause ND1 (the source ND) to block (or drop) data received from the first host device that is destined for the second host device, [0023]).
Regarding claim 8, Mulka teaches the system of claim 1, wherein the monitoring subsystem is further configured to monitor information to identify the change concurrent with operation of the SDN (In an SDN, operating in accordance with the OpenFlow™ protocol may include data path functions being executed by network devices (NDs), such as routers and switches, while control functions including high-level routing decisions are moved to a separate SDN controller, such as a network server, [0013]).
However, Mulka does not explicitly disclose the monitoring subsystem monitoring information from the plurality of network devices.
Evans teaches the monitoring subsystem is further configured to monitor information from the plurality of network devices to identify a change concurrent with operation of the SDN (Data on the control plane may be exchanged between the control device 120 and various components in the SDN at or near real-time, [0024]; The devices in the system may send the monitor data securely over a data-bus in real-time to the control device 120, [0026]; The monitor data may be based on the at least one device of the set of devices in the SDN monitoring of the set of characteristics substantially in real-time, [0094]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for a controller to receive traffic flow data directly from network devices in the system/method of Mulka as suggested by Evans to maintain functionality absent of a firewall security device. One would be motivated to combine these teachings in order for a SDN controller to more thoroughly monitor all relevant SDN traffic characteristics and parameters.
Regarding claim 9, Mulka teaches the system of claim 1, wherein the monitoring subsystem is further configured to identify the change to at least one aspect of the planned configuration without operator intervention (if malicious data is detected in the data flow path by a firewall, the firewall may generate a message indicating malicious activity associated with the flow ID. The SDN controller can identify the corresponding data flow path (and associated flow rules table and/or flow rules) using the flow ID, [0017]; In response to receiving the alert message, the SDN controller (and/or the SDN application) may extract the alert data flow ID from the alert message, determine a flow ID corresponding to the alert date (e.g., a flow ID corresponding to the header fields of packets suspected as being malicious), and reference a mapping of flow rule IDs to flow rules tables to identify the flow rules table for the first data flow path using the flow ID determined using the alert message, [0023]; the memory 1004 may store instructions or other logic for performing some or all of the functions described herein with regard to the SDN controller 102, [0051]).
Regarding claim 10, Mulka teaches the system of claim 1, wherein information from the plurality of network devices related to traffic in the SDN comprises a plurality of packets received from the plurality of network devices (A flow ID may uniquely identify a flow path based on a combination of a subset of fields from the packet's headers, such as media access control (MAC) addresses, IP addresses, Transmission Control Protocol (TCP) port, virtual local area network (VLAN) IDs and/or the like, [0017]; In response to receiving the alert message, the SDN controller (and/or the SDN application) may extract the alert data flow ID from the alert message, determine a flow ID corresponding to the alert date (e.g., a flow ID corresponding to the header fields of packets suspected as being malicious), and reference a mapping of flow rule IDs to flow rules tables to identify the flow rules table for the first data flow path using the flow ID determined using the alert message, [0023]).
However, Mulka does not explicitly disclose information from the plurality of network devices that fail to match the plurality of communication flows.
Evans teaches wherein information from the plurality of network devices related to traffic in the SDN comprises information received from the plurality of network devices that fail to match the plurality of communication flows (the processing logic may determine a change to a set of parameters of the SDN. In at least some embodiments, determining the change to the set of parameters of the SDN may include comparing the monitor data with a template and determining at least one difference between the monitor data and the template, [0095]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for a controller to receive and compare traffic flow data directly from network devices in the system/method of Mulka as suggested by Evans in order to thoroughly monitor all relevant SDN traffic characteristics and parameters. One would be motivated to combine these teachings because comparing differences between monitor data from network devices and a predetermined template or policy rules would enable determination of a change.
The method of claim 11 comprises limitations equivalent to those of system claim 1, and therefore is rejected in view of the same rationale.
The method of claim 12 comprises limitations equivalent to those of system claim 2, and therefore is rejected in view of the same rationale.
The method of claim 13 comprises limitations equivalent to those of system claim 3, and therefore is rejected in view of the same rationale.
The method of claim 14 comprises limitations equivalent to those of system claim 4, and therefore is rejected in view of the same rationale.
The method of claim 15 comprises limitations equivalent to those of system claim 5, and therefore is rejected in view of the same rationale.
The method of claim 16 comprises limitations equivalent to those of system claim 6, and therefore is rejected in view of the same rationale.
The method of claim 17 comprises limitations equivalent to those of system claim 7, and therefore is rejected in view of the same rationale.
The method of claim 18 comprises limitations equivalent to those of system claim 8, and therefore is rejected in view of the same rationale.
The method of claim 19 comprises limitations equivalent to those of system claim 9, and therefore is rejected in view of the same rationale.
The method of claim 20 comprises limitations equivalent to those of system claim 10, and therefore is rejected in view of the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Smith US 2019/0036776 – determining an effect of a network configuration change in a SDN and providing a network administrator with authority to approve a proposed change.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHU WOOLCOCK whose telephone number is (571)270-3629. The examiner can normally be reached Tuesday, Thursday 9-6 ET.
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, Chris Parry can be reached at 571-272-8328. 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.
MADHU WOOLCOCK
Examiner
Art Unit 2451
/MADHU WOOLCOCK/Primary Examiner, Art Unit 2451
Prosecution Insights