Versioning

Every application has its own version history. As you draft, Nodes-IP keeps a running record of where the application has been, so you can always reach back to a previous state, and so a filed version is preserved exactly as you filed it, no matter how the project evolves afterwards.

Applications and versions

An application is a single filing under a project: a US application, an EP application, a PCT application. A project can hold any number of applications, and each one is independent: it has its own claims, sections, title, docket, bibliography, and version history.

A version is a saved checkpoint of an application's content. Each version preserves:

  • The claims and application sections (Background, Summary, Detailed Description, etc.) as they read at that moment.
  • The title and docket / reference for the filing.
  • The inventors and applicants named on the filing, captured as they were at that moment, including their names, nationalities, and addresses.
  • The figures and reference-sign elements referenced from the content, captured with their state at that moment.

Versions are immutable. Once a version is frozen, nothing about it changes: not the claims, not the inventors, not the figures it points at. It is a faithful record of the application as it stood when you saved it.

Current draft and frozen versions

At any time, exactly one version of each application is the current draft, the editable draft you're typing into. Every other version is frozen.

When you save, Nodes-IP freezes your current draft (under a name, if you give it one), then creates a new current draft on top of it. You keep editing in the new current draft; the frozen version stays put as a permanent record.

You don't manage this by hand. There is no "switch to edit mode": if you can type into it, it's the current draft. If you can read it but not type, it's frozen.

Saving

Use Save (the save button on the editor toolbar, or Ctrl+S while editing claims or sections) to freeze a version. A name is optional. Naming a version is how you find it again later, so it's worth naming the ones that matter, like a milestone "as filed at the USPTO", "first office action response", or "ready for client review". When you save, Nodes-IP freezes the current draft, then opens a fresh current draft for you to continue editing in.

A saved version without a name is kept as a plain checkpoint. Either way, the saved version is kept and listed in the application's version history.

You cannot save while there are unresolved pending changes from the assistant on the current draft. Accept or reject them first, then save.

Version history

Open the Matters view to see an application's version history. Each application lists its current working draft at the top, followed by every saved version in order, with the name you gave it (or Checkpoint if you saved it without one) and how long ago it was saved.

The live registry vs frozen versions

Inventors, applicants, figures, and reference-sign elements live in a project-wide registry. Editing them updates the registry, and the change is reflected in the current draft of every application.

Frozen versions are immune. Renaming an inventor or updating an address changes how the registry reads going forward, but it does not change what's on any version you've already frozen. A filed version always shows the inventor exactly as named at filing time.

This is why a save freezes the bibliography too, so the record of who was named on which filing is preserved, even years later when the registry has moved on.

Forking from another application

A new application can start either empty or as a fork from a frozen version of another application in the same project. This is the natural workflow for follow-on filings, for example an EP application that starts from the US version 2 filing, or a continuation that starts from the parent's grant.

When you fork, the new application is created with a current draft whose content is copied from the source version (claims, sections, title, docket, bibliography, figures). It is its own application after that, and edits there don't affect the source.

Forking is project-scoped: you can only fork from versions in the same project. The element and figure registries are shared per-project, and crossing projects would break those references.

Deleting versions

You can delete a saved version from its row in the version history. Deleting a version does not break the chain: any later versions that branched from it are re-parented to its parent, so the history stays connected. If the deleted version has cross-application descendants (an EP application that forked from it, for example), the confirmation dialog warns you before re-parenting them. A root version (the very first version of an application) can't be deleted, since there's no parent to stitch its children onto, and the live current draft can't be deleted either.

Coming soon

A few related capabilities are not in the product yet:

  • Restoring an old version. Reopening a frozen version to fork the application from that point, so you can revise a claim set you'd abandoned or take the application in a different direction from a known good point. For now, the way to branch from an earlier state is to fork a new application from it (see Forking from another application above).
  • Renaming a version. Changing a saved version's name after the fact. For now, pick a name you'll recognise when you save.
  • Automatic checkpoints. Background autosaves between your named saves, so an unnamed safety-net copy is always available. Until that ships, save the states that matter: a version only exists once you save it.