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 .
Priority
This Application claims priority to a Chinese Patent Application # CN202310453610.6 filed 04/25/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/30/2025 was filed after the mailing date of the Non-Provisional Patent Application on 12/31/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
DETAILED ACTION
This Office Action is in response to a Non-Provisional Patent Application received on 12/31/2024. In the application, claims 1-10 have been received for consideration and have been examined.
Specification
Applicant’s submitted specification has been reviewed and found to be in compliance.
Drawings
Applicant’s submitted drawings have been reviewed and found to be in compliance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-10 rejected as failing to define the invention in the manner required by 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
The claim(s) are narrative in form and replete with indefinite language. The structure which goes to make up the device must be clearly and positively specified. The structure must be organized and correlated in such a manner as to present a complete operative device. The claim(s) must be in one sentence form only. Note the format of the claims in the patent(s) cited in the rejection below.
Claim Rejections - 35 USC § 103
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 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 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al., (US20220330029A1) in view of Chinese ref “Wang ” (CN112713995A) in view of Nambisan et al., (US20210044965A1) and further in view of Zhu et al., (CN113271579A).
Regarding claim 1, Wang discloses:
“A method for secure communication and control between a Bluetooth device, a mobile phone, and a server”
Wang teaches a system involving a mobile phone, Bluetooth device, and server. For example, ¶[0367] states:
“After verifying a mobile phone of the owner ... a car manufacturer server sends a digital car key to the mobile phone ... [and] Bluetooth binding information for establishing a Bluetooth binding relationship between the mobile phone ... and the car.”
Wang ¶[0368] further teaches that the mobile phone and car “automatically implement a Bluetooth connection,” followed by a service-layer security check. The car then performs a controlled action. Wang ¶[0370] similarly states that the mobile phone “automatically and directly connects to the car through Bluetooth” and that, after authentication, “the car controls door opening and closing of the car.”
Regarding:
“S1, The mobile phone performs identity authentication on the server, and after the identity authentication is successful, enters the step S2;”
Wang teaches certificate-based authentication in the mobile/Bluetooth architecture. In particular, ¶[0388] states:
“The verification performed by the first Bluetooth device on the second Bluetooth device may be device validity verification.... [using] a CA root certificate preset in the first Bluetooth device, a certificate chain ... and a digital signature.”
Wang ¶[0444] similarly teaches that a mobile phone verifies “signature data and the certificate chain ... based on a pre-stored root CA certificate.”
Wang, however, does not expressly describe this particular authentication as the mobile phone authenticating the server.
Wang’995 supplies the reciprocal server-authentication teaching. Wang’995 ¶[0008] states, translated:
“one group is an ‘initial key,’ used by the server side to verify whether the IoT terminal is a trusted device; the other group is a ‘verification key,’ used by the IoT terminal to verify whether the server side is a trusted device.”
Wang’995 ¶[0010] further states, translated:
“the server side uses the ‘verification key’ to encrypt the verified plaintext again and sends it back to the IoT terminal; the IoT terminal ... decrypts [it] using the ‘verification key,’ [and] compares the ‘verification plaintext’ with the received decrypted payload; if they are the same, it indicates that the server side is trustworthy.”
It would have been obvious to an ordinary skill in the before the effective filing date of the claimed invention to employ Wang’995's reciprocal server authentication in Wang's secure Bluetooth/mobile/server system because both references address establishing trusted communications before permitting secure device communication.
Regarding:
“S2, The mobile phone registers with the server, and saves the server public key after successful registration,”
Wang ¶[0372] teaches:
“registers the user with a financial application registration page, enters related user account information ... and uploads the user account information to a server. The server approves the registration.”
Wang ¶[0067] additionally teaches:
“store an identifier of the first Bluetooth device in association with user account information.”
Nambisan further teaches server public/private-key distribution. Nambisan ¶[0045] states:
“The private keys may have tightly controlled access, and are stored only on the server 210. The public keys may be widely disseminated.... The server 210 may have a static Diffie-Hellman private/public keypair and the public key may be burned ... into the operating system of the network device 202.”
Thus, Wang teaches registration/account association, while Nambisan teaches retaining the server's public key at the communicating device. It would have been obvious to an ordinary skill in the before the effective filing date of the claimed invention to combine these teachings to permit subsequent cryptographic authentication of the registered device/server relationship.
Regarding:
“S3, The mobile phone logs in to the server. The server verifies the mobile phone through the server private key to determine whether the mobile phone is a legitimate operator. If yes, enters the step S4;”
Wang ¶[0069] teaches a server-side:
“identity authentication module, configured to receive user identity information and the identifier ... and complete user identity authentication based on the user identity information and the identifier.”
Wang ¶[0451] further teaches:
“The server verifies the signature data and the certificate chain, that is, validity of Qian Ba's mobile phone based on a pre-stored root CA certificate. After the verification succeeds, the server determines that the public key of Qian Ba ... is indeed from the valid mobile phone.”
Nambisan ¶[0045] teaches that:
“The private keys ... are stored only on the server 210.... The server 210 may have a static Diffie-Hellman private/public keypair....”
Nambisan ¶[0050] further teaches that the mobile application relays the challenge token and “the engineer's credentials” to the server, after which the server performs a static-ephemeral Diffie-Hellman exchange.
It would have been obvious to an ordinary skill in the before the effective filing date of the claimed invention to employ Nambisan's server-held private key in Wang's server-side mobile-device authentication to cryptographically protect the authentication exchange.
Regarding:
“S4, The mobile phone connects to the Bluetooth device, and the Bluetooth device is authenticated by the mobile phone to the server. After the authentication is successful, enters the step S5;”
Nambisan ¶[0036] teaches:
“the mobile device 204 may transmit a BLE pairing request to the network device 202.... Responsive to receiving the BLE pairing request, the network device 202 generates the challenge token ... and transmits the challenge token to the mobile device.”
Nambisan ¶[0039] then teaches:
“responsive to receiving the challenge token from the network device, send the challenge token to a server.... the mobile device 204 sends the challenge token to the server 210.”
Nambisan ¶[0042] teaches that after receiving the server response:
“the mobile device 204 pairs with the network device 202 by transmitting the secure pairing key to the network device 202 ... thereby establishing the BLE connection.”
Wang ¶[0222] similarly teaches sending the Bluetooth-device identifier through the Bluetooth connection so that the receiving device uploads the identifier “to the server and initiate[s] user identity authentication in the server.”
Thus, the cited references expressly teach the claimed mobile/Bluetooth/server authentication path.
Regarding:
“S5, The mobile phone performs control commands on the Bluetooth device, and the Bluetooth device verifies the control commands from the mobile phone, and executes the control commands after the verification is successful;”
Zhu ¶[0039] states, translated:
“encrypt the control instruction according to an encryption key generated by the cloud server; combine the encrypted control instruction and the identification information of the Bluetooth device to generate a broadcast packet, and transmit the broadcast packet by broadcasting.”
Zhu ¶[0040] further states, translated:
“the client encrypts the control instruction using the encryption key and places it together with the Mac address in the broadcast packet.... The Bluetooth device ... matches whether it is an instruction that needs to be processed.... [It] processes the control instruction using the decryption key in the Bluetooth device. The decrypted control instruction triggers the corresponding behavior.”
Zhu ¶[0041] expressly teaches that, when the device identifier matches, the Bluetooth device:
“decrypts the ciphertext portion using the decryption key, obtains the control instruction, [and] executes the operation corresponding to the control instruction.”
Wang ¶[0454] independently states that:
“a control instruction is directly sent through the Bluetooth connection.”
It would have been obvious to an ordinary skill in the before the effective filing date of the claimed invention to use Zhu's cryptographic command verification in Wang's Bluetooth control arrangement to prevent an unauthorized control command from being executed.
Regarding:
“S6, After the Bluetooth device is executed, the server verifies the legitimacy of the Bluetooth device.”
Zhu ¶[0046] teaches, translated:
“after executing the control operation corresponding to the control instruction, generate a response broadcast packet and broadcast the response broadcast packet to the client.”
Zhu ¶[0048] further teaches that the Bluetooth device can encrypt updated state information and transmit the encrypted update to the client.
Nambisan teaches that the mobile device may act as a conduit between the Bluetooth/network device and server/network-management infrastructure, including forwarding information received from the device.
Wang’995 ¶[0009] teaches server-side device legitimacy verification: the IoT terminal transmits encrypted verification plaintext to the server, and:
“the server side uses the corresponding ‘initial key’ to decrypt [it], and then performs rule verification on the plaintext; if successful, it indicates that the IoT terminal is a trusted device.”
Accordingly, the combination teaches post-operation reporting together with server-side verification of device legitimacy.
It would have been obvious to an ordinary skill in the before the effective filing date of the claimed invention to apply the already-disclosed server-side device-verification procedure to the device's post-operation communication so that the server does not accept status information from an unauthorized device.
Regarding claim 2, the combination of Wang, Wang’995, Nambisan and Zhu discloses:
“before step S1, it also includes step SO, the server generates an asymmetric key (Ko+Kb), and registers its own digital certificate with CAby using its own public key Kb+;”
Nambisan ¶[0045] teaches:
“The server 210 may have a static Diffie-Hellman private/public keypair....”
Wang ¶[0388] teaches a PKI architecture employing:
“a CA root certificate ... a certificate chain ... and a digital signature,”
and further explains that the public key includes “at least one level of digital certificate issued by a CA.”
Thus, the references teach the server key-pair concept and CA-issued public-key certificate architecture. It would have been obvious to provide the server's public key with a CA certificate in order to permit the remote party to authenticate the server public key.
Regarding:
“Bluetooth device stores Bluetooth device identifier S, Bluetooth device private key K. and server public key Kb+;”
Nambisan ¶[0045] expressly teaches:
“The public keys may be widely disseminated, for example being loaded on every network device 202.... the public key may be burned ... into the operating system of the network device 202.”
Nambisan ¶[0048] further teaches that:
“The network device 202 may generate its own public/private key pair, Cpriv and Cpub.... The ephemeral private key, Cpriv, may be used with Spub, which is stored in the operating system…”
Regarding:
“The server stores Bluetooth device identifier S, Bluetooth device public key Kc+, and server private key Ko.”
Wang ¶[0067] teaches storing a Bluetooth-device identifier in association with user account information, while Nambisan ¶[0045] expressly teaches storage of the server private key at the server.
Wang ¶[0387] additionally teaches that:
“the server pre-stores the Bluetooth public key of the third Bluetooth device.”
Regarding:
“The mobile phone obtained the Bluetooth device identifier S”
Wang ¶[0061] teaches:
“receive, through the Bluetooth connection, an identifier sent by the first Bluetooth device.”
Wang ¶[0062] states that the identifier includes:
“at least one of a Bluetooth address of a terminal and a user identifier.”
Accordingly, claim 2 would have been obvious from Wang and Nambisan's complementary PKI/Bluetooth authentication teachings.
Claim(s) 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al., (US20220330029A1) in view of Chinese ref “Wang ” (CN112713995A) in view of Nambisan et al., (US20210044965A1) in view of Zhu et al., (CN113271579A) and further in view of Ye et al., (CN111211894B).
Regarding claim 3, the combination of Wang, Wang’995, Nambisan, Zhu and Ye discloses:
“S11, The mobile phone obtains the server digital certificate from the CA and the server public key Ko from the certificate;”
Wang ¶[0388] teaches authentication using:
“a CA root certificate ... a certificate chain ... and a digital signature,”
and states that the service public key includes a digital certificate issued by a CA.
Nambisan ¶[0045] expressly teaches server public/private-key pairs and distribution/storage of the server public key at remote devices.
Regarding:
“S12, After obtaining the server public key Kb+, the mobile phone generates a random number NA and sends it to the server,”
Wang’995 ¶[0009] teaches, translated:
“the IoT terminal generates ‘verification plaintext,’ [which] is composed of a group of random codes, signature bits, timestamps and other parameters,” encrypts it, and transmits it to the server.
Regarding:
“S13, The server generates random authentication information Me, and sends the data to the mobile phone. Then Me and Na are spliced into data M |Na, and digitally digests the data M B|/NA to obtain H(MB||NA);”
Ye teaches use of random values supplied by both sides of an authentication/key negotiation. In particular, the disclosed protocol includes gateway-generated R1, server-generated R2, and a digital digest determined from the random values. CN111211894B
Ye further expressly teaches calculating digests over the combined random values and comparing the resulting digests. CN111211894B
Regarding:
“S14, Signs the server private key Ko. to obtain f(Ko.,H(MB|NA )), and sends it to the mobile phone;”
Wang ¶[0452] teaches:
“the server signs the public key of Qian Ba by using the private key (the private key of the authorized device) to generate authorization information.”
Regarding:
“S15, The mobile phone uses the server public key Ko+ to decrypt the data and obtain H(Ma||NA), then obtains a digital digest of data M B||NA, and compares it with H(MB||NA). If the comparison is consistent, the mobile phone successfully authenticates the server.”
Wang’995 ¶[0010] teaches the terminal decrypting information from the server and comparing the returned information with its stored original verification information; “if they are the same, it indicates that the server side is trustworthy.”
Ye teaches the complementary digest-comparison mechanism: when independently determined digests D2 and D4 are equal, authentication/key negotiation succeeds.
It would have been obvious to use Ye's nonce/digest verification and Wang's private/public-key signature authentication within Wang’995's reciprocal server-authentication exchange because these are complementary cryptographic mechanisms directed to establishing authenticity and integrity of an authentication exchange.
Regarding claim 4, the combination of Wang, Wang’995, Nambisan, Zhu and Ye discloses:
“S21, The mobile phone sends a registration request to the server. Upon receiving the response, the mobile phone generates a login password R, then spliced the Bluetooth device identifier S, login password R and the mobile phone identifier D into data SIR||D, and encrypted the data SIR||D using the server public key Kb+ to obtain f(Kb+,SR|D). And the digital digest H(S||R|D) of the data SIR|D is encrypted to obtain f(Ko+,H(SIR|D)), then sends f(Kb+, S|R|D) and f(Kb+,H(S||R|D together to the server;”
Wang teaches registration and association of device/user identifiers. Wang ¶[0372] states that the user “registers the user with a financial application registration page” and uploads account information to the server. Wang ¶[0067] teaches storage of an identifier “in association with user account information.”
Nambisan ¶[0045] teaches use of a server public key at the remote device and retention of the corresponding private key at the server.
Ye teaches transmitting encrypted random/authentication information together with a digital digest and using public/private-key cryptography in the exchange. Specifically, Ye discloses sending a digest D2 together with E1, where E1 results from encrypting random number R3 using the selected asymmetric algorithm and public key P1; the server decrypts E1 using private key P2 and determines another digest D4.
Regarding:
“S22, After receiving the data, the server uses the server private key Ko. to decrypt and obtain the data S|R|D and H(S|R|D), and then extracts a digital digest from the data S|R|D and compares it with the received digital digest H(S||R|D). If the data is consistent, then verifies the legitimacy of S. If S is legitimate, the server stores data R and D, and associates with data S, agreeing the mobile phone to register as the legitimate operator of the Bluetooth device;”
Ye expressly teaches decrypting received encrypted material with a private key, determining a digest from the recovered information, and comparing the digest with the received digest.
Wang ¶[0067] teaches storing the Bluetooth identifier “in association with user account information,” and ¶[0069] teaches completing user identity authentication using the user identity information and Bluetooth-device identifier.
Regarding:
“S23, After receiving the response from the server, the mobile phone knows that the registration is successful.”
Wang ¶[0056] teaches an:
“authentication result receiving module, configured to receive an authentication result generated when the server completes the user identity authentication.”
It would have been obvious to protect Wang's registration/account-association exchange using Nambisan's public-key infrastructure and Ye's encrypted-data/digest verification because doing so protects the confidentiality and integrity of the registration information before accepting the user/device association.
Claim(s) 5-10 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al., (US20220330029A1) in view of Chinese ref “Wang ” (CN112713995A) in view of Nambisan et al., (US20210044965A1) in view of Zhu et al., (CN113271579A) in view of Ye et al., (CN111211894B) and further in view of Lu et al., (CN109345245A).
Regarding claim 5, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“S31, the mobile phone sends the login request and the mobile phone number to the server, and the server sends the short message service (SMS) verification code T after receiving it;”
Lu ¶[0046] states, translated:
“Step 101: the application server receives a user identity verification request sent by the mobile terminal, wherein the user identity verification request includes plaintext and the mobile phone number of the mobile terminal.”
Lu ¶[0047] then expressly states:
“Step 102: the application server sends an SMS verification code to the mobile terminal based on the mobile phone number, so that after receiving the SMS verification code, the mobile terminal returns verification information to the application server, wherein the verification information includes the SMS verification code and an encryption code of the plaintext.”
These are the exact SMS-authentication concepts missing from the earlier references.
Regarding:
“S32, After receiving the verification code T, the mobile phone generates the symmetric key Ka for communication. Then, the verification code T, login password R, mobile phone identifier D, and symmetric key Ka are combined into data TIR||D||Ka. Then, encrypted the data T|R|D|Ka using the server public key Kb+ to obtain f(Ko+,T|R||||Ka). And the digital digest H(T|R|D||Ka) of the data T||R||D|Ka is encrypted to obtain f(Kb.,H(T|R||D||Ka)), then sends f(K,,,T|R||D||Ka) and f(Kb, H(T||R|P||Ka)) together to the server;”
Lu ¶[0047] teaches returning the received SMS verification code together with cryptographically protected authentication information.
Ye teaches combining authentication/key-negotiation information including random values, transmitting a digital digest and public-key-encrypted material, and server private-key decryption.
Wang’995 ¶[0011] further teaches that after authentication:
“the server side uses the preconfigured ‘symmetric encryption’ key pair with a key exchange algorithm to generate a communication key, and sends it to the IoT terminal.” CN112713995A
Regarding:
“S33, The server uses the server private key K. to decrypt and obtain the data T|R|D|K and H(T|R|D||Ka), and then extracts a digital digest from the data T|R||D||Ka and compares it with the received digital digest H(T|R|D||Ka). If the data is consistent, the server will verify the legality of the data T, R, D. If the verification passes, the server confirms that the mobile phone is the legitimate operator of the Bluetooth device.”
Ye expressly teaches private-key decryption followed by digest generation and comparison.
Lu ¶[0049] teaches, translated:
“the application server compares the second ciphertext with the first ciphertext corresponding to the telephone number; if the first ciphertext and the second ciphertext are the same, and the SMS verification code in the verification information is correct, verification passes.”
Thus Lu supplies the claimed SMS-code verification missing from Wang.
one of ordinary skill would have had reason to incorporate Lu's SMS second-factor verification into Wang/Nambisan's authenticated mobile/server session to provide an additional verification of the person controlling the registered mobile number before authorizing Bluetooth-device control.
Regarding claim 6, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“the server verifies that the mobile phone is a legitimate operator, the symmetric key Ka is used to encrypt and decrypt the communication with the mobile phone during the same login connection period.”
Wang ¶[0069] teaches server-side user identity authentication.
Nambisan ¶[0030] teaches a security key having a limited lifetime:
“The secure pairing key may be time-limited, expiring after a predetermined period of time has elapsed. The secure pairing key may be use-limited....”
Wang’995 ¶[0011] teaches generation and distribution of a communication key after successful mutual authentication.
Wang’995 ¶[0032] further teaches that:
“after completing mutual authentication between the server side and the IoT terminal, the server side ... generates a communication key and sends it to the IoT terminal.”
It would have been obvious to an ordinary skill in the art before the effective filing date of the claimed invention to limit the post-authentication communication key to the authenticated connection/session, consistent with Nambisan's express teaching of time/use-limited session security keys.
Regarding claim 7, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“S41, the mobile phone sends the authentication request, the Bluetooth device first identifies the Bluetooth device as S after receiving the request, and encrypts the data using the server public key Ko+ to obtain f(Kb+,S) and sends it to the mobile phone. The mobile phone receives the data and encrypts it using the symmetric key Ka to obtain f(Ka, f(Kb+,S)), and then sends it to the back-end server along with the device authentication request;”
Nambisan ¶[0036] teaches the mobile device sending a Bluetooth pairing request and receiving a challenge token from the Bluetooth/network device.
Nambisan ¶[0038] teaches generating the challenge token using a unique identifier.
Nambisan ¶[0039] teaches:
“responsive to receiving the challenge token from the network device, send the challenge token to a server.”
Nambisan ¶[0045] further teaches that the server public key can be stored at the network device while the private key remains on the server.
Regarding:
“S42, The server uses the symmetric key Ka to decrypt and obtain the data f(Kb+, S), and then uses the server private key Ko. to decrypt and obtain the data S. Finally, the server verifies the legitimacy of the data S.”
Wang’995 ¶[0009] teaches the terminal encrypting verification information and transmitting it to the server, where:
“the server side uses the corresponding ‘initial key’ to decrypt [it], and then performs rule verification on the plaintext; if successful, it indicates that the IoT terminal is a trusted device.”
Nambisan ¶[0045] teaches the server-side private key and remote server public key.
Regarding:
“If the verification is passed, the server generates the symmetric key Kt for communication between the server and the Bluetooth device during the login, and the symmetric key Ky for verification, and concatenates them to form the data Kt||Ky.”
Wang’995 ¶[0008] expressly teaches two different security-key functions:
“one group is an ‘initial key,’ used by the server side to verify whether the IoT terminal is a trusted device; the other group is a ‘verification key,’ used by the IoT terminal to verify whether the server side is a trusted device.”
Wang’995 ¶[0011] additionally teaches generating a separate communication key after successful authentication.
Thus Wang’995 expressly establishes the architectural distinction between a verification key and a communication key.
Regarding the remaining cryptographic transport language:
“Then, the public key of the Bluetooth device Kc+ is used to encrypt the data Kt||Ky to obtain f(Kc+,Kt||Ky). The private key of the server Ko. is used to encrypt and sign the data Kt||Ky to obtain f(Kb., Kt||Ky). Then the data f(Kb, Kt|Ky) and f(Ke+, Kt]Ky) are encrypted with the symmetric key Ka to obtain f(Ka, f(Ko., Ktly)) and f(Ka, f(Ke+, Kt|Ky)), and sends it to the mobile phone;”
Wang ¶[0388] teaches public/private-key digital signatures and CA-based key authentication; Nambisan ¶[0045] teaches server private/public-key infrastructure; and Wang’995 teaches symmetric encryption of authentication material and generation/distribution of the post-authentication communication key.
Regarding:
“S43, the mobile phone uses the symmetric key Ka to decrypt and obtain the data (Ko-, KilKy) and f(Ko+, Kt|Ky), and sends the data to the Bluetooth device;”
Nambisan ¶¶[0039]–[0042] teach the mobile device acting as the intermediary between server and Bluetooth device: the device sends authentication information to the mobile device, the mobile forwards it to the server, the server returns the security information to the mobile, and the mobile provides the pairing key to the Bluetooth device.
Regarding:
“S44, the Bluetooth device uses the private key of the Bluetooth device Ko. to decrypt the data f(Ko+, Kt||Ky) to obtain Kt|Ky, and uses the public key of the server Ko+ to decrypt the data f(Ko-, Kt|Ky) to obtain Kt|Ky, and compares the two decrypted data. If the comparison is consistent, the authentication is successful.”
Wang’995 ¶[0030] teaches the same general compare-to-authenticate principle: the terminal decrypts server-returned information using the verification key and:
“compares the ‘verification plaintext’ with the received decrypted payload; if they are the same, it indicates that the server side is trustworthy.”
It would have been obvious to combine Nambisan's mobile-mediated Bluetooth/server challenge architecture with Wang’995's distinct verification and communication keys and Wang's asymmetric signing because the references address complementary aspects of authenticating a remote device and securely distributing cryptographic keys through an intermediary mobile device.
Regarding claim 8, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“after successful authentication between Bluetooth device and server, the Bluetooth device saves the symmetric key Kt for communication and the symmetric key Ky for verification as the symmetric key for communication and verification between Bluetooth device and server during the same login.”
Wang’995 ¶[0008] expressly distinguishes a verification key used for trust authentication. CN112713995A
Wang’995 ¶[0011] then teaches that:
“after completing mutual authentication between the server side and the IoT terminal, the server side ... generates a communication key, and sends it to the IoT terminal.”
Wang’995 ¶[0017] also identifies operations including:
“storing key pairs and using the key pairs to encrypt and decrypt data ... storing the communication key, and using the communication key to complete encryption and decryption of transmitted data.”
Nambisan ¶[0030] provides the session-limited aspect by teaching time/use-limited security keys.
It would therefore have been obvious to store the authentication/verification key and the post-authentication communication key for use during the authenticated connection period.
Regarding claim 9, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“S51, the mobile phone sends control commands to the Bluetooth device, the Bluetooth device generates a random number T after receiving the control command, and then encrypts the data T using the symmetric key Kt and sends the encrypted data f(Kt,T) to the mobile phone. After receiving the data, the mobile phone uses symmetric key Ka to encrypt and obtain f(Ka, f(Kt,T)), which is then sent to the server along with the control command;”
Zhu ¶[0039] teaches encrypting the mobile control instruction with a cloud-server-generated encryption key.
Zhu ¶[0040] teaches the mobile/client sending the encrypted command to the Bluetooth device and the Bluetooth device decrypting and processing the command.
Ye expressly teaches generating random values during an authenticated server/device exchange and using symmetric and asymmetric encryption together with those random values. The disclosed exchange includes gateway-generated R1, server-generated R2, and R3.
Regarding:
“S52, After receiving the data, the server first decrypts it using the symmetric key Ka to obtain the data f(Kt, T), and then decrypts the data using the symmetric key Kt to obtain the data T.”
Ye teaches decrypting cryptographically protected random-number information and using the recovered random number as part of the authentication/key-verification process.
Regarding:
“After obtaining the random number T, the server first encrypts the data T using the symmetric key Ky to obtain the data f(Ky,T). Then, it takes a digital digest of the data f(Ky,T) to obtain H(f(Ky,T)) Finally, the symmetric key Ka is used to encrypt the digital digest to obtain f(Ka,H(f(Ky, T)) and sends it to the mobile phone;”
Ye expressly teaches determining digital digests from random-number information and comparing the digests before accepting the negotiated key.
Wang’995 supplies the separate verification-key teaching, while Ye supplies the random-number/digest verification mechanism.
Regarding:
“S53, The mobile phone uses the symmetric key Ka to decrypt and obtain the data H(f(Ky, T)), and send it to the Bluetooth device. The Bluetooth device also encrypts the data T using the symmetric key Ky and extracts a digital digest to obtain H(f(Ky,T)). The generated data H(f(Ky, T)) is compared with the digital digest received from the mobile phone. If the comparison is consistent, the Bluetooth device executes the control command issued by the mobile phone.”
Ye's central authentication mechanism expressly compares independently generated digital digests and accepts the key negotiation when the digests match:
“When D2 and D4 are the same, determine that the symmetric encryption key is the digital digest D3 of random number R3.”
Zhu ¶[0041] supplies the control consequence: after the Bluetooth device successfully identifies/decrypts the protected instruction, it:
“obtains the control instruction [and] executes the operation corresponding to the control instruction.”
It would have been obvious to use Ye's nonce-and-digest challenge verification as an additional verification step before Zhu's Bluetooth device executes an encrypted control command, thereby preventing execution of a command unless the cryptographic challenge response is successfully verified.
Regarding claim 10, the combination of Wang, Wang’995, Nambisan, Zhu, Ye, & Lu discloses:
“S61, the Bluetooth device encrypts its own state L and the digital digest H(L) of L through the symmetric key Kt to obtain f(Kt,H(L)), and sends these data to the mobile phone;”
Zhu ¶[0046] teaches that:
“after executing the control operation corresponding to the control instruction, [the Bluetooth device] generates a response broadcast packet and broadcasts the response broadcast packet to the client.”
Zhu ¶[0048] more specifically teaches encrypted Bluetooth-device state/update reporting:
“when the Bluetooth device actively updates information, the update information is encrypted using an encryption key to generate an update broadcast packet; and the update broadcast packet is sent to the client.”
Ye teaches the additional digital-digest aspect, namely determining digital digests of authentication data and transmitting/verifying the resulting digest. CN111211894B
Regarding:
“S62, After receiving the data, the mobile phone encrypts them with the symmetric key Ka to obtain f(Ka,f(Kt,L)) and f(Ka,f(Kt,H(L))), and then sends f(Ka,f(Ka,f(Kt,L)) and f(Ka,f(Kt,H(L)) to the server.”
Nambisan establishes the mobile device as a cryptographic/data conduit between the remote device and server. Its claims expressly teach:
“receiving debugging data from the network device; and sending the debugging data to the server.”
Nambisan ¶[0044] similarly teaches that:
“the mobile device 204 provides a conduit between the network device 202 and the network management terminal 220 over the BLE connection.”
Ye teaches symmetric-key protected data transmission once key negotiation succeeds. Its claim 1 states:
“through the negotiated key, perform data transmission.”
Regarding:
“The server uses decryption to obtain the Bluetooth device status L and verify the legitimacy of the L.”
Wang’995 ¶[0009] teaches that the server decrypts received device information and performs verification:
“the server side uses the corresponding ‘initial key’ to decrypt [it], and then performs rule verification on the plaintext; if successful, it indicates that the IoT terminal is a trusted device.”
Zhu supplies the fact that the encrypted information may specifically be the Bluetooth device's updated state following device operation.
It would have been obvious to an ordinary skill in the art before the effective filing date of the claimed invention to forward Zhu's encrypted post-operation device status through Nambisan's mobile-to-server conduit and apply Wang’995/Ye's cryptographic verification to that status so that the server can verify that post-operation information originated from the authenticated Bluetooth device and was not altered in transit.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6: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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
