DETAILED ACTION
This Office Action is in response to claims filed on 04/07/2026
Claims 1-17 and 20-22 are pending.
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 .
Response to Arguments
Applicant's arguments filed 04/07/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
The Office relies on Sun to teach or suggest “assessing said open-source container environment for duplicative services” as required by the pending claims. Office Action, page 3. Applicant respectfully submits that the rejections are in error for this reason.
With respect to point (a), Examiner respectfully disagrees. Applicant argues in substance that the Sun reference does not reasonably teach or suggest the limitation of “assessing said open-source container environment for duplicative services” (Remarks, Pg. 9). Specifically, the Applicant contest that Sun does not reasonably teach or suggest the limitation of the “open-source container environment” as Sun teaches a materially different concept of a “shared computer environment” wherein such mapping would improperly broaden the claim language beyond the specification-defined meaning of a “clustered container orchestration system” (Remarks, Pg. 9). However, Examiner sets forth that “assessing said open-source container environment for duplicative services”, as reasonably interpreted in view of Applicant’s specification, is taught by the “shared computer environment” of Sun, thus satisfying the limitation of claim 1.
In light of MPEP 2173.01(I), the Examiner has taken the broadest reasonable interpretation of the claim in light of specification as would be interpreted by one of ordinary skill in the art. Applicant sets forth that the specification defines an “open-source container environment” as a “container orchestration platform that manages containers, services, and workloads a cluster control plane” (Remarks, Pg. 8-9) and supplies paragraphs and figures from the instant specification to support this assertion. However, upon inspection of the specification, the Examiner has not identified or recognized a special definition -or other limiting disclosure(s) for the limitation of “open-source container environment”. Accordingly, the Examiner must rely upon the broadest reasonable interpretation of the claim. Thus, under broadest reasonable interpretation, the ”open-source container environment” is a computing environment, implemented using a container technology, in which a pool of computing resources and servers are provisioned among multiple tenants or users.
As such, Sun supports the interpretation. Particularly, Sun recites tenancy in cloud computing environment such that “a new cloud environment set up for a new user” (Sun, [0029]) and resource access configurations directed to “private”, “sharable”, “semi-public”, and “public” such that provides computing environments scope (Sun, [0030]-[0034]). Further, Sun recites the implementation of the system on a cloud computing environment (Sun, [0082]-[0099]). Thus, Sun reasonably discloses a cloud system provision resources to user tenants associated with private computing environments such that a managing system may consolidate identical resource (Sun, [0039]) which is commensurate with the scope of the limitation.
Accordingly, when the claim is given its broadest reasonable interpretation, the reference of Sun reasonably teaches the limitation of the claims. Applicant’s arguments directed to the claim interpretation “open-source container environment” is unpersuasive. The rejection of the independent claims is maintained.
Argument has not been found to be persuasive.
The Office relies on Rosinosky to teach or suggest “introducing a migration controller to an open-source container environment” as required by the pending claims. Office Action, page 5. Applicant respectfully submits that the rejections are in error at least for this reason
With respect to point (b), Examiner respectfully disagrees. Applicant argues in substance that the Rosinosky reference does not reasonably teach the limitation of “introducing a migration controller to an open-source container environment” (Remarks, Pg. 9). Specifically, Applicant argues that the specification describes the migration controller as “a control-plane entity continuously managing service state within a container cluster” (Remarks, Pg. 10). However, Examiner sets forth that “introducing a migration controller to an open-source container environment”, as reasonably interpreted in view of Applicant’s specification, is taught by the references of Sun in view of Rosinosky, thus satisfying the limitation of claim 1.
Sun reasonably teaches a system that performs the operations of duplicative services assessment, and shared service selection. Further, Sun recites, at a high level, a “managing computer system” configured to perform the operations of identifying, matching, and sharing computer environment resources. However, Sun does not explicitly teach an introduction of a “migration controller to an open-source container environment” or “redirection, via said migration controller, resource requests to said shared service based on service combination rules.” Thus, the Examiner relies upon Rosinosky to supplement the deficiencies of Sun.
As currently presented, the independent claims explicitly recite “introducing a migration controller to an open-source environment” and “redirecting, via said migration controller resource requested to said shared service based on service combination rules”. Thus, Applicant’s arguments directed to Rosinosky failing to teach operations of “watching, reconciling, or continuously evaluating system state as a controller would” (Remarks, Pg. 9) and “not redirect[ing] service requests dynamically” (Remarks, Pg. 10) is an improper importation of claim limitations from the specification (see MPEP 2111.01(II)). As currently presented, the broadest reasonable interpretation of “migration controller” in light of the specification include a computer component configured to facilitate the migration of requests from one service to another.
Accordingly, when the claim is given its broadest reasonable interpretation, the combination of Sun and Rosinosky reasonably reach “introducing a migration controller to an open-source container environment” and “redirecting resource request through migration controller to the shared service”. Applicant’s arguments directed to features not explicitly recited within the claim and independent consideration of the Rosinosky reference are unpersuasive. The rejection of the independent claims is maintained.
Argument has not been found to be persuasive.
The Office relies on Kahrs to teach or suggest “duplicated services share a custom resource definition with another service” as required by the pending claims. Office Action, page 3. Applicant respectfully submits that the rejections are in error for at least this reason.
With respect to point (c), Examiner respectfully disagrees. Applicant argues in substance that the Kahrs reference does not reasonably teach or suggest the limitation of “duplicated services share a custom resource definition with another service” (Remarks, Pg. 11). Specifically, Applicant argues that the resource group definitions of Kahrs fails to teach the “type schema … a structural definition comparable to a CRD that defines a service type” (Remarks, Pg. 12). Further, Applicant sets forth that the resource groups definitions are merely “an overlay for management and organization” in contrast with “a mechanism that defines the intrinsic structure or type of the underlying resources” (Remarks, Pg. 12). However, Examiner sets forth that “duplicated services share a custom resource definition with another service”, as reasonably interpreted in view of Applicant’s specification, is taught by the references of Sun in view of Rosinosky in view of Kahrs, thus satisfying the limitation of claim 1.
As currently presented, the independent claims explicitly recite “duplicated services share a custom resource definition with another service.” Applicant argues that, in view of paragraphs [0031] and [0053] of the instant specification, “a CRD defines the type and schema of a service in the container environment” such that the “resource group definition” of Kahr fails to teach. However, Examiner respectfully disagrees. In view of the specification, the broadest reasonable interpretation of “custom resource definition” includes a form of identifier associated with a particular service by which services can be matched, such that the identifier is defined in a cluster or resource grouping.
Given the broadest reasonable interpretation, the combination of Sun, Rosinosky, and Kahrs reasonably teach “duplicated services share a custom resource definition with another service”. Kahrs reasonably teaches that “computing resources 108 in a resource group may be provided by different network service 106” (Kahrs, Col. 12), thus teaches separate duplicative services sharing identical resource grouping identifier. Further, Kahrs teaches “resource 108 matching the resource tags 116 specified in the resource group definition 116 (or an expression) at the time the resource group definition 404 is evaluated are considered to be a part of the resource group” (Kahrs, Col. 11) and “the resource group definition 404 is evaluated in the manner described above in order to identify the specific resources 108 that are in the resource group represented by the resource group definition 404” (Kahrs, Col. 17). That is, the resource tags associated with the resource group definition maybe used to match a selected resource to other resource incorporated within such resource group. Moreover, Kahrs reasonably teaches the association of resource group definitions with particular resource types, wherein “if the resource group definition 404 specifies resource types or regions, then only resources 108 of the specified type(s) … will be considered to be members of the resource group” (Khars, Col. 12).
Accordingly, when the claim is given its broadest reasonable interpretation, the combination of Sun, Rosinosky, and Kahrs reasonably teach “duplicated services share a custom resource definition with another service”. Applicant’s arguments directed to the claim interpretation of “a resource type and schema of a service” of the limitation of “custom resource definition” is unpersuasive. The rejection of the independent claims is maintained.
Argument has not been found to be persuasive.
The Office Action asserts that it would have bee obvious to modify Sun to include a migration controller. However, Sun already provides its now user-driven sharing mechanism, does not operate in a cluster control plane, does not identify duplication by CRD type and does not contemplate controller-mediated consolidation. See Sun, generally. The Office is silent with respect to why a person of ordinary skill would discard Sun’s existing sharing model and retrofit it with an open-source container-style operator that watches cluster resources and reconciles service state; this would fundamentally alter Sun’s architecture and purpose reflecting hindsight reconstruction based on Applicant’s disclosure.
…
Even if Sun and Rosinosky are considered together, the combination fails because Sun concerns application-level sharing, Rosinosky concerns database-level tenant data migration, neither reference describes a container control plane, and neither suggests margining data-migration SQL with live service-request redirection. See Sun, generally; see Rosinosky, generally. The Office Action does not explain why SQL scripts for tenant data movement would be recharacterized as a cluster-level service migration controller, nor how much scripts would dynamically redirect service traffic among running containers. See Office Action, generally.
With regard to point (d), Examiner respectfully disagrees. Applicant argues in substance that the motivation applied by the Examiner is hindsight reconstruction and that the combination of Sun “does not operate in a cluster control plane, identify duplication by CRD type, and does not contemplate controller-mediated consolidation”.
However, Sun reasonably teaches a shared computer environment and the performance of identifying matching resources owned by independent users, sharing matched resources, and deleting redundant resources. Rosinosky reasonably teaches migration of a tenant to a consolidated instance such that requires request redirection. Thus, Sun and Rosinosky are analogous art pertinent to the problem of efficient resource consolidation. That is, a person of ordinary skill would be motivated to apply the Rosinosky’s tenant migration solution to Sun’s resource consolidation system, as motivated by Rosinosky to “effectively enable the provider to scale up the number of requests that can be supported after migration and can, reversely, be used for tenant consolidation and resource savings” (Rosinosky, Pg. 4) as expressed in the prior Office Action.
Applicant imports the broader context and features of Sun and Rosinosky to suggest that each reference in relation to the claimed invention are unrelated or reconstructed from hindsight. However, Examiner respectfully submits that the rejection does not rely on Sun’s or Rosinosky’s overall objective. Rather, the Examiner refers strictly to the specific features disclosed in each reference respectively that is relevant to the claimed invention.
The Examiner respectfully maintains that express motivation of the Office Action is both rational and relevant to the claimed invention. The expressed motivation rationale would be obvious to one of ordinary skill in the art recognizing the benefit of migration to achieve tenant consolidation and resource savings. For the reasons set forth above and herein, Examiner respectfully maintains the rejection of Sun in view of Rosinosky.
Argument has not been found to be persuasive.
Finally, even assuming Sun and Rosinosky could somehow be combined, there is not motivation to further import Kahrs because the tags of Kahrs are metadata for grouping whereas the CRDs of the pending claims define service identity and duplication; these functions are not interchangeable. The Office Action fails to articulate why one would combine a tag-based cloud inventory system with an already strained Sun-Rosinosky combination to arrive at a CRD-based operator architecture. This triple-reference combination is a classic example of ex post facto assembly rather than a predictable motivated, design path.
With regard to point (e), Examiner respectfully disagrees. Similar to the argument above, Applicant argues in substance that the motivation applied by the Examiner is hindsight reconstruction and that the combination of Sun and Rosinosky in view of Kahrs fails to teach a motivation for applying “a tag-based cloud system” with Sun in view of Rosinosky to arrive at a “CRD-based operator architecture”.
However, as recited above, Sun reasonably teaches a shared computer environment and the performance of identifying matching resources owned by independent users, sharing matched resources, and deleting redundant resources. Kahrs reasonably teaches an association of resources with a shared resource group definition by which the resources may be identified by. -- Thus, Sun and Rosinosky in view of Kahrs are analogous art pertinent to the problem of efficient resource consolidation. That is, a person of ordinary skill would be motivated to apply the Kahrs’ resource grouping definition mechanism to Sun’s resource identification consolidation system, as motivated by Kahrs’ to “categorize resources on a service provider network that enables collection, filtering, and organization of the available and provisioned resources, searching for and view information about resources with matching tags, and managing resources with matching tags” (Kahrs, Col. 6) as expressed in the prior Office Action.
The Examiner respectfully maintains that expressed motivation of the Office Action is both rational and relevant to the claimed invention. The expressed motivation rationale would be obvious to one of ordinary skill in the art recognizing the benefit of resource grouping to resource organization in association with resource identification. For the reasons set forth above and herein, Examiner respectfully maintains the rejection of Sun in view of Rosinosky in view of Kahrs.
Argument has not been found to be persuasive.
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, 2, 6-9, 13-16, and 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. US 2022/0405144 A1 (hereinafter Sun) in view of Rosinosky et al. "A Methodology for Tenant Migration in Legacy Shared-Table Multi-tenant Applications" (hereinafter Rosinosky) in view of Kahrs et al. Patent No. US 9,934,269 (hereinafter Kahrs).
With regard to claim 1, Sun teaches a system, said system comprising ([0004], Some embodiments of the present disclosure can also be illustrated as a system):
a memory (Fig. 6, 620 Memory; [0106], FIG. 6 depicts the representative major components of an example Computer System 601 that may be used in accordance with embodiments of the present disclosure … The Computer System 601 may include a … Memory 620; [108], The Memory 620 of the Computer System 601 may include a Memory Controller 622); and
a processor (Fig. 6, 610 Processor; [0106], The Computer System 601 may include a Processor 610) in communication with said memory ([0108], The Memory Controller 622 may communicate with the Processor 610), said processor being configured to perform operations, said operations comprising ([0004], When the program instructions are executed by the processor, they are configured to cause the processor to perform the above-described method):
…
assessing an open-source container environment ([0003], Some embodiments of the present disclosure can be illustrated as a method comprising identifying a sharable resource of a first user’s user environment that is configured as sharable in a shared computer environment; [0038], If, on the other hand, the managing computer systems determines, in block 104, that resource can be configured as shareable, the managing computer system proceeds block 108 in which it determines if a matching resource exists with the identified resource could be shared) for duplicative services ([0039], For example, if the resource identified in block 102 is a streaming operator (service), block 108 may include attempting to locate another streaming operator that performs the same functions on the same type of tuples as the identified resource (duplicative services), such that they could be used interchangeably; [0040], In some embodiments, identifying a sufficiently similar resource may require locating a resource that is, for the purposes of the shared computing environment, identical to the identified resource (assessment of the environment for duplicative services). In other words, block 108 may require locating a resource that functions identically to the identified resource (for example, a streaming operator with the same exact input tuple type, operation, and output tuple type) (Examiner notes: “resource” and “streaming operator” interpreted as interchangeable with the term “service”));
…
selecting a shared service ([0029], Method 100 begins in block 102, in which a new or private resource of the shared computer environment is identified … In that case, block 102 may be performed when the user is configuring that new streaming operator (shared service); [0031], Upon identifying a resource in block 102, method 100 proceeds to block 104 in which the computer system determines whether the new or private resource can now be configured sharable (shared service is selected for sharing)) and a duplicate service from said duplicative services ([0046], If, however, a matching resource is discovered in block 108, the managing computer system can determine, in block 112, that the users of the matching resource agree to merge the identified resource with the matching resource; [0048], Once the agreement is confirmed, the managing computer gives, in block 114, the user of the identified resource access to the matching resource. The nature of this access may depend upon the nature of the shared and the properties of the matching resource);
…; and
terminating said duplicated service ([0049], Upon giving a user of the identified resource access to the shared matching resource, the managing computer system deletes any redundant resources that are no longer needed. For example, if the identified resource discovered at block 102 were a pre-existing private resource that a user requested to be reconfigured into a public resource, block 116 may include deleting the identified resource).
However, Sun does not explicitly teach introducing a migration controller to an open-source container environment and redirecting, via said migration controller, resource requests to said shared service based on service combination rules.
Rosinosky teaches introducing a migration controller to an open-source container environment (Pg. 3, We present a novel solution for scaling in or out such applications through the migration of a tenant’s data to new application and database instances. Our solution requires no change to the application and incurs no service downtime for non-migrated tenants. It leverages external tables and foreign data wrappers, as supported by major relational databases; The use of our proposed evolution of the application schema enables migrations using a series of SQL statements (i.e., in concordance with our objective of non-intrusion, we do not require the specific features from the database system itself). Table data stored in the tenant database and specific to the migrated tenant should be inserted in the corresponding table at the destination (which can be, in the case of a horizontal scale-out operation, a freshly-started database instance, or an existing instance in the case of a consolidation).);
…
redirecting, via said migration controller, resource requests to said shared service based on service combination rules (Pg. 9, The migration process requires the following steps to migrate tenant t from one stack a featuring database D.sub.a and application A.sub.a to stack b formed of database D.sub.b and application A.sub.b (Examiner notes: such that the database services can be combined): 1. Stop the tenant on application A.sub.a and disconnect users; 2. Disable foreign key checks for the database connection; 3. for each table in the tenant database, instantiate a temporary foreign table using a table data wrapper in database D.sub.a, targeting the corresponding table in database D.sub.b; then, in database D.sub.a. insert data corresponding to tenant t in the foreign tables, thereby inserting it in database D.sub.b; 4. enable foreign key checks for the database connection; 5. If there were no errors, delete temporary foreign tables used for the transfer from database D.sub.a and tenant t data from this database; 6. re-activate the tenant on application A.sub.b. Queries from users of tenant t should now target application A.sub.b).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rosinosky with the teachings of Sun in order to provide a system that teaches service request rerouting following tenant consolidation in accordance to multi-tenancy policies. The motivation for applying Rosinosky teaching with Sun teaching is to provide a system that enables service consolidation without requiring changes to underlying applications, seamlessly integrates common shared services without interruption, and allows for providers to effectively scale services to achieve resource savings (Rosinosky, Pg. 4). Sun and Rosinosky are analogous art directed towards resource allocation and request servicing. Therefore, it would have been obvious for one of ordinary skill in the art to combine Rosinosky with Sun to teach the claimed invention in order to provide shared service consolidation and routing.
Sun reasonably teaches identification of matching duplicate resources through analyzing shareable metadata tags (Sun, [0042]). However, Sun and Rosinosky do not explicitly teach that duplicative services share a custom resource definition with another service.
Kahrs teaches duplicative services share a custom resource definition with another service (Col. 12, lines 19-29, As also shown in FIG. 4, the resource groups service 402 might expose an API 410 for performing various types of functionality. For example, and without limitation, the API 410 might include methods for creating, editing, or deleting resource group definitions 404 (Examiner notes: Such that custom resource definitions can be engineered). The API 410 might also include a method for exporting resource group definitions 404. In this way, the resource group definitions 404 can be shared with other users of the service provider network 102 via a marketplace and/or in another manner. Other mechanisms might also be utilized to enable sharing of resource group definitions 404; Col. 12, lines 30-36, The API 410 might also include a method for evaluating a resource group definition 404. When a request is received to evaluate a resource group definition, the resource groups service 402 is configured to identify those resources 108 in the service provider network 102 that have associated resource tags that match the resource tags 116 in the resource group definition 404)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kahrs with the teachings of Sun and Rosinosky in order to provide a system that teaches customizable resource definitions supplying attribute information for detecting duplicative services under such resource definition. The motivation for applying Kahrs teaching with Sun and Rosinosky teaching is to provide a system that allows for a mechanism for categorizing resources on a service provider network such that enables collection, filtering, and organization of the available and provisioned resources, searching for and viewing information about resources with matching tags, and managing resources with matching tags (Kahrs, Col. 6). Sun, Rosinosky, Kahrs are analogous art directed towards request servicing and resource partitioning and consolidating. Therefore, it would have been obvious to a person of ordinary skill in the art to combine Kahrs with Sun and Rosinosky to teach the claimed invention in order to provide an efficient way of organizing and managing resources sharing identical resource definitions.
With regard to claim 2, Sun does not explicitly teach the claim.
Rosinosky teaches the system of claim 1, said operations further comprising:
scaling said shared service to support said resource requests (Pg. 4, We present a non-intrusive and efficient methodology for stop-and-copy tenant migration in legacy multi-tenant application using the shared-table approach. Our method enables such legacy applications to scale in and out based on tenants’ requirements (e.g., the volume of requests or data).).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Rosinosky with the teachings of Sun and Kahrs in order to provide a system that teaches shared service scaling to support resource demand. The motivation for applying Rosinosky teaching with Sun and Kahrs teaching is to provide a system that enables consolidation of services into a shared service while maintaining sufficient resource availability to preserve service performance and reduce duplicated consumption of computing resources (Rosinosky, Pg. 5). Sun, Kahrs, and Rosinosky are analogous art directed towards resource allocation and request servicing. Therefore, it would have been obvious for one of ordinary skill in the art to combine Rosinosky with Sun and Kahrs to teach the claimed invention in order to provide scaling operations for cloud services.
With regard to claim 6, Sun teaches the system of claim 1, said operations further comprising:
enabling an end-user rule input ([0025], Some embodiments of the present disclosure may also require a user to select sharing preferences when creating or modifying computing resources (e.g., adding more graphics hardware processors to the user’s processing array or adding more streaming operators to a stream computing environment). The stream computing system can then compare the sharing requirements of the new or modified resource with existing resources to determine whether updated sharing is possible).
With regard to claim 7, Sun teaches the system of claim 1, said operations further comprising:
establishing a service combination ruleset for said duplicative services ([0041], As discussed, if a managing computer system determines, block 104, that the identified resource can be configured as semi-public, the identified resource may have additional sharing requirements that must be met before the identified resource can be shared. In these instances, block 108 may also include locating resources that are not only sufficiently similar to the identified resource, but also that meet these sharing requirements. For example, block 108 may include only searching for resources that are rented by users on a list of users provided in block 104. Similarly, block 108 may include searching for resources that are only available to users of a particular group (e.g., employees of a company, members of a particular university, or members of joint venture group). Block 108 may also include searching for resource that meet particular security requirements, such as streaming operators that require input tuples be encrypted and that encrypt output tuples after processing).
With regard to claim 8, Sun teaches a computer-implemented method, said method comprising ([0028], As an illustrative example, FIG. 1 depicts a method 100 of merging a private resource in a shared computing environment into a shared resource):
…;
assessing an open-source container environment ([0003], Some embodiments of the present disclosure can be illustrated as a method comprising identifying a sharable resource of a first user’s user environment that is configured as sharable in a shared computer environment; [0038], If, on the other hand, the managing computer systems determines, in block 104, that resource can be configured as shareable, the managing computer system proceeds block 108 in which it determines if a matching resource exists with the identified resource could be shared) for duplicative services ([0039], For example, if the resource identified in block 102 is a streaming operator (service), block 108 may include attempting to locate another streaming operator that performs the same functions on the same type of tuples as the identified resource (duplicative services), such that they could be used interchangeably; [0040], In some embodiments, identifying a sufficiently similar resource may require locating a resource that is, for the purposes of the shared computing environment, identical to the identified resource (assessment of the environment for duplicative services). In other words, block 108 may require locating a resource that functions identically to the identified resource (for example, a streaming operator with the same exact input tuple type, operation, and output tuple type) (Examiner notes: “resource” and “streaming operator” interpreted as interchangeable with the term “service”));
…;
selecting a shared service ([0029], Method 100 begins in block 102, in which a new or private resource of the shared computer environment is identified … In that case, block 102 may be performed when the user is configuring that new streaming operator (shared service); [0031], Upon identifying a resource in block 102, method 100 proceeds to block 104 in which the computer system determines whether the new or private resource can now be configured sharable (shared service is selected for sharing)) and a duplicate service from said duplicative services ([0046], If, however, a matching resource is discovered in block 108, the managing computer system can determine, in block 112, that the users of the matching resource agree to merge the identified resource with the matching resource; [0048], Once the agreement is confirmed, the managing computer gives, in block 114, the user of the identified resource access to the matching resource. The nature of this access may depend upon the nature of the shared and the properties of the matching resource);
…; and
terminating said duplicated service ([0049], Upon giving a user of the identified resource access to the shared matching resource, the managing computer system deletes any redundant resources that are no longer needed. For example, if the identified resource discovered at block 102 were a pre-existing private resource that a user requested to be reconfigured into a public resource, block 116 may include deleting the identified resource).
However, Sun does not explicitly teach introducing a migration controller to an open-source container environment and redirecting, via said migration controller, resource requests to said shared service based on service combination rules.
Rosinosky teaches introducing a migration controller to an open-source container environment (Pg. 3, Software-as-a-service (SaaS) is the cloud service model with the highest market size. It allows client organizations, or tenants, to benefit from turn-key applications. Multi-tenancy is the sharing application instances across multiple tenants. It enables SaaS providers to benefit from economies of scale, consolidating service load for different tenants, and reducing total cost of ownership. Multi-tenancy can be implemented by sharing computing resources (virtual machines (VM) or containers), by sharing application servers, storing data for multiple tenants in the same database or using a combination of these approaches; The use of our proposed evolution of the application schema enables migrations using a series of SQL statements (i.e., in concordance with our objective of non-intrusion, we do not require the specific features from the database system itself). Table data stored in the tenant database and specific to the migrated tenant should be inserted in the corresponding table at the destination (which can be, in the case of a horizontal scale-out operation, a freshly-started database instance, or an existing instance in the case of a consolidation).);
…
redirecting, via said migration controller, resource requests to said shared service based on service combination rules (Pg. 9, The migration process requires the following steps to migrate tenant t from one stack a featuring database D.sub.a and application A.sub.a to stack b formed of database D.sub.b and application A.sub.b: 1. Stop the tenant on application A.sub.a and disconnect users; 2. Disable foreign key checks for the database connection; 3. for each table in the tenant database, instantiate a temporary foreign table using a table data wrapper in database D.sub.a, targeting the corresponding table in database D.sub.b; then, in database D.sub.a. insert data corresponding to tenant t in the foreign tables, thereby inserting it in database D.sub.b; 4. enable foreign key checks for the database connection; 5. If there were no errors, delete temporary foreign tables used for the transfer from database D.sub.a and tenant t data from this database; 6. re-activate the tenant on application A.sub.b. Queries from users of tenant t should now target application A.sub.b).
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 8 is being recited again as a computer-implemented method for the system of claim 1.
Sun reasonably teaches identification of matching duplicate resources through analyzing shareable metadata tags (Sun, [0042]). However, Sun and Rosinosky do not explicitly teach that duplicative services share a custom resource definition with another service.
Kahrs teaches duplicative services share a custom resource definition with another service (Col. 12, lines 19-29, As also shown in FIG. 4, the resource groups service 402 might expose an API 410 for performing various types of functionality. For example, and without limitation, the API 410 might include methods for creating, editing, or deleting resource group definitions 404 (Examiner notes: Such that custom resource definitions can be engineered). The API 410 might also include a method for exporting resource group definitions 404. In this way, the resource group definitions 404 can be shared with other users of the service provider network 102 via a marketplace and/or in another manner. Other mechanisms might also be utilized to enable sharing of resource group definitions 404; Col. 12, lines 30-36, The API 410 might also include a method for evaluating a resource group definition 404. When a request is received to evaluate a resource group definition, the resource groups service 402 is configured to identify those resources 108 in the service provider network 102 that have associated resource tags that match the resource tags 116 in the resource group definition 404) is substantially similar to claim 1, and therefore is rejected with similar rationale.
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 8 is being recited again as a computer-implemented method for the system of claim 1.
With regard to claim 9, Rosinosky teaches the computer-implemented method of claim 8, further comprising:
scaling said shared service to support said resource requests (Pg. 4, We present a non-intrusive and efficient methodology for stop-and-copy tenant migration in legacy multi-tenant application using the shared-table approach. Our method enables such legacy applications to scale in and out based on tenants’ requirements (e.g., the volume of requests or data).).
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 9 is being recited again as a computer-implemented method for the system of claim 2.
With regard to claim 13, Sun teaches the computer-implemented method of claim 8, further comprising:
enabling an end-user rule input ([0025], Some embodiments of the present disclosure may also require a user to select sharing preferences when creating or modifying computing resources (e.g., adding more graphics hardware processors to the user’s processing array or adding more streaming operators to a stream computing environment). The stream computing system can then compare the sharing requirements of the new or modified resource with existing resources to determine whether updated sharing is possible).
With regard to claim 14, Sun teaches the computer-implemented method of claim 8, further comprising:
establishing a service combination ruleset for said duplicative services ([0041], As discussed, if a managing computer system determines, block 104, that the identified resource can be configured as semi-public, the identified resource may have additional sharing requirements that must be met before the identified resource can be shared. In these instances, block 108 may also include locating resources that are not only sufficiently similar to the identified resource, but also that meet these sharing requirements. For example, block 108 may include only searching for resources that are rented by users on a list of users provided in block 104. Similarly, block 108 may include searching for resources that are only available to users of a particular group (e.g., employees of a company, members of a particular university, or members of joint venture group). Block 108 may also include searching for resource that meet particular security requirements, such as streaming operators that require input tuples be encrypted and that encrypt output tuples after processing).
With regard to claim 21, Sun teaches the computer-implemented method of claim 8, wherein said redirecting resource requests reduces a resource pull from said duplicative services ([0016], In some instances, these three users may pay for private use of their entire streaming application, including all operators therein. However, in some instances, some operators of each of the three private streaming applications may perform the same operations on the same type of data. In these instances, the streaming operators could theoretically be shared between three users. This would enable the owner of the streaming application environment to maintain only a single operator, rather than three (Examiner notes: where only one of the three operators are maintained, eliminating utilization from the identical operators). This could result in cost savings that can enable compensating the three users for sharing the operators).
With regard to claim 22, Sun teaches the computer-implemented method of claim 8, wherein said redirecting resource requests is in accordance with a service combination ruleset ([0048], Once the agreement is confirmed, the managing computer gives, in block 114, the user of the identified resource access to the matching resource. The nature of this access may depend upon the nature of the shared and the properties of the matching resource. For example, in a streaming application, providing a user access to a shared streaming operator may include directing the upstreaming operators of the user’s streaming application to output tuples to the shared streaming operator, and directing streaming application to accept tuples from the shared streaming operator. If on the other hand, the shared resource is a storage resource in a cloud computing environment, an address table of the cloud processor nodes used by the user’s computing environment may be updated to contain entries to the storage resource).
With regard to claim 15, With regard to claim 15, Sun teaches a computer program product, said computer program product comprising a computer readable storage medium having program instructions embodied therewith ([0005], Some embodiments of the present disclosure can also be illustrated as a computer program product. The computer program product comprises a computer-readable storage medium. The computer readable has program instructions embedded therewith), said program instructions executable by a processor to cause said processor to perform a function, said function comprising ([0004], The program instructions are executable by a computer to cause the computer to perform the above-described method):
…;
assessing an open-source container environment ([0003], Some embodiments of the present disclosure can be illustrated as a method comprising identifying a sharable resource of a first user’s user environment that is configured as sharable in a shared computer environment; [0038], If, on the other hand, the managing computer systems determines, in block 104, that resource can be configured as shareable, the managing computer system proceeds block 108 in which it determines if a matching resource exists with the identified resource could be shared) for duplicative services ([0039], For example, if the resource identified in block 102 is a streaming operator (service), block 108 may include attempting to locate another streaming operator that performs the same functions on the same type of tuples as the identified resource (duplicative services), such that they could be used interchangeably; [0040], In some embodiments, identifying a sufficiently similar resource may require locating a resource that is, for the purposes of the shared computing environment, identical to the identified resource (assessment of the environment for duplicative services). In other words, block 108 may require locating a resource that functions identically to the identified resource (for example, a streaming operator with the same exact input tuple type, operation, and output tuple type) (Examiner notes: “resource” and “streaming operator” interpreted as interchangeable with the term “service”));
…;
selecting a shared service ([0029], Method 100 begins in block 102, in which a new or private resource of the shared computer environment is identified … In that case, block 102 may be performed when the user is configuring that new streaming operator (shared service); [0031], Upon identifying a resource in block 102, method 100 proceeds to block 104 in which the computer system determines whether the new or private resource can now be configured sharable (shared service is selected for sharing)) and a duplicate service from said duplicative services ([0046], If, however, a matching resource is discovered in block 108, the managing computer system can determine, in block 112, that the users of the matching resource agree to merge the identified resource with the matching resource; [0048], Once the agreement is confirmed, the managing computer gives, in block 114, the user of the identified resource access to the matching resource. The nature of this access may depend upon the nature of the shared and the properties of the matching resource);
…; and
terminating said duplicated service ([0049], Upon giving a user of the identified resource access to the shared matching resource, the managing computer system deletes any redundant resources that are no longer needed. For example, if the identified resource discovered at block 102 were a pre-existing private resource that a user requested to be reconfigured into a public resource, block 116 may include deleting the identified resource).
However, Sun does not explicitly teach introducing a migration controller to an open-source container environment and redirecting, via said migration controller, resource requests to said shared service based on service combination rules.
Rosinosky teaches introducing a migration controller to an open-source container environment (Pg. 3, Software-as-a-service (SaaS) is the cloud service model with the highest market size. It allows client organizations, or tenants, to benefit from turn-key applications. Multi-tenancy is the sharing application instances across multiple tenants. It enables SaaS providers to benefit from economies of scale, consolidating service load for different tenants, and reducing total cost of ownership. Multi-tenancy can be implemented by sharing computing resources (virtual machines (VM) or containers), by sharing application servers, storing data for multiple tenants in the same database or using a combination of these approaches; The use of our proposed evolution of the application schema enables migrations using a series of SQL statements (i.e., in concordance with our objective of non-intrusion, we do not require the specific features from the database system itself). Table data stored in the tenant database and specific to the migrated tenant should be inserted in the corresponding table at the destination (which can be, in the case of a horizontal scale-out operation, a freshly-started database instance, or an existing instance in the case of a consolidation).);
…
redirecting, via said migration controller, resource requests to said shared service based on service combination rules (Pg. 9, The migration process requires the following steps to migrate tenant t from one stack a featuring database D.sub.a and application A.sub.a to stack b formed of database D.sub.b and application A.sub.b: 1. Stop the tenant on application A.sub.a and disconnect users; 2. Disable foreign key checks for the database connection; 3. for each table in the tenant database, instantiate a temporary foreign table using a table data wrapper in database D.sub.a, targeting the corresponding table in database D.sub.b; then, in database D.sub.a. insert data corresponding to tenant t in the foreign tables, thereby inserting it in database D.sub.b; 4. enable foreign key checks for the database connection; 5. If there were no errors, delete temporary foreign tables used for the transfer from database D.sub.a and tenant t data from this database; 6. re-activate the tenant on application A.sub.b. Queries from users of tenant t should now target application A.sub.b).
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 15 is being recited again as a computer program product for the system of claim 1.
Sun reasonably teaches identification of matching duplicate resources through analyzing shareable metadata tags (Sun, [0042]). However, Sun and Rosinosky do not explicitly teach that duplicative services share a custom resource definition with another service.
Kahrs teaches duplicative services share a custom resource definition with another service (Col. 12, lines 19-29, As also shown in FIG. 4, the resource groups service 402 might expose an API 410 for performing various types of functionality. For example, and without limitation, the API 410 might include methods for creating, editing, or deleting resource group definitions 404 (Examiner notes: Such that custom resource definitions can be engineered). The API 410 might also include a method for exporting resource group definitions 404. In this way, the resource group definitions 404 can be shared with other users of the service provider network 102 via a marketplace and/or in another manner. Other mechanisms might also be utilized to enable sharing of resource group definitions 404; Col. 12, lines 30-36, The API 410 might also include a method for evaluating a resource group definition 404. When a request is received to evaluate a resource group definition, the resource groups service 402 is configured to identify those resources 108 in the service provider network 102 that have associated resource tags that match the resource tags 116 in the resource group definition 404) is substantially similar to claim 1, and therefore is rejected with similar rationale.
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 15 is being recited again as a computer program product for the system of claim 1.
With regard to claim 16, Rosinosky teaches the computer program product of claim 15, said function further comprising:
scaling said shared service to support said resource requests (Pg. 4, We present a non-intrusive and efficient methodology for stop-and-copy tenant migration in legacy multi-tenant application using the shared-table approach. Our method enables such legacy applications to scale in and out based on tenants’ requirements (e.g., the volume of requests or data).).
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that claim 16 is being recited again as a computer program product for the system of claim 2.
With regard to claim 20, Sun teaches the computer program product of claim 15, said function further comprising:
establishing a service combination ruleset for said duplicative services ([0041], As discussed, if a managing computer system determines, block 104, that the identified resource can be configured as semi-public, the identified resource may have additional sharing requirements that must be met before the identified resource can be shared. In these instances, block 108 may also include locating resources that are not only sufficiently similar to the identified resource, but also that meet these sharing requirements. For example, block 108 may include only searching for resources that are rented by users on a list of users provided in block 104. Similarly, block 108 may include searching for resources that are only available to users of a particular group (e.g., employees of a company, members of a particular university, or members of joint venture group). Block 108 may also include searching for resource that meet particular security requirements, such as streaming operators that require input tuples be encrypted and that encrypt output tuples after processing).
Claims 3, 4, 10, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Rosinosky in view of Kahrs as applied to claims 1, 8, and 15 above, and further in view of Kwok et al. US 2010/0077449 A1 (hereinafter Kwok).
With regard to claim 3, the combination does not teach the claim.
Kwok teaches the system of claim 1, said operations further comprising:
calculating a duplicative resource usage of said open-source environment while said open-source environment uses said duplicative services ([0031], Let r be the number of users, and C(r) and M(r) be the CPU and storage required by an instance with multi-users (duplicative services), respectively. Then, C(r)=F.sub.cu.(r) M(r)=M.sub.0 + F.sub.mu.(r) where F.sub.cu.(r) and F.sub.mu.(r) are functions of r).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kwok with the teachings of Sun, Rosinosky, and Kahrs in order to provide a system that teaches calculate resource utilization of multi-user standalone services. The motivation for applying Kwak teaching with Sun, Rosinosky, and Kahrs teaching is to provide a system that allows for calculating resource utilization metrics for determining the basic or minimum requirements of available resource (Kwok, [0035]). Sun, Rosinosky, Kahrs and Kwok are analogous art directed towards resource allocation and request servicing. Therefore, it would have been obvious to a person of ordinary skill in the art to combine Kwok with Sun, Rosinosky, and Kahrs to teach the claimed invention in order to better quantify redundancy consumption of resources.
With regard to claim 4, the combination teaches, wherein Kwok teaches the system of claim 3, said operations further comprising:
calculating a shared resource usage of said open-source environment while said open-source environment uses said shared resource ([0031], However, the calculation of resources required for a shared instance supporting multi-tenants and multi-users are new and complicated. Let t be the number of tenants in a shared instance and n be the total number of users. Then, C(n,t)= F.sub.cu.(n)+f.sub.ct(t) M(n,t)=M.sub.0 + F.sub.mu.(n) + f.sub.mt.(t) where F.sub.ct.(t) and F.sub.mt.(t) are functions of t); and
assessing a resource savings between said duplicative resource usage and said shared resource usage ([0031], For a special case where there are two tenants t=2 and the number of users in the two tenants are both equal to r such that n=2r. Let us compare resources required in this special case deploy in two different computing environments (duplicative services vs shared service); [0032], Thus from equations (3), (4), and (7): C(2r,1) > 2C(r,1) … There are savings in those resources shared by multi-tenants such as storage and memory).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kwok with the teachings of Sun, Rosinosky, and Kahrs in order to provide a teaches that teaches calculating shared resource utilization and performing an assessment in relation to duplicative services. The motivation for applying Kwok teaching with Sun, Rosinosky, and Kahrs teaching is to provide a system that allows for determining shared resource utilization for determining an offer to be made to a instance, supporting multi-tenancy (Kwok, [0007]-[0008]). Sun, Rosinosky, Kahrs and Kwok are analogous art directed towards resource allocation and request servicing. Therefore, it would have been obvious to a person of ordinary skill in the art to combine Kwok with Sun, Rosinosky, and Kahrs to teach the claimed invention in order to better quantify shared consumption of resources and savings difference for consideration.
With regard to claim 10, the combination does not teach the claim.
Kwok teaches the computer-implemented method of claim 8, further comprising:
calculating a duplicative resource usage of said open-source environment while said open-source environment uses said duplicative services ([0031], Let r be the number of users, and C(r) and M(r) be the CPU and storage required by an instance with multi-users (duplicative services), respectively. Then, C(r)=F.sub.cu.(r) M(r)=M.sub.0 + F.sub.mu.(r) where F.sub.cu.(r) and F.sub.mu.(r) are functions of r) is substantially similar to claim 3, and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that claim 10 is being recited again as a computer-implemented method of the system of claim 3.
With regard to claim 11, the combination teaches, wherein Kwok teaches the computer-implemented method of claim 10,
calculating a shared resource usage of said open-source environment while said open-source environment uses said shared resource ([0031], However, the calculation of resources required for a shared instance supporting multi-tenants and multi-users are new and complicated. Let t be the number of tenants in a shared instance and n be the total number of users. Then, C(n,t)= F.sub.cu.(n)+f.sub.ct(t) M(n,t)=M.sub.0 + F.sub.mu.(n) + f.sub.mt.(t) where F.sub.ct.(t) and F.sub.mt.(t) are functions of t); and
assessing a resource savings between said duplicative resource usage and said shared resource usage ([0031], For a special case where there are two tenants t=2 and the number of users in the two tenants are both equal to r such that n=2r. Let us compare resources required in this special case deploy in two different computing environments (duplicative services vs shared service); [0032], Thus from equations (3), (4), and (7): C(2r,1) > 2C(r,1) … There are savings in those resources shared by multi-tenants such as storage and memory) is substantially similar to claim 4, and therefore rejected with similar rationale.
Examiner notes: It would be obvious for one of ordinary skill in the art to recognize that claim 11 is being recited again as a computer-implemented method of the system of claim 4.
With regard to claim 17, the combination does not teach the claim.
Kwok teaches the computer program product of claim 15, said further comprising:
calculating a duplicative resource usage of said open-source environment while said open-source environment uses said duplicative services ([0031], However, the calculation of resources required for a shared instance supporting multi-tenants and multi-users are new and complicated. Let t be the number of tenants in a shared instance and n be the total number of users. Then, C(n,t)= F.sub.cu.(n)+f.sub.ct(t) M(n,t)=M.sub.0 + F.sub.mu.(n) + f.sub.mt.(t) where F.sub.ct.(t) and F.sub.mt.(t) are functions of t) is substantially similar to claim 3, and therefore rejected with similar rationale.
Examiner notes: it would have been obvious for one of ordinary skill in the art to recognize that claim 17 is being recited again as a computer program product for the system of claim 3.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Rosinosky in view of Kahrs in view of Kwok as applied to claims 4 and 11 above, and further in view of Srinivasan et al. US 2022/0374283 A1 (hereinafter Srinivasan).
With regard to claim 5, the combination teaches, wherein Sun teaches the system of claim 4, said operations further comprising:
engaging said redirected resource requests because said resource savings achieves a savings … ([0015], In some instance, these three users may pay for private use of their entire streaming application, including all operators therein. However, in some instances, some operators of each of the three private streaming applications may perform the same operations on the same type of data. In these instances, the streaming operators could theoretically be shared between the three users. This would enable the owner of the streaming application to maintain only one operator, rather than three. This could result in cost savings that can enable compensating the three users for sharing the operators)
Sun teaches engaging in resource redirection enables saving, however, may not explicitly teach a savings threshold.
Srinivasan teaches said resource savings achieves a savings threshold ([0094], Generally, the more the potential savings are, the higher priority that the service resource unit should be optimized; [0095], As an example, if the cumulative savings percentage for a service resource unit is less than or equal to 65% the optimization priority for the service resource unit is set to be high).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Srinivasan with the teachings of Sun, Rosinosky, Kahrs, and Kwok in order to provide a system that teaches saving thresholds enabling request redirection. The motivation for applying Srinivasan teaching with Sun, Rosinosky, Kahrs, and Kwok teaching is to provide a system that enables resource optimization based on measurable efficiency, guiding a system to engage in decisions yielding the highest benefits and support the calculation of cumulative savings (Srinivasan, [0094]). Sun, Rosinosky, Kahrs, Kwok, and Srinivasan are analogous art directed towards resource allocation and request servicing. Therefore, it would have been obvious to a person of ordinary skill in the art to combine Srinivasan with Sun, Rosinosky, Kahrs, and Kwok to teach the claimed invention in order to implement request migration resulting in measurable resource savings.
With regard to claim 12, the combination teaches wherein Sun teaches the computer-implemented method of claim 11, further comprising:
engaging said redirected resource requests because said resource savings achieves a savings … ([0015], In some instance, these three users may pay for private use of their entire streaming application, including all operators therein. However, in some instances, some operators of each of the three private streaming applications may perform the same operations on the same type of data. In these instances, the streaming operators could theoretically be shared between the three users. This would enable the owner of the streaming application to maintain only one operator, rather than three. This could result in cost savings that can enable compensating the three users for sharing the operators)
Sun teaches engaging in resource redirection enables saving, however, may not explicitly teach a savings threshold.
Srinivasan teaches said resource savings achieves a savings threshold ([0094], Generally, the more the potential savings are, the higher priority that the service resource unit should be optimized; [0095], As an example, if the cumulative savings percentage for a service resource unit is less than or equal to 65% the optimization priority for the service resource unit is set to be high) is substantially similar to claim 5, and therefore is rejected with similar rationale.
Examiner notes: it would have been obvious for one of ordinary skill in the art to recognize that claim 12 is being recited again as a computer-implemented method of the system of claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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, Aimee Li can be reached at (571) 272-4169. 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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights