T 1338/04 (Message delivery/READSOFT) of 4.3.2008

Summary of Facts and Submissions

I. European patent application number 01124499.3 (publication no. EP-A-1 302 879) filed in 2001 concerns a method and a system for delivering a message from a sending party to a receiving party.

II. In the examination proceedings, the following documents (among others) were cited as relevant prior art:

D1: US-A-6 119 137 (published on 12 September 2000)

D5: W. J. McCalpin: "Traditional Electronic Printing on the Internet", November 1998, GCA Conference XML 98, Chicago (retrieved from http://www.info loom.com/gcaconfs/WEB/chicago98/mccalpin.HTM)

The examining division refused the application by a decision posted on 13 August 2004. The reason given for the refusal was lack of inventive step in the light of documents D1 and D5. The principal (but non-inventive) difference over the prior art was considered to reside in the features defining the message data stream as a print stream, from which information about the receiving party was extracted directly, using the existing infrastructure.

III. The appellant (applicant) filed an appeal and paid the appeal fee on 6 September 2004. On 3 November 2004, the appellant filed amended claims and a written statement setting out the grounds of appeal.

IV. The Board issued a negative opinion under Article 110(2) EPC on the allowability of the appeal. In its provisional view, the present application -- like document D1 -- seemed merely to relate to the selective routing of a data stream produced by a personal computer, for example, to a printer and other delivery means. The Board cited additional passages in document D1 and indicated that it considered as non-inventive to apply the teaching of document D1 to a configuration where a personal computer created a file in a high level representation format (as e.g. Postscript®) and sent it unaffected in its format, directly or over a network, to an appropriate (Postscript®) printer.

V. In a reply letter dated 24 October 2007, the appellant submitted further comments in support of the appeal and filed an amended set of claims 1 to 19, claim 1 including the features of previous dependent claims 2 and 4 and reading as follows:

"1. A method of determining whether a message is to be delivered from a sending party to a receiving party electronically as an e-mail, or in paper form by post mail or fax, or any combination thereof, characterised by the following steps performed automatically in a message delivery unit (100) at the sending party which is connected to a message generating unit (102) and a printer unit (104):

- A) receiving a message data stream from the message generating unit, the message data stream defining the message in a format normally used as input to printers,

- B) retrieving information from a recipient database (112),

- C) investigating the received data stream for identifying the receiving party,

- D) comparing the retrieved database information with the received data stream, in order to detect a match between the retrieved database information and the received data stream by which the receiving party can be identified, and

- E) determining whether the message is to be delivered from the sending party as an e-mail, or in paper form by post mail or fax, or any combination thereof, based on the investigating and comparing steps C), D),

wherein it is determined in step E) to deliver the message in an e-mail if a match is detected in step D) between the retrieved database information and the received data stream, and it is determined in step E) to deliver the message in paper form by post mail or fax if no match is detected in step D) between the retrieved database information and the received data stream, and

wherein the data stream is forwarded unaffected in the received format, to the printer unit for printing the message, if it is determined to deliver the message from the sending party in paper form in step E)."

VI. The appellant requested that the decision of the examining division be revoked in its entirety, and that the application proceeded to grant.

VII. The arguments of the appellant submitted in its written submissions of 3 November 2004 and 24 October 2007 may be summarised as follows:

(a) The present invention was concerned with the problem of determining, automatically and selectively, the delivery form of messages as e-mail or in paper form, without involving any time consuming and/or costly manual routines, or additional supervising control signalling. It was now clear from the amended independent claims 1 and 13 how the delivery form was determined based on whether a match was detected or not in step D.

(b) The above aim was achieved by investigating the print stream received from a message delivery unit for identifying the receiving party, retrieving information from a recipient database, comparing the information with the print stream, and determining the delivery form from the result of the comparing action. According to the present invention, a print format was converted into a high-level electronic document format if this was the appropriate delivery form; in contrast to document D1, where the format conversion always took place from a high to a low level representation format.

(c) The message delivery unit of the present invention was distinct from the DDCS server in D1. It resided and operated basically at one specific sending party, whereas the DDCS in D1 was an intermediate server handling electronic format conversion of documents transmitted between plural senders and receivers. It did neither include a printer driver, nor a destination selector, nor did the DDCS server execute any of the steps claimed.

