Two companies agree to develop a new technology together.

Company A brings an existing algorithm. Company B contributes proprietary manufacturing know-how. During the project, their teams develop a new process combining elements of both.

Who owns the new process?

Can Company A continue using its original algorithm after the collaboration ends? Can Company B commercialize the new technology without Company A? And if the resulting product cannot function without the pre-existing algorithm, does ownership of the newly created IP actually provide enough rights to bring it to market?

These questions illustrate one of the most important distinctions in research and development agreements: background intellectual property (IP) versus foreground IP.

The distinction may sound straightforward, but poorly drafted boundaries between the two can create significant problems when collaborators eventually try to protect, license, commercialize, or independently develop the results of their work.

What Is Background IP?

Background IP generally refers to intellectual property, technology, know-how, data, materials, software, processes, or other proprietary assets that a party already owns or controls independently of the collaborative project.

Depending on how the agreement is drafted, this may include:

The crucial point is that this material was not created as a result of the new collaboration.

For example, imagine that a biotechnology company enters into a research and development (R&D) collaboration with a university. The company contributes an existing diagnostic platform, while the university contributes a proprietary testing methodology developed through earlier research.

Those assets would typically be treated as background IP.

The collaboration agreement should make clear that simply allowing another party to use background IP for the project does not automatically transfer ownership of that IP.

What Is Foreground IP?

Foreground IP generally refers to intellectual property or other protectable results created through the activities carried out under the R&D project.

It could include:

The terminology is not universal. Some modern research frameworks use the term "results" instead of "foreground." For example, the Horizon Europe Model Grant Agreement distinguishes between pre-existing "background" and "results" generated through the project.

The contractual definition therefore matters more than the label itself.

A well-drafted agreement should clearly define which outputs fall within the relevant category rather than relying on assumptions about what "foreground IP" normally means.

Why the Difference Matters

The distinction becomes critical because ownership of the project results and permission to use the technology required to create or commercialize those results are not necessarily the same thing.

Suppose Company A owns a proprietary software engine before the collaboration begins.

During a joint development project, Companies A and B create a new analytics application that operates using that engine.

The parties might agree that Company B owns the newly developed application.

But if Company B does not also have appropriate rights to use Company A's underlying software engine, its ownership of the new application may have limited commercial value.

This is where R&D agreements need to address two separate questions:

Who owns the IP?

and

Who has the right to use the IP?

They are not interchangeable.

A party may own foreground IP but still need a license to another party's background IP before it can commercially exploit it.

Background IP Should Be Identified Before Work Begins

One of the most effective ways to reduce future disputes is to document important background IP at the beginning of the collaboration.

This can often be done through a schedule or annex to the agreement.

For example:

Party Background Asset Purpose in Project
Company A Existing machine-learning model Used to process project data
Company A Software platform v3.2 Development environment
Company B Manufacturing process Used to produce prototypes
Company B Proprietary testing dataset Product validation

The objective is not necessarily to catalogue every asset the organization owns.

Instead, the parties should identify background assets that are expected to be relevant to performing the project or exploiting its results.

The UK's Lambert research collaboration guidance similarly recommends identifying important background contributed to a project, particularly where the project's success depends on access to it.

Without this exercise, disputes may later arise over whether a particular technology existed before the project or was developed during it.

Good internal documentation can therefore become just as important as the contract itself.

Ownership of Background IP Should Usually Remain Clear

An R&D collaboration normally requires some degree of access to each participant's existing technology.

That access does not necessarily mean ownership should change.

A typical structure may provide that each party:

This allows the collaboration to function without unnecessarily transferring valuable pre-existing assets.

But the scope of the license deserves careful attention.

A license allowing background IP to be used for carrying out the research project may not automatically permit its use for commercializing the resulting product.

That difference can become extremely important after successful R&D.

Who Should Own the Foreground IP?

There is no single ownership model suitable for every collaboration.

Different R&D arrangements may allocate foreground IP differently depending on who created it, who funded the work, who contributed the relevant technology, and who is expected to commercialize the results.

Possible structures include:

Creator Ownership

Each party owns the foreground IP created by its employees or researchers.

This can work where contributions are easily distinguishable.

Lead-Party Ownership

One participant owns defined project results because it is expected to commercialize the technology.

Other participants may receive licenses, payments, royalties, or research-use rights.

Field-Based Ownership

