DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 05/28/2025 and 02/25/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered 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.
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 nonobviousness.
Claims 1, 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 20170064408 to Ketola et al (hereinafter Ketola) and US 20240007523 to Saxena et al (hereinafter Saxena).
As per claim 1, Ketola teaches:
A method comprising:
receiving, from a cloud platform, a to-be-processed data stream comprising an encrypted video stream and a first encrypted stream key (Ketola: [0063] In an embodiment, the video storage server includes a database for storing the one or more videos. [0100] In one embodiment, a first user of the plurality of users can be associated with the first terminal for accessing the encrypted first video from the video storage server. [0066]: The public keys can be used to encrypt encryption keys (which have been used to encrypt the videos) generated by the video camera or associated control unit or gateway. The encrypted encryption keys can be opened by the users that have the corresponding private keys, i.e., the first user receives the encrypted first video and encrypted encryption keys from the video storage server);
decrypting, based on a pre-obtained first wrapping key, the first encrypted stream key to obtain a first stream key (Ketola: [0066]: The public keys can be used to encrypt encryption keys (which have been used to encrypt the videos) generated by the video camera or associated control unit or gateway. The encrypted encryption keys can be opened by the users that have the corresponding private keys); and
decrypting, based on the first stream key, the encrypted video stream to obtain a to-be- played video stream (Ketola: The opened keys can be used to decrypt the encrypted video).
Ketola teaches a video storage server but does not teach a cloud platform. However, Saxena teaches:
cloud platform (Saxena: [0034]: A single video stream may be received from each camera 110 and VSaaS server 130 may be configured to receive video streams from all connected cameras in parallel. [0035] VSaaS server 130 may include one or more server devices and/or associated network storage devices 140.n, where each server device includes at least one processor 132, at least one memory 134, at least one storage device 140, and at least one interface, such as camera interface 136, network interface 138, and/or storage interface 142. A plurality of VSaaS servers 130 may be configured for mounting within rack systems and maintained in a data center that is remote from cameras 110 and/or geographically distributed among a number of data centers in geographic locations for distributed, cloud-based surveillance services. [0051]: In some embodiments, relay server 104 may be integrated in VSaaS server 130. [0109] At block 626, encrypted data from the relay server may be received).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Saxena in the invention of Ketola to include the above limitations. The motivation to do so would be to facilitate data transfer of encrypted video data (Saxena: [0051]).
As per claims 7 and 14, Ketola teaches:
A method comprising:
encrypting, based on a pre-obtained first stream key, a to-be-transmitted video stream to obtain an encrypted video stream; encrypting, based on a pre-obtained first wrapping key, the pre-obtained first stream key to obtain a first encrypted stream key (Ketola: [0011] recording a first video with at least one video camera during a first time interval; [0012] encrypting the first video with the first encryption key. [0066]: encryption keys to encrypt the videos recorded by the video camera can be generated in the video camera. The public keys can be used to encrypt encryption keys (which have been used to encrypt the videos) generated by the video camera. The encrypted encryption keys can be opened by the users that have the corresponding private keys); and
sending, to a cloud platform, a data stream comprising the encrypted video stream and the first encrypted stream key (Ketola: [0063] In an embodiment, the video storage server includes a database for storing the one or more videos. [0013] sending the encrypted first video to a video storage server. [0115]: the security system also generates a ciphertext encryption key (first encrypted stream key) using the user's master key. The ciphertext encryption key can be used to securely transmit encryption key with the data. The ciphertext encryption key corresponds to the encryption key for encrypting the data, i.e., the encrypted data and encrypted stream key are stored together).
Ketola teaches a video storage server but does not teach a cloud platform. However, Saxena teaches:
cloud platform (Saxena: [0034]: A single video stream may be received from each camera 110 and VSaaS server 130 may be configured to receive video streams from all connected cameras in parallel. [0035] VSaaS server 130 may include one or more server devices and/or associated network storage devices 140.n, where each server device includes at least one processor 132, at least one memory 134, at least one storage device 140, and at least one interface, such as camera interface 136, network interface 138, and/or storage interface 142. A plurality of VSaaS servers 130 may be configured for mounting within rack systems and maintained in a data center that is remote from cameras 110 and/or geographically distributed among a number of data centers in geographic locations for distributed, cloud-based surveillance services. [0051]: In some embodiments, relay server 104 may be integrated in VSaaS server 130).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Saxena in the invention of Ketola to include the above limitations. The motivation to do so would be to facilitate data transfer of encrypted video data (Saxena: [0051]).
Claims 2-4, 8, 10-12, 15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ketola in view of Saxena as applied to claims 1, 7, and 14 above, and further in view of US 20150229475 to Benoit et al (hereinafter Benoit).
As per claim 2, Ketola in view of Saxena teaches the user device sending the client public key to the camera (Saxena: [0080] and [0097]) does not explicitly teach the limitations of claim 2. However, Benoit teaches:
further comprising: sending a pre-obtained user certificate to an Internet Protocol (IP) camera (IPC) (Benoit: [0102]: The trusted configurator service 131 may send the configurator public key and the client certificate in fourth message 1026 to the client device 110. [0104] The client device 110 may include the client certificate and a client-provided nonce in the authentication request message 1034); receiving, from the IPC and in response to the pre-obtained user certificate, a first random number (Benoit: [0095]-[0096]. [0105] In the authentication response message 1032, the network device 120 may include the network-provided nonce (first random number), the network certificate, and a MAC of the client-provided nonce); and generating, based on the first random number, the pre-obtained first wrapping key (Benoit: [0097]: The client device 110 may use the network-provided nonce, client-provided nonce, client private key, and network public key to determine the same shared key. [0053]: pairwise master key (PMK), shared key (SK). The PMK can be derived from SK. The client device may derive the PMK using a predetermined function or algorithm having at least the SK as an input variable. Similarly, the network device may derive the PMK using the predetermined function or algorithm and the same SK, i.e., the network-provided nonce (first random number) is used to generate the shared key which in turn is used to generate the PMK (first wrapping key)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Benoit in the invention of Ketola in view of Saxena to include the above limitations. The motivation to do so would be to facilitate enrollment of a device being introduced to a network (Benoit: [0007]).
As per claim 3, Ketola in view of Saxena and Benoit teaches:
The method of claim 2, wherein generating the pre-obtained first wrapping key comprises: generating a shared key that is shared with the IPC (Saxena: [0080]: The camera generates a new set of ephemeral keys for Elliptic-curve Diffie-Hellman (ECDH) key exchange. The camera public key is sent to the client. Similarly, the client generates a pair of ephemeral keys for ECDH and sends the client public key to the camera. ECDH Key exchange followed by key derivation function, as done by the key derivation function manager 344.5, results in a shared key on both sides. Benoit: [0104]-[0106]); and obtaining, based on the first random number and the shared key and using a key derivation function, the pre-obtained first wrapping key (Benoit: [0097]: The client device 110 may use the network-provided nonce (first random number), client-provided nonce, client private key, and network public key to determine the same shared key. [0053]: pairwise master key (PMK), shared key (SK). The PMK can be derived from SK. The client device may derive the PMK using a predetermined function or algorithm having at least the SK as an input variable. Similarly, the network device may derive the PMK using the predetermined function or algorithm and the same SK, i.e., the PMK is generated based on network-provided nonce (first random number) and the shared key).
The examiner provides the same rationale to combine prior arts Ketola in view of Saxena and Benoit as in claim 2 above.
As per claim 4, Ketola in view of Saxena and Benoit teaches:
The method of claim 3, wherein generating the shared key comprises: receiving, from the IPC, a device certificate (Benoit: [0105]: In the authentication response message 1032, the network device 120 may include the network-provided nonce, the network certificate, and a MAC of the client-provided nonce); obtaining, based on the device certificate, a device public key of the IPC; and obtaining, based on the device public key and a pre-obtained user private key and using a key exchange algorithm, the shared key (Benoit: [0097]: The client device 110 may use the network-provided nonce, client-provided nonce, client private key, and network public key to determine the same shared key).
The examiner provides the same rationale to combine prior arts Ketola in view of Saxena and Benoit as in claim 2 above.
As per claims 8 and 15, Ketola in view of Saxena teaches the user device sending the client public key to the camera (Saxena: [0080] and [0097]) does not explicitly teach the limitations of claims 8 and 15. However, Benoit teaches:
further comprising: receiving, from a user equipment, a user certificate (Benoit: [0102]: The trusted configurator service 131 may send the configurator public key and the client certificate in fourth message 1026 to the client device 110. [0104] The client device 110 may include the client certificate and a client-provided nonce in the authentication request message 1034. Upon receiving the client certificate, the network device 120 may verify the client certificate at verification procedure 1046); verifying, based on a pre-built-in platform public key, the user certificate (Benoit: [0104]: For example, the network device 120 may use a configurator public key to verify the client certificate); generating a first random number when verifying the user certificate has succeeded; and generating, based on the first random number, the pre-obtained first wrapping key (Benoit: [0104]: For example, the network device 120 may generate a network-provided nonce and determine the shared key using the client-provided nonce, the client public key extracted from the client certificate, the network private key, and the network-provided nonce. [0053]: pairwise master key (PMK), shared key (SK). The PMK (wrapping key) can be derived from SK. The network device may derive the PMK using the predetermined function or algorithm and the same SK).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Benoit in the invention of Ketola in view of Saxena to include the above limitations. The motivation to do so would be to facilitate enrollment of a device being introduced to a network (Benoit: [0007]).
As per claims 10 and 17, Ketola in view of Saxena and Benoit teaches:
The method of claim 8, wherein generating the pre-obtained first wrapping key comprises: obtaining a shared key that is shared with the user equipment (Benoit: [0104]: For example, the network device 120 may generate a network-provided nonce and determine the shared key using the client-provided nonce, the client public key extracted from the client certificate, the network private key, and the network-provided nonce. [0097]: The client device 110 may use the network-provided nonce, client-provided nonce, client private key, and network public key to determine the same shared key); and obtaining, based on the first random number and the shared key and using a key derivation function, the pre-obtained first wrapping key (Benoit: [0053]: pairwise master key (PMK), shared key (SK). The client device may derive the PMK using a predetermined function or algorithm having at least the SK as an input variable. Similarly, the PMK (wrapping key) can be derived from SK. The network device may derive the PMK using the predetermined function or algorithm and the same SK).
The examiner provides the same rationale to combine prior arts Ketola in view of Saxena and Benoit as in claims 8 and 15 above.
As per claims 11 and 18, Ketola in view of Saxena and Benoit teaches:
The method of claim 10, wherein obtaining the shared key comprises: obtaining, based on the user certificate, a user public key of the user equipment; and obtaining, based on the user public key and a pre-obtained device private key and using a key exchange algorithm, the shared key (Benoit: [0104]: For example, the network device 120 may generate a network-provided nonce and determine the shared key using the client-provided nonce, the client public key extracted from the client certificate, the network private key, and the network-provided nonce).
The examiner provides the same rationale to combine prior arts Ketola in view of Saxena and Benoit as in claims 8 and 15 above.
As per claims 12 and 19, Ketola in view of Saxena teaches:
The method of claim 7, further comprising: generating a device public key and a pre-obtained device private key (Saxena: [0080]: The camera generates a new set of ephemeral keys for Elliptic-curve Diffie-Hellman (ECDH) key exchange, i.e., the camera generates ephemeral public key and private key);
Ketola in view of Saxena does not teach the rest of the limitations. However, Benoit teaches:
sending, to the cloud platform, a device identity and the device public key (Benoit: [0048]: For example, the enrollment message 256 may include …, an identifier of the network device 120. [0095]: network device 120 may initiate the enrollment process 931. [0101]: the network device 120 may provide the network public key (in second message 1016) to the trusted configurator service 131); receiving, from the cloud platform and based on the device identity, the device public key, and a platform private key, a device certificate (Benoit: [0101]: The trusted configurator service 131 may also generate a network certificate by signing the network public key with the configurator private key. [0102] The trusted configurator service 131 may send the configurator public key and the network certificate in third message 1024 to the network device 120); verifying, based on a pre-built-in platform public key, the device certificate; and storing the device certificate when verifying the device certificate has succeeded (Benoit: [0106] At verification procedure 1042, the client device may verify the network certificate using the configurator public key. If verified, the client device 110 can use the network public key stored in the network certificate. Storing a received certificate was well known to one of ordinary skill in the art before the effective filing date of the claimed invention).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Benoit in the invention of Ketola in view of Saxena to include the above limitations. The motivation to do so would be to facilitate enrollment of a device being introduced to a network (Benoit: [0007]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ketola in view of Saxena and Benoit as applied to claim 2 above, and further in view of US 20070189528 to Ueda et al (hereinafter Ueda).
As per claim 5, Ketola in view of Saxena and Benoit does not teach the limitations of claim 5. However, Ueda teaches:
further comprising: encrypting, based on the pre-obtained first wrapping key, the first random number to obtain a first encrypted random number; and sending, to the IPC, the first encrypted random number (Ueda: [0034] The exclusive-OR circuit 14 receives the 256-bit random number Nonce and the 256-bit pairwise master key PMK shared by the access point 2 and client station 4, takes their bit-wise exclusive logical OR, and outputs the result as a 256-bit transformed random number EX-Nonce to the frame generator 16. [0035]: The frame generator 16 places the transformed random number EX-Nonce received from the exclusive-OR circuit 14 in the Key-Nonce field and the parameters and data received from the parameter generator 15 in the other fields in FIG. 3. [0048] The EX-Nonce value output from the exclusive-OR circuit 14 and other parameters and data output from the parameter generator 15 are supplied to the frame generator 16, which generates a message for transmission).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Ueda in the invention of Ketola in view of Saxena and Benoit to include the above limitations. The motivation to do so would be to enable two stations in a wireless LAN to exchange a pair of random numbers, from which they derive an encryption key, without enabling an eavesdropper to learn the random numbers (Ueda: [0009]).
Claims 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ketola in view of Saxena and Benoit as applied to claims 8 and 15 above, and further in view of US 6058476 to Matsuzaki et al (hereinafter Matsuzaki).
As per claims 9 and 16, Ketola in view of Saxena and Benoit does not teach the limitations of claims 9 and 16. However, Matsuzaki teaches:
further comprising: sending, to the user equipment, the first random number (Matsuzaki: column 3, lines 41-43: First device 21 generates random number R1. This represents the first challenge data. Then this is sent through the line of communication to second device 22); receiving, from the user equipment and in response to the first random number, a first encrypted random number (Matsuzaki: column 3, lines 44-50: Second device 22 generates random number R2, and creates combined data R1||R2 by combining R2 with the random number R1 received from first device 21. Here the symbol || means that the data from both numbers are lined up by place. Second device 22 encrypts this combined data R1||R2 with the authentication key S as the encryption key, and transmits the encrypted text C1 to first device 21); decrypting, based on the pre-obtained first wrapping key, the first encrypted random number to obtain a second random number (Matsuzaki: column 3, lines 51-55: (3) First device 21 decrypts the encrypted text received from second device 22 using the authentication key S as the decryption key. The separated data in the upper position is called RR1, and the separated data in the lower position is called RR2); and generating the pre-obtained first stream key when the second random number is the same as the first random number (Matsuzaki: column 3, lines 56-63: (4) First device 21 compares the separated data RR1 with the random number R1 temporarily stored in first device 21. If these match then the entity in communication is judged to be a legitimate device in possession of the authentication key S. (5) First device 21 generates random number K and sets this as the data transfer key K).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Matsuzaki in the invention of Ketola in view of Saxena and Benoit to include the above limitations. The motivation to do so would be to provide mutual authentication method and the operations for distributing the data transfer key (Matsuzaki: column 3, lines 37-39).
Allowable Subject Matter
Claims 6, 13, and 20 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 12335242 to Yu et al: An interface data transmission method and apparatus, an electronic device and a storage medium are disclosed. The interface data transmission method includes: acquiring a target content stream and a content stream key corresponding to the target content stream; encrypting the target content stream according to the content stream key to obtain encrypted stream ciphertext; acquiring content control information and a shared key of a decryption terminal, and encrypting the content stream key and the content control information according to the shared key to generate a content control information list; embedding the content control information list into the encrypted stream ciphertext to generate encrypted content stream data; and sending the encrypted content stream data to the decryption terminal.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
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, Taghi Arani can be reached at (571)272-3787. 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.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Prosecution Insights