Archive for January, 2013

January 9, 2013

Standard-Essential Patents

by Steve Bellovin

The FTC has just announced a broad settlement with Google.  Let’s talk about one aspect, the consent order on “standard-essential patents” (SEP).  It’s an important issue; the New York Times noted that “legal experts say Google’s settlement with the F.T.C. signals progress in clarifying the rules of engagement in high-tech patent battles, and thus could ease them.”

Patents have long been a part of American society.  Indeed, the Constitution (Article I, Section 8) explicitly endorses them:

The Congress shall have Power …

To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries

Thomas Jefferson was a principal architect of the American patent system (and indeed, as the Supreme Court has noted, was the “first administrator of our patent system”).  He found patents, on the whole, to be beneficial, and noted that “An act of Congress authorising the issuing patents for new discoveries has given a spring to invention beyond my conception.”  Still, he was cautious.  By definition, a patent is a monopoly, albeit one presumed to be a net benefit to society.  The Supreme Court, channeling him, put it this way:

The grant of an exclusive right to an invention was the creation of society—at odds with the inherent free nature of disclosed ideas—and was not to be freely given. Only inventions and discoveries which furthered human knowledge, and were new and useful, justified the special inducement of a limited private monopoly. Jefferson did not believe in granting patents for small details, obvious improvements, or frivolous devices. His writings evidence his insistence upon a high level of patentability.

The issue of monopoly is the crux, though.  A patent is not the right to do something; rather, it is the right to prevent others from doing it.  Suppose, for example, that you hold the patent on the pencil and someone else holds a patent on an eraser.  Without the consent of the other, neither of you can manufacture pencils with attached erasers; such a device would infringe both patents.  (The question of whether or not this combination is itself patentable is a complex one; I won’t address it here.  For now, let it suffice to say that a patent may not be granted “if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains”.)

Beneficial monopolies can arise from another scenario: standardization.  Technical standards more or less by definition create monopolies; the chosen solution becomes the one everyone needs to implement: “[i]n the case of a standard that effectively requires the use of a proprietary technology, the standard, if adopted (whether de facto or by formal process), can imbue the technology with market power that it previously lacked. Thus there is the potential for monopolization, or more minimally a raising of rivals’ costs, through the conjunction of an adopted standard and a proprietary technology”.  Note especially the last clause: “the conjunction of an adopted standard and a proprietary technology”.  Therein lies the rub: how should the combination of a patent—one form of beneficial monopoly—and a technical standard—another form—be handled?

The issue can be thorny.  Not surprisingly, standards organizations have long recognized this problem, though different ones have taken different approaches.  The Internet Engineering Task Force (IETF) requires full disclosure of applicable patents, and lets the working groups decide if the proffered terms are acceptable.  The World Wide Web Consortium (W3C) requires a commitment to royalty-free licensingIEEE (the Institute of Electrical and Electronics Engineers)insists on a commitment that “a license for a compliant implementation of the standard will be made available to an unrestricted number of applicants on a worldwide basis without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination”.  In other words, the means and mechanisms differ, but the overall goal is the same: to ensure that many different parties can implement the standard, thus mitigating the monopoly characteristics of the patent.

Trouble can arise when companies abuse the standards process, especially with respect to patents.  The FTC has long taken a dim view of abuse: “This settlement makes it clear that firms cannot commit to an open standard, and then, after it becomes successful, assert patent rights in an effort to block use of the design or drive up the price through royalty payments.”  (In this case, Dell had asserted a patent pertaining to a video card interface design after it was accepted as a standard.)  Some patents, though, are more problematic than others.

If a patent applies to something within a device, it can be easier (though not free) to work around.  Consider that patent in the Dell case.  If that patent wasn’t licensable at a reasonable cost, a company could have designed its own interface to its own cards.  That’s more expensive (and hence still potentially abusive), because it precludes buying off-the-shelf, standards- (and patent-) compliant ones; still, it’s probably doable.  Life is much harder when the patent concerns ways of interacting with the outside world.  A cell phone, for example, must talk to the cell phone network; if it can’t, it’s nothing but a fancy toy.  No single party is big enough to build their own world-wide phone network; if nothing else, suitable radio spectrum isn’t available.  That’s why the consent order with Google is so important: Google has agreed that it will not seek injunctions to bar companies from using Google’s SEPs while license negotiations are taking place.  The issue of what constitutes a “FRAND”—fair, reasonable, and non-discriminatory—license fee is not resolved; however, it does prevent Google from keeping other companies out of certain markets entirely.  “The FTC concluded that this type of patent hold-up is precisely what the standard setting organizations sought to prevent by instituting FRAND licensing requirements”.  (In a related item, the Justice Department and the U.S. Patent Office have issued a statement saying that the International Trade Commission should not, in general, grant exclusion orders based on SEPs.)

“Talk to the outside world” is one aspect of interoperability.  Some of the devices affected by this settlement (e.g., smartphones and tablets) have to interoperate at many different levels.  Consider the iPhone.  It has to adhere to the myriad technical specifications needed for several different cell phone standards (2G, 3G, and CDMA, and LTE for the newer models); all of those come in different flavors for voice and data, and don’t forget text messages.  There are standards for WiFi and for USB.  There are IETF and W3C standards that say how to send and receive email and web pages.   JavaScript has its own definition.  JPEG standards have to be followed, not just for the camera but also for web pages.  Even many of the apps which don’t overtly use these mechanisms employ them under the hood, for their own purposes.  After all, why invent your own image or transport formats if you can use JPEG and HTTP over TCP instead.  All of these standards are needed; any may be subject to patents.  (A few months ago, I asked the head of a major standards body which areas in his organization were most affected by patents.  His answer was succinct: “All of them”.) 

