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 ACTION
The office action is a response to application filed on 2/5/2025. Wherein claims 1-5 are pending and ready for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all 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 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.
1. Claim(s) 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Hajduczenia (US 20140334822 A1) in view of Hajduczenia (US 20120251113 A1).
With respect to independent claims:
Regarding claim(s) 1, a method of provisioning a network interface device,
Hajduczenia (US 20140334822 A1) teaches comprising providing a network interface device having a controller for controlling the network device and a plurality of ports, wherein one or more of the plurality of ports are associated with a user, (Hajduczenia (US 20140334822 A1), [0051] Once the DPoE ONU comes online and is successfully configured by the network operator, the LLDP Transmitter agent starts sending LLDPDUs (using multicast destination address, as allowed by the 802.1AB LLDP standard) on the port connected to the Demarcation device. In case of S-ONUs equipped with multiple MU/MI ports on the User Network Interface (UNI) side, each port is able to operate an independent LLDP agent to allow for transmission of the LLDPDU across the link to the connected Demarc. The process can be continuous and its frequency can depend on the implementation. The operator is provided with the means to enable/disable LLDP transmission on each of the exposed MU/MI interfaces, allowing the operator to control which of the said ports support he automated configuration and which do not. [0052] After the Demarcation device MAC receives an LLDPDU with the DPoE specific TLV, the Demarcation device MAC parses the received LLDPDU and identifies the requirements for the port configuration to allow for the transmission of the DHCP request to the backoffice system, including among the others: (a) whether the DPoE ONU is configured to operate in the encapsulation or transport mode, (b) what virtual local area network VLAN ID, known as VID, needs to be applied to the DHCP request on the Demarcation device to allow for successful forwarding through the DPoE ONU, etc. The Demarcation device uses this information to configure its port into a state allowing for proper forwarding of frames through the DPoE ONU onto the DPoE Network. DHCP requests generated by the software agent operating on the Demarcation device are processed and encapsulated in a manner consistent with the DPoE ONU default configuration requirements as delivered using the DPoE specific TLV in the LLDPDU. In case of S-ONU, each MU/MI type port can be configured with a dedicated L2 configuration path parameters, so that each Demarcation device potentially connected to such ports is uniquely recognized by the backoffice system and be configured independently. [examiner notes: the Demarcation device interprets to be the network interface device. The operator interprets to be the controller.]) wherein the controller includes memory for storing an initial configuration file associated with the network device, (Hajduczenia (US 20140334822 A1), [0022] Several installation methods may be used, including, among the others, (a) pre-load the configuration file into the device memory prior to deployment of the Demarcation device (green-field scenario only),)
storing the initial configuration file (Hajduczenia (US 20140334822 A1), [0022] Several installation methods may be used, including, among the others, (a) pre-load the configuration file into the device memory prior to deployment of the Demarcation device (green-field scenario only),) and generating from the initial configuration file a final configuration file based on network interface device related information, including Quality of Service information and device identification information, (Hajduczenia (US 20140334822 A1), [0026] In implementations, an automated Demarcation device configuration process can include the following processing stages:
1. Startup of the Demarcation device and DPoE ONU which can be, e.g., a plugged in B-ONU device or connected S-ONU device.
2. Discovery of the DPOE ONU configuration information (including other vendor specific information) by the Demarcation device using the 802.1AB LLDP protocol with the DPoE specific type-length-value (TLV) values.
3. The Demarcation device reaches out to the back-office, announces its presence using, e.g., the Dynamic Host Configuration Protocol (DHCP), provides the backoffice system with additional information about itself, its capabilities etc., and requests a new service configuration file. ([0067] The new service configuration including change of QoS policies.)
4. The back-office system responds to the DHCP request from the Demarcation device, generates the required service configuration file and sends the required service configuration file downstream to the Demarcation device across the DPoE Network using the dedicated L2 transmission path established previously.
5. The Demarcation device receives the service configuration file, parses the received file and configures the services, as needed.
[0063] In the fourth stage, the back-office system receives the request for a service configuration file from the Demarcation device, together with a series of identification parameters for this device by the way of the DHCP option relay. Using the existing back-office automation processes, the Demarc-device specific configuration file is generated, containing among the others definitions of individual service flows, Quality of Service (QoS) parameters, Virtual Local Area Network (VLAN) configuration etc. Such a service configuration file is then delivered to the DPoE System and transmitted downstream to the particular DPoE ONU (using DPoE Network as a transport layer, as defined in the DPoE-SP-ARCH), with the appropriate VLAN tagging. Once at the DPoE ONU, the configuration file is forwarded to the Demarcation device using the default forwarding rules configured on the DPoE ONU for the given L2 transport path.)
receiving address information associated with the network interface device, locating and downloading by the network interface device the final configuration file, (Hajduczenia (US 20140334822 A1), [0023] Once the Demarcation device is configured, a communication path can be established between the Demarcation device (required to be equipped with an IP address) and the back-office system, a new configuration file can be downloaded directly into the Demarcation device using a number of mechanisms, with various flavours of data transfer protocols being used (e.g. TFTP, SFTP, HTTPS etc.).)
Hajduczenia (US 20140334822 A1) does not teach processing the initial configuration by the network interface device when a boot sequence is initiated, and automatically rebooting the network interface device to process the final configuration file.
Hajduczenia (US 20120251113 A1) however in the same field of computer networking teaches processing the initial configuration by the network interface device when a boot sequence is initiated, (Hajduczenia (US 20120251113 A1), Next, once at the DPoE ONU, such parameters are used to drive the configuration of the ONU device, specific configuration rules etc. In case of any changes to the DPoE ONU, service etc. configuration, the device has to be rebooted (power cycled) to go through the process of discovery and registration once again in order to restart the vCM and download the updated CM config file with new service-related parameters.)
and automatically rebooting the network interface device to process the final configuration file. (Hajduczenia (US 20120251113 A1), Next, once at the DPoE ONU, such parameters are used to drive the configuration of the ONU device, specific configuration rules etc. In case of any changes to the DPoE ONU, service etc. configuration, the device has to be rebooted (power cycled) to go through the process of discovery and registration once again in order to restart the vCM and download the updated CM config file with new service-related parameters.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Hajduczenia (US 20140334822 A1) by incorporating the teachings of Hajduczenia (US 20120251113 A1). The motivation/suggestion would have been because there is a need to update the configuration of the CM device (Hajduczenia (US 20120251113 A1), [0024]).
Regarding claim(s) 3, a network interface system,
Hajduczenia (US 20140334822 A1)-Hajduczenia (US 20120251113 A1) teach comprising a network interface device having a controller for controlling the network device and a plurality of ports, wherein one or more of the plurality of ports are associated with a user, (Hajduczenia (US 20140334822 A1), [0051] Once the DPoE ONU comes online and is successfully configured by the network operator, the LLDP Transmitter agent starts sending LLDPDUs (using multicast destination address, as allowed by the 802.1AB LLDP standard) on the port connected to the Demarcation device. In case of S-ONUs equipped with multiple MU/MI ports on the User Network Interface (UNI) side, each port is able to operate an independent LLDP agent to allow for transmission of the LLDPDU across the link to the connected Demarc. The process can be continuous and its frequency can depend on the implementation. The operator is provided with the means to enable/disable LLDP transmission on each of the exposed MU/MI interfaces, allowing the operator to control which of the said ports support he automated configuration and which do not. [0052] After the Demarcation device MAC receives an LLDPDU with the DPoE specific TLV, the Demarcation device MAC parses the received LLDPDU and identifies the requirements for the port configuration to allow for the transmission of the DHCP request to the backoffice system, including among the others: (a) whether the DPoE ONU is configured to operate in the encapsulation or transport mode, (b) what virtual local area network VLAN ID, known as VID, needs to be applied to the DHCP request on the Demarcation device to allow for successful forwarding through the DPoE ONU, etc. The Demarcation device uses this information to configure its port into a state allowing for proper forwarding of frames through the DPoE ONU onto the DPoE Network. DHCP requests generated by the software agent operating on the Demarcation device are processed and encapsulated in a manner consistent with the DPoE ONU default configuration requirements as delivered using the DPoE specific TLV in the LLDPDU. In case of S-ONU, each MU/MI type port can be configured with a dedicated L2 configuration path parameters, so that each Demarcation device potentially connected to such ports is uniquely recognized by the backoffice system and be configured independently. [examiner notes: the Demarcation device interprets to be the network interface device. The operator interprets to be the controller.]) wherein the controller includes memory for storing an initial configuration file associated with the network device, (Hajduczenia (US 20140334822 A1), [0022] Several installation methods may be used, including, among the others, (a) pre-load the configuration file into the device memory prior to deployment of the Demarcation device (green-field scenario only),)
a first server for storing the initial configuration file (Hajduczenia (US 20120251113 A1), [0037] As some point in time, a network operator identifies the need to modify the set of services configured on a D-ONU, resulting in the need to remove an at least one existing service, add at least one new service or simply modify parameters for at least one existing service. In order to do so, the operator may first edit (302) the CM config file (or associated service definitions associated with the given DPoE ONU and stored in the OSS servers), making sure that the DPoE ONU can start using the new CM config file with updated service definitions once and if it is rebooted. Next, using the existing OSS mechanisms, the operator may trigger the vCM to download the updated CM config file (304).) and for generating from the initial configuration file a final configuration file based on network interface device related information, including Quality of Service information and device identification information, (Hajduczenia (US 20140334822 A1), [0026] In implementations, an automated Demarcation device configuration process can include the following processing stages:
1. Startup of the Demarcation device and DPoE ONU which can be, e.g., a plugged in B-ONU device or connected S-ONU device.
2. Discovery of the DPOE ONU configuration information (including other vendor specific information) by the Demarcation device using the 802.1AB LLDP protocol with the DPoE specific type-length-value (TLV) values.
3. The Demarcation device reaches out to the back-office, announces its presence using, e.g., the Dynamic Host Configuration Protocol (DHCP), provides the backoffice system with additional information about itself, its capabilities etc., and requests a new service configuration file. ([0067] The new service configuration including change of QoS policies.)
4. The back-office system responds to the DHCP request from the Demarcation device, generates the required service configuration file and sends the required service configuration file downstream to the Demarcation device across the DPoE Network using the dedicated L2 transmission path established previously.
5. The Demarcation device receives the service configuration file, parses the received file and configures the services, as needed.
[0063] In the fourth stage, the back-office system receives the request for a service configuration file from the Demarcation device, together with a series of identification parameters for this device by the way of the DHCP option relay. Using the existing back-office automation processes, the Demarc-device specific configuration file is generated, containing among the others definitions of individual service flows, Quality of Service (QoS) parameters, Virtual Local Area Network (VLAN) configuration etc. Such a service configuration file is then delivered to the DPoE System and transmitted downstream to the particular DPoE ONU (using DPoE Network as a transport layer, as defined in the DPoE-SP-ARCH), with the appropriate VLAN tagging. Once at the DPoE ONU, the configuration file is forwarded to the Demarcation device using the default forwarding rules configured on the DPoE ONU for the given L2 transport path.)
wherein the first server can be configured to assign an internet protocol (IP) address to the network device, and (Hajduczenia (US 20120251113 A1), [0023] Once the Demarcation device is configured, a communication path can be established between the Demarcation device (required to be equipped with an IP address) and the back-office system, a new configuration file can be downloaded directly into the Demarcation device using a number of mechanisms, with various flavours of data transfer protocols being used (e.g. TFTP, SFTP, HTTPS etc.).)
a relay server for identifying selected device information associated with the network interface device, (Hajduczenia (US 20140334822 A1), [0034] The DPoE System can implement a DHCP snooper/helper agent for picking up DHCP requests received from the L2 configuration path configured on the given DPoE System and forwarding it to the backoffice for proper handling. In some implementations, the DHCP server responsible for handling the DHCP requests from the Demarcation device may be separate from a DHCP server used for other purposes in the DPoE Network. [0056] In the third stage, the Demarcation device generates the DHCP request. The DHCP discovery/request sourced from the Demarcation device is suggested to carry a number of populated option fields, including among the others, the unique identification of the Demarcation device, comprising its MAC address, and optionally, its public certificate or any other unique identifier allowing the back-office system to distinguish this particular device from any other such device on the network. [examiner notes: the DHCP server interprets to be the relay server.])
wherein the controller includes a processor that can execute suitable instructions to, upon
boot up, download and execute the final configuration file. (Hajduczenia (US 20120251113 A1), Next, once at the DPoE ONU, such parameters are used to drive the configuration of the ONU device, specific configuration rules etc. In case of any changes to the DPoE ONU, service etc. configuration, the device has to be rebooted (power cycled) to go through the process of discovery and registration once again in order to restart the vCM and download the updated CM config file with new service-related parameters.)
The same motivation to combine as the independent claim 1 applies here.
With respect to dependent claims:
Regarding claim(s) 2, method of claim 1
Hajduczenia (US 20140334822 A1)-Hajduczenia (US 20120251113 A1) teach wherein the step of receiving address information comprises receiving a media access control (MAC) address. (Hajduczenia (US 20140334822 A1), [0056] In the third stage, the Demarcation device generates the DHCP request. The DHCP discovery/request sourced from the Demarcation device is suggested to carry a number of populated option fields, including among the others, the unique identification of the Demarcation device, comprising its MAC address, and optionally, its public certificate or any other unique identifier allowing the back-office system to distinguish this particular device from any other such device on the network.)
2. Claim(s) 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Hajduczenia (US 20140334822 A1) in view of Hajduczenia (US 20120251113 A1) further in view of Guim (US 20210144517 A1). Bencheck (US20140280807A1).
Regarding claim(s) 4, system of claim 3,
Hajduczenia (US 20140334822 A1)-Hajduczenia (US 20120251113 A1) does not teach wherein the selected device information comprises location information associated indicative of the location of the network interface device.
Bencheck however in the same field of computer networking teaches wherein the selected device information comprises location information associated indicative of the location of the network interface device. (Bencheck, [0017] The NID management system 120 may include an input/output module 122 for sending and receiving data, a discovery module 124 for determining the identification of a network interface device (NID), and a configuration module 126 for determining a location and configuration of a NID.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Hajduczenia (US 20140334822 A1) by incorporating the teachings of Bencheck. The motivation/suggestion would have been because there is a need for automatically discovering and configuring NIDs using Service Operations, Administration and Maintenance (SOAM). (Bencheck, [0007]).
Regarding claim(s) 5, system of claim 3,
Hajduczenia (US 20140334822 A1)-Hajduczenia (US 20120251113 A1)- Bencheck teach wherein the device identification information includes a media control access (MAC) address. (Hajduczenia (US 20140334822 A1), [0034] The DPoE System can implement a DHCP snooper/helper agent for picking up DHCP requests received from the L2 configuration path configured on the given DPoE System and forwarding it to the backoffice for proper handling. In some implementations, the DHCP server responsible for handling the DHCP requests from the Demarcation device may be separate from a DHCP server used for other purposes in the DPoE Network. [0056] In the third stage, the Demarcation device generates the DHCP request. The DHCP discovery/request sourced from the Demarcation device is suggested to carry a number of populated option fields, including among the others, the unique identification of the Demarcation device, comprising its MAC address, and optionally, its public certificate or any other unique identifier allowing the back-office system to distinguish this particular device from any other such device on the network. [examiner notes: the DHCP server interprets to be the relay server.])
The same motivation to combine as the dependent claim 3 applies here.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
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.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights