DETAILED ACTION
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 are presented for examination.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shotton et al. (hereinafter Shotton) (US 2019/0042323 A1) in view of Chiplunkar et al. (hereinafter Chiplunkar) (US 2021/0132993 A1).
As to claim 1, Shotton teaches computer implemented method comprising (Abstract):
generating a credit unit defining a value indicating a number of times (a quota representing the maximum allowed number of client device requests for a service) an operation (API service request on data center resource) can be performed on a resource type in a data center (each service or resource represents a distinct operation or endpoint within distributed data center system that includes data center 203, 303, etc.; each API endpoint or service instance constitutes a resource type under quota enforcement) ([0005]; [0017]; [0021]-[0023]; [0062]-[0066]; [0070]-[0073]; claim 6; Table 5);
assigning credits, a credit limit (quota), and the credit unit to a user account (API Key/Key-ID identifies the user, group of users, or application to which quota counters, usage limits, and enforcement apply), wherein the credit limit is to indicate maximum credits that can be used to perform each operation in the data center (each user/customer is associated with API-id/KEY-id values identifying their account and service; a quota or counter limit is assigned to each combination) ([0019]; Table 1; [0070]-[0074]; [0064]-[0067]);
receiving, from a user associated with the user account, a request to perform the operation on a data center resource corresponding to the resource type (client/user sends a request to perform an operation on a resource (API endpoint/service) in the data center) ([0023]; [0062]);
determining whether the user is permitted to perform the requested operation on the data center resource based on available credits of the assigned credits, the credit limit, and the credit unit (an API delivery server determines whether the user is permitted or denied based on if the quota limit is exceeded by a counter, and if so, an OVER_QUOTA flag is triggered) ([0062]-[0066]; [0089]-[0090]); and
executing or denying execution of the requested operation on the data center resource based on the determination (executes or denies the user operation based on the quota check result or OVER_QUOTA flag) ([0068]-[0068]; [0130]; [0139]).
Shotton does not explicitly use the word “credit” or “credit unit.” Instead, it refers to counters, counts/diffs, usage, and quota limits. The functionality is equivalent to a credit system under the broadest reasonable interpretation, but the explicit “credit” terminology is not used.
Chiplunkar explicitly teaches a credit model in a multi-tenant environment, wherein credits are used interchangeable with tokens (Abstract; [0021]; [0031]; [0037]; Figs 1 and 2). Chiplunkar teaches generating tokens that define a value indicating the number of times an operation can be performed on a shared computing resource ([0037]; [0040]-[0042]). The system assigns tokens, a maximum token count, and a token unit to a token account associated with each request or tenant, where the maximum token count represents the highest number of tokens that can be used for performing operations ([0031]; [0037]-[0038]). A computing request is made and it is determined whether the requester is permitted to perform the requested operation based on the available tokens, the maximum token count, and the number of tokens required for the request ([0044]-[0046]). If there is a sufficient number of tokens, the system executes the computing request and debits the corresponding number of tokens from the token account. Otherwise, the system denies execution of the request until sufficient tokens are available ([0021]; [0045]-[0047]). It would have been obvious to one of ordinary skill in the art before the effective date of the application to combine the quota-enforcement framework of Shotton with Chiplunkar’s tokenized credit model because the combination would result in improved fairness and prevent reducing availability and causing delays for other tenant’s request (Chiplunkar: [0001]-[0002]).
As to claim 2, Shotton teaches the computer implemented method of claim 1, wherein generating the credit unit comprises: generating the credit unit by associating the operation and the resource type in the data center; and defining the value corresponding to the credit unit (counter key identifier binds a specific operation (API endpoint) to a resource type and assigns a quota value) ([0062]-[0064]; Table 3; [0070]-[0072]).
As to claim 3, Shotton teaches the computer implemented method of claim 1, wherein determining whether the user is permitted to perform the requested operation on the data center resource comprises: retrieving an operation value corresponding to the requested operation from an attribute associated with the data center resource (the AHEAD module has a list of all containers that have exceeded quota; each record in the counter table includes counter records or attributes describing a specific operation or API resource, such as counter_id, flags, quotal limit, count, etc.) ([0043]-[0045]; Table 4; Fig. 4), wherein the operation value is to indicate a number of credits to perform the requested operation (counters have a count field representing usage value of that service) ([0031]-[0033]; [0079]-[0082]; [0091]-[0093]; Table 5); and determining whether the user is permitted (determines whether to deny or “does not deny”) to perform the requested operation on the data center resource based on the operation value, the available credits, the credit limit, and the credit unit (http proxy server application can quickly determine if a counter has exceeded its quota) ([0044]-[0045]; [0066]-[0067]).
As to claim 4, Shotton teaches the computer implemented method of claim 3, wherein executing or denying the execution of the requested operation comprises: denying the execution of the requested operation on the data center resource in response to a determination that (determines whether to deny or “does not deny”; http proxy server application can quickly determine if a counter has exceeded its quota) ([0044]-[0045]; [0066]-[0067]): the available credits are less than the operation value (when counter has exceeded quota limit, the request is denied or blocked) ([00043]-[0045]; [0066]-[0068]); the credit limit is less than the operation value (when the count is greater than quota limit, over-quota flag is set) ([0043]-[0045]; [0089]-[0090]); the value indicating the number of times the operation can be performed on the resource type is zero (upon reset the count is set to the reset value and the over-quota flag is cleared; the counter is reset to zero before allowing service again) ([0088]-[0093]; [0130]-[0131]); the number of times the operation has been performed on the resource type exceeds the defined value (when counter has exceeded quota limit, the request is denied or blocked) ([00043]-[0045]; [0066]-[0068]); or any combination thereof.
As to claim 5, Shotton teaches the computer implemented method of claim 3, wherein executing or denying the execution of the requested operation comprises: permitting (via HTTP proxy server application) the execution of the requested operation on the data center resource in response to a determination that ([0043]-[0045]; [0064]-[0067]; Fig. 1): the available credits are equal to or greater than the operation value (aggregated count) ([0043]-[0045]; [0066]): the credit limit is equal to or greater than the operation value (execution is permitted or not denied if within the quota limit) ([0043]-[0045]; [0130]-[0133]); the value indicating the number of times the operation can be performed on the resource type is greater than or equal to one (upon reset the count is set to the reset value and the over-quota flag is cleared. After reset, over-quota services can begin servicing clients again. At this point, the count is active again) ([0088]-[0092]); and the number of times the operation has been performed (count field) on the resource type does not exceed the defined value (quota not exceeded) ([0043]-[0045]; [0080]-[0082]; [0130]-[0131]).
As to claim 6, Shotton teaches the computer implemented method of claim 3, further comprising: when the user account is associated with an active credit, deducting a number of credits (via “diff”, which represents an increment or decrement to the usage value) corresponding to the operation value (aggregated count) from the available credits associated with the user account upon either executing the requested operation on the data center resource or denying (“deny”) the execution of the requested operation on the data center resource ([0017]; [0033]; [0066]-[0067]; [0079]-[0082]; [0043]-[0045].
As to claim 7, Shotton teaches the computer implemented method of claim 3, further comprising: when the user account is associated with a passive credit (KEY-id corresponds to a given customer; RELAXED_SYNC flag/mode), deducting (via “diff” or usage delta) a number of credits corresponding to the operation value from the available credits associated with the user account upon executing the requested operation on the data center resource ([0019]; [0070]-[0074]; [0043]-[0046]).
As to claim 8, Shotton teaches the computer implemented method of claim 3, wherein retrieving the operation value corresponding to the requested operation comprises: retrieving the attribute associated with the data center resource from an attribute repository (metadata approach involving a control file and counter table function as the attribute repository) ([0075]; [0092]; [0107]); and retrieving the operation value corresponding to the requested operation from the retrieved attribute, wherein the operation value defined in the attribute is configurable (configure, defining the criteria, etc.) ([0072]; [0150]; [0031]-[0033]; [0107]).
As to claim 9, Shotton teaches the computer implemented method of claim 1, wherein assigning the credits, the credit limit, and the credit unit to the user account comprises: assigning at least one of a role-based access control and a scope-based access control to the user account (via Security Level designations of 0-7 for each user that describes different authorities) ([0117]; [0019]); and assigning the credits, the credit limit per operation, and the credit unit to the user account upon assigning at least one of the role-based access control and the scope-based access control (each API Key (Key-id) is assigned a quota limit and counter attributes (quota period for a counter is set in the portal along with quota limit and counter id) once its security level (role/scope) is defined) ([0019]-Table 1; [0045]; [0071]; [0117; Table 5]).
As to claim 10, Shotton teaches the computer implemented method of claim 1, further comprising: determining that the assigned credits, the credit unit, or both are utilized in accordance with an organization policy (track the usage of each tenant/customer against contractual usage limits) ([0005]; [0089]; [0103]); and reassigning the credits, the credit unit, or both to the user account in response to the determination (reassigns credit by reinitializing and resetting the count value to zero, etc.) ([0088]; [0103]).
As to claim 11, Shotton teaches the computer implemented method of claim 1, further comprising: setting an expiry time (reset time) to utilize the assigned credits and the credit unit associated with the user account ([0088]; [0092]); and obtaining an audit record (via counter table) of the user's transactions associated with a utilization of the assigned credits and the credit unit periodically (periodic sweeps of the counter tables) or upon the available credits and/or the value fall below a threshold (quota limit and count to enforce quota or counters that are over quota are identified) ([0107]; [0110]-[0114]; [0045]; [0130]).
As to claim 12, Shotton teaches a management node comprising:
a processor (Processor 704) (Fig. 7); and
a memory (Memory 710) comprising a credits-based access controller to ([0164]-[0168]; [0043]-[0045]; [0061]-[0066]; Fig. 7):
assign credits to a user account (the KEY-id identifies a customer or user account and counters are associated with it) ([0019]; [0070-[0073]);
set a credit limit corresponding to the user account, wherein the credit limit is to indicate maximum credits that can be used to perform each operation in a data center (quota enforcement of quota limit) ([0043]-[0045]; [0117]);
assign a credit unit to the user account, wherein the credit unit includes a value indicating a number of times an operation can be performed on a resource type (usage metric for a service is composed of a count of client requests for a particular service of a particular API during a given period) ([0031]-[0033]; [0070]-[0074]);
receive, from a user associated with the user account, a request to perform an operation on a data center resource (client/user sends a request to perform an operation on a resource (API endpoint/service) in the data center) ([0023]; [0062]);
determine whether the user is permitted to perform the requested operation on the data center resource based on available credits of the assigned credits, the credit limit, and the credit unit (an API delivery server determines whether the user is permitted or denied based on if the quota limit is exceeded by a counter, and if so, an OVER_QUOTA flag is triggered) ([0062]-[0066]; [0089]-[0090]); and
execute or deny execution of the requested operation on the data center resource based on the determination (executes or denies the user operation based on the quota check result or OVER_QUOTA flag) ([0068]-[0068]; [0130]; [0139]).
Shotton does not explicitly use the word “credit” or “credit unit.” Instead, it refers to counters, counts/diffs, usage, and quota limits. The functionality is equivalent to a credit system under the broadest reasonable interpretation, but the explicit “credit” terminology is not used.
Chiplunkar explicitly teaches a credit model in a multi-tenant environment, wherein credits are used interchangeable with tokens (Abstract; [0021]; [0031]; [0037]; Figs 1 and 2). Chiplunkar teaches generating tokens that define a value indicating the number of times an operation can be performed on a shared computing resource ([0037]; [0040]-[0042]). The system assigns tokens, a maximum token count, and a token unit to a token account associated with each request or tenant, where the maximum token count represents the highest number of tokens that can be used for performing operations ([0031]; [0037]-[0038]). A computing request is made and it is determined whether the requester is permitted to perform the requested operation based on the available tokens, the maximum token count, and the number of tokens required for the request ([0044]-[0046]). If there is a sufficient number of tokens, the system executes the computing request and debits the corresponding number of tokens from the token account. Otherwise, the system denies execution of the request until sufficient tokens are available ([0021]; [0045]-[0047]). It would have been obvious to one of ordinary skill in the art before the effective date of the application to combine the quota-enforcement framework of Shotton with Chiplunkar’s tokenized credit model because the combination would result in improved fairness and prevent reducing availability and causing delays for other tenant’s request (Chiplunkar: [0001]-[0002]).
As to claim 13, it is rejected for the same reasons as stated in the rejection of claim 3.
As to claim 14, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 15, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 16, it is rejected for the same reasons as stated in the rejection of claim 6.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 7.
As to claim 18, Shotton teaches a non-transitory computer-readable storage medium encoded with instructions that, when executed by a processor of a computing device, cause the processor to:
receive, from a user associated with a user account, a request to perform an operation on a data center resource (client/user sends a request to perform an operation on a resource (API endpoint/service) in the data center) ([0023]; [0062]);
upon receiving the request, determine available credits and a credit limit per operation associated with the user account ([0043]-[0045]); [0117]);
retrieve an operation value corresponding to the operation, the operation value indicating a number of credits to perform the operation ([0031]-[0033]; [0070]-[0074]);
upon determining that the user is permitted (via quota enforcement) to perform the operation based on the available credits, the credit limit, and the operation value, determine a remaining number of times the operation can be performed on a resource type of the data center resource based on a credit unit assigned to the user account ([0043]-[0045]; [0088]-[0093]; [0107]-[0110]; [0117]); and
execute the operation on the data center resource based on the determined remaining number (executes or denies the user operation based on the quota check result or OVER_QUOTA flag) ([0068]-[0068]; [0130]; [0139]).
Shotton does not explicitly use the word “credit” or “credit unit.” Instead, it refers to counters, counts/diffs, usage, and quota limits. The functionality is equivalent to a credit system under the broadest reasonable interpretation, but the explicit “credit” terminology is not used.
Chiplunkar explicitly teaches a credit model in a multi-tenant environment, wherein credits are used interchangeable with tokens (Abstract; [0021]; [0031]; [0037]; Figs 1 and 2). Chiplunkar teaches generating tokens that define a value indicating the number of times an operation can be performed on a shared computing resource ([0037]; [0040]-[0042]). The system assigns tokens, a maximum token count, and a token unit to a token account associated with each request or tenant, where the maximum token count represents the highest number of tokens that can be used for performing operations ([0031]; [0037]-[0038]). A computing request is made and it is determined whether the requester is permitted to perform the requested operation based on the available tokens, the maximum token count, and the number of tokens required for the request ([0044]-[0046]). If there is a sufficient number of tokens, the system executes the computing request and debits the corresponding number of tokens from the token account. Otherwise, the system denies execution of the request until sufficient tokens are available ([0021]; [0045]-[0047]). It would have been obvious to one of ordinary skill in the art before the effective date of the application to combine the quota-enforcement framework of Shotton with Chiplunkar’s tokenized credit model because the combination would result in improved fairness and prevent reducing availability and causing delays for other tenant’s request (Chiplunkar: [0001]-[0002]).
As to claim 19, Shotton teaches the non-transitory computer-readable storage medium of claim 18, further comprising instructions that, when executed by the processor, cause the processor to: deny executing the operation on the data center resource in response to a determination that the remaining number of times the operation can be performed on the resource type (determines whether to deny or “does not deny”; http proxy server application can quickly determine if a counter has exceeded its quota) ([0044]-[0045]; [0066]-[0067]) is less than a threshold (when counter has exceeded quota limit, the request is denied or blocked) ([00043]-[0045]; [0066]-[0068]).
As to claim 20, Shotton teaches the non-transitory computer-readable storage medium of claim 18, wherein instructions to execute the requested operation on the data center resource instructions to: permit execution (via HTTP proxy server application) of the requested operation on the data center resource in response to a determination that the remaining number of times the operation can be performed on the resource type is greater than or equal to a threshold (execution is permitted or not denied if within the quota limit) ([0043]-[0045]; [0130]-[0133]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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, Bradley Teets can be reached at 571-272-3338. 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.
/KENNETH TANG/Primary Examiner, Art Unit 2197