T 2366/15 () of 26.6.2020

European Case Law Identifier: ECLI:EP:BA:2020:T236615.20200626
Date of decision: 26 June 2020
Case number: T 2366/15
Application number: 02736449.6
IPC class: G07F17/12
G06Q10/00
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 407 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: SYSTEM AND METHOD FOR FACILITATING DELIVERY AND RETURN SERVICE
Applicant name: Singapore Post Limited
Opponent name: KEBA AG
ByBox Holdings Limited
Board: 3.4.03
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56 (2007)
European Patent Convention Art 83 (2007)
European Patent Convention Art 123(2) (2007)
European Patent Convention Art 123(3) (2007)
Keywords: Main Requst - not admissible (reformatio in peius)
Inventive step - auxiliary requests (no)
Catchwords:

-

Cited decisions:
G 0009/92
G 0004/93
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is against the interlocutory decision of the Opposition Division to maintain European patent No. EP 1 444 619 with the application number 02 736 449 in amended form. It concerns a system and method for facilitating delivery and return services.

II. The opposition was based on the grounds of opposition under Article 100 (a)-(c) EPC, i.e. inventive step, sufficiency of disclosure and added subject-matter.

In its decision, the Opposition Division found that the Main Request met the requirements of Articles 123(2) and 83 EPC but rejected the Main Request for lack of inventive step. The First Auxiliary Request was found to meet the requirements of the convention.

III. All parties - the Patent Proprietor and Opponents 1 and 2 - appealed this decision. With its statement of grounds of appeal, the Patent Proprietor maintained the Main Request and First to Third Auxiliary Requests which were filed before the Opposition Division.

IV. With its response dated 14 July 2016 to the appeals of the Opponents, the Proprietor filed Auxiliary Requests 1B and 3A.

V. In a communication annexed to summons to oral proceedings, the Board gave its preliminary opinion on the requests on file.

VI.

VII. With letter dated 12 March 2020 the Proprietor has withdrawn the appeal.

VIII. With letter dated 25 March 2020 Opponent 2 has withdrawn the request for oral proceedings and requested that the appeal be decided based on the written submissions. With letter dated 30 March 2020 Opponent 1 also has withdrawn the request for oral proceedings.

IX. Oral proceedings scheduled for 11 September 2020 have therefore been cancelled.

X. The Appellant - Opponent 1 (hereafter "Opponent 1") requested that the decision under appeal be set aside and that the patent be revoked.

XI. The Appellant - Opponent 2 (hereafter "Opponent 2") requested that the decision under appeal be set aside and that the patent be revoked.

XII. The Respondent - Patent Proprietor (hereafter "Proprietor") requested that the decision under appeal be set aside and that the patent be maintained on the basis of the Main Request as filed with letter dated 13 August 2015 before the Opposition Division. Alternatively the Proprietor requests maintenance of the patent in amended form based on one of First Auxiliary Request, Auxiliary Request 1B, Second Auxiliary Request, Auxiliary Request 3A and Third Auxiliary Request, the First to Third Auxiliary Requests as filed with letter dated 13 August 2015 and Auxiliary Requests 1B and 3A as filed with letter dated 14 July 2016.

XIII. Reference is made to the following documents:

E1 = WO 01/65431 A2

E3 = WO 01/48641 A1

E4 = US 6,300,873 B1

E6 = WO 00/51750 A1

E11 = WO 01/13286 A2

XIV. The patent was maintained in amended form by the Opposition Proceedings with the following claim wording (Claim 1) according to the First Auxiliary Request (underlining and labelling added by the Board here and in the following citations):

(I) A method for facilitating transfer of goods between a delivery party and a receiving party in a locker system comprising at least one locker module (15) having at least one locker unit, said method comprising the steps of:

a) providing, by said receiving party to said delivery party, at least one user input having at least one notification identifier associated with the receiving party;

b) receiving, by at least one controller (10) of said locker system, said at least one user input provided by said delivery party;

c) processing, by said at least one controller (10), said at least one user input to allow said delivery party to unlock and to deposit said goods into a locker unit of said at least one locker module (15); and then

d) generating, by said at least one controller and based upon said at least one user input, at least one notification message to said receiving party, said at least one notification message having an identification code for unlocking said locker unit to retrieve said goods,

e) the identification code being a unique one-time code for a given transaction that cannot be used again for another transaction; and

f) accessing said locker unit by a customer to collect said goods, said access depending upon said customer entering said identification code and said notification identifier.

XV. Claim 1 of the Main Request is identical to claim 1 of the Auxiliary Request except that Feature f) (underlined) is missing.

XVI. In Auxiliary Request 1B "Customer" is replaced by "receiving party" in Feature f).

