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 Arguments
Applicant's arguments filed 8/24/2026 have been fully considered, but cannot be held as persuasive.
On page 11, Applicant argues:“Neither Rong nor Ackermann teaches a particular port-based tenant-attribute determination at the DHCP relay. Even more, the references do not teach the combination of (i) identifying the ingress switch port from which the DHCP broadcast was received and (ii) retrieving the tenant attribute information from a mapping associated with that port.”
In response, the Examiner notes that Rong discusses such “port-based tenant-attribute determination at the DHCP relay” as illustrated by Rong’s Fig. 6. The DHCP client 210 sends a DHCP DISCOVER message (note that a DHCP DISCOVER is inherently sent via broadcast; in addition, Ackermann in [47-50] specifically notes such messages are broadcast). The DHCP Relay 220 then augments this DHCP DISCOVER with a “TENANT SPECIFIC OPTION” before relaying the augmented message to the DHCP Server 230. As [32-38] and [92] of Rong discuss, the tenant-specific options added to the DHCP message are determined based on a mapping from the VAP (virtual access point), as discussed in Rong’s [9,38,92] and [101]. The VAP, as [92] states, “can be physical ports or virtual ports” (including those of a switch, or vSwitch as discussed in [92]) utilized by the DHCP client shown in Fig. 6. [101] notes the “DHCP relay agent 420 derives its VNID from an associated VAP.” [32-38] of Rong notes that this VNID is a part of the above discussed tenant-specific option added by the relay to the DHCP message.
Continuing on page 11, Applicant argues:“There is no apparent reason why one of ordinary skill in the art would modify their
teachings to arrive at the claimed arrangement.”
In response, the Examiner notes that such a reason was provided as part of the 103 analysis presented in the 7/9/2026 Non-Final Rejection.
The remaining arguments rely on the rationale addressed above, and thus cannot be held as persuasive.
Finally, while not presently relied upon, use of a mapping between an ingress switch port and tenant attribute information is well-known in the prior art. For example, Dell Networking (Dell Networking SONiC. "How to Configure Virtual Routing and Forwarding". https://www.dell.com/support/kbdoc/en-us/000218893/dell-networking-sonic-how-to-configure-virtual-routing-and-forwarding-vrf?msockid=00fbf38d287f6fb71e08e46e29c16ea4. (Year: 2023)) details a process on pages 2 – 3 that, as illustrated on the figure spanning pages 2 – 3, derive tenant information such as a particular VRF based on a correspondence from a particular port to a particular VLAN ID. Similarly, Wang (US-20190199631-A1) discusses in [2,11,14] how ports are linked to particular tenants, and [88-94] how a port association can be used to determine a particular VRF associated with the tenant.
Claim Rejections - 35 USC § 103
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.
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.
Claims 1, 2, 10 – 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rong (US-20230108856-A1) in view of Ackermann (US-20060209714-A1).
Regarding claim 1, Rong shows a multi-tenant Dynamic Host Configuration Protocol (DHCP) server system comprising a DHCP relay agent and a DHCP server, the DHCP server system comprising one or more hardware processors memory storing computer instructions, the computer instructions when executed by the one or more hardware processors configured to perform: in a first process: obtaining, by the DHCP relay agent (Fig. 6, item 220, discussed further in [27,77,80] and in Fig. 4), a first DHCP message (Fig. 6 step 231 and [95]) from a first host (Fig. 6, client 219) within a first Virtual Local Area Network (VLAN) ([37,89,92]); determining, by the DHCP relay agent, first tenant attribute information ([31]) of the first host ([92] where the determination is implicit given that the agent adds the tenant attribute information to the header) based on switch configuration ([40]) information ([92], see “internal vSwitch interface ID”), the switch configuration information including a mapping between an ingress switch port associated with the first host and the first tenant attribute information ([32-38] discussing the values of a tenant-specific option, which includes support for mapping a VAP to a VNID, the VNID being part of said tenant-specific option), the determining the first tenant attribute information ([92] noting this can be done via “consulting the local cache”) including identifying the particular ingress switch port from which the first DHCP message was received (that is, the VAP “on which the DHCP client connects” as noted in [38]; [92] continues to clarify that the VAP can be a physical port or a virtual port) and retrieving the first tenant attribute information from the mapping ([38] discussing where “the VNID can be determined from . . .” and [92], see “that consists of the mapping between VNID and tenant ID”). augmenting, by the DHCP relay agent ([90], see “added to a DHCP header by a DHCP relay agent”), the first DHCP message with the determined first tenant attribute information ([92] discussing the “tenant-specific option added to the DHCP header by a DHCP relay agent”, see also Fig. 6 steps 231 to 232); transmitting, by the DHCP relay agent, the augmented first DHCP message to the DHCP server ([94] discussing the augmented information sent to the server and utilized for IP address assignment); in a second process: obtaining, by the DHCP relay agent (Fig. 6, item 220), a second DHCP message (Fig. 6 step 231 and [95]) from a second host within a second VLAN ([37,89,92] and [94] which discusses that the DHCP relay agent and DHCP server functionality cited above is performed on behalf of “networks of different tenants” in order to “serve all DHCP clients”, suggesting repeating the process for each tenant and for each tenants respective clients); determining, by the DHCP relay agent, second tenant attribute information of the second host based on the switch configuration information ([92]); augmenting, by the DHCP relay agent, the second DHCP message with the determined second tenant attribute information ([92]); converting, by the DHCP relay agent, the second DHCP message to a unicast form; and transmitting, by the DHCP relay agent, the augmented second DHCP message to the DHCP server ([94-95] discussing the “DHCP discover” message with “tenant specific options”); and in a third process: identifying, based on the unicast augmented first DHCP message, by the DHCP server, a first tenant associated with the first host ([94] which suggests repeating the above process for each host of each tenant); identifying, based on the augmented second DHCP message, by the DHCP server, a second tenant associated with the second host ([94]); assigning, by the DHCP server, a first Internet Protocol (IP) address to the first host ([94-96]) from a first allocated subspace of IP addresses for the first tenant and a second IP address to the second host from a second allocated subspace of IP addresses for the second tenant ([97] where “each tenant has a specific address pool” and “IP range”; see also [101]); and
provisioning first tenant configuration parameters for the first host and second tenant configuration parameters for the second host ([94] discussing to “deliver the DHCP replay message to the DHCP client accordingly”). Rong does not show: where the first DHCP message is broadcast,
converting, by the DHCP relay agent, the first broadcasted DHCP message to a unicast form;
processing and transmitting a unicast DHCP message.
Ackermann shows: where the first DHCP message is broadcast ([47-50] discussing responsive “IP address assignment based on the DHCP protocol” including where a “request message (DHCP-Discover) of the client is sent by means of a (broadcast) message sent to the entire network”),
converting, by the DHCP relay agent, the first broadcasted DHCP message to a unicast form ([49-50] where the “DHCP relay which mostly forwards the broadcast message as a directed message to one or more DHCP server”);
processing and transmitting a unicast DHCP message ([47-50]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the DHCP message processing of Rong with the DHCP functionality supported by Ackermann, along with Ackermann’s awareness and use of switch port-based processing (e.g., Ackermann, [12-14,26,36-38]) in order to ensure DHCP standards are followed (e.g., broadcasting of DHCP discover messages, followed by direct unicasting), thus better ensuring reliable and consistent operation of the resultant invention.
Regarding claim 2, the above combination further shows wherein the first allocated subspace and the second allocated subspace are at least partially overlapping (Rong, [97], see “can be overlapped”).
Regarding claim 10, the above combination further shows wherein augmenting, by the DHCP relay agent, the first broadcasted DHCP message comprises adding the first tenant attribute information to a tenant attribute field within a header of the DHCP message (Rong, [92] discussing the “tenant-specific option added to the DHCP header”).
Regarding claim 11, the limitations of said claim are addressed in the analysis of claim 1.
Regarding claim 12, the limitations of said claim are addressed in the analysis of claim 2.
Regarding claim 20, the limitations of said claim are addressed in the analysis of claim 10.
Claims 3 – 5 and 13 - 15 are rejected under 35 U.S.C. 103 as being unpatentable over Rong in view of Ackermann, as applied to claim 1 above, further in view of Guichard (US-20070058638-A1).
Regarding claim 3, the above combination shows: wherein the first tenant attribute information comprises a first VLAN identifier for the first broadcasted (Ackermann, [49-50]) DHCP message, and the second tenant attribute information comprises a second VLAN identifier for the second broadcasted (Ackermann, [49-50]) DHCP message (Rong, [92,94] discussing a VLAN ID associated with a VAP and a correspondence between tenant ID and VLAN ID mapping; as [94] notes the process is repeated for multiple clients across multiple tenants). The above combination does not show: use of both a VLAN identifier and a VRF identifier which identifies a first routing instance and a second VLAN identifier and a second VRF identifier which identifies a second routing instance. Guichard shows: use of both a VLAN identifier and a VRF identifier which identifies a first routing instance and a second VLAN identifier and a second VRF identifier which identifies a second routing instance ([4-6]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with virtual route forwarding techniques of Guichard in order to simplify network management and traffic forwarding operations (Guichard, [4]). Regarding claim 4, the above combination further shows wherein the switch configuration information (Rong, [92]) comprises a first mapping between the first tenant attribute information and first host connection information, and a second mapping between the second tenant attribute information and second host connection information (Rong, [92-94] and Ackermann, [49-50]).
Regarding claim 5, the above combination further shows wherein the determining, by the DHCP relay agent, first tenant attribute information of the first host comprises: determining the first host connection information based on the first VLAN identifier (Rong, [92,97] where the VLAN ID maps to the tenant ID which in turn maps to the tenant address space); and deriving the first VRF identifier based on the first host connection information and the switch configuration information (Rong, [92] discussing the VNID <-> VAP (the vSwitch interface ID)); and the determining, by the DHCP relay agent, second tenant attribute information of the second host comprises: determining the second host connection information based on the second VLAN identifier (Rong, [94]discussing that the processing techniques cited above are repeated for each tenant and client); and deriving the second VRF identifier based on the second host connection information and the switch configuration information (Rong, [94] discussing that the processing techniques cited above are repeated for each tenant and client).
Regarding claim 13, the limitations of said claim are addressed in the analysis of claim 3.
Regarding claim 14, the limitations of said claim are addressed in the analysis of claim 4.
Regarding claim 15, the limitations of said claim are addressed in the analysis of claim 5.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rong in view of Ackermann and Guichard, as applied to claim 3 above, further in view of Pani (US-20150124823-A1).
Regarding claim 6, the above combination shows the first host connection information defines a first connection of the first host to a first port on the switch and the second host connection information defines a second connection of the second host to a second port on the switch (Rong, [92-94]). The above combination does not show: wherein the DHCP relay agent is implemented on a switch. Pani shows wherein the DHCP relay agent is implemented on a switch ([14,30]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the switch-based relay of Pani in order to better utilize common network hardware such as switches, thus lowering implementation costs associated with the resultant invention.
Regarding claim 16, the limitations of said claim are addressed in the analysis of claim 6.
Claims 7, 8, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rong in view of Ackermann, as applied to claim 1 above, further in view of Gass (US-20090010249-A1).
Regarding claim 7, the above combination shows: wherein the first DHCP message comprises a first DHCP discover message (Rong, Fig. 6 step 231); and assigning, by the DHCP server, a first IP address to the first host comprises: transmitting, to the DHCP relay agent, a first DHCP offer message in unicast form that includes the assigned first IP address (Rong, Fig. 6 233-234, [94-97], and Ackermann, [49]); transmitting (Rong, Fig. 6 step 234), to the first host (Rong, Fig. 6 item 210), by the DHCP relay agent (Rong, Fig. 6 item 220), the first DHCP offer message (Rong, Fig. 6). The above combination does not show: converting, by the DHCP relay agent, the first DHCP offer message into a broadcast first DHCP offer message, and transmitting the first broadest DHCP offer. Gass shows converting, by the DHCP relay agent, the first DHCP offer message into a broadcast first DHCP offer message and transmitting the first broadest DHCP offer ([52]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the broadcast assignment notifications of Gass in order to better ensure network endpoints are aware of address assignments and thus utilize correct, up-to-date addressing information.
Regarding claim 8, the above combination further shows wherein the assigning, by the DHCP server, a first IP address to the first host comprises: obtaining, by the DHCP relay agent (Rong, [96]), a first broadcasted DHCP request message (Ackermann, [49]) from the first host within the first VLAN (Rong, [89,92]) in broadcast form (Ackermann, [49]); determining, by the DHCP relay agent, the first tenant attribute information of the first host based on the switch configuration information (Rong, [92]); augmenting, by the DHCP relay agent, the first broadcasted DHCP request message with the determined first tenant attribute information (Rong, [92]); converting, by the DHCP relay agent, the first broadcasted DHCP request message to a unicast form (Ackermann, [47-50] and Rong, [94]); and transmitting, by the DHCP relay agent, the unicast augmented first DHCP request message to the DHCP server (Ackermann, [47-50] and Rong, [94]). Regarding claim 17, the limitations of said claim are addressed in the analysis of claim 7.
Regarding claim 18, the limitations of said claim are addressed in the analysis of claim 8.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rong in view of Ackermann, as applied to claim 1 above, further in view of Extreme Networks (Extreme Networks - Dropping DHCP Discover/Request Packets. https://extreme-networks.my.site.com/ExtrArticleDetail?an=000102130. (Year: 2023)).
Regarding claim 9, the above combination shows wherein the computer instructions when executed by the one or more hardware processors are further configured to perform: detecting, by the DHCP server, a third DHCP message devoid of tenant attribute information (Rong, [98-99] and Fig. 7 step 315). The above combination does not show: flagging, by the DHCP server, the third DHCP message as nonconforming; and dropping, by the DHCP server, the third DHCP message. Extreme Networks shows: flagging, by the DHCP server, the third DHCP message as nonconforming (pgs. 1 – 2); and dropping, by the DHCP server, the third DHCP message (pgs. 1 – 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the DHCP message processing of Extreme Networks in order to better ensure reliable operation by preventing continued processing of packets that are not appropriately formed.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Rong in view of Ackermann and Gass, as applied to claim 17 above, further in view of Extreme Networks
Regarding claim 19, the above combination shows wherein the computer instructions when executed by the one or more hardware processors are further configured to perform: detecting, by the DHCP server, a third DHCP message devoid of tenant attribute information (Rong, [98-99] and Fig. 7 step 315). The above combination does not show: flagging, by the DHCP server, the third DHCP message as nonconforming; and dropping, by the DHCP server, the third DHCP message. Extreme Networks shows: flagging, by the DHCP server, the third DHCP message as nonconforming (pgs. 1 – 2); and dropping, by the DHCP server, the third DHCP message (pgs. 1 – 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the DHCP message processing of Extreme Networks in order to better ensure reliable operation by preventing continued processing of packets that are not appropriately formed.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
