RE: [ubl-dev] OB10 patent on common e-invoicing pattern?

Mikkel

One of the dimensions of the late 1990's internet-centric eBusiness "bubble" was that those involved genuinely thought that they invented fundamentally new "business methods" even though what they (we) were doing was nothing more than porting them. Indeed, the existence of the Rossetta Stone is a reminder that ancient people had pretty sophisticated "methods" even if the technology instantiating them was primitive.

I am not a patent lawyer, but an analyst with experience in the eBusiness field, so I look at patent applications and issued patents as specs and compare them to what I am aware of that went before or that "invent" methods that, in this case, would be obvious (or even unavoidable) to someone approaching the problem of "electronic document exchange" (EDI).

Below is a link to a white paper that incorporates brief references to the historic evolution of EDI and eBusiness standards, starting with the TDCC (Transportation Data Coordinating Committee) in the 1970's along with various industrial groups – e.g., in the automobile industry. The white paper's description of what problems were being addressed in the 1970's and how to solve them parallel the language in the Patent Application. A number of these organizations still exist and can provide more detail as to their offerings in the 1970s and 1980s. . www.sagepss.com/SolutionFile.ashx?id=3956

Sage Partner's brief description makes it clear that most of the "business process" needs required to exchange business documents such as orders and invoices between trading partners were anticipated by these standards groups and instantiated by some of the early technology players such as IBM and General Electric (of the U.S.) and, not named, but indeed then an early player, AT&T, along with a host of EDI startups. I was part of AT&T's early eBusiness initiative in the early to mid 1980's, but once AT&T figured out that, because of very slow adoption and low customer willingness to pay in-network EDI translation, was destined to be a niche business, AT&T in about 1985 handed over its customer portfolio to GE and exited the business (later to re-enter it and learn once again that the adoption curve and customer willingness to pay were both low). Note that at the conceptual "process" level there is zero distinction between, say, "classic" EDI and for example UBL.

With respect to your chart in the blog:

The network layer "business process" that defines a "VAN" as opposed to a plain old network was "invented" by the U.S. FCC (Federal Communications Commission) in the 1970's under "Computer Inquiry 2", essentially to define the boundary between regulated and non-regulated services. As the FCC and various other regulators around the world concluded, AT&T and other regulated service providers could provide private line and dial service under regulated tariffs, but could not offer services such as X.25 packet switching and, especially, the speed and protocol conversion involved in marrying x.25 backbone packet service with regulated private line, ISDN and dialup services. Such end-to-end services were reserved for non-regulated VANs. On June 1, 1982, under CI 2 rules, AT&T formed a non-regulated subsidiary to offer VAN services (and I was a charter member of that AT&T entity). Under the brand name "Net 1000" AT&T in effect implemented everything on your chart having to do with network service and communications interoperability along with node-level service functionality (e.g., in-network programmability). In this regard, it was matched by IBM, GE and others.

At the "Routing" layer in which documents are received, sent, etc., as I described in my earlier note, the processes described in the current Patent Application (receiving inbound invoice documents, sending outbound documents, holding them, etc.) were anticipated and instantiated in the 1980s by repurposing email constructs – directories, profiles, and email boxes for EDI purposes. If a company signed up for EDI service with a VAN (value added network), the customer essentially was buying a somewhat hardened, more expensive email service (e.g., with the ability to retransmit archived messages).

The invoice-translation and "dynamic data" portions of the patent application describes how the hypothetical "apparatus" would 1) translate idiosyncratic inbound invoices (e.g., received from, say United States Steel) into some apparatus-standard intermediary form, 2) it would at some future time then retranslate the invoice from the intermediate version to the version suited to the recipient (e.g., Ford) and then send the resulting invoice to the recipient. The description of translating an inbound invoice into an intermediary form to avoid many to many translations was (and is) a familiar approach. For example, in the bad old days of the 1980s and 1990s before Microsoft so kindly standardized the office environment for us all, there were translators from one word processing package to another that used intermediates.

The description in the application of what "apparatus" is needed to do the translation is so generic that from a programming perspective it can be (and was) instantiated any programming language that supports conditionals (If…Then), string functions, and arithmetic operators – e.g., Basic, COBOL, C, etc. If one had access to the spec for a 1980s translator package or reverse engineered the spec from the source code, it would exhibit and instantiate the essentials of "translation." The notion that everything was made new by innovations such as http or html or XML or TCP/IP as well as the overall "halo effect" of Internet eBusiness in my view blinded the USPO to the reality that predecessor technologies had instantiated what were thought of as "new" methods. The U.S. Patent office approved and indeed encouraged the submission of "business methods" patents during the Internet bubble years, leaving a challenging legacy.

