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
Claim Status
Claims 1-20 are pending in this application and are under examination in this Office Action. No claims have been allowed.
Specification
The disclosure is objected to because of the following informalities. Appropriate correction is required. The specification should be amended in accordance with 37 CFR 1.121(b), without introduction of new matter.
Paragraph [0005]
recites “wavelength selectable switch (WSS),” whereas the remainder of the disclosure, including Clauses 2, 9, and 16, paragraph [0071], and claims 2, 9, and 16, consistently uses “wavelength selective switch (WSS).” The terminology should be made consistent so that the same optical component is identified in full, clear, concise, and exact terms.
Paragraphs [0029]-[0031]
set forth Clauses 18-20 using the construction “wherein, the one or more instructions that …, cause the at least one processor to.” The comma immediately following “wherein” is grammatically unnecessary, and the comma immediately before the predicate “cause the at least one processor to” separates the grammatical subject from its predicate. The punctuation should be corrected consistently with the corresponding claims.
Paragraph [0077]
recites, near the end of the paragraph, “channel noise, and/or interference of a channel, data associated ).” The terminal phrase “data associated” is incomplete and does not identify what the data are associated with. Applicant is required to complete, delete, or otherwise correct the fragment so that the intended disclosure is stated clearly and grammatically.
Paragraph [0080]
recites “OCM data OCPM data, raw spectrum data, etc.” The wording omits punctuation and/or a conjunction between “OCM data” and “OCPM data.” Applicant is required to correct or clarify the intended relationship between the two data types.
The above examples are not necessarily exhaustive. The entire specification should be reviewed carefully and amended for grammatical and terminological consistency. Any amendment to the specification must comply with 35 U.S.C. 132(a) and 37 CFR 1.121 and may not introduce new matter.
Claim Objections
Claims 18-20 are objected to under 37 CFR 1.75(d)(1) because of the following informalities. Appropriate correction is required.
Regarding claims 18-20,
each claim recites the construction “wherein, the one or more instructions that …, cause the at least one processor to.” The comma immediately following “wherein” is grammatically unnecessary, and the comma immediately before “cause the at least one processor to” separates the grammatical subject (“the one or more instructions that …”) from its predicate (“cause”). The intended relationship is nevertheless reasonably ascertainable from claim 15 and the corresponding disclosure, and the issue is therefore treated as a minor claim informality rather than as indefiniteness under 35 U.S.C. 112(b). Applicant should correct the punctuation so that the additional limitations are stated clearly and consistently. Appropriate correction is required.
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.
The key to supporting a rejection under 35 U.S.C. § 103 is a clear articulation of the reason or reasons why the claimed invention would have been obvious, with an articulated reasoning having a rational underpinning. The analysis below identifies the teachings relied upon for each limitation and states a claim-specific reason for the proposed combination.
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).
For purposes of the prior-art analysis, the phrase “containerize the data ... according to a characteristic of the data” is read consistently with Applicant’s own disclosure, which states that a characteristic may include a tap point, channel, or OCM output classification, and that containerizing may be performed by storing a portion of the data in a container or specific location of a data structure mapped to that characteristic. [Applicant specification, ¶¶ [0068]-[0069], pp. 16-17]. This construction is used only to identify what the claims reasonably encompass; the Applicant’s disclosure is not relied upon as prior art.
Claims 1 and 8 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton (US 2005/0089027 A1) in view of Naik et al. (US 2022/0400052 A1).
Claim 1
Colton teaches an intelligent optical data-switching and management system in which optical performance data are acquired at selectable physical access/tap points of an optical network, supplied to a performance-management processor, accumulated in tap-point-specific databases, and made available through networked software clients and management applications. The disclosure therefore addresses the same technological setting as claim 1: processor-based acquisition, organization, storage, and external use of optical-network monitoring data.
More particularly, Colton teaches: “The Performance Manager 1000 uses the OPM circuit pack 216 to perform OSNR, power, and wavelength classification measurements on composite DWDM signals at selected tap points in the IOS 60. These access points are at composite DWDM TPM ingress and egress signal points, and the OPM 216 can perform the measurements on any wavelength within the composite DWDM signal. The Performance Manager 1000 supports two measurement modes: scanned (background exercise) and directed (camp-on).” [Colton, Performance Management; FIGS. 40-41 and 53-54; ¶ [1256]].
Colton further expressly teaches organization and storage by the selected access point: “FIG. 54 is a data flow diagram of the OPM 216 optical measurements. After initialization, the PFM 1000 runs in background mode, sequentially scanning through all equipped access points of the IOS 60 and compiling a database for each equipped access point over time. The user can reconfigure the desired measurement points and the scanning interval between measurement sets through an SNMP request.” [Colton, Performance Management; FIG. 54; ¶ [1257]].
Colton also expressly teaches that the optical-performance data are provided to users and requested by management software: “These results are periodically reported to the SDS 204 where GUI displays of the data are provided to the user. Also, the SDS 204 may request power measurements at specific access points.” [Colton, ¶ [1249]; FIG. 53]. Colton further teaches client-side access to the performance applications: “Network operators access the on-line server configuration, connection, topology, fault, and performance applications from client devices using the graphical user interface (GUI) display 1600.” [Colton, ¶ [0321]; FIG. 9].
And, for a particular optical-monitoring data source, Colton teaches on-demand transfer to the Services Delivery System (SDS): “On request from SDS 204 the PFM 1000 can command OPM 216 to read the optical spectrum for a specific tap point on a TPM circuit pack 121 and send response back to SDS 204. TCP is used to forward the spectrum data from PFM 1000 to SDS 204.” [Colton, Performance Management; FIG. 54; ¶ [1257]].
Accordingly, Colton teaches the claim limitation “receive data associated with an optical communications network” because the Performance Manager receives OSNR, power, wavelength-classification, and spectrum measurements from the OPM at optical-network access points.
Colton also teaches, under the above broadest reasonable construction, “containerize the data ... according to a characteristic of the data to provide a data structure that includes containerized data,” because the optical measurements are segregated and accumulated in a respective database for each equipped access point; the identity of the access point is the characteristic according to which the data are organized.
Colton further teaches “provide access to the data structure for one or more application sessions” through its fully distributed Java applications, GUI/client functions, SDS requests, SNMP requests, and TCP delivery of requested spectrum data.
Colton, however, does not use Applicant’s exact “containerize” terminology and does not expressly describe the software organization in the more modern terminology of partitioning system state by data/service type and publishing that stored information to subscribed software clients.
Naik provides these missing explicit teachings in an optical-network-element management architecture.
Naik teaches: “the core framework microservice 140a is responsible for and manages inter-service message brokering and state management. The core framework microservice 140a may include a messaging service and a storage. In some embodiments, the messaging service may be gRPC. In some embodiments, the storage is a datastore, such as a data lake, a database, a block of memory, and/or the like. In one embodiment, the core framework microservice 140a may maintain the system state. System state information may be partitioned by configuration or operational data and service type.” [Naik, ¶ [0079]].
Naik further teaches external subscribed access to the organized data: “the northbound microservice 140d is an external software client that is responsible for configuration and monitoring services being managed by the core framework microservice 140a. For example, in some embodiments, the northbound microservice 140d may collect, e.g., via the core framework microservice 140a, and aggregate data collected by one or more device microservice 140b from the hardware entity microservice 140c.” [Naik, ¶ [0085]].
Naik additionally teaches persistent publication and streaming to subscribed application-level services: “if the signal includes operational data (e.g., the signal is an operational signal), then publishing the operational data comprises publishing the operational data to any service that has subscribed to the operational data type. In some embodiments, publishing the operational data includes publishing the data to any service that has subscribed to operational data from a particular embedded device and/or node.” [Naik, ¶ [0109]].
“streaming the encoded data may include, for example, streaming the encoded data to one or more microservice 140 subscribed to the data stream. Streaming the encoded data may be a long-lived subscription.” [Naik, ¶ [0120]].
Taken together, the references account for every limitation of claim 1.
Colton supplies the optical-network source, optical tap/access-point measurements, processor-based performance manager, per-access-point database organization, and delivery to distributed applications.
Naik supplies explicit partitioning of stored system state by operational/configuration data and service type, a datastore/database, event-driven publication, and long-lived subscribed external software clients. The combination therefore yields at least one processor receiving optical-network data, organizing/storing that data in a data structure according to a data characteristic, and providing application sessions access to that organized data structure.
One of ordinary skill in the art would have been motivated to combine Colton with Naik because both references address management of operating information produced by optical-network equipment and both solve the same engineering problem of making device/network state available to higher-level management software.
Colton already accumulates measurements by optical access point and serves them to external management software. Naik teaches a known, later-developed software architecture for making the same class of operational state scalable and consumable: partition the state by data/service type in a datastore and publish or stream it to subscribed northbound applications. Applying that known data-management architecture to Colton would have preserved the source and meaning of Colton’s optical measurements while predictably improving organization, extensibility, and access by multiple software consumers.
The combination would not require a change in Colton’s principle of operation. The optical access points, OPM measurements, and Performance Manager remain intact; only the known software/data organization by which the measurements are stored and exposed is implemented using Naik’s partitioned datastore and publish/subscribe framework.
A person of ordinary skill would have had a reasonable expectation of success because both systems already employ processors, databases/datastores, network interfaces, and application-layer software, and Naik expressly contemplates optical links, optical power, embedded optical devices, and northbound monitoring clients. The proposed modification therefore represents the predictable use of known data-management techniques in the same optical-network-management field, with each element performing its known function.
Claim 1 is therefore unpatentable under 35 U.S.C. § 103.
Claim 8
Claim 8 recites the method counterpart of claim 1.
The same Colton and Naik teachings apply to the claimed method steps, and the method is performed by the processors and software components expressly disclosed in those references.
Colton teaches the receiving step through the Performance Manager/OPM arrangement: “The Performance Manager 1000 uses the OPM circuit pack 216 to perform OSNR, power, and wavelength classification measurements on composite DWDM signals at selected tap points in the IOS 60. These access points are at composite DWDM TPM ingress and egress signal points, and the OPM 216 can perform the measurements on any wavelength within the composite DWDM signal.” [Colton, Performance Management; FIGS. 40-41, 53-54; ¶ [1256]].
Colton teaches the claimed organizing/containerizing operation, under Applicant’s stated breadth, by repeatedly storing data according to its access-point characteristic: “After initialization, the PFM 1000 runs in background mode, sequentially scanning through all equipped access points of the IOS 60 and compiling a database for each equipped access point over time.” [Colton, Performance Management; FIG. 54; ¶ [1257]].
Naik reinforces that the storage is deliberately organized according to data characteristics: “System state information may be partitioned by configuration or operational data and service type.” [Naik, ¶ [0079]].
Naik teaches application-level access as a continuing subscribed data relationship: “streaming the encoded data may include, for example, streaming the encoded data to one or more microservice 140 subscribed to the data stream. Streaming the encoded data may be a long-lived subscription.” [Naik, ¶ [0120]].
Thus, “receiving, with at least one processor, data associated with an optical communications network” is taught by Colton’s processor-controlled OPM/Performance Manager acquisition of optical data; “containerizing, with at least one processor, the data ... according to a characteristic ... to provide a data structure” is taught by Colton’s database-per-access-point organization as expressly reinforced by Naik’s partitioning by operational/configuration data and service type; and “providing, with at least one processor, access ... for one or more application sessions” is taught by Colton’s distributed applications/SDS and Naik’s subscribed external northbound clients and long-lived data streams.
One of ordinary skill in the art would have combined these teachings for the same reasons stated for claim 1, but applied to the recited method: Colton already performs the optical-data acquisition and per-source data accumulation, while Naik provides a known process for partitioning and publishing stored operational data to external subscribers. Performing those known software operations on Colton’s optical measurements would have been a routine and predictable implementation of a scalable optical telemetry/management workflow, would not have altered the underlying physical optical monitoring, and would have had a reasonable expectation of success using conventional processors, memory, databases, and network messaging.
Claim 8 is therefore unpatentable under 35 U.S.C. § 103.
Claims 2 and 9 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., and further in view of Liu et al. (US 2010/0202777 A1).
Claim 2
With respect to claim 2, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 2 additionally requires providing a power balancing command to a wavelength selective switch (WSS).
However, within analogous art, Liu expressly teaches this functionality in a ROADM channel-power-control architecture.
Liu states: “A WSS 130 for each network output is used to combine the add wavelengths from a multiplexer 132 and wavelengths from the input network degrees 134. WSS 130 also provides per-channel variable attenuation. An optical channel monitor 136 at the output of the WSS measures the power of each wavelength, and this data is used to adjust the attenuation of the WSS to balance the channel powers.” [Liu, ¶ [0005]; FIG. 1].
Liu further identifies the processor that generates the control outputs: “A control loop processor (CLP) 146, shown as a single element but alternatively configured in multiple specific individual elements, executes control loop functionality based in part on inputs 148 and the channel power control loop (CPCL) configuration, for example computer code, which results in outputs 150 used to adjust or modify specific ROADM Node 100 elements and/or overall performance or functionality.” [Liu, ¶ [0005]; FIG. 1].
These passages expressly teach the added limitation of claim 2: channel-power measurements from an OCM are processed in a control loop to generate outputs/commands that adjust the attenuation of a WSS so that the wavelength-channel powers are balanced.
The command need not bear Applicant’s exact label “power balancing command”; the disclosed control output performs that claimed function by commanding WSS attenuation changes based on measured channel power.
One of ordinary skill in the art would have been motivated to add Liu’s WSS power-balancing control to the Colton/Naik data-management system because Colton already acquires optical power and wavelength measurements through an optical performance monitor, while Liu expressly teaches a known use for those same measurements: closed-loop adjustment of WSS per-channel attenuation to balance optical power. Using the optical monitoring data both for management/application access and as the input to a WSS power-control loop would have reduced duplicative sensing, maintained a single consistent measurement source, and shortened the path between measurement and corrective action.
The modification would have been no more than combining familiar optical-network functions according to their established roles. The OPM/OCM measures channel power; the processor evaluates those measurements; and the WSS receives attenuation-control outputs. Liu expressly discloses this chain, including the OCM, control-loop processor, WSS, and target-power behavior.
A person of ordinary skill therefore would have had a reasonable expectation that the combination would operate successfully without changing the basic optical-monitoring or data-access functions taught by Colton and Naik.
The result is the predictable integrated optical monitoring and power-balancing system recited by the claim.
Claim 9
With respect to claim 9, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 9 additionally requires providing a power balancing command to a wavelength selective switch (WSS).
However, within analogous art, Liu expressly teaches this functionality in a ROADM channel-power-control architecture.
Liu states: “A WSS 130 for each network output is used to combine the add wavelengths from a multiplexer 132 and wavelengths from the input network degrees 134. WSS 130 also provides per-channel variable attenuation. An optical channel monitor 136 at the output of the WSS measures the power of each wavelength, and this data is used to adjust the attenuation of the WSS to balance the channel powers.” [Liu, ¶ [0005]; FIG. 1].
Liu further identifies the processor that generates the control outputs: “A control loop processor (CLP) 146, shown as a single element but alternatively configured in multiple specific individual elements, executes control loop functionality based in part on inputs 148 and the channel power control loop (CPCL) configuration, for example computer code, which results in outputs 150 used to adjust or modify specific ROADM Node 100 elements and/or overall performance or functionality.” [Liu, ¶ [0005]; FIG. 1].
These passages expressly teach the added limitation of claim 9: channel-power measurements from an OCM are processed in a control loop to generate outputs/commands that adjust the attenuation of a WSS so that the wavelength-channel powers are balanced. The command need not bear Applicant’s exact label “power balancing command”; the disclosed control output performs that claimed function by commanding WSS attenuation changes based on measured channel power.
One of ordinary skill in the art would have been motivated to add Liu’s WSS power-balancing control to the Colton/Naik data-management system because Colton already acquires optical power and wavelength measurements through an optical performance monitor, while Liu expressly teaches a known use for those same measurements: closed-loop adjustment of WSS per-channel attenuation to balance optical power.
Using the optical monitoring data both for management/application access and as the input to a WSS power-control loop would have reduced duplicative sensing, maintained a single consistent measurement source, and shortened the path between measurement and corrective action.
The modification would have been no more than combining familiar optical-network functions according to their established roles.
The OPM/OCM measures channel power; the processor evaluates those measurements; and the WSS receives attenuation-control outputs.
Liu expressly discloses this chain, including the OCM, control-loop processor, WSS, and target-power behavior.
A person of ordinary skill therefore would have had a reasonable expectation that the combination would operate successfully without changing the basic optical-monitoring or data-access functions taught by Colton and Naik.
The result is the predictable integrated optical monitoring and power-balancing system recited by the claim.
Claims 3 and 10 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., and further in view of Frisken et al. (US 2014/0376909 A1).
Claim 3
With respect to claim 3, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 3 additionally requires storing the data structure in an on-board memory location of an optical channel monitoring (OCM) device. However, within analogous art, Frisken expressly discloses local database storage and processing physically integrated with an OCM.
Frisken teaches: “The data received by photodiodes 22, 23 and 24 is optionally able to be stored in an internal database 26 and processed by processor 27. Database 26 is also configured for storing calibration data to be applied to the received signal data. Processor 27 may also be configured to apply a calibration to outgoing signal data being ported to an external device. In other embodiments, this storage and processing of data is performed externally to OCM 1. Database 26 and processor 27 are disposed on an integrated circuit (not shown) along with other electronic components such as control electronics for the MEMs mirror and components for powering OCM 1.” [Frisken, ¶ [0057]; FIGS. 1-5].
This is direct evidence of the added structural/storage limitation of claim 3.
Frisken do not merely describe a remote network database; they expressly identify an “internal database 26” for measured optical data and place both that database and processor on an integrated circuit with the OCM electronics. Under the ordinary meaning of on-board memory, such internal integrated memory is an on-board memory location of the OCM device.
One of ordinary skill in the art would have been motivated to implement the Colton/Naik organized data structure in the OCM-local memory arrangement taught by Frisken because Colton obtains the data from an optical performance monitor and Frisken teaches that optical-monitoring data can be retained and processed locally within the OCM itself. Localizing at least the active data structure at the OCM would predictably reduce repeated transfer of high-volume spectrum/power data over a backplane or management network, permit faster access by local control software, and preserve recent monitoring data near its source.
The modification would not have changed the information stored or its higher-level access. It would only select a known physical memory placement for the database/data structure. Frisken expressly contemplates both internal and external storage, showing that memory location was an implementation choice in OCM design. A person of ordinary skill would therefore have had a reasonable expectation of success in storing Colton/Naik’s organized optical-monitoring data in an OCM-local memory or database while retaining network access to that data. Claim 3 is therefore unpatentable under 35 U.S.C. § 103.
Claim 10
With respect to claim 10, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 10 additionally requires storing the data structure in an on-board memory location of an optical channel monitoring (OCM) device. However, within analogous art, Frisken expressly discloses local database storage and processing physically integrated with an OCM.
Frisken teaches: “The data received by photodiodes 22, 23 and 24 is optionally able to be stored in an internal database 26 and processed by processor 27. Database 26 is also configured for storing calibration data to be applied to the received signal data. Processor 27 may also be configured to apply a calibration to outgoing signal data being ported to an external device. In other embodiments, this storage and processing of data is performed externally to OCM 1. Database 26 and processor 27 are disposed on an integrated circuit (not shown) along with other electronic components such as control electronics for the MEMs mirror and components for powering OCM 1.” [Frisken, ¶ [0057]; FIGS. 1-5].
This is direct evidence of the added structural/storage limitation of claim 10.
Frisken do not merely describe a remote network database; they expressly identify an “internal database 26” for measured optical data and place both that database and processor on an integrated circuit with the OCM electronics. Under the ordinary meaning of on-board memory, such internal integrated memory is an on-board memory location of the OCM device.
One of ordinary skill in the art would have been motivated to implement the Colton/Naik organized data structure in the OCM-local memory arrangement taught by Frisken because Colton obtains the data from an optical performance monitor and Frisken teaches that optical-monitoring data can be retained and processed locally within the OCM itself. Localizing at least the active data structure at the OCM would predictably reduce repeated transfer of high-volume spectrum/power data over a backplane or management network, permit faster access by local control software, and preserve recent monitoring data near its source.
The modification would not have changed the information stored or its higher-level access. It would only select a known physical memory placement for the database/data structure. Frisken expressly contemplates both internal and external storage, showing that memory location was an implementation choice in OCM design.
A person of ordinary skill would therefore have had a reasonable expectation of success in storing Colton/Naik’s organized optical-monitoring data in an OCM-local memory or database while retaining network access to that data.
Claim 10 is therefore unpatentable under 35 U.S.C. § 103.
Claims 4 and 11 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., as applied to claims 1 and 8 above, and further in view of Gagnon et al. (US 2012/0042164 A1).
Claim 4
With respect to claim 4, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 4 further requires determining first and second tap points for respective first and second portions of data and storing the portions in respective first and second locations of the data structure associated with the corresponding tap points.
However, within analogous art, Gagnon expressly teaches receiving separate portions of network data from separate tap points and maintaining the portions in separate locations/queues of a data structure.
Gagnon teaches in the Summary: “a method may include receiving, via a first network tap point included by a first network segment, a first portion of network communication data between a client computing device and a server computing device. The method may include receiving, via a second network tap point included by a second network segment, a second portion of network communication data between the client computing device and the server computing device.” [Gagnon, ¶ [0010]].
Gagnon then discloses a data structure with source-specific locations: “FIG. 3b is a block diagram of an example and less preferred embodiment of a data structure 300 in accordance with the disclosed subject matter. In various embodiments, the tap point analyzer device or apparatus may store, at least in a temporary fashion, data objects or sub-portions from the monitored network communication between the client computing device and server computing device.” [Gagnon, ¶ [0104]; FIG. 3B].
“In the illustrated embodiment, the device or apparatus may store data objects from a first network segment (e.g., the intranet, client-side, etc.) in a queue 302. In various embodiments, the device or apparatus may store data objects from a second network segment (e.g., the intranet, server-side, etc.) in a queue 304. In various embodiments, if additional network segments (e.g., a third or fourth network segment, etc.) are employed, respective queues may also be employed.” [Gagnon, ¶ [0105]; FIG. 3B].
The added limitation of claim 4 is therefore expressly accounted for by the combination. Colton already scans multiple optical access/tap points and compiles a database for each equipped access point. Gagnon makes explicit the source-indexed data-structure arrangement: data received from a first tap/source segment is stored in a first queue and data from a second tap/source segment is stored in a second queue.
Thus, the first and second data portions remain associated with their first and second tap-point origins through corresponding data-structure locations.
One of ordinary skill in the art would have been motivated to use Gagnon’s separate source-indexed queues/locations in Colton’s optical performance database because provenance is important when measurements are gathered from numerous monitoring points. Keeping measurements from different tap points in correspondingly identified storage locations makes it possible to reconstruct where a measurement was made, compare upstream/downstream behavior, correlate events, and diagnose the segment at which a fault or degradation begins. These are routine management objectives in the network-monitoring art.
The proposed combination is particularly natural because Colton already provides the functional premise of multiple optical access points and a database for each equipped access point while Gagnon provides the explicit data-structure mechanics of separate queues for data originating from separate tap/segment locations. Implementing those known storage mechanics in Colton/Naik would merely formalize the existing per-access-point organization and would predictably preserve source identity without changing the optical measurement process.
A skilled artisan would have had a reasonable expectation of success because the change is a software/data-structure organization applied to already digitized monitoring data.
Claim 4 is therefore unpatentable under 35 U.S.C. § 103.
Claim 11
With respect to claim 11, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 11 further requires determining first and second tap points for respective first and second portions of data and storing the portions in respective first and second locations of the data structure associated with the corresponding tap points. However, within analogous art, Gagnon expressly teaches receiving separate portions of network data from separate tap points and maintaining the portions in separate locations/queues of a data structure.
Gagnon teaches in the Summary: “a method may include receiving, via a first network tap point included by a first network segment, a first portion of network communication data between a client computing device and a server computing device. The method may include receiving, via a second network tap point included by a second network segment, a second portion of network communication data between the client computing device and the server computing device.” [Gagnon, ¶ [0010]].
Gagnon then discloses a data structure with source-specific locations: “FIG. 3b is a block diagram of an example and less preferred embodiment of a data structure 300 in accordance with the disclosed subject matter. In various embodiments, the tap point analyzer device or apparatus may store, at least in a temporary fashion, data objects or sub-portions from the monitored network communication between the client computing device and server computing device.” [Gagnon, ¶ [0104]; FIG. 3B].
“In the illustrated embodiment, the device or apparatus may store data objects from a first network segment (e.g., the intranet, client-side, etc.) in a queue 302. In various embodiments, the device or apparatus may store data objects from a second network segment (e.g., the intranet, server-side, etc.) in a queue 304. In various embodiments, if additional network segments (e.g., a third or fourth network segment, etc.) are employed, respective queues may also be employed.” [Gagnon, ¶ [0105]; FIG. 3B].
The added limitation of claim 11 is therefore expressly accounted for by the combination.
Colton already scans multiple optical access/tap points and compiles a database for each equipped access point. Gagnon makes explicit the source-indexed data-structure arrangement: data received from a first tap/source segment is stored in a first queue and data from a second tap/source segment is stored in a second queue.
Thus, the first and second data portions remain associated with their first and second tap-point origins through corresponding data-structure locations.
One of ordinary skill in the art would have been motivated to use Gagnon’s separate source-indexed queues/locations in Colton’s optical performance database because provenance is important when measurements are gathered from numerous monitoring points. Keeping measurements from different tap points in correspondingly identified storage locations makes it possible to reconstruct where a measurement was made, compare upstream/downstream behavior, correlate events, and diagnose the segment at which a fault or degradation begins. These are routine management objectives in the network-monitoring art.
The proposed combination is particularly natural because Colton already provides the functional premise of multiple optical access points and a database for each equipped access point while Gagnon provides the explicit data-structure mechanics of separate queues for data originating from separate tap/segment locations.
Implementing those known storage mechanics in Colton/Naik would merely formalize the existing per-access-point organization and would predictably preserve source identity without changing the optical measurement process.
A skilled artisan would have had a reasonable expectation of success because the change is a software/data-structure organization applied to already digitized monitoring data.
Claim 11 is therefore unpatentable under 35 U.S.C. § 103.
Claims 5 and 12 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., as applied to claims 1 and 8 above, and further in view of Wensink et al. (US 6,807,523 B1).
Claim 5
With respect to claim 5, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 5 additionally requires providing access to the data structure for application sessions via an Ethernet Bus.
However, within analogous art, Wensink expressly teaches an Ethernet bus in an optical-network-node environment and uses it to exchange optical-network control and status data between node processors and a workstation.
Wensink teaches: “Each of the nodes for which emulation processes may be utilized also includes an EBEM (Ethernet bus extender module) or equivalent. For example, the west terminal 20, OLA 30, and east terminal 40 include EBEMs 24, 34, 44 respectively connected to the backplanes 26, 36, 46. The EBEMs capture data present on the respective back planes and forward such data to the workstation 10 via an Ethernet connection. The EBEMs also provide data from the workstation 10 to the NCPs. In other words, the EBEMs function as a data bridge between the back plane bus 26, 36, 46 and an Ethernet bus to which the workstation 10 is connected such that data may be exchanged between the workstation 10 and the NCPs 22, 32, 42.” [Wensink, col. 8; FIG. 1B].
Wensink further teaches Ethernet switching/routing between node processors and the workstation: “The EBEMs shown in FIG. 1b may also function as a Switch (e.g. an Ethernet Switch) Such that data from and to the NCPs 22, 32, 42 are routed through EBEM 24 to workstation 10 and vice versa.” [Wensink, col. 9].
These disclosures expressly teach the “Ethernet Bus” access mechanism of claim 5: a workstation/software environment exchanges optical-node data with nodal control processors over an Ethernet bus, with a bridging module and, optionally, Ethernet switching. The claim does not require a particular Ethernet speed, frame format, or bus topology beyond access “via an Ethernet Bus,” all of which is met or rendered obvious by this disclosure.
One of ordinary skill in the art would have been motivated to use Wensink’s Ethernet-bus interconnect to provide application access to the Colton/Naik data structure because Ethernet was a known, standardized, high-availability interface already used inside optical communication equipment for management, control, and workstation communication.
Colton itself employs external and internal LANs, SNMP, TCP/UDP, and distributed software. Substituting or exposing the data structure through the expressly taught Ethernet bus of Wensink would therefore have been a straightforward selection of a known communication transport for the same type of optical management data.
The motivation is technical and implementation-specific: an Ethernet bus provides addressable data communication between processors and software clients, decouples the producer of optical measurements from the application consuming them, and permits multiple management/application processes to share a standard communications fabric. Because the references already operate with digital optical-network data and conventional Ethernet/TCP/IP software stacks, a skilled artisan would have reasonably expected the combination to work using ordinary interface/driver logic, without modifying the underlying optical monitoring.
Claim 5 is therefore unpatentable under 35 U.S.C. § 103.
Claim 12
With respect to claim 12, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 12 additionally requires providing access to the data structure for application sessions via an Ethernet Bus.
However, within analogous art, Wensink expressly teaches an Ethernet bus in an optical-network-node environment and uses it to exchange optical-network control and status data between node processors and a workstation.
Wensink teaches: “Each of the nodes for which emulation processes may be utilized also includes an EBEM (Ethernet bus extender module) or equivalent. For example, the west terminal 20, OLA 30, and east terminal 40 include EBEMs 24, 34, 44 respectively connected to the backplanes 26, 36, 46. The EBEMs capture data present on the respective back planes and forward such data to the workstation 10 via an Ethernet connection. The EBEMs also provide data from the workstation 10 to the NCPs. In other words, the EBEMs function as a data bridge between the back plane bus 26, 36, 46 and an Ethernet bus to which the workstation 10 is connected such that data may be exchanged between the workstation 10 and the NCPs 22, 32, 42.” [Wensink, col. 8; FIG. 1B].
Wensink further teaches Ethernet switching/routing between node processors and the workstation: “The EBEMs shown in FIG. 1b may also function as a Switch (e.g. an Ethernet Switch) Such that data from and to the NCPs 22, 32, 42 are routed through EBEM 24 to workstation 10 and vice versa.” [Wensink, col. 9].
These disclosures expressly teach the “Ethernet Bus” access mechanism of claim 12: a workstation/software environment exchanges optical-node data with nodal control processors over an Ethernet bus, with a bridging module and, optionally, Ethernet switching.
The claim does not require a particular Ethernet speed, frame format, or bus topology beyond access “via an Ethernet Bus,” all of which is met or rendered obvious by this disclosure.
One of ordinary skill in the art would have been motivated to use Wensink’s Ethernet-bus interconnect to provide application access to the Colton/Naik data structure because Ethernet was a known, standardized, high-availability interface already used inside optical communication equipment for management, control, and workstation communication.
Colton itself employs external and internal LANs, SNMP, TCP/UDP, and distributed software. Substituting or exposing the data structure through the expressly taught Ethernet bus of Wensink would therefore have been a straightforward selection of a known communication transport for the same type of optical management data.
The motivation is technical and implementation-specific: an Ethernet bus provides addressable data communication between processors and software clients, decouples the producer of optical measurements from the application consuming them, and permits multiple management/application processes to share a standard communications fabric.
Because the references already operate with digital optical-network data and conventional Ethernet/TCP/IP software stacks, a skilled artisan would have reasonably expected the combination to work using ordinary interface/driver logic, without modifying the underlying optical monitoring.
Claim 12 is therefore unpatentable under 35 U.S.C. § 103.
Claims 6 and 13 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., as applied to claims 1 and 8 above, and further in view of Funk (US 2002/0122219 A1).
Claim 6
With respect to claim 6, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 6 additionally requires receiving the optical-network data through at least one of an optical supervisory channel (OSC), a remote management channel (RMC), or any combination thereof. Because the claim is written in the alternative, a teaching of an OSC alone satisfies this limitation.
However, within analogous art, Funk expressly teaches management/status information carried through an optical supervisory channel across optical network elements.
Funk teaches: “The management network controls a channel wavelength called the optical supervisory channel (OSC) which may be transmitted over the network via the Internet protocol (IP). This OSC is usually an out-of-band wavelength, i.e. a wavelength outside the telecommunication wavelength band, which will get transmitted through all of the network elements.” [Funk, ¶ [0003]].
Funk further explains the management content carried in the optical network: “Those facilities primarily relate to the management of the components within the optical network and the distribution and display of information such as alarm reports, audit logs, alarm logs, Status reports and control messages.” [Funk, ¶ [0002]].
The recited alternative “OSC” is therefore expressly present. Funk teaches an out-of-band optical management wavelength, carried through network elements using IP, that transports network-management information such as status, alarms, logs, and control messages. Such information is “data associated with the optical communications network” within the breadth of claim 6.
One of ordinary skill in the art would have been motivated to receive at least some of the Colton/Naik monitoring/management data over Funk’s OSC because the OSC is specifically provided as a separate channel for optical-network management information. A separate supervisory path allows status and management information to remain reachable even when ordinary client traffic paths or external management paths are unavailable or impaired, and it avoids consuming payload-band resources. This use directly serves the reliability and remote-management goals of the combined optical data-management system.
The proposed use would have been predictable because Funk teaches IP-based OSC transport through all network elements, while Colton and Naik already use IP/network interfaces and processor-based management software. The data need only be received through the supervisory channel before being stored/organized in the same data structure. No change to the claimed containerization or application-access functions is required.
A person of ordinary skill therefore would have had a reasonable expectation of success.
Claim 6 is unpatentable under 35 U.S.C. § 103.
Claim 13
With respect to claim 13, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 13 additionally requires receiving the optical-network data through at least one of an optical supervisory channel (OSC), a remote management channel (RMC), or any combination thereof. Because the claim is written in the alternative, a teaching of an OSC alone satisfies this limitation.
However, within analogous art, Funk expressly teaches management/status information carried through an optical supervisory channel across optical network elements.
Funk teaches: “The management network controls a channel wavelength called the optical supervisory channel (OSC) which may be transmitted over the network via the Internet protocol (IP). This OSC is usually an out-of-band wavelength, i.e. a wavelength outside the telecommunication wavelength band, which will get transmitted through all of the network elements.” [Funk, ¶ [0003]].
Funk further explains the management content carried in the optical network: “Those facilities primarily relate to the management of the components within the optical network and the distribution and display of information such as alarm reports, audit logs, alarm logs, Status reports and control messages.” [Funk, ¶ [0002]].
The recited alternative “OSC” is therefore expressly present.
Funk teaches an out-of-band optical management wavelength, carried through network elements using IP, that transports network-management information such as status, alarms, logs, and control messages. Such information is “data associated with the optical communications network” within the breadth of claim 13.
One of ordinary skill in the art would have been motivated to receive at least some of the Colton/Naik monitoring/management data over Funk’s OSC because the OSC is specifically provided as a separate channel for optical-network management information. A separate supervisory path allows status and management information to remain reachable even when ordinary client traffic paths or external management paths are unavailable or impaired, and it avoids consuming payload-band resources. This use directly serves the reliability and remote-management goals of the combined optical data-management system.
The proposed use would have been predictable because Funk teaches IP-based OSC transport through all network elements, while Colton and Naik already use IP/network interfaces and processor-based management software. The data need only be received through the supervisory channel before being stored/organized in the same data structure. No change to the claimed containerization or application-access functions is required.
A person of ordinary skill therefore would have had a reasonable expectation of success.
Claim 13 is unpatentable under 35 U.S.C. § 103.
Claims 7 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., and further in view of Sadasivarao et al. (“High Performance Streaming Telemetry in Optical Transport Networks,” OFC 2018, Tu3D.3) and Shiner et al. (US 2018/0205454 A1).
Claim 7
With respect to claim 7, all limitations of claim 1 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 7 additionally requires transmitting the containerized data to one or more application sessions without interrupting a power balancing control loop.
However, within analogous art, Sadasivarao teaches high-rate push streaming of optical performance-monitoring data specifically in a ROADM environment having power-control loops, while Shiner teaches isolation of application compute resources so application access/processing does not interfere with ongoing optical-module operation.
Sadasivarao expressly ties streaming telemetry to optical power-control loops and a centralized ROADM controller: “In a truly disaggregated OLS optical transport network, open APIs are critical to achieve optical multi-vendor interoperability, specifically, optical power control loops for link turn-up and maintenance. For the optical link turn-up to be accurate, measured Tx/Rx power and other metrics, need to be available to a centralized ROADM network controller (RNC). Streaming PM data at very fine granularity ensures that the RNC power control loops are tighter and the slightest of variations in the measured values are monitored.” [Sadasivarao, Tu3D.3, pp. 1-2].
Sadasivarao further teaches a non-disruptive streaming architecture: “The architecture relies on a fully distributed and asynchronous interaction between different subsystems involved in the streaming functions. The entire streaming framework is designed as a modular software service whose life-cycle can be managed without adversely impacting the network element’s (NE) control or management planes.” [Sadasivarao, Tu3D.3, p. 2].
Sadasivarao additionally states: “The architecture fundamentally employs ‘push’ mechanism, right from the low-level drivers which collect the performance monitoring (PM) data from the data path elements, to the management agents which stream the data out to the collectors. This eliminates any polling cycles and the data is streamed as the measured PM values change.” [Sadasivarao, Tu3D.3, p. 2].
Additionally, within analogous art, Shiner independently teaches resource isolation so external/user applications do not interfere with optical operation: “the compute resources 350 are segmented such that operation of the user defined applications does not interfere with the operation of the optical transceiver 200 by isolating the core resources from the compute resources 350, except through APIs or the like which are tightly controlled. Thus, the compute resources 350 can be dedicated to executing the user defined applications, without affecting the on-going operation of the optical transceiver 200.” [Shiner, ¶ [0033]].
Shiner also teaches application-to-orchestrator data transfer using the isolated resources: “Similarly, the application can push or initiate communication with the orchestrator 390 or other apps that can reside on the same module or other modules. The compute resources 350 can be adapted to access the data via an API and wherein the compute resources 350 are adapted to communicate with the orchestrator 390 via a messaging bus associated with a network element housing the optical module 400.” [Shiner, ¶ [0055]].
The combined teachings meet the functional relationship required by claim 7. Sadasivarao expressly places streaming PM data in a ROADM/RNC power-control-loop setting and designs the distributed asynchronous streaming subsystem so that its lifecycle does not adversely impact the network element’s control or management planes.
Shiner supplies the complementary implementation technique of isolating application compute resources from core optical resources so that user/application activity does not interfere with ongoing optical operation. Applied to the Colton/Naik data structure, the result is transmitting the organized optical PM/monitoring data to application sessions through an asynchronous, isolated software path while the power-balancing control loop continues operating.
One of ordinary skill in the art would have been motivated to combine these teachings because external consumption of high-rate optical PM data can otherwise compete with real-time control for processor cycles, interfaces, locks, and data access.
Sadasivarao expressly identifies push streaming as a means to eliminate polling cycles and make telemetry available while the optical control environment continues to operate; Shiner expressly isolates app execution from core optical functions. A skilled artisan seeking to expose Colton/Naik’s stored optical data to applications without disturbing the control path would have recognized these as complementary, known techniques.
The combination also would have had a reasonable expectation of success. The references do not require changing the power-balancing algorithm; rather, they separate the data-export/application path from the real-time control path. The same measured values can be made available to both, while the control loop retains its normal execution. That is a predictable software-architecture improvement in an optical network element, and it directly addresses the risk of interruption created by synchronous polling or shared resources.
Claim 7 is therefore unpatentable under 35 U.S.C. § 103.
Claim 14
With respect to claim 14, all limitations of claim 8 are taught by Colton and Naik for the detailed reasons set forth above, except wherein claim 14 additionally requires transmitting the containerized data to one or more application sessions without interrupting a power balancing control loop.
However, within analogous art, Sadasivarao teaches high-rate push streaming of optical performance-monitoring data specifically in a ROADM environment having power-control loops, while Shiner teaches isolation of application compute resources so application access/processing does not interfere with ongoing optical-module operation.
Sadasivarao expressly ties streaming telemetry to optical power-control loops and a centralized ROADM controller: “In a truly disaggregated OLS optical transport network, open APIs are critical to achieve optical multi-vendor interoperability, specifically, optical power control loops for link turn-up and maintenance. For the optical link turn-up to be accurate, measured Tx/Rx power and other metrics, need to be available to a centralized ROADM network controller (RNC). Streaming PM data at very fine granularity ensures that the RNC power control loops are tighter and the slightest of variations in the measured values are monitored.” [Sadasivarao, Tu3D.3, pp. 1-2].
Sadasivarao further teaches a non-disruptive streaming architecture: “The architecture relies on a fully distributed and asynchronous interaction between different subsystems involved in the streaming functions. The entire streaming framework is designed as a modular software service whose life-cycle can be managed without adversely impacting the network element’s (NE) control or management planes.” [Sadasivarao, Tu3D.3, p. 2].
Sadasivarao additionally states: “The architecture fundamentally employs ‘push’ mechanism, right from the low-level drivers which collect the performance monitoring (PM) data from the data path elements, to the management agents which stream the data out to the collectors. This eliminates any polling cycles and the data is streamed as the measured PM values change.” [Sadasivarao, Tu3D.3, p. 2].
Shiner independently teaches resource isolation so external/user applications do not interfere with optical operation: “the compute resources 350 are segmented such that operation of the user defined applications does not interfere with the operation of the optical transceiver 200 by isolating the core resources from the compute resources 350, except through APIs or the like which are tightly controlled. Thus, the compute resources 350 can be dedicated to executing the user defined applications, without affecting the on-going operation of the optical transceiver 200.” [Shiner, ¶ [0033]].
Shiner also teaches application-to-orchestrator data transfer using the isolated resources: “Similarly, the application can push or initiate communication with the orchestrator 390 or other apps that can reside on the same module or other modules. The compute resources 350 can be adapted to access the data via an API and wherein the compute resources 350 are adapted to communicate with the orchestrator 390 via a messaging bus associated with a network element housing the optical module 400.” [Shiner, ¶ [0055]].
The combined teachings meet the functional relationship required by claim 14. Sadasivarao expressly places streaming PM data in a ROADM/RNC power-control-loop setting and designs the distributed asynchronous streaming subsystem so that its lifecycle does not adversely impact the network element’s control or management planes.
Shiner supplies the complementary implementation technique of isolating application compute resources from core optical resources so that user/application activity does not interfere with ongoing optical operation. Applied to the Colton/Naik data structure, the result is transmitting the organized optical PM/monitoring data to application sessions through an asynchronous, isolated software path while the power-balancing control loop continues operating.
One of ordinary skill in the art would have been motivated to combine these teachings because external consumption of high-rate optical PM data can otherwise compete with real-time control for processor cycles, interfaces, locks, and data access. Sadasivarao expressly identifies push streaming as a means to eliminate polling cycles and make telemetry available while the optical control environment continues to operate; Shiner expressly isolates app execution from core optical functions. A skilled artisan seeking to expose Colton/Naik’s stored optical data to applications without disturbing the control path would have recognized these as complementary, known techniques.
The combination also would have had a reasonable expectation of success. The references do not require changing the power-balancing algorithm; rather, they separate the data-export/application path from the real-time control path. The same measured values can be made available to both, while the control loop retains its normal execution. That is a predictable software-architecture improvement in an optical network element, and it directly addresses the risk of interruption created by synchronous polling or shared resources.
Claim 14 is therefore unpatentable under 35 U.S.C. § 103.
Claim 15 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., and further in view of Sadasivarao et al. and Shiner et al.
Claim 15
Claim 15 is an independent computer-program-product claim. It requires a non-transitory computer-readable medium carrying instructions that, when executed by at least one processor, cause the processor to (1) receive data associated with an optical communications network; (2) containerize that data according to a characteristic to provide a data structure containing the organized/containerized data; (3) provide access to the data structure for one or more application sessions; and (4) transmit the containerized data to the application sessions without interrupting a power balancing control loop. Each of these limitations is taught or rendered obvious by the cited combination.
First, Colton teaches acquisition of optical-network performance data from selected tap/access points, processor-based performance management, database organization according to the access-point source, and transfer of requested optical spectrum/performance data to distributed software clients. The relevant disclosures are not merely conceptual diagrams; they describe operating software modules, Performance Manager 1000, SDS 204, network interfaces, external LANs, and measurement databases.
Colton teaches the optical-data acquisition and characteristic-indexed storage: “After initialization, the PFM 1000 runs in background mode, sequentially scanning through all equipped access points of the IOS 60 and compiling a database for each equipped access point over time. The user can reconfigure the desired measurement points and the scanning interval between measurement sets through an SNMP request.” [Colton, Performance Management; FIG. 54; ¶ [1257]].
Colton teaches delivery to a software/data service: “On request from SDS 204 the PFM 1000 can command OPM 216 to read the optical spectrum for a specific tap point on a TPM circuit pack 121 and send response back to SDS 204. TCP is used to forward the spectrum data from PFM 1000 to SDS 204.” [Colton, Performance Management; FIG. 54; ¶ [1257]].
Second, Naik makes the claimed data-structure organization and computer-program-product implementation explicit. Their core framework stores system state in a datastore/database, partitions the state by operational/configuration data and service type, publishes it to subscribed services, and supports long-lived data subscriptions to external software clients.
Naik teaches the claimed non-transitory computer-readable-medium implementation: “Implementations of the above techniques include methods, apparatus, systems, and computer program products. One such computer program product is suitably embodied in a non-transitory computer-readable medium that stores instructions executable by one or more processors. The instructions are configured to cause the one or more processors to perform the above-described actions.” [Naik, ¶ [0006]].
They also teach the organized datastore: “System state information may be partitioned by configuration or operational data and service type. Generally, microservices 140 are stateless, when starting up, system state information is either recovered directly from underlying hardware device layer or from the datastore of the core framework microservice 140a.” [Naik, ¶ [0079]].
And they teach persistent application-style subscriptions: “streaming the encoded data may include, for example, streaming the encoded data to one or more microservice 140 subscribed to the data stream. Streaming the encoded data may be a long-lived subscription.” [Naik, ¶ [0120]].
Third, Sadasivarao and Shiner teach the final independent-claim limitation requiring transmission to application sessions without interrupting the power balancing control loop. Sadasivarao expressly discusses streaming PM data for tighter RNC power-control loops and a distributed asynchronous streaming service designed not to adversely impact the network element’s control or management planes.
Shiner provides the implementation detail of isolating application resources from core optical resources so the applications do not interfere with ongoing operation.
Sadasivarao states: “The entire streaming framework is designed as a modular software service whose life-cycle can be managed without adversely impacting the network element’s (NE) control or management planes.” [Sadasivarao, Tu3D.3, p. 2].
Shiner states: “the compute resources 350 are segmented such that operation of the user defined applications does not interfere with the operation of the optical transceiver 200 by isolating the core resources from the compute resources 350, except through APIs or the like which are tightly controlled. Thus, the compute resources 350 can be dedicated to executing the user defined applications, without affecting the on-going operation of the optical transceiver 200.” [Shiner, ¶ [0033]].
Accordingly, the cited combination covers every limitation of claim 15. The optical data received from the optical network and stored by access-point characteristic come from Colton; the explicit partitioned datastore, external subscriptions, and non-transitory computer-readable-medium instructions come from Naik; and the non-disruptive delivery path operating alongside optical power-control functions comes from Sadasivarao and Shiner. When these known software functions are embodied in the non-transitory medium expressly taught by Naik, the instructions cause a processor to carry out the complete claimed sequence.
One of ordinary skill in the art would have been motivated to combine Colton and Naik for the same reasons explained for claims 1 and 8: both concern processor-based management of optical-network operational data, and Naik provides a known scalable datastore/pub-sub software architecture for the same class of information.
A skilled artisan would further have been motivated to implement the resulting data-access system using Sadasivarao’s asynchronous push-streaming design and Shiner’s isolated application resources because external application access should not degrade time-sensitive optical-control functions. These teachings solve complementary portions of the same engineering problem collecting, organizing, serving, and safely consuming high-rate optical operational data.
The combination yields no unexpected functional conflict. The measurement/control plane continues to run using its normal PM data and power-control logic; the organized database/data structure is concurrently exposed to application software through an asynchronous isolated path. Naik expressly teaches that the software can be embodied as processor-executable instructions on a non-transitory medium. The skilled artisan therefore would have had a reasonable expectation of success.
The modification is the predictable combination of known processor, datastore, messaging, telemetry-streaming, and resource-isolation techniques in the same optical-network-management environment.
Claim 15 is therefore unpatentable under 35 U.S.C. § 103.
Claim 16 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., further in view of Sadasivarao et al. and Shiner et al., and further in view of Liu et al.
Claim 16
With respect to claim 16, the complete computer-program-product limitations of claim 15 including the non-transitory medium, receipt of optical-network data, characteristic-based data-structure organization, application-session access, and non-disruptive transmission while the power-balancing control loop continues are taught by Colton, Naik, Sadasivarao, and Shiner for the detailed reasons set forth above, except wherein claim 16 adds that the instructions further cause the processor to provide a power balancing command to a WSS.
However, within analogous art, Liu expressly teaches the added command relationship: “An optical channel monitor 136 at the output of the WSS measures the power of each wavelength, and this data is used to adjust the attenuation of the WSS to balance the channel powers.” [Liu, ¶ [0005]; FIG. 1].
Liu also discloses the control-loop processor whose outputs modify ROADM elements: “A control loop processor (CLP) 146, shown as a single element but alternatively configured in multiple specific individual elements, executes control loop functionality based in part on inputs 148 and the channel power control loop (CPCL) configuration, for example computer code, which results in outputs 150 used to adjust or modify specific ROADM Node 100 elements and/or overall performance or functionality.” [Liu, ¶ [0005]].
One of ordinary skill would have been motivated to incorporate Liu’s WSS power-control output into the claim-15 software for the same reason optical PM data are collected in the first place: the measured per-wavelength power is the direct feedback variable used to maintain balanced channel powers. Integrating that known output into the processor instructions avoids a redundant control path and permits the same OCM/PM data used for application access to support the preexisting real-time control function.
Because Liu already disclosed computer-code-configured control-loop processing driving the WSS, and the claim-15 combination already separates external data streaming from core control, the skilled artisan would have reasonably expected both functions to coexist.
Claim 16 is therefore unpatentable under 35 U.S.C. § 103.
Claim 17 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., further in view of Sadasivarao et al. and Shiner et al., and further in view of Frisken et al.
Claim 17
With respect to claim 17, all limitations of claim 15 are taught by Colton, Naik, Sadasivarao, and Shiner for the detailed reasons set forth above, except wherein claim 17 additionally requires the instructions to store the data structure in an on-board memory location of an OCM device.
However, within analogous art, Frisken expressly teaches an internal OCM database and processor physically disposed with the OCM electronics.
Frisken states: “The data received by photodiodes 22, 23 and 24 is optionally able to be stored in an internal database 26 and processed by processor 27. Database 26 is also configured for storing calibration data to be applied to the received signal data. Processor 27 may also be configured to apply a calibration to outgoing signal data being ported to an external device. In other embodiments, this storage and processing of data is performed externally to OCM 1. Database 26 and processor 27 are disposed on an integrated circuit (not shown) along with other electronic components such as control electronics for the MEMs mirror and components for powering OCM 1.” [Frisken, ¶ [0057]].
A skilled artisan would have been motivated to select this internal/on-board memory placement for the claim-15 data structure because the data originate at an optical monitor and are repeatedly used both by control logic and external applications.
Keeping the current data structure on the OCM reduces internal transport latency and bandwidth, keeps data available to the local control path, and still allows the external access/streaming path taught by the base combination.
Frisken expressly recognize internal and external storage as alternatives, so choosing internal OCM memory is a known design option with a reasonable expectation of success.
Claim 17 is therefore unpatentable under 35 U.S.C. § 103.
Claim 18 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., further in view of Sadasivarao et al. and Shiner et al., and further in view of Gagnon et al.
Claim 18
With respect to claim 18, all limitations of independent claim 15 are taught by Colton, Naik, Sadasivarao, and Shiner for the detailed reasons set forth above, except wherein claim 18 further requires that the instructions implementing characteristic-based containerization determine first and second tap points associated with respective first and second portions of data and store those portions in first and second locations associated with the respective tap points.
Gagnon expressly teaches first and second tap-point data acquisition: “a method may include receiving, via a first network tap point included by a first network segment, a first portion of network communication data between a client computing device and a server computing device. The method may include receiving, via a second network tap point included by a second network segment, a second portion of network communication data between the client computing device and the server computing device.” [Gagnon, ¶ [0010]].
They then teach respective data-structure locations for those different sources: “the device or apparatus may store data objects from a first network segment (e.g., the intranet, client-side, etc.) in a queue 302. In various embodiments, the device or apparatus may store data objects from a second network segment (e.g., the intranet, server-side, etc.) in a queue 304. In various embodiments, if additional network segments (e.g., a third or fourth network segment, etc.) are employed, respective queues may also be employed.” [Gagnon, ¶ [0105]; FIG. 3B].
The motivation to combine is the same provenance-preservation rationale described for claims 4 and 11, now implemented by the processor-executable instructions of claim 15.
Colton already provides multiple optical tap/access points and per-access-point databases. Gagnon provides a concrete first-location/second-location data-structure arrangement for separately sourced portions.
Using source-specific storage locations makes subsequent application access meaningful because the consumer can identify where each measurement originated and can correlate conditions across the network.
The software-only organization is predictable and requires no modification of the optical control loop, so a skilled artisan would have had a reasonable expectation of success.
Claim 18 is therefore unpatentable under 35 U.S.C. § 103.
Claim 19 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., further in view of Sadasivarao et al. and Shiner et al., and further in view of Wensink et al.
Claim 19
With respect to claim 19, the cited claim-15 combination teaches every limitation of the non-transitory computer-program product and its non-disruptive optical-data delivery. All limitations of independent claim 15 are taught by Colton, Naik, Sadasivarao, and Shiner for the detailed reasons set forth above, except wherein claim 19 adds that the instructions cause the processor to provide application-session access to the data structure via an Ethernet Bus.
However, within analogous art, Wensink expressly teaches the Ethernet-bus data path in optical communication nodes: “the EBEMs function as a data bridge between the back plane bus 26, 36, 46 and an Ethernet bus to which the workstation 10 is connected such that data may be exchanged between the workstation 10 and the NCPs 22, 32, 42.” [Wensink, col. 8].
A person of ordinary skill would have been motivated to expose the claim-15 data structure over this known Ethernet bus because Colton, Naik, and Sadasivarao all contemplate networked software consumers of optical management/telemetry data, and Wensink expressly uses an Ethernet bus between optical-node processors and a workstation. The Ethernet bus would provide the physical/logical communication path by which the already-isolated application session reaches the organized data without changing the power-control path. Standard Ethernet interfaces and processors were conventional and interoperable, providing a reasonable expectation of success.
Claim 19 is therefore unpatentable under 35 U.S.C. § 103.
Claim 20 is rejected under 35 U.S.C. § 103 as being unpatentable over Colton in view of Naik et al., further in view of Sadasivarao et al. and Shiner et al., and further in view of Funk.
Claim 20
With respect to claim 20, all limitations of independent claim 15 are taught by Colton, Naik, Sadasivarao, and Shiner for the detailed reasons set forth above, except wherein claim 20 further requires that the processor receive optical-network data through at least one of an OSC, an RMC, or a combination thereof. The alternative OSC is expressly taught by Funk.
Within analogous art, Funk teaches: “The management network controls a channel wavelength called the optical supervisory channel (OSC) which may be transmitted over the network via the Internet protocol (IP). This OSC is usually an out-of-band wavelength, i.e. a wavelength outside the telecommunication wavelength band, which will get transmitted through all of the network elements.” [Funk, ¶ [0003]].
One of ordinary skill in the art would have been motivated to use this OSC as an input path for the claim-15 program because it is a dedicated optical-network management channel designed to traverse network elements and carry status/control information outside the payload band. Such a path provides resilience when the ordinary management network is unavailable and fits naturally with a program that receives, organizes, and exposes optical-network operational data. The claim is satisfied by the OSC alternative alone; no separate showing of an RMC is required. Since the data remain digital management information once received, the same containerization, storage, and non-disruptive application-access processes of claim 15 continue unchanged.
Claim 20 is therefore unpatentable under 35 U.S.C. § 103.
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