Reexamination requested against two iPhone design patents (both found infringed by Samsung)

The WHDA law firm's US PTO Litigation Alert blog, authored by WHDA partner and experienced patent litigator Scott Daniels, reports today that anonymous ex parte reexamination requests have been filed against two Apple design patents:

• U.S. Design Patent No. D618,677, which a California jury found infringed by various Samsung phones last August; and

• U.S. Design Patent No. 618,678, which Administrative Law Judge Thomas B. Pender of the ITC found infringed by Samsung in an initial determination he made last October, a preliminary ruling that is now undergoing a thorough Commission review before a final ruling (currently scheduled for August 1 and appealable to the Federal Circuit) will issue.

Strategically, the D'677 is more important because most of the damages awarded in the federal litigation in the Northern District of California relate to design patents. Samsung will design around either one going forward, so the impact of injunctive relief doesn't matter much (in that regard, Apple's software patents-in-suit in both cases are more important). Judge Lucy Koh declined to overrule the jury on its design patent infringement findings because its decision was reasonable and not against the evidence, though she felt it was a close call. She also ruled against Samsung's request to declare this design patent invalid. A retrial of limited scope (it will only be about redetermining damages for 13 of the accused products) will be held in November. Thereafter, a final district court ruling will issue, which Samsung can then appeal to the Federal Circuit.

The reexamination requests discovered by WHDA's Scott Daniels are anonymous, but it's unlikely that anyone other than Samsung is behind them. Preliminary reexamination decisions concerning three other patents Apple is asserting against Samsung have been favorable to the defendant:

• About two months ago the USPTO issued a "final" (but not "final-final") Office action rejecting all but three claims of the '381 rubber-banding patent. The rejected claims include the one at issue in the California case.

• A first Office action concerning another California patent-in-suit, the '915 pinch-to-zoom API patent, tentatively rejected all claims. While not as important in terms of damages as the design patents-in-suit, this patent is the most valuable one of the multitouch software patents asserted in California.

• About a month ago the USPTO rejected, in another first Office action, the claims of Apple's RE'922 translucent images patent asserted in the ITC investigation.

In a formal sense it takes years (if a patent holder exhausts all appeals) before reexamination results in actual, definitive invalidation, as Apple recently pointed out. And the standard for an invalidity defense in an infringement case or ITC investigation is higher (clear and convincing evidence) than in reexamination (preponderance of the evidence). Nevertheless preliminary reexamination results (except perhaps first Office actions, which courts don't take too seriously) have persuasive impact on infringement cases -- not only in terms of whether the infringement court finds a patent invalid but also with a view to a stay (federal courts have more discretion in that regard).

With respect to Apple's design patent assertions against Samsung let me also mention quickly that the Hoge Raad (Supreme Court of the Netherlands) affirmed (appellate opinion in Dutch) in all respects except for litigation expenses a district court ruling that did not find Samsung's Galaxy Tab 10.1 to infringe an Apple Community design (the EU equivalent of a U.S. design patent).

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google lobbying front grossly overstates economic weight behind brief in Oracle Android/Java case

I've now located the fifth and last amicus curiae brief supporting Google against Oracle's Android/Java copyright appeal. The Computer & Communications Industry Association (CCIA) has published its submission to the Federal Circuit on the organization's website.

Last week I already said this about the CCIA's allegiance to Google:

Google is a driving force behind the CCIA. It has various other members, but there is no other member that the CCIA would have supported as consistently and aggressively in a variety of IP contexts in recent years as Google.

The CCIA's brief mentions refers to its decades of allegedly promoting interoperability. It is true that, like the EFF, it has done some pro-interoperability work. But just like Google and the equally Google-funded EFF, the CCIA also fails the litmus test for genuine and consistent advocates of interoperability: it doesn't fight against FRAND abuse. In a submission to the FTC, the CCIA warns that enforcement of FRAND licensing pledges could "diminish incentives to standard setting". Interestingly, the notion that affirmance of District Judge Alsup's denial of copyrightability to 7,000+ lines of declaring Java API code could "diminish incentives" to create and promote such platforms does not cross the CCIA's mind. In its FRAND-related submissions (also including one to the FTC and the DoJ) it conflates standard-essential patent (SEP) with non-SEP issues, which is a key part of Google's strategy that has failed all the way so far. True promoters of interoperability would never deny that SEPs raise issues that non-SEPs don't (even though some issues are relevant to all patents), and wouldn't discourage antitrust enforcement in this context and oppose implementer-friendly FRAND interpretations -- and, in particular, wouldn't suggest that it's fine to let SEP users renege on FRAND licensing pledges in order to give them leverage so they'll get away with infringement of non-SEPs. Simply put, the CCIA is all for IP when it's Google's IP, and all for infringement when Google infringes.

The first sentence describes the CCIA, but misleadingly blows out of proportion the economic weight behind its brief:

"The Computer & Communications Industry Association ('CCIA') represents over twenty companies of all sizes providing high technology products and services, including computer hardware and software, electronic commerce, telecommunications, and Internet products and services -- companies that collectively generate more than $250 billion in annual revenues."

It mentions Oracle and Sun's former membership (2011) and links to its list of members. Once you look that one up and think things through, the CCIA is suddenly only half as big as it claims. This is an amicus curiae brief -- Google as a party doesn't count. At the current run rate, Google's annual revenues are $56 billion. Microsoft is also a member of BSA | The Software Alliance and filed a pro-Oracle brief in its own name. Microsoft (annual revenues of $80 billion at current run rate) therefore has to be subtracted from the CCIA's list of members as far as this brief is concerned. Once you exclude Microsoft and Google, the potential amici represented by CCIA are smaller in revenues than Apple alone, which through BSA supports Oracle.

Oracle has clearly received far more powerful and meaningful support from amici than Google. Greater economic weight. Greater diversity. Greater independence (Oracle's amici include some of its competitors, such as IBM and Microsoft). At least four of the five, if not all five, pro-Google amicus briefs involve organizations and individuals paid by Google. While Oracle is supported even by archrivals, Google largely relies on its funded friends and their mobilization efforts.

I'm also underwhelmed by the content of the pro-Google briefs. They're all (which doesn't surprise in light of obvious orchestration) consistent in their interoperability-centric anti-copyrightability stance. Only the Application Developers Alliance at least raises an argument against resolving interoperability through "fair use" (though that argument comes down to fear of frivolous litigation, and the Alliance doesn't properly consider antitrust). I'm not saying that it's 100% certain the Federal Circuit will reject this theory of an interoperability-copyrightability dichotomy -- of course we all have to see what comes out of this. But if the circuit judges ask at the appellate hearing, whenever it will be held, whether interoperability can't also be ensured through fair use and, if all else fails, antitrust law, then Google and most of its amici will have to make an argument at the hearing that they didn't raise in their briefs -- and if the Federal Circuit deems "fair use" and FRAND the more appropriate and flexible tools for ensuring interoperability, then Oracle will be in great shape.

The CCIA's brief focuses on the international landscape, such as a ruling by the Court of Justice of the EU and various free trade agreements. I couldn't find any example in there of a problem that U.S. copyright law, with its robust "fair use" exception, can't solve unless copyrightablity is denied even to expressive and original creations. In fact, the CCIA's brief mentions the possibility of a fair-use-based solution all the time. Here are a couple of examples:

"Since this Court's 1992 decision in Atari Games Corp. v. Nintendo of America, 975 F.2d 832 (Fed. Cir. 1992), however, no less than five U.S. courts have permitted reproduction during the course of software reverse engineering under the fair use doctrine."

"The Legislative Council decided to broaden Hong Kong's fair dealing provision to more closely resemble the fair use provision of the U.S. Copyright Act."

Has the CCIA given up on non-copyrightability and is trying to at least support Google on the "fair use" side as a fallback position? Or does it want both non-copyrightability and the "fair use" exception to safeguard interoperability, though one such tool would be enough? Maybe this will become clearer at the appellate hearing.

But before we get there, Oracle will file a reply brief to Google's opening brief and the amicus curiae briefs, and since this is a cross-appeal, Google will also get to file a final reply on some minor issues.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google-supporting IP professors feel Oracle interprets the scope of copyrightability too broadly

For an appeal that Linus Torvalds thought was a waste of money by Oracle, the Android-Java copyright case has actually drawn a whole lot of interest, and the effort that Google, its funded friends and its few other supporters put into this shows that the outcome is far from the foregone conclusion that some people suggested a year ago.

There's another amicus curiae brief that I didn't list in my Friday post on the filings made last Thursday. It was filed by a group of intellectual property professors and uploaded to SSRN by Electronic Frontier Foundation (EFF) Vice Chairwoman Professor Pamela Samuelson. This suggests that she leads this group, so this may be the third (!) amicus curiae brief to have been orchestrated by the Google-funded and Google-loyal EFF. But I recognize that not all of the signatories are EFF activists or as Google aligned as, for example, Professor Mark Lemley, who supports Google's baseball extortion proposal to resolve FRAND disputes. In particular, I noted that New York University Professor Katherine Strandburg, who does support Judge Posner's FRAND ruling, is among the amici. That's a good sign, really.

The professors' brief has three sections. The first two sections seek to argue that the scope of copyrightable program code is allegedly narrower than Oracle claims. The third one talks about constraints on the design choices of subsequent programmers. I've compared the content of this brief to the three potential attack vectors against Google's position that I identified last week. My first concern was that interoperability is more of a "fair use" than copyrightability argument. I've since credited the Application Developers Alliance for at least trying to explain why "fair use" would not be the appropriate tool. In this regard, the brief of the App Dev Alliance also has a unique advantage over the one submitted by these professors, who only mention "fair use" in contexts in which they cite cases that support interoperability through fair use (which relates to, and supports, the third point I had made about Google's argument). The extent to which the professors, like Google and its other amici, try to conflate copyrightability and "fair use" considerations is best demonstrated by the following two consecutive sentences:

"[T]he interface procedures were unprotected aspects of the Sega program under § 102(b). [...] Nor did it undercut Accolade's defense that Sega had a licensing program for Genesis-compatible videogames in which Accolade declined to participate."

No one would ever argue that the existence of a licensing program is relevant to copyrightability. (You can only license what's copyrighted, but by offering a license you don't satisfy copyrightability criteria.) It's a "fair use" argument. But the professors say this right after citing to copyrightability law.

The unique part of the professors' brief, however, is its third section, which relates to my second point: large parts of Google's argument become irrelevant if the question of what constrained Google's design choices (after it made the fundamental decision to arbitrarily co-opt parts of the Java APIs, but anyway) is separated from what constrained the choices of Sun's programmers who created Java, and if the latter determines copyrightability, while the former may have a bearing on "fair use" (or FRAND, if antitrust were an issue, which it isn't because FRAND as well as GPL-based licenses are available and Google declined both). I will, therefore, focus in this post on the unique focus of the professors' brief, but before this I'll say only a few things about the narrow-scope argument.

Allegedly narrow scope of copyrightable program code

If Oracle were asserting against Google its copyrights in a book on object-oriented programming and claimed infringement by using and/or teaching OOP techniques described in that book, then Baker v. Selden would already have given the answer in the 19th century, and that answer would indeed favor Google. But the use of 7,000+ lines of declaring code from the asserted Java APIs is, in my opinion, far more on the "expression" than "idea" side of things.

I, too, would have a problem with the scope of software copyright if it became so broad that developers might infringe it inadvertently, or that they couldn't work around what it protects. I'm not afraid that I'd inadvertently write 7,000 lines of declaring code the same way someone else did, and/or to independently come up (or to be forced to come up) with the structure, sequence and organization of such a body of work.

Every software copyrightability case is about where to draw the line between function and expression. But no one can deny that the purpose of copyright is to protect originality, and if the structure, sequence and organization of 7,000+ lines of highly creative declaring code ended up being unprotectable, I believe copyright would fail to serve its stated purpose.

With all the legal argument about what different statutes and decisions say, the professors don't give even one example of a case in which a similarly complex body of original, highly creative code was denied copyrightability. There are "fair use" cases in which you could either copy small amounts of code or just make copies for your own development/testing purposes; there are cases in which non-original, preexisting data like the content of telephone directories was denied copyrightability despite being huge ("sweat of the brow" is not a substitute for creativity); but no U.S. court, before Judge Alsup's decision in question, found something like those 37 Java APIs uncopyrightable. If this ruling is affirmed, it's a game changer; but if it's reversed, then it just means that a new level of non-copyrightability is not reached.

The professors' brief does not address the second one of the two "axioms" Oracle's opening brief stated:

The Copyright Act's threshold for copyright protection is very low. Any "creative spark" counts, "no matter how crude [or] humble." Feist Publ'ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 345 (1991) (internal quotation marks omitted).

This is a Supreme Court decision that is central to Oracle's argument, and the professors' brief doesn't mention it even once -- maybe because it's inconvenient.

Constraints on design choices of subsequent programmers

The headline of the third section sums up this claim:

When a Computer Program Interface Constrains the Design Choices of Subsequent Programmers, the Merger Doctrine Precludes Copyright Protection for that Interface Design.

What's key here is the word "subsequent". Java's programmers were subsequent to other programmers, and Android's programmers were subsequent to Java's. What's not in dispute is that Oracle can't claim copyright in what was dictated at the time Java was created; what it disputes is that constraints on Android's developers, after they chose to copy some Java APIs, determine copyrightability.

The professors' related argument is built on top of Computer Associates v. Altai:

Altai established, and other courts later followed, the rule that external factors such as the 'compatibility requirements of other programs with which a program is designed to operate' limit the scope of copyright in programs because these factors constrain the freedom of design choices of subsequent programmers. Altai, 982 F.2d at 709-10.

Again, there's the word "subsequent". But that word does not appear in Altai anywhere near the concept of "freedom of choice" (only in completely different contexts). Let's look at the freedom-of-choice sentence in Altai (and the previous sentence):

"Professor Nimmer points out that 'in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques.' [...] This is a result of the fact that a programmer's freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program is intended to run; (2) compatibility requirements of other programs with which a program is designated to operate in conjunction; (3) computer manufacturers' design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry."

I honestly can't interpret that part as implying the word "subsequent" in the way in which Google's amici interpret it. All five items listed in that sentence undoubtedly make sense for constraints that affected both parties, CA and Altai.

Where Altai filters out elements dictated by external factors, it says this:

"The district court also found that the overlap exhibited between the list of services required for both ADAPTER and OSCAR 3.5 was 'determinated by the demands of the operating system and of the applications program to which it [was] to be linked through ADAPTER or OSCAR.' Id. In other words, this aspect of the program's structure was dictated by the nature of other programs with which it was designed to interact and, thus, is not protected by copyright."

So there was a third program here -- the operating system -- and dictated elements that both programs, the allegedly-infringing and the allegedly-infringed one, needed. It doesn't say that the asserted works dictated anything to the alleged infringers.

I know this isn't legal authority, but interestingly, the Wikipedia article on this ruling understands it this way, too:

"The court found that the similarity in services required by the operating system was due to the nature of the operating system, thus it was not protected by copyright."

Copyright, by definition, protects an original creator against subsequent copying. It doesn't help you against your predecessors. It wouldn't make sense to me if a copyist could get too much mileage out of the mere fact of being subsequent. And I don't think that that's what Altai meant.

There are IP professors supporting both parties' positions. Software companies and creatives are overwhelmingly in favor of Oracle's position. The Federal Circuit will think about what's the best policy to balance innovation and competition, and it will interpret such cases as Altai, so further down the road we'll know which professors are right in the Federal Circuit's opinion.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Application Developers Alliance lashes out at Oracle over its Android-Java copyright appeal

The weather is lousy here this weekend, so I might as well comment on a third amicus curiae brief filed in support of Google against Oracle's Android-Java copyright appeal. Yesterday I already discussed the two amicus briefs orchestrated by the Electronic Frontier Foundation (EFF). This morning I saw that the Application Developers Alliance issued a scathing press release on its amicus brief in this case, which it also published on its website. This means that three of the four Google-supporting amicus briefs have been published; only a Google lobbying front, the CCIA, hasn't done so yet, but its brief will soon appear on the Federal Circuit's electronic docket.

I already said in the post I just linked to that there's only one thing that app developers are truly concerned about: that if Oracle prevails, Google may have to bring Android back into the Java fold, necessitating rewrites, recompilations and redeployments of existing apps. The App Dev Alliance just doesn't admit this. It talks about all sorts of scenarios that aren't truly a concern to app devs. The true concern -- Google possibly having to modify Android's APIs over a transitional period of time -- is obviously something app devs don't like, but in that event Oracle would have prevailed in court and you can't blame the one who enforces the law -- you should always blame the one who violates it.

Oracle's appeal has elicited heat, not light, from Joel "on Software" Spolsky, the chairman of the App Dev Alliance. The organization's press release contains a quote from him that spans a relatively long paragraph but fails to present any reasonable argument. The organization's amicus brief has its shortcomings, which I'll address further below, but its style is reasonable -- unlike that of the Stack Exchange co-founder.

He starts with the words "Don't be fooled", but if there's anybody trying to fool people here, it's him. His first claim is that "APIs are not such a complicated thing". This contrasts nicely with what Google's own witnesses said at last year's trial about the skills required to design great APIs (click on an image to enlarge):

He then goes on to say that "[l]etting one company copyright APIs would be like letting one company have a monopoly on the use of the + sign [to mean addition]". As Mr. Spolsky likes to say, "don't be fooled": the asserted Java APIs consist of more than 7,000 lines, and if you want to learn about the creative choices involved (which don't exist for something like the plus sign), I can recommend an amicus brief submitted in support of Oracle by a group of computer science professors. None of the three pro-Google amicus briefs I've seen so far rebuts that submission, which I actually considered the most interesting one as far as the facts (not the law per se) are concerned.

After making such claims, which don't enhance the reputation of the organization he represents, Mr. Spolsky then calls Oracle's attempt "a ridiculous, shameful attempt to abuse the legal system for the purpose of extortion". Actually, Google was negotiating a license with Sun (before Oracle bought it) but decided to go ahead and release Android without a license.

Finally, Mr. Spolsky warns against "a catastrophic collapse of the ability of computer programs and systems to work together", which is just the doomsday version of what the EFF's briefs suggest. But I commend the Application Developers Alliance for at least making some limited effort to address what the EFF fails to explain: the fact that interoperability can also be safeguarded by other means than non-copyrightability. Congratulations: the App Dev Alliance is represented by a one-man-show appellate attorney from Texas while the EFF works with the renowned Samuelson Clinic in Berkeley, but it touches on the key issue the EFF doesn't even mention. Unfortunately, there isn't too much more substance than in the EFF briefs because the App Dev Alliance fails to give consideration to antitrust (I'll give a couple of examples further below), and its argument about "fair use" comes down to saying that regardless of whether a platform company would have a legal basis, it could always bring frivolous lawsuits:

"Oracle and its amici suggest that any balancing between the rights of an original author and those of a subsequent innovator should be done using the infringement prong of copyright analysis, particularly the doctrine of fair use. But the doctrine of fair use is a slippery one [...]

Were this Court to accept Oracle's position, almost every player in the industry would be susceptible to suits for copyright infringement when using declaring code. If liability for the entire market were determined based on a case-by-case determination of fair use (an already unpredictable doctrine), developers would be unable to adequately predict their exposure."

This is a very weak argument, but at least it is a fair-use-related argument. If a platform company actually started suing app developers for using APIs when writing apps (as opposed to stealing APIs to create rival platforms), you can be sure that the whole software industry -- and this includes Oracle's amici like BSA | The Software Alliance -- and software users (banks, for example) would stand by the first one who gets sued. They would fund his defense; they would submit amicus briefs. So let's be realistic: the doomsday scenario of someone trying to destabilize the software industry at large is a different thing than Oracle's dispute with a company that was actually negotiating a license before it decided to just take its chances. About two years ago District Judge Alsup looked at the evidence in this case and wrote that Google "may have simply been brazen, preferring to roll the dice on possible litigation rather than to pay a fair price". Now Mr. Spolsky accuses Oracle of extortion, and his organization's brief says "[t]he result that Oracle seeks in this case [...] would also jeopardize the livelihood of the millions of individuals employed as app developers or employed by publishers and platforms".

Someone who wants to sue on a meritless basis will always find a way to do so and doesn't need API copyrights for this. If the only purpose is to sue, the kinds of companies that create major APIs all have plenty of software patents over which they can sue -- and if necessary, they can always buy some more on the secondary market.

The brief is also one-sided. Just like the start-ups and the two non-Californian, notoriously IP-critical venture capitalists supporting Google, the App Dev Alliance fails to address the scenario in which little guys need IP to prevent the hijacking and supplantation of their creations by big companies employing "embrace, extend, extinguish" tactics.

Finally I'm going to talk about some of the specific examples given by the App Dev Alliance in its brief, and I'll pick those that show a fundamental misunderstanding or even ignorance of antitrust realities.

There's really a misconception out there. It's wrong to conclude from the fact that many companies didn't assert API copyrights against those reimplementing APIs that there was/is no copyright protection. As I explained in my commentary on the EFF's briefs, in most cases there's simply a commercial interest in API adoption, there's "fair use", and in those cases in which someone might act anticompetitively, there's always antitrust law.

The App Dev Alliance isn't too familiar with antitrust law. It discusses the MySQL-related part of the Oracle-Sun merger control process (a context in which I worked very hard against Oracle) and refers to "the European Commission on Competition". There's no such thing though. The European Commission is the EU's executive government. Among other things it also handles antitrust regulation. The specialized department in charge of antitrust enforcement is the European Commission's Directorate-General for Competition (DG COMP).

Like I said, I was intimately involved with that process (and had previously served as a strategy advisor to MySQL's CEO for three years). The App Dev Alliance is absolutely wrong when it says that "[t]he Commission was particularly worried that permitting Oracle to control the MySQL APIs would reduce the choices available to consumers and increase prices of database software". The facts can be found on the Internet. As Professor Eben Moglen's submission to the Commission explained, the competition concerns centered around the level of control Oracle would have over MySQL, despite its free and open source software (FOSS) status, due to the "copyleft" effect of the GPL license (requiring derivative works to be published under the GPL or not published at all). This also involved so-called storage engines, which rely on an API. The concern was just that Oracle could have modified MySQL's code for new versions released after the acquisition in ways that would have made it impossible for storage engines to run. In order to do that, you don't need copyright: you just have to be the one releasing and compiling the version of the code everyone uses. The other related issue was copyleft, not copyright. It was about whether Oracle could enforce the GPL's copyleft provisions against third-party storage engines, requiring them to release their code under the GPL, which would have killed most of their revenue opportunities. The App Dev Alliance's brief mentions Oracle's pre-clearance commitments concerning MySQL. The explanation I just gave is supported (and the distorted version of the App Dev Alliance proven wrong) by paragraph 646 of the final Commission decision:

"The notifying party [i.e., Oracle] has thus publicly declared that for five years it would continue to support MySQL's pluggable storage engine API and it would waive the copyleft provision of the GPL for third-party storage engine providers who implement this API. Oracle's non-assertion pledge should not be understood to imply that all cases in which a third-party storage engine implements this API constitute violations of the GPL. It can therefore be expected that third party storage engine vendors will be allowed to provide to their customers a combination of MySQL under the GPL and the storage engine (including if that is under a proprietary license) as an integrated product."

Since copyleft can only be enforced by means of copyright (but note that Oracle waived only its right to enforce copyleft, not the copyrights it acquired), the paragraph I just quoted additionally shows that the European Commission and Oracle don't consider APIs generally non-copyrightable, contrary to what Google's amici incorrectly portray as well-settled expectations of this industry.

The App Dev Alliance says that under a settlement with the U.S. government (relating to competition in the browser market) "Microsoft was forced to make its APIs publicly available so that other developers could utilize the declaring code for products, including web browsers, that were fully compatible with the Windows operating system". Note that the issue was public availability. If someone doesn't make APIs publicly available (Google, for example, has various APIs, particularly related to advertising, that it consistently refuses to make available), you can't solve the problem with non-copyrightability -- but you can with antitrust.

Yes, programmers expect to be able to use public APIs for certain purposes. But this expectation doesn't change copyright law. You can also have expectations based on what most companies do voluntarily, and on "fair use" and antitrust law.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

EFF's amicus briefs in Oracle v. Google suggest non-copyrightability is only path to interoperability

Many roads lead to Rome, but if all you have is a hammer, everything looks like a nail. I'm sure you've heard these two proverbs before, but the authors and signatories of two EFF-orchestrated amicus curiae briefs supporting Google against Oracle's Android-Java copyright appeal did not bear them in mind when making their submissions to the Federal Circuit, proposing to throw out the baby with the bath water by denying copyrightability to some of the most creative and expressive elements of computer programs for the sake of (whatever they mean by) interoperability.

In my previous post I explained that Google and the EFF's advocacy of "interoperability" is anything but principled, and that Android is not interoperable with Java by any stretch of the imagination. But for the purposes of this present post I'm going to forget about Android's incompatibility with Java and focus on the question of how to ensure true interoperability while affording software creations a reasonable degree of intellectual property protection.

In most cases software copyright isn't an obstacle to interoperability because the creators of application programming interfaces (APIs) frequently have an interest in the adoption of their creations. Self-regulation works, and it actually is possible to do clean-room implementations of the Java APIs, subject to reasonable terms and conditions that Google didn't want to accept. But every now and then there could be a problem with a right holder wielding copyright in an effort to prevent interoperability, just like there are standard-essential patent (SEP) owners, like Google, who pursue injunctions. What do we do then?

If true interoperability is at stake, the "fair use" exception might work. The EFF's "Start-ups" brief mentions "fair use" only twice, in the same paragraph, in an effort to portray "fair use" cases (Sony, Sega) as non-copyrightability decisions. Its "Scientists" brief doesn't mention it even once.

Even if "fair use" failed in a particular case to ensure interoperability (for example, it's specific to copyright and doesn't apply to patents), there would always be antitrust law as a last resort in order to obtain a compulsory license on FRAND terms. The EFF's "Start-ups" brief doesn't mention "antitrust" or "competition law" at all. Its "Scientists" brief refers to it only once, in connection with UNIX, but fails to address it otherwise, even in connection with IBM's conduct in the mainframe business and the effect it had on its PC-related strategies.

Both briefs presuppose that there is only one tool: copyrightability. But besides the non-copyrightability hammer, there are those other tools I just discussed. All it takes the appeals court to disagree with Google's lawyers' and amigos' anti-copyrightability argument is to agree with Google's in-house copyright counsel William Paltry, who advocated that the "appropriate balance" can best be struck with the help of "fair use" and other tools. The whole notion of an interoperability-copyrightability conflict goes away once there is a determination that interoperability is irrelevant to copyrightability and better resolved with the help of more flexible and use-specific tools. Copyrightability should be consistent from the moment of creation, just like patent offices don't reject applications that could result in standard-essential patents because of their subject matter (and patent law doesn't even have the "fair use" tool). Addressing protection first, access later means that creators don't become the victims of their own creations' success, while still being able to take market power and "expectations" into consideration, with the benefit of 20/20 hindsight, when someone wants to use someone else's creation. But some people want the Federal Circuit to destroy intellectual property with a hammer only to deprive itself and all other courts in the United States of the opportunity to decide on interoperability based on what happens to an API after its creation and on what a defendant wants to do with it and to it.

The EFF's submissions are, of course, consistent with Google's appellate brief, which even argued that intellectual property protection can be lost over time, mentioning Aspirin as one example. Not only are trademarks, contrary to copyright, a totally use-dependent intellectual property right but Google's lawyers omit a historic fact. A couple of readers contacted me on Twitter shortly after the post I just linked to and noted that Bayer lost trademark protection for Aspirin because it had to give up certain rights under the Treaty of Versailles (after World War I). The most diplomatic term for this is expropriation.

I'm now going to explain why there are (at least) two EFF amicus briefs, not just one, and then I'll quote some passages from those briefs and comment on them.

Two EFF amicus curiae briefs: one submitted in the name of "Computer Scientists", the other in the name of "Innovators, Start-ups, and Investors"

On Thursday the EFF issued a press release on the first of its amicus briefs in this case, which the EFF submitted as counsel to a group named "Computer Scientists". The EFF also published this brief. I have the greatest respect for these amici, which the EFF listed on its website with short bios, and for the EFF attorneys representing them. But for the reasons I explained in a previous post, all those Google-supporting amici (the ones on that list and all others) fail to counterbalance the economic weight of those supporting Oracle, and the EFF used FUD to mobilize people and companies for its cause. It says something that most amici only signed up as private persons because they couldn't get their current or former employers to support Google on this one.

The second EFF-orchestrated brief, published near-simultaneously on academic document site SSRN, is positioned as a submission by "Software Innovators, Start-ups, and Investors" and was filed by the Law, Technology, and Public Policy Clinic of the EFF's Vice Chairwoman of the Board, Professor Pamela Samuelson. On its website the Samuelson Clinic lists the EFF as its first client. One of the Computer Scientists' counsel is Professor Jason Schultz, who coauthored the Defensive Patent License with his colleague, Assistant Professor Jennifer Urban. Professor Schultz also was an Assistant Professor at the Samuelson Clinic while the DPL was originally conceived. The "Software Innovators, Start-ups, and Investors" include two former EFF leaders -- co-founder Mitch Kapor and former Chairwoman of the Board (1991-1998; the EFF was founded in 1990) Esther Dyson -- and Esther Dyson's EDventure Holdings. (The "Computer Scientists" also include several EFF board members: John Perry Barlow, Brian Behlendorf, David Farber).

Far be it from me to be disrespectful of Professor Samuelson and her staff. And I'm not accusing the EFF of circumventing any filing limitations or of finding ways to get more speaking time at the appellate hearing. I just want to shed light on the fact that support for Google is not nearly as broadbased as the EFF would have us believe. This effort is orchestrated, not organic.

Oracle's amici represent, among other things, a substantial percentage of software R&D, and include some of Oracle's fiercest competitors, while Google has not gathered support from any of its rivals.

The signatories of the EFF's briefs don't have a comparably high share among computer scientists, software innovators, start-ups, and investors as Oracle's corporate amici have in the overall software market. For example, there are only two venture funds among the investors the EFF mobilized: Foundry Group and Union Square Ventures. Those aren't California-based, which is where most of the venture capital action in the U.S. is (Sand Hill Road). They're also great, but only two, and about 90% of the anti-software-patent commentary that you'll find in the media (including social media) from venture investors comes from partners of these funds (Brad Feld and Fred Wilson), who are apparently more anti-IP than I thought (and than they probably are, but it appears to be easy to mobilize them for this kind of agenda).

The two EFF briefs are the only ones to have been published so far.

Commentary on select passages from the EFF briefs

The EFF's "Computer Scientists" brief talks a lot about the IBM PC and its BIOS (Basic Input/Output System) as an example of an open API and speculates that "IBM enforced copyright on the BIOS source code and would certainly have used copyright to control reimplementations of the BIOS API if the law allowed". But there's a much better explanation for IBM's decision. From the 1950s on (and even at the beginning of this decade) IBM had antitrust problems with its mainframe monopoly. While mainframes are mentioned in that same brief as one of various industries allegedly made innovative and competitive by "[t]he freedom to reimplement and extend existing APIs", and an AT&T consent decree is mentioned in connection with UNIX, the 1956 IBM Consent Decree is omitted. It's no less famous than the AT&T one, but less supportive of the EFF's argument. It shows that interoperability can be achieved by antitrust means. And when IBM created the PC, it had learned its lesson well and tried to steer clear of running into the same problems again in the next computing market. So it allowed the creation of IBM PC compatibles -- basically, in order to obviate the need for another consent decree.

One of the "Computer Scientists" is Andrew Tridgell, who created Samba, which the brief also discusses. Again, the antitrust approach worked, and Microsoft was required by the European Commission to offer a FRAND license to all relevant intellectual property (patents, copyright, whatever). The EFF already made a Samba-based anti-copyrightability argument last year, but it fails to explain why non-copyrightability is the answer (and "fair use" and FRAND are not).

Some of the EFF's examples are protocols that are far simpler than the Java APIs in question. For example, HTTP or the menu structure at issue in the Lotus case. I'm not saying that there's no copyright in simpler things than the Java APIs, but there's definitely a stronger case for non-copyrightability in cases like HTTP or a spreadsheet menu than in the Java case.

The EFF's briefs also suggest that software is cheaper if APIs aren't copyrightable. For example, the EFF gives an example of how NASA allegedly saved money because it was able to continue to use some old manufacturing robots even though the relevant APIs were "orphan works" ("The freedom to reimplement APIs also helps rescue 'orphan' software or data—systems whose creators have either gone out of business or abandoned their product in the marketplace."). The EFF then links this to budget cuts and the latest sequester. This "logic" runs counter to the positions taken very recently by the Federal Circuit's Chief Judge Rader in a snowplow patent case: "While the general public certainly enjoys lower prices, cheap copies of patented inventions have the effect of inhibiting innovation and incentive. This detrimental effect, coupled with the public’s general interest in the judicial protection of property rights in inventive technology, outweighs any interest the public has in purchasing cheaper infringing products. In sum, the public has a greater interest in acquiring new technology through the protections provided by the Patent Act than it has in buying 'cheaper knock-offs.'"

The EFF's "Innovators, Start-ups, and Investors" brief says a lot of things about the value of interoperability that I wholeheartedly agree with, beginning with the first paragraph:

"Interoperability between programs and systems is key to software innovation. It allows systems to connect and individuals to apply knowledge and skills from one environment to another. By easing the way for software developers to build upon existing platforms, interoperability allows efficient software ecosystems to grow, fueling the development of innovative new products and services and increasing competition to the benefit of consumers."

It's also true that "[c]loud services rely heavily on interoperability--and specifically on APIs--to work". But neither EFF brief explains why the denial of copyrightability is the only way to ensure interoperability. There's some talk about legal certainty, but if "fair use" was too uncertain to be useful, it wouldn't be as important as it is. FRAND is also given more and more meaning by courts (despite Google's efforts to derail or delay some of the related processes).

What I strongly dislike about the "Innovators, Start-ups, and Investors" brief are various references to the "use" of APIs. That's not at issue in this case. Oracle is happy to let anyone "use" the Java APIs to write Java apps.

The other key point I want to criticize about it is the lack of balance when it comes to the interests of start-ups in connection with intellectual property protection. Professor Samuelson herself has conducted studies such as the Berkeley Patent Survey that show, for example, that start-ups with patents are more likely to be funded by venture capitalists. It's simply wrong -- and inconsistent with the Samuelson Clinic's findings in other contexts -- to suggest that weaker IP, merely by lowering entrance barriers in some areas, is the perfect environment for startups to flourish. If every incumbent could force a startup out of the market by disallowing any use of APIs, there would be a problem, but that's not what would result from a reversal of the district court's non-copyrightability decision. There's another way to look at it: if even Oracle couldn't prevent Google from hijacking Java, what would a startup do if Google decided to supplant its products or services? IP is quite often needed to give startups leverage against incumbents.

The right balance must be struck, and in my opinion Google and the EFF's positions are too far on the anti-IP side. That's why I can't support them, though I support the cause of interoperability (more consistently than they do).

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google and EFF have credibility deficit in 'interoperability' context, try to redefine the term

Non-governmental organizations (NGOs) play an important role in democracy. While corporations have interests, activists are loyal to a cause regardless of whom it benefits. Even if I disagree with an NGO's positions and objectives (for example, because it demands too much of a good thing), I can still respect or even admire the idealism with which activists pursue a given cause, if they are indeed loyal to it. But I have no respect for those who under the guise of grassroots activism advance, instead of a noble cause, corporate interests, regardless of whether they do so for financial gain or due to ideological bias (or both). When this happens, they become dishonest and use double standards. And when I say "they", this rarely includes well-meaning members and external supporters but is usually limited to the leadership of such organizations.

There's a certain, transparent pattern. The Electronic Frontier Foundation (EFF) intermittently criticizes Google in contexts in which it's only about "end users v. Google" (1, 2), but never takes action against Google when it's about "Google v. other corporations", with other companies than Google promoting the interests of end users. Google knows that the EFF will give inconsequential lip service to its defense of digital liberties in fields in which Google doesn't face more resistence than a few screaming activists who can't force it to change any of its practices, but wherever Google has conflicts with its peers and could actually be forced by regulators or courts to do the right things, it knows that it can count on the EFF's support or, at a minimum, its deafening silence. Always.

I attribute this pattern of non-principled behavior to the combination of two factors. On the one hand, both organizations are anti-IP. On the other hand, Google has generously rewarded the EFF for its loyalty on the important issues.

Google and the EFF's claim to defend "interoperability" in connection with the Android/Java copyright case is the height of hypocrisy. First, Android isn't interoperable with Java, as Android co-founder Rich Miner admitted (click on the image to enlarge or read the text below the image):

"Q48. Does Android support existing Java apps?

A. No.

Q49. Is Android Java compatible?

A. No."

Nuff said.

Second, antitrust regulators and courts have had (and still have) to intervene against Google's (Motorola's) assault on interoperability by reneging on FRAND licensing (and even on reciprocal-licensing) commitments relating to patents declared essential to telecommunications and video standard, attempting to hold end users hostage by threatening to disconnect many millions of users from cellular networks and to prevent them from watching video material they or their friends had purchased or recorded. In the U.S., the FTC found Google's (Motorola's) conduct anticompetitive and stressed that this hurts consumers, and the European Commission recently issued a Statement of Objections (SO), a preliminary antitrust ruling, for the same reasons. Policy makers (Senators, Congressmen) and industry associations including an organization of retailers (who sell everybody's products) expressed profound concern over this outrageous conduct on multiple occasions -- but the EFF did not submit a single amicus curiae brief or position paper to contribute to the pressure others put on Google.

Just like Google has reneged on FRAND licensing and grant-back commitments, the EFF has reneged in this highly important context on its mission of "defending your rights in the digital world". I regret that I have to say so, but someone has to call them out for it.

I've run Google searches on the EFF's website with terms like "FRAND", "RAND", and "standard-essential patents". I found only one statement that the EFF itself made (as opposed to court filings or other official documents it nonjudgmentally republished). About a year ago, the EFF argued that Judge Posner's two-way Apple v. Motorola ruling was evidence of a broken patent system and said about Judge Posner's denial of injunctive relief over FRAND-pledged SEPs that it's "glad to see Judge Posner reaffirm this important principle" (that injunctions aren't granted over such patents). That's all there is. (They also used a regulatory statement on FRAND as an argument in a non-FRAND case, but that's just opportunistic behavior and doesn't promote FRAND.)

But where is the EFF now that the FRAND part of Judge Posner's ruling is being appealed by Google? The Posner appeal has prompted a similar number of amicus curiae briefs as Oracle v. Google. The EFF is silent. It will speak out against Google where it doesn't matter, but where Google has a dispute with Apple and a similar one with Microsoft, the EFF doesn't care about "your rights in the digital world".

If you look for true defenders and promoters of interoperability, you can't count on the EFF. You have to look elsewhere. Your rights in the digital world are actually being defended vigorously by Oracle's lead counsel in the Google copyright appeal, Orrick's Joshua Rosenkranz, who is also fighting -- against Google -- for affirmance of Judge Posner's FRAND ruling. Oracle, as a member of BSA | The Software Alliance, also supports this noble cause. Microsoft's landmark FRAND case against Google's Motorola in the Western District of Washington has helped shape the law in consumer-friendly ways. But the EFF won't support any other company against Google, no matter how noble and important the cause is. That's where it draws the line -- and that is not a principled stance on interoperability.

The EFF has orchestrated at least two of the four amicus curiae briefs that were submitted on Thursday in support of Google against Oracle's copyright appeal. These are also the only two pro-Google amicus briefs to have been published so far, and I will discuss their content (and the substance in them that I was hard-pressed to find) in a subsequent post. Before doing so, I wanted to draw more attention to Google and the EFF's insurmountable credibility problem in connection with interoperability. If Java apps don't run on Android, they have the chutzpah to call this state of affairs "interoperability". But if Google seeks sales and import bans over H.264, the format in which most of the world's digital video material is stored, or cellular standards like GPRS and 3G (UMTS), or WiFi (WLAN), everything's fine. I mean: fine with them. Not with me.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google says Skyhook's assertion of 98 patent claims makes lawsuit unmanageable

The first filing in a smartphone-related patent lawsuit bearing a June 2013 date was made by Google, which a few minutes after midnight by Eastern Time brought a "motion to require Skyhook to reduce the number of asserted claims and provide adequate infringement contentions" in the parties' federal litigation in the District of Massachusetts. According to the motion, Skyhook "is asserting infringement of 98 patent claims across 13 patents", which Google believes "make this case unmanageable, and it would be impractical to attempt to try to a jury a case involving even a fraction of the claims Skyhook is asserting". Therefore, wants the district court to "require Skyhook to reduce the number of asserted claims to a manageable number, for example a limit of 20 non-duplicative claims, and to provide adequate infringement contentions".

The case actually became so inflated because Google succeeded in getting a second lawsuit by Skyhook, filed in September 2012 in Delaware over nine additional patents, transferred to Massachusetts (where the first such case had been filed two years earlier) and consolidated into the earlier-filed case, resulting in considerable delay (the trial slipped into 2014). Google, like other defendants, wanted a delay. But it also wants to reduce the number of patents it has to defend itself against whenever the case may ultimately go to trial.

Here's Google's motion, which also lists all of the current assertions (this post continues below the document):

13-06-01 Google Motion to Require Skyhook to Narrow Claims

The list of asserted claims includes a total of nine claims from the '245 and '988 patents, which the court declared invalid on summary judgment and which Skyhook is only asserting (Google wants them dismissed anyway) to preserve its rights on appeal and a possible remand. These claims are, therefore, irrelevant to the question of whether the case is triable to a jury: a jury would never have to look at patents the court previously declared invalid.

Google does have a point that some reduction of the number of claims is necessary. I don't think Skyhook ever expected to take all of the asserted claims to trial. Presumably Skyhook wants more clarity on Google's defenses before it drops any patents. That may be the challenge here: determining a course of action that enables narrowing on a reasonably informed basis.

It's unusual for a defendant to bring a formal motion to require such a reduction. Usually the courts take such initiatives. Judges have two kinds of leverage to require U.S. patent plaintiffs to narrow their cases:

• Under Katz (a decision cited by Google in its motion) they can throw out duplicative claims. Plaintiffs can, however, often demonstrate that claims are non-duplicative.

• They can tell plaintiffs that there will be further delay unless they cooperate and narrow their cases.

Judges can accelerate the process through summary judgment rulings, some of which result in the immediate removal of patent claims while others at least provide an indication as to which claims are not too likely to succeed at trial.

Google says in its motion that it "intends to file a separate expedited motion seeking relief from the schedule shortly". Again, defendants generally try to delay. I'm sure Skyhook will find a way forward for its case.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|