All posts tagged ‘patents’

File Under: Web Standards

Is Apple Using Patents to Hurt Open Standards?

Opera developer Haavard Moen has accused Apple of repeatedly using patents to undermine the development of web standards and block their finalization.

World Wide Web Consortium (W3C), the industry group that governs and oversees the development of web standards, requires that every specification it approves be implementable on a royalty-free basis, barring extraordinary circumstances that justify an exception to this rule. The specifications can contain patented technology, as long as royalty-free patent licenses are available.

Members of W3C—a group that includes representatives from Apple, Microsoft, Google, Mozilla, and Opera—are required to disclose any patents that they hold that are relevant to each specification. Depending on how far the specification is through the standardization process, they have between 60 and 150 days to make this disclosure.

If royalty-free licensing is available, the specification can proceed as normal. Participation in the development of a particular specification obliges W3C members to offer royalty-free licensing for technology used in that specification. Nonparticipants can also voluntarily offer a royalty free license, but they are not obliged to.

If, however, there is no commitment to offer royalty-free licensing for the patents in question, a Patent Advisory Group (PAG) is formed. The PAG will then assess whether the patent is truly applicable to the specification, and if so, how best to address the issue. The PAG might then seek prior art to invalidate the patent, or it might recommend that the specification be modified, to work around the patent. It might even advise abandonment of the specification. Only in exceptional circumstances will it decide that the specification should stand, in spite of the lack of royalty freedom.

Without an appropriate patent grant, browser vendors—whether open source or proprietary—cannot implement the specification without opening themselves up to a lawsuit. Such specifications would be, at best, an extremely risky proposition for anyone seeking to develop a browser, and none of the major browser vendors would even consider implementing a specification with known unlicensed patents.

Haavard identifies three separate occasions, twice in 2009, and again in 2011, where Apple has disclosed patents and not offered royalty-free licensing. In the first 2009 patent claim, Apple said that it had a patent covering W3C’s “widget” specification. A PAG was formed, and determined that Apple’s patent was not relevant. In the second 2009 claim, Apple claimed to have two patents covering W3C’s widget security specification. A PAG was again formed. It decided that one patent was not relevant, and the other didn’t apply. With both 2009 claims, Apple waited until the last minute to disclose its patents.

Touch Events

This time, Cupertino is claiming to have three patents, and an application for a fourth, that cover some of W3C’s touch event specification. This time the disclosure was made with about a month left to go. Again, the lack of royalty-free licensing means that a PAG is likely to be formed.

This in turn will delay the development of the specification and cost W3C members further time and money. The PAG process is not quick; the widget security PAG did not deliver its verdict until October of this year.

Haavard’s conclusion is that there is a pattern of behavior here; that Apple is trying to disrupt the standards process with its patent claims. He references the touch specification in particular—this is plainly an area where Apple has lots of expertise and interest in the technology, but the company opted out of working on the specification. If Apple had worked on the specification, it would have had to disclose sooner and offer licensing, and Haavard believes that avoiding this commitment is why Apple refused to work on the specification.

Apple’s is acting within its rights. W3C obliges members to disclose patent claims, and Apple is duly disclosing them. However, it’s easy to be sympathetic to Haavard’s argument. The two prior PAGs that resulted from Apple’s refusal to offer royalty-free patent licenses delayed and inconvenienced W3C, but ultimately on both occasions the groups decided that Apple’s patent claims were irrelevant. If Apple was hoping to keep some technology to itself, it did not succeed.

Moreover, W3C doesn’t require patent-holders to give up their competitive advantage. It’s acceptable to W3C for the royalty-free patent licenses to only cover implementations of the W3C specifications; if Apple wants to permit the royalty-free use of its touch patents in HTML5 browsers, but nowhere else, this would be an option. Such terms would allow browsers to implement the standard but still keep the technology off-limits to, for example, Android. But Apple did not offer such terms before, and so it seems unlikely that it will offer such terms this time.

Further, the only likely result of this is that Apple’s patents simply get worked around. W3C’s aversion to royalties means that it’s unlikely that it would accept any non-free license (should Apple even offer one), and the importance of touch input to phones and tablets means that W3C is unlikely to abandon the specification altogether. There’s no win possible for Apple—just wasted time and money for those seeking to make the web a more effective, more open platform.

Indeed, the result might even constitute a loss for Apple; the prior art that PAGs can uncover could jeopardize the patents themselves. The PAG subjects the patents to a certain amount of scrutiny—scrutiny that could be avoided through provision of a suitable license.

Apple has thus far not responded to our request for comment.

Apple’s work on WebKit and with W3C has undoubtedly helped the web community. But actions such as this show the company’s approach to standards and intellectual property is, at best, inconsistent, and and worst downright unhelpful: if open standards and Apple’s IP interests conflict, it’s the IP interests that win out. This may be good for Apple, but it’s bad for the open web.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

File Under: HTML5, Multimedia

Royalty Deadline for H.264 Extended, But It’s Still Bad for the Web

As if the web’s video codec issues weren’t complex enough, the group that controls the licensing and royalties for the H.264 video codec has announced that H.264 will remain royalty-free until the end of 2016.

One the surface it sounds like a good thing — at least until 2016, you’re free to post H.264 videos on your web site without paying royalties to MPEG-LA, the controlling body. But after 2016, MPEG-LA could charge you whatever it wants — even an Austin Powers-style one million dollars per second of video.

MPEG-LA’s latest move seems ripped straight from a crack dealer’s marketing guide — “Here kid, the first hit’s free.” Then, once the web is even more heavily invested in H.264 than it is now, MPEG-LA can set its royalty fees at whatever rate it wants, sit back and reap the profits.

This news comes at a time when the web is in a heated debate over how to best display videos in the browser. The vast majority of content providers rely on Flash (which can decode H.264) to show videos. The certainty of Flash’s longevity on the web was thrown into question by the recent arrival of the iPad, which, like the iPhone, iPod Touch and other mobile devices, doesn’t support the Flash Player software. Some sites are experimenting with using HTML5 to display videos in either H.264 or Ogg Theora file formats. But different browser makers have chosen to support different file formats because of the licensing complexities — Mozilla, Apple, Opera and Google are all picking different sides.

It’s important to understand that the royalty fees being deferred by MPEG LA are in addition to the licensing fees the group already has in place (at over US$50,000 per year). Proponents of H.264, along with many unaware users, often argue that the licensing fees are irrelevant because web users like you and I remain unaffected by them.

But that doesn’t mean that the licensing fees won’t affect the web. Sure, the fees are no big deal for Apple, YouTube and other established players, but what if you want to build a web video encoding service to compete with YouTube and Vimeo? Well, if you want to serve your video to iPhone/iPod Touch/iPad users you’re going to need to come with $50,000+ in licensing fees.

Even without the royalty fees arriving in 2016, the licensing costs alone put start ups at a disadvantage, meaning that an H.264-encumbered web might well miss out on the next big leap in web video sharing.

Then there’s the decoding side of the equation.

At least part of the reason Mozilla and Opera refuse to support H.264 is the licensing fee necessary for software that decodes H.264. While both companies can likely afford it, smaller players can’t. For example, if you want to distribute your own version of Firefox, or simply create something totally new — some next-generation web browser or add-on based on Mozilla code — again, get ready to pony up the licensing fees if you plan to support H.264.

Even using Flash to decode H.264 doesn’t protect you from the licensing fees. As the Adobe H.264 page notes: “commercial use of the Flash Player to decode H.264 video may require a separate license.”

We’re not saying there’s anything wrong with H.264 or MPEG-LA’s desire to make money off it, but let’s not delude ourselves — H.264 isn’t a viable solution for the web’s open video woes.

See Also: