Saturday, June 06, 2009

"Notice of opposition" against OB10's Communication routing apparatus patent

I feel very stongly about the patent OB10 has received on an "Communication routing apparatus". See my previous post on the subject. To me it is like if somone reinvented the weel and then claimed to be the original inventor eventhough everyone else is driving around in cars.

I will keep updating this post with references to examples of common practice and publications dated before the orginal filing of the patent. If you would like to add something to my list please contact me or make a comment.

Protocol conversion has been common practice for 20+ years
We have had Value Added Networks in Denmark for more than 20 years. I have colleagues who have worked there and I know what they did for a living. They were not just network operators - they were value added network operators (VAN). The value add was to connect any customer via any protocol to other customers via any other protocol. (This is the protocol part of the OB10 patent.) They connected businesses and the public sector in b2b, b2g and g2g scenarios. Since way back his was everyday business for several companies providing services to the health sector the automotive industry and in eprocurement. This has been so common that no-one could imagine that someone would take out a patent on this practice.

Expired US Patent 5,708,828 from January 13th 1998 by Coleman [added June 12th 2009]
Coleman got another amazing patent very similar to the OB10 patent. Fortunately this patent has expired due to "NonPayment of Maintenance Fees". The title of the patent is "System for converting data from input data environment using first format to output data environment using second format by executing the associations between their fields". The existance of this patent was used as one of the reasons to reject several claims in the US version of the OB10 patent on October 30th 2008. The exmainer quoted the following lines from Coleman:

"the present invention comprises an improved system and method for converting data between different formats or types. The present invention converts data to a pre-defined generic data object or generic data type and then converts data from this generic type to the new format. This simplifies the conversion process."

The examiner also compared the two illustrations of the patents (see below) and stated that

"Figure 2B clearly discloses applicant's invention as shown below. One can easily see the similarities by the comparison of Figure 1 of the instant invention."

So the Coleman patent has clearly shown the USPTO and the EPO that the generic protocol and content transformation was prior art.

UN/EDIFACT [added June 6th 2009]
Well EDIFACT has been around for several years. Here you can find definitions of EDIFACT messages from 2000. These messages format were used (and are used) by different industries to exchange business business documents in a standardized format. The VAN operator would then as a value added service offer to do content conversions from and to various customer formats. To do such conversions would most often be the rule rather than the exception. There were many advantages to this approach for the customer: 1) Version changes in the standardized format would be dealt with by the VAN, 2) The company could out source the conversion and configuration. 3) The company would not have to deal with supporting many different protocols and content formats for all their business partners.

Commerce One and xCBL [added June 6th 2009]
Commerce One was a very successfull company doing business in the area that is described by the patent prior to 2000. Look here at an announcement from December 17 1999, where Commerce One announces an updated version of the XML-based de-facto e-invoicing standard - xCBL. It was made available at a number of repositories - one of them being operated and owned by Microsoft. was the home of a number of XML Schemas for different purposes and BizTalk was a middleware product that could do (gues what) protocol conversion and content conversion. The same was the case for the Commerce One products I believe. The characteristics of the OB10 patent are that static and dynamic data is added to the input protocol and the input content. But there is nothing novel to that. It is part of what you would have to do for this setup (see illustration) to work.

The illustration above was found on the Internet Archive Wayback Machine from May 2000.

The method of cross-translation with OmniMark [added June 8th 2009]
OmniMark from Stilo is a pearl-like language used to do content transformations. I has around since the late eighties and was in the beginning used by CD-ROM developers, technical documentation experts and CD-ROM publishers [Source: Omnimark at Work: Getting Started, Architag Press, 1997]. OmniMark supports (and supported) a content transformation model called cross-translation, which is a combination of an up-tranlation and a down-translation. The idea of a cross-translation is that you can set up a number of up-translations from various formats to a standardized format (could be SGML or XML). The tool makes it relatively easy to do such transformations from unstructured or structured data because you are guided by the DTD or the XML-Schema. The second part of the cross-translation is to do a down-translation to one or more output formats. To add static data to this process is a no-brainer (this is specific to the European patent). See also the Guide to OmniMark 5.0 from 2000

OmniMark also had the capability to send and receive data on different transport protocols. What protocols that were available in 2000 could be further. Anyway - the book about OmniMark programming cited above clearly shows that the described method of content conversions were common knowledge as early as 1997, and thus does not deserve to be part of a patent in 2000. I am furthermore confident that service providers / value added network providers used OmniMark in 2000 to support thier business.

The TradeCard Solution described publicly in October 2000 [added June 10th 2009]
TradeCard provides hosted technology, online services connecting buyers, suppliers and their service providers. In October 2000 TradeCard published a Technical Overview of their platform. Here are som quotes from the Technical Overview:

XML provides the TradeCard system with a mechanism for translating and integrating business data from disparate systems. Thus, TradeCard can ensure the free exchange of business documents, regardless of format or application.
Translation Services
All business documents are stored as XML within the TradeCard system. The TradeCard Messaging Infrastructure makes it possible to have multiple data formats within a single business transaction. For example, a seller may upload an invoice from an automated supply chain system directly into the TradeCard system. Then the buyer may view the invoice in HTML via a web browser. A freight forwarder may send the advance shipping notice in EDI format. All of these document types are stored internally in the TradeCard system as XML. Yet externally, the customers of TradeCard are not required to have XML compliant interfaces on their systems.
Message Broker
The web browser is only one of many methods that can be utilized to access the TradeCard system. All non-browser access to TradeCard is achieved by messaging. Messages are delivered in a variety of mediums and formats including SMTP, FTP, EDI, and custom formats. The TradeCard Messaging Infrastructure converts the messages to TradeCard XML formats. Message queuing services are provided by IBM MQSeries.

The Technical Overview clearly shows that the "invention" that was claimed by OB10 had indeed already been implemented and described by TradeCard and others in the industry. The European patent contains added characteristics describing how static and dynamic data is added to the input protocol and the input content (also mentioned earlier). These characteristics are not described in the TradeCard Technical Overview, but there is no invention in adding static and dynamic data. You cannot do protocol conversions without adding dynamic data and unfolding keys to static data (e.g. an address) is trivial and is also an implicit and trivial feature of middleware poducts like the IBM MQSeries used in the TradeCard solution.

EDIFACT on Wikipedia
Internet Archive Wayback Machine
Omnimark at Work: Getting Started, Architag Press, 1997
TradeCard Technical Overview


Blogger Test said...

It's unbelievable that a Patent Office today is still collecting these materials describing how the wheel can be reinvented. Hopefully there is still market around for eBusiness as the B2B software is not perfect yet and it is still costly. So the first question that comes to me is why the submitter of this patent is not dedicating his efforts into the development before asserting he's providing such an innovation. Patents are mainly driven by money, that's the answer. I really hope this patent will be pending for ever... or better will expire.

Anonymous said...

TradeCard ( has been in production with a global internet based e-invoicing platform since 1999. 2008 platform volumes were about $8 billion USD across 40+ countries in 2008 with 4000 trading partners in the TradeCard network.

The diagram in your blog is an exact match of the messaging architecture we designed in 1999 and it is the same that is currently in use.

The meta-data used by TradeCard is our own XML based schema with around 40 trade documents defined (PO, CI, ASN, etc...)

The communications protocol (AS2, SFTP, etc...) and format (ANSI, EDIFACT, UBL, etc...) can be different for all trading partners even within the context of a single transaction.

Reading through the claims of both patents looks like the inventors must have never heard of TradeCard.

More details:

BTW, the US application is substantively changed (claims dropped and amended) from the version linked to in your blog entry. (I have asked our consel if we can distribute the version he got this morning from the US patent office for us).

Nestor Zwyhun
TradeCard Inc.

Mikkel Hippe Brun said...

There are some really interesting and insightful contributions to this discussion on the UBL-DEV list. See notes from Fulton Wilcox, Nestor Zwyhun and Danny Gaethofs. See

Rob Eamon said...

Many vendors come to mind as providing this sort of capability. Some are still around, others have disappeared or were acquired. Many entries are for companies with products in the 90s.

IBM MQ Series (Broker and other tools); DataPower appliance

ActiveWorks from Active Software - acquired by webMethods which was acquired by Software AG. Still sold today as webMethods Broker. SAG also has Integration Server/Trading Networks as part of the solution. These have been around a while as well.

TIBCO Rendezvous, et al.


SAGAVista from SAGA

SeeBeyond, acquired by Sun, acquired by Oracle.

Sonic from Progress Software.

I'm sure others have additional examples.

EDIMapper said...

An additional comment regarding this patent. The synopsis I have read implies that the "system" requires no additional programming no matter what the format of the data presented. This is not the case. We have represented a customer that was forced to connect to this exchange to send invoices to one of it's customers and we were told that the raw format proposed could not be used without some "mapping" effort at the exchange. So we converted the data on behalf of the client to a format that the exchange in question could handle without modification.

Anonymous said...

It is certainly interesting for me to read this post. Thanx for it. I like such themes and anything connected to them. I definitely want to read a bit more soon.

Anonymous said...

Well I acquiesce in but I dream the post should acquire more info then it has.