Showing posts with label SQLite. Show all posts
Showing posts with label SQLite. Show all posts

Wednesday, January 16, 2013

German Nokia cases against HTC and ViewSonic over messaging patent will go to joint trial in May

Lately I've been reporting a lot on Nokia's patent assertions, and unless there are some more license deals, there will be numerous hearings, trials and (increasingly) rulings in and by German court in the weeks and months ahead. RIM has settled and accepted to pay royalties to Nokia, but for the time being HTC and ViewSonic are still defending themselves vigorously (as RIM was until it gave in).

Some of the pending cases are of relevance not only to HTC and ViewSonic but to the entire Android ecosystem. Google only appears to intervene when its closed-source mandatory components of licensed Android distributions, such as the Google Play store app or the Google Talk client app, are at issue, but not when closed-source components of Android that all OEMs use (even if some of those may theoretically be modified) are being accused of infringement. Yes, the bottom line is that Google is, in the litigation context and generally, far more committed to the closed-source parts of Android than to its open-source code -- and above all, Google is interested in its revenue-generating online services, of course.

At a court hearing today in Munich relating to EP0982959 on a "mobile telephone user interface for short messages", Google was notably absent, but HTC asked the court to hold a joint trial over Nokia's assertions of a text message user interface patent (basically the patent covers the concept of pre-sorting text messages, also known as SMS, by a given contact or group) against HTC and ViewSonic because this is an Android patent issue. In the ViewSonic case, a first hearing (the second one in Munich is a trial and followed by a decision) was already held in late November. HTC's first hearing took place today. Service of Nokia's complaint to HTC's headquarters in Taiwan took longer than to US-based ViewSonic. But the court already said at the time of the ViewSonic hearing that it intended to schedule the second hearings (i.e., trials) for the same day: May 29, 2013.

The court's original plan was to hold the ViewSonic trial at 11:15 AM and the HTC trial at 2 PM (both on May 29), but HTC's lead counsel in this action, Dr. Martin Chakraborty of Hogan Lovells, said that there are no technical differences between the cases concerning the infringement analysis since "this is about Android" and suggested a joint trial to avoid duplicative discussion. Nokia agreed, and the court gladly adopted the proposal (German courts don't manage cases through imposed consolidation the way their U.S. counterparts do). But if it's about Android, as everyone in the courtroom agreed today, then Google has just as much of a reason to intervene as it has in certain other cases, such as the ITC investigation of Nokia's complaint against HTC (in which Google even wanted to be named as a co-defendant but was allowed to participate only as an intervenor).

The issue of Google's involvement in Android patent infringement actions is also going to be front and center at a March 7 Munich trial over the alleged infringement of a Microsoft patent by Google Maps.

As for the substantive part of the discussion today, it appears to me that Nokia's lead counsel in the two lawsuits over this patent, Klaus Haft of Reimann Osterrieth Koehler Haft, is gradually inching closer to a favorable decision. The court still expressed skepticism based on the infringement contentions provided in and along with the original complaint against HTC (which was also the case at the ViewSonic hearing), but Nokia has not yet had the opportunity to reply to HTC and ViewSonic's answers to the complaint. Mr. Haft assured the court that Nokia would provide infringement contentions of greater specificity. Apparently, the complaint was largely based on screenshots that show the functionality provided to end users, but the patent-in-suit is not necessarily infringed by a user interface that sorts text messages by conversation: under the court's interpretation of the patent, an incoming message must be stored in a conversation-specific folder.

HTC and ViewSonic stress functional differences between the concept of a folder in a file system's directory structure and a database (Android uses SQLite for this purpose), but Nokia argues that the very same technical functions needed to store a file in a directory on a storage medium are also performed by a database. Obviously, an SQL database can do much more than that, but under patent law, the presence of additional functionality is not sufficient to avoid an infringement finding. At the ViewSonic hearing in November, Nokia presented this logic for the first time.

It would be a gross exaggeration to say that Nokia is now on the winning track, especially since Judge Andreas Mueller ("Müller" in German) generally appears to be very difficult to persuade of infringement contentions (other plaintiffs also struggled in his court), but today I got the impression that Nokia's functional infringement contentions have more than enough traction that the May 29 Nokia v. HTC and ViewSonic joint trial is going to be a very interesting fight. A lot will depend on the infringement arguments Nokia is going to file in the meantime. The court would like to see information on Android's inner workings, and the related source code is available, so Nokia, with its vast experience in patent litigation, should be able to substantiate its assertions in detail.

To the extent that Android's SQLite text message database uses an index column for the thread ID, meaning that it actually keeps a list of all database records belonging to a given conversation, I think there's no functional difference whatsoever (except for irrelevant additional functionalities) between a directory in a file system and a grouping of database records by means of an index column. In that case I don't think HTC and ViewSonic can argue that they sort the records only at display time as if they performed a full table scan (opening and evaluating every single database record) on demand. An index table is, for the purposes of this patent, the same as the directory information on a storage information. Both contain pointers to records/files and represent a grouping, and both are updated immediately if the composition of the grouping changes. Some of you may know about my past involvement with a database company (MySQL), so it won't surprise you that I'm particularly interested in the technical issues presented by HTC and ViewSonic's shared non-infringement argument.

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:


Monday, April 12, 2010

The patents used by IBM against Hercules are a threat to several major FOSS projects

As I reported last week, IBM sent a list of 173 patents (67 of them applications) to the founder of the Hercules open source project.

Meanwhile I have taken a closer look at some of the patents. The patents IBM uses against Hercules are also a potential threat to other key FOSS projects. Based on a first analysis, those include (but are not limited to) OpenBSD, Xen, VirtualBox, Red Hat Enterprise Virtualization, MySQL, PostgreSQL, SQLite and Kaffe.

I will list below the relevant patent numbers and explain why I believe they could be used against certain projects. Considering that IBM has already used them in a threat letter to TurboHercules, those patents must be considered particularly dangerous. I just explained why IBM's attack on Hercules is an attack on interoperability and FOSS innovation in general. The fact that the patents in action here are also a threat to other key FOSS projects underscores the need to act.

At the end of this post, I am asking the FOSS community to contribute to this important analysis in various ways. I will then check on the material I receive and post the relevant contributions to this blog.

Note that the analysis below doesn't talk about actual or even likely infringement. It talks about potential issues. A wording like "patent A could read on program B" means that given what program B does, further analysis is required whether patent A covers a method used by program B. Even if that were to be the case, it's still possible that patent A could then be invalidated based on prior art.

Here's my initial analysis:

US Patent No. 5,953,520
(#65 on list IBM sent to TurboHercules)

This patent applies to any emulator that emulates a computer with virtual memory. This includes virtualization software, such as Xen, VirtualBox or Red Hat Enterprise Virtualization, as well as emulators and simulators.

US Patent No. 6,009,261
(#63 on list IBM sent to TurboHercules)

This patent reads on many emulators including virtualization software, such as Xen, VirtualBox or Red Hat Enterprise Virtualization. It teaches a method of reflecting the specifications of a guest instruction into the semantic routine of host instructions which emulate that guest instruction. That method is used by many emulators.

US Patent No. 6,654,812
(#46 on list IBM sent to TurboHercules)

This teaches a method for transferring network messages between partitions without going onto the network. This method or a very similar one is most likely used in virtualization systems, such as Xen, VirtualBox or Red Hat Enterprise Virtualization.

US Patent No. 5,875,336
(#70 on list IBM sent to TurboHercules)

This patent teaches a method for translating Java Bytecode. This could apply to Java Virtual Machines such as Kaffe.

US Patent No. 6,748,460
(#42 on list IBM sent to TurboHercules)

This patent describes a method that could be used in a virtualization system (such as Xen, VirtualBox or Red Hat Enterprise Virtualization) to present interrupts to a VM.

US Patent No. 6,615,373
(#47 on list IBM sent to TurboHercules)

This patent describes a method for resolving potential deadlocks. The resolution of deadlocks is key to the functioning of multi-threaded database servers. This could read on MySQL, PostgreSQL and SQLite in addition to any other database management system (still checking into object-oriented and other "NoSQL" databases). It is also possible but less likely that it could read on distributed caching software such as OSCache or JBoss Cache, which cache Java objects on servers. It is more likely that these use broadcast invalidates but needs checking.

US Patent No. 6,209,106
(#60 on list IBM sent to TurboHercules)

This patent describes a method for setting clocks on a variety of different Virtual Machines using offsets. This would be an obvious solution to the problem in a VM system such as Xen, VirtualBox or Red Hat Enterprise Virtualization.

US Patent No. 7,127,599
(#28 on list IBM sent to TurboHercules)

I'm still struggling to read the claims in this one. However, it could apply to managing I/O subsystems in a Virtual Machine system, such as Xen, VirtualBox or Red Hat Enterprise Virtualization.

US Patents No. 6,332,171 / 6,339,802 / 6,345,329
(#58, #56 and #55 on list IBM sent to TurboHercules)

These patents describe a method of using queues to handle data going to and from an I/O device. The use of queues is common in operating systems such as GNU/Linux and openBSD as well as in virtualization systems such as Xen, VirtualBox or Red Hat Enterprise Virtualization.

US Patent No. 6,971,002
(#34 on list IBM sent to TurboHercules)

This patent describes a method for booting a partition of a computer system without restarting the system. It would likely apply to Xen and VirtualBox to the same extent it would apply to Hercules.


CALL TO RESEARCH

This initial analysis requires further scrutiny and exploration. I therefore call on everyone in the FOSS community with an interest in this matter to help expand this.

Like I said further above, I will publish the input (to the extent it is relevant) on this blog. I will do so anonymously to protect all sources. I don't want anyone to have to fear that their project could make itself unpopular with IBM for contributing to this effort here. (If anyone wants to be credited for a contribution, you are free to blog about it yourself.)

The key areas of research that would help me are the following:
  • further detail related to the initial concerns identified above, leading to more specific explanations and possibly claim charts

  • any examples where additional ones of the patents IBM listed (the letter containing the list is available as a PDF file and in multiple PNG files) might read on FOSS projects

  • any examples of other IBM patents beyond the 173 asserted against Hercules potentially reading on FOSS projects

Please use the contact form to send your input.

Based on more analysis of all of this, we may then consider what kind of commitments we ask IBM to make. It's always been clear to me that IBM's pledge of 500 patents was a drop in the ocean. I criticized it on the day of the announcement. Later that year (2005), I wrote this Slashdot op-ed on the issue.

IBM has 50,000 patents or so, and gets 4,500 new ones every year.

As Richard Stallman puts it, if you have 100,000 mines in a park and you take out 1,000, the park is still not safe to walk.

It was a PR stunt by IBM and they weren't sincere about really reducing in any meaningful way the threat their patents represent to FOSS. Now that IBM has actually started to use patents against FOSS, it's key to understand the danger so it can be dealt with appropriately. For everyone developing or using FOSS, not just Hercules.