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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 35 USC 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that the cited prior arts do not disclose accessing, from a physical media interfaced with a wireless router, network-layer (NL) configuration parameters of a device service set identifier (SSID), a private key of the device SSID, and device configuration data of a plurality of Internet-of-Things (IoT) devices associated with the device SSID, wherein the NL configuration parameters and the device configuration data are stored on the physical media as a JavaScript object notation (JSON) object, and wherein the private key is stored on the physical media as a public-key cryptography standards (PKCS) #12 file.
Examiner respectfully disagrees. Ahlers et al US 2011/0235549 discloses Par 0051/0074 and Fig.1, disclose, The USB key as a physical media interfaced with a wireless router , the configuration setting is stored in the USB key, the USB key may be used to initially configure a network of the Router 130 all Wi-Fi routers include an SSID (Service Set Identifier), i.e. device service set identifier (SSID), which is the unique name of the wireless network. Wherein the routers included devices such as , smart phone, game console, printing device, i.e. IoT devices, par 0054 discloses configuration settings file includes new configuration settings such as a new network password, i.e. private key, a new network identifier, and a new administrative password, i.e. configuration parameters,. Wherein the configured setting include the security key or pass phrase/password as a private key, the These configured settings could be serialized, i.e. serialized data can be seen as a JSON file, it is can be seen as the private key is stored in the JSON file, or otherwise uniquely created for each computer readable medium. The new configuration settings may be used during the setup process to configure the router with the new configuration settings, and to set the wireless profile on the computer such that the computer can wirelessly connect to the router, fig.4, 0037 web address of the router (e.g., 192.168.0.1, etc.), an administrative username and password, a network name or service set identifier (SSID) (i.e., a name that identifies a wireless LAN and may have up to 32 characters), a network password (i.e., security key or passphrase, private key), and a media access control (MAC) address (i.e., a unique identifier assigned to a network adapter or network interface card, often referred to as a physical address,, the USB key can contain a JSON key file, or multiple JSON key files, just as it can store any other type of digital data, A USB key (or USB drive) is a physical data storage device, whereas a JSON key file is a specific type of digital file format used to store data such as cryptographic keys, such as a private key. 0093 [0093] In step 2425, a wireless profile may be created in the new computer. The wireless profile may be created using existing configuration settings from configuration settings file 410 on the USB key. Configuration settings file 410 may contain configuration settings, such as those shown in example XML file 1420, which was shown and described with reference to FIG. 14. The wireless profile may include, among other things, the SSID, i.e. public key, and the network password, i.e. private key,, which can be used by the operating system to establish a secure, persistent wireless connection with the router wireless using security encryption protocols. Par 0037 a network password (i.e., security key or passphrase), and a media access control (MAC) address (i.e., a unique identifier assigned to a network adapter or network interface card, often referred to as a physical address). In addition, routers are often initially configured with open encryption so the first time the user powers up the router, it becomes an open access point with no encryption and with a published SSID, allowing anyone with an Internet connection immediate access to any devices connected behind the router. Therefore, properly securing the router during the setup configuration is essential and may require the user to select an encryption protocol such as, for example, Wired Equivalent Privacy (WEP) encryption or Wi-Fi Protected Access (WPA and WPA2) encryption.
Ahlers does not disclose the USB stored the private key as a public key encryption standards ( PKCS) #12 file.
However, Hughes US 2019/0074982 discloses the USB stored the private key as a public key encryption standards ( PKCS) #12 file ( 0076 user centric” PKI model is used (all public/private key material is created on the client, and the system administrator can create key material (public certificate and private key) and distribute them securely to users (in PKCS #12 packages or USB security token). In that case, all users would have UPA Fallback disabled from the beginning).
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)1-2,8-9 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Ahlers et al US 2011/0235549 and Hughes US 2019/0074982.
As per claim 1. Ahlers discloses A computer-implemented method, the method comprising :
accessing, from a physical media interfaced with a wireless router, network-layer (NL) configuration parameters of a device service set identifier (SSID), a private key of the device SSID, and device configuration data of a plurality of Internet-of-Things (IoT) devices associated with the device SSID, wherein the NL configuration parameters and the device configuration data are stored on the physical media as a JavaScript object notation (JSON) object( Par 0051/0074 and Fig.1, disclose, The USB key as a physical media interfaced with a wireless router , the configuration setting is stored in the USB key, the USB key may be used to initially configure a network of the Router 130 all Wi-Fi routers include an SSID (Service Set Identifier), i.e. device service set identifier (SSID), which is the unique name of the wireless network. Wherein the routers included devices such as , smart phone, game console, printing device, i.e. IoT devices, par 0054 discloses configuration settings file includes new configuration settings such as a new network password, i.e. private key, a new network identifier, and a new administrative password, i.e. configuration parameters,. Wherein the configured setting include the security key or pass phrase/password as a private key, the These configured settings could be serialized, i.e. serialized data can be seen as a JSON file, it is can be seen as the private key is stored in the JSON file, or otherwise uniquely created for each computer readable medium. The new configuration settings may be used during the setup process to configure the router with the new configuration settings, and to set the wireless profile on the computer such that the computer can wirelessly connect to the router, fig.4, 0037 web address of the router (e.g., 192.168.0.1, etc.), an administrative username and password, a network name or service set identifier (SSID) (i.e., a name that identifies a wireless LAN and may have up to 32 characters), a network password (i.e., security key or passphrase, private key), and a media access control (MAC) address (i.e., a unique identifier assigned to a network adapter or network interface card, often referred to as a physical address,, the USB key can contain a JSON key file, or multiple JSON key files, just as it can store any other type of digital data, A USB key (or USB drive) is a physical data storage device, whereas a JSON key file is a specific type of digital file format used to store data such as cryptographic keys, such as a private key. 0093 [0093] In step 2425, a wireless profile may be created in the new computer. The wireless profile may be created using existing configuration settings from configuration settings file 410 on the USB key. Configuration settings file 410 may contain configuration settings, such as those shown in example XML file 1420, which was shown and described with reference to FIG. 14. The wireless profile may include, among other things, the SSID, i.e. public key, and the network password, i.e. private key,, which can be used by the operating system to establish a secure, persistent wireless connection with the router wireless using security encryption protocols. Par 0037 a network password (i.e., security key or passphrase), and a media access control (MAC) address (i.e., a unique identifier assigned to a network adapter or network interface card, often referred to as a physical address). In addition, routers are often initially configured with open encryption so the first time the user powers up the router, it becomes an open access point with no encryption and with a published SSID, allowing anyone with an Internet connection immediate access to any devices connected behind the router.);
adding the device SSID as an additional network of the wireless router ( 0034/0039 an administrative tool application may be installed on computer 120b to provide a user with the ability to configure additional devices to be added to network 100 and to configure administrative settings for network 100, such as parental controls, guest access, and/or router settings.);
connecting the plurality of IoT devices to the device SSID using the private key ( [0093] In step 2425, a wireless profile may be created in the new computer. The wireless profile may be created using existing configuration settings from configuration settings file 410 on the USB key. Configuration settings file 410 may contain configuration settings, such as those shown in example XML file 1420, which was shown and described with reference to FIG. 14. The wireless profile may include, among other things, the SSID, i.e. public key, and the network password, i.e. private key,, which can be used by the operating system to establish a secure, persistent wireless connection with the router wireless using security encryption protocols.); and
configuring settings of the plurality of IoT devices based on the device configuration data (0040 , the setup component may attempt to remedy the connection problem. Once the user completes the setup of the router and the first computer, the configuration settings may be stored in a computer readable medium, which may be used to configure additional computers for wireless or hardwired connection to the router. In addition, the setup component may install an administrative tool component on the first computer that provides the user with necessary information to connect other electronic devices to the router. Thus, such a system simplifies the setup procedure for secure wireless LANs and minimizes the frustration and time spent by users configuring such networks).
Alhers does not disclose wherein the private key is stored on the physical media as a public-key cryptography standards (PKCS) #12 file.
However, Hughes US 2019/0074982 discloses the USB stored the private key as a public key encryption standards ( PKCS) #12 file ( 0076 user centric” PKI model is used (all public/private key material is created on the client, and the system administrator can create key material (public certificate and private key) and distribute them securely to users (in PKCS #12 packages or USB security token). In that case, all users would have UPA Fallback disabled from the beginning).
Alhers and Hughes are both considered to be analogous to the claimed invention because they are in the same field of USB.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alhers to incorporate the teachings of Huges and provide PKI key or cyrptoken.
Doing so would provide authentication for the user identity, thereby prevent false user to use the SSID enable device.
As per clam 2. Alhers and Hughes discloses The method of claim 1, Hughes further comprising:
disabling access to the device SSID by a previous user (0075 disable UPA Fallback for a user. When UPA Fallback is disabled, the “UPA Allowed” field in the user's database entry is set to false, and their salted, hashed password is encrypted using a key known only to the server (ideally kept in an Hardware Security Module (HSM)). When UPA Fallback is enabled for a given user, the “UPA allowed” field in their database is set to true, and their hashed, salted password is decrypted. UPA Fallback can optionally be enabled for a set time (e.g. 30 minutes) after which UPA will automatically be disabled for them again, whether or not they have obtained a new client certificate. In the present case, since IRP itself is how the user obtains their client certificates, when the user obtains their new certificate. UPA Fallback is a feature that may be automatically disabled.); re-registering the plurality of IoT devices under an account of a new user (0044 all registered information is digitally signed by the Domain Identity Registry (DIR) server, and those digital signatures are provided to clients along with the resource records, to establish creator authentication (the information was definitely created by the authoritative server) and message integrity ); generating a new private key of the device SSID (0076 user centric” PKI model is used (all public/private key material is created on the client, and the system administrator can create key material (public certificate and private key) and and storing the new private key in place of a previous private key (0076 distribute them securely to users (in PKCS #12 packages or USB security token)).
As per claims 8-9, those claims are rejected based on the same rational set forth in the claims 1-2 respectively.
As per claims 15-16, those claims are rejected based on the same rational set forth in the claims 1-2 respectively.
Claim(s) 3,5-6, 10,12,13,17,19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ahlers et al US 2011/0235549 and Hughes US 2019/0074982 and Bhatt et al US 2020/0169886.
As per clam 3. Alhers and Huges discloses the method of claim 1, further comprising: the combination does not explicitly disclose
defining the device SSID, wherein the defining comprises defining the NL configuration parameters of the device SSID;
generating the private key of the device SSID;
configuring the plurality of IoT devices for connectivity with the device SSID; receiving device configuration data for each IoT device of the plurality; and
storing the NL configuration parameters, the private key, and the device configuration data for each IoT device of the plurality on the physical media(bolded emphasis).
However, Bhatt discloses defining the device SSID, wherein the defining comprises defining the NL configuration parameters of the device SSID ( claim 1 the IoT device connecting to the Wi-Fi hotspot using the factory defined SSID, WPA2-PSK; IoT device verifying if connection to hotspot was successful; once the IoT device is connected to the mobile device's Wi-Fi hotspot, mobile configuration application sending to the IoT device a random packet key encrypted with the IoT device's public key,);
generating the private key of the device SSID (claim 1 IoT device decrypting the random packet key using its corresponding private key and decrypting the Wi-Fi SSID and PSK of the router using the decrypted random packet key);
configuring the plurality of IoT devices for connectivity with the device SSID; receiving device configuration data for each IoT device of the plurality (0025 configure Internet of Things (IoT) device. The initial configuration starts (1000) by opening the mobile application on the smartphone (1001). First, it is verified if the user is new (1002) or if the user already has an account on the application. If the user does not have an account yet, the user creates a new account (1003) and selects the “Configure IoT device” option on the mobile application. It will allow the user to add his device configuration preferences such as Wi-Fi SSID (Service Set IDentifier) and PSK (pre-shared key) of the router (1005). The profile information and Wi-Fi SSID and PSK can be stored securely on the cloud service and/or in the secure storage of the smartphone. If the user already has an account, he can simply log-in using his user id and password. Upon successful log-in, the user profile, the previously configured devices and the configuration preferences are retrieved and displayed to the user (1004). Subsequently, the user selects pre-existing configuration preferences or adds new preferences (1005)); and
storing the NL configuration parameters, the private key, and the device configuration data for each IoT device of the plurality on the physical media( 0015 configuration of IoT devices using any popular IoT communication protocol that use security settings such as PSK or passcode. According to the present invention and in order to provide a better understanding, scenarios specific to Wi-Fi technology (IEEE 802.11 standard , i.e. NL configuration parameters).
Alhers and Hughes and Bhatt are both considered to be analogous to the claimed invention because they are in the same field of wireless.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alhers to incorporate the teachings of Huges, including the teahing of Bhatt and provide PKI key or cyrptoken.
Doing so would provide authentication for the user identity, thereby prevent false user to use the SSID enable device.
As per claim 5. Alhers and Hughes disclose the method of claim 1, the combination does not explicitly disclose wherein the plurality of IoT devices is integrated within a physical location, However, Bhatt discloses wherein the plurality of IoT devices is integrated within a physical location ([0029] Once the IoT device receives the encrypted random packet key and the encrypted Wi-Fi SSID and PSK, it decrypts the random packet key using its private key corresponding to its public key on the QR code. Then, using the random packet key, it decrypts the Wi-Fi SSID and PSK of the router, as well as the configuration key (Kc). In case of any error during decryption, the IoT device sends an error message to the mobile application, which attempts to encrypt and send again. If the process still fails, the device powers off and the configuration ends. Finally, the IoT device attempts to connect to the router using the Wi-Fi SSID and PSK received in the previous step (1017). If the IoT device is unable to connect to the router (1018), it connects back to the smartphone's Wi-Fi hotspot and informs the application about the failure (1019) and it powers off. This way the mobile application informs the user to check if the router is switched-on and the Wi-Fi SSID and PSK are correct. Following this, the user is directed to the initial configuration screen of the mobile application, where the user corrects/sets the configuration preferences (1005) and continues with the configuration process. Conversely, if the IoT device is able to connect with the router successfully, it saves this configuration and connects back to the smartphone hotspot (1020). Once it is connected to the smartphone hotspot, it sends a success message to the mobile application. The application securely saves the IoT device information and its configuration key (Kc) on the cloud and/or locally in the secure area, i.e. physical location of the smartphone. The application also notifies the user (1021) about the success of the configuration. Subsequently, the mobile application turns off the smartphone's hotspot (1022) and the IoT device connects back to the router (1023). Then, the successful configuration of the device (1024) is finished. ).
As per claim 6. Alhers and Hughes disclose the method of claim 1, the combination fails to discloses wherein the device configuration data of the plurality of IoT devices is selected from the group consisting of respective IoT device automation settings, respective IoT device designations and/or location designations within a physical location, IoT device groupings within the plurality, home location data, and relationships between IoT devices of the plurality.
However, Bhatt discloses wherein the device configuration data of the plurality of IoT devices is selected from the group consisting of respective IoT device automation settings, respective IoT device designations and/or location designations within a physical location, IoT device groupings within the plurality, home location data, and relationships between IoT devices of the plurality(0033configure a new IoT device (103) using a smartphone (101) with the IoT device configuration mobile application installed, which automates most of the steps of the proposed method. Once the user has added the configuration preferences after a successful login to his account on the cloud service (106) using secure communication channel (such as properly configured TLS) (105), the user is able to scan the QR code printed on paper (102) shipped together with the device. After the QR code is scanned, the mobile application decodes the data contained in the QR code, verifies the digital signature, and automatically enables a Wi-Fi hotspot (108) on the smartphone (101), based on the information retrieved from the QR code [steps 1007-1013]. Then, the mobile application informs the user to switch on the IoT device (103). Once the IoT device (103) is turned on and boots completely, it connects to the hotspot (108) on the smartphone (101) using the default Wi-Fi SSID and PSK saved in its memory (which are the same as on the QR code) [step 1014]. The mobile application sends a random packet key (Kp) encrypted using IoT device's public key retrieved from QR code and wireless network settings and Kc (configuration key) of the router encrypted using Kp, (hence improving security of credential transfer (104)), to the IoT device (103) [step 1016]. The IoT device uses its private key (corresponding to its public key) to decrypt the Kp and uses Kp to decrypt the Wi-Fi SSID, PSK and Kc. Only a genuine device from the manufacturer would be able to successfully perform this operation. Hence, the proposed method guarantees the genuineness of the IoT device (103)).
Alhers and Hughes and Bhatt are both considered to be analogous to the claimed invention because they are in the same field of wireless.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Alhers to incorporate the teachings of Huges, including the teahing of Bhatt and provide PKI key or cyrptoken.
Doing so would provide authentication for the user identity, thereby prevent false user to use the SSID enable device.
As per claims 10,12,13, those claims are rejected based on the same rational set forth in the claims 3,5,6 respectively.
As per claims 17,19,20, those claims are rejected based on the same rational set forth in the claims 3,5,6 respectively.
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 ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights