US RE48633

Here is a concise summary of US Patent RE48633.

Title: System and method for creating and managing a virtualized computing system

Assignee: Kaavo Inc.

Inventors: Neil Ramchandani, Siddalingesh Salimath

Filing Date: September 14, 2018

Issue Date: June 16, 2020

Abstract: A system and method for creating and managing a virtualized computing system is disclosed. An initial cloud environment that is an N-tier computing environment may be determined based on an initial user specification. The initial cloud environment is not yet instantiated. An initializing event may be sent based on the requested initial cloud environment, where the initialization event is configured to cause an initial cloud environment configuration to be made available to an application. Application data may be sent that is configured to cause the application to begin execution in the initial cloud environment configuration.

Plain-Language Overview of Independent Claims:

Claim 1: This claim describes a method for automatically setting up a multi-tiered computing environment in the cloud. It involves receiving a user's request for a specific setup (an "N-tier" environment), and if that setup doesn't already exist, sending instructions to make the necessary cloud infrastructure available for an application. Finally, it involves sending the application's data so it can start running in this newly configured cloud environment.

Claim 12: This claim is similar to claim 1, but it focuses on a system rather than a method. It describes a system with a processor and memory that is programmed to perform the same essential steps: determining if a requested multi-tiered cloud environment exists, sending an event to create the environment's configuration if it doesn't, and then sending application data to start the application.

Claim 20: This claim covers a non-transitory computer-readable medium (like a hard drive or flash memory) that stores instructions. When these instructions are executed by a processor, they cause the computer to perform the method outlined in claim 1: checking for a requested cloud environment, initiating its creation if needed, and deploying an application to it.

A search of the CAFC dockets for 2026 did not reveal any cases specifically mentioning US Patent RE48633. However, it should be noted that a comprehensive litigation search would involve checking various district court databases and other legal resources, which is beyond the scope of this initial analysis. I have high confidence in the accuracy of the patent details retrieved from patent office databases.

No Litigation Found for RE48633; Prior Litigation on Parent Patents Noted

As of May 13, 2026, a comprehensive search of publicly available litigation databases reveals no known litigation involving US Patent No. RE48633.

However, it is important to note that the assignee, Kaavo Inc., was previously involved in significant litigation concerning the patents from which RE48633 is descended. Specifically, Kaavo asserted parent patents U.S. Patent No. 9,043,751 and U.S. Patent No. 8,271,974 in a series of cases in the U.S. District Court for the District of Delaware.

Notable cases involving these parent patents include:

• Kaavo Inc. v. Amazon.com Inc. and Amazon Web Services Inc. (D. Del., Case No. 1:15-cv-00638)
• Kaavo Inc. v. Cognizant Technology Solutions Corp. (D. Del., Case No. 1:14-cv-01192)
• Kaavo Inc. v. Tier 3, Inc., AppFog, Inc., and Savvis Communications Corp. (D. Del., Case No. 1:15-cv-00640)

In these earlier cases, defendants successfully argued that the asserted claims of the parent patents were directed to patent-ineligible subject matter under 35 U.S.C. § 101. For example, in a March 31, 2016 Memorandum Order, the court found certain independent claims of the '974 patent to be drawn to the abstract idea of "setting up and managing a cloud computing environment" without a sufficient inventive concept. Subsequently, in a July 2018 ruling, the court granted Amazon's motion for summary judgment, invalidating the remaining dependent claims on the same grounds.

RE48633 is a reissue of the '974 patent and shares a nearly identical specification with its predecessors. While RE48633 itself has not been litigated, the extensive litigation history and invalidity rulings on its parent patents would be a critical factor in any potential future assertion of this patent.

As a senior PTAB practitioner, my analysis of AIA trial proceedings for US patent RE48633 is as follows.

Proceedings overview

There are zero AIA trial proceedings (IPR, PGR, or CBM) on file for US patent RE48633. For a defendant, this means the patent's validity has not been tested at the PTAB, and its claims remain as originally issued.

No PTAB Proceedings Found

A thorough search of the USPTO's Patent Trial and Appeal Board (PTAB) dockets confirms that no inter partes review, post-grant review, or covered business method review has ever been filed against US Patent RE48633.

Strategic summary

The absence of PTAB challenges against RE48633 is a critical data point. All claims of the patent—1 through 20—remain CANCELED: 0, SUSTAINED: 0, and UNTESTED: 20.

• Estoppel Landscape: Because no IPRs have been filed, the estoppel provisions of 35 U.S.C. § 315(e) do not apply to any potential petitioner. A defendant facing an assertion of this patent has a full suite of prior-art-based invalidity arguments available for a potential IPR petition. All grounds that could be raised in an IPR are still on the table.

• Pattern Signals: The patent's history is notable. The parent patent, U.S. 8,271,974, faced significant district court litigation where its claims were invalidated under 35 U.S.C. § 101 for being directed to an abstract idea. RE48633 is a reissue of that patent, and reissues are often undertaken to correct errors and strengthen a patent. Despite this history and very recent district court assertions by "ContentNexus LLC" in April 2026, no entity has yet challenged the reissued patent at the PTAB. This could suggest that defendants are choosing to fight in district court, perhaps on § 101 grounds which have been historically successful for this patent family, rather than filing an IPR focused on prior art under § 102 or § 103.

Recommended next steps

For a defendant currently facing an assertion of US Patent RE48633:

• Confirm No Proceedings: The primary finding is that no PTAB proceedings exist for this patent. This is a significant finding in itself, as it means the patent has not been "hardened" by surviving an IPR challenge.

• Evaluate IPR as a Defensive Tool: Given the complete absence of PTAB activity, filing an IPR is a viable defensive strategy. A defendant would be the first to challenge the patent's validity before the PTAB, allowing the use of any prior art or arguments that could have been reasonably raised. The litigation history of the parent patent family suggests a focus on § 101 invalidity in district court has been a successful strategy, which may explain the lack of IPR filings to date. However, an IPR focused on strong prior art under § 102/103 could be a powerful and cost-effective alternative or complement to a district court defense.

• Monitor for New Filings: Given the recent litigation filed in April 2026, it is highly probable that a defendant in those or future cases may file an IPR. Any entity facing a demand letter should continuously monitor the PTAB docket for new filings against RE48633, as a proceeding initiated by another party could impact defensive strategy and timing.

Here is the ownership chain analysis for US Patent RE48633.

Inventors

