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

On Tue, Jun 9, 2009 at 10:18 AM, Sacha Schlegel <sacha@schlegel.li> wrote:

Hi UBL List

Support http://stopsoftwarepatents.org/ to fight Software Patents.

Allows groups like the Universal Business Language (UBL) to be as
creative and innovative as possible and not to be stopped by Software
Patents.

We simply want to bring the world a step ahead ... actually the Universe
in this particular case :-)

Regards

Sacha

Am Dienstag, den 09.06.2009, 00:09 -0700 schrieb Danny Gaethofs:

> Dear Mikkel,
>
> There are other companies that received patents for einvoicing
> components:
>
> http://www.bottomline.co.uk/news/press_releases/patent.html
> Bottomline Technologies (NASDAQ: EPAY), a leading provider of
> collaborative payment, invoice and document automation solutions,
> today announced that the company has been granted a technology patent
> by the United States Patent and Trademark Office for advanced
> capabilities enabling the automated, rules-based validation of invoice
> data.
>
>
> SAP AG (Walldorf, DE)
> Methods, systems and software applications for verifying certain
> requirements on electronic documents
>
> http://www.freepatentsonline.com/7519817.html
> 1. A method for automatically processing a first electronic document
> sent from a sender to a designated receiver, the first electronic
> document including a digital signature, the method comprising:
> receiving the first electronic document from the sender; validating
> the digital signature by usina a public key of the sender; checking
> whether the digital signature is from a person or a legal entity
> authorized to send the first electronic document; determining, if the
> person or the legal entity is authorized to send the first electronic
> document, whether the person or the legal entity that signed the first
> electronic document is authorized by an issuer named in the first
> electronic document to sign the first electronic document; creating an
> electronic protocol of the results of validating, checking, and
> determining; signing the protocol; archiving at least one of data
> selected from the group consisting of the protocol and the first
> electronic document; and presenting the first electronic document to
> the designated receiver.
>
> 2. The method of claim 1, further comprising: converting the first
> electronic document into a format supported by the designated
> receiver.
>
> 3. The method of claim 1, further comprising: requesting a time stamp
> from a trusted authority and adding the time stamp to the first
> electronic document before archiving.
>
> 4. The method of claim 1, further comprising: requesting a time stamp
> from a trusted authority and adding the time stamp to the first
> electronic document before presenting.
>
>
> Accenture LLP (Palo Alto, CA, US)
> http://www.freepatentsonline.com/7069234.html
> Initiating an agreement in an e-commerce environment
>
>
>
> ONLINE INVOICING AND PAYABLES INFORMATION DATABASE WITH A WEB
> INTERFACE
> http://www.freepatentsonline.com/WO2004092892.html
>
>
> Kind regards
> Danny Gaethofs
>
> ______________________________________________________________________
> From: Danny Gaethofs <dgaethofs@yahoo.com>
> To: Mikkel Hippe Brun <mhb@schemaworks.com>;
> ubl-dev@lists.oasis-open.org
> Cc: fulton.wilcox@coltsnecksolutions.com
> Sent: Tuesday, June 9, 2009 8:42:04 AM
> Subject: Re: [ubl-dev] OB10 patent on common e-invoicing pattern?
>
> Dear Mikkel,
>
> On linkedin.com there is a groups called Service Oriented Architecture
> Special Interest Group with over 10000 members. Maybe it is a good
> idea for you to drop your concerns on this patent there.
>
> The URL is: http://www.linkedin.com/groups?gid=36604
>
> I am looking into this patent and from what I can read it looks like a
> very high-level conceptual proposal for how such an communication
> apparatus should work.
>
> Whereas most of the functionality proposed comes from what enterprise
> service bus and soa architecture are providing. So I am surprised and
> I wonder how the patent offices validate these kinds of requests.
>
>
> kind regards
> Danny Gaethofs
>
>
> ______________________________________________________________________
> From: Mikkel Hippe Brun <mhb@schemaworks.com>
> To: ubl-dev@lists.oasis-open.org
> Cc: fulton.wilcox@coltsnecksolutions.com
> Sent: Monday, June 8, 2009 10:19:46 AM
> 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
>

> 1. Use it like any other VAN would use it
> 2. Add "salt and pepper" to the conversion (that's the unique
> part)
> 3. 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
>
>
>

--
Homepage: http://sacha.schlegel.li
Microblog: http://identi.ca/sacha
Neuste Veranstaltung: BarCamp Dornbirn 6.-7. Juni 09 http://is.gd/pFD9
Neustes Projekt: http://www.nosomi.com, http://www.breakpoint.li

ubl-dev message