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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim(s) 1-6, 8-10, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1).
Regarding claim 1, Kurmala teaches a non-transitory machine-readable storage medium comprising instructions that upon execution cause a server to:
receive a first message comprising an indicator for a compute entity, the first message being part of a network address assignment process for the compute entity, and the indicator informing the server that the server is to assign a role to the compute entity for implementing a role-based policy; ([0033]: DHCP client transmits a DHCP discover message 211 (or a DHCP request message) to the DHCP server 225. As seen, the DHCP discover message 211 includes option 60. Option 60 is a code that is part of the DHCP standard. According to the standard, option 60 is used by DHCP clients in order to identify itself to the DHCP server. Here, option 60 is used by the branch gateway 220 as a mechanism to inform the DHCP server 225 that uplink details are being requested.)
determine, based on detecting the indicator, the role of the compute entity; and ([0033]: In response to receiving the DHCP discover message 211, the DHCP server 225 can check the VCI to determine whether the option 60 matches the VCI defined on the DHCP server 225. If there is a match between the VCI of the received option (i.e., option 60 and VCI ArubaGw) and the VCI on the DHCP server 225, the DHCP server 225 will return a return message 226 including an option 43. According to the standard, when the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as option 43.)
send, from the server as a response to the first message, a second message containing a role field specifying the role of the compute entity. ([0033]: the DHCP server 225 will return a return message 226 including an option 43. In the embodiments, the return message 226 is particularly configured to include the configuration information needed to bring up the branch gateway 220, and further uses option 43 to convey information that specifically indicates the type (e.g., role) of uplink ports on the branch gateway 225. Option 43 is a code that is part of DHCP standard. In the embodiments, option 43 is distinctly configured to include a “type” indication, where the “type” indicates the type of ports that are implemented on the corresponding device.)
Kurmala does not explicitly disclose provide a network address assignment service for compute entities to assign network addresses to the compute entities via the DHCP discover and offer messages.
However, Zimmer teaches provide a network address assignment service for compute entities to assign network addresses to the compute entities via the DHCP discover and offer messages. ([0038]: In response to a DHCP discovery message, each listening DHCP server will broadcast a DHCP address offer that includes an IP address offered by the server to be assigned to the client that issued the DHCP discovery message.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala. One would have been motivated to do so because it is well-known in the art that using DHCP discover/request message and offer/return message to assign IP address to a DHCP client is part of DHCP standard. As taught by Zimmer, [0038].
Regarding claim 2, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 1.
Kurmala teaches wherein the server comprises a Dynamic Host Configuration Protocol (DHCP) server, and the network address assignment process comprises a DHCP process. ([0033]: DHCP client transmits a DHCP discover message 211 (or a DHCP request message) to the DHCP server 225. The DHCP server 225 will return a return message 226 including an option 43 to the DHCP client.)
Regarding claim 3, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 2.
Kurmala teaches wherein the first message comprises a DHCP Discover message, and the indicator is included in the DHCP Discover message. ([0033]: DHCP client transmits a DHCP discover message 211 (or a DHCP request message) to the DHCP server 225. As seen, the DHCP discover message 211 includes option 60. Option 60 is a code that is part of the DHCP standard. According to the standard, option 60 is used by DHCP clients in order to identify itself to the DHCP server. Here, option 60 is used by the branch gateway 220 as a mechanism to inform the DHCP server 225 that uplink details are being requested.)
Regarding claim 4, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 3.
Kurmala teaches wherein the indicator comprises a vendor class identifier (VCI) set to a specified value, the VCI being according to DHCP option 60. ([0033]: As seen, the DHCP discover message 211 includes option 60. Option 60 is a code that is part of the DHCP standard. According to the standard, option 60 is used by DHCP clients in order to identify itself to the DHCP server. A VCI for option 60 can be defined. In the illustrated example, the VCI for option 60 is defined as “ArubaGw.” In response to receiving the DHCP discover message 211, the DHCP server 225 can check the VCI to determine whether the option 60 matches the VCI defined on the DHCP server 225.)
Regarding claim 5, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 3.
Kurmala teaches wherein the second message comprises a DHCP Offer message, and the role field is included in the DHCP Offer message. ([0033]: the DHCP server 225 will return a return message 226 including an option 43. In the embodiments, the return message 226 is particularly configured to include the configuration information needed to bring up the branch gateway 220, and further uses option 43 to convey information that specifically indicates the type (e.g., role) of uplink ports on the branch gateway 225. Option 43 is a code that is part of DHCP standard. According to the standard, when the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as option 43. In the embodiments, option 43 is distinctly configured to include a “type” indication, where the “type” indicates the type of ports that are implemented on the corresponding device.)
Regarding claim 6, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 5.
Kurmala teaches wherein the role field is included in vendor-specific information of the DHCP Offer message. ([0033]: the DHCP server 225 will return a return message 226 including an option 43. In the embodiments, the return message 226 is particularly configured to include the configuration information needed to bring up the branch gateway 220, and further uses option 43 to convey information that specifically indicates the type (e.g., role) of uplink ports on the branch gateway 225. Option 43 is a code that is part of DHCP standard. According to the standard, when the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as option 43.)
Regarding claim 8, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 1.
Zimmer teaches wherein the indicator is added to the first message by a network device to which the compute entity is connected for access of a network. ([0037]: After the network interface has been initialized, in a block 304 the client broadcasts a DHCP discovery message to receive DHCP address offers from any listening DHCP servers on the network or sub-net. In accordance with the DHCP framework, a client initially is not assigned to a network address, but rather is dynamically allocated an address from a pool of addresses reserved by each DHCP server.)
Regarding claim 9, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 8.
Kurmala teaches wherein the server is to send the second message to the network device that extracts role information from the role field in the second message. ([0033]: the DHCP server 225 will return a return message 226 including an option 43. In the embodiments, the return message 226 is particularly configured to include the configuration information needed to bring up the branch gateway 220, and further uses option 43 to convey information that specifically indicates the type (e.g., role) of uplink ports on the branch gateway 225. Option 43 is a code that is part of DHCP standard. According to the standard, when the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as option 43. In the embodiments, option 43 is distinctly configured to include a “type” indication, where the “type” indicates the type of ports that are implemented on the corresponding device.)
Same rationales apply to claim 10 (network device) and claim 19 (method) because they are substantially similar to claim 1 (machine-readable storage medium).
Regarding claim 20, Kurmala and Zimmer teach the method of claim 19.
Zimmer teaches wherein the second message further comprises an Internet Protocol (IP) address assigned to the compute entity by the network address assignment server. ([0038]: In response to a DHCP discovery message, each listening DHCP server will broadcast a DHCP address offer that includes an IP address offered by the server to be assigned to the client that issued the DHCP discovery message.)
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Sharma (Configuring DHCP Option 43 and Option 60).
Regarding claim 7, Kurmala and Zimmer teach the non-transitory machine-readable storage medium of claim 6.
Kurmala and Zimmer do not explicitly disclose wherein the role field is included in Type-Length-Value (TLV) encoded information, and the role field in the TLV encoded information is indicated by a specified sub-option type, and wherein the TLV encoded information is a sub-option of DHCP option 43.
However, Sharma teaches wherein the role field is included in Type-Length-Value (TLV) encoded information, and the role field in the TLV encoded information is indicated by a specified sub-option type, and wherein the TLV encoded information is a sub-option of DHCP option 43. (Page 3: Inside option 43, we can have encapsulated vendor-specific sub-option codes between 0 and 255. The sub-options are all included in the DHCP offer as type-length-value (TLV) blocks embedded within Option 43. Vendors can define these sub-options as per their wish.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala and Zimmer. One would have been motivated to do so because as defined by DHCP standard, inside option 43, we can have encapsulated vendor-specific sub-option codes between 0 and 255. The sub-options are all included in the DHCP offer as type-length-value (TLV) blocks embedded within Option 43. Vendors can define these sub-options as per their wish. As taught by Sharma, Page 3.
Claim(s) 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Lee (US 20150319559 A1).
Regarding claim 11, Kurmala and Zimmer teach the network device of claim 10.
Kurmala and Zimmer do not explicitly disclose add information of the role to an entry of network address mapping information, the entry correlating the role to a network address of the compute entity.
However, Lee teaches add information of the role to an entry of network address mapping information, the entry correlating the role to a network address of the compute entity. ([0031]: each of the first terminal 100 and the second terminal 110 determines an IP address according to its own determined role, and generates an ARP table based on the determined IP address and the MAC address acquired by using the ARP IE. The ARP table represents a mapping relation between an IP address and a MAC address.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala and Zimmer. One would have been motivated to do so because it is well-known in the art that ARP table represents a mapping relation between an IP address and a MAC address. As taught by Lee, [0031].
Regarding claim 12, Kurmala, Zimmer and Lee teach the network device of claim 11.
Lee teaches wherein the network address mapping information comprises a Media Access Control (MAC) address table or an Address Resolution Protocol (ARP) table. ([0031: each of the first terminal 100 and the second terminal 110 determines an IP address according to its own determined role, and generates an ARP table based on the determined IP address and the MAC address acquired by using the ARP IE. The ARP table represents a mapping relation between an IP address and a MAC address.)
Claim(s) 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Lee (US 20150319559 A1), and further in view of Joshi (US 20220417287 A1).
Regarding claim 13, Kurmala, Zimmer and Lee teach the network device of claim 11.
Kurmala, Zimmer and Lee do not explicitly disclose wherein the network device is to add a role tag to a header of a data packet from the compute entity, the role tag comprising the information of the role retrieved from the entry of the network address mapping information.
However, Joshi teaches wherein the network device is to add a role tag to a header of a data packet from the compute entity, the role tag comprising the information of the role retrieved from the entry of the network address mapping information. ([0036]: The second network device 114 may utilize the VXLAN-GPO encapsulation (shown as VXLAN overlay 122) for encapsulating the data packets with the source role tag of the first entity 106. The source role tag may be present in the VXLAN header. For example, data packets transmitted from the second entity 108 may be encapsulated by the second network device 114 with a source role tag as “guest” in the VXLAN packet header. Further, the first network device 112 may determine a destination role tag of the first entity 106 based on a destination IP address or the Media Access Control (MAC) address present in the VXLAN header.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala, Zimmer and Lee. One would have been motivated to do so because controlling access rights of users or devices to resources of an enterprise or an organization may be useful for maintaining the security needs of the distributed networks. The access rights assigned to a user define how the user may access data available in the distributed network or how the user may communicate within the organization's resources. Further, the access rights may be controlled by a security device that is integrated with the distributed network and provides privileges to the user based on the role of the user. As taught by Joshi, [0001].
Claim(s) 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Hooda (US 20200228404 A1).
Regarding claim 14, Kurmala and Zimmer teach the network device of claim 10.
Kurmala and Zimmer do not explicitly disclose a forwarding hardware controller to forward data packets, wherein the hardware processor is to dynamically install the role-based policy corresponding to the role in the forwarding hardware controller responsive to discovering the role as part of the network address assignment process.
However, Hooda teaches a forwarding hardware controller to forward data packets, wherein the hardware processor is to dynamically install the role-based policy corresponding to the role in the forwarding hardware controller responsive to discovering the role as part of the network address assignment process. ([0011]: receiving notifications from a switch that a host joined an enterprise network. The hosts are then assigned an address within a common subnet associated with the enterprise network. A policy is generated for the host based on the assigned address that includes assigning the host a role associated with the enterprise network (e.g. provider, subscriber).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala and Zimmer. One would have been motivated to do so because enterprise network itself can be broken up into smaller and more efficient subnetworks. Subnets can allow connected computing devices to communicate with each other within the subnet while utilizing routers to communicate between subnets. It is desirable for providing software defined access fabric without subnet restrictions to a virtual network. As taught by Hooda, [0004] and [0011].
Regarding claim 15, Kurmala, Zimmer and Hooda teach the network device of claim 14.
Hooda teaches wherein the forwarding hardware controller is to enforce the role-based policy when forwarding a data packet. ([0011]. [0033]: generating site-specific policies that only allow communications to be transmitted between a particular site within the subnet with the headquarter site, namely only communications between sites having different roles (e.g. between the provider virtual network and a subscriber virtual network) are allowed.)
Claim(s) 16 is rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Hooda (US 20200228404 A1), and further in view of Wu (US 20250030633 A1).
Regarding claim 16, Kurmala, Zimmer and Hooda teach the network device of claim 14.
Kurmala, Zimmer and Hooda do not explicitly disclose wherein the forwarding hardware controller comprises a Ternary Content-addressable Memory (TCAM) hardware controller.
However, Wu teaches wherein the forwarding hardware controller comprises a Ternary Content-addressable Memory (TCAM) hardware controller. ([0120]: a TCAM may also be configured in the network device, and forwarding entry of the data plane are stored in the TCAM. The network device completes the matching of the source address with the key field of the forwarding entry of the data plane by using the TCAM, which can greatly improve the matching efficiency and further improve the packet processing efficiency.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala, Zimmer and Hooda. One would have been motivated to do so because a TCAM may also be configured in the network device, and forwarding entry of the data plane are stored in the TCAM. The network device completes the matching of the source address with the key field of the forwarding entry of the data plane by using the TCAM, which can greatly improve the matching efficiency and further improve the packet processing efficiency. As taught by Wu, [0120].
Claim(s) 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Peng (US 20200044917 A1).
Regarding claim 17, Kurmala and Zimmer teach the network device of claim 10.
Kurmala and Zimmer do not explicitly disclose to: remove, at the network device, the role field from the second message; and send, from the network device to the compute entity, the second message without the role field.
However, Peng teaches to: remove, at the network device, the role field from the second message; and send, from the network device to the compute entity, the second message without the role field. ([0125]: it removes the Link Selection Sub-option and Vendor-Specific Information Sub-option from the option 82 (step 462), restores the gateway address to the DHCP Relay Agent 50 (step 463), and forwards the packet to the DHCP Relay Agent 50 (step 464). Since the DHCP Relay Agent 50 performs standard DHCP relay functions, the packets are then forwarded to the DHCP clients.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala and Zimmer. One would have been motivated to do so because when the DHCP Relay Agent 50-1 on the NAT gateway 410 receives the DHCP BOOTREPLY packet from the DHCP server 42 (step 461), it removes the Link Selection Sub-option and Vendor-Specific Information Sub-option from the option 82 (step 462), restores the gateway address to the DHCP Relay Agent 50 (step 463), and forwards the packet to the DHCP Relay Agent 50 (step 464). Since the DHCP Relay Agent 50 performs standard DHCP relay functions, the packets are then forwarded to the DHCP clients. The DHCP packets travel successfully between the DHCP client in the network element 12-1 and the DHCP server 42 on the NAT GNE network configuration. As taught by Peng, [0125].
Claim(s) 18 is rejected under 35 U.S.C. 103 as being unpatentable over Kurmala (US 20220353147 A1) in view of Zimmer (US 20040193867 A1), and in view of Kaliyamoorthy (US 20210377299 A1).
Regarding claim 18, Kurmala and Zimmer teach the network device of claim 10.
Kurmala and Zimmer do not explicitly disclose wherein the first and second messages are Dynamic Host Configuration Protocol (DHCP) messages, and the network device is to perform DHCP snooping to detect the first and second messages.
However, Kaliyamoorthy teaches wherein the first and second messages are Dynamic Host Configuration Protocol (DHCP) messages, and the network device is to perform DHCP snooping to detect the first and second messages. ([0031]-[0038]: a DHCP client 205 sends (220) a DHCP discover message to a DHCP snooping-enabled switches/routers 210. To facilitate detection of a trusted DHCP server, the DHCP snooping device 210 adds (225) an indicator to the discover message from the DHCP client 205 and sends (230) DHCP discover message with the indicator set to the DHCP server 215. Upon receiving the DHCP offer message from the DHCP server 215, the DHCP snooping-enabled device 210 checks that the received message includes a unique trusted identifier in option field. [0040]: given that the DHCP server 215 is trusted, the DHCP snooping-enabled device 210 will forward the DHCP offer message 605 (which may include removing the unique trusted identifier in the option 101 field), which includes the IP address for the DHCP client from the DHCP server.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kurmala and Zimmer. One would have been motivated to do so because it is highly desirable to find improved ways to verify whether a DHCP server is a trusted or a rogue device, such as systems and methods for determining a trusted Dynamic Host Configuration Protocol (DHCP) server in a DHCP snooping environment. As taught by Kaliyamoorthy, [0001]-[0005].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455
Prosecution Insights