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 .
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), 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 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 information ([92], see “internal vSwitch interface ID”); augmenting, by the 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”); 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 in order to ensure DHCP standards are followed, 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Onoue (Onoue, Koichi, Naoki Matsuoka, and Jun Tanaka. "Host-based multi-tenant technology for scalable data center networks." Proceedings of the eighth ACM/IEEE symposium on Architectures for networking and communications systems. (Year: 2012)).
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
Prosecution Insights