DETAILED ACTION
Response to Arguments
Applicant’s arguments with respect to claim(s) s 1, 10, and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The claims have been amended and the new grounds to rejection is to address the new claim scope.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Re claim 20, the claim is amended to recite “logging error details in sub network connection diagnostics” and “checking, by the processing system, for the failure or an originated node or a terminating node on the current working route”, such as both steps are required by the claim. However, within Fig. 3, in shows that the step of “log the error details in SNC diagnostics” is part of step 317 and checking for the failure on originated or terminated node” is part of the step 322, but steps 317 and 322 are along separate paths, such that they are dependent upon different scenarios, at least in the order it was presented within the claim limitation, such that the claim limitation, as it is present, is not supported by the claim scope, such that it is unclear whether or not both steps to be performed together is taught by the prior art.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-9 and 12-18 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Re claim 4, the claim is dependent upon claim 1 and recites “wherein the operations further comprise:
checking a capacity change mode,
wherein the network operations are initiated responsive to the capacity change mode not being set to MODE1”.
However, claim 1, which the claim is dependent, recites “implementing one of: raising an alarm response to detecting the failure or performing network operations responsive to not detecting the failure”. Hence, according to claim 10, the scope is such that the system could perform network operations in the case when the system does not detected the failure, such that the limitation of “wherein the performing the network operations are initiated responsive to the capacity change not being set to MODE1” such that it is unclear if the network operations are performed twice, once in response to no detecting the failure and again after determining the capacity change not being set to MODE1 or if both limitations of the failure not being detected and the capacity change mode not being set to MODE1 in order to perform network operations. Additionally, if the system is in the scenario of a failure occurring, and such that the limitation of “implementing one of: raising an alarm response to detecting the failure” would take place, the limitation of claim 10 would state that the performing the network operations would not take place, hence, would the network operations still take place if a failure has then place by the capacity change mode is not set to MODE1, such as to override the initial condition that prevented it. Due to the confusion of the claim scope, the claim is indefinite.
Re claim 5, the claim is dependent upon claim 4 and further suffers from the issues previously stated.
Re claim 6, the claim is dependent upon claim 1 and additionally recites “wherein the operations further comprise:
logging error details in sub network connection diagnostics, and initiating the raising of the alarm responsive to an OPTIMIZATION_MODE parameter set to DENY”.
The limitation of “initiating the raising of the alarm responsive to an OPTIMIZATION_MODE parameter set to DENY”, but due to the act being responsive to an OPTIMIZATION_MODE parameter, but the presence of the OPTIMIZATION_MODE parameter is not currently required by the claim scope, it is unclear whether or not it is required by the claim scope. The examiner has noticed that the OPTIMIZATION_MODE parameter is disclosed by dependent claim 5, such that it is unclear whether the claim is supposed to be dependent upon claim 5, to have the claim scope require the OPTIMIZATION_MODE and clarify the confusion.
Additionally, claim 1, from which claim 6 is dependent, states “implementing one of: raising an alarm responsive to detecting the failure”, such that if there is an failure, it is unclear whether or not the “initiation the raising of the alarm responsive to an OPTIMIZATION_MODE parameter set to DENY”, would also take place in a second and different alarm, or rather, whether both limitations are required such this only takes place when a failure is not detected as well as the OPTIMIZATION_MODE parameter set to DENY, or the if alarm can take place when the OPTIMIZATION_MODE is set to DENY and no fault is detected. Due to the confusion, the claim scope is considered indefinite.
Re claim 7, the claim is dependent upon claim 1 and additionally recite “wherein the operations further comprise:
checking for the failure on an originating node or a terminating node on the current working route responsive to an OPTIMIZATION_MODE parameter set to OPTIMIZE;
logging error details in sub network connection diagnostics, and initiating the raising the alarm responsive to the failure occurring on the originating node or the terminating node”.
The limitation of “checking for the failure on an originating node or a terminating node on the current working route responsive to an OPTIMIZATION_MODE parameter set to optimize”, but due to the act being responsive to an OPTIMIZATION_MODE parameter, but the presence of the OPTIMIZATION_MODE parameter is not currently required by the claim scope, it is unclear whether or not it is required by the claim scope. The examiner has noticed that the OPTIMIZATION_MODE parameter is disclosed by dependent claim 5, such that it is unclear whether the claim is supposed to be dependent upon claim 5, to have the claim scope require the OPTIMIZATION_MODE and clarify the confusion.
Additionally, claim 1, from which claim 7 is dependent, states “implementing one of: raising an alarm responsive to detecting the failure”, such that if there is an failure, it is unclear whether or not the “initiation the raising of the alarm responsive the failure occurring on the originated node or the terminating node”, would also take place and a second and different alarm, or rather, whether or not this only takes place when a failure is not detected. Due to the confusion, the claim scope is considered indefinite.
Re claim 8, the claim is dependent upon claim 1 and additionally recites “wherein the operations further comprise escalating a capacity change mode to MODE2 and performing the network operations responsive to the failure not occurring on an originating node or a terminating node”.
However, it is unclear whether or not a failure has occurred within the portion of the limitation. Claim 1, from which this claim depends, recites “implementing one of: rising an alarm responsive to detecting the failure or performing network operations associated with the indication responsive to not detecting a failure”, such that if a failure has not been detected, that network operations are performed. Hence, in the limitation of claim 8, which recite “performing the network operations responsive to the failure not occurring on an origination node or a terminating node”, as there is no failure operation, would the network operations be performed twice or rather, is the failure being present required, just not that the originated node or the terminating node. Due to the confusion that to whether or not the failure is required on the network operations is being performed twice, the claim scope is indefinite.
Re claim 9, the claim is dependent upon claim 8 and suffers from the issues previously stated.
Re claim 12, this claim is dependent upon claim 10 and additionally recites “wherein the operations further comprise:
checking a capacity change mode,
wherein the performing the network operations are initiated responsive to the capacity change mode not being set to MODE1.”
However, claim 10, which the claim is dependent, recites “implementing one of: raising an alarm response to detecting the failure or performing network operations responsive to not detecting the failure”. Hence, according to claim 10, the scope is such that the system could perform network operations in the case when the system does not detected the failure, such that the limitation of “wherein the performing the network operations are initiated responsive to the capacity change not being set to MODE1” such that it is unclear if the network operations are performed twice, once in response to no detecting the failure and again after determining the capacity change not being set to MODE1 or if both limitations of the failure not being detected and the capacity change mode not being set to MODE1 in order to perform network operations. Additionally, if the system is in the scenario of a failure occurring, and such that the limitation of “implementing one of: raising an alarm response to detecting the failure” would take place, the limitation of claim 10 would state that the performing the network operations would not take place, hence, would the network operations still take place if a failure has then place by the capacity change mode is not set to MODE1, such as to override the initial condition that prevented it. Due to the confusion of the claim scope, the claim is indefinite.
Re claim 13, the claim is dependent upon claim 10 and additionally recites “wherein the operations further comprise:
checking an OPTIMIZATION_MODE parameter wherein the performing the network operations are initiated responsive to the OPTIMIZATION_MODE parameter being set to NONE”.
However, claim 10, which the claim is dependent, recites “implementing one of: raising an alarm response to detecting the failure or performing network operations responsive to not detecting the failure”. Hence, according to claim 10, the scope is such that the system could perform network operations in the case when the system does not detected the failure, such that the limitation of “wherein the performing the network operations are initiated responsive to OPTIMIZATION_MODE parameter being set to NONE” such that it is unclear if the network operations are performed twice, once in response to no detecting the failure and again after determining the OPTIMIZATION_MODE or if both limitations of the failure not being detected and the OPTIMIZATION_MODE being set to NONE in order to perform network operations. Additionally, if the system is in the scenario of a failure occurring, and such that the limitation of “implementing one of: raising an alarm response to detecting the failure” would take place, the limitation of claim 10 would state that the performing the network operations would not take place, hence, would the network operations still take place if a failure has then place by the OPTIMIZATION_MODE set to NONE, such as to override the initial condition that prevented it. Due to the confusion of the claim scope, the claim is indefinite.
Re claim 14, the claim is dependent upon claim 10 and additionally recites “wherein the operations further comprise:
logging error details in sub network connection diagnostics, and initiating the raising the alarm responsive to an OPTIMIZATION_MODE set to DENY”.
Additionally, claim 10, from which claim 14 is dependent, states “implementing one of: raising an alarm responsive to detecting the failure”, such that if there is an failure, it is unclear whether or not the “initiation the raising of the alarm responsive to an OPTIMIZATION_MODE parameter set to DENY”, would also take place in a second and different alarm, or rather, whether both limitations are required such this only takes place when a failure is not detected as well as the OPTIMIZATION_MODE parameter set to DENY, or the if alarm can take place when the OPTIMIZATION_MODE is set to DENY and no fault is detected. Due to the confusion, the claim scope is considered indefinite as there are multiple ways to interpret this set of limitations together.
Re claim 15, the claim is dependent upon claim 10 and additionally recites: “wherein the operations further comprise:
checking for the failure on an originating node or a terminating node on the current working route responsive to an OPTIMIZATION_MODE parameter set to OPTIMIZE; and
logging error details in sub network connection diagnostics, and initiating the raising the alarm responsive to the failure occurring on the originating node or the terminating node”.
The limitation of “checking for the failure on an originating node or a terminating node on the current working route responsive to an OPTIMIZATION_MODE parameter set to optimize”, but due to the act being responsive to an OPTIMIZATION_MODE parameter, but the presence of the OPTIMIZATION_MODE parameter is not currently required by the claim scope, it is unclear whether or not it is required by the claim scope. The examiner has noticed that the OPTIMIZATION_MODE parameter is disclosed by dependent claim 14, such that it is unclear whether the claim is supposed to be dependent upon claim 14, to have the claim scope require the OPTIMIZATION_MODE and clarify the confusion.
Additionally, claim 10, from which claim 15 is dependent, states “implementing one of: raising an alarm responsive to detecting the failure”, such that if there is an failure, it is unclear whether or not the “initiation the raising of the alarm responsive the failure occurring on the originated node or the terminating node”, would also take place and a second and different alarm, or rather, whether or not this only takes place when both limitations of a failure and a failure occurring on the originated node or the terminating node. Due to the confusion, the claim scope is considered indefinite.
Re claim 16, this claim is dependent upon claim 10 and additionally recites: “wherein the checking the nodes results in not detecting the failure and wherein the operations further comprise escalating a capacity change mode to MODE2 and performing the network operations to the failure not occurring on an originating node or a terminating node”.
However, it is unclear whether or not a failure has occurred within the portion of the limitation. Claim 10, from which this claim depends, recites “implementing one of: rising an alarm responsive to detecting the failure or performing network operations associated with the indication responsive to not detecting a failure”, such that if a failure has not been detected, that network operations are performed. Hence, in the limitation of claim 16, which recite “performing the network operations responsive to the failure not occurring on an origination node or a terminating node”, as there is no failure operation, would the network operations be performed twice or rather, is the failure being present required, just not that the originated node or the terminating node. Due to the confusion that to whether or not the failure is required on the network operations is being performed twice, the claim scope is indefinite.
Re claim 17 and 18, these claims are dependent upon claim 16 and therefore inherent the issues previously stated. Furthermore, the claim scope of these dependent claims do not clarify the claim scope as to overcome these 112 issues.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3 ,10, 11, 19, is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rao et al (herein Rao) US PG PUB 2017/0338887.
Re claim 1, Rao discloses node in a fiber optic network (the system is towards address the optical communication system with multiple nodes or stops along said path), the node comprising a processing system including a processor and executable instructions that, when executed by the processing system, facilitate performance of operations, the operations comprising:
receiving an indication of auto-reversion or a manual operation to switch a current working route following fault recovery (after a wait to restore (WTF) time expire but before reverting back to the working path, the POSM 400 may request the ROADM card 420 to re-evaluate this SCH OPR LOW alarm condition ¶ [0064], wherein the request is an indication of auto-reversion at it is tied to the wait to restore time);
checking nodes in the current working route for a failure responsive to the receiving of the indication of the automatic or manual trigger (SCH OPR LOW is a resulting of optical power message 422 of the ROADM card. The SCH OPR LOW condition is determined based on the OPM scan in the dem-multiplexing direction perform by the ROADM card ¶ [0061], wherein the SCH OPR LOW alarm may be able to detected law lop degradation of the system ¶ [0062], such that it is determining if there is a potential failure); and
implementing one of: raising an alarm responsive to detecting the failure or performing network operations associated with indication responsive to not detecting the failure (when this alarm condition comes on the working path, the OPSM 400 may determine not to switch back to the working path because traffic maybe not recovered possibly due to the last hop degradation ¶ [0064], such that the system could raise the SCH OPR LOW alarm is present due to a detection of failure along path).
Re claim 2, Rao discloses all the elements of claim 1, which claim 2 is dependent. Furthermore, Rao discloses wherein indication of the auto-reversion comprises a protect route validation timer expiring or a wait to revert timer expiring (after a wait to restore (WTF) time expire but before reverting back to the working path, the POSM 400 may request the ROADM card 420 to re-evaluate this SCH OPR LOW alarm condition ¶ [0064], such that the request is in response to the WTF time expiring).
Re claim 3, Rao discloses all the elements claim 1, which claim 3 is dependent. Furthermore, Rao discloses wherein the failure comprises a node block, an upgrade in progress on any of the nodes in the current working route, a local shelf sync issues, a comms failure (the SCH POR LOW alarm condition is an optical power status message which means that the super-channel optical power received is low ¶ [0061], such that the low amount of signals could result in a communication failure if the signal is too low to be communicated. It is disclosed that when this alarm condition comes on the work path, the OPSM 400 may determine not the switch back to the working path. The motivation here may be that the traffic may not be recovered ¶ [0064], which the inability to recovery means a communication failure), a domain optical controller out of service, or any combination thereof.
Re claim 10, Rao discloses a non-transitory machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor, facilitate performance of operations (The methods and flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable storage medium for execution by a general purpose computer or a processor. ¶ [0122]), the operations comprising:
obtaining an indication of an auto-reversion or a manual operation to switch a current working route following fault recovery (after a wait to restore (WTF) time expire but before reverting back to the working path, the POSM 400 may request the ROADM card 420 to re-evaluate this SCH OPR LOW alarm condition ¶ [0064], wherein the request is an indication of auto-reversion at it is tied to the wait to restore time);
checking nodes in the current working route of a fiber optic network for a failure responsive to detecting the automatic or manual trigger (SCH OPR LOW is a resulting of optical power message 422 of the ROADM card. The SCH OPR LOW condition is determined based on the OPM scan in the dem-multiplexing direction perform by the ROADM card ¶ [0061], wherein the SCH OPR LOW alarm may be able to detected law lop degradation of the system ¶ [0062], such that it is determining if there is a potential failure); and
implementing one of: raising an alarm responsive to detecting the failure or performing network operations responsive to not detecting the failure (when this alarm condition comes on the working path, the OPSM 400 may determine not to switch back to the working path because traffic maybe not recovered possibly due to the last hop degradation ¶ [0064], such that the system could raise the SCH OPR LOW alarm is present due to a detection of failure along path).
Re claim 11, Rao discloses all the elements of claim 10, which claim 11 is dependent. Furthermore, Rao discloses wherein the failure comprises a node block, an upgrade in progress on any of the nodes in the current working route, a local shelf sync issue, a comms failure (the SCH POR LOW alarm condition is an optical power status message which means that the super-channel optical power received is low ¶ [0061], such that the low amount of signals could result in a communication failure if the signal is too low to be communicated. It is disclosed that when this alarm condition comes on the work path, the OPSM 400 may determine not the switch back to the working path. The motivation here may be that the traffic may not be recovered ¶ [0064], which the inability to recovery means a communication failure), a domain optical controller out of service, or any combination thereof.
Re claim 19, Rao discloses a method, comprising:
receiving, by a processing system including a processor (the methods provided maybe implemented in a general purpose computer, a processor, or a processor core ¶ [0120]), an indication of an auto-reversion or a manual operation to switch a current working route following fault recovery (after a wait to restore (WTF) time expire but before reverting back to the working path, the POSM 400 may request the ROADM card 420 to re-evaluate this SCH OPR LOW alarm condition ¶ [0064], wherein the request is an indication of auto-reversion at it is tied to the wait to restore time);
checking, by the processing system, nodes in the current working route of a fiber optic network for a failure (SCH OPR LOW is a resulting of optical power message 422 of the ROADM card. The SCH OPR LOW condition is determined based on the OPM scan in the dem-multiplexing direction perform by the ROADM card ¶ [0061], wherein the SCH OPR LOW alarm may be able to detected law lop degradation of the system ¶ [0062], such that it is determining if there is a potential failure); and
implementing one of: raising an alarm, by the processing system, responsive to detecting the failure or performing network operations (when this alarm condition comes on the working path, the OPSM 400 may determine not to switch back to the working path because traffic maybe not recovered possibly due to the last hop degradation ¶ [0064], such that the system could raise the SCH OPR LOW alarm is present due to a detection of failure along path), by the processing system, responsive to not detecting the failure.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TANYA MOTSINGER whose telephone number is (571)270-7488. The examiner can normally be reached 9-4.
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.
TANYA MOTSINGER
Examiner
Art Unit 2637
/TANYA T MOTSINGER/ Examiner, Art Unit 2635