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 curiae 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 171.206)

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 171.102)

F. Further Exceptions for Screenshot Sharing (Section 170.403)

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 issues.

  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 Interoperability

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.

  • B. Licensing of Possible Copyrights in Interfaces (Section 171.206)

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.

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

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 technologies.

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

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 them.

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.

  • E. Definition of “Interoperability Element” (Section 171.102)

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.

  • F. Further Exceptions for Screenshot Sharing (Section 170.403)

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 developers.

  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.

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

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.

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

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 process.

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.

  • B. Publication of Licensing Rates (Section 171.206)

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.

  • C. Exhaustion of IP Rights (Section 171.206)

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.

  • D. Licensing to Any Requestor (Section 171.206)

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.

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

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.

  • F. Smallest Salable Practicing Unit (Section 171.206)

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.

  • V. Conclusion

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 Standards, 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 21–35.

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

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

[8]   See Duan, supra note 3, at 10.

[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 LLC (“Oracle II”), 886 F.3d 1179 (Fed. Cir. 2018).

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

[15] See Oracle Am., Inc. v. Google Inc., 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 LLC, 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. 147.

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

[24] Id. at 1011–12.

[25] Impression Prods., Inc. v. Lexmark Int’l, Inc., 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.