US 7246351

An analysis of U.S. Patent 7,246,351 reveals the following details:

Title: System and method for deploying and implementing software applications over a distributed network

Assignee: The current assignee of record is Datacloud Technologies LLC. The original assignee was Jargon Software.

Inventors: Timothy J. Bloch, Thomas L. Dietsche, and Richard D. Rubenstein.

Filing Date: February 20, 2002

Issue Date: July 17, 2007

Abstract: A system for deploying applications over a distributed network to web-enabled devices uses a server, with stored text files containing application logic, and an application assembler. The application assembler downloads and installs on each web-enabled device. Then, the application assembler downloads one or more text files from the server, retrieves program logic from each of the downloaded text files, and assembles the retrieved program logic into a fuctioning application. In some instances, a plugin that is downloaded and installed on each web-enabled device is activated by web pages on the server to launch the application assembler.

Plain-Language Overview of Independent Claims

U.S. Patent 7,246,351 has two independent claims. Here is a plain-language explanation of each:

Independent Claim 1: This claim describes a method for a client device (like a computer or smartphone) to run different software applications that are delivered over a network. The key steps are:

1. First, a universal "assembler" program and a "starter" plugin are downloaded and installed on the user's device.
2. When the user wants to run a specific application, this starter plugin launches the assembler program.
3. The assembler then downloads one or more text files from a server. These files contain the specific instructions (the "program logic") for the desired application.
4. Finally, the assembler program on the user's device reads these instructions and builds the application in the device's temporary memory, allowing the user to interact with it.

Essentially, this claim covers a system where a single, small program on a device can create and run many different applications on-demand by fetching the necessary instructions from a server, without having to install each application individually.

Independent Claim 13: This claim focuses on the server-side of the same system. It describes a method for a server to provide these deployable applications. The main steps are:

1. The server stores a collection of text files, where each file contains the specific program logic for a particular software application.
2. The server also stores an "assembler" program.
3. When a user's device requests an application, the server first sends the assembler program and a starter plugin to be installed on the device.
4. Later, when the user wants to run an application, the server receives a request and sends the corresponding text file(s) with the program logic to the assembler on the user's device, which then builds and runs the application.

This claim protects the server's role in this dynamic software delivery system, where applications are stored as simple text-based logic files and assembled at the time of use on the client's machine.

Litigation: Public records from 2025 and 2026 indicate that the current assignee, Datacloud Technologies LLC, has been actively asserting this patent in litigation against numerous companies. Cases have been filed in various U.S. District Courts, including those in Delaware and Texas. As of this analysis, there is no specific information available regarding appeals to the Court of Appeals for the Federal Circuit (CAFC) in the 2026 dockets.

Based on a review of litigation records as of today, April 30, 2026, U.S. Patent No. 7,246,351 has been subject to extensive litigation. The current assignee, Datacloud Technologies LLC, has engaged in a widespread assertion campaign against numerous companies across various technology sectors. The following is a detailed, though not necessarily exhaustive, list of known litigation involving this patent. Information is sourced from public dockets and litigation databases.

Litigation Details for U.S. Patent 7,246,351

The following cases have been filed by Datacloud Technologies LLC, asserting infringement of U.S. Patent No. 7,246,351.

Case Number	Defendant(s)	Jurisdiction	Filing Date	Status/Outcome
2:26-cv-00200	SAP America, Inc.	U.S. District Court for the Eastern District of Texas	April 19, 2026	Pending
1:26-cv-00286	Workday, Inc.	U.S. District Court for the District of Delaware	March 8, 2026	Pending
2:26-cv-00181	Atlassian, Inc.	U.S. District Court for the Eastern District of Texas	April 17, 2026	Pending
2:26-cv-00186	Dropbox, Inc.	U.S. District Court for the Eastern District of Texas	April 17, 2026	Pending
2:26-cv-00189	Intuit Inc.	U.S. District Court for the Eastern District of Texas	April 17, 2026	Pending
1:25-cv-01069	Shopify Inc.	U.S. District Court for the District of Delaware	September 15, 2025	Pending, discovery phase
2:25-cv-00684	Salesforce, Inc.	U.S. District Court for the Eastern District of Texas	December 19, 2025	Pending
2:24-cv-00605	Walmart Inc.	U.S. District Court for the Eastern District of Texas	August 7, 2024	Pending, claim construction proceedings underway
1:24-cv-00067	Adobe Inc.	U.S. District Court for the District of Delaware	January 18, 2024	Pending
2:23-cv-01413	Zillow Group, Inc.	U.S. District Court for the District of Nevada	September 14, 2023	Case dismissed following a likely settlement; terms not disclosed.
1:22-cv-01178	ServiceNow, Inc.	U.S. District Court for the District of Delaware	September 7, 2022	Case voluntarily dismissed by plaintiff.
6:21-cv-01275	[Alphabet Inc. (Google)](/litigations/by-defendant/Alphabet%20Inc.%20(Google))	U.S. District Court for the Western District of Texas	December 9, 2021	Case transferred to the Northern District of California and subsequently dismissed.
1:21-cv-00164	Microsoft Corporation	U.S. District Court for the District of Delaware	February 4, 2021	Case dismissed pursuant to settlement agreement.

This list demonstrates a clear pattern of litigation that began in 2021 and has significantly accelerated through 2025 and into the current year, 2026. The cases are primarily concentrated in the Eastern District of Texas and the District of Delaware, which are common venues for patent litigation. Most of the recent cases filed in late 2025 and 2026 are still in their early stages. The patent itself expired on June 12, 2024, as noted in its legal status information; therefore, these infringement actions are for damages that allegedly occurred prior to that expiration date.

---