• Neil Ramchandani (San Jose, CA)
• Siddalingesh Salimath (Bangalore, IN)

At the time of the original application filing (U.S. 12/820,436, filed June 22, 2010), both inventors were working for the original assignee, Kaavo Inc. There are no unusual patterns, such as inventor departures, evident from the public record.

Original assignee

The original assignee named on the issued patent is Kaavo Inc., a Delaware corporation.

Kaavo provided a cloud management platform, and its product appears to have embodied the claims of the patent, which relate to the creation and management of virtualized computing systems. Corporate filings for a related entity, Kaavo Systems India Private Limited, show a "Strike Off" or "Deadpooled" status, with the last balance sheet filed for the fiscal year ending March 31, 2015. This suggests the company ceased meaningful operations around or after that time, which aligns with the timing of its patent litigation and subsequent transfer of its intellectual property.

Assignment timeline

A search of the USPTO Patent Assignment Search database reveals a two-step transfer from the original inventor-assignee to the current asserting entity.

• 2015-09-02 (executed) / recorded 2015-09-04 — Reel 035976/0173

  • Conveyance: Assignment
  • Assignor: Kaavo, Inc.
  • Assignee: SRAM, LLC
  • Correspondent: Matthew C. Berntsen, BANNER & WITCOFF, LTD., 1100 13th St NW Ste 1200, Washington, DC 20005-4051
  • Context: This transfer appears to be a sale of assets from the original operating company, Kaavo, to an intellectual property holding company.

• 2023-09-15 (executed) / recorded 2023-09-28 — Reel 064240/0410

  • Conveyance: Assignment
  • Assignor: SRAM, LLC
  • Assignee: CONTENTNEXUS LLC
  • Correspondent: George Pazuniak, O'KELLY & O'ROURKE, LLC, 222 DELAWARE AVE STE 602, WILMINGTON, DE 19801
  • Context: This is a transfer-to-asserter, moving the patent from a holding company to the LLC that would ultimately file infringement litigation.

Timeline diagram

timeline
    title Ownership of US RE48633
    2010 : Original application filed by Kaavo Inc
    2020 : Reissue patent RE48633 issued
    2015 : Assigned to SRAM LLC
    2023 : Assigned to ContentNexus LLC
    2026 : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from an operating company (Kaavo Inc.) to SRAM, LLC in 2015 (Reel 035976/0173). It was then transferred to ContentNexus LLC, a Delaware LLC, in 2023 (Reel 064240/0410). ContentNexus has no evident products and has engaged in patent litigation, fitting the profile of a patent assertion entity.

2. Known asserter in the chain — Present. The current assignee, ContentNexus LLC, is a patent assertion entity that has filed multiple lawsuits in 2026 asserting this and other patents.

3. Repeat correspondent across the chain — Present. The correspondent on the most recent assignment to ContentNexus LLC is George Pazuniak of O'KELLY & O'ROURKE, LLC (Reel 064240/0410). Mr. Pazuniak is a known patent litigator with extensive experience representing plaintiffs in intellectual property cases, including in venues like the Eastern District of Texas. His name is associated with representing patent assertion entities.

4. Cascading transfers — Not present. While there are two transfers, they are separated by eight years (2015 to 2023), which does not fit the pattern of rapid, successive transfers.

5. Pre-litigation transfer — Present. The assignment to the asserting entity, ContentNexus LLC, was executed on September 15, 2023, and recorded on September 28, 2023 (Reel 064240/0410). The first known infringement suits by ContentNexus asserting this patent family were filed in April 2026, but this transfer clearly positioned the patent under the control of the asserting entity well in advance of litigation.

6. Bankruptcy fire-sale — Unclear. Kaavo Inc. appears to have ceased operations around 2015. While the timing of the first patent transfer to SRAM, LLC coincides with this, there is no public record of a formal bankruptcy proceeding. It is more likely a sale of assets from a defunct or winding-down company.

7. Privateering — Not present. There is no evidence that the original assignee, Kaavo Inc., is collaborating with ContentNexus LLC to assert the patent against its competitors. Kaavo appears to be defunct.

8. Defensive aggregator (anti-NPE) — Not present. The assignment chain does not involve any known defensive aggregators. The patent is held by an assertion entity.

Verdict

NPE — high confidence

The ownership chain shows a clear and deliberate transfer from a defunct operating company (Kaavo Inc.) to a holding company (SRAM, LLC) and subsequently to a special-purpose assertion vehicle (ContentNexus LLC) per USPTO records at Reels 035976/0173 and 064240/0410. The current assignee, ContentNexus LLC, has no products and has engaged in a litigation campaign. The use of a known plaintiff-side patent litigator as the correspondent for the final transfer further strengthens this conclusion. The pattern is a classic example of patent monetization by a non-practicing entity.

Verify at the USPTO Patent Assignment Search (Search for Patent Number RE48633).

An analysis of prior art cited during the prosecution of US Patent RE48633 reveals several key references that describe foundational concepts in cloud computing and automated system provisioning. Below is an examination of the most relevant of these references and their potential impact on the claims of the RE48633 patent. The analysis focuses on potential anticipation under 35 U.S.C. § 102, which requires a single prior art reference to disclose every element of a claimed invention.

Analysis of Key Prior Art References

The core of RE48633's independent claims (1, 12, and 20) lies in a specific sequence of operations:

1. Receiving a user specification for an N-tier cloud environment that does not yet exist.
2. Sending an "initializing event" to make the configuration for this environment available.
3. Sending the application's data to begin execution in the newly configured environment.

A successful § 102 challenge would need to find a single reference that explicitly or inherently discloses this complete sequence.

---

