Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The present office action is responsive to communications received on 02/11/2026.
Status of Claims
1, 3, 7, 9, 12-14, 17 and 19 were amended.
Claims 1-20 are pending.
Response to arguments
With respect to applicant arguments the arguments are not persuasive. It is clear from the cited paragraphs (particularly ¶63 and 67-68) that each RKP comprises a public key and when different RKPs are rotated each RKP is kept track of to determine that current RKP is within threshold use limit. The threshold is for each RKP o f the plurality of the RKPs.
Furthermore, the examiner cites in the pertinent prior art (conclusion section) another prior art Banerjee et al. (US-20250048113-A1) that also explicitly recites in ¶116 “PQC KEM public key may be re-used for a number of times less than a predetermined threshold number.” Therefore, the examiner does not believe that the claims are allowable.
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-4, 6-13 and 15-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Donlan et al. (US 20220417036 A1) hereinafter referred to as Donlan.
With respect to claim 1, Donlan discloses: A method comprising: accessing a database maintained within a cloud environment, the database storing a plurality of public keys, (Donlan ¶67 teaches “fleet management service 134” [cloud environment] storing RPKs “route key pair (RKP)”. Each RKP comprises a “public key” and attributes as understood from Donlan ¶12).
wherein each public key has a corresponding attribute, (Donlan ¶12 each public key has a “route” attribute. Another interpretation Donlan ¶34 recites “RKP status (pending, issuing, deprecated, deactivated) [different attributes]”).
and the database further storing a plurality of attributes corresponding to the plurality of public keys, (Donlan ¶12 each public key has a “route” attribute which means if a plurality of keys are stored then there is a plurality of routes for the plurality of keys or the attributes can be a route in addition to the “RKP status (pending, issuing, deprecated, deactivated)”).
and wherein each public key is associated with either (i) a corresponding user account of a corresponding tenancy of the cloud environment or (ii) a compute instance hosted within a corresponding tenancy of the cloud environment; (given BRI a tenancy is a user account; Donlan Abstract summarizes the invention when reciting “Systems and methods are described for rotating keys in a trust store to be used by a group of peer devices for secure communications between the peers [corresponding user accounts or compute instance(s)] in the group [corresponding tenancies in a group stored on a “key store” cloud environment]. In some examples, a service, such as an identify authority service, may make a determination that a set of peers that individually trust at least one public key from a group of public keys satisfies a set of conditions. As a result of the determination, the service may update the plurality of public keys by at least removing at least one public key from the group of public keys and indicate the updated plurality of public keys to at least one of the peers in the group. The service may remove the at least one public key from the group upon determining that less than a threshold number of peers in the group use the at least one public key.”)
determining a number of occurrences of a first public key or a first attribute corresponding to the first public key occurs within the database, (Donlan ¶68 determination “The minimum age of the oldest pending RKP to start issuing: may be set to four times” which is the minimum time a public key can be used before its status is changed. In other words, the number of times a specific RPK, from a plurality of RPKs, used is tracked to determine that it does not exceed the threshold limit).
wherein each occurrence corresponds to a current usage of the first public key or the first attribute for a respective cloud resource, such that the number of occurrences corresponds to a number of different cloud resources with which the first public key or the first attribute is currently associated; (it can be understood from Donlan ¶67-68 that the RPK currently used in the ring comprises a public key currently used and each RPK has privileges to access different peer cloud resources that are associated as part of the peer group as understood from Donlan ¶63)
determining that the number of occurrences is equal to or greater than a threshold number; (Donlan ¶68 teaches determination whether the RKP is used within or more than a threshold).
tagging the first public key as being reused for at least the threshold number of times occurrences; and generating an output indicating that the first public key is being reused for at least the threshold number of occurrences. (Donlan ¶68 “age of a deactivated RKP at deletion may be set to fourteen times” which is interpreted as system output to use the RKP comprising the public key for a specific threshold).
Claims 17 and 19 recite a “non-transitory computer-readable medium” and a “system” respectively. While the claims might have slight difference in language however, they recite the same limitations as claim 1 and therefore rejected based on the same rationale.
With respect to claim 2, Donlan discloses: The method of claim 1, wherein the threshold number is a positive integer that is greater than one. (Donlan ¶68 teaches the threshold number is a number such as four times).
With respect to claim 3, Donlan discloses: The method of claim 1, wherein determining the number of occurrences of the first public key or the first attribute corresponding to the first public key within the database comprises: determining that (i) a first occurrence of the first public key or the first attribute is associated with a first user account of a first tenancy of the cloud environment, (Donlan ¶66 teaches different peers in different groups using the same RKP associated with the user of the group and ¶68 determines the usage threshold).
and (ii) a second occurrence of the first public key or the first attribute is associated with a second user account of a second tenancy of the cloud environment. (Donlan ¶67 “a fleet management service 134 may actually be a collection of systems that manage different groups [different tenancies] of peers on the route (e.g., one for the servers and one for each client fleet).” using the same RKP public key).
With respect to claim 4, Donlan discloses: The method of claim 3, wherein the first tenancy and the second tenancy are different tenancies of the cloud environment. (Donlan ¶67 teaches the peers belong to “different groups” yet using the same RKP public key).
With respect to claim 6, Donlan discloses: The method of claim 3, wherein the first tenancy and the second tenancy are a same tenancy of the cloud environment. (Donlan ¶67 teaches the peers can be users [tenants] belonging to the same group [cloud environment]).
With respect to claim 7, Donlan discloses: The method of claim 1, wherein determining the number of occurrences of the first public key or the first attribute corresponding to the first public key within the database comprises: determining that (i) a first occurrence of the first public key or the first attribute is associated with a first compute instance hosted within a first tenancy of the cloud environment, and (ii) a second occurrence of the first public key or the first attribute is associated with a second compute instance hosted within a second tenancy of the cloud environment. (Similar to claim 3, Donlan ¶66 teaches different peers in different groups using the same RKP associated with the user of the group. Donlan ¶67 “a fleet management service 134 may actually be a collection of systems that manage different groups [different tenancies] of peers on the route (e.g., one for the servers and one for each client fleet).” using the same RKP public key).
With respect to claim 8, Donlan discloses: The method of claim 7, wherein the first tenancy and the second tenancy are different tenancies of the cloud environment, or a same tenancy of the cloud environment. (It can be understood from Donlan ¶67 that the first peer and second peer are different users [tenants] of the network and not the same user that could belong to the same group or different groups user accounts’ [tenancies]).
With respect to claim 9, Donlan discloses: The method of claim 1, wherein determining the number of occurrences of the first public key or the first attribute corresponding to the first public key within the database comprises: determining that (i) a first occurrence of the first public key or the first attribute is associated with a user account of a first tenancy of the cloud environment, and (ii) a second occurrence of the first public key or the first attribute is associated with a compute instance hosted within a second tenancy of the cloud environment. (Donlan ¶68 teaches plurality of peers using RKP which has a certain number before it is rotated to a different RKP “RKP at removal may also be set to four times” and the public key can be used by peers which happen to be users accounts such as Donlan fig. 1 user 118 or compute instances Donlan fig. 1 instance 124).
With respect to claim 10, Donlan discloses: The method of claim 9, wherein the first tenancy and the second tenancy are different tenancies of the cloud environment, or a same tenancy of the cloud environment. (It can be understood from Donlan ¶67 that the first peer and second peer are different users [tenants] of the network and not the same user that could belong to the same group or different groups [tenancies]).
With respect to claim 11, Donlan discloses: The method of claim 1, wherein the first attribute is a fingerprint of the first public key, and is generated from the first public key by applying a hash function to the first public key. (Donlan ¶37 “The partition key for a peer certificate table may be the subject key identifier, such as a SHA-256 hash [fingerprint] of the peer public key.”)
With respect to claim 12, Donlan discloses: The method of claim 1, wherein the first public key is associated with at least (i) a first user account or (ii) a first compute instance, and wherein the method further comprises: responsive at least in part to the output indicating that the first public key is being reused for at least the threshold number of occurrences, prompting a user of the first user account or the first compute instance to associate a public key, which is different from the first public key, with the first user account or the first compute instance. (Donlan ¶65 teaches trigger event, such as the reaching the threshold, which “the triggering event may include some other event that prompts an action to rotate the RKPs.” And rotating the RKP means associating a public key different from the first public key to be used).
With respect to claim 13, Donlan discloses: The method of claim 1, wherein the threshold number is a low threshold number, and wherein the method further comprises: determining that the number of occurrences is equal to or greater than a high threshold number that is greater than the low threshold number; and generating a request to deactivate or delete one or more user accounts or one or more compute instances associated with the first public key. (Donlan ¶66 teaches when exceeding a first threshold of issuing then followed by a second threshold after deprecating then followed by deactivating a compute instance based on threshold of not using public key is exceeded when reciting “At operation 318, a deprecated RKP may be advanced to a deactivated state 320. Deactivated RKPs are no longer trusted”)
With respect to claim 15, Donlan discloses: The method of claim 1, wherein the database stores the plurality of public keys and the plurality of attributes for a single tenancy of the cloud environment. (It can be understood from Donlan ¶67 that the RKPs are stored [database] for one group or multiple groups of peers operating within one or more servers).
With respect to claim 16, Donlan discloses: The method of claim 1, wherein the database stores the plurality of public keys and the plurality of attributes for a plurality of tenancies of the cloud environment. (It can be understood from Donlan ¶67 that the RKPs are stored [database] for one group or multiple groups of peers operating within one or more servers).
Claims 18 and 20 recite a “non-transitory computer-readable medium” and a “system” respectively. While the claims might have slight difference in language however, they recite the same limitations as claims 15-16 and therefore rejected based on the same rationale.
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) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Donlan as applied to claims 1-4, 6-13 and 15-20 above, and further in view of Ecker et al. (US 20240160481 A1) hereinafter referred to as Ecker.
With respect to claim 5, Donlan discloses: The method of claim 4,
Donlan does not explicitly disclose: wherein the first tenancy and the second tenancy are rented out to a same cloud customer, or rented out to a first cloud customer and a second cloud customer, respectively.
However, Ecker in an analogous art discloses: wherein the first tenancy and the second tenancy are rented out to a same cloud customer, or rented out to a first cloud customer and a second cloud customer, respectively. (Ecker ¶26 “computing system 102 may be implemented at a tenancy of a cloud environment. The users 128, 130, 132 may be associated with an enterprise that has purchased and/or rented access to the tenancy.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Donlan wherein the first tenancy and the second tenancy are rented out to a same cloud customer, or rented out to a first cloud customer and a second cloud customer, respectively as disclosed by Ecker because sometimes enterprises can rent out access to tenancy and not own the system themselves as understood from Ecker ¶26.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Donlan as applied to claims 1-4, 6-13 and 15-20 above, and further in view of Sholtis et al. (US 20220321364 A1) hereinafter referred to as Sholtis.
With respect to claim 14, Donlan discloses: The method of claim 1, further comprising: receiving a request, the request accompanied by the first public key; and responsive at least in part to (i) the first public key being tagged for being reused for at least the threshold number of occurrences and (ii) receiving the request, rejecting the request (Donlan ¶66 teaches based on receiving a request and when exceeding a first threshold of issuing then followed by a second threshold after deprecating then followed by deactivating a compute instance based on threshold of not using public key is exceeded when reciting “At operation 318, a deprecated RKP may be advanced to a deactivated state 320. Deactivated RKPs are no longer trusted”)
and requesting an association of a public key, which is different from the first public key, with the first user account or the first compute instance. (Donlan ¶65 teaches trigger event, such as the reaching the threshold, which “the triggering event may include some other event that prompts [requesting an association] an action to rotate the RKPs.” And rotating the RKP means associating a public key different from the first public key to be used).
Donlan does not explicitly disclose that the received request is “to open a first user account or host a first compute instance”
However, Sholtis in an analogous art discloses: received request is “to open a first user account or host a first compute instance” (Sholtis Abstract and ¶55 a request to open a user account using a public key wherein “Another detection algorithm involves utilizing thresholds that can be set for unlocked accounts which only allow the public keys to be used an N number of times before automatically locking again … a user can choose the number of times the user expects to use the public key. If the expectation is one time and the user sets the threshold to one, then the public key will automatically relock after the next account protection check.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the received request by Donlan wherein received request is “to open a first user account or host a first compute instance” as disclosed by Sholtis to control a threshold number of time a public key can be used to open an account or have access (see Sholtis Abstract and ¶55).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Banerjee et al. (US-20250048113-A1) ¶116 “PQC KEM public key may re-used for a number of times less than a predetermined threshold number.”.
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 HANY S GADALLA whose telephone number is (571)272-2322. The examiner can normally be reached Mon to Fri 8:00AM - 4:00PM.
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, Carl Colin can be reached at (571) 272-3862. 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.
/HANY S. GADALLA/Primary Examiner, Art Unit 2493