In re: 21st Century Cures Act: Interoperability, Information
Blocking, and the ONC Health IT Certification Program

The following comments are respectfully submitted in response to the Notice of Proposed Rulemaking dated March 4, 2019.[1]

As the Office of the National Coordinator recognizes, intellectual property plays an important role in electronic health record interoperability: While patents and copyrights can in some cases provide useful incentives for invention and creativity, in many situations IP rights “can be misused in ways that undermine the promotion of competition and innovation.”[2] Accordingly, ONC correctly and importantly recognizes the need to consider and limit the use of IP to restrain competition in health care systems.

The R Street Institute and the undersigned counsel
have significant experience in IP policy, and in particular with the
intersection between IP and regulatory systems. Among other things, the
commenter has testified before Congress on patent policy, been cited by
justices of the Supreme Court of the United States in patent cases, authored a
paper on copyright licensing and technical standards, and written numerous amicus
briefs, administrative comments, and articles on IP policy. It is
therefore hoped that this expertise will prove informative to ONC as it crafts
its health care interoperability rule.


I. ONC Should Address
Copyright-Specific Issues Relating to Interoperability Elements

A. Recent Changes in the Law of Copyright and Interoperability

B. Licensing of Possible Copyrights in Interfaces (Section

C. Copyrights in Standards Adopted in the Certification
Criteria (Subparts 170(B)–(C))

D. ONC Should Advise the Government Against Copyrights in
Software Interfaces

E. Definition of “Interoperability Element” (Section

F. Further Exceptions for Screenshot Sharing (Section

II. The Rule Should Address Likely Situations Where
Intellectual Property Is Not Held by Regulated Entities

A. Transfers of IP To Third Parties (Subpart 171(A))

B. IP Originating from Third Parties (Section 170.406;
Subparts 170(B)–(C))

C. The Rule Should Require Disclosures of Relevant IP
(Section 170.406)

III. The Rule Should Declare Categorically that
Interoperability Elements Are Not Trade Secrets (Section 171.206)

IV. The Information Blocking Exception for Intellectual
Property Licensing Should Be More Tailored

A. Overlap Between Cost Recovery and IP Licensing (Sections
171.204 and 171.206)

B. Publication of Licensing Rates (Section 171.206)

C. Exhaustion of IP Rights (Section 171.206)

D. Licensing to Any Requestor (Section 171.206)

E. Top-Down Computation of Royalties (Section 171.206)

F. Smallest Salable Practicing Unit (Section 171.206)

V. Conclusion

*Note: To assist in indexing these comments against
the notice of proposed rulemaking, each section heading identifies the Code of
Federal Regulations provision relevant to the section of these comments.
Section headings identifying no C.F.R. provision provide general background on

  1. I. ONC Should Address Copyright-Specific Issues Relating
    to Interoperability Elements

Although the notice of proposed rulemaking refers generally
to “intellectual property,” the discussion therein appears to focus on issues
specific to patents and trade secrets. However, it is the commenter’s view that
copyright law may play an outsized role in interoperability and information
blocking practices. As a result, ONC should pay specific attention to the
unique problems that copyright law may pose for health care interoperability.

  1. A. Recent Changes in the Law of Copyright and

Special attention to copyright issues is especially necessary in a rulemaking that pertains to computer system interoperability, because recent case law in that area has dramatically changed. Accordingly, this section summarizes a law review article that the commenter has written, a copy of which is attached to this comment for reference.[3]

Interoperability among computer systems is generally made possible by mutual agreement among those systems on a common language, called an “application programming interface” or “API,” that generally comprises a vocabulary of names of commands or data entities. For years, under cases such as Lotus Development Corp. v. Borland International, Inc.,[4] courts held that copyright law did not prohibit the copying of command names for purposes of implementing an API. In light of these holdings, the technology industry in many fields—including health care—developed technical standards that included APIs, without substantial attention to copyright licensing issues (in stark contrast to those standards developers’ demonstrable caution about patent licensing).[5]

But in Oracle America, Inc. v. Google Inc.[6] and Oracle America, Inc. v. Google LLC (“Oracle II”),[7] the U.S. Court of Appeals for the Federal Circuit held that a copyright in an API exists and is infringed when another party implements that API. This arguably creates a split between the Federal Circuit and the other courts of appeals, but because it is almost always possible for one to obtain Federal Circuit jurisdiction by attaching a patent infringement claim to a copyright lawsuit, commentators have recognized that the Federal Circuit’s decision is effectively the current law of the land.[8]

As a result, there is at least an open possibility
that any API developed through a technical standard-setting process is subject
to one or more copyrights held by those who contributed to the standard. ONC
will need to give due attention to that possibility throughout its rule,
because such copyrights could be powerful tools for information blocking, as
described below.

The information blocking exception for RAND[9] licensing of interoperability elements should generally serve equally for licensing of copyrights as it does for licensing of patents. However, some adjustment may need to be made to the provision for reasonable royalties under proposed 42 C.F.R. § 171.206(b)(2).

Unlike patent law, where damages are almost always proportional to the extent of injury or the value of the patented technology,[10] copyright damages are not. Instead, a copyright owner may be entitled to statutory damages fixed by law at up to $150,000 per work infringed.[11] The resulting possibility of statutory damages unrelated to the value of the copyright potentially skews the hypothetical negotiation that is the basis for computation of the RAND royalty rate.

ONC could avoid this problem simply by specifying
that the RAND rate for any copyright in interoperability elements should be
computed without regard for the possibility of statutory damages. But a better
approach may be to require “RAND-Zero” licensing, by which the copyright holder
may still impose non-discriminatory licensing terms on the licensee but may not
charge a royalty.

In fact, RAND-Zero licensing would be appropriate
for copyrights on interoperability elements. First, as noted above, the
industry expectation for years was that no copyrights inhered in APIs or other
elements of interoperability, so RAND-Zero licensing would be a mere
continuation of prior industry expectations. Second, RAND-Zero licensing would
simplify what could otherwise be a quagmire of licensing needs for users of
interoperability elements, thereby advancing the interests of encouraging
interoperable systems. Third, RAND-Zero licensing would avoid difficult
questions as to the scope of copyright interests in APIs to which the Federal
Circuit’s Oracle decisions gave rise. Since it is within ONC’s power
to determine what constitutes information blocking, it would be reasonable for
ONC to avoid difficult questions about the value of API copyrights simply by
returning to the state of the world prior to the Federal Circuit’s decisions, and
thus to require costless licensing of APIs to third-party developers.

In Part 170 of the proposed rule, ONC adopts a variety of APIs and technical standards for use in certified technology. The possibility of copyright protection in APIs means that there may be IP in those adopted standards and other standards previously adopted. Problematically, the holders of those IP rights need not be regulated actors with certified technology; they may be unrelated associations (such as the AMA, which developed lists of billing codes deemed to be protected under copyright[12]). This means that ONC potentially has no enforcement avenue to prevent anticompetitive assertion of IP in some adopted standards.

It is unknown to the commenter whether ONC has
conducted an audit of possible IP rights, in particular copyrights, in the
standards it adopts; if it has not, ONC should do so and should ensure that any
IP in those standards cannot be used to block the development of interoperable

It should be obvious that newfound copyrights in APIs will
potentially pose serious problems for ONC’s objectives to increase
interoperability and to eliminate information blocking. Should the office wish
to avoid such problems, it may consider informing its coordinate agencies of

The Oracle II case[13] is currently on petition for review with the Supreme Court, and the Court has called for the views of the Solicitor General on whether to grant review of the case. If the Supreme Court does grant review, then the government will likely present its views on the merits in an amicus curiae brief. Should the Supreme Court reverse the Federal Circuit, the many problems posed by API copyrights would largely go away.

It thus may be in the interest of ONC to advise the
Solicitor General of these concerns and the effect that the Federal Circuit’s
decisions on copyright in APIs may have on ONC’s statutory obligations.

To be sure, even a reversal of the Federal Circuit would not eliminate any need for ONC to consider copyright-related issues. For example, Practice Management Information Corp. v. American Medical Ass’n,[14] the case that permitted the AMA to maintain a copyright in its medical billing codes, could present another impediment to interoperability insofar as interoperable systems need to use such things as medical billing codes. Nevertheless, reversal of the Federal Circuit’s decisions would likely simplify the issues before ONC greatly, and it would make sense for the Solicitor General to be informed of this dimension of the Oracle II case.

Under proposed 42 C.F.R. § 171.102, an “interoperability element” is defined as “[a]ny functional element of a health information technology.” This definition is of concern because the term “functional” is sometimes used in contrast to the term “expressive” to refer to copyrightable subject matter. This would suggest that the term “interoperability element” is limited to uncopyrightable subject matter, and since the Federal Circuit held APIs subject to copyright protection,[15] APIs would arguably not be interoperability elements.

This issue in the definition of “interoperability
element” may be addressed by noting that functionality should be determined
without regard to protectability under copyright or patent law. That said, APIs
likely fall under other subelements of the definition, so no change may be
necessary, but there appears to be no harm in clarification.

Under proposed 42 C.F.R. § 170.403(a)(2)(ii)(C)–(D), a
health IT developer may prohibit communications that would infringe the
developer’s IP rights and may further prohibit sharing of certain screenshots.
In both cases, the permitted prohibitions carry exceptions that the
prohibitions may not extend to prevent communications that would be fair use under
copyright law.

Fair use is a reasonable baseline standard for
limiting the ability of health IT developers to prohibit communications. But,
as ONC recognizes, the limitation may be broader than fair use alone: The
proposed rule at § 170.403(a)(2)(ii)(D)(1) also denies health IT
developers the ability to prohibit sharing of annotated authentic screenshots,
even though such screenshots may not always constitute fair use.

ONC should therefore expand the list of
communications categorically exempted under this section beyond annotated
screenshots. This is because, in many situations, application of the fair use
doctrine can be difficult and uncertain. Safe harbors and clarity are thus
especially important to ensure robust communication about health IT.

Candidates for that list of categorically
unrestrictable communications may include communications for news reporting,
educational communications, communications for criticism, or parodic
communications. These types of communications all likely count as fair use
under current law anyway, and the value of certainty on behalf of the
communicating parties almost certainly outweighs any costs to health IT

  1. II. The Rule Should Address Likely Situations Where
    Intellectual Property Is Not Held by Regulated Entities

Under 42 U.S.C. §§ 300jj–52(a)(6), ONC’s and the
Inspector General’s enforcement powers over information blocking are generally
limited to those entities who themselves engage in it. This is problematic with
respect to information blocking practices that involve intellectual property,
because the IP involved need not arise from a regulated actor and may be
transferred to an unregulated entity to avoid enforcement. ONC obviously cannot
act beyond its statutory authority, but it should take measures to mitigate
harms resulting from these very real possibilities.

  1. A. Transfers of IP To Third Parties (Subpart 171(A))

Although a regulated actor who holds IP may not assert it in ways contrary to the information blocking or other rules, that actor may transfer the IP to a third party outside ONC’s jurisdiction, and the third party may potentially assert the IP in ways that hinder competition or bolster the regulated actor’s monopoly position. History shows this to be a realistic threat, often referred to as “patent privateering.”[16] In the past, the Federal Trade Commission has dealt with these practices, in particular when a holder of patents essential to a technical standard sells those patents to a new company not bound to the attached RAND obligation.[17] But such FTC action is possible only by virtue of the agency’s general power over most firms engaged in unfair and deceptive practices;[18] ONC does not appear to have this sort of plenary jurisdiction.

To the extent that a transfer of IP to an
unregulated entity is intended to facilitate circumvention of the information
blocking prohibition, the transfer itself is likely an act of information
blocking under proposed 42 C.F.R. § 171.103, since the transfer “is likely
to interfere with, prevent, or materially discourage access, exchange, or use
of electronic health information.” It is worth making this explicit either in
the text of the rule or in the preamble, because without such a statement, the
aforementioned argument is vulnerable to a common argument among IP holders
that their right to alienate IP outweighs regulatory interests.

The other problem is that the transfer of IP rights
between a regulated actor and an unregulated third party is not necessarily
transparent, so developers using interoperability elements may be caught off
guard by the unregulated third party’s IP assertions, particularly if they are
unaware of the original source of the IP right. This suggests a need for
disclosure and accounting of regulated entities’ IP rights, as discussed below.

It is also possible that, for some interoperability
elements, relevant IP does not originate from a regulated actor. This may
happen in two ways, both of which should be addressed.

First, interoperability elements included in a regulated actor’s technology may be taken from an external third-party source, perhaps under license from that third party. For example, a regulated actor’s health IT system may use a list of billing codes developed by a medical trade association, where the trade association maintains a copyright in the list.[19] Developers of interoperable systems may require use of that list of billing codes and thus may need their own licenses, which the trade association—perhaps with the blessing of the regulated actor—may refuse to grant.

This problem is reasonably easy to solve: ONC should
require any regulated actor to disclose any third-party IP in their
interoperability elements, along with a representation that the actor has the
right to grant sublicenses consistent with § 171.206. This could be done
as an attestation under proposed 42 C.F.R. § 170.406(a).

Second, as noted previously, there may be
IP in the API standards that ONC adopts in this rulemaking. Prior to adopting
those standards into the rule, ONC should conduct an audit of the IP present in
those adopted standards, or it should require the developers of those standards
to certify that no IP will be asserted against implementers and that they have
the right to make that certification.

Many of the issues identified thus far would be alleviated if ONC required disclosures of IP rights on interoperability elements. To do so would be well in line with private industry practice.[20]

For example, ONC’s exception to information blocking
under § 171.206 largely follows the practice of private standard-setting
organizations in imposing RAND licensing obligations on regulated actors’
interoperability elements. Often, private standard-setting organizations also
require listings of any IP held by participants in the standard-setting

By the same token, ONC should require regulated
actors, likely as part of the certification process, to declare any IP rights
they have on interoperability elements, including IP rights of third parties.
Also following private industry practice, ONC may consider requiring regulated
actors to make a written declaration of their commitment to the RAND obligation
under § 171.206. These declarations could likely be incorporated into the
attestations required in proposed § 170.406.

Besides improving transparency and reducing frictions in the development of interoperable health care technology, these declarations may serve useful purposes by enabling other government regulators to police improper information blocking. Courts have held, for example, that a patent owner’s omission of IP from a declaration to a standard-setting organization can qualify as inequitable conduct rendering the IP right unenforceable.[21] The Federal Trade Commission has also relied on declarations to standard-setting organizations as a basis for charging firms with anticompetitive or deceptive practices.[22] If ONC were to require similar declarations, it would thus expand the universe of enforcers and more greatly dissuade firms from engaging in information blocking.

  1. III. The Rule Should Declare Categorically that
    Interoperability Elements Are Not Trade Secrets (Section 171.206)

Various parts of the proposed rule suggest that a regulated
actor may maintain trade secret protection over information even in the course
of making interoperability elements available to others. For example, proposed
§ 171.206(b)(5) permits an actor to “require a reasonable non-disclosure
agreement that is no broader than necessary to prevent unauthorized disclosure
of the actor’s trade secrets.”

It is unclear what else might constitute a trade
secret that must be disclosed to a potential licensee of interoperability elements,
but ONC should categorically declare that interoperability elements themselves
may not be protected as trade secrets. Trade secret protection on
interoperability elements would act much like other intellectual property on
interoperability elements, preventing third parties from accessing and using
electronic health information.

Likely, ONC can eliminate trade secret protection for interoperability elements under current case law. In Ruckelshaus v. Monsanto Co. the Supreme Court held that data submitted to the Environmental Protection Agency as part of a regulatory application was not a trade secret, because the EPA made no guarantee that the data would be held in confidence, so the data submitter “could not have a reasonable, investment-backed expectation” that the information would maintain the confidentiality prerequisite to trade secret protection.[23] Similarly, then, if ONC were to prohibit the assertion of trade secret law over interoperability elements as a form of information blocking, or better yet were to require disclosure to ONC of interoperability elements, then under Monsanto no trade secret protection would inhere.

Indeed, Monsanto suggests that it could potentially be problematic down the road if the final rule explicitly recognizes the possibility of trade secret protection for interoperability elements. In that same case, the Supreme Court considered a brief period when the relevant statute did provide for confidentiality of data submitted to the EPA, and held that a subsequent change to the law eliminating such confidentiality effected a taking of property subject to just compensation under the Fifth Amendment.[24] Thus, if ONC were to recognize the possibility of trade secret protection in interoperability elements in the present rule (as § 171.206(b)(5) does) and wish to change course later, it could end up being required to pay compensation.

Eliminating trade secret protection on
interoperability elements is unlikely to have substantial effect on incentives
or compensation for developers of interoperability elements. Patents and
copyrights may be used to protect them as much as possible. To the extent that
an interoperability element is neither patentable nor copyrightable, that
unprotectability is almost certainly a sign that the interoperability element
carries no independent value meriting licensing royalties, in which case the
developer ought to be limited to recovery of reasonable costs under proposed 42
C.F.R. § 171.204.

  1. IV. The Information Blocking Exception for Intellectual
    Property Licensing Should Be More Tailored

ONC is to be commended for its attention to the information
blocking problems that intellectual property can create. The following
suggestions are intended to strengthen the IP licensing exception for
information blocking and to avoid possible abuse of the RAND licensing scheme
it sets forth.

  1. A. Overlap Between Cost Recovery and IP Licensing
    (Sections 171.204 and 171.206)

While § 171.206 provides an exception to information
blocking for licensing of interoperability elements, § 171.204 provides
for recovery of “costs reasonably incurred to provide access, exchange, or use
of electronic health information.” In a sense, these charges overlap: Licensing
of IP is intended to recoup the costs of development of that IP, so where the
IP is an interoperability element, the costs reasonably incurred for its
development should be incorporated into the royalty rate. Indeed,
§ 171.204(c)(2) specifically permits for recovery of “actual development
or acquisition costs” of intangible assets, which presumably includes IP.

To prevent regulated actors from earning a double
recovery, the rule should be clear in one or both of those sections that only a
single recovery is permitted. Likely the best way to do so is to provide in
§ 171.204 that no recovery may be had for any development costs that led
to the creation of IP if the actor receives a royalty for that IP pursuant to
the § 171.206 exception or otherwise.

ONC should require regulated actors who engage in RAND
licensing of interoperability elements to publish either standard licensing
rate offers or actual licenses concluded. Doing so would increase transparency
for developers of interoperable systems, avoid gamesmanship over licensing
rates, and ensure verifiable compliance with ONC’s rules.

ONC should provide that a regulated actor who sells a product may not withhold any patent licenses necessary to operate the product from the buyer or from downstream purchasers of that same product. Such a rule simply encapsulates the patent exhaustion doctrine articulated by the Supreme Court recently in Impression Products, Inc. v. Lexmark International, Inc.[25] However, patent-holding firms, most notably Qualcomm, have sought to circumvent the exhaustion doctrine in an effort to charge (and indeed overcharge) purchasers of their products for patent licenses in addition to the product cost.

Recently, a federal district court held Qualcomm’s
exhaustion-circumvention practice to be anticompetitive. Accordingly, in order
to give teeth to the exhaustion doctrine against the strong impulses of IP
holders to try to overcome it, ONC should similarly adopt the exhaustion
doctrine into its rule.

In the Qualcomm litigation described above, the district
court also considered and deemed anticompetitive Qualcomm’s practice of
licensing even its RAND-encumbered patents on certain semiconductor chips only
to complete smartphone manufacturers, refusing to license those patents to
competing chipmakers. To prevent IP owners from attempting the same strategy,
ONC should similarly prohibit regulated actors from refusing to license their
IP to any type of entity.

There are generally two methodologies for computing a
reasonable royalty under RAND terms: the “bottom-up” approach where the value
of the technology being licensed is compared to other elements of value in the
licensee’s products, and the “top-down” approach where the universe of relevant
patents is gathered and a royalty rate is determined by apportioning value
among those patents. The top-down approach is generally favored because it
avoids the possibility of royalty stacking, in which the sum total of royalties
owed by a firm on a product exceeds the value of the product.

The preamble’s description of § 171.206(b)(2)
appears to adopt the top-down approach in noting that a licensor must account
for “the cost to the licensee of obtaining other interoperability elements that
are important for the viability of the products for which it is seeking to
license elements.” But the proposed rule itself, at § 171.206(b)(2)(ii),
appears to take the bottom-up approach, focusing on “the independent value of
the actor’s technology to the licensee’s products.” It seems that the intent of
the rule’s language was to incorporate the top-down principle stated in the
preamble, but given that the plain language recites two distinct approaches,
some clarification to the language of the rule would be useful.

In determining royalty rates under RAND obligations, an
initial question is the “base” price for the royalty, which depends on the
“base” product. Consider, for example, a licensing negotiation between a
smartphone manufacturer and a holder of a patent on the smartphone camera. The
patent holder would prefer the royalty base to be the entire phone, since that
gives the patent holder greater leverage to demand a higher overall royalty
even with a small royalty rate percentage; the phone manufacturer would prefer
the base to be just the camera component since the maximum royalty is limited.

Traditionally, the favored approach is to base the royalty rate on the “smallest salable practicing unit,” or SSPU, namely the smallest component that could be independently sold on some market.[26] In an effort to obtain greater negotiating leverage, patent owners have often resisted the use of the SSPU as the basis of royalty calculations. But using a royalty base larger than the SSPU would be to the detriment of licensees who may be forced to pay unpredictable or unnaturally high royalty rates.

ONC should therefore include in its rule that the
reasonable royalty must be based on the smallest salable practicing unit.

The commenter thanks ONC for providing the opportunity to
submit these comments. If there are any remaining questions relating to the
matters presented herein, the undersigned would be happy to provide further
information as necessary.

Respectfully submitted,
 Charles Duan
 R Street Institute
 1212 New York Avenue NW, Suite 900
 Washington, D.C. 20005
 Counsel for the R Street Institute
 June 5, 2019

[1]   The deadline for submitting comments was
extended to June 3, 2019, in 84 Fed. Reg. 16384 (Apr. 23, 2019).

[2]   Office of the Nat’l
Coordinator for Health Info. Tech., Information
Blocking Exception for the Licensing of Interoperability Elements on Reasonable
and Non-Discriminatory Terms (Feb. 13, 2019),

[3]   See Charles Duan, Internet of
Infringing Things: The Effect of Computer Interface Copyrights on Technology
, 45 Rutgers Computer & Tech. L.J.
1 (2019),˙id=3303618.

[4]   Lotus Dev. Corp. v. Borland Int’l, Inc.,
49 F.3d 807 (1st Cir. 1995), aff’d by an equally divided Court, 516
U.S. 233 (1996) (per curiam).

[5]   See Duan, supra note 3, at

[6]   Oracle Am., Inc. v. Google Inc.,
750 F.3d 1339 (Fed. Cir. 2014).

[7]   Oracle Am., Inc. v. Google LLC (“Oracle
”), 886 F.3d 1179 (Fed. Cir. 2018).

[8]   See Duan, supra note 3, at

[9]   Reasonable and non-discriminatory, as used
throughout the notice of proposed rulemaking.

[10] See 35 U.S.C.
§ 284. Design patents do not follow this proportionality rule, because an
infringer of a design patent is “liable to the [patent] owner to the extent of
his total profit.” § 289; see Samsung Elecs. Co. v.
Apple Inc.
, 137 S. Ct. 429, 435 (2016). It is difficult to imagine a
situation where a design patent would cover an interoperability element, but to
the extent it does, similar remedial rules to those described here with respect
to copyrights may be necessary.

[11] See 17 U.S.C.
§ 504(c).

[12] See Practice Mgmt. Info. Corp. v.
Am. Med. Ass’n
, 121 F.3d 516, 520 n.8 (9th Cir. 1997).

[13] See Oracle Am., Inc. v. Google
(“Oracle II”), 886 F.3d 1179 (Fed. Cir. 2018).

[14] Practice Mgmt., 121 F.3d 516.

[15] See Oracle Am., Inc. v. Google
, 750 F.3d 1339 (Fed. Cir. 2014).

[16] See Tom Ewing, Indirect Exploitation
of Intellectual Property Rights By Corporations and Investors: IP Privateering
and Modern Letters of Marque and Reprisal
, 4 Hastings
Sci. & Tech. L.J. 1 (2012),

[17] See In re Motorola Mobility
, 156 F.T.C. 147, 153, 165–66 (July 23, 2013).

[18] See Federal Trade Commission Act § 5,
15 U.S.C. § 45.

[19] See Practice Mgmt., 121 F.3d at
520 n.8.

[20] See Duan, supra note 3, at
25–26 & n.92.

[21] See Core Wireless Licensing
SARL v. Apple Inc.
, 899 F.3d 1356, 1369 (Fed. Cir. 2018); Qualcomm
Inc. v. Broadcom Corp.
, 548 F.3d 1004, 1027 (Fed. Cir. 2008).

[22] See Motorola Mobility, 156 F.T.C.

[23] Ruckelshaus v. Monsanto Co., 467 U.S.
986, 1006 (1984).

[24] Id. at 1011–12.

[25] Impression Prods., Inc. v. Lexmark Int’l,
, 137 S. Ct. 1523 (2017).

[26] Traditionally this concept applies to patents
so the term is usually rendered as “smallest salable patent practicing unit” or
SSPPU. But since interoperability elements may be protected by copyrights as
well as patents, the term “patent” is omitted here.

Featured Publications