OB10 patent on ESB middleware and VANs pattern?

OB10 has received a patent on an "Communication routing apparatus" by the European Patent Office (EPO). The original application was filed on December 3rd 2001 and the European patent was granted on October 29th 2008. There is however a 9 months period where a "Notice of opposition" can be sent to EPO (i.e. by the end of July 2009).

An attempt to patent an old pattern known from middleware products and VANs
The patent describes a middleware product (e.g. an ESB) where the ESB acts as an intermediary messaging hub between many IT-systems. It basically describes protocol conversion and content conversion between 1) senders 2) the hub and 3) receivers.

[Note on June 5th 2009: This is my interpretation of the patent and I have tried to describe the patent with a more familiar terminology. I have however been corrected today by a patent attorney. The characteristics of the patent are that static and dynamic data is added to the input protocol and the input content (see added text below in italic). But really - there is nothing to it - and in my mind this does not change anything. This was apparently added to the European patent because the first description was found to be known by EPO. So please be aware that there is a difference in the text between the US patent and the European patent! You should go to the source for an authoritative description.]

1. Data can be received by a hub from different IT-systems (senders) on many different transport protocols. (The patent describes an external system producing an electronic invoice as an example of it's use). A new input transport protocol only needs to be added once. Several input systems can use the same transport protocol but could also use different protocols. [Added June 5th 2009: Dynamic data is added to the input signal. In other words the hub creates a new envelope for the data with "transaction code, a transaction id and the mapping definition used". Nothing new here - you need an envelope so you need to do that!]


2. Data is then converted to an intermediate form (by the hub). It is described how the original invoice in one format is transformed to a neutral invoice format by the middleware product. This could for instance be the upcoming Cross Industry Invoice from UN/CEFACT or Universal Business Language from OASIS. [Added June 5th 2009: Static data is added to the data. E.g. name and address of the source of the invoice. Again it is quite common to unfold information from a key. If an input invoice only has a supplier identifier then you should insert the name and the address of the source.]


3. The next step is that the data is converted from the neutral format to the desired format of the receiver. (e.g. this could be a conversion from the Cross Industry Invoice to the SAP idoc format).


4. Finally the data is sent to the receiver on a transport protocol supported by the receiver. New transport protocols only needs to be implemented once in the system.

I my view this is standard functionality in many middleware products and most ESB's. I also believe that the described pattern of transformations of protocols and content describes exactly what Value Added Network Operators has been making a business on for the last 20+ years. The "VA" (Value Added) in the VAN acronym - is to do transformations on protocols and contents like it is described in the patent.

One of the inventors is also advisor to an EC expert group on e-invoicing
One of the inventors of the patent, Stefan Foryszewski, is also advisor to the European Commission's Expert Group on Electronic Invoicing. The group was formed in November 2007 with the task to establish a European Electronic Invoicing Framework by 2009. The purpose of the expert group is defined here:

"By Decision 2007/717/EC, the Commission has set up an Expert Group on electronic invoicing (e-Invoicing). The tasks of this Group will be to identify the business requirements, to allocate responsibilities for the execution of specific work and to propose the necessary steps for the creation of the European e-Invoicing Framework. This framework is to establish a common conceptual structure to support the provision of e-Invoicing services in an open and interoperable manner across Europe." Source: Original call for applications

"The (purpose of the) European e-Invoicing Framework is to establish a common conceptual structure, including business requirements and standard(s), and propose solutions supporting the provision of e-Invoicing services in an open and interoperable manner across Europe." Source: Mid-Term Report of the European Commission Expert Group on e-Invoicing

The original call does not require the applicant to sign a "patent non-assert agreement" nor does it require the applicant to inform about patent rights that might be covered by the work. This should perhaps be the case with future expert groups?

I asked Stefan Foryszewski the following questions in an email on May 25th 2009 but have (so far) not received any answer:

"Dear Stefan Foryszewski,

I write to you in my role as Technical Director in the PEPPOL project. I have some questions regarding the OB10 Patent on a "Communication routing apparatus" submitted by yourself and some colleagues (http://bit.ly/Kh95m). There is only a few weeks to make objections to the patent and I want to make sure that I understand the implications that the patent has on the Framework for Interoperability and existing Value Added Network operators and other service providers.

Can you please explain how an FFI compliant instance (e.g. PEPPOL) would be (or would not be) affected by the patent? Such a framework would have a standardized format for e-Invoices (e.g. CEN/ISSS BII in UNCEFACT CII syntax or OASIS UBL syntax) and transformations between this format and other invoice formats would be the norm for most service providers. The same would be the case for the transport standards. Is this not exactly what you are describing in your patent? How do you intend to enforce your patent? Are you just protecting a pattern that can be used freely by anyone?

My personal opinion is that the patent is describing an already established pattern for exchanging and transforming e-Invoices. (Event at the time of filing in 2001).

Best regards
Mikkel Hippe Brun"

Possible threat to global e-invoicing

Electronic invoices are specifically mentioned in the patent, but other types of business documents are also covered. I am neither a developer of middleware products nor a Value Added Network operator / Service Provider. I am however the technical director of the PEPPOL project (Pan European Public Procurement Online) which is an ambitious European e-procurement infrastructure. I do not see the patent as a direct threat to the PEPPOL infrastructure. But it is (in my mind) a direct threat to the service providers connecting to the infrastructure and the middleware products used to making it possible.

It all depends on whether service providers and suppliers of middleware products will oppose the patent and whether OB10 will seek licenses for the use of its patent.

I urge suppliers of Middleware products and service providers to send an opposition to the patent. This could hit you hard! I have been told that an opposition has to be made for each individual country covered by the patent, so it is not a trivial task lying in front of us. [Added June 8th 2009 - I have made a new blogpost where I am collecting evidence that could be used for an opposition.]

Appeal to OB10
So my appeal to OB10 is to quickly come up with a "patent non-assert statement". There is a saying that if you are not part of the solution then you are part of the problem. Private companies and government institutions will have to spend lots of time and money to oppose your patent. It does not bring us anywhere and it confirms the impression that more government regulation is needed. You are putting yourself in a delicate position and you are not helping the industry. Save us that burden NOW! Participate in the expert group and let us change the landscape of global electronic invoicing. There are 25 million SME's in Europe that will be participating in electronic business processes within the next 10 years. Let us help each other to get them "connected". There is so much money to be saved and and also a lot of money to be made. Let us not delay this for one second.

Links:

Patent: "Communication routing apparatus" on European Patent Office homepage

Latest version of amended US patent as of March 17th 2009

Direct link to PDF of patent on "Communication routing apparatus" where information about the 9 months "opposition period" can be seen at the bottom. For some reason it is just the first page you get in the PDF.
Full text of European patent

Patent: "Communication routing apparatus" on Google Patent Search homepage. Observe: US patent text - not European.

European Patent Office (EPO)

EPO Notice of opposition