DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 remarks filed on 12/10/2025 have been fully considered.
Regarding claim[s] 16 – 30 under the rejection for non – statutory subject matter - abstract idea without significantly more/practical application, applicant’s remarks have been considered, however, they are not persuasive. See the examiner’s response in the office action below.
Regarding claim[s] 16 – 30 under the various anticipatory and obviousness rejections, applicant’s remarks are not persuasive, therefore, the examiner has responded to such remarks in the office action below.
The examiner will address all other remarks that do not concern the prior art rejection, if any, in the office action below.
The examiner’s response to applicant’s remarks regarding the rejections issued under 35 U.S.C. 101 – abstract idea without significantly more/no practical application:
Applicant states on page[s] 11 of the remarks as filed: “Applicant respectfully submits that the claims are not directed to mathematical relationships, and, even if construed to include some mathematical relationships, the claims integrate such into a practical application, namely to "improve the security of data communication between IoT devices and application servers." (See para. [004] of Applicant's originally filed specification).”
In response the examiner isn’t persuaded, the examiner does not read the subject matter of paragraph: 0004 of the specification as filed into the claim language. Applicant’s encrypting of data then moving the data while encrypted data generically between devices is not a practical application, but extra solution activity.
Applicant states on page[s] 11 of the remarks as filed: “Even if, arguendo, the claims are construed to include mathematical relationships, the claims integrate such into the practical application of improving the security of data communication. As described in para. [008] the present application: "Since, according to the invention, the re-encryption server is, other than the application server, a trusted intermediary entity operated by a trustworthy party, the invention enables a cryptographically secured data communication between the IoT device and the application server without the necessity to provide the IoT device's decryption keys to the application server. The lack of trustworthiness of the application server is thus compensated by the trustworthiness of the intermediary re-encryption server." (Applicant's originally-filed specification, para. [008]) Accordingly, claims 16-30 are not directed to mathematical relationships and, even if construed to include such, integrate such into a practical application.
Withdrawal of this rejection is kindly requested.”
In response the examiner isn’t persuaded, the examiner does not read the subject matter of paragraph: 0008 of the specification as filed into the claim language. Applicant’s encrypting of data then moving the data while encrypted data generically between devices is not a practical application, but extra solution activity.
What is further, the examiner isn’t persuaded based on that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a trusted intermediary entity operated by a trustworthy party, the invention enables a cryptographically secured data communication between the IoT device and the application server without the necessity to provide the IoT device's decryption keys to the application server) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Examiner’s response regarding the prior art rejections under 35 USC 102 to Chaubey [US PAT # 11258774]
Applicant states on page[s] 12 of the remarks as filed: “First, Chaubey is silent as to a re-encryption server that uses "an encryption key of the application server" to re-encrypt the decrypted data as required by claims 16 and 26. Chaubey instead teaches a "network device" that merely "inspects the TLS/SSL traffic" between a "client device" and a "server device." (see col. 2, 11. 47-53 of Chaubey). To this end, the network device in Chaubey performs a handshake with the client device and a handshake with the server device (see col. 2, 11. 50-53 of Chaubey). The handshakes in Chaubey do not disclose or suggest a re-encryption server that is configured to re-encrypt decrypted data using an encryption key of the application server because in Chaubey, the handshakes include cryptographic keys only of the network device (see col. 2, 11. 55-58 of Chaubey).
Accordingly, Chaubey is silent as to re-encrypting the decrypted data using an encryption key of the application server as required by claims 16 and 26.”
In response the examiner isn’t persuaded, the examiner points out that applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e.,…First, Chaubey is silent as to a re-encryption server that uses "an encryption key of the application server" to re-encrypt the decrypted data as required by claims 16 and 26…) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant states on page[s] 12 of the remarks as filed: “Additionally, Chaubey does not disclose or suggest receiving by the encryption server encrypted data that has been encrypted by the IoT device as required by claims 16 and 26. Chaubey merely describes a network device that acts "as a man in the middle and break the connection between the client device and the server device." (see col. 2, 11. 47-50 of Chaubey).”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake.
Applicant states on page[s] 12 and 13 of the remarks as filed: “In contrast, claim 16 is amended to require "receiving by the re-encryption server encrypted data that has been encrypted by the loT device." As shown in Applicant's FIG. 1 and described in Applicant's originally filed specification, the re-encryption server may be configured to receive such encrypted data through the application server 102 or from the IoT device. (See paras. [0039]-[0040] of the originally filed specification). Chaubey fails to disclose or suggest such a configuration, as the network device of Chaubey only receives TLS/SSL traffic from the client device.
For at least these reasons, pending claims 16, 17, 21, 26, 29, and 30 are patentable over Chaubey.
Withdrawal of the rejection is kindly requested.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake.
This meets applicant’s argued claim limitation of: “..receiving by the re-encryption server encrypted data that has been encrypted by the loT device..”
Examiner’s response regarding the prior art rejections under 35 USC 103 to Chaubey [US PAT # 11258774] in view of Liu [US PGPUB # 2018/0054315]
Applicant states on page[s] 13 of the remarks as filed: “In the combination, Liu fails to remedy the above described deficiencies of Chaubey because Liu focuses on a "method and device for providing a key for IoT communication." (See Abstract of Liu). Liu is silent as to "receiving by the re-encryption server encrypted data from the application server that has been encrypted by the IoT device" as required by amended claim 16.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey. Specifically, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
Further of Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.
Examiner’s response regarding the prior art rejections under 35 USC 103 to Chaubey. [US PAT # 11258774] in view of Zakaria [US PAT # 9503969]
Applicant states on page[s] 14 of the remarks as filed: “In the combination, Zakaria fails to remedy the above described deficiencies of Chaubey because Zakaria focuses on an "apparatus and method for adjusting a scan interval or scan width of a BTLE device." (See Abstract of Zakaria). Zakaria is silent as to "receiving by the re-encryption server encrypted data from the application server that has been encrypted by the IoT device" as required by amended claim 16.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey. Specifically, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
Further of Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.
Examiner’s response regarding the prior art rejections under 35 USC 103 to Chaubey [US PAT # 11258774] in view of Ouellette [US PAT # 11429971]
Applicant states on page[s] 14 of the remarks as filed: “In the combination, Ouellette fails to remedy the above described deficiencies of Chaubey and Liu because Ouellette focuses on a "integrating a first party service into a second party computer application are disclosed." (see Abstract of Ouellette). Ouellette is silent as to "receiving by the re-encryption server encrypted data from the application server that has been encrypted by the IoT device" as required by amended claim 16.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey. Specifically, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
Further of Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.
Examiner’s response regarding the prior art rejections under 35 USC 103 to Chaubey [US PAT # 11258774] in view of Kumar [US PGPUB # 2019/0058586]
Applicant states on page[s] 15 of the remarks as filed: “In the combination, Kumar fails to remedy the above described deficiencies of Chaubey and Zakaria because Kumar focuses on "joining an Internet of Things (IoT) network." (See Abstract of Kumar). Kumar is silent as to "receiving by the re- encryption server encrypted data from the application server that has been encrypted by the IoT device" as required by amended claim 16.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Chaubey. Specifically, at col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
Further of Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 35 are pending in the instant application.
Regarding claim[s] 20, 24, under the rejection for indefinite claim language (i.e. and/or), applicant’s claim amendments have been considered, therefore, the rejections have been withdrawn.
Claim[s] 1 – 30 under the various types of anticipatory and obviousness rejections, applicant’s claim amendments have been considered, but are not persuasive. Therefore, the examiner has addressed such claim amendments in the office action below.
Regarding claim[s] 31 – 35 that are newly added claims and are addressed in the office action below.
Claim Interpretation
Claim[s] 35 is objected to under 37 CFR 1.75 as being a substantial duplicate of claim 18. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Appropriate Action required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim[s] 16 – 30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to the abstract idea: “mathematical relationships: [mathematical relationships, mathematical calculations]” without significantly more.
Regarding claim[s] 16, 26, 29, for example, the claim limitations that recite the identified abstract idea in at least the claim(s) 16, recite(s)
“……..wherein a re-encryption server
decrypts data encrypted by the IoT device; and
re-encrypts the decrypted data by an encryption key of the application server in such a way that the application server can obtain the data by decrypting the re-encrypted data….”
This judicial exception is not integrated into a practical application because the remaining claim limitations amount to adding insignificant solution activity to the identified judicial exception:
“A method for securely transmitting data from an IoT device to an
application server via a telecommunication network……………………………….”
The claim(s) 17 – 25, 27, 28, 30 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claim language either recites a further identified abstract idea/the same identified abstract idea or adding insignificant extra – solution activity to the identified judicial exception in the following manner:
As per claim 17. [i.e. abstract idea – mathematical relationship/calculation]
As per claim 18. [i.e. a further identified abstract idea – mathematical relationship/calculation]
As per claim 19. ***[i.e…significantly more/practical application]**
As per claim 20. [i.e. a further identified abstract idea – mathematical relationship/calculation]
As per claim 21. [i.e. a further identified abstract idea – mathematical relationship/calculation]
As per claim 22. [i.e. a further identified abstract idea – mathematical relationship/calculation]
As per claim 23. ***[i.e…significantly more/practical application]**
As per claim 24. [i.e. adding insignificant solution activity to the judicial exception]
As per claim 25. [i.e. a further identified abstract idea – mathematical relationship/calculation]
As per claim 27. ***[i.e…significantly more/practical application]**
As per claim 28. [i.e. a further identified abstract idea – mathematical relationship/calculation/adding insignificant solution activity used with identified judicial exception]
As per claim 30. [i.e. a further identified abstract idea – mathematical relationship/calculation]
Claim Rejections - 35 USC § 102
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 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 16, 17, 21, 26, 29, 31 - 34 is/are rejected under 35 U.S.C. 102(a)(2) as being taught by Chauby et al. [US PAT # 11258774].
As per claim 16. Chauby does teach a method for securely transmitting data from an IoT device to an application server via a telecommunication network [Chauby, Figure # 1A and 1B and col. 2, lines 37 – 41, In some cases, a network device needs to inspect TLS/SSL traffic to enforce a security policy. For example, the network device may need to inspect TLS/SSL traffic transmitted between a client device and a server device via a communication session.
Where further at figure # 2, and col. 11, lines 2 – 27, Client device 210 may include a communication device and/or a computing device. For example, client device 210 may include a wireless communication device, a user equipment (UE), a mobile phone (e.g., a smart phone or a cell phone, among other examples), a laptop computer, a tablet computer, a handheld computer, a desktop computer, a gaming device, a wearable communication device (e.g., a smart wristwatch or a pair of smart eyeglasses, among other examples), an Internet of Things (IoT) device, or a similar type of device. Client device 210 may communicate with one or more other devices of environment 200, as described elsewhere herein. Server device 220 includes one or more devices capable of receiving, generating, storing, processing, providing, and/or routing information associated with adaptive control of secure sockets layer proxy, as described elsewhere herein. Server device 220 may include a communication device and/or a computing device. For example, server device 220 may include a server, an application server, a client server, a web server, a database server, a host server, a proxy server, a virtual server (e.g., executing on computing hardware), a server in a cloud computing system], the method comprising:
receiving by the re-encryption server encrypted data that has been encrypted by the IoT device [Chaubey, at col. 2, lines 50 – 63, As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device [i.e. applicant’s re – encryption server] may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake.];
decrypting by the re-encryption server the encrypted data that has been encrypted by the IoT device to obtain decrypted data [Chaubey, at col. 2, lines 50 – 63, As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device [i.e. applicant’s re – encryption server] may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake.]; and
re-encrypting by the re-encryption server the decrypted data to obtain re-encrypted data using an encryption key of the application server [Chauby, Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.] such that data of the re-encypted data is obtainable by the application server by the application server decrypting the re-encrypted data [Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device].
As per method claim 17 that includes the same or similar claim limitations as method claim 16, and is similarly rejected.
As per method claim 21 that includes the same or similar claim limitations as method claim 16, and is similarly rejected.
As re-encryption server claim 26 that includes the same or similar claim limitations as method claim 16, and is similarly rejected.
As per system claim 29 that includes the same or similar claim limitations as method claim 16, and is similarly rejected.
As per system claim 30 that includes the same or similar claim limitations as method claim 16, and is similarly rejected.
As per claim 31. Chaubey does teach the method according to claim 16, further comprising sending by the application server the data encrypted by the IoT device to the re-encryption server [Chaubey, col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
Further of Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device.].
As per claim 32. Chaubey does teach the method according to claim 16, further comprising sending by the IoT device the data encrypted by the IoT device to the re-encryption server [Chaubey, col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake].
As per claim 33. Chaubey does teach the method according to claim 16, further comprising the application server decrypting the re-encrypted data [Chaubey, at Figure # 1A and 1B and col. 6, lines 16 – 22, The network device may re-encrypt the information so that the re-encrypted information may be transmitted to the intended destination of the information (e.g., the client device and/or the server device) such that the client device and server device are not aware that there is a man-in-the-middle between the client device and the server device ].
As per claim 34. Chaubey does teach the method according to claim 17, further comprising the IoT device encrypting the data by using the encryption session key corresponding to the decryption session key used by the re-encryption server in the decrypting of the data [Chaubey, col. 2, lines 50 – 63, The network device [i.e. applicant’s re – encryption server] may perform two TLS handshakes, a first handshake with the client device and a second handshake with the server device [i.e. applicant’s application server]. The parameters and cryptographic keys generated for these handshakes may be different. After performing the two TLS handshakes, the network device is in possession of cryptographic keys needed to encrypt and decrypt client traffic as well as server traffic for that communication session.
As an example, the client device [i.e. applicant’s IOT device] may transmit TLS/SSL traffic to the server device. The network device may receive the TLS/SSL traffic and may decrypt the TLS/SSL traffic using the cryptographic keys used to perform the first handshake ].
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 18, 19, 22, 23, 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauby et al. [US PAT # 11258774] in view of Liu [US PGPUB # 2018/0054315]
As per claim 18. Chauby does teach what is taught in the rejection of claim 17 above.
Chauby does not clearly teach the method according to claim 17, wherein a reference code is generated by the IoT device by means of the encryption session key and the method further includes the re-encryption server generating a comparison code by means of the decryption session key.
However, Liu does teach the method according to claim 17, wherein a reference code is generated by the IoT device by means of the encryption session key and the method further includes the re-encryption server generating a comparison code by means of the decryption session key [paragraph: 0038, IoT devices 102, personal device 122 generate a shared key from the security code, the IoT server 122 is sent the shared key. Where further at Figure # 1, and paragraph: 0030, communication between the IoT devices 102 of the system are encrypted or verified with an integrity key].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of Chauby and Liu in order for the transmission of data securely between the client and the server thru the network device of Chauby to include one - time key operations of Liu. This would allow for the parties of: the client, the network device, server, to communicate with different keys each time of communication with each other to prevent man in the middle attacks or compromising the communications between such parties. See paragraph: 0070 of Liu.
As per claim 19. Chauby as modified does teach the method according to claim 18, further comprising the re-encryption server authenticating the data encrypted by the IoT device in a case that the reference code and the comparison code correspond to each other [Liu, Figure # 5, and paragraph: 0079].
As per claim 22. Chauby as modified does teach the method according to claim 17, wherein a comparison code is generated by the application server by means of the decryption key configured to be used by the application server to decrypt the re-encrypted data; and the method further comprises the re-encryption server generating a reference code by means of the encryption key used by the re-encryption server to re-encrypt the data [Liu, Figure # 11, step 1106, 1108, 1110, and paragraphs: 0105, 0106, 0107].
As per claim 23. Chauby as modified does teach the method according to claim 22, wherein in the re-encrypting of the decrypted data, the decrypted data is re-encrypted such that data of the re-encrypted data is obtainable by the application by the application server authenticating the data re-encrypted by the re-encryption server in a case that the reference code and the comparison code correspond to each other [Liu, Figure # 5, and paragraph: 0079].
As per method claim 35, which includes the same or similar claim limitations as method claim 18, and is similarly rejected.
Claim(s) 20, 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauby et al. [US PAT # 11258774] in view of Zakaria [US PAT # 9503969]
As per claim 20. Chauby as modified does teach the method according to claim 17, wherein the encryption session key is derived from an encryption key used by the IoT device, or the decryption session key is derived from a decryption key used by the re-encryption server [Zakaria, Figure # 16A, and col. 20, lines 40 – 65, and col. 21, lines 1 – 5, Turning first to FIG. 16A, the IoT service 120 includes an encryption engine 1660 which manages a set of “service session keys” 1650 and each IoT device 101 includes an encryption engine 1661 which manages a set of “device session keys” 1651 for encrypting/decrypting communication between the IoT device 101 and IoT service 120. The encryption engines may rely on different hardware modules when performing the security/encryption techniques described herein including a hardware security module 1630-1631 for (among other things) generating a session public/private key pair and preventing access to the private session key of the pair and a key stream generation module 1640-1641 for generating a key stream using a derived secret. In one embodiment, the service session keys 1650 and the device session keys 1651 comprise related public/private key pairs. For example, in one embodiment, the device session keys 1651 on the IoT device 101 include a public key of the IoT service 120 and a private key of the IoT device 101. As discussed in detail below, in one embodiment, to establish a secure communication session, the public/private session key pairs, 1650 and 1651, are used by each encryption engine, 1660 and 1661, respectively, to generate the same secret which is then used by the SKGMs 1640-1641 to generate a key stream to encrypt and decrypt communication between the IoT service 120 and the IoT device 101. Additional details associated with generation and use of the secret in accordance with one embodiment of the invention are provided below. In FIG. 16A, once the secret has been generated using the keys 1650-1651, the client will always send messages to the IoT device 101 through the IoT service 120, as indicated by Clear transaction 1611].
As per claim 28. Chauby does teach claim limitations:
a storing means including a…………………………………..configured
to store cryptographic keys used by the re-encryption server in the course of a method for securely transmitting data from an IoT device to an application server via a telecommunication network, wherein a re-encryption server
decrypts data encrypted by the IoT device to obtain decrypted data; and
re-encrypts the decrypted data to obtain re-encrypted data using an encryption key of the application server such that data of the re- encrypted data is obtainable by the application server by the application server decrypting the re-encrypted data.
See what is taught in the rejection of claim 26 above.
Chauby does not clearly teach…. hardware security module (HSM)…..
However, Zakaria does teach the claim limitation of: “….a hardware security module (HSM)…..” [Figure # 16, and col. 22, lines 15 – 24, In one embodiment, the encryption engine 1660 of the IoT service 120 sends a command to the HSM 1630 (e.g., which may be such as a Cloud HSM offered by Amazon®) to generate a session public/private key pair. The HSM 1630 may subsequently prevent access to the private session key of the pair. Similarly, the encryption engine on the IoT device 101 may transmit a command to the HSM 1631 (e.g., such as an Atecc508 HSM from Atmel Corporation®) which generates a session public/private key pair and prevents access to the session private key of the pair.]
It would have been obvious to one of ordinary skilled in the art before the effective filing date of Chauby as modified and Zakaria in order for the transmission of data securely between the client and the server thru the network device of Chauby as modified modified to include transmission path delay calculations of Zakaria. This would allow for optimum transmission speeds of the network to transmit data. See col. 1, lines 31 – 35 of Zakaria.
Claim(s) 24, 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauby et al. [US PAT # 11258774] in view of Liu [US PGPUB # 2018/0054315] as applied to claim[s] 18 above, and further in view of Ouellette et al. [US PAT # 11429971]
As per claim 24. Chauby and Liu do teach what is taught in the rejection of claim 18 above.
Chauby and Liu do not clearly teach the method according to claim 18, wherein the reference code is a CMAC code, or the comparison code is a CMAC code.
However, Ouellette does the method according to claim 18, wherein the reference code is a CMAC code, or the comparison code is a CMAC code [col. 6, lines 32 – 42, Once the consumer is authenticated by the merchant, the CMAC may be used to authenticate the consumer to the financial institution. In one embodiment, the CMAC value may be managed by a financial institution. Because the CMAC links the consumer, the consumer's device, and the merchant, the financial institution may have a variety of options should there be a compromise. For example, if the merchant is compromised, the financial institution may revoke or suspend all CMACs that are associated with that merchant (e.g., for all consumers, all of the customer's devices, etc.).].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of Chauby as modified and Ouellette in order for the transmission of data securely between the client and the server thru the network device of Chauby as modified to include authenticating the client device and the server device of Ouellette. This would allow for the mutual authentication of the parties before the encrypted communications are exchanged between the client device, network device and server. See col. 6, lines 14 – 24 of Ouellette.
As per claim 27. Chauby as modified does teach the re-encryption server according to claim 26, wherein the cryptography means is configured to generate a comparison CMAC code by means of a session key [Ouellette, col. 7, lines 5 – 17, Electronic device 110 may also execute merchant app 124, which may be, for example, a merchant shopping app, a merchant payment app, etc. In one embodiment, merchant app 124 may be provided with software development kit (SDK) 126 for the financial institution. CMAC 128 may also be provided. In one embodiment, CMAC 128 may be stored in one or more location on electronic device 110. The location may depend on the manufacturer of electronic device 110, the operating system, etc. For example, CMAC 128 may be stored in a “key ring” or “key vault” on the device, in secure storage on electronic device 110, within merchant app 124, within SDK 126, etc.] and to authenticate the data encrypted by the IoT device in a case that a reference CMAC code and the comparison CMAC code correspond to each other [Ouellette, col. 6, lines 32 – 42, Once the consumer is authenticated by the merchant, the CMAC may be used to authenticate the consumer to the financial institution.].
Claim(s) 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chauby et al. [US PAT # 11258774] in view of Zakaria [US PAT # 9503969] as applied to claim 20 above, and further in view of Kumar et al. [US PGPUB # 2019/0058586]
As per claim 25. Chauby and Zakaria do teach what is taught in the rejection of claim 20 above.
Chauby and Zakaria do not clearly teach the method according to claim 20, wherein the decryption key used by the re-encryption server is derived by the re-encryption server from a master key of the IoT device, by using an IoT device identifier.
However, Kumar does teach the method according to claim 20, wherein the decryption key used by the re-encryption server is derived by the re-encryption server from a master key of the IoT device, by using an IoT device identifier [paragraph: 0081, In some embodiments, the key authenticator 320 may determine an encryption/a decryption key based on symmetric parameters common between the electronic device 102 and the IoT device 104. The symmetric parameters may include at least one of identification information associated with the electronic device 102 and the IoT device 104 and identification information associated with a user of the electronic device and a user of the IoT devices. The symmetric parameters can be a model type pertaining to the electronic device 102 and a model type of the IoT device 104. For example, if the IoT device 104 is a refrigerator, the identification information can be an indicative of the IoT device 104 being a refrigerator, the electronic device 102 being a smartphone or a tablet computer and also the birth date or the social security number of the user. The encryption key is generated based on the symmetric parameters common between the electronic device 102 and the IoT device 104. In some embodiments, a pre-shared decryption and/or encryption key can be generated using serial number of the electronic device and/or the IoT device(s), manufacturer name, a type or a model of the electronic device 102 and/or the IoT device 104, customer details and other details pertaining to the group of IoT devices 104, and a combination thereof. The pre-shared key is unique for the group of IoT devices 104 and is provided by the manufacturer of at least one of the electronic device and/or the IoT devices. ].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of Chauby as modified and Kumar in order for the transmission of data securely between the client and the server thru the network device of Chauby as modified to include automatic on-boarding configuration operations of Kumar. This would allow for the different keys used in the communications between the parties to automatically installed in an efficient manner to such parties to prevent disruption of the communications between such parties. See paragraph: 0004 of Kumar.
Conclusion
THIS ACTION IS MADE FINAL. 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 DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 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, Kambiz Zand can be reached at 571- 272- 3811. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434