XVII. In the Second Auxiliary Request Features e) and f) are omitted, instead in Feature a) the "notification identifier" is replaced by a "delivery identifier":

(Board's labelling, additions and [deleted: deletions] with respect to the Main Request highlighted by the Board)

(I) A method for facilitating transfer of goods between a delivery party and a receiving party in a locker system comprising at least one locker module (15) having at least one locker unit, said method comprising the steps of:

a) providing, by said receiving party to said delivery party, at least one [deleted: user input having at least one notification] delivery identifier associated with the receiving party;

a2) providing by said delivery party to said receiving party, a delivery advice comprising the delivery identifier corresponding to a delivery attempt;

b2) receiving, by at least one controller (10) of said locker system, [deleted: said] at least one user input provided by said delivery party via said locker module, said at least one user input being associated with said receiving party and comprising said delivery identifier;

c) processing, by said at least one controller (10), said at least one user input to allow said delivery party to unlock and to deposit said goods into a locker unit of said at least one locker module (15);

c2) and then providing by said receiving party to said at least one controller (10) at least one notification

identifier based upon said at least one delivery identifier;

d)and then generating, by said at least one controller and based upon said at least one user input, at least one notification message to said receiving party, said at least one notification message having an identification code for unlocking said locker unit to retrieve said goods.

[deleted: e) the identification code being a unique one-time code for a given transaction that cannot be used again for another transaction].

XVIII. Auxiliary Request 3A corresponds to Auxiliary Request 1B with the addition that the "notification identifier" is specified in feature a) for "providing information to send a notification message".

XIX. The Third Auxiliary Request comprises in addition to the First Auxiliary Request the feature

a3) "the notification identifier comprising one of a mobile number, a pager number, a phone number, an email address and an instant messaging identifier".

XX.

XXI. The arguments of the Proprietor can be summarized as follows regarding inventive step of the Main Request and First Auxiliary Requests:

E1 was closest prior art and did not disclose or teach a "notification identifier". None of the documents taught the use of a unique and one-time code in combination with the teachings of E1. The prior art merely taught entry of a generic second code such as a pin code in addition to an identification code. The invention however defined instead entry of the same code ("notification identifier") that was used to generate a notification message. This meant that the notification identifier and the identification code are inherently linked in a way that was neither disclosed nor suggested by any of the cited prior art.

XXII. The Opponents have argued that E3 or E4 taught a unique and one-time code and that the combination of E1 or E6 with these documents deprived the claimed invention of inventiveness.

Reasons for the Decision

1. The claimed invention

1.1 The claimed invention concerns a locker system for storing goods. In most existing delivery and pickup systems, identification cards or IC Cards are used as a credentialing means at the storage system when picking up a delivered product. This creates a problem when the IC card is lost, spoilt or cancelled.

1.2 What should be provided by the claimed invention is a delivery and pickup system that keeps track of all transactions and transacted parties, reports status of these transactions and intelligently keeps payment data relating to the transactions.

1.3 Such a system should be reliable, safe and convenient to use. It should not require user registration or users to have prior knowledge of the system. In addition, the delivery and pickup system should be able to provide all relevant parties automated notification of a delivery in a convenient manner (paragraphs [0009] and [0010] of the impugned patent).

2. Main Request and Second Auxiliary Request - Reformatio in Peius

The Proprietor has withdrawn the appeal and therefore both opponents are the only appellants left with the Proprietor as Respondent. According to G9/92 and G4/93 the principle of Reformatio in Peius now applies (Headnote 2). The Proprietor is therefore primarily restricted in the appeal proceedings to defending the patent as maintained, in the present case the patent according to the First Auxiliary Request. Consequently, the Main Request is no longer admissible. Furthermore, as claim 1 of the Second Auxiliary request is broader than that of the patent as maintained (deletion of Feature e)), this request is also no longer admissible.

3. First Auxiliary Request and Auxiliary Request 1B -inventive step (Article 56 EPC)

3.1 Closest prior art

3.2

3.2.1 In the first instance proceedings E1 was considered to be closest prior art for the Main Request and the First Auxiliary Request. It was conceded by the parties and the Opposition Division that feature e) and feature f) of claim 1 were not disclosed by E1. Assessment of inventive step was made starting from E1 and combining E1 with E3 or E4.

3.2.2 E6 was also proposed by the opponents as closest prior art. E6 has indeed more features in common than E1, in particular E6 discloses a "notification identifier" and is also from the same technical field. Therefore, the Board considers E6 as closest prior art.

3.3 Disclosure of E6 - Features (I) - c)

3.3.1 Opponent 1 argued that E6 disclosed the following features:

Feature (I): See page 1, lines 3-4: "This invention relates to the highly efficient distribution of parcels to large number of users with security and ease of use".

Feature a): See page 9, lines 6-10: "At step 30, recipient (i.e. customer) data such as name, credit card number or other payment means, and contact information such as email-address or telephone number is acquired".

Feature b): See page 9, lines 10-12: "This information is input into the customer delivery database within the memory of local controller 18, which resides at the customer designated geographical location".

Feature c): See Page 10, lines 18-26: "Receipt of parcel from carrier step 38 occurs at the time the carrier delivers the parcel to local unit 10. [...] Local controller 18 locates the designated parcel and the receptacle assignment in the customer delivery database [...] local controller 18 unlocks the assigned receptacle 14 by application of a signal [...]. Local controller 14 will display a prompt asking the carrier whether the parcel was placed in the assigned receptacle. If the carrier responds yes, local controller 14 will lock the assigned receptacle".

The Board agrees with this reasoning.

3.4 Disclosure of E6 - contested Feature d)

3.4.1 For this feature Opponent 1 referred further to

(a) Fig. 2, step 38: "Send notice to recipient (notifying geographical location, parcel receipt date, and receptacle number)";

(b) Page 12, lines 23-24: "The notice given to the recipient in step 38 will be sent automatically by issuing an e-mail";

(c) Page 9, lines 19-23: "The customer order with intent to use the delivery service of the invention is acknowledged by the issuing of a password by communication over the Internet to the customer. Alternatively, other information such as an order identification number or receptacle number (where the parcel will be stored) may be issued to the customer in addition to the password."

(d) Page 4, lines 24-26: "The recipient is notified at the time the parcel has been received such that the recipient may come for pickup at his or her earliest convenience".

3.4.2 The Proprietor argued that E6 only disclosed that an access code was supplied to the customer when they indicate an intent to use the delivery service, which was generally the time at which an order is placed. The password, order identification number and/or receptacle number were therefore supplied at the time of acknowledgement of the order, which was distinct from the time at which a parcel is ready for pickup.

3.4.3 The Board however is of the opinion that the wording of claim 1 is such that Feature d) can be read on E6 according to the assessment made above, in particular in view of the disclosure on Page 9, lines 21-23 (see item (c) in section 3.4.1.).

3.5 Disclosure of E6 - contested Features e)

3.5.1 Regarding Feature e), the Opponents argued that after reaching step 42, the process shown in E6 starts again at step 30 and runs again and again for a large number of different recipients and transactions. The process according to Fig. 2 was therefore a loop process that repeated itself several times. This inevitably meant that the access password generated in accordance with E6 must be unmistakable and unique and must also be a one-time code.

3.5.2 The Proprietor argued that the Opponent has separated two features of the code - these features being that it was a "unique" AND "one-time code". E6 did not disclose both that the code is "unique" and a "one-time code".

3.5.3 The Board agrees with the Opponents that a unique code is disclosed in E6, because "unique" has a quite broad meaning. There is however no explicit or implicit disclosure that this unique code is a "one-time" code. Therefore, the Board is of the opinion that the feature "one-time" is not disclosed in E6.

3.5.4

3.6 Disclosure of E6 - contested Feature f)

3.6.1 The Opposition division found in its assessment starting from E1 that Feature f) is not disclosed. The Board however has chosen E6 as closest prior art, because it is of the opinion that E6 does disclose Feature f) in contrast to E1:

3.6.2 The opponents noted that E6 disclosed that a credit card number can be included in the "recipient data", corresponding to the notification identifier of the claim. E6 disclosed at page 4, lines 30-33 that "access to the receptacle can be made conditional upon the entry of the correct password as well as valid physical identification, such as credit card, whereby online credit card fraud and other unauthorized access is deterred".

3.6.3 The Board is of the opinion that this anticipates "said access depending upon said customer entering said identification code and said notification identifier" in Feature f) of claim 1. The credit card number is entered physically by inserting the credit card into the locker. However, the claim wording "entering" leaves it open, whether the credit code (credit card number) is entered manually or via a card reader.

3.6.4 The Board is of the opinion that in view of the disclosure of the description the term "notification identifier" has to be construed in a broad manner. Paragraph [0032] states that by associating a smart card and a PIN number (identification code) to an individual, the smart card is able to uniquely identify a person. Paragraph [0115] states that the notification identifier could be ... a good or article number (e.g. Delivery Advice Number or Parcel Identifier) ... the notification identifier can also be the login ID of the registered customer. Paragraph [0045] states that the notification identifier is associated with a customer and is something personal to the customer.