(d) In document D1, the information regarding the delivery form was derived by making a normal database lookup using a pre-given address data as key. The claimed invention derived the appropriate delivery form directly, by making a match with the recipient database, from the address data encoded in the print stream. It was not an easy task, and actually required technical specialisation in this area, to extract data from print streams since such kind of address data, e.g. the postal name and address, was an unstructured piece of information, one or more of them could be located anywhere in the document, they might include abbreviations, etc.

(e) Document D1 did not disclose or even suggest how the recipient could be identified and the delivery form could be determined merely on the basis of information present in the print stream. The mapping tables 1 and 2 in document D1 did not indicate any such capabilities of users.

(f) E-mail could of course be used to deliver a document. However, it was an entirely different matter to automatically pick out individual documents from a print stream to be sent electronically by e-mail, leaving documents to be sent in paper form by post mail, unaffected in its format. In document D1, the delivery format was always electronic; paper form was not mentioned. Although the receiver´s equipment could be a printer, in which case the delivered document was converted into paper form by the receiver after delivery, document D1 was entirely directed to electronic delivery formats.

(g) The present invention could be carried out without undue efforts, using the publicly available documentation on print formats. For Windows, for example, an intermediate native print data stream format could be used in a spooling system for the matching and extraction operations. Principally, all standard applications that print within a Windows environment used this process.

Reasons for the Decision

1. The appeal is admissible.

2. The appeal, however, is not allowable since the method for which claim 1 of the present request seeks patent protection does not meet the requirement of inventive step as set out in Article 56 EPC 1973 (according to the transitional provisions of EPC 2000).

3. In fact, the method claimed is obvious in the light of document D1. This document certainly forms a relevant piece of prior art: it discloses a method for delivering an electronic document to one of different receiving units in a representation format selected on the basis of the capabilities of the recipient and the type of the electronic document to be delivered (see for example the summary of the invention on col. 2, line 61 to col. 3, line 10 and claim 1).

4. Document D1 describes two basic applications of the method, both involving one or more so-called dynamic document conversion or DDCS servers:

In the embodiment of figure 1, the document is sent, in a high-level, transportable data format, to a DDCS server 20 via an intermediate DDCS server 10 and is then delivered, in an appropriate representation format, by the DDCS server 20 to a final receiving unit, in fig. 1 either to a printer 18, a PC 14, or a fax machine 16.

In the embodiment of figures 2 and 3, the document is forwarded by a DDCS server (DDCS 26) directly to the intended recipient without using any intermediate DDCS server (D1, col. 4, line 54 to col. 5, line 4). In a variant of this embodiment, also illustrated in fig. 3 and described in D1, col. 5, line 10 to line 20, the document data are generated from paper by a scanner 43 in a low-level representation, which is then converted into a high-level representation by the sender's computer, for example by using optical character recognition technology.

Although both embodiments are relevant to the present invention as claimed, this last variant of the second embodiment is most appropriate as starting point for assessing inventive step.

5. Scanner 43 produces the data in a "low-level representation", which is then converted by the sender's computer 22 to data in a "malleable, yet high-level, representation" and "portable representation", respectively, using for example a "virtual printer driver" (see D1, col. 5, lines 14 to 34). Data produced by a virtual printer driver can, by definition, be used as input to an appropriate type of printer. Hence, sender 43 and computer 22 of document D1 meet the definition of a "message generating unit at the sending party" in the terminology of present claim 1.

Actually, a narrow construction of the message format in claim 1 does not find any support in the application. In paragraph [0002] of the present application it is stated that "(i)n this description, the word 'message' will be used in the broad sense of any written text and/or images intended to be read and/or analysed by ... persons and/or machines ...". In paragraphs [0018] and [0019], it is then said: "... The message generating unit 102 may thus generate a normal printer data stream regardless of whether the message is to be delivered electronically or in paper form by post or fax. [0019] The invoice data stream [generated by the message generating unit] includes information on the invoice content, such as texts, lines, tables, images, layouts etc., preferably in a format normally used as input to document printers according to a pre-defined printer standard, which will not be described here further. ... However, any data stream format may be used within the scope of the invention."

