[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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). From: Mikkel Hippe
Brun [mailto:mhb@schemaworks.com] 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 US patent: http://bit.ly/DfgOP European patent: http://bit.ly/fa5LM Observe the difference between the
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?
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
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"?
Agree - there are ways around the patent, but traditional business of
Value Added Network operators, where they do all the conversion is covered.
Well - you would need some table with information about the
expected format of the end receivers.
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
In my world this translates to: "Add salt and pepper".
Agree - it is a new patent on the wheel.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]