In mid-July, Administrative Law Judge (ALJ) Carl Charneski made an initial determination (a recommendation for an ITC decision) that HTC was deemed to infringe two Apple patents with its Android-based devices. That initial determination related only to Apple's first ITC complaint against HTC. Shortly before that recommendation, Apple had filed a second ITC complaint against HTC, and there are several other lawsuits going on between those two companies.
The target date for the final decision on this investigation is December 6, 2011. The final decision is taken by the six-member Commission, the ITC's highest-ranking decision-making body. The Commission can either adopt or review the ALJ's initial determination.
Petitions for review
On August 1, 2011, the following petitions for review were filed:
Apple argues against a review. Apparently, Apple would rather take two birds (two infringed patents) in the hand than shoot for a maximum of four birds in the bush. However, should the Commission grant a review, Apple raises some issues (in what is called a contingent petition) that could result in HTC being found to infringe one or two more patents. The ALJ deemed those patents valid, but not infringed, and he concluded that even Apple itself doesn't practice those patented inventions, so he denied the existence of a domestic industry for them (meaning that Apple commercially exploits those patents in the U.S. market, a requirement for an ITC import ban).
HTC asks the Commission to review the ALJ's determination with respect to the two patents HTC was deemed to infringe. HTC would obviously prefer the Commission not to review the ALJ's determination with respect to the two patents HTC was not found to infringe.
HTC raises a multitude of issues that could be outcome-determinative with respect to the validity of the asserted patents, their alleged infringement, and the existence of a domestic industry. For each of the two patents, HTC would be fine if it achieves even just one of three things: have it declared invalid; have it declared not infringed; have the existence of a domestic industry denied.
Should the Commission decide to review the initial determination not only with respect to the two patents HTC was found to infringe but also with respect to one or two other patents, HTC also raises some issues concerning those in order to reduce the likelihood of the Commission taking a decision that would (with respect to those patents or even on the bottom line) be worse for HTC than the ALJ's initial determination.
The ITC staff (Office of Unfair Import Investigations, OUII) participates in many (but not all) investigations as a third party and makes non-binding recommendations to the ALJ or, at this stage, to the Commission.
The OUII supports HTC in terms of advocating a review, but the OUII's petition for review raises only a limited subset of the issues raised by HTC. The OUII wants the '263 patent (which I'll call "the API patent" hereonafter) declared not to be infringed by HTC and not to be practiced by Apple itself. The OUII also attacks the validity of the asserted claims of that patent as well as the other one HTC was found to infringe (the '647 patent, or hereonafter "data tapping patent"), but does not dispute the infringement of the data tapping patent.
On the bottom line, if the Commission adopted the OUII's proposals, HTC would also be fine since it wouldn't be found to infringe any valid patent.
The OUII also submits that "very few of these numerous issues [the ones raised by HTC's petition and Apple's contingent petition] reach the level of Commission Review". In other words, the parties raise far more issues than the OUII believes should be evaluated. HTC certainly has a much better chance of getting a Commission review of those issues that the OUII also criticizes, but as I'll explain further below, I doubt that the ALJ erred on the few items on which the OUII disagrees.
In its original petition for review, the OUII didn't raise any issues concerning the other two (non-infringed) patents. In a response to HTC's petition and Apple's contingent petition, the OUII supports the ALJ with respect to the validity and non-infringement of the other two patents.
The petitions for review were originally filed under seal. Redacted versions for the public became available on August 17 (Apple HTC) and 18 (OUII), 2011. On August 9, 2011, HTC replied to Apple's petition, Apple replied to HTC's and the OUII's petitions, and the OUII replied to Apple's and HTC's petitions. Redacted public versions of those replies became available on August 17 (HTC), 18 (OUII) and 22 (Apple).
I took my time to analyze those pleadings thoroughly and will share my views on the key issues further below. Prior to that, I'll comment on the parties' public interest statements with respect to a possible import ban.
Apple says HTC can still sell Windows Phone devices even if barred from selling Android-based products
After the ALJ recommended a "limited exclusion order" in terms of an import ban, the Commission asked the parties to answer five questions related to public-interest considerations in connection with such sanctions. The Commission's notice sums up the focus of those questions as follows:
"Comments should address whether issuance of a limited exclusion order and/or a cease and desist order in this investigation could affect the public health and welfare in the United States, competitive conditions in the United States economy, the production of like or directly competitive articles in the United States, or United States consumers."
Apple and HTC filed their responses on August 25. Apple obviously wants an import ban and says that "[t]he present investigation does not present an instance where a compelling public interest might supersede the entry of a statutory exclusion order". HTC tries to outline possible public interest considerations that might dissuade the Commission from imposing an import ban if HTC is found to infringe valid patents.
Apple says that "the infringing HTC products do not implicate any particular public health, safety, or welfare concerns". There have been a very few cases in which the ITC didn't ban the importation of infringing products because of overarching public interest considerations. Such cases related to, for example, hospital beds or atomic research. HTC says that "[h]earing impaired customers use the HTC Accused Devices to communicate by using the special features available on those devices", "health care professionals can improve their ability to remotely monitor patients using smartphones, and emergency first responders can rapidly assess and coordinate disaster action with their smartphones by using on-site video and audio. In rural areas, the HTC Accused Devices are used as an early notification system for impending natural disasters such as hurricanes and tornadoes, and disaster victims have used them to apply for disaster aid." HTC also mentions the use of its products by "public agencies" in the United States and their compliance with requirements related to "enhanced 911" location services. I don't believe that those use cases are sufficiently unique to HTC's products to represent a barrier to an exclusion order.
With respect to the general consumer interest, HTC calls its products "the most popular choice of devices running the Android operating system" (by some recent statistics Samsung's products are actually more popular), underlines its exclusive "HTC Sense" Android add-on, and notes that "non-Android devices may not be able to run applications developed for Android", mentioning that, obviously, "[Apple's] devices, which run the iOS operating system, cannot run Android applications."
Apple, however, argues that "[c]onsumers do not face any potential shortage of like or directly competitive products in the United States". Since Apple and HTC agreed at an early stage of the investigation that Apple's infringement assertions were related only to Android-based products, Apple points out that, "therefore, even HTC itself could potentially replace the volume of articles subject to a remedial order in this investigation within a commercially reasonable time" by selling more Windows-based HTC phones instead of Android-based ones.
What Apple says is factually correct. HTC does offer Windows-based phones. There's no indication of patent issues between Apple and Microsoft, and Android's IP issues, which go way beyond Apple's various lawsuits, certainly create an incentive for device makers to hedge their bets. In addition, at least one Microsoft executive reacted to Google's announcement of its proposed acquisition of Motorola Mobility with the conclusion that this transaction would make Windows Phone the only major smartphone operating system that's independent from any particular device maker. While consumer demand varies greatly between the two platforms at this stage, the availability of Windows Phone-based devices is an argument that Android isn't needed from a supply point of view.
I'm pretty sure that public interest considerations won't help HTC. It will have to defeat those patents or the infringement contentions, or perhaps it can prove that there's no domestic industry for them.
HTC's and the OUII's arguments for a review and modification of the ALJ's initial determination
It's extremely difficult to assess the merits of most of the arguments made by HTC and the OUII in their petitions for review. The ALJ's initial determination is heavily-redacted, and some important material (evidence, hearing transcripts etc.) aren't in the public record, at least not at this stage. Also, no matter what any external person believes, the six-member Commission may come to conclusions that the outside world would never anticipate. And these issues are very complex. Notwithstanding the obvious limitations of any attempt to form an opinion on this, I do want to comment on a few key aspects of those petitions for review.
Like I said further above, the issues raised by both the OUII and HTC are more likely to give rise to a review than those advocated only by HTC. So I'll focus on those.
For details on the two patents the ALJ deems HTC to infringe, may I refer you to an earlier blog post that contains the official infringement claim charts Apple presented to the ITC along with its complaint. It became one of the most-read posts on this blog.
It's possible that HTC can get part of the decision reviewed or reversed, but it will be relatively difficult for HTC to have both patents deemed invalid or not infringed. The API patent is a broader one and therefore at a significantly greater risk of invalidation than the narrower data tapping patent. In my view, the API patent is highly likely to be infringed (contrary to the OUII's view, which in my view is erroneous), and about the infringement of the data tapping patent there isn't even any serious debate (even the OUII doesn't fight the ALJ over that one).
How "realtime" does each component of a "realtime" system have to be?
For the API patent, which would have architectural implications for Android and doesn't look like it can easily be worked around without compatibility problems and other technical issues, the finding of an infringement (and also of a domestic industry in terms of being practiced by Apple) relied on a certain understanding of the term "realtime API" by the ALJ. This is how the OUII argues in its petition (HTC makes similar points, too):
Specifically, while the ID's [ID = the ALJ's initial determination] construction of the term "realtime" recognized that this term requires processing data within an upper-bounded time limit, the ID asserted that the word 'realtime' modifies the whole invention. Put another way, the ID held that the invention as a whole must act in a way that appears to the user to work in 'realtime,' but the individual components listed in the claim did not need to work in 'realtime,' i.e., process within upper-bounded time limits. [...] This is plainly wrong.
Both [the OUII] and HTC pointed out that the term 'realtime' did not appear just once in the claims or that it was merely used to describe the whole invention. Rather, the word 'realtime" is used to modify eight different terms. Thus, the claims recite, for example, 'realtime services,' 'realtime signal processing subsystem', and 'realtime application programming interface (API).' [...] However, the ID rejected any requirement that each of the claimed realtime components, such as a 'realtime API' or 'realtime signal processing subsystem,' must understand time limits such that those components could process data within an upper bounded time limit. Id. The ID argued that to require that each of these components work in realtime is 'formalistic wordplay,' and concluded that the system as a whole must transmit and process date at realtime rates."
At heart, I'm a programmer, and as such I must agree with the judge and Apple, and completely disagree with the OUII and HTC. I don't blame for HTC for trying anything to escape an import ban. But I'm very disappointed that the OUII team working on this case takes -- for whatever reason (maybe they're just too formalistic and legalistic) -- a position that independent people with a technical understanding shouldn't take.
The ALJ is right. It's "formalistic wordplay" to demand that each and every component of a realtime system must be realtime in terms of relating to operations that are executed by a scheduling system that will disconnect if time limits are exceeded.
In particular, if one defines the term "API" narrowly (meaning really just the application programming interface layer), it wouldn't make sense to use a scheduler. For almost everything that an API per se does (and I've programmed on a variety of APIs over the years and read about many more), a scheduler would actually need more processor cycles to perform its task than by simply doing its job, which is that of a messenger layer between the application and the underlying system -- in other words, the API itself is about message-passing. If operations are simple, they are by definition executed within a predictably narrow time window, and that's why a scheduler layer would be counterproductive.
The API layer in a narrow sense is not the only component for this is true. There are also other technical elements of a system that perform operations that are fast enough that they don't run counter to the idea of a realtime system. A chain is a strong as its weakest link, and the performance of a system can be dragged down by any one component in theory, though in practice there are components that won't ever do that if they're implemented the way any reasonable and competent person would implement them.
There's no reason why a realtime system shouldn't be a combination of elements that cause scheduling predictability problems (and therefore need to be monitored by a scheduler) as well as elements that can be reasonably assumed to deliver sufficient performance under all circumstances.
This includes the fact that the claimed invention presupposes an underlying operating system, which may or may not be a realtime operating system. There's nothing wrong with using operating system functions that can also be reasonably assumed to be consistent with the idea of a realtime system. If operating system functions are used even though they may cause delays beyond what's acceptable for a realtime system, then the code calling those operating systems can be put under the supervision of a scheduler.
It's not even possible to have all elements of a system on a scheduler because at least the scheduler itself would contain some program code that isn't supervised by a scheduler and could also, theoretically speaking, cause delays.
I guess the folks at the OUII never programmed the kinds of 8-bit computers with which I started. On the Commodore 64, the operating system (the whole code of which I showed and commented on in a book published back in 1987) also contained some realtime communications features. In fact, even the communication between that computer and its originallymost common type of storage media (cassette recorders, though floppy disk drives soon became more popular) had to be realtime because once those recorders started to read or write data, they moved forward at the speed of the tape and the Commodore 64 operating system had to provide data to be recorded, or process data that was read, right away. There was only a minimal tolerance due to buffering by one of the input/output chips in that machine. There was, however, no scheduler: the developers of that operating system ensured that all of those realtime functions were sufficiently fast. The code for realtime communications purposes on the Commodore 64 and similar devices even contained some "NOP" (no operation) commands that paused the CPU for a couple of cycles only to make sure that data wouldn't be sent prematurely.
A similar example of realtime computing without a scheduler layer is how programmers used to draw the screen content for early game consoles such as the Atari 2600. Drawing graphics for that system wasn't like simply setting some pixels in a bitmap, relying on the hardware to draw the screen according to the bitmap (at least the Commodore 64 and its predecessor VIC 20 were sufficiently "advanced" to do that). Instead, game developers had to write the code for their cartridges (the storage medium for that purpose) in such a way that the content of each cathode ray line (meaning the vertical unit of a TV screen) was available just in time when the hardware wanted it. Not one CPU cycle earlier, not one CPU cycle later. The programmers of those times had to calculate (manually) the exact number of cycles that the code needed to get to a certain point, and they also had to frequently execute NOP (wait) commands for timing reasons.
In other words, programmers have created truly realtime stuff without schedulers and similar techniques under immensely tougher conditions than the ones Apple's invention relates to.
In light of that, I think that ALJ Charneski and Apple's lawyers are spot-on, the OUII's position flies in the face of software development reality, and HTC will only win on this count if the Commission adopts the OUII's and HTC's fundamentally flawed proposal, which would be very disappointing because anyone who's ever done real-world, realtime programming would consider it a completely misguided decision by people who may understand the law but not technology. I believe the Commission shouldn't even agree to review this question. And should it review it, the only reasonable decision would be in Apple's favor on this one.
Prior art proposals related to the two infringed patents
For each of the two patents deemed infringed, the OUII and HTC have indeed found prior art that appears to be fairly close to the claimed inventions. Prior art doesn't have to be identical to a claimed invention: if there's only a very small difference between the prior art and the claimed invention, the patent fails the non-obviousness test or it can be considered to have been anticipated.
While I would personally welcome a very high quality standard for patents, especially for software patents, and therefore like the notion of a high non-obviousness hurdle, this ITC investigation isn't about policymaking. It's about applying the law as it stands, and Apple is a defendant in far more patent infringement cases than the instances in which it's a plaintiff, so it would be unfair to apply a higher standard to Apple's patents when Apple is the plaintiff than when others sue Apple. Even if Apple never got sued by anyone else, it would deserve the same right to enforce its patents as other right holders in the same jurisdiction. And compared to the usual legal standard, I believe the ALJ was right that the OUII and HTC failed to provide clear and convincing evidence to consider any of those patents invalid (in my view, the OUII and HTC didn't even meet the lower preponderance standard).
For the realtime API patent, the prior art that the OUII and HTC primarily claim to have identified is AT& T's VCOS system. While they claim that it was displayed in 1992, it seems they only presented descriptions of a much later version. Based on the information that I have found in the public record, it really seems that the VCOS system architecture did not provide the kind of abstraction that's really the essence of Apple's '263 patent. Apparently, the ALJ never took VCOS too seriously in terms of being potentially applicable prior art. Again, I don't know all of the pertinent detail, but my impression is that this ALJ wouldn't dismiss a prior art proposal too easily unless it was really a pretty clear case. Maybe he was so sure of his position that the OUII and HTC now believe the Commission will find the initial determination insufficiently specific in this respect. But even though I don't like this API patent at all, I'm unconvinced of the suitability of VCOS as prior art.
I wish last year's Bilski ruling by the Supreme Court had defined very clearly but also broadly the kind of subject matter that is too abstract to be patentable. In my view, the '263 patent is too abstract because it's really an architecture patent. But compared to the patents that I have seen ruled "abstract" by U.S. courts, it's far too concrete and specific.
By the way, there's a funny anecdote concerning the '263 patent and Android founder Andy Rubin that I'll tell in a subsequent -- much shorter -- blog post.
Concerning prior art for the data tapping patent, the OUII and HTC argue that a system called Perspective also provided a user interface that allowed users to perform actions on certain data, such as names. For example, one could mark up the name "Bob" and would then be able to look up Bob's address or phone number. However, the fundamental difference appears to be that the name "Bob" would then not just be a sequence of characters in a document such as an email. Instead, at the time when users of Perspective triggered an action, the name was already stored in a database record. Even though Perspective may have come with tools that enabled users to initially convert unstructured data into such structured data, I believe that's still different from Apple's invention, which identifies certain types of data, such as phone numbers, in a document such as an email and then links actions to it. Apple also argues that "the fact 'that Perspective allows you to select something based on its location' does not 'have anything to do with there being a linked action or performing a linked action.'"
Again, I don't have access to all of the information, but I would be surprised if the Commission doubted the validity of the data tapping ('647) patent. I have the impression that it's just broad enough to be deemed infringed (even by the OUII) but narrow enough not to be found invalid.
The ALJ's initial determination accuses HTC of making a "disingenuous" argument
In this final paragraph of the present post, I'd like to highlight an interesting thing that I found in the public version of ALJ's initial determination. It's about HTC's lawyers firstly declaring that a certain piece of evidence (a CD) wasn't needed only to later argue that printouts of screenshots aren't admissible as evidence because the original screenshots are on a CD previously declared unnecessary by HTC's lawyers themselves. This is how the ALJ describes the situation -- whenever he says "HTC", he means "HTC's lawyers", which I replaced accordingly in the quote below:
"[T]he record is clear that [HTC's lawyers] welcomed testimony regarding the screen shots prepared by [two expert witnesses] in lieu of admission of the disks from which they came. As [HTC's lawyers] must concede, [HTC's lawyers] did not renew its objections. In fact, [HTC's lawyers] expressly stated that [they] had no objections to the screen shots and testimony regarding them. [...] [quoting HTC's lawyers] "And we have no objection to the screen shots..." [...] In contrast to [their] post-hearing brief, [HTC's lawyers] represented that [they] did not think the underlying CD from which the screen shots came would be useful to the [ALJ]. [...] It is disingenuous for [HTC's lawyers] to argue that the CD is unnecessary and should not be admitted because the screen shots have been admitted, but then move to strike testimony concerning the screen shots because the CD was not admitted".
Defendants try all sorts of things to fend off a patent infringement suit. However, the above story shows that HTC's lawyers went far beyond what reasonable litigants do and used tactics that are very, very questionable and look desperate to say the least.
The ALJ also disagreed with Apple's lawyers on some of their claims. In those contexts, the ALJ says that their arguments were "unavailing", "unpersuasive", or "erroneous" at worst. But only HTC's lawyers are criticized for disingenuousness. They own a patent on that one now.
This may have been the last stage in the process at which the ITC provided us (the general public) with so much detail on where things stand. The process will now be somewhat opaque in the coming months, but I'll do my best to keep you informed.
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+.
Share with other professionals via LinkedIn:
