DETAILED ACTION
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 .
Response to Amendment
This Action is in response to amendment/ election filed on 04/30/2025.
Claims 16-20 have been cancelled and claims 21-25 are newly added.
Claims 1, 13 and 21 are independent claims in this application.
Claims 1-15 and 21-25 are presented for examination, and remain pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/29/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS is being considered by the examiner.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claim(s) 3 and 14-15 is/are objected to because of the following informalities:
Claim 3 recites the limitation “the group” in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claims 14-15 recite “the first device configuration request messages” in line 2. Examiner suggests amending them to recite “the first device configuration request messages”
Appropriate correction is required.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3, 7-10, 12-15 and 21 is/are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Bigall (US 20140052830 A1).
Regarding claim 1, Bigall discloses a method of obtaining device configuration information (see [0034]-[0040]; also see [0023]; controller determine the entire and complete configuration for the client IHS, and then send that determined configuration to the client IHS; also see [0014]-[0015]; DHCP allows a computer to obtain its network configuration over the network before that computer has been configured to use the network), the method comprising:
transmitting (see Fig.4:408a), by a network device (see Fig.4:402 “Client IHS”; also see Fig.1:100 in view of [0012]-[0013]; an information handling system (IHS) may be a personal computer, a PDA, a consumer electronic device, a display device or monitor, a network server or storage device, a switch router or other network communication device), a first device configuration request message (see [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c; also see [0016]; the client IHS 202 sending a discover message requesting a network configuration; also see [0015]; the client IHS is used to communicate with the DHCP server… to request and receive network configuration information) for reception at a network address assignment server (see Fig.4:406 and/or 404; see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; examiner articulates that the DHCP server that provide configuration message including IP Addresses assignments corresponds to the claimed “network address assignment server”);
transmitting (see Fig.4:408b), by the network device (see Fig.4:402) and prior to receiving a response (see Fig.4:410a-c) to the first device configuration request message (see Fig.4: 408a), a second device configuration request message (see [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c) for reception at the network address assignment server (see Fig.4:406 and/or 404; also see [0032]-[0033] in view of Fig.3:304-306; the DHCP server 406 in the controller 404 receives the discover messages 408a, 408b, and 408c over the network from the client IHS 402 and determines whether all of the discover messages have been received by checking whether each discover message in the sequence has been received. If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data);
receiving, by the network device (see Fig.4:402), a device configuration response message (see Fig.4:410a-c) from the network address assignment server (see Fig.4:406 and/or 404) in response to the first device configuration request message (see Fig.4:408a) or the second device configuration request message (see Fig.4:408b; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data; The controller 404 is operable to process the capability data in the capability message, determine a configuration message that includes configuration data for the client IHS 402, and provide that configuration data to the DHCP server 406; The offer messages may then be created by the DHCP server 406 using the configuration message including the configuration data in substantially the same manner as discussed above for the discover messages created by the client IHS 402 using the capability message including the capability data. Thus, the offer messages sent at block 306 of the method 300 may include offer messages 410a, 410b, and 410c that each include configuration data, which are portions of the configuration message, provided in DHCP options; also see [0024]; the "tunnel" provided through the DHCP server 406 allows for the exchange of relatively large capability and configuration messages by breaking them into pieces that can be transported using the traditional DHCP protocol); and
configuring, by the network device (see Fig.4:402 “Client IHS”; also see Fig.1:100), a network interface (see Fig.1:116 in view of [0012]-[0013]; IHS 100 includes network interface controllers (NICs) 116) based on information in the device configuration response message (see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; also see [0037]-[0040]; the client IHS 402 has all the configuration data necessary to configure the IHS 402; either immediately following the determination that the client IHS 402 has received all of the offer messages at decision block 308, or upon receiving the acknowledge message 414, the client IHS 402 may stop any modified DHCP clients that are running, construct the configuration message from the configuration data, and/or apply the configuration data received in the offer messages at block 306 in order to completely configure the client IHS 402).
Regarding claim 2, Bigall discloses the method defined in claim 1, as set forth above. In addition, Bigall further discloses wherein the first device configuration request message (see Fig.4:408a) comprises a first Dynamic Host Configuration Protocol (DHCP) message (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see [0024]; configuring IHS's using DHCP communications; the "tunnel" provided through the DHCP server 406 allows for the exchange of relatively large capability and configuration messages by breaking them into pieces that can be transported using the traditional DHCP protocol) containing a first device identifier of the network device (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number) and wherein the second device configuration request message (see Fig.4:408b) comprises a second DHCP message (see [0023]-[0024]) containing a second device identifier of the network device (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… MAC address).
Regarding claim 3, Bigall discloses the method defined in claim 2, as set forth above. In addition, Bigall further discloses wherein the first and second device identifiers comprise two device identifiers selected from the group consisting of: a device serial number, a device hardware address, a domain name system (DNS) name, a link-layer address with time information, a link- layer address, an enterprise number with additional enterprise- specific information, and a universally unique identifier (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number, … MAC address).
Regarding claim 7, Bigall discloses the method defined in claim 1, as set forth above. In addition, Bigall further discloses wherein the first device configuration request message comprises a first message associated with a first protocol (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see [0024]; configuring IHS's using DHCP communications) and wherein the second device configuration request message comprises a second message associated with a second protocol (see [0027]; DHCP is a broadcast User Datagram Protocol (UDP); also see [0044]; UDP broadcast protocol).
Regarding claim 8, Bigall discloses the method defined in claim 1, as set forth above. In addition, Bigall further discloses wherein the network device is awaiting, during at least partially overlapping periods of time, responses to the first and second device configuration request messages (see [0032] After sending final discover message 208c, the modified DHCP client in the client IHS 402 waits for a response; the DHCP server 406 in the controller 404 receives the discover messages 408a, 408b, and 408c over the network from the client IHS 402 and determines whether all of the discover messages have been received by checking whether each discover message in the sequence has been received; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data; also see [0044]; a predetermined time interval passing without receiving an offer message including capability data).
Regarding claim 9, Bigall discloses the method defined in claim 1, as set forth above. In addition, Bigall further discloses:
transmitting, by the network device (see Fig.4:402 “Client IHS”; also see Fig.1:100) and prior to receiving responses to the first and second device configuration request messages (see Fig.4: 410a-b), a third device configuration request message (see Fig.4:408c in view of [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c; In an example, the capability message may include capability data that requires three discover messages to be created and sent to the controller 404); and
transmitting, by the network device (see Fig.4:402 “Client IHS”; also see Fig.1:100) and prior to receiving responses to the first, second, and third device configuration request messages, a fourth device configuration request message (see [0031]; In an example, the capability message may include capability data that requires three discover messages to be created and sent to the controller 404, although one of skill in the art will recognize any number of discover messages may be used to send a capability message from the client IHS 402 to the controller 404, depending on the amount of capability data needed by the controller 404 to provide a complete configuration for the client IHS 402; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data).
Regarding claim 10, Bigall discloses the method defined in claim 9, as set forth above. In addition, Bigall further discloses wherein the network device is awaiting, during at least partially overlapping periods of time, responses to the first, second, third, and fourth device configuration request messages (see [0032] After sending final discover message 208c, the modified DHCP client in the client IHS 402 waits for a response; the DHCP server 406 in the controller 404 receives the discover messages 408a, 408b, and 408c over the network from the client IHS 402 and determines whether all of the discover messages have been received by checking whether each discover message in the sequence has been received; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data; also see [0044]; a predetermined time interval passing without receiving an offer message including capability data).
Regarding claim 12, Bigall discloses the method defined in claim 1, as set forth above. In addition, Bigall further discloses wherein the information in the device configuration response message comprises at least one of an assigned network address of the network device, subnet mask information, default gateway information, domain name system (DNS) server information, or domain name information (see [0034] and the table that follows; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses,… Subnet Mask; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; also see [0017]; the offer message may include the following information: Default gateway: 192.168.96.1 Domain Name Servers: 10.128.40.50 10.128.40.79 Domain Name: scalent.dell.com; also see [0024]; the "tunnel" provided through the DHCP server 406 allows for the exchange of relatively large capability and configuration messages by breaking them into pieces that can be transported using the traditional DHCP protocol).
Regarding claim 13, Bigall discloses one or more non-transitory computer-readable storage media (see Fig.1:114 in view of [0013]) comprising computer-executable instructions that, when executed by one or more processors (see Fig.1:102 in view of [0013]) in a network device (Fig.1:100; also see Fig.4:402 “Client IHS”; also see [0025]; IHS 402 may include a non-transitory, computer-readable medium having instructions that, when executed by one or more processors), cause the one or more processors (see Fig.1:102) to:
send first and second device configuration request messages (see Fig.4:408a-b) containing different information (see [0027]; Because the capability message includes capability data that will typically exceed the allowable size for a single DHCP packet payload, multiple discover messages including capability data that provides portions of the capability message are created by the client IHS 402), wherein the one or more processors are awaiting, during at least a portion of a period of time, responses to the first and second device configuration request messages (see [0032] After sending final discover message 208c, the modified DHCP client in the client IHS 402 waits for a response; the DHCP server 406 in the controller 404 receives the discover messages 408a, 408b, and 408c over the network from the client IHS 402 and determines whether all of the discover messages have been received by checking whether each discover message in the sequence has been received; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data; also see [0044]; a predetermined time interval passing without receiving an offer message including capability data);
receive a device configuration response message (see Fig.4:410a-c) from a network address assignment server (see Fig.4:406 and/or 404; see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; examiner articulates that the DHCP server that provide configuration message including IP Addresses assignments corresponds to the claimed “network address assignment server”) that is responsive to the first device configuration request message (see Fig.4:408a) or the second device configuration request message (see Fig.4:408b) within the time period (see [0032]-[0033] and [0044]); and
complete a message exchange operation based on the device configuration response message to obtain a network address for the network device (see Fig.4:406 and/or 404; see [0031]-[0039]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; apply the configuration data received in the offer messages at block 306 in order to completely configure the client IHS 402; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1).
Regarding claim 14, Bigall discloses the one or more non-transitory computer-readable storage media defined in claim 13, as set forth above. In addition, Bigall further discloses wherein the first device configuration request messages (see Fig.4:408a) is sent based on a first protocol (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see [0024]; configuring IHS's using DHCP communications) and the second device configuration request message (see Fig.4:408b) is sent based on a second protocol (see [0027]; DHCP is a broadcast User Datagram Protocol (UDP); also see [0044]; UDP broadcast protocol), wherein the received device configuration response message (see Fig.4:410a-c) is responsive to the second device configuration request message (see Fig.4:408b), and wherein the message exchange operation is completed based on the second protocol (see [0027]; DHCP is a broadcast User Datagram Protocol (UDP); also see [0044]; UDP broadcast protocol).
Regarding claim 15, Bigall discloses the one or more non-transitory computer-readable storage media defined in claim 13, as set forth above. In addition, Bigall further discloses wherein the first device configuration request messages (see Fig.4:408a) contains a first device identifier for the network device (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number) and the second device configuration request message (see Fig.4:408b) contains a second device identifier for the network device (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… MAC address), wherein the received device configuration response message (see Fig.4:410a-c) is responsive to the first device configuration request message (see Fig.4:408a) and based on the first device identifier, and wherein the message exchange operation is completed based on the first device identifier (see Fig.4:406 and/or 404; see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; also see [0024]; the "tunnel" provided through the DHCP server 406 allows for the exchange of relatively large capability and configuration messages by breaking them into pieces that can be transported using the traditional DHCP protocol).
Regarding claim 21, Bigall discloses a network device (see Fig.4:402 “Client IHS”; also see Fig.1:100 in view of [0012]-[0013]; an information handling system (IHS) may be a personal computer, a PDA, a consumer electronic device, a display device or monitor, a network server or storage device, a switch router or other network communication device) comprising:
a packet processor (see Fig.1:116);
memory circuitry (see Fig.1:114); and
processing circuitry (see Fig.1:102) coupled to the memory circuitry (see Fig.1:114) and the packet processor (see Fig.1:116) and configured to:
send a first device configuration request message (see Fig.4:408a; also see [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c; also see [0016]; the client IHS 202 sending a discover message requesting a network configuration; also see [0015]; the client IHS is used to communicate with the DHCP server… to request and receive network configuration information);
send a second device configuration request message (see Fig.4:408b; also see [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c), wherein the first and second device configuration request messages (see Fig.4:408a-b) are pending in parallel for at least a portion of a time period (see [0032] After sending final discover message 208c, the modified DHCP client in the client IHS 402 waits for a response; the DHCP server 406 in the controller 404 receives the discover messages 408a, 408b, and 408c over the network from the client IHS 402 and determines whether all of the discover messages have been received by checking whether each discover message in the sequence has been received; also see [0033]; If at decision block 304 it is determined that all of the discover messages have been received, the method 300 proceeds to block 306 where the controller 404 sends offer messages including configuration data; also see [0044]; a predetermined time interval passing without receiving an offer message including capability data); and
in response to receiving a device configuration response message (see Fig.4:410a-c) from a network address assignment server (see Fig.4:406 and/or 404; see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; examiner articulates that the DHCP server that provide configuration message including IP Addresses assignments corresponds to the claimed “network address assignment server”) responsive to the first device configuration request message (see Fig.4:408a) or the second device configuration request message (see Fig.4:408b), configure a network interface using device configuration information in the device configuration response message (see Fig.4:406 and/or 404; see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1).
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, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bigall (US 20140052830 A1) in view of Zhu et al. (hereinafter, Zhu, US 20200404499 A1).
Regarding claim 4, Bigall discloses the method defined in claim 2, as set forth above. In addition, Bigall further discloses wherein the first DHCP message is a first discover message (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see Fig.4:408a that shows “DISCOVER MESSAGE”) containing the first device identifier, wherein the second DHCP message is a second discover message (see Fig.4:408b that shows “DISCOVER MESSAGE”) containing the second device identifier (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number, … MAC address), and wherein the device configuration response message is a offer message (see Fig.4:410a that shows “OFFER MESSAGE CONTAINING CONGIGURATION”).
Although, and as set forth above, Bigall discloses DHCP discover messages and DHCP offer message (see Fig.4: Fig.4:408a-b and 410b), Bigall does not explicitly disclose that these DHCP messages are DHCPv4 messages.
However, in an analogous art, Zhu discloses wherein the first DHCP message is a first Dynamic Host Configuration Protocol version 4 (DHCPv4) discover message, wherein the second DHCP message is a second DHCPv4 discover message, and wherein the device configuration response message is a DHCPv4 offer message (see [0275]; if the access message is a DHCP discover message of a DHCPv4 message, the feedback message may be a DHCP offer message of the DHCPv4 message).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zhu with Bigall so that the first DHCP message is a first Dynamic Host Configuration Protocol version 4 (DHCPv4) discover message containing the first device identifier, the second DHCP message is a second DHCPv4 discover message containing the second device identifier, and that the device configuration response message is a DHCPv4 offer message.
One of ordinary skill in the art would have been motivated to enable the terminal to access the serving network, thereby expanding a usage scenario of the serving network and improving the user experience (Zhu: [0023] and [0292]).
Regarding claim 5, Bigall discloses the method defined in claim 2, as set forth above. In addition, Bigall further discloses wherein the first DHCP message is a first message (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see Fig.4:408a) containing the first device identifier, wherein the second DHCP message is a second message (see Fig.4:408b) containing the second device identifier (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number, … MAC address), and wherein the device configuration response message is a DHCP message (see Fig.4:410a in view of [0023]; The present disclosure describes a system and method that uses DHCP communications).
Although, and as set forth above, Bigall discloses DHCP messages (see Fig.4: Fig.4:408a-b and 410b in view of [0023]), Bigall does not explicitly disclose that these DHCP messages are DHCPv6 solicit and advertise messages.
However, in an analogous art, Zhu discloses wherein the first DHCP message is a first Dynamic Host Configuration Protocol version 6 (DHCPv6) solicit message, wherein the second DHCP message is a second DHCPv6 solicit message, and wherein the device configuration response message is a DHCPv6 advertise message (see [0275]; If the access message is a DHCP solicit message of a DHCPv6 message, the feedback message may be a DHCP advertise message of the DHCPv6 message).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zhu with Bigall so that the first DHCP message is a first Dynamic Host Configuration Protocol version 6 (DHCPv6) solicit message containing the first device identifier, the second DHCP message is a second DHCPv6 solicit message containing the second device identifier, and that the device configuration response message is a DHCPv6 advertise message.
One of ordinary skill in the art would have been motivated to enable the terminal to access the serving network, thereby expanding a usage scenario of the serving network and improving the user experience (Zhu: [0023] and [0292]).
Regarding claim 6, Bigall discloses the method defined in claim 2, as set forth above. In addition, Bigall further discloses wherein the first DHCP message is a first DHCP information request message (see [0023]; The present disclosure describes a system and method that uses DHCP communications; also see Fig.4:408a; also see [0016]; the client IHS 202 sending a discover message requesting a network configuration; also see [0015]; the client IHS is used to communicate with the DHCP server… to request and receive network configuration information) containing the first device identifier, wherein the second DHCP message is a second DHCP information request message (see Fig.4:408b; also see [0016]; the client IHS 202 sending a discover message requesting a network configuration; also see [0015]; the client IHS is used to communicate with the DHCP server… to request and receive network configuration information) containing the second device identifier (see [0025] and the table that follows; the client IHS 402 sends discover messages including capability data… The capability message may include capability data providing information about hardware resources available on the client IHS 402 and/or a variety of other capability data known in the art. For example, a capability message for the client IHS 402 may include… serial number, … MAC address), and wherein the device configuration response message is a DHCP reply message (see Fig.4:410a in view of [0023]; The present disclosure describes a system and method that uses DHCP communications).
Although, and as set forth above, Bigall discloses DHCP information request messages and DHCP reply message (see Fig.4: Fig.4:408a-b and 410b in view of [0023]), Bigall does not explicitly disclose that these DHCP messages are DHCPv6 messages.
However, in an analogous art, Zhu discloses wherein the first DHCP message is a first Dynamic Host Configuration Protocol version 6 (DHCPv6) information request message, wherein the second DHCP message is a second DHCPv6 information request message, and wherein the device configuration response message is a DHCPv6 reply message (see [0275]; If the access message is a DHCP request message of the DHCPv6 message, the feedback message may be a DHCP reply message of the DHCPv6 message).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zhu with Bigall so that the first DHCP message is a first Dynamic Host Configuration Protocol version 6 (DHCPv6) information request message containing the first device identifier, the second DHCP message is a second DHCPv6 information request message containing the second device identifier, and that the device configuration response message is a DHCPv6 reply message.
One of ordinary skill in the art would have been motivated to enable the terminal to access the serving network, thereby expanding a usage scenario of the serving network and improving the user experience (Zhu: [0023] and [0292]).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bigall (US 20140052830 A1) in view of Qiang (US 20140066047 A1).
Regarding claim 11, Bigall discloses the method defined in claim 1, as set forth above, including configured network interface (see [0034]; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1; also see [0037]-[0040]).
Bigall does not explicitly disclose obtaining, by the network device, bootstrapping data for device provisioning using the configured network interface.
However, in an analogous art, Qiang discloses obtaining, by the network device, bootstrapping data for device provisioning using the configured network interface (see [0041] In one embodiment, the Root Identifier is provisioned in the UE, and the UE is configured to transfer or otherwise indicate the Root Identifier to the 3GPP network as part of 3GPP bootstrapping (i.e., during attachment by the UE to the 3GPP network); also see [0072]-[0081] that discloses provisioning procedure(s) that involves M2M bootstrapping request, where the machine type device 16 indicates a request for M2M subscription activation and the MTC Server 66 responds to the machine type device 16 to confirm the acceptance of the bootstrapping).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Qiang with Bigall to obtain, by the network device, bootstrapping data for device provisioning using the configured network interface.
One of ordinary skill in the art would have been motivated to support automatic provisioning in the wireless network domain, using protocol-based signaling (Qiang: [0026] and [0128]).
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bigall (US 20140052830 A1) in view of KURMALA et al. (hereinafter, KURMALA, US 20220353147 A1).
Regarding claim 22, Bigall discloses a network device defined in claim 21, as set forth above, including wherein the first and second device configuration request messages are sent (see Fig.4:408a - 408b; also see [0031] and [0015]-[0016]).
Bigall does not explicitly disclose wherein the network device is an un-provisioned network device and wherein the first and second device configuration request messages are sent to perform a device self-provisioning operation.
However, in an analogous art, KURMALA discloses wherein the network device is an un-provisioned network device and wherein the first and second device configuration request messages are sent to perform a device self-provisioning operation (see [0030]; ZTP is a feature implemented by network devices, such as switches, that allows the devices to be provisioned and configured automatically; the network device sends out a request through DHCP (Dynamic Host Configuration Protocol) or TFTP (Trivial File Transfer Protocol) to get the location of its centrally stored image and configuration, which it downloads and runs. Thereafter, ZTP automates steps like updating operating systems, deploying patches and bug fixes, and implementing added features prior to connecting the network device to the network. The tool carries out basic configuration, after which the switch can be deployed in an environment where custom configuration changes are made).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of KURMALA with Bigall so that the network device is an un-provisioned network device and wherein the first and second device configuration request messages are sent to perform a device self-provisioning operation.
One of ordinary skill in the art would have been motivated to eliminate most of the manual labor involved with adding the network devices, such as switches to a network (KURMALA: [0030]).
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bigall (US 20140052830 A1) in view of KURMALA et al. (hereinafter, KURMALA, US 20220353147 A1) in view of Qiang (US 20140066047 A1).
Regarding claim 23, Bigall (modified by KURMALA) discloses a network device defined in claim 22, as set forth above, including configuring network interface (see Bigall [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1), and provisioning the un-provisioned network device (see KURMALA [0030]).
Bigall (modified by KURMALA) does not explicitly disclose wherein the processing circuitry is configured to: obtain bootstrapping data using the configured network interface; and process the bootstrapping data to provision the un-provisioned network device.
However, in an analogous art, Qiang discloses wherein the processing circuitry is configured to:
obtain bootstrapping data using the configured network interface (see [0041] In one embodiment, the Root Identifier is provisioned in the UE, and the UE is configured to transfer or otherwise indicate the Root Identifier to the 3GPP network as part of 3GPP bootstrapping (i.e., during attachment by the UE to the 3GPP network); also see [0072]-[0081] that discloses provisioning procedure(s) that involves M2M bootstrapping request, where the machine type device 16 indicates a request for M2M subscription activation and the MTC Server 66 responds to the machine type device 16 to confirm the acceptance of the bootstrapping); and
process the bootstrapping data to provision the un-provisioned network device (see [0041] In one embodiment, the Root Identifier is provisioned in the UE, and the UE is configured to transfer or otherwise indicate the Root Identifier to the 3GPP network as part of 3GPP bootstrapping (i.e., during attachment by the UE to the 3GPP network); also see [0072]-[0081] that discloses provisioning procedure(s) that involves M2M bootstrapping request, where the machine type device 16 indicates a request for M2M subscription activation and the MTC Server 66 responds to the machine type device 16 to confirm the acceptance of the bootstrapping).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Qiang with Bigall and KURMALA so that the processing circuitry is configured to: obtain bootstrapping data using the configured network interface; and process the bootstrapping data to provision the un-provisioned network device.
One of ordinary skill in the art would have been motivated to support automatic provisioning in the wireless network domain, using protocol-based signaling (Qiang: [0026] and [0128]).
Claim(s) 24-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bigall (US 20140052830 A1) in view of Yamashita (US 20060173988 A1).
Regarding claim 24, Bigall discloses a network device defined in claim 21, as set forth above, including at least the first and second device configuration request messages within the time period (see [0031]; the client IHS 402 sending the discover messages 408a, 408b, and 408c; also see [0032]-[0033], [0042] and [0044]). Bigall does not explicitly disclose in response to not receiving responses to at least the first and second device configuration request messages within the time period, send two or more additional device configuration request messages that are pending in parallel for at least a portion of an additional time period.
However, in an analogous art, Yamashita discloses in response to not receiving responses to at least the first and second device configuration request messages within the time period, send two or more additional device configuration request messages that are pending in parallel for at least a portion of an additional time period (see [0064]; Since the IP telephone terminals 22-1 to 22-n cannot obtain a response because a malfunction has occurred in the transmission line 100, the terminals resend a DHCP Discover (c4 to c6 in FIG. 10) every 4, 8, 16, and 32 seconds, for example, and wait for a response for about 2 minutes from the first send).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yamashita with Bigall so that in response to not receiving responses to at least the first and second device configuration request messages within the time period, the processing circuitry is configured to send two or more additional device configuration request messages that are pending in parallel for at least a portion of an additional time period.
One of ordinary skill in the art would have been motivated to re-register the address in the backup system control device when a malfunction has occurred in the interstation transmission line (see [0011]).
Regarding claim 25, Bigall (modified by Yamashita) discloses a network device defined in claim 24, as set forth above, including sending two or more additional device configuration request messages that are pending in parallel for at least a portion of an additional time period (see Yamashita [0064]). In addition, Yamashita also teaches receiving a device configuration response message responsive to one of the two or more additional device configuration request messages (see [0071]; DHCP Discover is sent (d5 in FIG. 11), and an IP address request is provided to the address management device 12… the IP telephone terminals 22-1 to 22-n acquire an IP address from the address management device 12).
Similarly, and as set forth above, Bigall already teaches in response to receiving a device configuration response message responsive to one of the two or more additional device configuration request messages, configure a network interface using device configuration information in the device configuration response message responsive to the one of the two or more additional device configuration request messages (see [0034]; the configuration message including configuration data determined from the capability data may provide for a complete configuration of the client IHS 402; For example, a configuration message for the client IHS 402 may include… IP Addresses; also see [0022]; when providing a network configuration …, the DHCP server may attempt to assign an address to NIC1).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yamashita with Bigall so that in response to receiving a device configuration response message responsive to one of the two or more additional device configuration request messages, the processing circuitry is configured to configure a network interface using device configuration information in the device configuration response message responsive to the one of the two or more additional device.
One of ordinary skill in the art would have been motivated to re-register the address in the backup system control device when a malfunction has occurred in the interstation transmission line (see [0011]).
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
ASAKURA (US 20230300932 A1) executes a Device Provisioning Protocol with request using a bootstrapping key.
Kerr et al. (US 20090185564 A1) forwards the DHCP IP request to the DHCP server that results in the automatic provisioning of customer equipment.
Chen et al. (US 20140215034 A1) discloses automatically setting Internet access mode.
ZHU et al. (US 20140074997 A1) resends a DHCP DISCOVER to the DHCP server if a VM doesn’t receive a response from the DHCP server within a period of time.
Gardiner et al. (US 20030225864 A1) discloses maximum number of attempts to resend the broadcasted DHCP discover packet.
Loewenthal et al. (US 20140297818 A1) teaches parallel querying of multiple network interfaces for communication configuration information.
LIN et al. (WO 2017092519 A1) discloses sending multiple discovery messages corresponding to multiple protocols to the network server in a parallel manner.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453