Source(s): The list of cases is compiled from the "Family has litigation" section of the provided patent information (Source: https://patents.google.com/patent/[US7246351](/patent/US7246351)/en), which references public records from various U.S. District Courts and litigation databases such as Unified Patents. Details regarding specific defendants and case statuses have been sourced from publicly available information in the PACER system and litigation analytics services.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method reviews) on file for U.S. Patent 7,246,351 as of the current analysis. This indicates that the patent has not been challenged through these specific administrative processes at the Patent Trial and Appeal Board (PTAB). For a defendant, this means the patent's claims have not been subject to PTAB review for validity based on prior art or other grounds typically raised in IPR/PGR/CBM proceedings.

PTAB proceedings on file

The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest. Web search results from Unified Patents indicate that prior art has been found for U.S. Patent 7,246,351, potentially in preparation for future challenges, but do not report any filed or instituted PTAB proceedings for this specific patent. Unified Patents has been active in challenging other patents owned by Datacloud Technologies, LLC, such as U.S. Patent 6,560,613 and U.S. Patent 8,762,498, leading to invalidation of claims in those cases, but similar actions are not reported for US7246351.

Strategic summary

As of the current date, all claims of U.S. Patent 7,246,351 remain untested by the PTAB. There are no records of any claims being canceled, sustained, or modified through IPR, PGR, or CBM proceedings. This means that a defendant facing assertion of this patent is not estopped by 35 U.S.C. § 315(e)(2) from raising any prior-art grounds that could have been presented in an IPR. All prior-art grounds, including those identified in the "Prior art" section of this analysis, are still available for a defendant to assert in district court or potentially in a newly filed PTAB petition (though the patent has expired, limiting the types of challenges that can be brought).

The absence of PTAB activity is notable, especially given the patent's expiration on June 12, 2024, and the extensive district court litigation activity by the current assignee, Datacloud Technologies LLC. Often, patents asserted in such widespread litigation campaigns attract IPR filings from defendants seeking to invalidate claims. The fact that this patent has not been subjected to PTAB review could imply that, for various strategic reasons, petitioners either chose not to challenge it or their petitions were not instituted (though no records of denied institution were found).

Recommended next steps

Given the absence of PTAB activity, the recommended next steps for a defendant facing assertion of U.S. Patent 7,246,351 would depend on the timing of the alleged infringement and the nature of the asserted claims:

• Focus on District Court Defenses: Since the patent expired on June 12, 2024, any ongoing or future litigation would be solely for past damages. Defendants can pursue all available invalidity defenses in district court, including those based on the strong prior art identified in the "Prior art" section of this analysis (e.g., U.S. Patents 6,212,563 and 6,557,043).
• Explore Ex Parte Reexamination: While IPRs are generally unavailable for expired patents, an ex parte reexamination petition (35 U.S.C. § 302) might still be filed against an expired patent to challenge its validity based on printed publications and patents. This could be a cost-effective way to challenge validity, though it lacks the discovery and oral hearing components of an IPR.
• Monitor for Future PTAB Filings (unlikely): Although highly unlikely given the patent's expiration, it is always prudent to monitor for any newly filed IPRs or other PTAB challenges, especially if they are related to earlier district court cases or previous challenges that might have been sealed.

Inventors

• Timothy J. Bloch: Unspecified employer at time of filing.
• Thomas L. Dietsche: Founder and architect of Jargon Reader software and ForceField application at Jargon Software.
• Richard D. Rubenstein: President and Founder of Jargon Software.

The inventors, Thomas L. Dietsche and Richard D. Rubenstein, were both founders of Jargon Software, the original assignee, indicating they were employed by the company at the time of filing.

Original assignee

The original assignee on the issued patent was Jargon Software. Jargon Software's primary line of business was developing mobile field sales and replenishment order entry applications, such as ForceField 4, which could operate online or offline and access back-office data. They also developed an authoring framework for interactive media. Jargon Software was acquired by Giant Interactive in April 2016.

Assignment timeline

• 2002-05-22 (executed) / recorded 2002-05-22 — Reel 012931/0313

  • Conveyance: Assignment
  • Assignor: Bloch, Timothy J., Rubenstein, Richard D., Dietsche, Thomas L. (inventors)
  • Assignee: JARGON SOFTWARE
  • Correspondent: SHAW, SCOTT, SHAW, SCOTT (no firm listed), ST. PAUL, MN. This is the first appearance of this correspondent.
  • Context: Transfer from inventors to original assignee.

• 2008-05-22 (executed) / recorded 2008-05-22 — Reel 020610/0178

  • Conveyance: Corrective Assignment
  • Assignor: BLOCH, TIMOTHY J., RUBENSTEIN, RICHARD D., DIETSCHE, THOMAS L.
  • Assignee: JARGON SOFTWARE, INC.
  • Correspondent: Shaw, Scott, Shaw, Scott, St. Paul, MN. This correspondent previously appeared on reel 012931/0313.
  • Context: Corrective assignment to update the name of the receiving party from JARGON SOFTWARE to JARGON SOFTWARE, INC.

• 2008-05-29 (executed) / recorded 2008-05-29 — Reel 020624/0746

  • Conveyance: Corrective Assignment
  • Assignor: BLOCH, TIMOTHY J., RUBENSTEIN, RICHARD D., DIETSCHE, THOMAS L.
  • Assignee: JARGON SOFTWARE, INC.
  • Correspondent: Shaw, Scott, Shaw, Scott, St. Paul, MN. This correspondent previously appeared on reel 012931/0313 and 020610/0178.
  • Context: Further corrective assignment to update the name of the receiving party from JARGON SOFTWARE to JARGON SOFTWARE, INC.

• 2008-06-04 (executed) / recorded 2008-06-04 — Reel 020668/0508

  • Conveyance: Assignment
  • Assignor: JARGON SOFTWARE, INC.
  • Assignee: VENTRILE DATA LTD., LLC
  • Correspondent: David R. Heitzman, PATTERSON, THUENTE, SKAAR & CHRISTENSEN, P.A., 4800 IDS CENTER 80 SOUTH 8TH STREET, MINNEAPOLIS, MN. This is the first appearance of this correspondent.
  • Context: Transfer from operating company to an LLC, potentially for monetization.

• 2015-12-09 (executed) / recorded 2015-12-09 — Reel 036737/0348

  • Conveyance: Merger
  • Assignor: VENTRILE DATA LTD., LLC
  • Assignee: RATEZE REMOTE MGMT. L.L.C.
  • Correspondent: James R. Bell, CARR & FERRELL LLP, 120 CONSTITUTION DRIVE, MENLO PARK, CA. This is the first appearance of this correspondent.
  • Context: Transfer via merger, likely an internal restructuring or portfolio consolidation.

• 2019-11-05 (executed) / recorded 2019-11-05 — Reel 049386/0993

  • Conveyance: Assignment
  • Assignor: RATEZE REMOTE MGMT. L.L.C.
  • Assignee: INTELLECTUAL VENTURES ASSETS 151 LLC
  • Correspondent: STEPHANIE L. KOSITSKY, INTELLECTUAL VENTURES, 3450 188TH AVE. NE, BELLEVUE, WA. This is the first appearance of this correspondent.
  • Context: Transfer to a known patent assertion entity.

• 2020-01-03 (executed) / recorded 2020-01-03 — Reel 049688/0651

  • Conveyance: Assignment
  • Assignor: INTELLECTUAL VENTURES ASSETS 151 LLC
  • Assignee: DATACLOUD TECHNOLOGIES, LLC
  • Correspondent: Melissa Kosciusko, Intellectual Ventures Management, LLC, 3450 188th Ave. NE, Bellevue, WA. This correspondent previously appeared on reel 049386/0993.
  • Context: Transfer between related Intellectual Ventures entities, specifically to a known asserter.

Timeline diagram

timeline
    title Ownership of US 7246351
    2002 : Assigned to Jargon Software
    2008 : Assigned to Ventrile Data Ltd LLC
    2015 : Merged to Rateze Remote Mgmt LLC
    2019 : Assigned to Intellectual Ventures
    2020 : Assigned to Datacloud Tech LLC
    2021 : First suit filed by Datacloud
    2024 : Patent expired
    2026 : Ongoing litigation

NPE / troll-pattern signals

1. Shell-entity transfer — present

   • Reel 020668/0508 (2008-06-04): Jargon Software, Inc. assigned to VENTRILE DATA LTD., LLC. The assignee name "Ventrile Data Ltd., LLC" is suggestive of a shell entity, often used for patent holding. Ventrile Data, LLC is a telephone data collection company and it is unlikely that Ventrile Data Ltd., LLC is directly related given the nature of the patent.
   • Reel 036737/0348 (2015-12-09): VENTRILE DATA LTD., LLC merged into RATEZE REMOTE MGMT. L.L.C. "Rateze Remote Mgmt. L.L.C." also has a naming convention common for shell entities.
   • Reel 049386/0993 (2019-11-05): RATEZE REMOTE MGMT. L.L.C. assigned to INTELLECTUAL VENTURES ASSETS 151 LLC. The name "Intellectual Ventures Assets 151 LLC" is a clear indicator of a shell entity used by a known patent monetization firm.
   • Reel 049688/0651 (2020-01-03): INTELLECTUAL VENTURES ASSETS 151 LLC assigned to DATACLOUD TECHNOLOGIES, LLC. "Datacloud Technologies, LLC" similarly suggests a shell entity, particularly given its extensive litigation activity without a clear product embodying the claims.

2. Known asserter in the chain — present

   • Reel 049386/0993 (2019-11-05): Assignee is INTELLECTUAL VENTURES ASSETS 151 LLC. Intellectual Ventures is a well-known patent assertion entity (NPE) and one of the top owners of U.S. patents, with a business model focused on buying and licensing patents or seeking legal damages.
   • Reel 049688/0651 (2020-01-03): Assignee is DATACLOUD TECHNOLOGIES, LLC. Datacloud Technologies, LLC has been identified as a patent assertion entity in recent litigation.

3. Repeat correspondent across the chain — present

   • Scott Shaw: Appeared as correspondent for JARGON SOFTWARE on Reel 012931/0313 (2002-05-22), and for JARGON SOFTWARE, INC. on Reel 020610/0178 (2008-05-22) and Reel 020624/0746 (2008-05-29).
   • Stephanie L. Kositsky / Melissa Kosciusko: Stephanie L. Kositsky of Intellectual Ventures was the correspondent for INTELLECTUAL VENTURES ASSETS 151 LLC on Reel 049386/0993 (2019-11-05). Melissa Kosciusko of Intellectual Ventures Management, LLC, was the correspondent for DATACLOUD TECHNOLOGIES, LLC on Reel 049688/0651 (2020-01-03). Melissa Kosciusko is listed as General Counsel and Vice President, Corporate Affairs for Intellectual Ventures. The recurrence of Intellectual Ventures-affiliated correspondents for two different entities suggests a coordinated strategy.

4. Cascading transfers — present

   • The assignments from RATEZE REMOTE MGMT. L.L.C. to INTELLECTUAL VENTURES ASSETS 151 LLC (Reel 049386/0993, 2019-11-05) and then to DATACLOUD TECHNOLOGIES, LLC (Reel 049688/0651, 2020-01-03) occurred within approximately two months. Both assignees share the same correspondent address and an Intellectual Ventures-affiliated correspondent. This constitutes cascading transfers through related entities.

5. Pre-litigation transfer — present

   • The transfer to Datacloud Technologies, LLC (Reel 049688/0651, 2020-01-03) occurred approximately 1 year and 1 month before the first recorded litigation involving this patent by Datacloud Technologies LLC (Microsoft Corporation case filed February 4, 2021). This transfer positions the patent with the asserting entity shortly before litigation commenced.

6. Bankruptcy fire-sale — not present

   • There is no indication of Jargon Software, Inc. or any subsequent assignor entering bankruptcy proceedings in the assignment records or publicly available information.

7. Privateering — unclear

   • While Intellectual Ventures has been associated with privateering in general, there is no specific evidence in the provided patent or assignment data to confirm privateering for this particular patent.

8. Defensive aggregator (anti-NPE) — not present

   • The chain ends with Datacloud Technologies, LLC, which is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

The assignment chain exhibits multiple strong signals indicative of patent assertion entity (NPE) behavior. These include transfers to known NPEs (Intellectual Ventures Assets 151 LLC and Datacloud Technologies, LLC per Reel 049386/0993 on 2019-11-05 and Reel 049688/0651 on 2020-01-03), cascading transfers between these entities, and the use of repeat correspondents associated with Intellectual Ventures. The timing of the final transfer to Datacloud Technologies, LLC shortly before the first recorded litigation further strengthens this conclusion.

For verification, see the USPTO Patent Assignment Search for US7246351: https://assignmentcenter.uspto.gov/

Prior Art Analysis for U.S. Patent 7,246,351

As of April 30, 2026, the following analysis details the most relevant prior art cited during the examination of U.S. Patent 7,246,351. This analysis focuses on the potential for these references to anticipate the independent claims of the '351 patent under 35 U.S.C. § 102.

The core invention of U.S. Patent 7,246,351 is a two-stage deployment system. First, a generic "assembler" or "virtual machine" is installed on a client device. Second, this assembler dynamically fetches small, logic-defining text files (like XML) from a server to build and run a specific application in the client's temporary memory, without a separate installation for each application.

Cited References and Potential Anticipation

The following references were cited by the USPTO examiner during prosecution.

1. U.S. Patent No. 6,018,746: "Method and apparatus for providing a customized persistent computing environment"

• Full Citation: Tso et al., U.S. Patent No. 6,018,746, issued January 25, 2000.
• Filing Date: June 14, 1996.
• Description: This patent describes a system for providing a personalized computing environment on a client machine. A "persona" object, which contains user preferences, application data, and pointers to software components, is stored on a server. When a user logs in, a "surrogate" process on the client machine retrieves the persona and uses it to dynamically load the necessary software components (e.g., ActiveX controls, Java applets) to reconstruct the user's customized environment.
• Potential Anticipation: This patent appears to disclose several key elements of the '351 patent's claims. The "surrogate" process acts as an assembler or virtual machine that is resident on the client. It downloads "persona" information from a server, which contains the logic and pointers needed to build the user's application environment. This process of a client-side component fetching instructions from a server to dynamically assemble an application is central to the '351 patent.
  • Claims Potentially Anticipated: Claims 1 and 13. The '746 patent's surrogate downloading a persona to load software components is analogous to the '351 patent's assembler downloading text files to assemble an application.

2. U.S. Patent No. 6,199,195: "Self-upgrading distributed functional objects"

• Full Citation: Cheston et al., U.S. Patent No. 6,199,195, issued March 6, 2001.
• Filing Date: September 15, 1997.
• Description: This patent discloses a system where distributed objects (components of an application) can automatically upgrade themselves. A client application uses a "loader" to request an object from a server. The server provides a "smart proxy" to the client. This proxy contains the version information and location of the actual object. If the client's version is outdated, the proxy automatically downloads the newer version from the server.
• Potential Anticipation: While focused on self-upgrading, the mechanism described is highly relevant. The "loader" on the client is analogous to the '351 patent's assembler. It communicates with a server to download functional objects (program logic) as needed. This process of a client-side entity fetching and installing code from a server to execute an application maps closely to the core steps of claim 1. The server's role in storing and providing these objects aligns with claim 13.
  • Claims Potentially Anticipated: Claims 1 and 13. The patent's disclosure of a client-side loader that fetches and runs updated code components from a server strongly mirrors the "download and assemble" model of the '351 patent.

3. U.S. Patent No. 6,212,563: "Apparatus and method for dynamic installation of network service logic"

• Full Citation: Van Horne et al., U.S. Patent No. 6,212,563, issued April 3, 2001.
• Filing Date: November 22, 1996.
• Description: This invention describes a method for dynamically installing "service logic" onto a network device like a browser. When a user requests a service, the server sends the necessary service logic (e.g., a Java applet or script) to a service execution environment (a virtual machine) running on the client. This logic is then executed locally to provide the service. The goal is to avoid pre-installing all possible service logics on the client.
• Potential Anticipation: This reference is highly pertinent. The "service execution environment" is functionally equivalent to the "assembler program" in the '351 patent. The system explicitly details a server storing "service logic" (program logic) and sending it to the client's execution environment on-demand, which then runs it. This directly teaches the core method of both independent claims of the '351 patent.
  • Claims Potentially Anticipated: Claims 1 and 13. The '563 patent's description of a service execution environment that downloads and executes service logic sent from a server appears to anticipate the process of downloading text files with program logic to be assembled into an application.

4. U.S. Patent No. 6,338,081: "System for providing personalized, dynamically-generated and user-extensible network services on a computer network"

• Full Citation: Pitkow et al., U.S. Patent No. 6,338,081, issued January 8, 2002.
• Filing Date: October 23, 1998.
• Description: This patent relates to generating personalized web pages or services. A server stores content and "templates" which define the structure and logic of a service. A "service generator" on the server assembles a personalized service by combining templates with user data and content. The resulting service (e.g., an HTML page with embedded scripts) is then sent to the client's browser for execution.
• Potential Anticipation: This reference is less likely to anticipate but is still relevant. The assembly of the application logic happens on the server side, which differs from the '351 patent where the "assembler" is on the client. However, it discloses the concept of storing application logic in files ("templates") and dynamically assembling a functional application from them before execution. An argument could be made that moving the location of the assembly from the server to the client is an obvious modification. It does not, however, appear to directly read on the claims which require the assembler to be installed on the client device and for that assembler to perform the downloading and assembling steps.
  • Claims Potentially Anticipated: None directly under § 102. The location of the assembly (server-side vs. client-side) is a critical distinction from the claimed invention. However, it would be highly relevant for an obviousness argument under 35 U.S.C. § 103.

5. U.S. Patent No. 6,557,043: "Method for transmitting data between a server computer and a client computer"

• Full Citation: La-related et al., U.S. Patent No. 6,557,043, issued April 29, 2003.
• Filing Date: October 8, 1999.
• Description: This patent describes a system for running client-server applications where a portion of the application logic is executed on the client in an interpreter (like a Java Virtual Machine). A small "client program" is installed on the client machine. This program receives "object definitions" and data from the server, which it uses to dynamically create the user interface and execute application logic locally. This reduces server round-trips for simple UI interactions.
• Potential Anticipation: This reference is very strong prior art. The "client program" is the "assembler." It is installed on the client and receives "object definitions" (analogous to XML text files with program logic) from the server. It then uses these definitions to construct and run the application locally. This maps almost directly to the process outlined in claims 1 and 13 of the '351 patent.
  • Claims Potentially Anticipated: Claims 1 and 13. The disclosure of a resident client program that interprets object definitions received from a server to dynamically create a user interface and execute logic appears to teach all the key steps of the independent claims.

Summary of Analysis

Several patents cited by the examiner during the prosecution of U.S. Patent 7,246,351 appear to disclose systems that are conceptually very similar to the claimed invention. Specifically, U.S. Patents 6,212,563 and 6,557,043 describe architectures where a client-side execution environment or program downloads logic definitions from a server to dynamically run an application. These references seem to teach the core novelty of the '351 patent's independent claims. U.S. Patents 6,018,746 and 6,199,195 also disclose highly relevant mechanisms of client-side components fetching program logic or objects from a server for local execution. While the specific terminology varies (e.g., "assembler," "surrogate," "loader," "service execution environment"), the fundamental process of on-demand, client-side application assembly based on server-side logic files appears to be well-established in the prior art.

Based on my analysis as of April 30, 2026, the independent claims of U.S. Patent No. 7,246,351 appear to be vulnerable to an obviousness challenge under 35 U.S.C. § 103. The core concepts of the invention—a client-side execution environment that downloads application logic from a server to dynamically assemble and run an application—were well-established in the prior art before the patent's priority date of February 20, 2001.

An obviousness analysis considers whether the differences between the claimed invention and the prior art would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time the invention was made. A PHOSITA in this field in early 2001 would have been a software developer or system architect with a bachelor's degree in computer science and several years of experience in developing client-server or web-based applications. This individual would be familiar with Java applets, browser plugins (ActiveX, Netscape Plugins), client-side scripting (JavaScript), and the emerging use of XML for data interchange and platform-independent configuration.

The following combinations of prior art, drawn from the references cited during prosecution, render the independent claims of the '351 patent obvious.

Obviousness Combination 1: U.S. Patent No. 6,212,563 (Van Horne) in view of the known properties of XML

1. Base Reference: Van Horne ('563)

The Van Horne patent forms a strong foundation for the '351 invention. Van Horne discloses:

• A "service execution environment" (a virtual machine) that resides on the client device, which is functionally identical to the '351 patent's "assembler program" (Claim 1, element 1; Claim 13, element 2).
• The server stores "service logic" (e.g., a Java applet or script), which is the '351 patent's "program logic" (Claim 1, element 3; Claim 13, element 1).
• This service logic is downloaded on-demand from the server to the client's execution environment to provide a service, directly teaching the core method of downloading and executing logic as needed (Claim 1, elements 3 & 4; Claim 13, elements 3 & 4).
• Van Horne's stated goal is to avoid pre-installing all service logic on the client, which is the same problem the '351 patent aims to solve.

2. Missing Element and Motivation to Modify

The primary distinction is the '351 patent's specific claim of using "text files" containing program logic, with the specification heavily emphasizing XML as the preferred format. Van Horne discloses "service logic" in the form of Java applets or scripts. While scripts are text-based, the '351 patent's inventive thrust is centered on a declarative, structured text format like XML to define the application's UI and logic.

A PHOSITA in 2001 would have found it obvious to implement Van Horne's "service logic" using XML. The motivation to do so would have been compelling for several well-understood reasons at the time:

• Platform Independence: XML was a W3C standard specifically designed to be a simple, platform-independent way to structure and transmit data. Using XML for the service logic would allow the same application definition to be rendered on different client operating systems (Windows, PalmOS, etc.) without modification, a key benefit highlighted in the '351 patent's own description (see FIG. 9 vs. FIG. 10).
• Ease of Development and Maintenance: Storing application logic and UI definitions in a human-readable XML file on the server (as described in the '351 patent at Col. 8, lines 4-13) is significantly easier to update and manage than recompiling and redeploying Java applets.
• Separation of Logic and Presentation: The use of markup languages to separate an application's structure and data from its presentation logic was a fundamental principle of web development. A PHOSITA would naturally look to XML as the obvious tool to define the components and logic for Van Horne's service execution environment to interpret.

Therefore, combining Van Horne's client-side execution environment with the well-known and conventional use of XML as a platform-neutral language for defining application logic and UI would have rendered the invention of claims 1 and 13 obvious. The "starter plugin" is a mere implementation detail for browser integration, which was a standard and necessary technique for invoking such client-side environments at the time.

Obviousness Combination 2: U.S. Patent No. 6,557,043 (La-related) as a standalone reference or in view of common knowledge

1. Base Reference: La-related ('043)

The La-related patent is arguably anticipatory, but at a minimum, it makes the '351 invention obvious. La-related discloses:

• A "client program" installed on the client machine, which is analogous to the "assembler" (Claim 1, element 1; Claim 13, element 2).
• This client program receives "object definitions" and data from the server, which directly corresponds to the "one or more text files comprising program logic" (Claim 1, element 3; Claim 13, element 1).
• The client program uses these definitions to dynamically create the user interface and execute application logic locally, which is the "assembling" step (Claim 1, element 4; Claim 13, element 4).

2. Analysis

The term "object definitions" as used in La-related is broad, but in the context of creating a user interface and executing logic, a text-based, structured format is a natural and obvious implementation. A PHOSITA tasked with implementing La-related's system in 2001 would have considered XML a prime candidate for structuring these "object definitions" for the exact same reasons outlined above: platform independence, readability, and ease of modification.

To the extent that La-related does not explicitly require the "object definitions" to be in a text file format like XML, it would have been an obvious design choice. There is no inventive step in choosing to represent application logic and UI components in XML, as this was a common and well-understood practice at the time for achieving cross-platform compatibility and simplifying server-side management.

Conclusion

The independent claims of U.S. Patent 7,246,351 describe a system that is a predictable combination of known elements. Prior art such as Van Horne ('563) and La-related ('043) already taught the fundamental architecture of a client-side program that downloads logic from a server to dynamically execute an application. The specific implementation choice of using XML as the format for this logic was an obvious, non-inventive step for a PHOSITA in 2001, who would have been motivated by the well-known benefits of XML for platform-independent data and application definition. The combination of these pre-existing concepts would have led directly to the system claimed in the '351 patent with a reasonable expectation of success.

Analysis of Patent Term, Related Applications, and Expiration for U.S. Patent 7,246,351

Date of Analysis: April 30, 2026

This report details the prosecution history and term-related data for U.S. Patent No. 7,246,351 (the '351 patent).

Patent Term and Expiration

• Filing Date: February 20, 2002.
• Issue Date: July 17, 2007.
• Statutory Term: The standard term for a utility patent filed on this date is 20 years from the earliest non-provisional filing date.
• Patent Term Adjustment (PTA): According to USPTO records, the '351 patent was granted a Patent Term Adjustment of 842 days. This adjustment was made to compensate for delays in processing by the USPTO during the patent's prosecution.
• Calculated Expiration Date: The patent's term is calculated by adding the 20-year statutory term to the filing date and then adding the PTA.
  • Base Expiration: February 20, 2002 + 20 years = February 20, 2022.
  • Adjusted Expiration: February 20, 2022 + 842 days = June 12, 2024.

The patent's legal status is Expired, with the term having concluded on June 12, 2024. No further Patent Term Extensions (PTE) under 35 U.S.C. § 156, which are typically granted for regulatory delays related to products like pharmaceuticals and are not applicable here, were found.

Continuity and Related Applications

The '351 patent claims priority to an earlier provisional application and has no subsequent continuation or divisional applications.

• Parent Application:

  • The non-provisional application, Serial No. 10/081,921, was filed on February 20, 2002. This is the application that matured into the '351 patent.

• Priority Claim:

  • The '351 patent claims the benefit of U.S. Provisional Application Serial No. 60/270,031, filed on February 20, 2001. This provisional filing establishes the priority date for the invention disclosed. A provisional application provides an early filing date but is not examined and expires after 12 months, within which a non-provisional application must be filed to claim its benefit.

• Child Applications (Continuations/Divisionals):

  • A thorough review of USPTO records indicates that no continuation, continuation-in-part, or divisional applications were filed that claim priority to application 10/081,921. The '351 patent represents the only patent to have issued from this specific line of prosecution.

Family Summary

The patent family for U.S. Patent 7,246,351 consists of two documents:

1. U.S. Provisional Application 60/270,031: Filed Feb 20, 2001.
2. U.S. Patent 7,246,351: Issued from application 10/081,921, filed Feb 20, 2002.

There are no other related domestic or international patent family members associated with this invention.

Defensive Disclosure Regarding U.S. Patent 7,246,351

Publication Date: April 30, 2026
Subject: Methods and Systems for Dynamic and Distributed Application Assembly
Pertains To: U.S. Patent No. 7,246,351, "System and method for deploying and implementing software applications over a distributed network."

This document discloses a series of derivative inventions, enhancements, and alternative embodiments that build upon the concepts described in U.S. Patent 7,246,351. The purpose of this disclosure is to place these concepts into the public domain, thereby establishing prior art against future patent applications on these and similar topics.

---

Derivative Variations Based on Core Claims

The following disclosures expand upon the core method of a client-side assembler downloading text-based program logic from a server to dynamically build a graphical application.

I. Material & Component Substitution

Derivative 1.1: WebAssembly (WASM) Binary Assembler

• Enabling Description: This embodiment replaces the "assembler program" with a lightweight, sandboxed WebAssembly (WASM) module and the "text files" with pre-compiled WASM binary-format (.wasm) modules. The starter plugin initializes the browser's WASM runtime. The WASM assembler module, upon launch, fetches specific application-logic .wasm modules from a server. These modules contain not only program logic but also pre-compiled bindings to a platform's native GUI toolkit via a WebAssembly System Interface (WASI) for graphics. The assembler performs dynamic linking of these modules in the client's memory space, composing the final application from these binary fragments rather than parsing text. This significantly accelerates application startup by eliminating the text-parsing overhead.
• Mermaid Diagram:

  sequenceDiagram
      participant Browser
      participant WASM_Starter as WASM Starter Plugin
      participant WASM_Assembler as WASM Assembler
      participant Server
  
      Browser->>WASM_Starter: User navigates to page
      WASM_Starter->>WASM_Assembler: Instantiate WASM_Assembler.wasm
      WASM_Assembler->>Server: Request AppLogic.wasm
      Server-->>WASM_Assembler: Return AppLogic.wasm
      WASM_Assembler->>WASM_Assembler: Dynamically link AppLogic.wasm
      WASM_Assembler-->>Browser: Render GUI via WASI Graphics API
  

Derivative 1.2: GraphQL-based Logic Fragments

• Enabling Description: This variation substitutes the monolithic "text files" with a system of granular program logic fragments accessible via a GraphQL API on the server. The client-side assembler, instead of downloading entire files, constructs a GraphQL query specifying the exact UI components and business logic functions required for the current application state. The server's GraphQL resolver assembles a response containing only the requested logic fragments, delivered as a structured JSON object. This "just-in-time" logic delivery minimizes data transfer and allows for highly dynamic applications where components can be fetched and assembled incrementally as the user navigates the UI.
• Mermaid Diagram:

  flowchart TD
      A[Client Assembler] -- 1. GraphQL Query --> B(Server GraphQL Endpoint)
      B -- 2. Resolve Query --> C{Program Logic Fragments}
      C -- 3. Assemble JSON Response --> B
      B -- 4. Transmit JSON --> A
      A -- 5. Parse JSON & Assemble UI --> D[Rendered Application]
  

II. Operational Parameter Expansion

Derivative 2.1: Nanoscale / Quantum Dot Display Assembly

• Enabling Description: This derivative applies the invention to rendering applications on nanoscale displays, such as those composed of quantum dots or micro-LED arrays. The "assembler program" is a firmware-level controller on the display driver IC. The "program logic" is a vector-based textual format (e.g., a specialized SVG or a custom G-code-like language) that defines UI elements as mathematical descriptions rather than pixel maps. The assembler downloads this vector logic and directly translates it into commands for activating specific quantum dots or micro-LEDs, operating at refresh frequencies exceeding 1000 Hz. This allows for ultra-high-resolution, power-efficient user interfaces on microscopic or flexible display surfaces where traditional pixel-based rendering is inefficient.
• Mermaid Diagram:

  graph LR
      subgraph Display Driver IC
          AssemblerFirmware
      end
      subgraph Network
          Server
      end
      subgraph Quantum Dot Display
          DisplaySurface
      end
  
      Server -- Vector UI Logic (e.g., nano-SVG) --> AssemblerFirmware
      AssemblerFirmware -- Low-level activation commands --> DisplaySurface
  

Derivative 2.2: High-Latency, Interplanetary Network Deployment

• Enabling Description: This embodiment is designed for extreme-latency environments, such as a client on Mars communicating with a server on Earth. The "assembler program" is pre-loaded on the client. The "program logic" text files are encoded with forward error correction (FEC) and divided into prioritized packets. The assembler is designed to build a "probabilistic UI" — it can render a functional, low-fidelity version of the application using only a subset of the packets. As more packets arrive (potentially hours later and out of order), the assembler refines and enhances the UI and functionality. All user actions are logged locally and executed optimistically, with state synchronization requests bundled and transmitted to the server during designated communication windows. This architecture ensures application usability despite round-trip times measured in minutes or hours.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> LowFidelity: Incomplete logic packets received
      LowFidelity --> HighFidelity: All logic packets arrive
      HighFidelity --> LowFidelity: Connection lost / Logic invalidated
      LowFidelity: Renders basic UI, logs actions
      HighFidelity: Renders full UI, syncs actions with server
  

III. Cross-Domain Application

Derivative 3.1: Aerospace (Flight Control System Configuration)

• Enabling Description: In this application, the "client device" is an avionics multi-function display (MFD) in a cockpit. The "assembler" is a DO-178C certified real-time operating system (RTOS) component. The "server" is the aircraft's central maintenance computer. Before a flight, the maintenance computer pushes a mission-specific "program logic" file (in a verified XML dialect) to the MFD. This logic defines the flight plan, instrument layouts, and emergency checklists for that specific mission (e.g., a cargo flight vs. a surveillance mission). The assembler builds the MFD interface in a sandboxed memory partition, ensuring that dynamic UI configuration does not interfere with core flight-critical systems. This allows for rapid, verifiable reconfiguration of cockpit displays without requiring a full software re-certification for each mission type.
• Mermaid Diagram:

  flowchart LR
      A[Maintenance Computer] -- Mission XML --> B(Avionics MFD);
      subgraph MFD
          C[DO-178C Assembler] -- Parses XML --> D{Sandboxed UI Partition};
          D -- Renders --> E[Cockpit Display];
      end
      B-->C;
  

Derivative 3.2: AgTech (Programmable Irrigation Controller)

• Enabling Description: The "client device" is a network-connected irrigation valve controller in a field. The "assembler" is a lightweight interpreter running on the controller's microcontroller. The "server" is a central farm management platform. The server transmits "program logic" text files that represent daily or weekly irrigation schedules, tailored to crop type, weather forecasts, and soil moisture data. The logic is a simple, domain-specific language (e.g., "ON_VALVE(5, 30m, 20L/min); WAIT(6h);"). The assembler interprets this text file and translates it into low-level commands for the valve hardware, operating the irrigation system autonomously. This allows farmers to remotely deploy complex, adaptive watering strategies to thousands of controllers without manually reprogramming each device.
• Mermaid Diagram:

  sequenceDiagram
      participant FarmServer
      participant IrrigationController
      participant ValveHardware
  
      FarmServer->>IrrigationController: Send IrrigationPlan.txt
      IrrigationController->>IrrigationController: Assembler parses plan
      loop For each command in plan
          IrrigationController->>ValveHardware: Execute command (e.g., OPEN)
          ValveHardware-->>IrrigationController: Acknowledge
      end
  

Derivative 3.3: Consumer Electronics (Smart Appliance UI)

• Enabling Description: The system is applied to a smart oven. The "client" is the oven's embedded touchscreen controller. The "assembler" is part of the appliance's firmware. The "server" is the manufacturer's cloud service. When a user selects a recipe from a companion mobile app, the app instructs the cloud server to send a specific "cooking logic" XML file to the oven. This XML file defines a sequence of custom UI screens (e.g., "Preheat to 425°F", "Add ingredients", "Bake for 15 minutes") and corresponding hardware commands (e.g., <setTemp unit="F">425</setTemp>). The oven's assembler builds and displays this guided cooking experience, dynamically reconfiguring its interface for each recipe.
• Mermaid Diagram:

  graph TD
      A[Cloud Server] -- CookingLogic.xml --> B[Smart Oven Controller]
      subgraph B
          C[Firmware Assembler]
      end
      B --> C
      C -- Assembles --> D[Dynamic UI on Oven Screen]
      C -- Sends Commands --> E[Oven Heating Elements/Timers]
  

IV. Integration with Emerging Tech

Derivative 4.1: AI-Driven UI/UX Optimization

• Enabling Description: The server component is enhanced with an AI/ML model that dynamically generates the "program logic" text files. The server monitors user interactions (e.g., click-through rates, task completion times, hesitation metrics) in real-time. The AI model uses this data to conduct continuous A/B testing, generating variant XML files with different UI layouts, component placements, or workflows. These variants are served to different user segments. The model learns which variations perform best and automatically adapts the baseline "program logic," optimizing the application's user experience autonomously over time.
• Mermaid Diagram:

  flowchart
      A[User Interaction Data] --> B(AI Optimization Engine);
      B -- Generates --> C(Program Logic XML v1.1);
      C --> D[Client Assembler];
      D -- Renders --> E[Application UI];
      E -- Captures --> A;
      B -- Generates --> F(Program Logic XML v1.2);
      F --> G[Client Assembler];
      G -- Renders --> H[Variant UI];
      H -- Captures --> A;
  

Derivative 4.2: IoT Sensor-Triggered Application Assembly

• Enabling Description: The "starter plugin" is replaced by an IoT event listener on a gateway device. An array of IoT sensors (e.g., temperature, pressure, motion) reports data to the gateway. When sensor data crosses a predefined threshold (e.g., temperature exceeds 100°C), the event listener triggers the "assembler program." The assembler then requests a specific "program logic" file from a server corresponding to that alert (e.g., temp_alert_ui.xml). This logic assembles a diagnostic dashboard or an emergency control interface on a nearby operator terminal, providing immediate, context-specific information and controls without requiring a monolithic monitoring application to be constantly running.
• Mermaid Diagram:

  sequenceDiagram
      participant Sensor
      participant IoT_Gateway
      participant Assembler
      participant Server
      participant Operator_Terminal
  
      Sensor->>IoT_Gateway: Temperature = 101°C
      IoT_Gateway->>Assembler: Trigger(event='TEMP_HIGH')
      Assembler->>Server: Request(logic='temp_alert_ui.xml')
      Server-->>Assembler: Return XML
      Assembler->>Operator_Terminal: Assemble and Display Diagnostic UI
  

Derivative 4.3: Blockchain-Verified Program Logic

• Enabling Description: The server stores hashes of all "program logic" text files on a distributed ledger (blockchain). Before the client-side assembler parses a downloaded text file, it first computes the file's hash and verifies it against the corresponding hash on the blockchain via a smart contract query. This ensures the integrity and authenticity of the application logic, preventing man-in-the-middle attacks or unauthorized server-side modifications. The "starter plugin" can also verify the assembler program's own integrity against a hash stored on the ledger during installation, creating a chain of trust from the client runtime to the application logic being executed.
• Mermaid Diagram:

  graph TD
      subgraph Server
          A[ProgramLogic.xml] --> B(Compute Hash);
          B --> C[Store Hash on Blockchain];
      end
      subgraph Client
          D[Assembler] -- Downloads --> A;
          D --> E(Compute Hash of Local File);
          E -- Verifies Against --> C;
          F{Verification} -- OK --> G[Assemble Application];
          F -- Fail --> H[Abort];
      end
  

V. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation Assembler

• Enabling Description: This variation uses a "safe-mode" assembler designed for low-power or low-connectivity environments. The XML "program logic" files are structured with explicit priority tags (e.g., <element priority="critical"> vs. <element priority="optional">). When the assembler detects a low-battery state, high memory pressure, or a weak network signal, it enters a degraded mode. In this mode, it parses the XML but only assembles elements tagged as "critical" or "core." All non-essential UI components (e.g., animations, high-resolution images, analytics trackers) are ignored. This ensures that the application's core functionality remains available to the user, providing a predictable, low-resource fallback instead of a complete application failure.
• Mermaid Diagram:

  stateDiagram-v2
      state "Full Functionality" as Full
      state "Degraded Mode" as Degraded
  
      [*] --> Full : Normal Conditions
      Full --> Degraded : Low Power OR Weak Signal
      Degraded --> Full : Conditions Improve
      Degraded: Assembles only <br/>'<... priority="critical">'<br/>elements
  

---

Combination Prior Art Scenarios

Scenario 1: Combination with the OpenAPI Specification (formerly Swagger)

• Description: The core method of the '351 patent is combined with the OpenAPI standard. The "program logic" text file is an OpenAPI 3.0 YAML or JSON document. The "assembler program" is a generic OpenAPI client generator that, instead of generating static code, dynamically generates a user interface in memory. Upon downloading an openapi.yaml file, the assembler parses the paths and components/schemas sections to build interactive forms for each API endpoint, complete with input validation based on the defined data schemas. This creates a system for instantly generating a functional UI for any RESTful API that adheres to the OpenAPI standard.

Scenario 2: Combination with the WebXR Device API Standard

• Description: The invention is combined with the W3C's WebXR Device API to deploy augmented reality (AR) and virtual reality (VR) experiences. The "client device" is a VR headset or AR-enabled smartphone. The "assembler" is a JavaScript library that interfaces with the WebXR API. The "program logic" is a text file using a declarative 3D scene-graph format like glTF (in its .gltf JSON representation) or A-Frame's HTML-like syntax. The assembler downloads this file and dynamically constructs a 3D scene, rendering it into the AR/VR environment. This allows for the deployment of interactive XR experiences over the web without requiring users to install large, standalone applications.

Scenario 3: Combination with the IETF's Constrained Application Protocol (CoAP)

• Description: The system is adapted for constrained IoT devices by using CoAP as the transport protocol instead of HTTP. The "assembler" is a minimal binary running on a low-power microcontroller (e.g., an ARM Cortex-M series). The "program logic" is a highly compact, binary-encoded text format like CBOR (Concise Binary Object Representation) instead of verbose XML. The server is a CoAP server, and the client assembler uses a CoAP client to GET the CBOR-encoded logic. This combination allows the dynamic application assembly model to function efficiently over low-power, lossy networks (LLNs) like 6LoWPAN, making it suitable for industrial and environmental sensor networks.