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 .
Response to Amendment
The applicant’s amendments have overcome the prior art rejection of claim 1 and its dependents for the reasons explained in the 8/1/2025 office action and the first written description issue presented in the 8/1/2025 office action. The amendments have overcome the prior art rejections as neither Dunbar or Siracusano suggested building a network service function “responsive to” BGP data (claims 1 and 11) or “based on” BGP data (claim 16), as presently claimed.
Response to Arguments
Applicant's arguments filed 10/24/2025 have been fully considered but they are not persuasive. The applicant has not made any arguments regarding the first and third written description issues presented in this office action (previously the second and fourth written description issues). The applicant’s amendments do not address these issues and the amended language is accounted in the rejections in this office action. The applicant’s argument regarding the second written description issues (previously the third written description issue) are not persuasive. The applicant has not provided any description of the “service chain builder” function references in paragraph 44 of the applicant’s disclosure. Naming a function “service chain builder” is not a description of how the functions of a service chain builder are performed. Describing how claimed functions are to be performed is necessary in order to meet the requirements of the written description requirement according to the guidance given in section 2161.01(I) of the MPEP. The applicant’s arguments regarding the prior art rejections of claims 11 and 16 are not persuasive because the applicant did not amend claims 11 and 16 to the full content of claim 8 and claim 8 was objected to in the context of claim 1 and not claim 11 (the examiner notes that claim 20 corresponds to claim 8).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 and 4-22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Written Description Issue #1
Claims 1, 11, and 16 feature the following limitations:
exposing, by the processing system, the list of network service functions through an application programming interface (API), wherein exposing the list of network service functions comprises providing, to a user through the API, information about one or more available service functions of the list of service functions and information describing the capabilities of each respective network service function, the type of each network service function and the current loading of each respective network service function of the one or more available service functions available on the service provider network and wherein exposing the list of network service functions further comprises omitting from the list of network service functions one or more service functions which are subject to user-based constraint;
Claim 11 features the following limitations:
exposing information about respective network service functions of the list of network service functions at an application programming interface (API), wherein the exposing the list of network service functions comprises providing information about one or more available service functions which are available over the service provider network and information describing attributes of the one or more available service functions;
Claim 16 features the following limitations:
exposing the list of network service functions through an application programming interface (API), including providing at least a portion of the network information to a customer device through the API, wherein the exposing the list of network service functions comprises providing information about one or more available service functions of the list of network service functions and information describing attributes of the one or more available service functions;
The applicant did not disclose how to expose a received list of network service functions through an API that can then be interfaces by customer devices to receive requests. Paragraph 27 states that the controller learns the availability of the network service functions via protocols such as BGP. Paragraph 27 then states that the controller may then transform BGP data in the form of a representational state transfer (REST) API and then make the API available for use. This is the only description of how the API which is exposed and then used for receiving customer requests from a customer device is created. There is no description of how the applicant’s invention takes BBP data and transforms it in the form of a REST API that can be made available to customers in order to receive “flows” provided by the customer. The applicant’s disclosure is void of any description of the transformation of BGP data that is necessary in order to perform the function of exposing the API, claimed by the applicant. As such, the applicant has failed to meet the requirements of written description described in sections 2161.01(I) of the MPEP regarding providing a description of how functions are to be performed.
Written Description Issue #2
Claims 1, 11, and 16 feature the following limitations:
building, by the processing system, a service function path that includes the at least one network service function, resulting in a built service function path, wherein the building the service function path is responsive to the customer request, the BGP data advertising the reachability of the list of network service functions, and the user interaction by the user through the API to build the service function path;
Claim 11 features the following limitations:
responsive to the customer interaction defining the customer request for routing data traffic and the BGP data advertising the reachability of the network service functions, building a service function path in the service provider network, the service function path including the plurality of network service functions, resulting in a built service function path;
Claim 16 features the following limitations:
based on the customer interaction defining the customer request and the BGP data advertising the reachability of the network service functions, building a service function path that includes the at least one network service function, resulting in a built service function path;
The applicant did not disclose how to build a service function path in response to a customer request from a customer to create a network service function path.
The applicant provides examples of network service functions in paragraph 26:
Various embodiments described herein provide mechanisms for customers to specify network service functions to create service function chains, and dynamically append, modify and delete network service functions in existing service function chains. Customers may place an order at a customer portal device where a menu of available appliances that implement network services functions can be viewed and selected. Selected appliances may then be added to a service function chain to steer traffic through an ordered set of appliances. By exposing network service functions (e.g., network address translation “NAT,” packet analyzer server “PAS,” distributed denial of service (DDoS) mitigation, firewalls, proxies, etc.), the customer can form service function chains based upon any available criteria, including, location, current loading, service function type (e.g., vendor), etc. The customer’s data is then routed through the appliances in the service function chain. Management of data and monitoring as described herein may be subject to authorization of the relevant parties including the customer whose data is being monitored, where the authorization can be obtained in various ways including opt-in and opt-out techniques.
Paragraphs 13, 17, 18, 45, 58, 65, 85, 92 provide literal support for the phrase “building a network service path” but they do not describe how the network service path is actually built to include more than one network service function which is covered by the “at least one network service function responsive to the claimed customer request” language. Paragraphs 45 and 46 reference a service chain builder function 210C but the applicant provides no description of how this function operates to build network service chains.
Paragraph 41 depicts a network service path as reference number 220B in Figure 2B. Paragraph 41 does not provide a description of how this path is defined or how it is created. Figure 2B shows the path 220B to be a line through physical equipment and a service function node 220, which includes a provider edge 3 and processing resource 222A. Paragraph 29 provides examples of processing resources 222A as being a virtual server that implements PAS server or a server that implements a NAT in software. The line 220B which depicts the network service path does not show how more than one service function would be implemented in the service function path. There is no description of how the PAS would interface with the NAT or any of the other examples of network service functions covered by the applicant’s disclosure to create a service function path.
Additionally, the final sentence of paragraph 53 states that the customer request for creating a path could include a path with network service functions at different physical locations. The applicant has not provided any description of how such a path would be implemented and Figure 2B only shows implementing two separate paths to network service functions located at different physical locations (220B and 230B). There is no description of how these paths would be combined. The applicant has not provided any description of how a path between different physical locations would be implemented.
The applicant’s claims cover scenarios of building a service function path that includes more than one network service function requested by a customer. The applicant does not disclose how such a service function path would be built. The applicant does not describe what such a path would comprise because there is no description of how resources 222A or 272A would be combined to create a path or how resources in different locations would be combined into a single path so it cannot be inferred from what is disclosed how such a path would be “built”. The applicant is claiming the function of building a server function path that could include more than one network service functions but fails to provide any description of how such a path is actually built. As such, the applicant has failed to meet the requirements of written description described in sections 2161.01(I) of the MPEP regarding providing a description of how functions are to be performed.
Further, the applicant’s disclosure does not even provide literal support for the 10/24/2025 claim amendments because the applicant does not disclose any relationship between the BGP data advertising reachability of the network service functions and the action of building a network service path. As explained, the applicant refers to the reception of BGP data in paragraph 17, 27, 36 and 51. There is no description of building a network service function “responsive to” BGP data (claims 1 and 11) or “based on” BGP data (claim 16), as presently claimed. The original disclosure did not provide support for the 10/24/2025 claim amendment.
Written Description Issue #3
Claim 1 features the following limitations:
assigning a classifier to the built service function path;
identifying a match between the classifier assigned to the built service function path and a traffic classifier, wherein the traffic classifier is added to the data traffic; and
routing data traffic according to a-the classifier of added to the data traffic, the classifier corresponding to the built service function path.
Claim 11 features the following limitations:
providing a classifier corresponding to the built service function path; and
routing data traffic according to the classifier of the data traffic, wherein the routing comprises identifying a match between a traffic classifier added to the data traffic and the classifier corresponding to the built service function path.
Claim 16 features the following limitations:
assigning a classifier to the built service function path; and
routing data traffic according to a classifier of the data traffic, including identifying a match between the classifier of the data traffic and the classifier assigned to the built service function path.
The applicant did not disclose how to actually route data traffic according to a classifier. Paragraph 17 states that operations of the invention include “adding a classifier to data traffic destinated for the customer, wherein the classifier corresponds to the service function path”. It is not clear what element performs this operation described in paragraph 17. Paragraph 27 states that “the controller may create a classifier route and map it to a given service chain path, based on flows provided by the customer”. The applicant has not described what such “flows” provided by the customer comprise, how the “classifier route” is different from the “service chain path”, how the classifier route is created, or what the classifier route actually comprises. The term “classifier route” is never used by the applicant again in the disclosure and the applicant never references the customer providing “flows” again in the disclosure. Paragraph 43 states that a “classifier may be added to data traffic to be routed on the service function path” but there is no description of what element is adding the classifier to the data traffic. Paragraph 55 states that if a classifier match is found the router will route the data traffic through the network service functions that are on the matching service function path. As previously explained, the applicant does not actually describe how a “network service function path” is created or how routing on such a path would be implemented. There is no description of how the routing described in paragraph 55 would be performed. The routing cannot be inferred because of the incoherent description regarding “classifier routes” which are somehow different than “service chain paths” provided in paragraph 27. Paragraph 106 and 107 use the term classifier in a completely different context, corresponding to using machine learning to recognize patterns in data traffic, which is has nothing to do with the classifier claimed. The applicant does not provide a sufficient description of how the claimed function of routing data traffic according to a classifier is performed and thus does not meet the requirements of section 2161.01(I) of the MPEP regarding providing a description of how functions are to be performed.
Claims Not Rejected with Prior Art
The applicant’s amendments have overcome the prior art rejections for the reasons explained and updated search did not reveal any prior art that would anticipate or make obvious the claimed invention. They are not indicated as allowable because of the written description rejections presented in this office action.
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 DOUGLAS B BLAIR whose telephone number is (571)272-3893. The examiner can normally be reached Monday-Friday 9am-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, Glenton 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.
/DOUGLAS B BLAIR/Primary Examiner, Art Unit 2454