Those who applied for business process patents are not to blame for applying and indeed may have had to do so to preempt others and to satisfy funders that their intellectual property was duly protected. Instead the USPO is to blame for not fully vetting the applications against prior art and, more specifically, not having examiners with the time and preparation needed to discern the essential commonalities between newly submitted business method patent applications and long-existing products and services (whose conceptual "business methods" were not protected by business process patents, because the USPO in the 1970s and 1980s did not encourage such applications).

Fulton Wilcox

From: Mikkel Hippe Brun [mailto:mhb@schemaworks.com]
Sent: Monday, June 08, 2009 4:20 AM
To: ubl-dev@lists.oasis-open.org
Cc: fulton.wilcox@coltsnecksolutions.com
Subject: Re: [ubl-dev] OB10 patent on common e-invoicing pattern?

Fulton,

I do apologize about the links. Copy paste from web-mail is not advisable.

My interpretation of the patent can be found here: http://bit.ly/JxvZX
Blogpost where I am collecting evidence to be used in a notice of opposition: http://bit.ly/l0zBq. Please help out collecting evidence.

US patent: http://bit.ly/DfgOP

European patent: http://bit.ly/fa5LM

Observe the difference between the US patent and the European patent. They could not get the US patent approved in Europe without adding "salt and pepper".

You do highlight a significant concern although the concern is probably

better addressed to the many entities involved specifically in the

translation of electronic invoices, which very well might impact for example

vertical applications from SAP, Oracle, etc.

You are right - I was hoping that some of these entities were following this list. Does anyone know of a more appropriate forum to raise this concern in?

The patent application (from 2002) does not reference an existing

instantiation, but instead is apparently a purely business method patent

application. It describes a conceptual describes a single point of

translation, with an "apparatus" determining how to translate an inbound

invoice based on from whom it is received and how to translate the inbound

document based on to whom it is going. It references storing the document in

an intermediate form although that feature is characteristic of many-to-many

translators.

Yes that is what I find so upsetting.

So - would an "off the shelf" product like BizTalk (available in 2000) be covered by the patent? Or is it only the use of BizTalk in the scenario specified by the patent, that is covered? To me the patent could be reduced to the following essence:

Take an "off the shelf" middleware product

Use it like any other VAN would use it
Add "salt and pepper" to the conversion (that's the unique part)
Done - that's the patent.

Based on the application text, tt appears to apply only to some central

in/out third party processing service.

But could it not cover products that has this capability? Is it only processing services? They are putting a significant limitation on the use of "off the shelf" products with the patent. How would you do it any other way if you were a service provider running with a "three corner business model"?

The resulting patent, if approved, apparently would not apply if the sender

(or the sender's agent) does translation into, say, UBL, and at the far end

the receiver (or the receiver's agent) does translation from UBL into the

receiver's chosen output.

Agree - there are ways around the patent, but traditional business of Value Added Network operators, where they do all the conversion is covered.

Also, it apparently would not apply if in-network translation was determined

not by something specifically associated with the originator or receiver

point, but instead by something embedded the document – e.g. information as

to UBL invoice version or ANSI EDI version, etc.

Well - you would need some table with information about the expected format of the end receivers.

From what I saw online, the applicants' U.S. Patent Application does not

reference the existence of prior art although clearly invoice translation

processes have been around for a long time – back into the early 1980s.

Hundreds of EDI translator packages and in-network translation services

available in the 1980s and 1990s provided invoice translation.

Do you have any references to these? I have found evidence of the Commerce One solution using xCBL on the wayback machine: http://bit.ly/KBOga

The European patent varies a little form the US patent. It has the following sentence added:

"... characterised in that the input processing means (9a, 9b) is configured to: add static data to the signal received from the input transmission line means when processed into the standard intermediate form, add dynamic data to the signal received from the input transmission line means when processed into the standard intermediate form, and validate the processed signal in the standard intermediate form before storing said validated processed signal at the data Warehouse."

Source: http://bit.ly/fa5LM

In my world this translates to: "Add salt and pepper".

Given that the application does not cite prior art, it does not assert its

differences nor in what respect it offers an improvement.

The application does not claim that its method for the translation of

invoices is in any way unique as compared to, for example, the translation

of purchase orders or ship notices or any other structured document. It does

not assert nor demonstrate that some previously existing translation process

working to translate POs, etc. would not work equally well for invoices.

Agree - it is a new patent on the wheel.

The U.S. Patent Office has initiated a peer review service which might be

helpful to OASIS in watch for patents that involve standards domains. - see

http://www.peertopatent.org/

Very usefull thank you. How do we make sure that we do not discover something like this less than two months before a decision is finalized. It is very frustrating that we have to watch our back like this. I respect patents on genuine inventions. This patent is just obstruction, wast of money and time. And worst of all - it is delaying global roll out of electronic invoicing. I guess it is the "immune system" of an old service provider trying to fight the "viral" technologies and business practices.

All the best

Mikkel

Mikkel Hippe Brun

ubl-dev message