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 .
DETAILED ACTION
Claims 1-7, 15,18 are pending in Instant Application.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of CN202110846385.3 filed 07/26/2021.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/29/2023 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
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.
Claims 1-2 are rejected under 35 U.S.C. 103 as being unpatentable over Tunnell et al., “hereinafter Tunnell” (U.S. Patent Application: 20160379220) in view of Bhatt et al., “hereinafter Bhatt” (U.S. Patent Application: 20200169886).
As per Claim 1, Bhatt discloses a method for setting a device control authority, the method being applied to a first Internet of Things device, comprising:
receiving access information for a second cloud server transmitted by a second Internet of Things device that has established a connection relationship with the first Internet of Things device (Tunnell, Para.59, To gain access using this common “password-based authentication, each user initially registers (or is registered by someone else, such as a systems administrator), using an assigned or self-declared login ID and a password. On each subsequent use, the user must enter the login ID and the password. However, password-based authentication is not considered to provide adequately strong security for any system that contains sensitive data., Para.41, a first entity 12 (point of sale device as a non-limiting example) may interact with a second 11 (a phone in this non-limiting example) and third entity 70 (a remotes service on a server (not shown) on the internet or device (not shown) in a cloud, as non-limiting examples), wherein the second entity is local and the third entity (a device in the cloud) could be remote to the first and second entities. Under this example, access to data 21 requested from a first entity (Point of sale) from a second entity 11 (phone) is not released until a third entity 70 (remote service 70 on some device on the internet or cloud) authenticates 20 the first entity 12 (point of sale device) and reports that to the second device 11 (phone),), wherein the first Internet of Things device and the second Internet of Things device belong to different Internet of Things systems, and the second cloud server is a cloud server having a trust relationship with the second Internet of Things device (Tunnell, Para.92, the second entity (e.g., a smart card 13) may ask for additional authentication 20 prior to releasing any data 21. This additional authentication 22 may comprise the first entity (phone 11) authenticating 23 with a third entity (a user, an entity, or another device on the cloud 70 that is trusted by the second entity (smart card 13) as shown by “trusted comms” 23 (e.g., trusted communication links and systems) between a second and third entities, as non-limiting examples). Note in this example a communication process 23 can take place directly between the second entity (smart card 13 in this example) and the third entity (cloud 70 in this example), or through the first entity (communications path not shown) to reach the third entity.);
authenticating the second cloud server based on the device authentication information (Tunnell, Para.41, the same multi-instance shared authentication methods could be applied to an application, software, API (application programmers interface), service 50 or the like, called “services” herein, on the first entity 12 or a remote service 70 residing on a device on the internet or in the cloud, Para.98, a first entity (such as a smart wallet) storing sensitive private information (such as credit card or bank account information, referred to generally as financial information and considered “personal information”) authenticating with a second entity, such as but not limited to a computer or a USB (universal serial bus) memory device storing private information physically connected to a computer) and authenticating with a third entity (such as a cloud-based server) before any data is transferred from the first entity, Para.102, The application may then authenticate with a fourth entity, such as a cloud-based server, before transferring data to or receiving data from the fourth entity. Alternatively, once the software application has been authenticated to the first, second, and fourth entities (either directly or indirectly) data can be transferred between and among any of these entities.);
However Tunnell does not disclose obtaining device authentication information of the second cloud server based on the access information; and in response to the authentication being passed, setting authority information of the second Internet of Things device for the first Internet of Things device
Bhatt discloses obtaining device authentication information of the second cloud server based on the access information (Bhatt, Para.16, In order to configure an IoT device, the user needs to scan a QR code, which is shipped together with the device, using a mobile application, which contains wireless network settings of the router, such as network name and corresponding password, and other configuration preferences. The QR code contains identifiers of the device, randomly generated wireless network settings (SSID and WPA2-PSK), to which a device expects to connect during setup, and the manufacturer's digital signature over data part.);
in response to the authentication being passed, setting authority information of the second Internet of Things device for the first Internet of Things device (Bhatt, Para.15, setup/configure an IoT device to connect to an access point or master/controller device with the aid of a computational device (for example, a smartphone or a laptop with required hardware) while verifying its genuineness and providing secure exchange of the local network security settings and cryptographic keys. It may be used for configuration of IoT devices using any popular IoT communication protocol that use security settings such as PSK or passcode, Para.31, The method also allows secure reconfiguration of the device. It is done by logging in the mobile application, which may be connected to the cloud service by selecting the pre-configured device in the mobile application logged in with the previous profile, then select to reconfigure the device).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Bhatt with the teachings as in Bhatt. The motivation for doing so would have been for implementing a method for configuring IoT devices. It enables users to securely associate their IoT devices to the network gateway or master/controller device, such as an internet access point (router), improves the usability as compared to other known solutions and does not rely on user knowledge for security configuration process. Furthermore, the proposed method guarantees genuineness of the IoT device and secure exchange of security parameters and cryptographic keys between infrastructure entities during configuration and reconfiguration of the device. The method can be applied to IoT devices supporting different communication protocols that are commonly found on IoT devices. (Bhatt, Para.2).
With respect to Claim 15, 18 are substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 2, Tunnell in view of Bhatt discloses the method of claim 1, wherein the authenticating of the second cloud server based on the device authentication information comprises:
determining authentication verification information required for verifying the second cloud server; and performing information verification for the device authentication information with the authentication verification information to authenticate the second cloud server (Tunnell, Para.84, one or more authentication techniques may be used to verify an entity or a user. These may include, but are not limited to, symmetric, asymmetric, and/or combinations of any authentication techniques, Para.91, a second authentication process depicted by the arrowhead 30 with a cloud-based entity 70, Para.41, the same multi-instance shared authentication methods could be applied to an application, software, API (application programmers interface), service 50 or the like, called “services” herein, on the first entity 12 or a remote service 70 residing on a device on the internet or in the cloud, Para.92, This additional authentication 22 may comprise the first entity (phone 11) authenticating 23 with a third entity (a user, an entity, or another device on the cloud 70 that is trusted by the second entity (smart card 13) as shown by “trusted comms” 23 (e.g., trusted communication links and systems) between a second and third entities, as non-limiting examples). Note in this example a communication process 23 can take place directly between the second entity (smart card 13 in this example) and the third entity (cloud 70 in this example), or through the first entity (communications path not shown) to reach the third entity. In this embodiment, the second entity may authenticate with the third entity through the second entity to prevent a man-in-the-middle attack). One entity requesting multiple authentication instances across a plurality of entities prior to releasing data to one or more of the entities improves the security of the data.).
Allowable Subject Matter
Claim 3-7 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 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, Vivek Srivastava can be reached at 5712727304. 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.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449
Prosecution Insights