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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-13 and 20 in the reply filed on 6/18/2026 is acknowledged.
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 20 is rejected under 35 U.S.C. 101 because the claims to not fall within at least one of the four categories of patent eligible subject matter.
Claim 20 recites a “system” configured to obtain and respond to commands. The claim does not positively recite any hardware element, only the function the system is intended to do. Therefore, under broadest reasonable interpretation, the system may be interpreted as a software program configured to perform the limitations described in the claim, directing the system as a whole toward being solely software. Therefore, claim 20 is rejected under 35 U.S.C. 101.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 6, 11- 12, 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sanchez (US-20040156506-A1)
Regarding claim 1, Sanchez teaches a method comprising: obtaining, at a cryptographic key generation service in a secure element of a device, a first one or more commands to generate and store one or more cryptographic keys in the cryptographic key generation service; (Paragraph 37, "At step 505, the key generator 315 determines whether to generate a RSA key of x-bits to store with the plurality of cached RSA keys. For example, the key generator may receive a message to generate a replacement RSA key of x-bits to replace the selected cached RSA key of x-bits for the plurality of cached RSA keys at a future appropriate time." The message to generate a replacement RSA key received by key generator the is interpreted as a cryptographic key generation service receiving a first one or more commands to generate and store cryptographic keys. Storing the keys in the cache is interpreted as the storing of the cryptographic keys. The CPU and key generator system is interpreted as a secure element.).
In response to the first one or more commands: generating the one or more cryptographic keys at the cryptographic key generation service; and (Paragraphs 36-37, "FIG. 5 illustrates a flow chart showing a method of implementing the key production phase 390 of FIG. 3 in accordance with an embodiment of the present invention. It should be understood that the operating system of the system 300 of FIG. 3 can be non-preemptive, preemptive, or any other type. At step 505, the key generator 315 determines whether to generate a RSA key of x-bits to store with the plurality of cached RSA keys. For example, the key generator may receive a message to generate a replacement RSA key of x-bits to replace the selected cached RSA key of x-bits for the plurality of cached RSA keys at a future appropriate time. Moreover, at start-up of the system 300, the key generator 315 may receive a message to generate RSA keys to store as cached RSA keys for future requests for RSA keys. Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The message to generate/store replacement RSA keys is processed in Fig. 5 to generate an RSA key, then save the RSA key in a cached location. Item 515 has the RSA key being generated, with item 520 having the generation completed.).
storing the one or more cryptographic keys at the cryptographic key generation service; (Fig. 5 shows at item 520, that if the RSA key's generation is complete, that the RSA key will be saved at a location for cached RSA keys.).
obtaining, at the cryptographic key generation service, a second command to generate a cryptographic key for an application associated with the device; and (Fig. 4 shows a request for an RSA key of X bits at 405. Paragraph 6, "Typically, the size (or length in bits) of the RSA key depends on the security needs of the particular application. The larger the size of the RSA key, the greater the security, but also the longer it takes to generate the RSA key." The request is interpreted to come from an application associated with the device.).
in response to the second command, outputting at least a portion of one of the one or more cryptographic keys stored at the cryptographic key generation service. (Fig. 4 shows that if the system received a request for RSA key of x bits, if there are cached RSA keys, it will select a cached RSA key of x bits and output the key of X bits to the requesting entity.).
Regarding claim 6, Sanchez teaches the method of claim 1. Sanchez teaches further comprising: incrementing a counter in response to storing the one or more cryptographic keys, wherein a count of the counter is based at least in part on a quantity of cryptographic keys included in the one or more cryptographic keys. (Paragraph 31, "Continuing at step 415, if any one of the plurality of cached RSA keys satisfies the request for the RSA key of x-bits, a cached RSA key of x-bits is selected and removed from the plurality of cached RSA keys." Paragraph 37, "Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." Paragraph 41, "Furthermore, at step 545, if the RSA key is completed, the RSA key is saved and stored with the plurality of cached RSA keys. Then, the method 500 proceeds to step 505 again." The generating and caching of the RSA keys, where the number of RSA keys is checked in regards to the number of keys stored, is interpreted as having a counter based on the quantity of cryptographic keys.).
Regarding claim 11, Sanchez teaches the method of claim 1. Sanchez further teaches wherein the one of the one or more cryptographic keys comprises a cryptographic key pair including a public key and a private key, and wherein the portion of the one of the one or more cryptographic keys comprises the public key. (Fig. 5 shows generating an RSA key, which by definition have public and private keys. A portion of these RSA keys is public keys.).
Regarding claim 12, Sanchez teaches the method of claim 1. Sanchez further teaches wherein the one or more cryptographic keys comprise one or more Rivest-Shamir-Adleman (RSA) key pairs. (Fig. 5 shows generation of RSA keys.).
Regarding claim 20, Sanchez teaches a system comprising: a cryptographic key generation service in a secure element, wherein the cryptographic key generation service configured to: (Paragraph 37, "At step 505, the key generator 315 determines whether to generate a RSA key of x-bits to store with the plurality of cached RSA keys. For example, the key generator may receive a message to generate a replacement RSA key of x-bits to replace the selected cached RSA key of x-bits for the plurality of cached RSA keys at a future appropriate time." The message to generate a replacement RSA key received by key generator the is interpreted as a cryptographic key generation service receiving a first one or more commands to generate and store cryptographic keys. Storing the keys in the cache is interpreted as the storing of the cryptographic keys. The CPU and key generator system is interpreted as a secure element.).
obtain a first one or more commands to generate and store one or more cryptographic keys in the cryptographic key generation service; (Paragraphs 36-37, "FIG. 5 illustrates a flow chart showing a method of implementing the key production phase 390 of FIG. 3 in accordance with an embodiment of the present invention. It should be understood that the operating system of the system 300 of FIG. 3 can be non-preemptive, preemptive, or any other type. At step 505, the key generator 315 determines whether to generate a RSA key of x-bits to store with the plurality of cached RSA keys. For example, the key generator may receive a message to generate a replacement RSA key of x-bits to replace the selected cached RSA key of x-bits for the plurality of cached RSA keys at a future appropriate time. Moreover, at start-up of the system 300, the key generator 315 may receive a message to generate RSA keys to store as cached RSA keys for future requests for RSA keys. Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The message to generate/store replacement RSA keys is processed in Fig. 5 to generate an RSA key, then save the RSA key in a cached location. Item 515 has the RSA key being generated, with item 520 having the generation completed.).
in response to the first one or more commands, generate and store the one or more cryptographic keys; (Paragraphs 36-37, "FIG. 5 illustrates a flow chart showing a method of implementing the key production phase 390 of FIG. 3 in accordance with an embodiment of the present invention. It should be understood that the operating system of the system 300 of FIG. 3 can be non-preemptive, preemptive, or any other type. At step 505, the key generator 315 determines whether to generate a RSA key of x-bits to store with the plurality of cached RSA keys. For example, the key generator may receive a message to generate a replacement RSA key of x-bits to replace the selected cached RSA key of x-bits for the plurality of cached RSA keys at a future appropriate time. Moreover, at start-up of the system 300, the key generator 315 may receive a message to generate RSA keys to store as cached RSA keys for future requests for RSA keys. Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The message to generate/store replacement RSA keys is processed in Fig. 5 to generate an RSA key, then save the RSA key in a cached location. Items 510 and 515 have the RSA key being generated, with item 520 having the generation completed. Fig. 5 shows at item 520, that if the RSA key's generation is complete, that the RSA key will be saved at a location for cached RSA keys.).
obtain a second command to generate a cryptographic key for an application associated with the system; and (Fig. 4 shows a request for an RSA key of X bits at 405. Paragraph 6, "Typically, the size (or length in bits) of the RSA key depends on the security needs of the particular application. The larger the size of the RSA key, the greater the security, but also the longer it takes to generate the RSA key." The request is interpreted to come from an application associated with the device.).
in response to the second command, output at least a portion of one of the one or more cryptographic keys. (Fig. 4 shows that if the system received a request for RSA key of x bits, if there are cached RSA keys, it will select a cached RSA key of x bits and output the key of X bits to the requesting entity.).
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 nonobviousness.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Puri (US-20070230702-A1).
Regarding claim 2, Sanchez teaches the method of claim 1. However, Sanchez does not explicitly teach wherein obtaining the first one or more commands comprises: obtaining the first one or more commands in accordance with a scheduled task.
Puri teaches wherein obtaining the first one or more commands comprises: obtaining the first one or more commands in accordance with a scheduled task (Paragraph 30, “Under certain circumstances, a later key generation request may be generated by a second communication node, a user or a resident application while communications with a first communication node are being handled. The communications with the first node may include, for example, a prior key generation request or an over-the-air (OTA) updating session with the first communication node. In such an event, information relating to the later key generation request may be stored in the key generation request storage structure 216 until such time as the transport stack 206 and key generation module 218 are freed up to handle the stored key generation request. The queued up key generation requests are represented by the blocks marked REQUEST 1 through REQUEST N in FIG. 4. In general, the pending key generation requests may be handled in a first-in, first-out order, although certain embodiments may, of course, assign multiple levels of priority to different types of key generation requests or key generation requests received from various sources.” The obtaining of the first one or more commands is interpreted as the key generation requests when being handed to the key generation modules when the system is free to handle the request. The scheduling is interpreted as the sending and storage of the request, where it is stored in a request storage structure before it is to be handled.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Puri by enhancing Sanchez’ key generation process (Fig. 4 item 420 shows that if a cached key is to be transmitted to a requesting entity, that a message is sent to the RSA key generator to replenish the key at a later time) to include a queue for storing key generation requests, where it has the key generator generate the keys when the system is free to do so, as taught by Puri. The motivation is to provide the system to store key generation requests so that in the case of the device resetting, the key generation requests are not lost.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Puri (US-20070230702-A1), in further view of Zhao (US-20200358598-A1).
Regarding claim 3, Sanchez in view of Puri teaches the method of claim 2. Puri further teaches wherein obtaining the first one or more commands in accordance with the scheduled task comprises: obtaining the first one or more commands over a … duration. (Paragraph 30, “… The queued up key generation requests are represented by the blocks marked REQUEST 1 through REQUEST N in FIG. 4. In general, the pending key generation requests may be handled in a first-in, first-out order, although certain embodiments may, of course, assign multiple levels of priority to different types of key generation requests or key generation requests received from various sources.” The obtaining of the first one or more commands is interpreted as the key generation requests when being handed to the key generation modules when the system is free to handle the request. The scheduling is interpreted as the sending and storage of the request, where it is stored in a request storage structure before it is to be handled.).
The motivation to combine Sanchez and Puri is the same as in claim 2.
However, Sanchez in view of Puri does not teach a obtaining the first one or more commands over a fixed duration.
Zhao teaches obtaining the first one or more commands over a fixed duration. (Paragraphs 13-15, "According to some examples of the present disclosure, generating a key request period for each key request according to the quantity of secret-keys to be provisioned may include: generating a key request pair when any two key requests with a high level can be paired, adding the quantity of keys required by the two key requests of each key request pair and taking the summation as the quantity of secret-keys required by the key request pair; determining the quantity of secret-keys that can be generated in one time slot; calculating the quantity of time slots required by each key request according to the ratio of the quantity of secret-keys to be provisioned for each key request and the quantity of secret-keys that can be generated in one time slot; and generating a key request period for each key request according to the quantity of time slots required by the key request. According to some examples of the present disclosure, configuring an SKP period according to the SKP queue and the key request period of each key request may include: determining the quantity of time slots required by all the key requests; extracting time slots according to the quantity determined; dividing the time slots exacted according to the order of the key requests in the key request queue and the key request period of each key request; and allocating the time slots divided to each key request. According to some examples of the present disclosure, generating at least one secret-key according to the SKP queue in the SKP period may include: generating secret-keys for each key request in the time slots allocated to the key request." The time slot generated for the key requests, with these time slots being allocated to each key request, then the secret keys for these key requests being generated in the time slots allocated is interpreted as a key generating component receiving key generation commands over a fixed duration.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez in view of Puri’s RSA cache system with Zhao by enhancing Sanchez in view of Puri’s key scheduling process to generate keys from key generation requests in allocated time slots based on the determined time requirements, as taught by Zhao. The motivation is to efficiently perform key generation by generating keys in clearly designated time windows so that the system can better schedule and plan generating keys in a way that takes expected generation time into account, being able to maximize idle times to generate the greatest number of scheduled keys.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Kuravangi-Thammaiah (US 20260089499 A1), hereafter referred to as Kuravangi.
Regarding claim 4, Sanchez teaches the method of claim 1. However, Sanchez does not teach further comprising: in response to outputting the portion of the one of the one or more cryptographic keys, applying a flag to the one of the one or more cryptographic keys, wherein the flag indicates a status associated with the one of the one or more cryptographic keys.
Kuravangi teaches in response to outputting the portion of the one of the one or more cryptographic keys, applying a flag to the one of the one or more cryptographic keys, wherein the flag indicates a status associated with the one of the one or more cryptographic keys. (Paragraph 27, "The authentication request received by the home core network device may include a request for application-specific keys or an indication of preferred application services of the UE 105. Such additional information in the authentication request may streamline generation or retrieval of network key information that is closely aligned with immediate requests of the UE 105. The H-NEF may act as an intermediary between the roaming UE 105 and other home core network devices responsible for authenticating the roaming UE 105 and providing the network key information to facilitate secure access to application services." Paragraph 29, "As shown at step 5, the home core network device (e.g., the H-NEF) may receive the network key information from the other home core network device (e.g., the H-AAnF). For example, the other home core network device (e.g., H-AAnF) may provide the network key information to the home core network device (e.g., the H-NEF), and the home core network device (e.g., the H-NEF) may receive the network key information from the other home core network device (e.g., the H-AAnF). In some implementations, the network key information may include a set of application function keys that includes an application key identifier, an authentication key identifier associated with the UE 105, a monitoring key for use by a lawful intercept entity, and/or the like. Alternatively, or additionally, the home core network device (e.g., H-NEF) may receive temporary network key information that is time-limited and specific to a roaming duration of the UE 105. The H-AAnf may provide additional application function keys KAF that are associated with other application servers 115 a priori if those application servers 115 have pre-registered with the home network or are requested by the V-NEF." The request for application specific keys is interpreted as the second command type. The keys are interpreted as the application function keys with the application key identifier. The applied flags are interpreted as the application key identifier on the keys, the reason being that the application key identifiers indicate the application the keys are to be associated with, thus being a status of the key’s affiliation.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Kuravangi by enhancing Sanchez’ outputted keys to have an indicator attached to them, indicating the application the key is intended to be used for, as taught by Kuravangi. The motivation is to organize generated and requested keys with an identifier such that the system can keep track of which RSA keys are being used for the applications requesting them.
Regarding claim 5, Sanchez in view of Kuravangi teaches the method of claim 4. Kuravangi teaches wherein the status indicates that the one of the one or more cryptographic keys is unavailable for one or more other applications associated with the device. (Paragraph 27, "The authentication request received by the home core network device may include a request for application-specific keys or an indication of preferred application services of the UE 105. Such additional information in the authentication request may streamline generation or retrieval of network key information that is closely aligned with immediate requests of the UE 105. The H-NEF may act as an intermediary between the roaming UE 105 and other home core network devices responsible for authenticating the roaming UE 105 and providing the network key information to facilitate secure access to application services." Paragraph 29, "As shown at step 5, the home core network device (e.g., the H-NEF) may receive the network key information from the other home core network device (e.g., the H-AAnF). For example, the other home core network device (e.g., H-AAnF) may provide the network key information to the home core network device (e.g., the H-NEF), and the home core network device (e.g., the H-NEF) may receive the network key information from the other home core network device (e.g., the H-AAnF). In some implementations, the network key information may include a set of application function keys that includes an application key identifier, an authentication key identifier associated with the UE 105, a monitoring key for use by a lawful intercept entity, and/or the like. Alternatively, or additionally, the home core network device (e.g., H-NEF) may receive temporary network key information that is time-limited and specific to a roaming duration of the UE 105. The H-AAnf may provide additional application function keys KAF that are associated with other application servers 115 a priori if those application servers 115 have pre-registered with the home network or are requested by the V-NEF." The request for application specific keys is interpreted as the second command type. The keys are interpreted as the application function keys with the application key identifier. The keys being application specific is interpreted as the keys being unavailable for one or more other applications associated with the device.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Kuravangi by enhancing Sanchez’ outputted keys to have an indicator attached to them, indicating the application the key is intended to be used for, with the key being specific to applications/application servers, as taught by Kuravangi. The motivation is to enhance security of the keys being generated for applications, since by binding these keys to specific applications, possible multiple application compromises are prevented by having only a single application compromised.
Claim(s) 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Malygin (US-20170177248-A1).
Regarding claim 7, Sanchez teaches the method of claim 6. Sanchez teaches further comprising:
obtaining, at the cryptographic key generation service, a third command to generate and store another cryptographic key in the cryptographic key generation service; and (Paragraph 37, "Moreover, at start-up of the system 300, the key generator 315 may receive a message to generate RSA keys to store as cached RSA keys for future requests for RSA keys. Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The case of the key generating deciding to not generate an RSA key for the plurality of RSA keys in response to a key generation request is interpreted as the third command to generate and store a cryptographic key in the key generation service.)
in response to the third command, … [not generating keys] … based at least in part on the count of the counter satisfying a threshold. (Paragraph 37, "Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The threshold is interpreted as the number of keys not being below a certain number, thus not generating them.).
However, Sanchez does not teach … outputting a message comprising an error code …
Malygin teaches … outputting a message comprising an error code … (Paragraph 33, "When a request is made to allocate a storage chunk of a given type, the system (or more particularly the chunk management service 108c) determines which group 302 the chunk belongs to and then compares the current node used capacity to the used capacity threshold assigned to the chunk group. If the node used capacity is below the chunk group threshold, a new chunk may be allocated. Otherwise, the system may return an error indicating insufficient storage capacity.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Malygin by enhancing Sanchez’ key generation system, when it doesn’t generate a key due to the cached RSA keys not being below a configured value, an error in regards to key capacity is sent in response, as taught by Malygin. The motivation is to incorporate a key capacity system to prevent an unnecessary amount of RSA keys to be generated, utilizing a set capacity of keys to store, with the system responding to a key generation request with a capacity error to indicate to the requesting entity no more keys are needed than what has already been generated, thus preventing more unnecessary requests from the requesting entity.
Regarding claim 8, Sanchez in view of Malygin teaches the method of claim 7. Sanchez teaches further comprising: decrementing the counter in response to outputting the portion of the one of the one or more cryptographic keys. (Paragraph 31, "Continuing at step 415, if any one of the plurality of cached RSA keys satisfies the request for the RSA key of x-bits, a cached RSA key of x-bits is selected and removed from the plurality of cached RSA keys." Paragraph 37, "Additionally, the key generator 315 may check whether the actual number of cached RSA keys in each group is below the level provided by the value associated with each group, whereas the value is a configuration parameter of each group. If the key generator 315 decides to generate a RSA key for the plurality of cached RSA keys, the method 500 proceeds to step 510. Otherwise, the key generator 315 waits." The removing of the cached RSA keys is interpreted as decrementing a counter of RSA keys, since there is a key generator checking an actual number of cached RSA keys cached.).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Hopkins (US-7016494-B2), in further view of Szigeti (US-20240297708-A1).
Regarding claim 9, Sanchez teaches the method of claim 1. Sanchez further teaches wherein obtaining at least one of the first one or more commands is based at least in part on a level of performance … associated with the device … (Paragraph 23, "Since the request for the RSA key of x-bits is selected from the plurality of cached RSA keys 140, the CPU does not have to be used to generate the RSA key in real-time as is done in the prior art. As discussed earlier, the computational capacity of the CPU may not allow real-time generation of the RSA key within a reasonable amount of time that does not affect overall system performance. Thus, the cached RSA keys provide a buffer to mitigate the affects that generation of RSA keys in real-time would have on the system due to a slow CPU. By storing the cached RSA keys, the wait time when a request for a RSA key is received is very short, potentially near zero since the RSA key has already been generated and stored prior to receiving the request for the RSA key." The generate and store commands are based on the device not being able to perform real time generation of an RSA key in a reasonable amount of time.).
However, Sanchez does not explicitly teach obtaining … commands … based at least in part on a level of performance of at least one application associated with the device failing to satisfy a threshold.
Hopkins teaches wherein obtaining at least one of the first one or more commands is based at least in part on a level of performance of at least one application associated with the device failing to satisfy [low latency]. (Col 5 lines 24 - 50, "To summarize, the generation of cryptographic keys based on large prime numbers (such as for use in the classic two-prime RSA public key cryptosystem, and in the MultiPrime extension of the RSA system) is a computationally expensive problem requiring total operations on the order of the key length L (in bits) taken to the fourth power. As the need for stronger security forces the RSA public key cryptosystem cryptographic key lengths to grow from 512 to 1024, 2048, and 4096 bits, the time and cost of computer resources for generation of a new key grows correspondingly from 1 to 16 to 256 to 4096. In certain certificate authority applications, key management applications, secure server applications, and secure client applications, both the latency (elapsed time) and the throughput (transactions per second) of the end application involving key generation may be important to operational efficiency and economics or to user satisfaction" Col. 6 lines 1-7, "It is an object of the present invention to provide a system and method that provides large randomly generated prime numbers and cryptographic key parameters in response to requests therefor with a minimum amount of latency." Col 23, lines 17 - 27, "An advantage of the above described methods and apparatus for providing cryptographic parameters with minimal latency is that it eliminates all of the computational latency in delivering a cryptographic key when requested by an application. For example, the latency seen by a requesting application could be reduced from a few seconds to just a few microseconds. The present invention provides for an application (having capacity and transaction rate limited by slow key generation performance in accordance with prior art methods) to experience an improvement by a very large factor on the order of 100.times. or more." Col 22 line 50 - Col 23 lines 1-5, "At time t.sub.1, the server system 32 (FIG. 2) is initialized and begins to precompute and securely store sets of cryptographic parameters, and continues the process of precomputing and securely storing until a time t.sub.2 when the key memory storage unit reaches its full memory capacity. At times t.sub.3, t.sub.5, and t.sub.7, the server system 32 receives bursts of requests for sets of cryptographic parameters, and during each burst of requests, the number of sets of cryptographic parameters stored in the key memory storage unit decreases. However, there is no latency in issuing key parameters in response to requests as shown by the request latency curve 162 unless the number of cryptographic parameters in the key memory storage unit is exhausted to zero, or EMPTY." The precomputing of the keys is done to reduce latency of applications running on the devices reliant on the generation of the RSA keys. The precomputing having keys repeatedly generated is interpreted as obtaining commands based on the device failing to satisfy low latency.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Hopkins by enhancing Sanchez’ system to base its key generation commands based on minimizing latency for applications by attempting to maximize the keys generated, as taught by Hopkins. The motivation is to ensure low latency and high speed of applications, since high latency in applications requiring RSA key generation results in failure to provide a satisfactory user experience.
However, Sanchez in view of Hopkins does not explicitly teach … a threshold.
Szigeti teaches … a threshold (Paragraph 35, "Consider an example where latency is used as a QoS metric for routing the data. The source ground station 108 may include a latency component 132 that determines a type of the data (e.g., video data, sensor data, etc.), and/or the application 104 that generated the data (e.g., a web-conferencing application, sensor application, etc.) and determine a latency threshold for the data. In a simplistic example, the latency threshold may be on a scale from 1-10 where a latency threshold of “1” would be used for an application 104 with almost no latency requirements (e.g., data collection application 104), and a latency threshold of “10” would be used for an application 104 with very strict (low) latency requirements (e.g., video-conferencing application). As another example, the latency component 132 may determine actual latency values for the data, such as an acceptable latency defined by a number of milliseconds, seconds, minutes, etc.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez in view of Hopkin’s’ RSA cache system with Szigeti by enhancing Sanchez in view of Hopkin’s’ latency system with applications to have different latency thresholds for different types of applications, as taught by Szigeti. The motivation is to have the system allocate the pre-generated key resources to the applications that need them most, with the applications of lower latency requirements not being prioritized for the key allocation process.
Claim(s) 10 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sanchez (US-20040156506-A1) in view of Yan (“Intel and TongxinMicro Implement StrongBox on Celadon,” June 12 2024).
Regarding claim 10, Sanchez teaches the method of claim 1. However, Tan does not explicitly teach wherein the secure element comprises an embedded secure element (eSE) or an integrated secure element (iSE).
Yan teaches wherein the secure element comprises an embedded secure element (eSE) or an integrated secure element (iSE). (Page 2 shows Keymint running on a secure element as a cryptographic key generation service on a mobile device.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Yan by enhancing Sanchez’ secure element component with the key generation unit and CPU to be an embedded secure element on a computing device, as taught by Yan. The motivation is to have dedicated processing components for key generation isolated from the rest of the device so that possible attacks on the device’s main CPU won’t compromise key generation on the device.
Regarding claim 13, Sanchez teaches the method of claim 1. However, Sanchez does not teach wherein the cryptographic key generation service is KeyMint.
Yan teaches wherein the cryptographic key generation service is KeyMint (Page 2 shows Keymint running on a secure element as a cryptographic key generation service.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sanchez’ RSA cache system with Yan by enhancing Sanchez’ secure element component with the key generation unit and CPU to be an embedded secure element on an android device, having KeyMint as the service running on it, as taught by Yan. The motivation is to enhance Sanchez’ system by incorporating it on a device that would benefit from pre-generating keys, such as Android devices, as Android devices in general have low processing capabilities, utilizing KeyMint as the service since it would operate well with Android devices. (Yan, Page 2, “KeyMint, ensuring seamless integration and interoperability. Additionally, the associated Vendor Test Suite (VTS) and Compatibility Test Suite (CTS) tests have yielded exceptional results, with nearly 100% of the tests passing successfully.”)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
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, Rupal Dharia can be reached at 571-272-3880. 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.
/M.H.R./Examiner, Art Unit 2492
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491
Prosecution Insights