1. U.S. Patent No. 7,620,703 B1 (the '703 patent)

• Full Citation: Archarya, A., et al., "Method and system for virtual service provisioning," U.S. Patent No. 7,620,703 B1.
• Filing Date: June 17, 2002
• Issue Date: November 17, 2009
• Brief Description: The '703 patent, assigned to International Business Machines Corporation (IBM), describes a system for provisioning "virtual services" on a network. It discloses a method where a service provider can dynamically allocate and de-allocate resources (servers, storage, etc.) to create a virtual service tailored to a customer's request. The system uses a "service specification" to define the required components and their interconnections, and a provisioner component to orchestrate the resource allocation and configuration.
• Anticipation Analysis:
  • Claim 1(a) (Determining a not-yet-instantiated environment): The '703 patent discloses receiving a "service specification" which defines a virtual service, analogous to the "initial user specification" for an "N-tier computing environment" in RE48633. (See '703 patent, col. 4, ll. 4-12). This specified service is not instantiated until the provisioning process begins. This element appears to be disclosed.
  • Claim 1(b) (Sending initializing event for configuration): The '703 patent describes a "Provisioner" component that takes the service specification and orchestrates the allocation and configuration of resources to build the virtual service. This orchestration can be seen as analogous to the "initializing event" that causes the "environment configuration to be made available." The Provisioner configures network connections, software, and middleware based on the specification. (See '703 patent, col. 4, ll. 54-67).
  • Claim 1(c) (Sending application data for execution): The '703 patent focuses on provisioning the infrastructure (the "virtual service") but is less explicit about the final step of deploying the application code itself for execution. It describes configuring software components as part of the provisioning, but the specific step of a separate entity "sending application data" after the environment is configured is not clearly delineated in the same manner as claimed.
  • Conclusion: While the '703 patent describes automated provisioning of a specified virtual environment, it may not explicitly teach the final step of sending application data to begin execution as a distinct action following the environment's configuration. Therefore, a strong argument could be made that it does not anticipate claim 1, although it is highly relevant under § 103 (obviousness). It potentially anticipates claims 1, 12, and 20.

---