Since practically any format is accepted as input to a normal printer, provided that an appropriate print driver is installed, present claim 1 must be construed to encompass embodiments using any format at the input of the message delivery unit, of high as well as of low representation level whatever low and high may mean in this context.

6. Furthermore, the data are transmitted to DDCS server 26, which finally delivers the data in an appropriate representation format to the recipient. The recipient unit shown in figs. 2 and 3 is a PC, but document D1 also refers to printers as a suitable recipient unit, as explicitly disclosed for example in col. 6 lines 5 to col. 7, line 51 in connection with Table 2, column 6 "Target Device (Recipient)", and particularly col. 7, lines 44 to 49. The DDCS server 26 is thus a message delivery unit in the sense of present claim 1 and the appellant's submission to the contrary (see VII (c) above) cannot be accepted.

It follows that document D1 anticipates the claim features up to and inclusively step A) of claim 1.

7. Moreover, a recipient database stores information about the recipient's capabilities to receive and process data received from the message delivery unit (document D1 fig. 3, user database 37 and/or a LDAP - Lightweight Directory Access Protocol - server providing a directory, see col. 6, line 66 to col. 7, line 41). "Capabilities information pertinent to a particular delivery" is retrieved from the LDAP server by using a query engine (see D1, col. 7, lines 26 to 33).

A "directory" service allows access to data by providing a name, address etc., which in document D1 can only be the delivery address identifying the recipient. Since document D1 refers to a standard network protocol like HTTP, it follows that the delivery address is encoded into the message data stream and determined by the message delivery unit through investigating the message data stream.

8. Making a query to a LDAP server, therefore, means that the search for the address is made in the directory and the corresponding information is retrieved. The event that the specific address is present in the directory, and thus the query is successful, may be called the detection of a "match" between the retrieved database information and the received message data stream, since in both pieces of data the information identifying the recipient (the name, address etc) must match.

Hence, steps B), C), and D) of the claimed method are considered to be fully anticipated by document D1.

The appellant submitted that document D1 was related to a normal database look-up using a pre-given address data as key, whereas the invention extracted the address data from a print stream, in which such kind of data could be hidden as an unstructured piece of information anywhere in the document (see VII(d) and (e) above). This argument, however, is based on a unjustified narrow construction of the claim wording. There is nothing in the claim or elsewhere in the application which excludes an embodiment using a format providing for a separate address field, for example, which explicitly contains the address data used for searching the recipient database. On the contrary, the description, col. 5, line 7 expressly refers to an embodiment where "predefined fields" of the received data stream must be scanned to identify the recipient.

9. According to document D1, the DDCS server determines from the result of the query whether a data conversion is necessary or not and delivers the document to the recipient in the appropriate format. The delivery format might include e-mail (see document D1, col. 5, lines 64 ff.), post mail or fax (printer and fax machine, see D1, Table 2 in col. 6). Hence, step E) is also known from document D1.

10. The method of present claim 1 differs from the prior art of document D1 only by the scheme how to decide on the format, which is defined in present claim 1 as follows:

"wherein it is determined in step E) to deliver the message in an e-mail if a match is detected in step D) between the retrieved database information and the received data stream, and it is determined in step E) to deliver the message in paper form by post mail or fax if no match is detected in step D) between the retrieved database information and the received data stream, and

wherein the data stream is forwarded unaffected in the received format, to the printer unit for printing the message, if it is determined to deliver the message from the sending party in paper form in step E)".

11. This scheme gives a solution to the problem that automatically arises in implementing the dynamic document delivery server of document D1, namely what to do when the database query fails to provide information regarding the required delivery format because a particular recipient is not in the directory, for example. The answer the present invention gives is straightforward: if you don't know into which delivery format the message should be converted ("no match is detected"), deliver the message in the original format to a default delivery device, thereby leaving the data stream "unaffected in the received format". In the considered example of document D1, the received format is the format of the data stream produced at the output of the virtual printer driver - see document D1, col. 5, line 33 f. Choosing, in such a situation, an appropriate printer as default delivery device is an obvious design option not requiring any inventive considerations.

ORDER

For these reasons it is decided that:

The appeal is dismissed.