DETAILED ACTION
This Office Action is in response to the Amendments filed on 09/03/2025.
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 09/08/2025 have been fully considered but they are not persuasive.
Regarding claim 1, on pages 11-12, applicant argues that Cisco does not disclose:
A secondary EAP dialogue that is distinct from a primary authentication for the wireless network.
“group identity” is a “shared identity that is distributed to other devices that are allowed to access the first UDN group’.
Authenticating the group identity independent of the Media Access Controller (MAC) address.
In response, Examiner respectfully disagrees and submits that:
Cisco discloses to gain access to the Cisco UDN service, user must first provide their credentials and be successfully authenticated (at least pages 7 & 12, sections ‘Cisco UDN Mobile App’ and ‘Device registration flow’). This corresponds to the recited ‘primary authentication’. Then when the user chooses to connect the device to the network by selecting the UDN SSID at the device, the SSID is configured with 80x.1x to authenticate the device (at least page 12, section ‘Device Access Network’). This corresponds to the recited ‘secondary EAP dialogue’. So, clearly authentication of the credentials and authentication of device using the SSID configured with 802.1x are distinct from one another.
UDN-ID/name corresponds to the recited ‘group identity’ because the UDN-ID/name identifies a UDN that is shared by a group of devices which received invitation/authorization to join the UDN (at least page 8).
When the SSID configured with 802.1x is used to authenticate the device and verify the UDN-ID/name, user identity or other identifiers are used instead of MAC address.
As such, based on the above reasons, applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 102
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 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.
Claims 1-4, 6-12, 14-22 are rejected under 35 U.S.C. 102(a)(a) as being anticipated by User Defined Network Prescriptive Deployment Guide (Published in April 2021, hereinafter Cisco).
Regarding claim 1, Cisco discloses a method implemented by a controller of a wireless network, the method comprising:
receiving a first request to connect to the wireless network from a device of a user, the first request including a personal identity usable to authenticate the user (at least page 4, sections “Cisco UDN Cloud” & “Identity Provider”, page 7, sections “Cisco UDN Mobile App” & “Cisco UDN Cloud Service”, wherein a request is received from a user mobile device to connect to Cisco User Defined Network (UDN) cloud, the request includes credentials queried from the single sign-on (SSO) service);
authenticating the personal identity (at least page 4, section “Identity Provider”, wherein credentials of the user mobile device is authenticated);
granting access to the wireless network to the device in response to authenticating the personal identity (at least page 4, section “Identity Provider”, page 7, sections “Cisco UDN Mobile App” & “Cisco UDN Cloud Service”, wherein the user mobile device is granted access the Cisco UDN Cloud);
subsequent to granting the device access to the wireless network, receiving, from the device, a second request to connect to a first user defined network (UDN) group within the wireless network, (at least pages, 8-9, 11, a second request to connect to a UDN is received, the second request includes i.e.: UDN-ID, UDN-name), the first UDN group bring a virtual network segment of the wireless network (at least page 11, a UDN SSID is virtual segment of the network);
establishing, in response to the second request, a secondary Extensible Authentication Protocol (EAP) dialogue with the device, wherein (at least page 11, a second authentication is established with the user mobile device);
the secondary EAP dialogue includes receiving, from the device, a group identity that validates the device as being allowed to access the first UDN group (at least page 12, UDN-ID/name (via UDN SSID) is received from the mobile device);
the group identity being obtained by the device in an out-of-band process between the device and a remote UDN identity service and the group identity being a shared identity that is distributed to other devices that are allowed to access the first UDN group (at least page 8, UDN-ID/name is shared/distributed to other users who are invited to join the UDN, page 12, the UDN-ID/name (via UDN SSID) is obtained in a different process (by searching available wi-fi networks) between the mobile device and a remote entity that provides UDN identity service);
the group identity does not include a Media Access Controller (MAC) address (at least page 12, UDN-ID/name (via UDN SSID) does not include MAC);
authenticating, using the secondary EAP dialogue, that the group identity was created by the remote UDN identity service for device and other devices of the first UDN group that were distributed to the device, the secondary EAP dialog being distinct from a primary authentication for the wireless network (at least pages 4, 8-9, and 11-2, at least the UDN-ID/name is created by a remote UDN identity service for the UDN and is sent to the mobile device & well as other devices as i.e.: invite, authentication of the UDN-ID is distinct from the authentication of the credentials above. The SSID is configure with 802.1x to authenticate the device);
granting access to the first UDN group to the device based at least in part on the group identity being created for the device and other devices of the first UDN group, (at least pages 11-12, the user mobile device is granted access to the UPN based on the UDN-ID), wherein the device supports (MAC) rotation and is associated with a current MAC address that is different than a previous MAC address used when accessing the first UDN group at a previous time (at least page 7, ‘Cisco UDN Mobile App’ & page 12, ‘Device registration flow’ step 3, MAC randomization); and
storing an indication that the device is associated with the first UDN group in a first list associated with the first UDN group (at least page 8, device-user mapping for a specific UDN is established/stored).
Regarding claim 2, Cisco discloses the method of claim 1. Cisco also discloses receiving, from the device, a third request to connect to a second UDN group within the wireless network, the third request including third credentials associated with the second UDN group (at least page 8, i.e.: when the user mobile device accepts an invitation to a different UDN);
establishing, in response to the third request, another secondary EAP dialogue with the device (at least page 11, another secondary authentication is established with the user mobile device);
authenticating the third credentials associated with the second UDN group (at least pages 4 & 11, i.e.: UDN specific information such as UDN-ID);
granting access to the second UDN group to the device (at least page 11, the user mobile device is granted access to a particular UPN that its MAC is associated with);
updating the first list to remove the device from the first UDN group (at least page 8, change of UDN is updated to show user’s current device and its UDN association); and
storing an indication that the device is associated with the second UDN group in a second list associated with the second UDN group (at least page 8, user to device mapping is updated and stored).
Regarding claim 3, Cisco discloses the method of claim 2. Cisco also discloses the wireless network comprises a plurality of UDN groups, including the first UDN group and the second UDN group, each respective UDN group being associated with a respective profile of the user (at least page 4, each user is given their own private UDN; page 8, wherein end users can be invited to different UDNs).
Regarding claim 4, Cisco discloses the method of claim 1. Cisco also discloses the group identity comprise at least one of an identifier associated with the first UDN group or a username and password associated with the first UDN group (at least pages 8-9 & 12, second credential comprises UDN-ID & UDN name).
Regarding claim 6, Cisco discloses the method of claim 1. Cisco also discloses the group identity comprise a decorated network access identifier (at least pages 8-9 & 12, UDN-ID).
Regarding claim 7, Cisco discloses the method of claim 1. Cisco also discloses the secondary EAP dialogue may comprise an identifier associated with the first UDN group (at least pages 8-9 & 12, UDN ID).
Regarding claim 8, Cisco discloses the method of claim 1. Cisco also discloses further comprising:
sending, to the device and in response to authenticating the personal identity, a request for group identity, the request including an identifier associated with the first UDN group (at least page 8, once the user mobile device has been authenticated to access the Cisco UDN Cloud, the user mobile device receives an invite to join a second UDN. The invite requests the user to select a device that the user would like to bring over to the second UDN);
receiving, from the device, a message including the group identity (at least page 8, when the user accepts the invite and includes a UDN-ID); and
establishing, in response to receiving the group identity, the secondary EAP dialogue with the device (at least pages 4 & 8, in response to receiving the UDN specific information such as UDN-ID, a secondary authentication is established with the user mobile device).
Claim 9 is rejected for the same rationale as claim 1. In addition, Cisco also implicitly discloses one or more processors (at least page 4, wherein components of the Cisco UDN Cloud service that perform operations of the claim).
Claim 10 is rejected for the same rationale as claim 2 above.
Claim 11 is rejected for the same rationale as claim 3 above.
Claim 12 is rejected for the same rationale as claim 4 above.
Claim 14 is rejected for the same rationale as claim 6 above.
Claim 15 is rejected for the same rationale as claim 7 above.
Claim 16 is rejected for the same rationale as claim 8 above.
Regarding claim 17, Cisco discloses a method comprising:
displaying, on a user interface of a device, one or more UDN groups within a wireless network, wherein each of the one or more UDN groups are associated with a respective profile of a user of the device (at least page 8, a clear view of the dashboard showing the user’s current device and its UDN association);
sending, from the device, a first request to access the wireless network, the first request including a personal identity usable to authenticate the user (at least pages 4 & 11, user mobile device sends a request to access CISCO UDN Cloud, the request includes credentials);
accessing, by the device, the wireless network (at least pages 4 & 11, upon successful authentication, the user mobile device accesses the CISCO UDN Cloud);
sending, from the device, a second request to access a first UDN group of the one or more UDN groups, wherein the second request comprises group identity associated with accessing the first UDN group (at least page 11, a request to access a specific UDN is sent);
establishing, with the wireless network, a secondary EAP dialogue (at least page 11, an additional/secondary authentication is established with the user mobile device,) wherein
the secondary EAP dialogue includes receiving, from the device, the group identity that validate the device as being allowed to access the first UDN group (at least page 12, UDN-ID/name (via UDN SSID) is received from the mobile device);
the group identity being obtained by the device in an out-of-band process between the device and a remote UDN identity service and the group identity being a shared identity that is distributed to other devices that are allowed to access the first UDN group (at least page 8, UDN-ID/name is shared/distributed to other devices that are invited to join the UDN, page 12, the UDN-ID/name (via UDN SSID) is obtained in a different process (by searching available wi-fi networks) between the mobile device and a remote entity that provides UDN identity service);
the group identity does not include a Media Access Controller (MAC) address (at least page 12, UDN-ID/name (via UDN SSID) does not include MAC);
accessing, by the device, the first UDN group (at least page 11, the mobile device accesses the UDN which associates with the user mobile device MAC address,) wherein the device supports (MAC) rotation and is associated with a current MAC address that is different than a previous MAC address used when accessing the first UDN group at a previous time (at least page 7, ‘Cisco UDN Mobile App’ & page 12, ‘Device registration flow’ step 3, MAC randomization);
Regarding claim 18, Cisco discloses the method of claim 17. Cisco also implicitly discloses creating, by the device, a first profile associated with the first UDN group and a second profile associated a second UDN group, wherein the first profile and the second profile comprise a same primary identifier, and wherein the first profile comprises a secondary identifier that is different from a secondary identifier of the second profile (at least pages 4 & 8, 12-13, i.e.: a first UDN ID is generated for a first user mobile device (first profile) and devices that the user wants to access the first UDN, while a second UDN ID is generated for the user mobile device (second profile) and other devices that the user wants to access the second UDN). Both the first and second profiles access the CISCO UDN cloud using the same credentials/key (at least pages 11-13)), and the user mobile device comprises a first UDN ID that is different from second UDN ID of the user mobile device (pages 11-13, specific UDN ID associates with a specific registered devices).
Regarding claim 19, Cisco discloses the method of claim 17. Cisco also discloses the second request is sent in response to receiving user input selecting a first profile associated with the first UDN group (at least pages 11-13, when the user mobile device selects to access a specific UDN ID).
Regarding claim 20, Cisco disclose the method of claim 17. Cisco also implicitly discloses sending, from the device, a third request to access a second UDN group of the one or more UDN groups, wherein the third request comprises third credentials associated with accessing the second UDN group (at least pages 11-13, when the user mobile device requests to access a second UDN ID);
establishing, with the wireless network, a secondary EAP dialogue (at least pages 11-13, additional/secondary authentication is established); and
accessing, by the device, the second UDN group (at least pages 11-13, the user mobile device accesses an associated UDN/the second UDN).
Regarding claim 21, Cisco discloses the method of claim 1. Cisco also implicitly discloses receiving, from the device, a third request to connect to a second UDN group within the wireless network, the third request including a second group identity associated with the second UDN group (at least page 8, user accepts/ requests to access another UDN-ID/name);
authenticating the second group identity via a secondary EAP dialogue (at least page 12, UDN-ID/name is authenticated/verified);
granting access to the second UDN group to the device (at least page 8, device is moved/granted to another UDN); and
updating the first list to remove the device from the first UDN group and storing an indication that the device is associated with the second UDN group in a second list (at least pages 8 & 13, owner-device mapping as well as host UDN mapping is updated).
Regarding claim 22, Cisco discloses the method of claim 1. Cisco also discloses the second request is received in response to a user selection of one of a plurality of profiles on the device, and wherein each of the plurality of profiles corresponds to a respective UDN group and includes a unique group identity, while sharing a same primary identifier for accessing the wireless network (at least pages 12, 79-85, where the UDN-ID/name is different, but the SSID is the same).
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 PHY ANH TRAN VU whose telephone number is (571)270-7317. The examiner can normally be reached Monday-Friday 7 am-1 pm.
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, Taghi T Arani can be reached at (571) 272-3787. 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.
/PHY ANH T VU/ Primary Examiner, Art Unit 2438