DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to 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 later invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-2, 5-7, 9, 13, 17 are rejected in the Instant Application. Claims 4 and 8 are objected to.
Election/Restrictions
Applicant Elects Claims 1-2, 4-9, 13, 17 for prosecution.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of PCT/CN2022/109051 filed 7/29/2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 11/18/2024, 9/22/2205, 4/17/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Objections
Claims 4 and 8 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 1-2, 5-7, 9, 13, 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Martini (US Pub. 2019/0384580) in view of Wu (US Pub. 2023/0125058), and further in view of Dec (US Pub. 2017/0078158).
With respect to Claim 1, Martini teaches a method comprising: creating a specification data type using yet another next generation (YANG) language for indicating device specification data associated with a network device; (para. 48; YANG language may be used to model configuration and state of network elements. para. 31, 72; YANG can be used to identify its capabilities such as bandwidth.)
creating a YANG based device specification data model using the specification data type; (para. 31; YANG model that identifies capabilities.)
But Martini does not explicitly teach a constraint model.
Wu, however, does teach creating a YANG based device specification constraint model; (paras. 36-43; defining QoS parameters such as bandwidth needed in YANG format.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Martini with the constraint model in order to provide configuration requirements between networks in an agnostic format.
But modified Martini does not explicitly teach sharing models with a network management system.
Dec, however, does teach and sharing the device specification data model and the device specification constraint model with a network management system and the network device. (para. 19; Network manager stores YANG models and sends the YANG models to configure a network device. para. 31; Request of YANG model stored in network device.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Martini with the sharing of the models in order to use the models to configure devices.
With respect to Claim 2, modified Martini teaches the method of claim 1, and Martini also teaches wherein the device specification data includes mixed characteristics of configuration data and state data associated with the device specification model. (para. 48; YANG models both configuration and state data.)
With respect to Claim 5, modified Martini teaches the method of claim 1, and Martini also teaches wherein the device specification data model defines device specifications associated with the network device. (para. 31, 72; YANG can be used to identify its capabilities such as bandwidth.)
With respect to Claim 6, modified Martini teaches the method of claim 1, and Wu also teaches wherein the device specification constraint model defines constraints rules in accordance with which the network management system configures the network device. (paras. 36-43; defining QoS parameters such as bandwidth for providing a service.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 7, modified Martini teaches the method of claim 2, and Dec also teaches wherein the device specification data assists the network management system and the network device in validating the configuration data. (paras. 37-38; validation of YANG model.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 9, Martini teaches a method comprising: wherein: the device specification data is filled in a yet another next generation (YANG) based device specification data model using a specification data type, the specification data type indicating device specifications associated with the network device; (para. 48; YANG language may be used to model configuration and state of network elements. para. 31, 72; YANG can be used to identify its capabilities such as bandwidth.)
But Martini does not explicitly teach confirming a connection.
Wu, however, does teach confirming, by the network management system, a connection to the network device; (A network device and management system will be taught later. para. 112; confirming establishment of a channel.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Martini with the confirmation of a connection in order to verify a mechanism for transmitting data to another device.
But modified Martini does not explicitly teach sharing models with a network management system.
Dec, however, does teach creating, by a network management system, a connection request to a network device; (Fig. 1, para. 31; management device connects to network device.)
receiving, by the network management system, device specification data associated with the network device, (para. 31; management device requests device’s YANG models, and stores the received models. Storage in a confirmation that the connection existed.)
and storing the device specification data in a datastore. (paras. 19, 31, 39; storage of YANG models in a cache.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Martini with the sharing of the models in order to use the models to configure devices.
With respect to Claim 13, modified Martini teaches the method of claim 9, and Dec also teaches further comprising updating the datastore with an updated device specification data received from the network device. (paras. 2-3, 39; updating of a YANG model.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 17, Martini teaches a method comprising: including, in a network device, a yet another next generation (YANG) based device specification data model wherein: the device specification data model includes a specification data type that defines device specifications associated with the network device, (para. 48; YANG language may be used to model configuration and state of network elements. para. 31, 72; YANG can be used to identify its capabilities such as bandwidth. See also Dec, para. 31; Request of YANG model stored in network device.)
filling, by the network device, a device specification data in the specification data model using the specification data type; (para. 31; YANG model that identifies capabilities.)
But Martini does not explicitly teach a constraint model.
Wu, however, does teach and a YANG based device specification constraint model, and the device specification constraint model defines constraints rules (paras. 36-43; defining QoS parameters such as bandwidth needed in YANG format.)
confirming, by the network device, a connection to the network management system; (A network device and management system will be taught later. para. 112; confirming establishment of a channel.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Martini with the constraint model in order to provide configuration requirements between networks in an agnostic format.
But modified Martini does not explicitly teach sharing models with a network management system.
Dec, however, does teach in accordance with which a network management system configures the network device with a configuration; (para. 19; Network manager stores YANG models and sends the YANG models to configure a network device. para. 31; Request of YANG model stored in network device.)
receiving, by the network device, a connection request from the network management system; (Fig. 1, para. 31; management device connects to network device.)
and sending, by the network device, the device specification data to the network management system. (para. 31; management device requests device’s YANG models, and stores the received models.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Martini with the sharing of the models in order to use the models to configure devices.
Remarks
Applicant elects Group I with traverse only inasmuch as Applicant also seeks to have Claim 17 examined. Examiner will treat Claim 17 with Group I.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights