PTAB

IPR2025-00965

Oracle Corporation v. VirtaMove, Corp.

Log In

1. Case Identification

2. Patent Overview

  • Title: System for Containerization of Application Sets
  • Brief Description: The ’814 patent discloses a system for isolating software applications into "secure containers" on a server. This containerization allows applications to run in distinct environments with their own associated system files while sharing the underlying operating system (OS) kernel, aiming to avoid resource conflicts and the performance overhead of traditional virtual machines.

3. Grounds for Unpatentability

Ground 1: Claims 1-34 are obvious over Schmidt-479 in view of Tormasov.

  • Prior Art Relied Upon: Application # 20020095479 (Schmidt-479), Application # 20020124072 (Tormasov).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Schmidt-479 teaches portable "compute capsules" that encapsulate an active computing environment, including applications and necessary system files, allowing them to be stored and moved between servers. Tormasov was argued to teach lightweight "virtual computing environments" (VCEs) that provide isolated, full-featured OS functionality (e.g., unique file systems, independent processes) while sharing a single host OS kernel, overcoming the overhead of full hardware emulation. The combination of these references, Petitioner contended, discloses all limitations of the challenged claims, including storing secure, kernel-less containers on a plurality of servers with differing operating systems.
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine Tormasov’s VCEs with Schmidt-479’s capsule technology to make the robust, isolated VCEs easily portable and deployable across a multi-server system. This combination would achieve both the comprehensive isolation of Tormasov and the seamless mobility of Schmidt-479. Petitioner further argued a POSITA would be motivated to deploy these combined VCE-capsules on servers running different OS versions within the same family (e.g., Solaris 8 and Solaris 10) to support application portability in common enterprise environments.
    • Expectation of Success: A POSITA would have a reasonable expectation of success because both references teach compatible techniques operating on conventional OSs (e.g., Unix, Linux). The concepts of virtual namespaces, isolated file system views, and sharing a common kernel are overlapping and complementary, making their integration a matter of ordinary programming skill.

Ground 2: Claims 1-34 are obvious over Schmidt-479 and Tormasov in view of Calder.

  • Prior Art Relied Upon: Schmidt-479, Tormasov, and Application # 20020066022 (Calder).

  • Core Argument for this Ground:

    • Prior Art Mapping: This ground builds upon the Schmidt-Tormasov combination from Ground 1. Petitioner argued that Calder teaches techniques to make an application package executable on non-native OS platforms by modifying its system files (e.g., libraries) to translate system calls. For example, Calder teaches how to make a Windows-native application run on a Unix-based OS.
    • Motivation to Combine: A POSITA would be motivated to apply Calder's teachings to the VCE-capsules of the Schmidt-Tormasov combination to make them executable across servers running different OS families (e.g., Windows and Unix), not just different versions of the same family. This would significantly improve application portability and utility in heterogeneous corporate networks, which often contain servers running disparate operating systems.
    • Expectation of Success: A POSITA would reasonably expect success because Calder’s techniques for translating system calls are designed for the same types of conventional operating systems disclosed in Schmidt-479 and Tormasov. Applying Calder's file modification and translation methods to the system files contained within a VCE-capsule would be a predictable extension of the art requiring only ordinary skill.

  • Additional Grounds: Petitioner asserted additional obviousness challenges (Grounds 3 and 4) based on the combinations of Grounds 1 and 2 in further view of Application # 20020138629 (Schmidt-629). Schmidt-629 was argued to teach assigning a unique locator, such as an IP address, to each capsule to facilitate communication and migration across a network, thus rendering obvious claims requiring a unique identity like an IP address (e.g., claims 5, 6, 31).

4. Key Claim Construction Positions

  • Petitioner noted that key terms are subject to competing constructions in a co-pending district court case but argued that the claims are unpatentable under either party's proposed constructions.
  • The petition primarily mapped the prior art to the parties' joint construction of the term "container," defined as "[a]n aggregate of files required to successfully execute a set of software applications on a computing platform," where "[e]ach container for use on a server is mutually exclusive of the other containers, such that read/write files within a container cannot be shared with other containers." Petitioner argued the "VCE-capsules" of the combined prior art meet both prongs of this construction.

5. Arguments Regarding Discretionary Denial

  • Petitioner argued that discretionary denial is unwarranted because it concurrently filed a Motion for Joinder with a previously filed IPR by Google (IPR2025-00488) challenging the same patent. Petitioner contended that if joined, it would take an "understudy role," which would not impact the Board's finite resources or present fairness concerns.

6. Relief Requested

  • Petitioner requests the Board institute an inter partes review and cancel claims 1-34 of Patent 7,519,814 as unpatentable.