3.6.5 The Board agrees with the Opponents that in view of paragraphs [0032], [0045] and [0115] the skilled person would recognise that the "good or article number (e.g. Delivery Advice Number or Parcel Identifier)", or the "unique reference number that is assigned by the locker system", or any other single piece of information contained in a relational database and associated with the receiving party, could be used to identify the receiving party and retrieve his contact details from a database.

3.6.6 Claim 1 does not impose any technical limitations on the "notification identifier" and does not preclude the use of any particular piece of information for this purpose. On the other side the description provides enough basis for implementing the different options.

3.6.7 Claim 1 does not require the customer either to register his contact information in advance in order to use the system, or to include his contact information in the notification identifier.

3.6.8 The term "notification identifier" therefore may be construed in light of either a registered user embodiment or an unregistered user embodiment, since the claim does not recite the essential limitations of either embodiment. Consequently, E6 discloses Feature f).

3.7 Difference

The Board is therefore of the opinion that the single feature not being disclosed in E6 is that the code is a "one-time" code (part of Feature e)).

3.8 Technical effect

The technical effect of this difference is improved security relative to the system of E6.

3.9 Problem

The problem can therefore be formulated as providing improved security in a locker system.

3.10 Obviousness

3.10.1 The Opposition Division argued with respect to E3 / E4 and for a very similar problem (starting from E1) that the skilled person would search in the field of lockers having locking mechanisms controlled by access codes and find documents E3 and E4 among others. Document E4 disclosed in column 3, lines 62 to 67, that increased security (reduced theft and tampering) could be provided by using unique one-time access codes for each transaction (access, pickup or delivery).

3.10.2 Document E3 also discloses in the last paragraph of page 7, page 12 and page 13 the use of unique one-time codes associated with a particular purchase transaction for the purpose of opening lockers. The Board is therefore of the opinion that the use of unique one-time codes was at the priority date of the invention well-known to the skilled person for the purpose of opening electronic lockers. This motivates the skilled person to modify the method of E6 by including Feature e).

3.10.3 The Board therefore is of the opinion that confronted with the aforementioned problem, the skilled person would be pointed to E3 or E4 among others and would modify the method of E6 by providing a unique and one-time code to the customer in step 32 (Feature e)). Consequently, the subject-matter of claim 1 of the First Auxiliary Request does not involve an inventive step within the meaning of Article 56 EPC.

3.10.4 Replacing "Customer" by "receiving party" in Auxiliary Request 1B does not make a difference for the inventive step reasoning. Consequently, the subject-matter of claim 1 of Auxiliary Request 1B is also not inventive over E6 in combination with E3 or E4.

4. Auxiliary Request 3A - Third Auxiliary Request

4.1 Difference

4.1.1 The main difference of these Requests with respect to the First Auxiliary Request is that "notification identifier" is limited to be suitable for "providing information to send a notification message" (Auxiliary Request 3A) and comprises one of "a mobile number, a pager number, a phone number, an email address and an instant messaging identifier" (Third Auxiliary Request).

4.1.2 E6 does not disclose these differing features and the feature "one-time code".

4.2 Effect

The effect of using an email address or phone number instead of a credit card number is that the customer can be contacted via the "notification identifier" directly and a notification message together with further information can be provided.

4.3 Problem

Starting again from E6 the problem therefore can be formulated as providing a notification identifier, which allows to notify the client and which can be used as identifier in the locker system.

4.4 Obviousness

4.4.1 E11 explicitly teaches that instead of a credit card number other "notification identifiers" can be used such as a phone number (page 5, line 12ff, underlining added by the Board):

"Bei der frei wählbaren Zuordnung des Schlüssels zum Schloß ist es insbesondere möglich, daß eine eindeutige personenbezogene Kennung, beispielsweise eine Kreditkartennummer des Übernehmers, bzw. eine eindeutige Kennung des dem Übernehmer gehörigen Endgeräts, beispielsweise die Mobilfunknummer, als Schlüssel gewählt wird und dem Schloß zugeordnet wird". Translation: "If the key can be freely assigned to the lock, it is in particular possible to chose a unique personal identifier, such as a credit card number of the recipient, or a unique identifier of the terminal device belonging to the recipient, such as the mobile telephone number, as key and assign it to the lock".

4.4.2 The Board therefore is of the opinion that it would have been obvious to the skilled person to use an email address or phone number instead of a credit card number as "notification identifier".

4.4.3 Consequently, the Board is of the opinion that the subject-matter of claim 1 of the Third Auxiliary Request, and therefore also of Auxiliary Request 3A, does not involve an inventive step within the meaning of Article 56 EPC

5. Conclusion

Consequently, the Board is of the opinion that none of the present Requests fulfills the requirements of the EPC.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2 The patent is revoked.

Quick Navigation