It is no stretch to say that without these standards, smartphones couldn’t exist.  This settlement will allow for “reasonable” incentives for inventors, while preserving the interoperability necessary in today’s interconnected world.

January 2, 2013

COPPA and Signaling

by Steve Bellovin

As has been widely reported, the FTC recently amended its COPPA Rule enforcing the Children’s Online Privacy Protection Act. There’s a lot to be said about the new amendments to the Rule—indeed, a lot is being said—but as this is the FTC Tech Blog, I’m going to restrict my comments to technical aspects. Today, I’m going to talk about signaling—the way that a website can signal its COPPA status to the operators of other sites who provide it with some of the content that users see.

If you run a simple website, complying with COPPA is reasonably straightforward. If you’re covered—that is, if you have actual knowledge that a child is using your site, or if your content is directed towards children younger than 13— you must get parents’ permission before collecting personal information from kids. (N.B. Please see the formal rules to learn who is covered and for the precise definition of a “website or online service directed to children.” The Federal Register notice with the new rules is 167 pages of PDF; I’m not going to try to interpret or even summarize all that text. And ask your lawyers, not your computer scientists.) However, many commercial websites contain content from multiple sources: ad networks, third party plug-ins, etc. Who should be responsible for their COPPA compliance?

The announcement of the amended Rule makes this very clear: “The definition of an operator has been updated to make clear that the Rule covers a child-directed site or service that integrates outside services, such as plug-ins or advertising networks, that collect personal information from its visitors.” If it’s on your site, you’re responsible—period.

The announcement also says that “the definition of a website or online service directed to children is expanded to include plug-ins or ad networks that have actual knowledge that they are collecting personal information through a child-directed website or online service.” How can a plug-in “have actual knowledge” that it is on a child-oriented site?

To answer that question (and to return to purely technical matters), we have to take a deeper look at how a website is constructed. When a user types a URL into a browser or perhaps clicks on a link on some other site, the browser contacts the site to retrieve an HTML (Hypertext Markup Language) file. That HTML file, in turn, can contain pointers to other content necessary to render the page: style sheets, images, IFRAMES (mini-webpages embedded in a larger one) and more. The user’s browser, not the website, then fetches these additional HTML files, which in turn can contain other embedded content.

In many instances, a plug-in or other site or service offering up content will not know everywhere that it has been embedded, nor can it easily control or prevent embedding. A site may receive a Referer: header, but sending those headers is optional. (In fact, some browsers let you disable sending them.) If one is present, it may be from yet another party; often, references in the original HTML file point to, say, an ad network, which in turn points to the actual ad. But let’s assume that there’s a genuine Referer: header that really mentions the COPPA-covered site. Does the embedded site then “have actual knowledge”? That’s not likely without further information.

We can resolve this problem if there is explicit signaling from the embedding web page to the plug-in or other included content. This could be accomplished by a joint effort of industry members. Indeed, such signaling is already in place for other purposes; ad networks generally prescribe how to request ads that are relevant to the page on which they’re being displayed. Here’s a random example I stumbled on recently in a news article about North Korea:

http://ad.doubleclick.net/adj/trb.chicagotribune/news;;ptype=s;slug=sns-rt-us-korea-north-touristbre8bk10z-20121221;rg=ur;ref=chicagotribunecom;pos=T;dcopt=ist;sz=728×90;tile=1;ca=CrimeLawandJustice;en=SeoulSouthKorea;at=CrimeLawandJustice;at=SeoulSouthKorea;at=PhysicalFitnessandExercise;at=CivilRights;at=PyongyangNorthKorea;u=sz%7C728x90%21;ord=84919093?

Quite obviously, Doubleclick is being passed information about the website, the article name, the countries involved, and various keywords relevant to the topic. It would be no stretch at all to include a “COPPA-covered site” flag as well.

We could do better than this if there were a formal standard or agreed-upon convention, though. What might one look like? It has to be something in the URL, since that’s the only thing that a browser will understand and be able to pass on. While it’s possible to put the signal into the hostname or username/password sections of the URL, those are awkward. A better idea is to put the signal into the path. Thus, an IFRAME directive from a COPPA-covered site might start something like this:

A more general form, perhaps to be adopted by the W3C, might look something like this:

http://hostname/__RESTRICT:US-COPPA13,EU-PRIVACY,etc/…

Furthermore, if the embedded content itself embeds other content from yet other sites or sends Redirect messages, it would be obligated to pass along the COPPA signal. Note that in the first scenario, one couldn’t, even in principle, rely on the Referer: line, since it only goes back one hop.
Your plug-in doesn’t collect any information that would implicate COPPA? No problem; with the Apache web server (and almost certainly with other popular web servers), configuring the system to ignore such flags if irrelevant is almost trivially simple.
The same principle can be applied to links to platforms (e.g., a Facebook “Like” button, a Google “+1” button, etc.): the embedding site is the only component that knows at the outset at whom it is directed, and hence must pass along that signal.
This can’t be done today to embed arbitrary content; as I said, there are no current COPPA signaling standards. But there’s an opportunity here for industry action to make such signaling a real option for tomorrow.