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 OFFICE ACTION
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2024-08-06 and 2025-10-01 in compliance with the provisions of 37 CFR 1.97 has been considered by the examiner and made of record in the application file.
Claim Status
Claims 1-6 are pending in this application and are under examination in this Office Action. No claims have been allowed.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
The limitations reciting a “conversion unit,” “generation unit,” and “API control unit” have been reviewed for possible treatment under 35 U.S.C. 112(f). The limitations are not separately rejected under 35 U.S.C. 112(b) on this basis in this Office Action because the specification identifies corresponding components and describes sufficient operations for the recited functions, including conversion unit 323, generation unit 324, API control unit 311, user information database 332, topology database 333, and the computer hardware implementation shown in Fig. 5. This statement is provided for clarification and does not constitute a separate rejection.
Claim Rejections - 35 USC § 112(b)
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 2-4 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 2,
Claim 2 recites that “the generation unit is configured to refer to a topology storage unit that stores transmission system parameters of the optical path, identifies transmission system parameters of the optical path corresponding to the two optical path endpoints, and generate the control information using the transmission system parameters and the two optical path endpoints.”
As written, the scope of claim 2 is unclear because the claim does not clearly identify which claimed component performs the active functions of identifying the transmission system parameters and generating the control information. The claim first recites “the generation unit is configured to refer to a topology storage unit,” and then uses the relative clause “that stores transmission system parameters of the optical path, identifies transmission system parameters . . . and generate the control information.” Grammatically, the word “that” most naturally refers to the immediately preceding noun phrase, namely the “topology storage unit.” Under that reading, the topology storage unit, rather than the generation unit, would be required to identify the relevant transmission system parameters and generate the control information.
This ambiguity is material because claim 2 separately recites a “generation unit” and a “topology storage unit,” and the scope of the claim depends on whether the claimed generation and identification operations are performed by the generation unit, by the topology storage unit, or by some other component. The problem is further confirmed by the nonparallel wording “identifies transmission system parameters . . . and generate the control information,” which leaves uncertain whether the phrase is intended to describe functions of the topology storage unit or functions of the generation unit. The specification does not remove the ambiguity in the claim language. The specification describes the topology database 333 as storing transmission system parameters and describes the generation unit 324 as referring to the topology database, identifying transmission system parameters, and generating control information. However, claim 2 does not clearly recite that same relationship. Instead, the claim language blurs the distinction between the storage function of the topology storage unit and the active processing/generation function of the generation unit.
Accordingly, one of ordinary skill in the art would not be reasonably apprised of the metes and bounds of claim 2, and claim 2 is indefinite.
Regarding claim 3,
Claim 3 recites “an API control unit configured to control a first API directed to an outside of the carrier network and a second API directed to the transmission device.” The phrase “a first API directed to an outside of the carrier network” renders the scope
of claim 3 unclear because the claim does not identify what structure, device, system, interface, boundary, network portion, or entity is being referred to as “an outside.” The phrase “an outside” is not a recognized structural component of a carrier network and does not reasonably identify the endpoint or target of the first API. As written, it is unclear whether the first API is directed to a service provision device located outside the carrier network, directed to an external network, exposed at an external boundary of the carrier network, directed to an external user terminal, or merely accessible from outside the carrier network.
The ambiguity is not cured by the remaining language of claim 3. Claim 3 later recites that the conversion unit receives the connection request transmitted from the service provision device via the API control unit, but claim 3 does not state that the first API is directed to the service provision device. Thus, the claim leaves uncertain the relationship between the first API and the service provision device from which the connection request is received. This uncertainty is material because the first API is the claimed interface by which outside entities access the optical path control device.
Claim 3 is also unclear because it recites that the API control unit controls “a second API directed to the transmission device,” while later reciting that the generation unit transmits the control information “to a transmission device controller that controls the transmission device via the API control unit.” As written, it is unclear whether the endpoint of the second API is the transmission device itself, the transmission device controller, or both. This ambiguity is material because claim 3 expressly distinguishes
between a “transmission device” and a “transmission device controller,” and the scope of the claimed API control unit depends on which entity is actually controlled through, or addressed by, the second API.
The specification confirms that these are distinct concepts. The disclosure describes a transmission device controller 4 that controls transmission devices 5, and also describes a transmission device API 82 arranged between the optical path control device 3 and the transmission device controller 4. The claim, however, recites a second API directed to the transmission device while also reciting transmission of control information to a transmission device controller. Therefore, the intrinsic record does not resolve the uncertainty created by the claim language itself. Accordingly, one of ordinary skill in the art would not be reasonably apprised of the scope of claim 3, and claim 3 is indefinite.
Regarding claim 4,
Claim 4 depends from claim 3 and therefore incorporates all limitations of claim 3. Claim 4 recites the layer arrangement of the API control unit, the conversion unit, the generation unit, the user information storage unit, and the topology storage unit. However, claim 4 does not cure the ambiguity in claim 3 regarding what is meant by “a first API directed to an outside of the carrier network” or whether the second API is directed to the transmission device itself, to the transmission device controller, or to both.
Because claim 4 depends from and incorporates the indefinite limitations of claim 3, the metes and bounds of claim 4 are likewise not reasonably certain. Accordingly, claim 4 is indefinite.
Accordingly, claims 2-4 are indefinite under 35 U.S.C. 112(b).
Claim Rejections – 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for the 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.
As reiterated by the Supreme Court in KSR, and as set forth in MPEP 2141 (R-01.2024), II, the factual inquiries of Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), applied for establishing a background for determining obviousness under 35 U.S.C. §103, are summarized as follows:
Determining the scope and content of the prior art;
Ascertaining the differences between the prior art and the claims at issue;
Resolving the level of ordinary skill in the pertinent art; and
Considering objective evidence indicative of obviousness or non-obviousness, if present.
This application currently names joint inventors. In considering patentability of the claims, the examiner presumes that the subject matter disclosed in the prior art was created by another (i.e., not by the inventive entity) unless proven otherwise. Applicant is advised of the obligation under 37 C.F.R. § 1.56 to point out the inventor and effective filing dates of each claim, and any evidence of common ownership/assignment as of the effective filing date, so that the examiner may properly consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the claimed invention(s).
Claims 1, 5 and 6 are rejected under 35 U.S.C. § 103 as being unpatentable over Campanella et al. (ODTN: Open Disaggregated Transport Network. Discovery and control of a disaggregated optical network through open-source software and open APIs) in view of Chikushima et al. (JP 2012-150569 A, English translation), further in view of Previdi et al. (US9253041B2) and Lingampalli (US9736556B2).
Claim 1
As per claim 1, Campanella teaches an optical path control device in the form of an ONOS/ODTN controller for controlling a disaggregated optical transport network.
Campanella states in the Abstract: "ONOS discovers and manages a topology made of Transponders and a dedicated OLS, using standard protocols (NETCONF/RESTCONF) and models (OpenConfig/TAPI)." [Campanella, p. 1, Abstract].
Campanella further teaches that the ODTN controller is used for both topology discovery and connectivity setup.
Campanella states: "The demo shows the use of ONOS (i.e., Open Network Operating System) controller for the control of a partially disaggregated network. The demo has two phases, first topology discovery and second, point-to-point connectivity setup." [Campanella, p. 1, section 1, Overview].
Campanella also teaches that the request for optical connectivity is transmitted from a service-side or operator-side system, corresponding to the claimed service provision device.
Campanella states: "TAPI Connectivity requests are going to be issued by the operator’s BSS or OSS, the system overarching the whole network deployments." [Campanella, p. 1, section 1, Overview].
Campanella teaches the optical path and carrier-network transmission-device environment.
Campanella states that the underlying infrastructure includes "two disaggregated white box optical transponders" and "an OLS to which both line-side ports of the controller are connected." [Campanella, p. 1, section 1, Overview].
Campanella further states that "the transponder’s capabilities are discovered, querying the device capabilities such as components, ports and interfaces, as well as supported Optical
Channels, according to the OpenConfig models," and that ONOS relies on RESTCONF interfaces exported by the OLS. [Campanella, p. 2, section 1.2, Topology Discover].
Campanella teaches that the control information is generated and sent to transmission devices and/or a transmission-device controller using transmission-system parameters.
Campanella states: "The first request, OTSi specific, will contain parameters for the OLS and the line side ports of the transponders. This request will be broken down by ONOS to a rest call containing a connectivity-service object from TAPI to the OLS and two requests modifying port state, power and frequency on the transponder line side." [Campanella, p. 2, section 1.3, Connectivity setup].
Campanella further states: "For both requests the Transponder will be configured though OpenConfig defined messages exchanged on top of the previously established Netconf SSH session." [Campanella, p. 2, section 1.3, Connectivity setup].
Therefore, Campanella teaches generating control information for transmission devices arranged in a carrier/transport network using optical-path parameters, including at least port state, power, frequency, optical channels, service interface points, and transponder line-side information.
Campanella does not expressly disclose the precise wording of "convert a connection source user ID and a connection destination user ID ... into two optical path endpoints." However, within analogous art, Chikushima expressly teaches the missing user/request-to-endpoint conversion and completion functionality.
Chikushima states in the Abstract: "PROBLEM TO BE SOLVED: To make it possible to automatically reserve appropriate resources even when a client does not explicitly designate a location of the resources to be reserved." [Chikushima, p. 1, Abstract].
Chikushima further states in the Abstract that the resource reservation device performs the following steps: "receiving a request message for operating an application from a client; generating a missing object and connection to the object and connection included in the request message to complement their contents; retrieving required resources based on the database and existing combination algorithm; complementing a reservation message for reserving the required resources on behalf of the client; and reserving the resources based on the reservation message." [Chikushima, p. 1, Abstract].
Chikushima teaches that the resource reservation apparatus has user, service, object/connection-analysis, object-change, connection-change, and network-database components.
Chikushima states: "The resource reservation apparatus 100 includes a core unit 110, a service database management unit 120, a service confirmation unit 130, an object / connection analysis unit 140, an object change unit 150, and a connection change unit 160." [Chikushima, p. 3, Description of Embodiments].
Chikushima further teaches the user and network database structures used to identify endpoints and network resources.
Chikushima states: "The user database management unit 10 manages the identifier and location of the user, and in accordance with an instruction from the resource reservation
device 100, the endpoint at which the user accesses the nearest network edge, usable computers and storages, and network restrictions Or a function of searching for a part of them and responding." [Chikushima, p. 4, Description of Embodiments].
Chikushima also states: "The network database management unit 60 manages part or all of the network resource type, identifier, location, and usable time of nodes and communication channels..." [Chikushima, p. 4, Description of Embodiments].
Chikushima teaches that the service database stores domain relationships and endpoint identifiers so that the endpoints of a connection can be determined.
Chikushima states: "By storing a table including the identifier of the target domain, the identifier of the adjacent domain, the identifier of the end point of the target domain, and the identifier of the end point on the adjacent domain side, the end point of the connection can be determined." [Chikushima, p. 6, Description of Embodiments].
Chikushima further teaches that the connection includes endpoints and an opposite endpoint.
Chikushima states: "The end point of the connection and the end point on the opposite side are the end points shown in FIG. 9, or identifiers of elements of computer resources and storage resources." [Chikushima, p. 7, Description of Embodiments].
Most importantly for the conversion limitation, Chikushima states: "As a feature of the present invention, it is not necessary for the client to specify the identifier or usage time of the element of the network resource, the end point of the connection, and the end point or feature of the opposite side. This is because the resource reservation device 100 searches for
resources, usage time, connection endpoints, and features that meet the client’s conditions." [Chikushima, pp. 7-8, Description of Embodiments].
Chikushima also teaches the specific step of using user identifiers to obtain endpoints. Chikushima states: "This is an example in which the object changing unit 150 makes an inquiry to the user database management unit 10 according to the user identifier of the user object... In response to the inquiry from the core unit 110, the user database management unit 10 responds with computer resources, storage resource candidates, and endpoints that the user is permitted to use." [Chikushima, pp. 14-15, Description of Embodiments].
Chikushima further teaches the connection-change process that completes endpoints and determines connection candidates.
Chikushima states: "Through the object change step 140, the endpoints of each connection candidate have already been clarified. Therefore, the end point obtained in the element part of each connection candidate is complemented." [Chikushima, p. 16, Description of Embodiments].
Chikushima also states: "The connection changing unit 160 determines connection endpoints based on the object candidate 1. Similarly, end points of connection candidates based on the object candidate 2 are determined." [Chikushima, p. 16, Description of Embodiments].
Accordingly, Chikushima teaches that a client-side request can identify users or objects without requiring the client to provide the detailed connection endpoints, and that the resource reservation device uses user information, service information, network-resource information, and database-stored endpoint/domain relationships to automatically determine and
complement the endpoints for the connection. When applied to Campanella’s optical/TAPI connectivity environment, the determined connection endpoints correspond to the claimed two optical path endpoints.
Within analogous art, Previdi further reinforces the optical endpoint/topology parameter aspects.
Previdi teaches a Layer 0 optical network and exchange of L0 topology information.
Previdi states: "In a typical example, the L0 network is an optical network and the L3 network is an IP network." [Previdi, col. 2, lines 8-10].
Previdi further states that the topological information is analyzed "to determine connections available to the L3 network, yet within the L0 network" and that a connection request is sent to the L0 network. [Previdi, col. 2, lines 10-17].
Previdi also teaches endpoint/point-of-attachment information and transmission-system parameters such as wavelength and latency.
Previdi states: "A PoA message may include the advertising node, associated autonomous system, Source and destination points of attachment (PoAS)." [Previdi, col. 4, lines 20-24].
Previdi further states: "Individual link attribute TLVs may include link bandwidth and other links metrics such as link latency, available and used wavelengths (W)." [Previdi, col. 3, lines 62-67].
Lingampalli further reinforces the request-to-optical-path provisioning aspect.
Lingampalli states in the Abstract: "a programmable network platform for an interconnection facility exposes an interface by which customers of the interconnection system provider may
request fiber cross-connects to other customers of the interconnection system provider." [Lingampalli, Abstract].
Lingampalli further states that, in response to such request, the platform "configure[s] an optical switch fabric of the interconnection facility network infrastructure to create a fiber cross-connect between the demarcation points for the customers to be interconnected." [Lingampalli, Abstract].
Lingampalli also teaches the specific sequence of receiving a request, identifying an optical path, and provisioning the path.
Lingampalli’s FIG. 8 recites: "RECEIVE, BY A PROGRAMMABLE NETWORK PLATFORM, A REQUEST FOR A FIBER CROSS-CONNECT BETWEEN A FIRST CUSTOMER AND A SECOND CUSTOMER," then "IDENTIFY, BY THE PROGRAMMABLE NETWORK PLATFORM, AN OPTICAL PATH THROUGH A PRE-PROVISIONED OPTICAL SWITCH FABRIC," and then "PROVISION, BY THE PROGRAMMABLE NETWORK PLATFORM, THE FIBER CROSS-CONNECT BY CONFIGURING THE OPTICAL SWITCH FABRIC TO INSTANTIATE THE OPTICAL PATH." [Lingampalli, FIG. 8].
Therefore, claim 1 is taught by Campanella in view of Chikushima, further in view of Previdi and Lingampalli.
Campanella teaches the optical path control device, service-side TAPI connectivity request, topology discovery, connectivity setup, transmission devices, OLS/transponders, control APIs, and generation/transmission of control information including port state, power, frequency, and other optical/transmission parameters.
Chikushima teaches the missing conversion logic, namely using user/request information and databases to determine and complement connection endpoints that the client did not specify.
Previdi confirms that optical-layer topology includes endpoints/points of attachment, wavelengths, latency, and available optical connectivity.
Lingampalli confirms that a customer/service request can be converted into an identified optical path and provisioned by configuring optical switching infrastructure.
One of ordinary skill in the art would have been motivated to combine Campanella and Chikushima because Campanella expressly provides an API-controlled optical network in which TAPI connectivity requests from OSS/BSS are used to set up point-to-point optical connectivity, while Chikushima solves the complementary problem of allowing a client to request service without specifying the exact resource locations or connection endpoints.
A person of ordinary skill implementing Campanella’s ODTN controller for operator/service-provider use would have recognized the immediate benefit of Chikushima’s user/request-to-endpoint completion logic: the OSS/BSS or service provider could submit a higher-level request identifying source and destination users, and the controller-side logic could consult user, service, topology, and network databases to determine the actual optical endpoints and the transmission resources needed for the optical path. This is a predictable integration of a known service-abstraction/resource-reservation technique into a known optical SDN/TAPI controller architecture. The combination would reduce the amount of optical-transport knowledge required from the service-side requester, would automate endpoint selection, would allow topology-aware provisioning, and would make Campanella’s optical connectivity setup usable
by higher-level service systems. One of ordinary skill in the art would have further relied on Previdi because it teaches the same L0 optical topology and endpoint/point-of-attachment abstraction used to translate higher-layer connectivity into optical-network connectivity.
One of ordinary skill in the art would have also relied on Lingampalli because it confirms that customer/service requests were known to be converted into identified optical paths and then provisioned through optical switching infrastructure. The resulting system is no more than the predictable use of known optical SDN control, known client-request endpoint completion, known L0 optical topology parameters, and known optical path provisioning to obtain the claimed optical path control device.
Claim 5
As per claim 5, the claim recites an optical path control method executed by an optical path control device. Claim 5 is the method counterpart of claim 1 and recites the steps of converting a connection source user ID and a connection destination user ID included in a connection request for an optical path, transmitted from a service provision device, into two optical path endpoints; and generating control information for a transmission device arranged in a carrier network using transmission system parameters corresponding to the two optical path endpoints.
Campanella teaches the method environment because ONOS/ODTN performs topology discovery and point-to-point optical connectivity setup.
Campanella states: "The demo has two phases, first topology discovery and second, point-to-point connectivity setup." [Campanella, p. 1, section 1].
Campanella further teaches that the request comes from the outside service/operator side: "TAPI Connectivity requests are going to be issued by the operator’s BSS or OSS." [Campanella, p. 1, section 1].
Campanella teaches the generating-control-information step because ONOS breaks down the connectivity request into control calls.
Campanella states: "This request will be broken down by ONOS to a rest call containing a connectivity-service object from TAPI to the OLS and two requests modifying port state, power and frequency on the transponder line side." [Campanella, p. 2, section 1.3].
Campanella further states: "For both requests the Transponder will be configured though OpenConfig defined messages exchanged on top of the previously established Netconf SSH session." [Campanella, p. 2, section 1.3].
Chikushima teaches the converting step in method form.
Chikushima states that the resource reservation method includes a message exchange step, service confirmation step, object/connection analysis step, object change step, connection change step, and resource reservation step. [Chikushima, pp. 4-5, Description of Embodiments].
Chikushima teaches that missing connection information and endpoints are automatically generated and complemented.
Chikushima states: "Step 150) The connection change unit 160 generates a missing connection through the results of the service confirmation step (Step 120), the object connection analysis step (Step 130), and the object change step (Step 140), and The contents of the connection are complemented through data exchange with the network database management unit 6 and stored in the service database management unit 120." [Chikushima, pp. 4-5, Description of Embodiments].
Chikushima further states: "As a feature of the present invention, it is not necessary for the client to specify ... the end point of the connection, and the end point or feature of the opposite side. This is because the resource reservation device 100 searches for resources, usage time, connection endpoints, and features that meet the client’s conditions." [Chikushima, pp. 7-8, Description of Embodiments].
Chikushima also teaches the user-ID-to-endpoint method step. Chikushima states that the object changing unit inquires according to the user identifier, and that the user database responds with "endpoints that the user is permitted to use." [Chikushima, pp. 14-15, Description of Embodiments].
Previdi and Lingampalli further confirm the optical method context. Previdi teaches that topology information is analyzed to determine L0 optical connections and that a connection request is sent to the L0 network. [Previdi, col. 2, lines 10-17].
Lingampalli teaches receiving a request, identifying an optical path through optical switching infrastructure, and provisioning/configuring the optical switch fabric to instantiate the optical path. [Lingampalli, FIG. 8].
Therefore, claim 5 would have been obvious for the same reasons as claim 1, applied in method form. The combination teaches receiving a service-side optical path request, using user and database information to determine endpoints that the user did not specify, identifying optical topology and transmission parameters corresponding to those endpoints, and generating/sending control information to optical transmission devices or controllers.
One of ordinary skill in the art would have been motivated to perform the method of claim 5 because it is the natural operational sequence of the apparatus of claim 1. Campanella’s controller necessarily performs method steps when it receives a TAPI connectivity request and breaks it into OLS/transponder configuration messages. Chikushima provides the method steps for completing missing connection endpoints and resource information based on client/user conditions and database lookup. Previdi provides the L0 topology and endpoint abstraction needed to analyze optical connectivity, and Lingampalli provides the request-to-optical-path provisioning sequence. Combining these known method steps would have predictably allowed an optical path control device to receive a high-level source/destination user request, determine the actual optical endpoints, identify the corresponding optical transmission parameters, and generate the control information required to provision the optical path. The method is therefore an obvious implementation of known service abstraction, endpoint completion, topology-based optical control, and optical path provisioning techniques.
Claim 6
With respect to claim 6, all limitations of claim 1 are taught by Campanella, Chikushima, Previdi and Lingampalli as discussed above, except wherein Claim 6 further recites a computer-readable storage medium storing a program which causes a computer to function as the optical path control device according to claim 1.
However, within analogous art, Chikushima expressly teaches program implementation.
Chikushima states: "The operations of the components of the resource reservation device 100 in the first to fourth embodiments are constructed as a program and installed in a computer used as the resource reservation device for execution or distributed via a network." [Chikushima, p. 22, Description of Embodiments].
Chikushima also includes a program claim.
Chikushima states: "The resource reservation program for functioning a computer as each means which comprises the resource reservation apparatus of any one of Claim 1 thru | or 3." [Chikushima, p. 27, Description of Embodiments].
Campanella likewise teaches that the optical path control functionality is software-based and implemented in ONOS/ODTN.
Campanella states that ODTN’s solution has "three key pillars: open-source software, Open APIs and device disaggregation." [Campanella, p. 3, section 2].
Campanella further states that ONOS is used as the controller for topology discovery and connectivity setup, and that transponders are configured through OpenConfig messages over NETCONF. [Campanella, pp. 1-2, sections 1.2-1.3].
Therefore, Chikushima expressly teaches storing/constructing the resource-reservation device functions as a program for execution by a computer, and Campanella teaches software-based ONOS/ODTN optical path control. Once claim 1 is obvious over Campanella in view of Chikushima and the additional supporting references, storing the corresponding program instructions on a computer-readable storage medium to cause a computer to perform the optical path control device functions would have been obvious.
One of ordinary skill in the art would have been motivated to implement the combined optical path control device as program instructions stored on a computer-readable storage medium because the cited references themselves use software-controlled network systems. Campanella’s ONOS/ODTN controller is expressly open-source software implementing topology discovery, API handling, and optical connectivity setup. Chikushima expressly states that the operations of the resource reservation device can be constructed as a program and installed in a computer used as the resource reservation device. In the optical SDN/control art, implementing controller functions as software stored on non-transitory computer-readable media was routine and predictable because network controllers, database lookup modules, API handlers, and path/control-generation logic are all computer-executed functions. Therefore, claim 6 would have been obvious.
Claims 2-4 are rejected under 35 U.S.C. § 103 as being unpatentable over Campanella et al., in view of Chikushima et al., further in view of Previdi et al., and Lingampalli, and further in view of Paolucci et al. (Open Network Database for Application-based Control in Multi-Layer Networks).
Claim 2
With respect to claim 2, all limitations of claim 1 are taught by Campanella, Chikushima, Previdi and Lingampalli as set forth above, except wherein claim 2 further recites that the conversion unit refers to a user information storage unit in which user information is stored, and converts each of the connection source user ID and the connection destination user ID into the two optical path endpoints. However, within analogous art, Chikushima expressly teaches this limitation.
Chikushima states: "The user database management unit 10 manages the identifier and location of the user, and in accordance with an instruction from the resource reservation device 100, the endpoint at which the user accesses the nearest network edge, usable computers and storages, and network restrictions Or a function of searching for a part of them and responding." [Chikushima, Description of Embodiments].
Chikushima further states: "This is an example in which the object changing unit 150 makes an inquiry to the user database management unit 10 according to the user identifier of the user object... In response to the inquiry from the core unit 110, the user database management unit 10 responds with computer resources, storage resource candidates, and
endpoints that the user is permitted to use." [Chikushima, pp. 14-15, Description of Embodiments].
The above teachings correspond directly to the claimed conversion unit referring to a user information storage unit and converting the connection source user ID and connection destination user ID into the two optical path endpoints. In the combined system, the source user ID and destination user ID would be two user identifiers for two respective user objects or service endpoints. Chikushima teaches querying user information according to the user identifier and obtaining the endpoint at which the user accesses the nearest network edge. Applying that user endpoint lookup to both the connection source user ID and the connection
destination user ID yields the claimed two optical path endpoints when used in Campanella’s optical path control environment.
Claim 2 further recites that the generation unit refers to a topology storage unit that stores transmission system parameters of the optical path, identifies transmission system parameters of the optical path corresponding to the two optical path endpoints, and generates the control information using the transmission system parameters and the two optical path endpoints. Campanella teaches topology discovery and parameter-based connectivity setup.
Campanella states: "The demo first demonstrates the automated optical network topology discovery through ONOS." [Campanella, p. 2, section 1.2].
Campanella further states that ONOS discovers "components, ports and interfaces, as well as supported Optical Channels, according to the OpenConfig models." [Campanella, p. 2, section 1.2].
Campanella also teaches generating the control information using the relevant parameters.
Campanella states: "The first request, OTSi specific, will contain parameters for the OLS and the line side ports of the transponders."
Campanella further states that ONOS breaks the request into "a connectivity-service object from TAPI to the OLS and two requests modifying port state, power and frequency on the transponder line side." [Campanella, p. 2, section 1.3].
Previdi further teaches that optical topology information includes transmission-related parameters corresponding to links/endpoints.
Previdi states: "Individual link attribute TLVs may include link bandwidth and other links metrics such as link latency, available and used wavelengths (W)." [Previdi, col. 3, lines 62-67].
Paolucci further teaches an open database storing traffic-engineering and topology information for multi-layer networks.
Paolucci states in the Abstract: "In this work we propose a novel network element called Open Network Database."
Paolucci further states that a "YANG-based database for interconnected TE networks is proposed and implemented to enable dedicated applications to perform complex multi-domain/layer operations." [Paolucci, p. 1, Abstract].
Paolucci states that the ONDB "stores information retrieved from a set of existing controller databases and additional information directly stored by the management plane (e.g., inventory, static associations)." [Paolucci, p. 2, section III].
Paolucci also teaches that "Standard YANG definitions are considered within the ONDB, such that vendor-independent NetAPPs can perform queries and elaborations having policy-enabled access to selected parameters of the whole network." [Paolucci, p. 2, section III].
Therefore, the cited art teaches the topology storage unit storing transmission system parameters, identifying parameters corresponding to endpoints, and generating control information using the parameters and endpoints.
Campanella’s ONOS/ODTN controller discovers topology, ports, interfaces, and optical channels and then generates TAPI/OpenConfig/NETCONF control messages including port state, power, and frequency.
Previdi confirms that optical topology includes wavelengths, latency, bandwidth, and points of attachment.
Paolucci confirms the use of a dedicated database for topology/traffic-engineering information that applications can query to perform multi-layer operations.
Chikushima confirms that databases and service storage are used to complete the endpoint and resource information required for connection reservation.
One of ordinary skill in the art would have been motivated to combine these teachings because, after the user endpoints are obtained from the user information storage unit as taught by Chikushima, an optical controller must consult topology and optical-parameter information to determine whether and how the optical path can be set up between those endpoints. Campanella already performs topology discovery and connectivity setup using optical-channel and line-side parameters. Previdi confirms that L0 topology information includes the exact kind
of optical link metrics and wavelength availability needed for such determination.
Paolucci teaches storing and querying such topology/traffic-engineering information in a database to simplify application-based network control. The combination therefore predictably yields an optical path control device in which the conversion unit uses user information storage to convert user IDs to endpoints, and the generation unit uses topology storage to identify transmission-system parameters corresponding to those endpoints and generate control
information. This is a direct and predictable use of known database-assisted endpoint lookup and known optical topology-assisted path provisioning.
Claim 3
With respect to claim 3, all limitations of claim 2 are taught by Campanella, Chikushima, Previdi, Lingampalli and Paolucci as discussed above, except wherein Claim 3 further recites an API control unit configured to control a first API directed to an outside of the carrier network and a second API directed to the transmission device; that the conversion unit receives the connection request via the API control unit; and that the generation unit transmits the control information to a transmission device controller via the API control unit.
However, within analogous art, Campanella expressly teaches an API-based optical controller architecture having a northbound API and southbound/device-facing APIs. Campanella states that the ODTN demonstration uses "standard protocols (NETCONF/RESTCONF) and models (OpenConfig/TAPI)." [Campanella, p. 1, Abstract].
Campanella further states: "We demonstrate the use of recursive Transport API [3], both at the ONOS NBI level (since it acts as a network orchestration) as well as at the SBI level, acting as a client of the OLS, along with the use of T-API in two different layers..." [Campanella, p. 2, section 1.1].
Campanella teaches the first/outside API because the request comes into the ONOS northbound interface.
Campanella states: "Setup of such connectivity will be triggered from a request coming to ONOS Northbound RESTCONF interface of a T-API connectivity service." [Campanella, p. 2, section 1.3].
This corresponds to the claimed first API directed outside of the carrier network because the northbound RESTCONF/TAPI interface receives the connection request from an external OSS/BSS or service-side system.
Campanella teaches the second/transmission-device API because ONOS uses OpenConfig/NETCONF to configure the transponder and RESTCONF/TAPI toward the OLS. Campanella states that ONOS "opens a Netconf session over SSH to the terminal devices" and discovers transponder capabilities using OpenConfig models. [Campanella, p. 2, section 1.2].
Campanella further states: "For both requests the Transponder will be configured though OpenConfig defined messages exchanged on top of the previously established Netconf SSH session." [Campanella, p. 2, section 1.3].
Campanella also teaches that the generation unit transmits control information to the transmission device controller and/or transmission devices through the API control unit.
Campanella states that the OTSi-specific request "will be broken down by ONOS to a rest call containing a connectivity-service object from TAPI to the OLS and two requests modifying port state, power and frequency on the transponder line side." [Campanella, p. 2, section 1.3].
Chikushima teaches that client request messages are received and processed by message exchange means/core unit, and that the object/connection completion units communicate with
databases and network resources through that message exchange arrangement.
Chikushima states: "Step 110) The core unit 110 exchanges resource reservation messages with the client (resource reservation message exchange step)." [Chikushima, p. 4, Description of Embodiments].
Chikushima further states that the object changes unit and connection change unit communicate with database management units via the core unit. [Chikushima, pp. 4-5, Description of Embodiments].
Therefore, Campanella teaches the claimed API control unit, first API, second API, receipt of the connection request through the API, and transmission of control information through the API. Chikushima reinforces the general architecture of receiving a client request through a message exchange unit and forwarding completed control/reservation information to the appropriate resource-management components.
One of ordinary skill in the art would have been motivated to combine the API control teachings of Campanella with the database/endpoint-completion teachings of Chikushima because both references solve different portions of the same service-provisioning problem. Campanella
provides the optical SDN/TAPI northbound/southbound API architecture by which an outside OSS/BSS system can request optical connectivity and by which ONOS can control OLS/transponders. Chikushima provides the endpoint-completion logic that allows the outside requester to avoid specifying lower-level connection endpoints and resource details. It would have been obvious to place the conversion unit behind Campanella’s northbound RESTCONF/TAPI API so that the service provision device can submit a high-level request through the first API, and to place the generation unit in communication with Campanella’s southbound TAPI/OpenConfig/NETCONF APIs so that the generated control information is sent to the OLS/transponder controller or devices. This arrangement would have predictably separated the service-facing API from the device-facing API, improved abstraction, allowed external service systems to request optical paths without knowing device-level details, and preserved the established ONOS/ODTN method for configuring optical transmission devices.
Thus, claim 3 would have been obvious.
Claim 4
With respect to claim 4, all limitations of claim 3 are taught by Campanella, Chikushima, Previdi, Lingampalli and Paolucci as discussed above, except wherein Claim 4 further recites that the API control unit is arranged in a web layer, the conversion unit and the generation unit are arranged in an application layer, and the user information storage unit and topology storage unit are arranged in a DB layer.
However, within analogous art, Campanella teaches the web/API layer corresponding to the claimed API control unit because it receives the connectivity request through a Northbound RESTCONF interface.
Campanella states: "Setup of such connectivity will be triggered from a request coming to ONOS Northbound RESTCONF interface of a T-API connectivity service." [Campanella, p. 2, section 1.3]. A RESTCONF/TAPI northbound interface is a web/API-facing layer through which the external OSS/BSS or service provision device accesses the optical path control device.
Campanella also teaches the application-layer optical control logic corresponding to the claimed conversion/generation functionality because the ONOS controller performs topology discovery, decomposes connectivity requests, and generates device-facing calls. Campanella states that ONOS performs "topology discovery" and "point-to-point connectivity setup." [Campanella, p. 1, section 1].
Campanella further states that the request is "broken down by ONOS to a rest call containing a connectivity-service object from TAPI to the OLS and two requests modifying port state, power and frequency on the transponder line side." [Campanella, p. 2, section 1.3].
Chikushima teaches the database layer corresponding to user information storage and service/network/topology storage.
Chikushima states that the resource reservation apparatus is connected to "a user database management unit 1, a data database management unit 2, an application database management unit 3, a computer database management unit 4, a storage database
management unit 5, and a network database management unit 6." [Chikushima, p. 3, Description of Embodiments].
Chikushima further states that the service database management unit stores correspondence/access-method tables for the database management units. [Chikushima, p. 3, Description of Embodiments].
Paolucci further teaches arranging topology and traffic-engineering information in a database used by network applications.
Paolucci states: "An Open Network Database (ONDB) is proposed as a novel and independent network element storing YANG-defined TE information of heterogeneous network segments having limited visibility of each other (e.g., areas, layers, domains)." [Paolucci, p. 1, Introduction].
Paolucci further states: "The proposed ONDB is a multi-table database which may be populated by different entities. In particular, the ONDB stores the Traffic Engineering information of each layer, populated by the related controller." [Paolucci, p. 3, section III].
Paolucci also teaches that applications read the database and trigger controller actions. Paolucci states: "NetAPPs have the rights to perform read access to the ONDB" and that "each NetAPP runs dedicated set of queries in order to correlate specific inter-layer information."
Paolucci further states that, once results are retrieved, "NetAPPs trigger the related multi-layer procedures by sending proper list of actions towards the layer controllers." [Paolucci, p. 3, section III].
Accordingly, Campanella teaches the API/web layer and the application/control logic layer; Chikushima teaches the user/service/network database management/storage units; and Paolucci teaches a database layer storing topology/traffic-engineering information used by applications to trigger network-control actions. Applying these teachings to the claim 3 device yields the claimed arrangement in which the API control unit is in a web/API layer, the conversion and generation logic is in an application/control layer, and user/topology data is in a database layer.
The claim does not require the prior art to use the exact labels “web layer,” “application layer,” and “DB layer”; rather, the claim requires the functional placement of the API control unit, conversion/generation logic, and storage units. The cited combination expressly teaches those functional placements: Campanella’s RESTCONF/TAPI northbound interface performs the external API/web-facing function, Campanella’s ONOS controller performs the request-processing and control-generation application logic, and Chikushima’s user/service/network database management units and Paolucci’s ONDB perform the persistent DB-layer storage and query functions. Thus, even where the references use network-controller terminology rather than the exact words of claim 4, the same three-layer arrangement is taught or at least would have been obvious to implement.
One of ordinary skill in the art would have been motivated to arrange the claim 3 system in the claimed three-layer form because the cited references already disclose the natural separation of external API handling, control/application logic, and persistent user/topology data. Campanella’s northbound RESTCONF/TAPI interface is the external web/API-facing entry point
for service requests, while its ONOS controller performs application-level decomposition, topology discovery, and generation of device-control calls. Chikushima separates the core/control functions from user, service, and network database management units. Paolucci teaches an independent open network database queried by network applications to trigger control actions. It would have been an obvious and predictable implementation choice to keep the RESTCONF/TAPI interface at the web/API layer, place the conversion and generation logic in the application layer where service request processing and optical path computation occur, and
place user/topology information in the DB layer where persistent endpoint, topology, and traffic-engineering data can be stored and queried. This arrangement would improve modularity, scalability, maintainability, security separation, and the ability to update user/topology data without changing the API entry point or application logic.
Therefore, claim 4 would have been obvious.
It is noted that any citations to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammed Abdelraheem, whose telephone number is (571) 272-0656. The examiner can normally be reached Monday–Thursday.
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, David Payne, can be reached at (571) 272-3024. 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.
/MOHAMMED ABDELRAHEEM/Examiner, Art Unit 2635
/DAVID C PAYNE/Supervisory Patent Examiner, Art Unit 2635
Prosecution Insights