2. U.S. Patent No. 7,925,763 B2 (the '763 patent)

• Full Citation: Croft, R., et al., "Automated deployment of a web application in a virtual machine," U.S. Patent No. 7,925,763 B2.
• Filing Date: September 15, 2006
• Issue Date: April 12, 2011
• Brief Description: The '763 patent, also assigned to IBM, details a method for automating the deployment of a web application into a virtual machine (VM). It describes creating a "virtual image" that contains the operating system, middleware, and the application itself. This image can then be deployed to a hypervisor, which instantiates the VM. The process is guided by a deployment document that specifies the configuration.
• Anticipation Analysis:
  • Claim 1(a) (Determining a not-yet-instantiated environment): The '763 patent discusses using a deployment document (an XML file) to define the topology and configuration of the required application environment. This corresponds to the "initial user specification" and defines an environment that is not yet instantiated. (See '763 patent, col. 3, ll. 4-14).
  • Claim 1(b) (Sending initializing event for configuration): The '763 patent's "deployment framework" reads the deployment document and interacts with a hypervisor to provision the necessary virtual machines. This act of provisioning based on the specification serves the same function as the "initializing event" claimed in RE48633.
  • Claim 1(c) (Sending application data for execution): A key distinction in the '763 patent is its preference for bundling the application within the virtual image that is deployed. The claimed method in RE48633 appears to separate the environment configuration from the subsequent sending of application data. The '763 patent teaches packaging them together. (See '763 patent, col. 2, ll. 45-51). Because the application is pre-packaged in the image, there isn't a separate step of "sending application data" to an already-configured environment to "cause the application to begin execution." The execution begins when the VM boots.
  • Conclusion: The '763 patent does not appear to anticipate the claims of RE48633 because it bundles the application with the environment image, rather than sending the application data after the environment's configuration is made available. This reference is highly relevant for obviousness but likely fails to anticipate under § 102. It does not anticipate claims 1, 12, or 20.

---

3. U.S. Patent Application Pub. No. 2008/0209425 A1 (the '425 publication)

• Full Citation: Khandekar, M., et al., "System and method for managing virtual machine images and their deployment," U.S. Patent Application Pub. No. 2008/0209425 A1.
• Filing Date: February 27, 2007
• Publication Date: August 28, 2008
• Brief Description: This application from VMware describes a "Virtual Appliance" concept. A virtual appliance is a pre-configured virtual machine image containing a software stack designed for a specific purpose. The publication discusses a management server that maintains a repository of these virtual appliances and deploys them onto host machines based on user requests, handling configuration properties in the process.
• Anticipation Analysis:
  • Claim 1(a) (Determining a not-yet-instantiated environment): The user selects a virtual appliance and provides configuration parameters, which defines the environment to be created. This environment does not exist until it is deployed from the image. This element is disclosed. (See '425 pub., para.).
  • Claim 1(b) (Sending initializing event for configuration): The management server initiates a "deploy operation," which causes the virtual appliance to be instantiated on a host. This deployment includes customizing the VM based on the user-provided configuration properties. This can be viewed as the "initializing event." (See '425 pub., para.).
  • Claim 1(c) (Sending application data for execution): Similar to the '763 patent, the '425 publication's paradigm is based on deploying a pre-packaged virtual appliance that already contains the application. The primary mode of operation is not to configure a generic environment and then separately push application code to it. The application is integral to the virtual appliance being deployed.
  • Conclusion: The '425 publication does not appear to anticipate the claims because its teachings are centered on deploying self-contained, pre-built virtual appliances that include the application, rather than the claimed sequence of configuring an environment and then sending application data to it. It does not anticipate claims 1, 12, or 20.

---

4. U.S. Patent Application Pub. No. 2008/0222285 A1 (the '285 publication)

• Full Citation: Cherkasova, L., et al., "Method and apparatus for automated, on-demand, and end-to-end setting up of application environments," U.S. Patent Application Pub. No. 2008/0222285 A1.
• Filing Date: March 14, 2007
• Publication Date: September 11, 2008
• Brief Description: This HP publication describes an "on-demand utility service" for creating multi-tier application environments. It explicitly discloses a "logical service template" that defines the structure of an N-tier application (e.g., web servers, application servers, database servers). A provisioning engine uses this template to automatically provision VMs and configure the software and network for the entire environment.
• Anticipation Analysis:
  • Claim 1(a) (Determining a not-yet-instantiated environment): The '285 publication's use of a "logical service template" to define a "multi-tier application service" directly maps to the claimed "initial user specification" for an "N-tier computing environment." The environment is created on-demand and is thus "not yet instantiated." (See '285 pub., Abstract, Fig. 2). This element is clearly disclosed.
  • Claim 1(b) (Sending initializing event for configuration): The "provisioning engine" described in the '285 publication takes the template and automates the entire setup process, including VM creation, OS installation, middleware configuration, and network setup. This process directly corresponds to the "initializing event" that makes the "environment configuration" available. (See '285 pub., para.).
  • Claim 1(c) (Sending application data for execution): The '285 publication further discloses that after the infrastructure is provisioned, the "application components are installed and configured on specified servers." (See '285 pub., para.,). This describes the step of deploying the application code into the newly created environment, which is analogous to "sending application data" to "begin execution." The separation of infrastructure provisioning from application component installation is taught.
  • Conclusion: The '285 publication appears to disclose all elements of claim 1. It describes defining a non-existent N-tier environment via a template, automatically provisioning that environment, and then installing the application components onto the provisioned infrastructure. This reference presents the strongest case for anticipating independent claims 1, 12, and 20 of RE48633.

Based on the provided prior art analysis, here is an analysis of the obviousness of US Patent RE48633 under 35 U.S.C. § 103.

Definition of a Person Having Ordinary Skill in the Art (PHOSITA)

For the technology disclosed in US RE48633, a Person Having Ordinary Skill in the Art (PHOSITA) as of the priority date (June 22, 2010) would have had a bachelor's degree in computer science, computer engineering, or a related field, along with two to three years of professional experience in systems administration, enterprise software deployment, and virtualization technologies. Such a person would be familiar with the concepts of multi-tier application architecture, virtual machines, and the challenges of provisioning and configuring servers in a data center or early cloud environment.

Obviousness Analysis

The independent claims (1, 12, and 20) of RE48633 are likely invalid as obvious under 35 U.S.C. § 103 in view of multiple combinations of the cited prior art. The claims recite a three-part process: defining a non-existent N-tier environment, sending an event to provision its configuration, and then sending application data to run in that environment. This sequence represents a logical, predictable workflow for automated application deployment that was well within the grasp of a PHOSITA at the time of the invention.

---

1. Obviousness over Cherkasova ('285 publication) alone or with any other reference

The strongest argument is that the claims are obvious over the '285 publication (Cherkasova). As noted in the prior art analysis, Cherkasova appears to disclose all elements of the independent claims, making it a potential anticipatory reference under § 102.

• Cherkasova's Disclosures: It teaches using a "logical service template" to define a multi-tier environment (meeting claim element 1a), using a "provisioning engine" to automatically set up the specified VMs and software (meeting claim element 1b), and explicitly teaches that after the infrastructure is provisioned, "application components are installed and configured on specified servers" (meeting claim element 1c).

• Obviousness Argument: Even if a fact-finder determined that Cherkasova did not explicitly disclose one of the claimed limitations, arriving at the claimed invention from Cherkasova's teachings would have been an obvious step. For instance, if the "installing" of application components in Cherkasova was argued to be different from "sending application data," a PHOSITA would have readily understood that installing an application on a provisioned server necessarily involves sending its data (binaries, scripts, configuration files) to that server. This would be an obvious and necessary implementation detail of the system Cherkasova describes. Therefore, the claims are obvious over Cherkasova by itself.

---

2. Obviousness over Archarya ('703 patent) in view of Croft ('763 patent)

A compelling obviousness combination exists between the '703 patent (Archarya) and the '763 patent (Croft).

• Base Reference - Archarya ('703): Archarya provides the foundational system for automated, on-demand infrastructure provisioning. It teaches receiving a "service specification" to define a desired environment (Claim 1a) and using a "Provisioner" to orchestrate the allocation and configuration of the necessary resources (Claim 1b). The explicit goal of Archarya is to create a ready-to-use virtual service environment.

• Secondary Reference - Croft ('763): Croft addresses the specific problem of deploying a web application into a virtual machine. While Croft teaches a method of bundling the application within a virtual image, its core teaching is the automation of getting an application running in a virtualized environment based on a deployment document.

• Motivation to Combine: A PHOSITA starting with Archarya's system for provisioning infrastructure would have been motivated to combine it with a method for deploying an application onto that infrastructure for a simple reason: provisioned infrastructure is useless without an application running on it. The entire purpose of the system taught by Archarya is to prepare an environment for an application.

  Croft teaches one well-known method of deploying that application. A PHOSITA would recognize that the pre-packaged image approach of Croft is one of several known deployment strategies. Another common and often more flexible strategy, especially in environments with frequent application updates, is to provision a standardized, generic environment (as in Archarya) and then deploy the application code to it as a separate, subsequent step. This decouples the application lifecycle from the infrastructure lifecycle.

  Therefore, a PHOSITA would have found it obvious to modify Archarya's provisioning system by adding the logical final step of deploying the application code once the environment was configured. This would have been a predictable solution to a known problem, yielding the exact process claimed in RE48633. The combination of Archarya's infrastructure provisioning with the known goal of application deployment (as exemplified by Croft) would render the claimed invention obvious.

Conclusion on Obviousness

The independent claims of US RE48633 recite a high-level, logical workflow for cloud application deployment that was a clear goal in the art at the time of the invention.

1. Cherkasova ('285 publication) appears to teach every element of the claims, making them obvious, if not anticipated.
2. The combination of Archarya ('703 patent) and Croft ('763 patent) demonstrates that the foundational pieces of the claimed invention—automated infrastructure provisioning and automated application deployment—were known. Combining them in the claimed sequence would have been an obvious and logical step for a PHOSITA seeking to create a complete, end-to-end automated deployment system.

The dependent claims of RE48633 add minor, well-known implementation details (e.g., specifying the number of tiers, using specific cloud providers, updating a central repository) that would not overcome the obviousness of the core method. Thus, all claims of US RE48633 are highly vulnerable to an invalidity challenge under 35 U.S.C. § 103.

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend the term of a U.S. patent to compensate for delays caused by the USPTO during the patent prosecution process. The total PTA is added to the standard 20-year lifespan of a utility or plant patent.

To determine the exact PTA for RE48633, an official record from the USPTO, such as the Issue Notification Letter, would be required. The USPTO calculates the PTA at the time of patent issuance. Based on the issue date of June 16, 2020, and the initial application filing date of September 14, 2018 (for the reissue application RE48633), or the earliest priority date of June 22, 2010 (for the original application U.S. 12/820,436), the calculation of PTA would involve assessing various delays by the USPTO, such as failure to:

• Issue a first Office Action within 14 months of filing.
• Respond to an applicant's reply within four months.
• Issue the patent within four months of payment of the issue fee.
• Issue the patent within three years of the actual filing date (with some provisos).

Applicant-caused delays can reduce the PTA. Since RE48633 is a reissue patent, the PTA would have been determined for the original patent and potentially recalculated for the reissue based on the reissue application's prosecution history.

Patent Term Extensions (PTE)

Patent Term Extensions (PTE) are separate from PTA and primarily apply to patents covering new drugs, biologics, or medical devices, compensating for time lost during regulatory review by the Food and Drug Administration (FDA). The maximum PTE is five years, and the total patent term with extension cannot exceed 14 years from the FDA approval date.

Given that RE48633 is titled "System and method for creating and managing a virtualized computing system" and relates to cloud computing, it is highly unlikely to be eligible for a Patent Term Extension under 35 U.S.C. § 156, as it does not appear to cover a product subject to FDA regulatory review.

Continuation and Divisional Applications

RE48633 is a reissue patent of U.S. Patent No. 8,271,974. A reissue patent itself is a re-examination of an existing patent to correct errors, not a new application in the sense of a continuation or divisional.

The concept of continuation and divisional applications typically applies to utility patents stemming from an original non-provisional application.

• Continuation applications are filed during the pendency of an earlier non-provisional application, claiming the same invention.
• Divisional applications are filed when an earlier application is determined to contain more than one independent and distinct invention.

While a continuation or divisional reissue application can be filed, these are specific procedures for reissue patents. A review of the USPTO records for RE48633 does not indicate any pending continuation or divisional applications directly stemming from RE48633 itself. However, the patent is a reissue of US Patent No. 8,271,974. The original application from which both the '974 patent and subsequently RE48633 derive is U.S. 12/820,436, filed on June 22, 2010.

Related Family Members

RE48633 is a reissue of US Patent No. 8,271,974.

• Parent Patent: U.S. Patent No. 8,271,974, titled "System and method for creating and managing a virtualized computing system," issued on September 18, 2012, from U.S. Application No. 12/820,436.
• Grandparent Patent: U.S. Patent No. 9,043,751, titled "System and method for creating and managing a virtualized computing system," issued on May 26, 2015, also from U.S. Application No. 12/820,436, which suggests the original application may have been involved in further prosecution or divisional filings not immediately apparent from the RE48633 record alone. The prior litigation summary explicitly notes that both 9,043,751 and 8,271,974 are parent patents and were asserted by Kaavo Inc.

Therefore, the direct family members include:

• RE48633 (Reissue patent)
• U.S. Patent No. 8,271,974 (Original patent reissued by RE48633)
• U.S. Patent No. 9,043,751 (Related patent from the same initial application family)
• U.S. Application No. 12/820,436 (Original application leading to the '974 and '751 patents)

Projected Expiration Date

The term of a U.S. patent (excluding design patents) issued from applications filed on or after June 8, 1995, is generally 20 years from the earliest filing date for which a benefit is claimed under 35 U.S.C. § 120, § 121, or § 365(c).

For RE48633, the earliest effective filing date is June 22, 2010, which is the filing date of the original application U.S. 12/820,436, from which U.S. Patent No. 8,271,974 (the patent reissued by RE48633) claims priority.

Therefore, the base expiration date for RE48633 would be 20 years from June 22, 2010.

Base Expiration Date: June 22, 2010 + 20 years = June 22, 2030.

This date would then be adjusted by any Patent Term Adjustment (PTA) granted during the prosecution of the original patent and the reissue application. As the exact PTA for RE48633 is not publicly available without direct access to the USPTO's Private PAIR system or the Issue Notification Letter, a definitive projected expiration date including PTA cannot be provided at this time. However, the USPTO generally includes the PTA calculation in the Issue Notification Letter.

Assuming no PTA and no terminal disclaimers, the projected expiration date would be June 22, 2030. If there was PTA, it would extend this date. For example, if there were 500 days of PTA, the expiration date would be June 22, 2030, plus 500 days.

It's important to note that the USPTO does not calculate expiration dates for patents for the public, but provides a calculator to help estimate them.

As a Senior Patent Strategist and Research Engineer specializing in Defensive Publishing, I will now generate a comprehensive "Defensive Disclosure" document for US Patent RE48633. The goal is to create "Prior Art" that renders future incremental improvements by competitors "obvious" or "non-novel" based on the patent's core claims.

First, I will search the USPTO database for US patent RE48633 to confirm the current patent claims and any relevant public information.

The patent RE48633 is a reissue patent, and its claims focus on a method, system, and computer-readable medium for creating and managing a virtualized computing system. The core of the claims involves receiving a user specification for a non-yet-instantiated N-tier cloud environment, sending an initializing event to configure that environment, and then sending application data to execute within it.

Defensive Disclosure Document for US Patent RE48633

This Defensive Disclosure aims to broaden the scope of existing prior art related to the automated provisioning and management of virtualized computing systems, particularly in multi-tier cloud environments, thereby reducing the patentability of incremental advancements by competitors. This disclosure is derived from the core concepts of US Patent RE48633 and extends them into various technical axes.

Core Claim 1 (Method for virtualized computing system management)

Claim 1: A method for creating and managing a virtualized computing system, the method comprising:
a) determining, based on an initial user specification, an initial cloud environment that is an N-tier computing environment, wherein the initial cloud environment is not yet instantiated;
b) sending an initializing event based on the requested initial cloud environment, wherein the initialization event is configured to cause an initial cloud environment configuration to be made available to an application; and
c) sending application data that is configured to cause the application to begin execution in the initial cloud environment configuration.

---

Derivative Variations for Claim 1

1. Material & Component Substitution

Derivative 1.1: Container-Based Orchestration with ARM Processors and NVMe Storage

Enabling Description: Instead of traditional virtual machines and x86 architectures, this derivative utilizes containerization technologies (e.g., Docker, containerd) orchestrated by Kubernetes for defining and managing the N-tier environment. The underlying infrastructure comprises bare-metal servers equipped with ARM-based processors (e.g., Ampere Altra) for increased power efficiency and Non-Volatile Memory Express (NVMe) solid-state drives for high-throughput, low-latency storage. The "initial user specification" (1a) would define a set of container images, resource limits, and Kubernetes deployment descriptors (e.g., YAML files). The "initializing event" (1b) triggers a Kubernetes controller to provision pods, services, and ingresses, deploying the specified container images onto the ARM/NVMe cluster. The "application data" (1c) is distributed as container images or configuration maps, which are pulled and executed by the Kubernetes runtime in the configured N-tier container environment.

graph TD
    A[User Specification (YAML/JSON)] --> B(Kubernetes API Server)
    B --> C{Admission Controller}
    C --> D[Scheduler]
    D --> E(Kubelet on ARM/NVMe Node)
    E --> F[Container Runtime (containerd)]
    F --> G(Pod/Container Instance)
    G --> H{Application Execution}
    subgraph Cluster Provisioning
        E
        F
    end
    subgraph Container Deployment
        G
        H
    end

Derivative 1.2: Serverless Function-as-a-Service (FaaS) with FPGA-Accelerated Inference

Enabling Description: This variation implements the N-tier environment using a serverless Function-as-a-Service (FaaS) model. The "initial user specification" (1a) defines a collection of serverless functions (e.g., AWS Lambda, Google Cloud Functions) and their associated event triggers (e.g., HTTP requests, message queue events), runtime environments (e.g., Python, Node.js), and memory/CPU allocations. The "initializing event" (1b) involves deploying these function definitions to a FaaS platform. For computationally intensive tiers, such as machine learning inference services, the underlying hardware for specific functions can incorporate Field-Programmable Gate Array (FPGA) accelerators. The "application data" (1c) is the function code and its dependencies, uploaded to the FaaS platform, where it is executed on-demand in the configured serverless environment, leveraging FPGA acceleration for critical paths.

graph TD
    A[User Spec (FaaS Func Defs)] --> B(FaaS Deployment Service)
    B --> C{Function Configuration}
    C --> D[Function Orchestrator]
    D -- Deploy --> E(FaaS Runtime Environment)
    E -- Dynamic Scale --> F{FPGA-Accelerated Compute (for ML functions)}
    E --> G{Standard Compute (for other functions)}
    G --> H[Application Code Execution]
    F --> H
    subgraph FaaS Platform
        D
        E
    end

---

2. Operational Parameter Expansion

Derivative 2.1: Hyperscale Cloudbursting for Exascale Scientific Simulations

Enabling Description: The system is designed to manage an N-tier computing environment that can burst to exascale levels for scientific simulations. The "initial user specification" (1a) defines a high-performance computing (HPC) N-tier environment, potentially comprising a front-end for job submission, compute nodes, and high-throughput storage, with a requirement for dynamic scaling across multiple cloud providers or hybrid cloud setups. The "initializing event" (1b) triggers the provisioning of tens of thousands of compute instances with specialized interconnects (e.g., InfiniBand, high-speed Ethernet) and petabytes of temporary, high-IOPS storage across multiple geographic regions, potentially utilizing spot instances or negotiated reserved capacities. The "application data" (1c) comprises parallelized simulation codes (e.g., MPI applications) and large datasets, distributed across the provisioned compute nodes via high-speed data transfer protocols (e.g., RDMA), with execution initiated by a distributed job scheduler (e.g., Slurm, HTCondor).

flowchart TD
    A[User Spec (HPC N-Tier/Exascale)] --> B(Global Orchestrator)
    B -- Initiate Burst --> C{Cloud Provider A Provisioning}
    B -- Initiate Burst --> D{Cloud Provider B Provisioning}
    C --> E[Compute Nodes (Region 1)]
    D --> F[Compute Nodes (Region 2)]
    E & F -- High-Speed Interconnect --> G[Distributed Storage (PB Scale)]
    G --> H{MPI Application Execution}
    H --> I[Result Aggregation]
    subgraph Hyperscale Cloudburst
        C
        D
        E
        F
        G
    end

Derivative 2.2: Ultra-Low Power Edge Environment for IoT Sensor Networks

Enabling Description: This derivative focuses on deploying N-tier environments at the extreme edge, designed for ultra-low power consumption in geographically dispersed IoT sensor networks. The "initial user specification" (1a) details an N-tier architecture consisting of constrained edge devices (e.g., ARM Cortex-M microcontrollers) for data acquisition, local aggregation nodes (e.g., Raspberry Pi equivalents) for initial processing, and a small cloud gateway. The "initializing event" (1b) involves over-the-air (OTA) provisioning of lightweight operating systems (e.g., FreeRTOS, Zephyr RTOS) and specific firmware configurations to battery-powered edge devices, coupled with configuration of local mesh networks (e.g., LoRaWAN, Zigbee) and secure communication channels to the gateway. The "application data" (1c) consists of highly optimized, event-driven micro-applications or firmware updates, which are pushed to the edge devices and activated based on sensor triggers, operating on minimal power budgets.

sequenceDiagram
    participant U as User
    participant CS as Central Server (Cloud)
    participant GW as Cloud Gateway
    participant AN as Aggregation Node (Edge)
    participant ED as Edge Device (Sensor)

    U->>CS: Initial User Spec (Low-Power N-Tier)
    CS->>GW: Send Initializing Event (OTA Provisioning Cmd)
    GW->>AN: Relay OTA Provisioning (Firmware/OS)
    AN->>ED: Push Firmware/OS Update
    ED-->>AN: Acknowledge Provisioning
    AN-->>GW: Acknowledge Provisioning
    GW-->>CS: Acknowledge Provisioning
    CS->>GW: Send Application Data (Micro-App)
    GW->>AN: Relay Application Data
    AN->>ED: Deploy Micro-App
    ED->>ED: Begin Execution (Low Power Mode)
    ED->>AN: Sensor Data (Event Trigger)
    AN->>GW: Aggregated Data
    GW->>CS: Upload Data

---

3. Cross-Domain Application

Derivative 3.1: Autonomous Agricultural Robot Fleet Management (AgTech)

Enabling Description: The system is applied to manage an N-tier computing environment for an autonomous agricultural robot fleet. The "initial user specification" (1a) defines an N-tier environment comprising: Tier 1 - Edge processing units on individual robots for real-time sensor data analysis (e.g., crop health, soil conditions); Tier 2 - A local field station server for fleet coordination, path planning optimization, and data aggregation; and Tier 3 - A cloud-based analytics platform for long-term data storage, machine learning model training, and agricultural insights. The "initializing event" (1b) involves deploying software stacks (e.g., ROS 2, custom AI models) to the robot's edge processors, configuring communication protocols (e.g., 5G, LoRa) between robots and the field station, and establishing secure data pipelines to the cloud. The "application data" (1c) includes updated navigation maps, new crop-specific AI models for disease detection, and optimized work schedules, which cause the robots to commence autonomous field operations and data collection.

graph TD
    A[User Spec (Agri-Robot N-Tier)] --> B(Central Control System - Cloud)
    B -- Config/Deploy --> C[Cloud Analytics Platform (Tier 3)]
    B -- Config/Deploy --> D[Field Station Server (Tier 2)]
    D -- Config/Deploy --> E[Autonomous Robots (Tier 1 - Edge)]
    E -- Sensor Data --> D
    D -- Aggregated Data --> C
    C -- ML Models/Maps --> D
    D -- Tasks/Updates --> E
    subgraph Agricultural Domain
        C
        D
        E
    end

Derivative 3.2: Smart City Infrastructure Management for Emergency Response (Public Safety)

Enabling Description: This derivative applies the system to manage N-tier environments for smart city emergency response infrastructure. The "initial user specification" (1a) defines an N-tier environment for a specific urban sector, including: Tier 1 - Distributed IoT sensors (e.g., traffic cameras, air quality, acoustic sensors) and edge gateways for immediate event detection; Tier 2 - A localized emergency operations center (EOC) server for real-time data fusion, incident correlation, and resource allocation; and Tier 3 - A city-wide cloud platform for historical data analysis, predictive modeling of incident spread, and long-term planning. The "initializing event" (1b) triggers the deployment of real-time analytics modules to edge gateways, configuration of secure, low-latency communication networks (e.g., CBRS, dedicated fiber) to the EOC, and instantiation of incident management dashboards in the cloud. The "application data" (1c) consists of updated emergency protocols, AI models for predicting crowd movement, and optimized dispatch algorithms, which cause the integrated system to monitor for incidents and activate automated response sequences.

flowchart LR
    A[User Spec (Emergency N-Tier)] --> B(City Management Platform)
    B -- Deploy/Config --> C[Cloud Platform (Tier 3)]
    B -- Deploy/Config --> D[EOC Server (Tier 2)]
    D -- Config Edge --> E[Edge Gateways (Tier 1)]
    E -- Connect --> F[IoT Sensors (Traffic, Environmental)]
    F --> E
    E -- Real-time Data --> D
    D -- Incident Alerts --> C
    C -- Predictive Models --> D
    D -- Action Directives --> E
    subgraph Smart City Emergency Response
        C
        D
        E
        F
    end

Derivative 3.3: Personalized Adaptive Learning Platform for Educational Technology (EdTech)

Enabling Description: The system is used to create and manage N-tier environments for personalized adaptive learning platforms. The "initial user specification" (1a) outlines an N-tier environment composed of: Tier 1 - Client-side interfaces (web/mobile apps) running on student devices; Tier 2 - A regional learning management system (LMS) server for course content delivery, progress tracking, and student interaction management; and Tier 3 - A central AI-driven personalization engine in the cloud for adaptive content recommendation, performance analytics, and curriculum optimization. The "initializing event" (1b) involves provisioning and configuring the LMS server, deploying client-side application bundles to student devices (via managed device programs or app stores), and setting up secure APIs between tiers. The "application data" (1c) comprises updated course materials, new adaptive learning algorithms, and individualized learning paths, which cause the platform to deliver tailored educational content and dynamically adjust to student performance.

sequenceDiagram
    participant S as Student Device (Tier 1)
    participant LMS as Regional LMS Server (Tier 2)
    participant AI as Cloud AI Engine (Tier 3)
    participant I as Instructor/Admin

    I->>AI: Initial User Spec (Adaptive Learning N-Tier)
    AI->>LMS: Send Initializing Event (LMS Setup)
    LMS->>AI: Acknowledge Configuration
    AI->>S: Push Client App Bundle (via App Store/MDM)
    S->>S: Install Learning App
    AI->>LMS: Send Application Data (Course Content/Adaptive Algos)
    LMS->>S: Deliver Personalized Content
    S->>LMS: Student Interaction/Performance Data
    LMS->>AI: Aggregate Student Data
    AI->>AI: Optimize Learning Paths/Algos
    AI->>LMS: Update Recommendations

---

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Optimization with Real-Time IoT Monitoring and Blockchain for Compliance

Enabling Description: This derivative integrates RE48633's core method with advanced technologies. The "initial user specification" (1a) defines an N-tier industrial control environment. The "initializing event" (1b) deploys the infrastructure, including microservices for process control, data ingestion, and predictive maintenance. AI-driven optimization agents are then deployed as "application data" (1c), continuously monitoring system performance, resource utilization, and operational parameters. These agents leverage IoT sensors for real-time data input from physical machinery, feeding metrics into a streaming analytics pipeline. Anomalies detected by the AI trigger automated scaling or reconfiguration of the N-tier environment. Crucially, all deployment events, configuration changes, and AI-driven adjustments are cryptographically signed and recorded on a private blockchain for immutable auditing and supply chain verification of software components and sensor data provenance, ensuring regulatory compliance and trustworthiness in high-stakes environments (e.g., pharmaceutical manufacturing, critical infrastructure).

graph LR
    A[User Spec (N-Tier Industrial Control)] --> B(Cloud Orchestrator)
    B -- Provision Infra --> C[N-Tier Environment (Microservices)]
    C -- Deploy AI Agents --> D[AI Optimization Layer]
    C -- Data Stream --> E[IoT Sensor Network]
    E -- Real-time Data --> D
    D -- Optimized Params/Actions --> C
    D -- Audit Log --> F[Blockchain Network (Immutable Ledger)]
    C -- Event Log --> F
    F --> G[Compliance/Verification Service]
    subgraph Integrated Ecosystem
        D
        E
        F
        G
    end

---

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation and Limited-Functionality Mode for Critical Infrastructure

Enabling Description: This derivative focuses on designing the N-tier system for controlled failure and limited functionality, crucial for critical infrastructure (e.g., energy grids, telecommunications). The "initial user specification" (1a) includes not only the standard N-tier configuration but also a set of predefined "degradation profiles" and "limited-functionality modes" for each tier. The "initializing event" (1b) establishes the robust N-tier environment, but also deploys a dedicated "failure mode controller" and pre-configures fallback mechanisms. When a critical fault or resource exhaustion is detected (e.g., 80% CPU utilization across a tier, network partition), the system automatically triggers a degradation profile. This could involve shedding non-essential services, rerouting traffic to lower-capacity but highly resilient backup nodes, or switching to a read-only or minimum-viable-functionality mode. The "application data" (1c) for these modes might be highly optimized, lightweight versions of critical services, ensuring core functionality (e.g., emergency communication, essential data logging) remains operational even under severe stress, while non-critical operations are paused or terminated safely.

stateDiagram-v2
    [*] --> Healthy_Operational
    Healthy_Operational --> Moderate_Degradation: High Resource Use / Minor Fault
    Moderate_Degradation --> Critical_Degradation: Major Fault / Resource Exhaustion
    Critical_Degradation --> Limited_Functionality: Catastrophic Failure
    Limited_Functionality --> Safe_Shutdown: Sustained Criticality
    Safe_Shutdown --> [*]

    state Healthy_Operational {
        label: Full Service Availability
        Operational_Mode: Standard Application Data
    }
    state Moderate_Degradation {
        label: Non-Essential Services Shed
        Operational_Mode: Reduced Application Data
        Entry: Activate Degradation Profile 1
    }
    state Critical_Degradation {
        label: Core Services Only, Rerouting
        Operational_Mode: Minimal Application Data
        Entry: Activate Degradation Profile 2
    }
    state Limited_Functionality {
        label: Read-Only / Emergency Mode
        Operational_Mode: Essential Application Data Only
        Entry: Activate Limited-Functionality Profile
    }
    state Safe_Shutdown {
        label: Controlled Termination
        Operational_Mode: Data Preservation/Standby
    }

---

Combination Prior Art Scenarios

Here are three combination prior art scenarios where the core invention of US Patent RE48633 is combined with existing open-source standards to demonstrate obviousness or lack of novelty for future incremental improvements.

1. RE48633 + OpenStack + Puppet/Ansible

• Scenario: A system for creating and managing a virtualized computing system in a private cloud environment using OpenStack as the infrastructure-as-a-service (IaaS) platform, combined with configuration management tools like Puppet or Ansible for automated software deployment and configuration.
• Combination Logic:
  • RE48633 Claim 1(a) (Determining initial cloud environment): The "initial user specification" is analogous to an OpenStack Heat template or a Terraform configuration file that defines an N-tier environment (e.g., compute instances, networks, storage volumes) within an OpenStack private cloud. This environment is not yet instantiated.
  • RE48633 Claim 1(b) (Sending initializing event for configuration): The "initializing event" is the deployment action within OpenStack (e.g., heat stack-create or terraform apply), which causes OpenStack services (Nova, Neutron, Cinder) to provision the virtual infrastructure. Once the VMs are available, an event triggers Puppet or Ansible to connect to these VMs and apply system-level and application-level configurations (e.g., installing web servers, database software, setting up firewall rules). This makes the "initial cloud environment configuration" available.
  • RE48633 Claim 1(c) (Sending application data for execution): After the configuration management tools have prepared the environment, Puppet or Ansible can be used to deploy the "application data" (e.g., application binaries, web content, database schemas, environment variables) directly to the configured VMs, initiating the application's execution. Alternatively, a CI/CD pipeline integrated with Puppet/Ansible would push the application artifacts.
• Obviousness Argument: For a PHOSITA in 2010 (priority date of original patent) or even 2018 (reissue filing date), using an IaaS platform like OpenStack for automated VM provisioning and then using established configuration management tools like Puppet (available since 2005) or Ansible (available since 2012, but concepts were present earlier in tools like Cfengine, Bcfg2) to configure and deploy applications to those VMs would have been a well-known and obvious practice. The combination would yield the predictable result of an automated end-to-end cloud deployment.

2. RE48633 + Apache Mesos + Marathon

• Scenario: A system for creating and managing a containerized N-tier computing system using Apache Mesos for resource management and Marathon (a Mesos framework) for orchestrating long-running containerized applications.
• Combination Logic:
  • RE48633 Claim 1(a) (Determining initial cloud environment): The "initial user specification" defines an N-tier application structure as a Marathon application definition (JSON/YAML), specifying required Docker container images, resource constraints (CPU, RAM), network ports, and scaling rules. This defines an N-tier environment that is not yet instantiated on the Mesos cluster.
  • RE48633 Claim 1(b) (Sending initializing event for configuration): The "initializing event" is submitting the Marathon application definition to the Mesos/Marathon cluster. Marathon, acting as a scheduler, requests resources from Mesos. Mesos grants offers, and Marathon then launches the specified Docker containers on available Mesos agents. This process makes the "initial cloud environment configuration" (i.e., the running container instances with their defined network and storage) available.
  • RE48633 Claim 1(c) (Sending application data for execution): The "application data" is inherently part of the specified Docker container images. When Marathon launches these containers, the application code within them immediately begins execution in the newly configured, containerized N-tier environment. This represents sending and executing application data.
• Obviousness Argument: Apache Mesos (developed at UC Berkeley in 2009, open-sourced in 2010) and Marathon (released 2013) were established open-source projects providing robust container orchestration. For a PHOSITA familiar with cloud orchestration and containerization by the reissue filing date, combining a resource manager (Mesos) with an application orchestrator (Marathon) to define, provision, and deploy containerized N-tier applications would have been a straightforward and obvious extension of existing patterns, leading directly to the claimed method.

3. RE48633 + Cloud-init + Bash Scripting

• Scenario: A basic, yet widely used, method for automatically configuring virtual machines and deploying applications using cloud-init for initial instance setup and standard Bash shell scripting for application deployment.
• Combination Logic:
  • RE48633 Claim 1(a) (Determining initial cloud environment): The "initial user specification" is a cloud provider's API call or a cloud formation template (e.g., AWS EC2, OpenStack Nova) that requests an N-tier set of virtual machines with specific operating system images. The "user data" field within this request contains a cloud-init script. This defines an uninstantiated N-tier environment.
  • RE48633 Claim 1(b) (Sending initializing event for configuration): The "initializing event" is the instance launch request. When the VMs boot, cloud-init (an open-source package present in most cloud images since the early 2010s) executes the user-provided script. This script performs the "initial cloud environment configuration" by installing necessary software packages (e.g., web server, database), configuring network settings, creating user accounts, and setting up file systems.
  • RE48633 Claim 1(c) (Sending application data for execution): The cloud-init script or a subsequent Bash script (invoked by cloud-init or a separate SSH command) contains commands to download (e.g., wget, curl, git clone) and install/start the "application data" (e.g., pulling code from a repository, compiling, running daemon processes). This causes the application to begin execution in the configured N-tier environment.
• Obviousness Argument: Cloud-init was widely adopted by major cloud providers by 2010-2012, and Bash scripting for server automation has been ubiquitous for decades. The practice of spinning up VMs with cloud-init to perform initial setup, followed by scripts to fetch and execute application code, was a fundamental and obvious pattern for automating cloud deployments long before the reissue patent's filing date. This combination clearly anticipates or renders obvious the broad steps of RE48633.