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 .
Status of Claims
Claims 1-15 are presented for examination.
Claims 1-15 are rejected.
Claim Rejections - 35 USC § 102
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.
Claim(s) 1-15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by ALLAIN et al. (US Pub. No.: 2015/0222615 A1: hereinafter “ALLAIN”).
Consider claims 1, 8, and 11:
ALLAIN teaches an apparatus, a network apparatus, and authentication server apparatus (Figs. 1-4A-C elements 100-408) comprising: a memory (Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); and a processor coupled with the memory and configured to cause the authentication server apparatus (Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812) to: receive from a communication device a first message for connecting to an access network (See ALLAIN, e.g., “…A method, system, and manufacture for authorizing an untrusted client device for access on a content management system…receives a request from an untrusted client device to access content on the content management system…sends an authentication key to the untrusted client device…receives the authentication key from a trusted client device…transmits data to the untrusted client device in accordance with any additional instructions that the trusted client device may have sent…Request 406 may specifically identify which content item(s) untrusted device 402 wishes to access. Request 406 may also include information that can uniquely identify untrusted device 402, such as a product name, a serial number, a model number, an IP address, a MAC address…”, of Abstract, ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812), the first message containing a Network Address Identifier ("NAI") of the communication device (See ALLAIN, e.g., “…Request 406 may specifically identify which content item(s) untrusted device 402 wishes to access. Request 406 may also include information that can uniquely identify untrusted device 402, such as a product name, a serial number, a model number, an IP address, a MAC address…user Angela may request through untrusted device 402 to access all the files that belong to her own user account on server 102. In another instance, user Angela can request to access every photograph that has been taken by user Brian in the past 72 hours without specifically designating individual content items…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); determine to request a first server to authorize the communication device, said determination based on the NAI in the first message (See ALLAIN, e.g., “…in response to an access request from requesting device 104, generates a unique key for the purpose of authenticating an untrusted device or an unauthorized user account. Once generated, such authentication key can be linked to the request, the appropriate content item, and/or requesting device 104. The generated keys can be stored in authentication key database 270 to be retrieved later for authentication. Once content management system 206 receives an authentication key from a client device, authenticator module 226 may determine whether the received authentication key matches the one that is stored in authentication key database 270…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); wherein the transceiver further: receives a response from the first server containing a token for authorizing the communication device via another device (See ALLAIN, e.g., “…in response to an access request from requesting device 104, generates a unique key for the purpose of authenticating an untrusted device or an unauthorized user account. Once generated, such authentication key can be linked to the request, the appropriate content item, and/or requesting device 104. The generated keys can be stored in authentication key database 270 to be retrieved later for authentication. Once content management system 206 receives an authentication key from a client device, authenticator module 226 may determine whether the received authentication key matches the one that is stored in authentication key database 270…An untrusted device can be added to the list of trusted devices stored inside trusted device database 280. Trusted device database 280 may contain unique identifiers of trusted devices along with any information on which content each trusted device is authorized to access and any access restrictions imposed on the devices such as an expiration time, a number of access, a version, etc. Alternatively, trusted device database 280 may store a list of untrusted devices with an assumption that the devices not on the list are authorized to access the content…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); transmits a second message to the communication device, the second message containing the token (See ALLAIN, e.g., “…server 102 may initiate the authorization process by issuing authentication key 408 to untrusted device 402. Alternatively, server 102 may send an inquiry first to untrusted device 402 as to whether the authorization process should be initiated. Authentication key 408 can be a code in the form of an alphanumeric text string, an optically machine-readable code (e.g., barcode, QR code, etc.), a static image, a moving image, a video, a sound (e.g., audible sound, inaudible sound), and/or a signal (e.g., Wi-Fi, Ethernet, Bluetooth, near field communication, infrared data association)…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); receives a third message from the first server, the third message containing an identity of a user equipment ("UE") having a first subscription (See ALLAIN, e.g., “…Each time server 102 receives request 406 from client devices, server 102 may generate a unique authentication key, such as authentication key 408, so that each authentication key may be uniquely linked to request 406, untrusted device 402, and/or specific content items being requested. Server 102 may also store such information, for example in authentication key database 270, so that it can be used later when authenticating untrusted device 402. In some aspects, authentication key 408 is configured for playback or presentation on untrusted device 402 such that authentication key 408 can be perceived by another device or a user of untrusted device 402. In other words…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812); and transmits a fourth message to the communication device enabling the communication device to connect to the access network using the first subscription (See ALLAIN, e.g., “…when server 102 determines that the user has properly authorized the device to have access to the content, server 102 can finally allow untrusted device 402 to access the content on server 102. Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812), wherein the apparatus refrains from performing authentication with the communication device (See ALLAIN, e.g., “…Once authentication key 408 is perceived and replicated at trusted device 404, authentication key 408 is sent to server 102 for authentication, for example, via network 108. Additionally, trusted device 404 may send a request to server 102 to transmit content items to untrusted device 402. Trusted device 404 may also transmit additional sharing instructions 410 to server 102. These instructions specify how the requested content is to be shared with untrusted device 402. In other words, the user of trusted device 404 may use the device to custom design how individual content item is to be shared with untrusted device 402…”, of ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0074], ¶ [0071]-¶ [0072], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claims 2, 9, and 12:
ALLAIN teaches everything claimed as implemented above in the rejection of claims 1, 8, 11. In addition, ALLAIN teaches wherein the third message is received in response to the UE authorizing the apparatus to connect to the access network using the first subscription (See ALLAIN, e.g., “…when server 102 determines that the user has properly authorized the device to have access to the content, server 102 can finally allow untrusted device 402 to access the content on server 102. Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claims 3, 10, and 13, 15:
ALLAIN teaches everything claimed as implemented above in the rejection of claims 1, 9, 11, and 14. In addition, ALLAIN teaches wherein the first message comprises a Network Address Identifier ("NAI") of the apparatus (See ALLAIN, e.g., “…Request 406 may specifically identify which content item(s) untrusted device 402 wishes to access. Request 406 may also include information that can uniquely identify untrusted device 402, such as a product name, a serial number, a model number, an IP address, a MAC address…user Angela may request through untrusted device 402 to access all the files that belong to her own user account on server 102. In another instance, user Angela can request to access every photograph that has been taken by user Brian in the past 72 hours without specifically designating individual content items…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812), wherein the NAI indicates that the apparatus is to be authorized to connect to the access network via another device having a subscription with the PLMN (See ALLAIN, e.g., “…server 102 may initiate the authorization process by issuing authentication key 408 to untrusted device 402. Alternatively, server 102 may send an inquiry first to untrusted device 402 as to whether the authorization process should be initiated. Authentication key 408 can be a code in the form of an alphanumeric text string, an optically machine-readable code (e.g., barcode, QR code, etc.), a static image, a moving image, a video, a sound (e.g., audible sound, inaudible sound), and/or a signal (e.g., Wi-Fi, Ethernet, Bluetooth, near field communication, infrared data association)…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claim 4:
ALLAIN teaches everything claimed as implemented above in the rejection of claim 3. In addition, ALLAIN teaches wherein the NAI further indicates that the apparatus does not support Non-Access Stratum ("NAS") signaling over the access network (See ALLAIN, e.g., “…Each time server 102 receives request 406 from client devices, server 102 may generate a unique authentication key, such as authentication key 408, so that each authentication key may be uniquely linked to request 406, untrusted device 402, and/or specific content items being requested. Server 102 may also store such information, for example in authentication key database 270, so that it can be used later when authenticating untrusted device 402. In some aspects, authentication key 408 is configured for playback or presentation on untrusted device 402 such that authentication key 408 can be perceived by another device or a user of untrusted device 402. In other words…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claim 5:
ALLAIN teaches everything claimed as implemented above in the rejection of claim 1. In addition, ALLAIN teaches wherein the processor is configured to cause the apparatus to generate a visual representation of the received token (See ALLAIN, e.g., “…Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812), and wherein to share the token with the UE the processor is configured to cause the apparatus to display the visual representation to the UE (See ALLAIN, e.g., “…when server 102 determines that the user has properly authorized the device to have access to the content, server 102 can finally allow untrusted device 402 to access the content on server 102. Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claim 6:
ALLAIN teaches everything claimed as implemented above in the rejection of claim 1. In addition, ALLAIN teaches wherein to share the token with the UE, the processor is configured to cause the apparatus to transfer the token to the UE using a device-to-device communication link (See ALLAIN, e.g., “…each of the components of system 100 in FIG. 1 can be implemented in a localized or distributed fashion in a network. Network 108 can be a public network, such as the Internet, but can also include a private or quasi-private network, such as an intranet, a home network, a virtual private network (VPN), a shared collaboration network between separate entities, etc. Indeed, the principles set forth herein can be applied to many types of networks, such as local area networks (LANs), virtual LANs (VLANs), corporate networks, wide area networks, ad hoc networks, and virtually any other form of suitable wired or wireless network. Many different forms of communication may be employed on such network 108, including Wi-Fi, Ethernet, Bluetooth, near field communication (NFC), and infrared data association (IrDA)…”, of ¶ [0007]-¶ [0010], ¶ [0024], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Consider claims 7, 14:
ALLAIN teaches everything claimed as implemented above in the rejection of claims 1, 11. In addition, ALLAIN teaches wherein the processor is configured to cause the apparatus to create at least one security key from the received token in response to receiving the third message (See ALLAIN, e.g., “…Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812), wherein the security key is used to establish secure communication with the access network (See ALLAIN, e.g., “…when server 102 determines that the user has properly authorized the device to have access to the content, server 102 can finally allow untrusted device 402 to access the content on server 102. Allowing access can be accomplished in many different ways. Server 102 can send a link, such as a URL, to untrusted device 402 where the desired content may be accessed and/or downloaded. Server 102 can also send a token, with which untrusted device 402 can access the desired content. The token can be a code, a password, a data string, etc. In addition, server 102 can simply directly transmit the data to untrusted device 402. Moreover, server 102 can flag untrusted device 402 as an authorized device and/or a trusted device with appropriate privileges…”, of ¶ [0007]-¶ [0010], ¶ [0030], ¶ [0043], ¶ [0062], ¶ [0064]-¶ [0067], ¶ [0071]-¶ [0072], ¶ [0075]-¶ [0096], and Figs. 1-4A-C elements 100-408, Fig.6-8 steps 600-812).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LIAO (US Pub. No.: 2022/0141662 A1) teaches “The present disclosure is directed to systems and methods for providing interactive services to a device. For example, a method may include determining service authorization information for a device, the service authorization information being associated with an interactive service on a wireless network. The method may also include determining device policies for the device based on the service authorization information. The method may also include transmitting the device policies to the device, wherein the device policies cause the device to select a cloud rendering server for the interactive service.”
BIRKLER et al. (WO 2012135563 A1) teaches “A server in a communications network establishes a communication channel between a user's device and another device having a display. Particularly, the server generates a Quick Response (QR) code utilizing one or more parameters, and sends it to a device for display to a user. Using his or her device, the user captures an image of the displayed QR code and extracts the parameters using an image analysis technique. The device then sends the extracted parameters back to the server, which then utilizes them to authenticate the user and establish the communications session.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BABAR SARWAR whose telephone number is (571)270-5584. The examiner can normally be reached on Mon-Fri 9:00 AM-5:00 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, Faris S. Almatrahi can be reached on (313)446-4821. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free)? If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BABAR SARWAR/Primary Examiner, Art Unit 3667