DETAILED ACTION
Claim Status
Claim 17 has been cancelled. New claim 21 has been added. Claims 1-16 and 18-21 are pending in the application
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-9, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Salpico (US 20170195162 A1) in view of Kurmala (US 20220353147 A1).
Regarding claim 1, Kurmala teaches a non-transitory machine-readable storage medium comprising instructions that upon execution cause a server to:
provide a network address assignment service for compute entities to assign network addresses to the compute entities; ([0002]: The DHCP can be said to have two main functions: supplying specific configuration parameters to each equipment (host) and supplying and assigning network addresses to the network equipment. The DHCP uses a client-server model, such that a designated DHCP server assigns network addresses and supplies network configuration parameters to pieces of network equipment (devices) that would be the client equipment.)
receive, at the server from a network device, a first message comprising an indicator for a compute entity, the first message being part of a network address assignment process and sent by 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; ([0097]: using policies based on roles (profiles) directly linked to the physical identification of the device (for example, the MAC address) are used. [0033]-[0037]: receiving from the device a layer 2 (of the OSI model) message (for example, a DHCPDISCOVER), requesting network configuration parameters, where this message includes an identifier of the device; assigning a network access profile (e.g. role) to the device obtained from the database depending on the identifier of said device; assigning to the device a set of network configuration parameters depending on the access profile assigned thereto, said set of network configuration parameters including a network address for the device, where said network address (for example, IP) belongs to a range of network addresses available for the device depending on the access profile assigned thereto;)
determine, based on detecting the indicator, the role of the compute entity by accessing Media Access Control (MAC) address-role mapping information comprising entries correlating MAC addresses to respective roles; and ([0033]-[0037]: determining in the network element if the identifier of the device is registered in a database of devices with allowed network access (i.e., if it is in the table of identifiers of devices (MAC addresses) with allowed access). [0107]: Roles (profiles) MAC: It stores the profiles (roles) in the network of the devices. In this table, one profile or another will correspond to each device of the network (for example, depending on its MAC address); in other words, from the MAC address of the device, the profile corresponding to the device is obtained through this table. In the case shown in FIG. 2, these profiles will be, for example, GUEST, HOME AUTOMATION, QUARANTINE, WIRED CONNECTION, WIRELESS; but obviously this is only an example and there can be many other different profiles.)
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, the second message further containing an Internet Protocol (IP address of the compute entity and being part of the network address assignment process and targeted to the compute entity. ([0033]-[0037]: receiving from the device a layer 2 (of the OSI model) message (for example, a DHCPDISCOVER), requesting network configuration parameters, where this message includes an identifier of the device; assigning a network access profile (e.g. role) to the device obtained from the database depending on the identifier of said device; assigning to the device a set of network configuration parameters depending on the access profile assigned thereto, said set of network configuration parameters including a network address for the device, where said network address (for example, IP) belongs to a range of network addresses available for the device depending on the access profile assigned thereto; [0044]: sending a layer 2 message (for example, a DHCPOFFER) to the device, including said network configuration parameters available for the device. [0094]: The DHCP servers capturing the DHCPDISCOVER message (there can be more than one) respond with a series of DHCPOFFER messages (one or more) in which they inform same of at least one available IP address.)
Salpico does not explicitly disclose the indicator added by the network device to the first message.
However, Kurmala teaches the indicator added by the network device to the first 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.)
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 Salpico. One would have been motivated to do so because it is well-known standard in the art that the DHCP discover message 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. As taught by Kurmala, [0033].
Regarding claim 2, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 1.
Salpico teaches wherein the server comprises a Dynamic Host Configuration Protocol (DHCP) server, and the network address assignment process comprises a DHCP process. ([0002]: The DHCP can be said to have two main functions: supplying specific configuration parameters to each equipment (host) and supplying and assigning network addresses to the network equipment. The DHCP uses a client-server model, such that a designated DHCP server assigns network addresses and supplies network configuration parameters to pieces of network equipment (devices) that would be the client equipment.)
Regarding claim 3, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 2.
Salpico teaches wherein the first message comprises a DHCP Discover message, and the indicator is included in the DHCP Discover message. [0033]-[0037]: receiving from the device a layer 2 (of the OSI model) message (for example, a DHCPDISCOVER), requesting network configuration parameters, where this message includes an identifier of the device.)
Regarding claim 4, Salpico and Kurmala 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, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 3.
Salpico teaches wherein the second message comprises a DHCP Offer message, and the role field is included in the DHCP Offer message. ([0033]-[0037]: receiving from the device a layer 2 (of the OSI model) message (for example, a DHCPDISCOVER), requesting network configuration parameters, where this message includes an identifier of the device; assigning a network access profile (e.g. role) to the device obtained from the database depending on the identifier of said device; assigning to the device a set of network configuration parameters depending on the access profile assigned thereto, said set of network configuration parameters including a network address for the device, where said network address (for example, IP) belongs to a range of network addresses available for the device depending on the access profile assigned thereto; [0044]: sending a layer 2 message (for example, a DHCPOFFER) to the device, including said network configuration parameters available for the device. [0094]: The DHCP servers capturing the DHCPDISCOVER message (there can be more than one) respond with a series of DHCPOFFER messages (one or more) in which they inform same of at least one available IP address.)
Regarding claim 6, Salpico and Kurmala 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, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 1.
Salpico teaches wherein the role of the compute entity specified by the role field comprises a guest role of a user of the compute entity or identifies a department within an organization. ([0107]: Roles (profiles) MAC: It stores the profiles (roles) in the network of the devices. In this table, one profile or another will correspond to each device of the network (for example, depending on its MAC address); in other words, from the MAC address of the device, the profile corresponding to the device is obtained through this table. In the case shown in FIG. 2, these profiles will be, for example, GUEST, HOME AUTOMATION, QUARANTINE, WIRED CONNECTION, WIRELESS; but obviously this is only an example and there can be many other different profiles.)
Regarding claim 9, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 8.
Salpico teaches wherein the role of the compute entity is determined by retrieving an entry from the MAC address-role mapping information, the entry selected based on a MAC address of the compute entity in the first message, and the entry correlating the MAC address of the compute entity to the role of the compute entity. ([0033]-[0037]: determining in the network element if the identifier of the device is registered in a database of devices with allowed network access (i.e., if it is in the table of identifiers of devices (MAC addresses) with allowed access). [0107]: Roles (profiles) MAC: It stores the profiles (roles) in the network of the devices. In this table, one profile or another will correspond to each device of the network (for example, depending on its MAC address); in other words, from the MAC address of the device, the profile corresponding to the device is obtained through this table. In the case shown in FIG. 2, these profiles will be, for example, GUEST, HOME AUTOMATION, QUARANTINE, WIRED CONNECTION, WIRELESS; but obviously this is only an example and there can be many other different profiles.)
Same rationales apply to claim 19 (method) because it is substantially similar to claim 1 (machine-readable storage medium).
Regarding claim 20, Salpico and Kurmala teach the method of claim 19.
Salpico teaches wherein the role of the compute entity specified by the role field comprises a guest role of a user of the compute entity or identifies a department within an organization. ([0107]: Roles (profiles) MAC: It stores the profiles (roles) in the network of the devices. In this table, one profile or another will correspond to each device of the network (for example, depending on its MAC address); in other words, from the MAC address of the device, the profile corresponding to the device is obtained through this table. In the case shown in FIG. 2, these profiles will be, for example, GUEST, HOME AUTOMATION, QUARANTINE, WIRED CONNECTION, WIRELESS; but obviously this is only an example and there can be many other different profiles.)
Regarding claim 21, Salpico and Kurmala teach the method of claim 19.
Salpico teaches wherein the role of the compute entity is determined by retrieving an entry from the MAC address-role mapping information, the entry selected based on a MAC address of the compute entity in the first message, and the entry correlating the MAC address of the compute entity to the role of the compute entity. ([0033]-[0037]: determining in the network element if the identifier of the device is registered in a database of devices with allowed network access (i.e., if it is in the table of identifiers of devices (MAC addresses) with allowed access). [0107]: Roles (profiles) MAC: It stores the profiles (roles) in the network of the devices. In this table, one profile or another will correspond to each device of the network (for example, depending on its MAC address); in other words, from the MAC address of the device, the profile corresponding to the device is obtained through this table. In the case shown in FIG. 2, these profiles will be, for example, GUEST, HOME AUTOMATION, QUARANTINE, WIRED CONNECTION, WIRELESS; but obviously this is only an example and there can be many other different profiles.)
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Salpico (US 20170195162 A1) in view of Kurmala (US 20220353147 A1), and in view of Sharma (Configuring DHCP Option 43 and Option 60).
Regarding claim 7, Salpico and Kurmala teach the non-transitory machine-readable storage medium of claim 6.
Salpico and Kurmala 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 Salpico and Kurmala. 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.
Allowable Subject Matter
Claims 10-16 and 18 are allowed.
The following is a statement of reasons for the indication of allowable subject matter: The prior art of record fail to explicitly disclose each and every limitation recited in independent claim 10.
Response to Arguments
Applicant’s arguments regarding independent claims 1 and 19, see pages 9-11 of the Remarks, filed on 09/03/2026, have been fully considered but are moot in view of new ground(s) of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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