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 .
The following NON-FINAL Office Action is in response to Applicant’s communication filed 09/10/2025 regarding Application 19/325,378. The following is the first action on the merits.
Priority Acknowledgment
Examiner acknowledges Applicant’s priority claim as a continuation of Application 17/737,309 with a priority filing date of 05/05/2022.
Status of Claim(s)
Claim(s) 1-20 is/are currently pending and are rejected as follows.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1, 8, and 15 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over Claim(s) 1, 8, and 15 of U.S. Patent No. US 12,437,245 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the limitations below are anticipated by the claims provided in the previously granted patent. Support for this determination is given in the citations provided below:
Claim(s) 1, 8, and 15 –
creating an account associated with a license for computational resources; (Bauwer: Claims 1, 8, and 15: “generate an account, the account including a license for a plurality of computational resources”)
generating an allotment of the computational resources; (Bauwer: Claims 1, 8, and 15: “generate an allotment of computational resources under the license of the account”)
in response to generating the allotment, populating the allotment with a plurality of seats representing authorized entities, (Bauwer: Claims 1, 8, and 15: “in response to generating the allotment, populate the allotment of computational resources with a plurality of seats, the plurality of seats being a selection of individuals or devices for whom usage of the plurality of computational resources is authorized”)
in response to populating the allotment, maintaining associations between the seats and corresponding devices or users in a dynamic table in real-time, and (Bauwer: Claims 1, 8, and 15: “in response to populating the allotment, store an identifier of an individual or a device, and a seat of the plurality of seats within a dynamic table stored in the memory, the identifier representing an association between the individual or the device, and that seat”)
in response to maintaining associations between the seats and corresponding devices or users, controlling access authorization to the computational resources based on seat assignments within the allotment; (Bauwer: Claims 1, 8, and 15:” automatically control an authorization and deauthorization of that seat to access a portion of the plurality of computational resources under the license of the account”)
detecting access to the computational resources by an accessing device; (Bauwer: Claim(s) 1, 8, and 15: “based on the portion of the plurality of computational resources under the license of the account being accessed by an individual or device associated with an authorized seat, track usage of the plurality of computational resources by the individual or device”)
in response to detecting access to the computational resources, identifying a seat associated with the accessing device using the dynamic table; and (Bauwer: Claim(s) 1, 8, and 15: “in response to tracking usage of the plurality of computational resources by the individual or device, identify the authorized seat associated with the identifier of the individual or the device in the dynamic table”)
in response to identifying the seat associated with the accessing device, attributing resource consumption to the identified seat. (Bauwer: Claim(s) 1, 8, and 15: “in response to identify the authorized seat, tag the tracked usage of the plurality of computational resources as usage by the identified seat; and in response to tagging the tracked usage of the plurality of computational resources as usage by the identified seat, report the tracked usage of the plurality of computational resources by the identified seat to a usage asset of the license.”)
Therefore Claim(s) 1, 8, and 15 of Applicant’s claims are rejected under double patenting in view of the rationale provided above as the content within Applicant’s claim limitations are directed to patentably indistinct subject matter from the previously granted patent.
Statutory Subject Matter with Regard to 35 U.S.C. 101
Claim(s) 1-20 have been analyzed under the Alice/Mayo framework and determined to be statutory with regards to 35 U.S.C. 101 for the following reasons. First, under Step 1 of the Alice/Mayo framework, it must be considered whether the claims are directed to one or more of the statutory classes. In the instant case, Claim(s) 1-7 are directed towards an apparatus, Claim(s) 8-14 is directed towards a method comprising at least one step, and Claim(s) 15-20 are directed towards a product. Accordingly, these claims fall under the four statutory category of invention and will be further analyzed under Step 2 of the Alice/Mayo framework. Independent claims 1, 8, and 15 were all deemed to recite the abstract idea of Organizing Human Activity, specifically that of Commercial or Legal Interactions. However, under Step 2A, Prong Two, the claims were
deemed to recite several additional elements such as the computational resources, user account, processor, computer-readable medium, and dynamic table are integrated in such a way that it provides an improvement onto the technology of computational resource assignment and tracking, and integrates the abstract idea into something significantly more than merely adding the words “apply it” to a computer. Therefore the claims as currently represented are deemed allowable subject matter in view of 101. However, any changes made to Applicant’s claims to overcome any applied rejections below does not prevent a rejection under 101 should it be deemed appropriate under subsequent analysis in view of those changes.
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) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ennaji (US 9,645,840 B2) in view of Shah (US 2023/0195858 A1)
Claim(s) 1, 8, and 15 –
Ennaji discloses the following limitations:
a processor; (Ennaji: Column 4 lines 5-20, "Those skilled in the art will also appreciate that the subject matter described herein may be practiced on or in conjunction with other computer system configurations beyond those described herein, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handheld computers, personal digital assistants, e-readers, cellular telephone devices, special-purposed hardware devices, network appliances and the like. The embodiments described herein may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.")
a computer-readable medium storing instructions that are operative upon execution by the processor to: (Ennaji: Column 4 lines 5-20, "Those skilled in the art will also appreciate that the subject matter described herein may be practiced on or in conjunction with other computer system configurations beyond those described herein, including multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, handheld computers, personal digital assistants, e-readers, cellular telephone devices, special-purposed hardware devices, network appliances and the like. The embodiments described herein may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.")
create an account associated with a license for computational resources; (Ennaji: Column 2 lines 53-60, "In various embodiments described further in this disclosure, customers may be provided with the ability to create a private marketplace that operates to offer a customer-defined set of the customer's instances to a selected group of users according to a bidding or pricing policy that, in some cases, may be similar to a spot instance policy. For example, an organization such as a university may have a set of reserved instances that are offered via a private marketplace that allows users to bid for the reserved instances. In this example, the university may offer the customer-defined set of instances to departments within the university. Individuals or computers within the departments can bid internally for the reserved instances."; Column 17 lines 4-16, "In one embodiment, the functionality of the user-defined pool generation service 180 may be provided via software that can be installed and executed on a customer's computing resources. For example, the customer may own and/or operate their own computing infrastructure and configure their computing resources as a plurality of resource slots configured to host computing instances. The pool generation service software may provide interfaces for selecting the customer's resource slots, selecting parameters for a user-selected pool as described above and create the user-selected pool. The pool generation service software may further facilitate the requests/bids for the resource slots and track usage information for tracking/billing purposes."; Column 11 line 31-51, "resource manager of the provider network may implement a programmatic resource reservation interface (e.g., via a Web site or a set of Web pages) that allows clients to learn about, select, purchase access to and/or reserve resource instances. In some embodiments discussed below where an entity such as a resource manager or a pricing optimizer is described as implementing one or more programmatic interfaces such as a Web page or an API, an interface manager subcomponent of that entity may be responsible for the interface-related functionality. In many embodiments equivalent interface-related functionality may be implemented by a separate or standalone interface manager, external to the resource manager and the pricing optimizer. Such an interface may include capabilities to allow browsing of a resource catalog, provide details and specifications of the different types or sizes of resources supported, the different reservation types or modes supported, pricing models and so on.")
generate an allotment of the computational resources; (Ennaji: Column 9 line 45-63 "A network set up by an entity such as a company or a public sector organization to provide one or more services (such as various types of cloud-based computing or storage) accessible via the Internet and/or other networks to a distributed set of clients may be termed a provider network. Such a provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment and the like, needed to implement and distribute the infrastructure and services offered by the provider network."; Column 12 line 64 - Column 13 line 6, "The interface manager 482 may in some embodiments implement one or more programmatic interfaces allowing clients 448 to search for, browse, reserve and acquire instances 430 to obtain various types of services, e.g., to run and/or access various applications. In the illustrated embodiment, at a given point in time, some or all of the instances 430 may be assigned to instance pools, such as reserved instance pools 421A or 421B, on-demand instance pools 423A or 423B, available instance pool 425 or other pools such as other pool 427."; Column 13 line 29-55, "In some embodiments, such as in FIG. 5, a data center 500 may be viewed as a collection of shared computing resources and/or shared infrastructure. For example, as shown in FIG. 5, a data center 500 may include virtual machine slots 504, physical hosts 502, power supplies 506, routers 508, isolation zones 510 and geographical locations 512. A virtual machine slot 504 may be referred to as a slot or as a resource slot. A physical host 502 may be shared by multiple virtual machine slots 504, each slot 504 being capable of hosting a virtual machine, such as a guest domain. Multiple physical hosts 502 may share a power supply 506, such as a power supply 506 provided on a server rack. A router 508 may service multiple physical hosts 502 across several power supplies 506 to route network traffic.")
in response to generating the allotment, populate the allotment with a plurality of seats representing authorized entities, (Ennaji: Column 16 line 38-50, "a customer may have a first account for a first project and have associated resource slots allocated with the first account. The customer may also have a second account for a second project and have associated resource slots allocated with the second account. In one embodiment, the customer may be provided the ability to select resource slots associated with either the first or second accounts and allocate the selected resource slots for a single private marketplace. Customers may thus be able to mix and match resources from multiple pools of resources into one user-defined pool.")
and in response to maintaining associations between the plurality of seats and corresponding devices or users, control access authorization to the computational resources based on seat assignments within the allotment; (Ennaji: Column 17 line 17-40, "Entity A, who may correspond to entity A in FIG. 6, may have associated internal users A, B, C, D, E and F. Entity A may also have allocated reserved instances A, B, C and D of entity A's reserved instances in user-defined pool 620. Entity A may also allocate instances 1 and 2 of entity A's spot instances for the user-defined pool 620. Entity B may have associated internal users N, P, R, S, T and U. Entity B may also allocate instances K and L of entity B's reserved instances for user-defined pool 650. User B may also allocate instances 8 and 9 of user B's spot instances for the user-defined pool 650. Entity A may further authorize its internal users A, B, C, and D (subset 710) to access its user-defined pool 620. Entity B may further authorize its internal users R, S, and T (subset 720) to access its user-defined pool 650. The authorized internal users may now bid for access to the instances in their respective user-defined pools. Furthermore, entity A and entity B may elect to join resources and request that user-defined pool 620 and user-defined pool 650 be joined into a single user-defined pool. In one embodiment, users A, B, C, and D of entity A and users R, S, and T of entity B may bid for the combined single user-defined pool.")
detect access to the computational resources by an accessing device; (Ennaji: Column 24 line 1-19, "The user-defined pool record 1200 may further contain information regarding one or more usage records 1220A-1220N (also referred to herein generally as "usage 1220") and billing records 1222A-1222N (also referred to herein generally as "billing 1222"). As further discussed above in regard to FIG. 10, a user may access an instance after successfully bidding for the instance in the private marketplace. Billing records 1222A-1222N for usage 1220A-1202N may be tracked for the user for billing purposes. It will be appreciated that the user-defined pool record 1200 may contain additional data elements beyond those shown in FIG. 12 and described above that are utilized by the instance management module 926, the instance listings module 936 and/or other modules of the cloud computing platform 902 implementing the private marketplace.)
in response to identifying the seat associated with the accessing device, attribute resource consumption to the identified seat. (Ennaji: Column 24 lines 20-28, “In additional embodiments, the instance management module 9926 or other modules in the cloud computing platform 0902 may provide UIs or APIs 932 to the customer 920 and/or customer computer system 9922 that allow the customer to modify their user-defined pool, check the status of the user-defined pool and/or to delete the user-defined pool if it is no longer desired to provide the instances using the user-defined pool delivery mechanism.”)
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
in response to populating the allotment, maintain associations between the plurality of seats and corresponding devices or users in a dynamic table in real-time, (Shah: Paragraph 18, “For example, the license system may store the license data in a database, a table, a list, and/or the like associated with the license system. In some implementations, the license system may store the license data in the data structure in accordance with the fields (e.g., a name, a type of license, entitlements associated with the license, a start date and duration of the license, an object type associated with the license; a quantity of objects associated with the license, and/or the like) provided in the device licenses and the organization licenses.”; Paragraph 19, “As shown in FIG. 1B, and by reference number 115, the license system may identify, in the license data, entitlements for one or more licenses associated with the organization and may combine the entitlements to generate combined entitlements. For example, the organization may be associated with one or more licenses, such as one or more device licenses and/or one or more organization licenses. The license system may identify, in the license data, the one or more licenses associated with the organization. For example, the license system may parse the license data to generate parsed license data (e.g., parsed according to the fields of the licenses), and may identify the one or more licenses associated with the organization in the parsed license data. The license system may identify, in the parsed license data of the one or more licenses, the entitlements for the one or more licenses associated with the organization. The license system may combine the entitlements, for the one or more licenses associated with the organization, to generate the combined entitlements. For example, a security device management license may provide one-hundred (100) gigabytes (GB) of storage, an application insights license may provide five-hundred (500) GB of storage, and a secure access service edge (SASE) license may provide one-thousand and two-hundred (1,200) GB of storage. In such an example, the combined storage entitlements may provide one-thousand and eight-hundred (1,800) GB. In some implementations, the license system may store the combined entitlements in the data structure associated with the license system.”; Paragraph 23, “As further shown in FIG. 1E, and by reference number 135, the license system may generate, based on the request and the entitlement-to-capability mapping, an authentication token for the user based on particular capabilities associated with a particular role of the particular user and particular entitlements associated with the particular capabilities. For example, when the license system receives the request for authentication, the license system may identify the particular role of the particular user in the request for authentication. In some implementations, the license system may determine first particular capabilities corresponding to the particular role of the particular user, based on identifying, in the license data, the roles of the users and the capabilities associated with each of the roles, as described above. The license system may also identify particular entitlements associated with the device, the service, the software, and/or the like to be accessed by the particular user. In some implementations, the license system may determine second particular capabilities corresponding to the particular entitlements based on the entitlement-to-capability mapping. The license system may combine the first particular capabilities and the second particular capabilities to generate resultant particular capabilities. The license system may generate the authentication token and may populate the authentication token with the resultant particular capabilities. If the particular user is authenticated, the license system may provide the authentication token to the user device. The user device may utilize the authentication token for requests (e.g., API calls) provided to the multi-tenant system.”)
in response to detecting access to the computational resources, identify a seat associated with the accessing device using the dynamic table; and (Shah: Paragraph 24, “FIG. 1F is an example call flow diagram associated with authorizing the user device to access an application (App) of the multi-tenant system. As shown at step 1, the user device may access the application of the multi-tenant system. As shown at steps 2 and 3, the application may redirect the user device to the license system, and the user device may grant access to the redirection to the license system. As shown at steps 4 and 5 of FIG. 1F, the license system may provide an authorization code to the application, and the application may exchange, with the license system, the authorization code for an access token. The access token may be utilized to access a resource of the multi-tenant system (e.g., the application). A resource owner may include an owner of the resource that is being accessed. A client may include an application that accesses protected resources on behalf of the resource owner. A resource server may include a server that hosts the protected resources and accepts and/or responds to requests by clients using access tokens. An authorization server may include server that issues access tokens after successfully authorizing a client and a resource owner. An authorization grant may include a credential that represents the resource owner’s authorization (to access protected resources) used by the client to obtain an access token. An access token may include a credential used to access protected resources and that represents specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and the authorization server. A scope may define permissions of an access token and may define what resources can be accessed using the access token.”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Claim(s) 2, 9, and 16 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji further discloses the following:
based on removing the seat, automatically deauthorize the seat from accessing the computational resources. (Ennaji: Column 14 line 54 - Column 15 line 7, "User A may have associated reserved instances 600, on-demand instances 605 and spot instances 610. User A may allocate instances A, B, C and D of user A's reserved instances 600 for userdefined pool 620. User A may also allocate instances 1 and 2 of the spot instances 600 for the user-defined pool 620. Instances A, B, C and D of user A's reserved instances 600 may be referred to as a subset of the reserved instances 600, and instances 1 and 2 of the spot instances 600 may be referred to as a subset of the spot instances 600. User B may have associated reserved instances 630 and spot instances 640. User B may allocate instances K and L of user B's reserved instances 630 for user-defined pool 650. User B may also allocate instances 8 and 9 of user B's spot instances 640 for the user-defined pool 650. Instances Kand L of user B's reserved instances 630 may be referred to as a subset of the reserved instances 630, and 8 and 9 of user B's spot instances 640 may be referred to as a subset of the spot instances 640. In some embodiments, user A or user B can remove instances that have been allocated to a user-defined pool."; Column 23 line 4-18, "According to one embodiment, the customer 920 may be able to list the specific identifier, name and organization for the users who can access the marketplace. These users may have been previously entered and stored as users associated with customer 920. The user information can be used to determine users who are authorized to bid for the resources in the private marketplace and can also be used to track usage for billing purposes. The customer 920 may also remove one or more users by deleting users using UI controls 1104A-1104 N .")
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
update the dynamic table when a seat is removed from the plurality of seats; and (Shah: Paragraph 20, “As shown in FIG. 1C, and by reference number 120, the license system may determine an entitlement count of the combined entitlements, may add new entitlements to the entitlement count, and may subtract expired entitlements from the entitlement count. For example, the license system may add the quantity of entitlements provided in the combined entitlements to determine the entitlement count of the combined entitlements. In some implementations, if the organization receives a new license with new entitlements or receives new entitlements to an existing license, the license system may add the quantity of the new entitlements to the entitlement count to generate an updated entitlement count. In some implementations, if one or more entitlements, of the one or more licenses associated with the organization, expire, the license system may subtract the quantity of the expired entitlements from the entitlement count. In some implementations, the organization may pay for a threshold quantity of entitlements for the licenses of the organization. In such implementations, the license system may compare the entitlement count to the threshold quantity to ensure that the threshold quantity is not exceeded by the entitlement count.”; Paragraph 30, “In this way, the license system provides programmable model-driven license management and enforcement in a multi-tenant system. For example, the license system may define new licenses during execution of applications in a multi-tenant system, and may consolidate entitlements (e.g., features or capabilities enabled by a license) based on licenses associated with an organization utilizing the multi-tenant system. The license system may map entitlements to capabilities of the applications, which may enable license enforcement as part of authorization through identity management. The license system may manage quotas (e.g., usage quotas, quantity quotas, and/or the like) associated with the licenses, and may utilize a machine learning model to recommend the entitlements based on the entitlement usage. Thus, the license system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed by causing downtime for a user when new licenses are introduced for an application, causing delays or downtime for a user when microservices and/or modules in the application to be updated for every license addition and/or modification, failing to adequately manage licenses for a multi-tenant system, and/or the like.”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Claim(s) 3, 10, and 17 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji further discloses the following:
generate a usage asset associated with the license, wherein attributing resource consumption to the identified seat comprises reporting the resource consumption to the usage asset. (Ennaji: Column 23 lines 4 – 28, “The UI 1100 may further include a number of entry UI controls 1104A-1104N, allowing the customer 920 to specify users who can participate in the private marketplace. According to one embodiment, the customer 920 may be able to list the specific identifier, name and organization for the users who can access the marketplace. These users may have been previously entered and stored as users associated with customer 920. The user information can be used to determine users who are authorized to bid for the resources in the private marketplace and can also be used to track usage for billing purposes. The customer 920 may also remove one or more users by deleting users using UI controls 1104A-1104N. In some embodiments, an API may be provided for facilitating the creation and management of user-defined pools. The API may be configured to receive electronic messages that encode identifiers indicative of requests for allocating computing resources in a provider network and creating a user-defined pool of the computing resources. In response to receiving one of the electronic messages, the API may send second electronic messages indicative of information indicating that a set of resource slots associated with a customer is associated with a pricing policy and one or more users designated for the user-defined pool.”; Column 24 lines 20-28, “In additional embodiments, the instance management module 9926 or other modules in the cloud computing platform 0902 may provide UIs or APIs 932 to the customer 920 and/or customer computer system 9922 that allow the customer to modify their user-defined pool, check the status of the user-defined pool and/or to delete the user-defined pool if it is no longer desired to provide the instances using the user-defined pool delivery mechanism.”)
Claim(s) 4, 11, and 18 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
wherein the license comprises a first license and a second license for the computational resources, ; (Shah: Paragraph 17, “Each of the device licenses and the organization licenses may include fields identifying a name of a device, a service, software, and/or the like to be licensed; a type of license (e.g., a base license, an add on license, and/or the like); entitlements associated with the license (e.g., identifying names, allocation sizes, allocation units, and/or the like of the entitlements); a duration of the license (e.g., in years, months, days, a start date, a termination date, and/or the like); an object type associated with the license; a quantity of objects associated with the license; and/or the like. For example, a device license for a storage device may include fields identifying a name of the storage device; a type of license (e.g., base); entitlements associated with the license (e.g., log storage of ten gigabytes, a virtual private network (VPN), a policy, a network address translation (NAT), device health statistics, and/or the like); a duration of the license (e.g., one year); an object type (e.g., a device object); a quantity of objects (e.g., ten objects); and/or the like. In another example, an organization license for cloud storage may include fields identifying a name of the cloud storage, a type of license (e.g., add on), entitlements associated with the license (e.g., log storage of one terabyte), a duration of the license (e.g., five years), an object type (e.g., an organization), and/or the like.”; Paragraph 21, “The license system may identify, in the parsed license data of the one or more licenses, the entitlements for the one or more licenses associated with the organization. The license system may map the entitlements and the capabilities associated with each of the roles to generate the entitlement-to-capability mapping. For example, the license system may identify first capabilities associated with a first user, second capabilities associated with a second user, and third capabilities associated with a third user. The license system may map one or more of the entitlements to the first capabilities to generate a first entitlement-to-capability mapping, may map one or more of the entitlements to the second capabilities to generate a second entitlement-to-capability mapping, and may map one or more of the entitlements to the third capabilities to generate a third entitlement-to-capability mapping. The first entitlement-to-capability mapping, the second entitlement-to-capability mapping, and the third entitlement-to-capability mapping may correspond to the entitlement-to-capability mapping.”)
wherein the allotment comprises a first allotment under the first license and a second allotment under the second license, (Shah: Paragraph 20, “As shown in FIG. 1C, and by reference number 120, the license system may determine an entitlement count of the combined entitlements, may add new entitlements to the entitlement count, and may subtract expired entitlements from the entitlement count. For example, the license system may add the quantity of entitlements provided in the combined entitlements to determine the entitlement count of the combined entitlements. In some implementations, if the organization receives a new license with new entitlements or receives new entitlements to an existing license, the license system may add the quantity of the new entitlements to the entitlement count to generate an updated entitlement count. In some implementations, if one or more entitlements, of the one or more licenses associated with the organization, expire, the license system may subtract the quantity of the expired entitlements from the entitlement count. In some implementations, the organization may pay for a threshold quantity of entitlements for the licenses of the organization. In such implementations, the license system may compare the entitlement count to the threshold quantity to ensure that the threshold quantity is not exceeded by the entitlement count.”; Paragraph 23, “As further shown in FIG. 1E, and by reference number 135, the license system may generate, based on the request and the entitlement-to-capability mapping, an authentication token for the user based on particular capabilities associated with a particular role of the particular user and particular entitlements associated with the particular capabilities. For example, when the license system receives the request for authentication, the license system may identify the particular role of the particular user in the request for authentication. In some implementations, the license system may determine first particular capabilities corresponding to the particular role of the particular user, based on identifying, in the license data, the roles of the users and the capabilities associated with each of the roles, as described above. The license system may also identify particular entitlements associated with the device, the service, the software, and/or the like to be accessed by the particular user. In some implementations, the license system may determine second particular capabilities corresponding to the particular entitlements based on the entitlement-to-capability mapping. The license system may combine the first particular capabilities and the second particular capabilities to generate resultant particular capabilities. The license system may generate the authentication token and may populate the authentication token with the resultant particular capabilities. If the particular user is authenticated, the license system may provide the authentication token to the user device. The user device may utilize the authentication token for requests (e.g., API calls) provided to the multi-tenant system.”)
wherein the plurality of seats comprises a first plurality of seats in the first allotment and a second plurality of seats in the second allotment, and (Shah: Paragraph 20, “As shown in FIG. 1C, and by reference number 120, the license system may determine an entitlement count of the combined entitlements, may add new entitlements to the entitlement count, and may subtract expired entitlements from the entitlement count. For example, the license system may add the quantity of entitlements provided in the combined entitlements to determine the entitlement count of the combined entitlements. In some implementations, if the organization receives a new license with new entitlements or receives new entitlements to an existing license, the license system may add the quantity of the new entitlements to the entitlement count to generate an updated entitlement count. In some implementations, if one or more entitlements, of the one or more licenses associated with the organization, expire, the license system may subtract the quantity of the expired entitlements from the entitlement count. In some implementations, the organization may pay for a threshold quantity of entitlements for the licenses of the organization. In such implementations, the license system may compare the entitlement count to the threshold quantity to ensure that the threshold quantity is not exceeded by the entitlement count.”; Paragraph 23, “As further shown in FIG. 1E, and by reference number 135, the license system may generate, based on the request and the entitlement-to-capability mapping, an authentication token for the user based on particular capabilities associated with a particular role of the particular user and particular entitlements associated with the particular capabilities. For example, when the license system receives the request for authentication, the license system may identify the particular role of the particular user in the request for authentication. In some implementations, the license system may determine first particular capabilities corresponding to the particular role of the particular user, based on identifying, in the license data, the roles of the users and the capabilities associated with each of the roles, as described above. The license system may also identify particular entitlements associated with the device, the service, the software, and/or the like to be accessed by the particular user. In some implementations, the license system may determine second particular capabilities corresponding to the particular entitlements based on the entitlement-to-capability mapping. The license system may combine the first particular capabilities and the second particular capabilities to generate resultant particular capabilities. The license system may generate the authentication token and may populate the authentication token with the resultant particular capabilities. If the particular user is authenticated, the license system may provide the authentication token to the user device. The user device may utilize the authentication token for requests (e.g., API calls) provided to the multi-tenant system.”)
wherein resource consumption is tracked separately for each allotment. (Shah: Paragraph 27, “As further shown in FIG. 1G, and by reference number 145, the license system may determine whether a license quota associated with a particular capability of the request is satisfied, and may generate a response to the request based on whether the license quota is satisfied. For example, the license system may maintain a license quota for every entitlement capability for the licenses associated with the organization. The license quota may include information identifying an entitlement capability, a unit associated with the capability (e.g., memory size, processor utilization, and/or the like), a threshold quantity of units that may be utilized, and/or a source (e.g., a resource) associated with entitlement capability. When a user attempts to utilize the multi-tenant system (e.g., a resource of the multi-tenant system), the license system may authorize the user, may determine whether the user is authorized for the utilization, may determine whether the user is associated with a licensed capability to utilize the multi-tenant system, and may determine whether the license quota is satisfied. As part of the license quota enforcement, the license system may identify the license quota associated with the particular capability of the request. If the license quota is satisfied (e.g., less than a threshold quantity of units is being utilized), the license system may generate a response to the request that allows the user device to utilize the multi-tenant system. The license system may also update usage in license quota associated with the particular capability. If the license quota is not satisfied (e.g., not more than a threshold quantity of units is being utilized), the license system may generate a response to the request that denies the user device access to the multi-tenant system. In some implementations, the license system may provide the response to the user device (e.g., via the multi-tenant system).”; Paragraph 30, “The license system may map entitlements to capabilities of the applications, which may enable license enforcement as part of authorization through identity management. The license system may manage quotas (e.g., usage quotas, quantity quotas, and/or the like) associated with the licenses, and may utilize a machine learning model to recommend the entitlements based on the entitlement usage. Thus, the license system conserves computing resources, networking resources, and/or the like that would otherwise have been consumed by causing downtime for a user when new licenses are introduced for an application, causing delays or downtime for a user when microservices and/or modules in the application to be updated for every license addition and/or modification, failing to adequately manage licenses for a multi-tenant system, and/or the like.”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Claim(s) 5, 12, and 19 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji further discloses the following:
and populate the allotment with the plurality of seats according to the identified security principle. (Ennaji: Column 7 line 43-62, "Auto scaling is one mechanism for scaling computing resources in response to increases or lulls in demand for the resources. Auto scaling allows customers of data center 210 to configure data center 210 to scale their purchased computing resources according to conditions defined by the customer. For instance, rules may be defined for scaling up capacity in a particular manner in response to the occurrence of specified conditions, such as a spike in demand. Similarly, rules might also be defined to scale down capacity in a particular manner in response to the occurrence of other conditions, such as a lull in demand. The mechanisms disclosed herein for launching virtual machine instances might be utilized when instances are manually launched by a customer or when instances are launched by an auto scaling component in data center 210."; Column 17 line 41 - Column 18 line 7, "the capacity of the resource slots allocated to a user-defined pool by a customer may be exceeded by the requests for the resource slots generated by the users. For example, a customer may underestimate the demand for resource slots and select a number of resource slots for the user-defined pool that is insufficient to meet the actual demand. In one embodiment, the provider network may provide an option for the customer to allow for such excess capacity demands to be met using unused capacity. For example, an option may be provided to fulfill the exceeded capacity using unused capacity that is already allocated to the customer but not allocated to the userdefined pool. As another example, an option may be provided to fulfill the exceeded capacity using unused capacity provided by the provider network. The provider network may charge a fee for the service. By providing such a capability, instead of rejecting user requests due to insufficient capacity, a customer may be able to continue providing access to the user-defined pool by accessing or "bursting" into additional capacity provided by the service provider or by the customer (using the customer's unused capacity) on an as-needed basis.")
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
identify a security principle associated with the allotment, the security principle including information regarding authorizations of the allotment; (Shah: Paragraph 12, “The license system may map the entitlements and the capabilities to generate an entitlement-to-capability mapping, and may authorize a particular user of the multi-tenant system based on the entitlement-to-capability mapping. The license system may process usage of the entitlements, with a machine learning model, to predict future usage of the entitlements, and may determine one or more entitlement recommendations based on the future usage. The license system may provide the one or more entitlement recommendations for display.”; Paragraph 24, “he access token may be utilized to access a resource of the multi-tenant system (e.g., the application). A resource owner may include an owner of the resource that is being accessed. A client may include an application that accesses protected resources on behalf of the resource owner. A resource server may include a server that hosts the protected resources and accepts and/or responds to requests by clients using access tokens. An authorization server may include server that issues access tokens after successfully authorizing a client and a resource owner. An authorization grant may include a credential that represents the resource owner’s authorization (to access protected resources) used by the client to obtain an access token. An access token may include a credential used to access protected resources and that represents specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and the authorization server. A scope may define permissions of an access token and may define what resources can be accessed using the access token.”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Claim(s) 6, and 13 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji further discloses the following:
modifying a seat in the allotment to increase…privilege to the seat, thereby causing the seat to gain access to additional computational resources. (Ennaji: Column 7 line 43-62, "Auto scaling is one mechanism for scaling computing resources in response to increases or lulls in demand for the resources. Auto scaling allows customers of data center 210 to configure data center 210 to scale their purchased computing resources according to conditions defined by the customer. For instance, rules may be defined for scaling up capacity in a particular manner in response to the occurrence of specified conditions, such as a spike in demand. Similarly, rules might also be defined to scale down capacity in a particular manner in response to the occurrence of other conditions, such as a lull in demand. The mechanisms disclosed herein for launching virtual machine instances might be utilized when instances are manually launched by a customer or when instances are launched by an auto scaling component in data center 210."; Column 17 line 41 - Column 18 line 7, "the capacity of the resource slots allocated to a user-defined pool by a customer may be exceeded by the requests for the resource slots generated by the users. For example, a customer may underestimate the demand for resource slots and select a number of resource slots for the user-defined pool that is insufficient to meet the actual demand. In one embodiment, the provider network may provide an option for the customer to allow for such excess capacity demands to be met using unused capacity. For example, an option may be provided to fulfill the exceeded capacity using unused capacity that is already allocated to the customer but not allocated to the userdefined pool. As another example, an option may be provided to fulfill the exceeded capacity using unused capacity provided by the provider network. The provider network may charge a fee for the service. By providing such a capability, instead of rejecting user requests due to insufficient capacity, a customer may be able to continue providing access to the user-defined pool by accessing or "bursting" into additional capacity provided by the service provider or by the customer (using the customer's unused capacity) on an as-needed basis.")
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
…security [privilege]… (Shah: Paragraph 12, “The license system may map the entitlements and the capabilities to generate an entitlement-to-capability mapping, and may authorize a particular user of the multi-tenant system based on the entitlement-to-capability mapping. The license system may process usage of the entitlements, with a machine learning model, to predict future usage of the entitlements, and may determine one or more entitlement recommendations based on the future usage. The license system may provide the one or more entitlement recommendations for display.”; Paragraph 24, “he access token may be utilized to access a resource of the multi-tenant system (e.g., the application). A resource owner may include an owner of the resource that is being accessed. A client may include an application that accesses protected resources on behalf of the resource owner. A resource server may include a server that hosts the protected resources and accepts and/or responds to requests by clients using access tokens. An authorization server may include server that issues access tokens after successfully authorizing a client and a resource owner. An authorization grant may include a credential that represents the resource owner’s authorization (to access protected resources) used by the client to obtain an access token. An access token may include a credential used to access protected resources and that represents specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and the authorization server. A scope may define permissions of an access token and may define what resources can be accessed using the access token.”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Claim(s) 7, 14, and 20 –
Ennaji in view of Shah disclose the limitations of claims 1, 8, and 15
Ennaji further discloses the following:
subtract the attributed resource consumption from an allocation of resource availability; (Ennaji: Column 14 line 32-52, "The customer may select a subset of the customer's reserved and on-demand instances and create an internal marketplace in which departments and/or users within the educational institution may bid internally for the reserved instances and on-demand instances. The bidding process may be similar to the process for bidding for a spot instance in a spot market as described above. In some embodiments, the customer may select other bidding processes or allow for bidding using other forms of payment such as with allotted credits. In various embodiments, aspects may be customizable-such as the currency, the minimum/maximum prices or price levels, the bidding/pricing algorithm, interruption cycles and other parameters."; Column 17 line 41-Column 18 line 7, "Such a capability may be useful when peak demand occurs only on an occasional basis, in which case it may be more cost effective for the customer to purchase burst capacity rather than dedicate additional resource slots to the user-defined pool. In some embodiments, the decision as to whether excess capacity will be bursted from the provider network or from the customer's nonallocated capacity can be based on a policy selected by the customer. For example, the customer may specify a maximum price that the customer is willing to pay for excess capacity. The customer may also specify a maximum budget within which burst requests can be fulfilled until the maximum budget is reached."; Column 24 line 1-19, "The user-defined pool record 1200 may further contain information regarding one or more usage records 1220A-1220N (also referred to herein generally as "usage 1220") and billing records 1222A-1222N (also referred to herein generally as "billing 1222"). As further discussed above in regard to FIG. 10, a user may access an instance after successfully bidding for the instance in the private marketplace. Billing records 1222A-1222N for usage 1220A-1202N may be tracked for the user for billing purposes. It will be appreciated that the user-defined pool record 1200 may contain additional data elements beyond those shown in FIG. 12 and described above that are utilized by the instance management module 926, the instance listings module 936 and/or other modules of the cloud computing platform 902 implementing the private marketplace.)
Ennaji does not explicitly disclose the following, however, in analogous art of computational resource management, however, Shah discloses the limitations below:
compare the attributed resource consumption with the allocation of resource availability; and (Shah: Paragraph 20, “As shown in FIG. 1C, and by reference number 120, the license system may determine an entitlement count of the combined entitlements, may add new entitlements to the entitlement count, and may subtract expired entitlements from the entitlement count. For example, the license system may add the quantity of entitlements provided in the combined entitlements to determine the entitlement count of the combined entitlements. In some implementations, if the organization receives a new license with new entitlements or receives new entitlements to an existing license, the license system may add the quantity of the new entitlements to the entitlement count to generate an updated entitlement count. In some implementations, if one or more entitlements, of the one or more licenses associated with the organization, expire, the license system may subtract the quantity of the expired entitlements from the entitlement count. In some implementations, the organization may pay for a threshold quantity of entitlements for the licenses of the organization. In such implementations, the license system may compare the entitlement count to the threshold quantity to ensure that the threshold quantity is not exceeded by the entitlement count.”)
based on the attributed resource consumption exceeding the allocation, cause restrictions on the accessing device for the computational resources or cause additional charges to the account. (Shah: Paragraph 27, “As further shown in FIG. 1G, and by reference number 145, the license system may determine whether a license quota associated with a particular capability of the request is satisfied, and may generate a response to the request based on whether the license quota is satisfied. For example, the license system may maintain a license quota for every entitlement capability for the licenses associated with the organization. The license quota may include information identifying an entitlement capability, a unit associated with the capability (e.g., memory size, processor utilization, and/or the like), a threshold quantity of units that may be utilized, and/or a source (e.g., a resource) associated with entitlement capability. When a user attempts to utilize the multi-tenant system (e.g., a resource of the multi-tenant system), the license system may authorize the user, may determine whether the user is authorized for the utilization, may determine whether the user is associated with a licensed capability to utilize the multi-tenant system, and may determine whether the license quota is satisfied. As part of the license quota enforcement, the license system may identify the license quota associated with the particular capability of the request. If the license quota is satisfied (e.g., less than a threshold quantity of units is being utilized), the license system may generate a response to the request that allows the user device to utilize the multi-tenant system. The license system may also update usage in license quota associated with the particular capability. If the license quota is not satisfied (e.g., not more than a threshold quantity of units is being utilized), the license system may generate a response to the request that denies the user device access to the multi-tenant system. In some implementations, the license system may provide the response to the user device (e.g., via the multi-tenant system).”)
Ennaji discloses a method for creating allotments of computational resources and tracking and dividing those allotments to be filled with seats. Shah discloses a method for managing a license resources which includes tracking entitlements which identifies devices and privileges associated with resource seats. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Ennaji with the teachings of Shah in order to improve compliance with resource license agreements as disclosed by Shah (Shah: Paragraph 2, “Product license management is a mechanism tool that helps businesses document and manage product licenses to ensure compliance with usage terms and conditions.”)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Raleigh (US 2022/0360608 A1) discloses a method for network service plan design
Dillons (US 2022/0337445 A1) discloses a method for secure access for vcores
Manevich (US 2022/0286299 A1) discloses a method for dynamic media key block and broadcast encryption
Kempf (US 2021/0081404 A1) discloses a method for managing cloud services using smart contracts
Chowdhury (WO 2020/037208 A1) discloses a method for rule-based resource management
Nirwal (US 2018/0145955 A1) discloses a method for managing credentials in hyper-converged infrastructures
Lingafelt (US 2013/0262250 A1) discloses a method for allocation of application licenses within cloud or infrastructure
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Philip N Warner whose telephone number is (571)270-7407. The examiner can normally be reached Monday-Friday 7am-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, Jerry O’Connor can be reached at 571-272-6787. 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.
/Philip N Warner/Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624
Prosecution Insights