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
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) 2-9, 11-18 and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Henry et al. (US PG PUB 20220311523), hereinafter "Henry", in views of Goldschlag et al. (US PG PUB 20160292694 ), hereinafter "Goldschlag", further in views of Slowiak et al. (US PAT 11784995), hereinafter "Slowiak", further in views of Grayson et al. (US PG PUB 20210274426), hereinafter "Grayson".
Regarding Claim 2, Henry discloses:
(Claim 1) A device (i.e. client device 102) (102 – Fig. 2 and ¶ 0020)
comprising processing circuitry coupled to storage (i.e. the client device 102 includes a central processing unit 802 [i.e. processing circuitry] coupled to memory/storage 804) (Fig. 8 and ¶ 0064), the processing circuitry configured to:
(Claim 11) A non-transitory computer-readable medium storing computer-executable instructions which when executed by one or more processors (i.e. memory 804 storing instructions executable by CPU 802) (Fig. 8 and ¶ 0063 - 0064) result in performing operations comprising:
(Claim 20) A method comprising:
Initiate/initiating a federated onboarding service process to a framework via an access network provider (ANP) connected to the device (i.e. the client device may initiate authentication process, e.g. providing public/private ID [i.e. a federated onboarding service process], to a framework of a multi-access environment via an access provider 104 [i.e. an access network provider (ANP)] connected to the client device) (104, 222 & 226 – Fig. 2 and ¶ 0030 – 0032).
However, Henry does not explicitly disclose:
Establish/establishing a secure tunnel between the device and a federated onboarding service; and transmit/transmitting information from the device to the federated onboarding service via the secure tunnel to enable the federated onboarding service to route an onboarding of the device to an identity provider (IdP).
On the other hand, in the same field of endeavor, Goldschlag teaches:
Establish/establishing a secure tunnel between the device and a federated onboarding service (i.e. VPN tunnel [i.e. a secure tunnel] may be established between the user device and identity proxy [i.e. a federated onboarding service] of VPN concentrator) (Fig. 2A, Fig. 2C, 3030 - Fig. 3, ¶ 0069 and ¶ 0076); and
Transmit/transmitting information from the device to the federated onboarding service via the secure tunnel to enable the federated onboarding service to route an onboarding of the device to an identity provider (IdP) (i.e. user device may send/transmit SAML including the user identity [i.e. information] request to identity proxy [i.e. the federated onboarding service] via VPN tunnel [i.e. the secure tunnel] to enable the identity proxy [i.e. the federated onboarding service] to forward/route an access to [an onboarding] of the user device to identity provider IdP 2110) (Fig. 2A, Fig. 2C, Fig. 3, ¶ 0069 – 0070 and ¶ 0076 - 0078).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing dated of the claimed invention was made to modify the method/device/computer-readable-medium of Henry to include features for/to establish a secure tunnel between the device and a federated onboarding service; and transmit information from the device to the federated onboarding service via the secure tunnel to enable the federated onboarding service to route an onboarding of the device to an identity provider (IdP) as taught by Goldschlag so that the access to the identity provider may be implemented via secure connection (Fig. 2A, Fig. 2C, Fig. 3, ¶ 0069 – 0070 and ¶ 0076 - 0078).
However, the combination of Henry and Goldschlag does not explicitly disclose:
Receive/receiving an IdP-generated user-specific profile based on the information.
On the other hand, in the same field of endeavor, Slowiak teaches:
Receive/receiving an IdP-generated user-specific profile based on the information (i.e. relying party App 205 of the user device may receive identity attributes [i.e. a user-specific profile] including the user’s account information based on the user’s universal digital identity [i.e. the information] provided by the user) (9 & 205 – Fig. 2, Column 6 Line # 50 – 67, Column 7 Line # 52 – 56 and Column 8 Line # 33-42).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the method/device/computer-readable-medium of Henry and Goldschlag to include the feature for/to receive an IdP-generated user-specific profile based on the information as taught by Slowiak so that the user may be provided with information with respect to identities provided by a plurality of identity providers and identity attributes associated with the selected identity provider (Abstract and ¶ 0012).
However, the combination of Henry, Goldschlag and Slowiak does not explicitly disclose:
Authenticate/authenticating and connect/connecting to the framework using the IdP-generated user-specific profile.
On the other hand, in the same field of endeavor, Grayson teaches:
Authenticate/authenticating and connect/connecting to the framework using the IdP-generated user-specific profile (i.e. UE may connect to OpenRoaming access network [i.e. the frame work] using a user specific identity of profile 2 [i.e. the user-specific profile]) (Fig. 11, ¶ 0027, ¶ 0135 and ¶ 0139 - 0140).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the method/device/computer-readable-medium of Henry, Goldschlag and Slowiak to include the feature to authenticate and connect to the framework using the IdP-generated user-specific profile as taught by Grayson so that the device may select and use the most appropriate user identity of the user in accessing the framework (Fig. 5, Fig. 8, Fig. 10, ¶ 0096 and ¶ 0132 - 0135).
Regarding Claims 3,12 and 21 Henry, Goldschlag, Slowiak and Grayson disclose, in particular Grayson teaches:
wherein the information comprises at least one of: IdP-specific credentials, terms and conditions, or user account validation or creation (i.e. the information regarding charge policy [i.e. terms and conditions] may be communicated) (¶ 0137).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claims 2 and 11.
Regarding Claims 4 and 13, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Henry teaches:
wherein the federated onboarding service is configured to query a domain name system (DNS) server to discover the identity provider (IdP) (i.e. the method/system may request a Domain Name Service (DNS) server 204 to discover the address of the identity provider) (Fig. 2 and ¶ 0031).
Regarding Claims 5 and 14, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Grayson teaches:
wherein the IdP- generated user-specific profile is pushed to the device using operating system specific interfaces supported on the device (i.e. In some instances, the home network 120 may be considered an Identity Provider (IdP or IDP), which may be analogous to SP, such that the IdP may provide access decisions (accept, reject, limited access, etc.), identity information, and/or the like for one or more devices, such as UE 102 [i.e. IdP provide/push identity information / IdP- generated user-specific profile] via network interface of the UE [i.e. operating system specific interfaces supported on the device]) (¶ 0025).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claims 2 and 11.
Regarding Claims 6 and 15, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Slowiak teaches:
wherein the IdP-generated user-specific profile is generated by tokenizing an authorization token and associating the authorization token with the identity provider (IdP) (i.e. the identity attributes [i.e. IdP-generated user-specific profile] is generated by using token received for authentication [i.e. an authorization token] and correlating the token with identity provider) (Column 6 Line # 60 – 67, Column 7 Line # 1 – 51 and Column 8 Line # 33 - 42).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claims 2 and 11.
Regarding Claims 7 and 16, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Henry teaches:
wherein the operations further comprise automatically authenticate to the framework using an extensible authentication protocol (EAP) over a transport layer security (TLS) encryption connection (i.e. the access provider 104 sets up an encrypted and authenticated Transport Layer Security (TLS) tunnel to an identity provider 106 (230). The identity provider 106 provides an EAP authorization using Remote Authentication Dial In User Service (RADIUS) attributes to the access provider 104 (232), and the access provider 104 provides an EAP authorization to the client device 102 using EAP over LANs) (Fig. 2 and ¶ 0031).
Regarding Claims 8 and 17, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Grayson teaches:
wherein the IdP-generated user-specific profile comprises a network access identifier (NAI) realm for the federated onboarding service (i.e. UE may connect to OpenRoaming access network using a user specific identity of profile 2, e.g. UserA@provider1.com [i.e. a network access identifier (NAI) realm for the federated onboarding service]) (Fig. 11, ¶ 0027, ¶ 0135 and ¶ 0139 - 0140).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claims 2 and 11.
Regarding Claims 9 and 18, Henry, Goldschlag, Slowiak and Grayson disclose, in particular Goldschlag teaches:
wherein the processing circuitry is further configured to validate the federated onboarding service using a root certificate installed at the device prior to establishing the secure tunnel (i.e. the user device may use information identifying the device (such as a device ID or a certificate identifying the device), application, or user of the device, such as a certificate, token, cookie, or other identity indicator) (¶ 0061).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claims 2 and 11.
Claim(s) 10 an 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Henry in views of Goldschlag further in views of Slowiak in further view of Grayson as applied to claims 2 and 11 above, and further in view of Yu et al. (US PG PUB 20170201878), hereinafter "Yu".
Regarding Claims 10 and 19, Henry, Goldschlag, Slowiak and Grayson disclose all the features with respect to Claims 2 and 11 as described above.
However, the combination of Henry, Goldschlag, Slowiak and Grayson does not explicitly disclose:
wherein the access network provider (ANP) is registered with the framework, and wherein the processing circuitry is further configured to verify the ANP using a certificate issued to the ANP during registration.
On the other hand, in the same field of endeavor, Yu teaches:
wherein the access network provider (ANP) is registered with the framework (i.e. Wireless network access points [i.e. the access network provider (ANP)] that are authentic are registered with a certificate authority [i.e. the framework]) (¶ 0016 and ¶ 0022), and
wherein the processing circuitry is further configured to verify the ANP using a certificate issued to the ANP during registration (i.e. the method/system may attempt to match any received access point certificates to an received or available root certificates [i.e. verify the ANP using a certificate issued to the ANP during registration]) (Fig. 3, ¶ 0022 and ¶ 0043).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the method/device/computer-readable-medium of Henry, Goldschlag, Slowiak and Grayson to include the feature wherein the access network provider (ANP) is registered with the framework, and wherein the processing circuitry is further configured to verify the ANP using a certificate issued to the ANP during registration as taught by Yu in order to connect to only authentic available wireless network access points thereby creating a safer network environment for users of mobile devices (¶ 0016 and ¶ 0022).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SOE MIN HLAING whose telephone number is (303)297-4282. The examiner can normally be reached Monday-Friday 9AM - 5PM.
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, Christopher Parry can be reached at 571-272-8328. 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.
/Soe Hlaing/Primary Examiner, Art Unit 2451