Different parties receive ownership or exclusive rights within different fields of application.

For example, one collaborator may commercialize the technology in healthcare while another holds rights for industrial applications.

Assignment of Particular Results

The agreement may establish mechanisms for assigning specific categories of newly created IP to one participant.

Joint Ownership

Where multiple parties genuinely contribute to an invention or other asset, joint ownership may arise or be contractually agreed.

However, joint ownership should not be treated as the easy compromise.

The legal consequences of joint ownership can differ significantly depending on the type of IP and applicable law, including whether one co-owner may exploit, license, assign, or enforce the right without the consent of the other.

If joint ownership is contemplated, the agreement should therefore establish detailed rules governing how that ownership will operate.

The Lambert Toolkit demonstrates why multiple ownership models may be appropriate: its research collaboration agreements provide different structures depending on which participant should own and exploit the project results.

The Difficult Category: Improvements to Background IP

One of the most challenging questions arises when foreground developments improve an existing background asset.

Suppose Company A contributes a proprietary chemical formulation.

During the collaboration, researchers develop a significantly improved version of that formulation.

Is the improvement:

There is no universal contractual answer.

The agreement needs one.

Organizations should therefore consider expressly addressing improvements, modifications, derivatives, enhancements, and adaptations of background IP.

Otherwise, a successful technical improvement may produce precisely the ownership dispute the collaboration agreement was intended to prevent.

Access Rights Can Matter More Than Ownership

R&D agreements frequently focus heavily on ownership while paying less attention to access.

Yet commercialization often requires several layers of intellectual property.

A product might incorporate:

Party A's background technology + Party B's background technology + jointly created project results.

Even if ownership of every component is clear, neither participant may be able to commercialize the complete product unless the agreement also provides the necessary licenses.

This is why sophisticated agreements distinguish between access required:

The answer may involve different license terms, including:

Do Not Forget Third-Party IP

A participant may control technology without owning every element of it.

For example, project background might contain:

An R&D partner cannot necessarily grant another participant rights broader than the rights it possesses itself.

Before identifying an asset as available background IP, organizations should therefore understand:

  1. Who actually owns it?
  2. What license rights does the organization have?
  3. Can those rights be extended to project partners?
  4. Are there restrictions on modification or commercial use?
  5. Are there confidentiality obligations?
  6. Are sublicenses permitted?

In some cases, third-party restrictions can prevent a project participant from granting the access rights required by the collaboration.

Confidentiality and Publication Must Align With IP Ownership

R&D collaborations frequently involve competing objectives.

Researchers may want to publish findings.

Commercial partners may need to preserve confidentiality until patent applications are filed.

Businesses may need sensitive manufacturing know-how to remain a trade secret indefinitely.

The agreement should therefore connect its background and foreground IP provisions with its:

A contractual right to publish research results without an appropriate patent-review mechanism, for example, could potentially interfere with the ability to obtain patent protection in jurisdictions where premature public disclosure affects novelty.

IP ownership provisions should therefore not be drafted in isolation.

What Should an R&D Agreement Address?

There is no universal clause that solves every collaboration, but organizations should generally consider the following questions before the project begins:

Background

Project access

Foreground or results

Protection

Commercialization

After termination

These questions are often easier—and considerably less expensive—to resolve before valuable technology exists.

From Contract Drafting to Active IP Management

The background-versus-foreground distinction should not exist only on paper.

During long or technically complex R&D programs, organizations should maintain records showing:

This turns the R&D agreement from a static legal document into an active framework for managing innovation.

When a potentially patentable invention emerges six months into a collaboration, the organization should not need to reconstruct its ownership history from emails and meeting notes.

It should already know where the invention came from, which background assets contributed to it, who participated in developing it, and which contractual provisions govern it.

For innovation-driven organizations, that distinction can determine whether a successful R&D project becomes a commercially usable asset or a collection of valuable technology that no participant has sufficient rights to exploit independently.

A strong IP management process therefore begins before the research does: identify the background, establish ownership and access rules, document new results as they arise, and connect every protection decision to the commercial objectives of the collaboration.

NovaLexi® helps organizations manage intellectual property across the full innovation lifecycle, from IP identification and documentation to protection, portfolio management, and commercialization.

If your organization is entering or already running R&D collaborations, book a demo to see how NovaLexi keeps background and foreground IP documented, traceable, and ready to act on from day one.